Start with the pages that matter
Ask for examples from your important service, location and contact pages. Can visitors reach them? Can Google consider them for search? Is an old address being shown instead of the current page? A long audit can contain many warnings with very different consequences.
A useful issue description might say that three live service pages still carry a setting intended to hide previews from search. It should name those pages and explain the proposed correction, rather than present a score without context.
Separate broken tasks from optional improvements
Prioritise unavailable pages, incorrect destinations and failed contact routes. Then assess slower pages, confusing navigation or other problems that affect real use. An advisory warning about an optional enhancement may deserve less attention.
Ask the supplier to distinguish what is observed from what is suspected. A slow laboratory test can suggest a problem, but it does not show how every visitor experienced the page.
Agree the repair and the acceptance check
- Which public pages are affected?
- What will change and who approves it?
- What working behaviour must be preserved?
- How will you test the published result, including on a phone?
- How would the team recover if the change caused a problem?
After a repair, repeat the original failing task. A successful deployment message alone does not show that the visitor's problem has been resolved.
Keep search results separate from technical completion
A corrected page can become eligible for crawling or indexing without receiving an immediate ranking improvement. Ask for the change date, evidence of the completed fix and a sensible later review of search performance. Technical work should be accountable without being sold as a guaranteed traffic increase.
Sources and further reading
Choose a useful next step
Bring the audit or the problem you can see. We can help turn it into a short list of explained actions.
