A useful way through
- Describe the business question and the actual audience before requesting a proposal. Identify current useful pages and any known technical problems. Separate verified analytics from estimates and sales claims; a tool’s traffic forecast is not a record of customers.
- Ask for a scoped audit explaining findings, recommended changes, priorities and limitations. Google advises granting read-only Search Console access at the audit stage, not write access. Account ownership and permission decisions should remain with the responsible site owner.
- Require proposed changes to name the affected pages, expected user benefit, implementation owner and verification method. Ask about risks and any third-party work. Google warns that nobody can guarantee a number-one ranking; a promised position is not an acceptance test for delivered work.
- Agree how changes will be reviewed, backed up and measured over a defined period. Keep a dated change log and compare like-for-like metrics with their limitations. A technically completed task is not proof that traffic or enquiries increased, and a changed number alone does not establish causation.
Read the map as text
A CLOSER LOOK · FINDING · 12 broken internal links · WORK · Approved destinations · ACCEPTANCE · Live link checks · OUTCOME · Separate observation · No guaranteed ranking.
- Finding
- Work
- Acceptance
- Outcome
Put it into practice
A fictional proposal says “improve product discovery”. A useful revision identifies twelve broken internal links, the intended live destinations and a check that each link reaches the correct page. A separate reporting section records available search data and its dates. The client can verify the repair without pretending that it guarantees a ranking or a sale.
Illustrative example, not a reported client project or test.
Your take-away checklist
Read an SEO proposal as work, evidence and access
- □ Finding: ____________________
- □ Work: ____________________
- □ Acceptance: ____________________
- □ Outcome: ____________________
Before you act
No ranking, traffic or commercial result is promised. This page describes proposal review, not a service endorsement or an audit of your site.
A worked record
Start with the example, then keep your own observations and confirmed information in the blank record.
- Finding
- 12 broken internal linksEvidence and destination list
- Work
- Repair approved linksNamed implementation owner
- Acceptance
- Correct live destinationsResponse and rendered link checks
- Outcome
- Search and enquiry observationPeriod and attribution limits
A question to send before signing
“For each proposed action, which page or system changes, what evidence supports the action, who approves it and what result verifies delivery?” Ask the supplier to distinguish their fee, third-party costs and optional work. Keep a vague promise out of the accepted scope until it has a concrete answer.
Separate access from ownership
Start with the permissions needed for the agreed task and review them when the work ends. Do not send passwords through a report or transfer ownership simply to receive an audit. Keep content quality, technical checks and measurement distinct; a package name does not establish any of them.
Sources & context
The earlier topic was published 2022-08-05 under the Maria Baldwin byline. The present procedure and illustrative record are by MichaelT editorial.
Source information checked 17 October 2026. Use the current requirements relevant to your situation.