The length of an audit says little about what should happen on Monday. Start with the pages the business needs customers to find, identify the crawl or indexing fault, and write a fix someone can implement and verify.
Diagnose one broken commercial page
Suppose a hypothetical product page is absent from search, while a tracking-parameter version appears. Do not begin by rewriting the copy. First establish which URL should represent the page and what the site is actually telling crawlers.
| Check | Hypothetical observation | Next step |
|---|---|---|
| Preferred URL | Clean product URL | Document it as the intended destination |
| Page availability | Clean URL loads | Check crawl and indexing evidence separately |
| Canonical declaration | Points to an old category | Investigate and correct the mismatch |
| Internal links | Mostly parameter URLs | Link consistently to the preferred URL |
| Sitemap | Contains the old URL | Update discovery to match the intended structure |
Google describes canonicalisation as a way to consolidate duplicate or very similar pages; its canonical URL guidance explains the available signals. A declaration alone does not guarantee the selected canonical.
Inspect the affected page in Search Console, record the reported state, correct the conflicting signals and check again after recrawling. Keep a before-and-after record of the actual settings, not just a screenshot of a green audit score.
Check page purpose before consolidating similar URLs. Commercial importance and a demonstrated fault should set the repair priority.
Fix the commercial fault first
Priority is a business decision supported by technical evidence. A warning repeated across thousands of low-value pages can appear more urgent than one broken product journey. Count affected URLs, but also name what their failure prevents a buyer from doing. The repair should have an owner and an observable acceptance check. Search outcomes may take longer to assess. Keeping those two timelines separate avoids both premature victory and endless reopening of a correctly implemented ticket.
Begin with the pages that matter
Identify service pages, commercial categories, product pages and supporting content that help buyers decide. Map the journey from discovery to a useful action. A broken template affecting these pages may deserve attention before a minor warning scattered across old archives.
Check a representative URL from each template. Can the intended content be accessed? Is the page available for indexing? Do links point to it? Does the user reach the expected page without errors? Verify the actual behaviour rather than relying only on a crawler label.
For marketplaces, begin with category supply and page-family decisions. For articles that exist but are hard to find, the internal-link audit can reveal a simpler problem than a platform rebuild.
Separate facts from assumptions
“Crawl found 500 duplicate titles” is a fact about the tool’s output. “This is the reason leads fell” is a hypothesis requiring more evidence. Some warnings concern low-value URLs; some reflect an intentional setup.
Record affected URLs, how the issue was reproduced, when it began if known and what business journey it interrupts. Ask the developer about constraints before prescribing a fix that creates a different problem.
Use a decision table, not a colour parade
| Issue | Priority rises when | How to validate the fix |
|---|---|---|
| Inaccessible commercial pages | Buyers and crawlers cannot reach core offers | Recheck access, content and discovery |
| Conflicting indexing instructions | Important pages are affected | Inspect delivered instructions and search status |
| Broken internal paths | Relevant pages become hard to find | Re-crawl links and test navigation |
| Poor mobile experience | Key actions fail or become difficult | Test real journeys on mobile |
| Metadata inconsistencies | Search descriptions misrepresent the page | Review templates and displayed page information |
A tool’s severity rating is a starting point. It does not know your sales model, release schedule or the value of an affected page.
Ship a fix you can evaluate
Write an implementation ticket with the template, expected behaviour, example URLs and acceptance checks. Avoid “fix SEO” as a requirement. If several templates share a component, review the wider effect before deployment.
After the release, confirm that the delivered page changed as intended. Then monitor the affected group over time. Discovery and indexing can take time, and commercial results may lag further. An immediate crawler improvement is not the same as a demonstrated revenue improvement.
For markup issues, the structured-data release checklist helps distinguish a syntax problem from inaccurate page information.
Keep a smaller, better roadmap
My preferred audit ends with a short sequence: blockers first, high-value improvements next, low-impact housekeeping later. The team should know what to do this week, why it matters and what would make us revise the priority.
That makes technical work easier to defend. It also makes “we fixed 300 issues” less tempting as a substitute for a better site.
Verify a finding before assigning priority
Reproduce the issue on actual pages. If a tool reports missing content, inspect the delivered HTML and relevant rendering behaviour. If it reports broken links, check whether the destination is genuinely wrong or whether the crawl encountered a temporary condition. Record the evidence in a way the developer can use.
Google’s JavaScript SEO documentation explains the processing of JavaScript content in Search. My implementation priority is to make important information dependable and inspectable rather than assuming every interactive page is either perfectly accessible or completely invisible.
Look at the affected template and page count, but also the importance of the URLs. Ten unavailable offer pages can matter more than thousands of harmless variations. Priority should reflect the journey interrupted, the confidence in the diagnosis and the effort required to fix it safely.
Write tickets that reduce back-and-forth
A useful ticket includes the observed problem, expected behaviour, affected template, sample URLs and acceptance checks. Include what should remain unchanged. For example, a navigation fix should preserve the relevant mobile behaviour and not expose restricted pages.
| Ticket component | Example instruction type |
|---|---|
| Observation | These links resolve to the wrong page |
| Expected behaviour | Each link reaches its matching destination |
| Scope | This shared category template |
| Evidence | Reproducible examples and crawl output |
| Acceptance | Recheck examples and representative siblings |
| Risk | Confirm no change to intended access or routing |
Avoid prescribing a particular code change when you have not inspected the architecture. Describe the requirement and collaborate on the implementation. That lets the developer solve the problem without being forced into a brittle patch.
Handle page changes as a controlled release
When an audit leads to changed URLs, templates or indexing instructions, keep an inventory of what changed. Test representative pages before and after release. Check internal links, expected content, intended metadata and important user actions. A technically correct SEO change can still break a form or navigation path.
For broader migrations, establish ownership and a rollback plan appropriate to the deployment. Do not treat redirects as a substitute for reviewing the full path. The old URL, new destination, navigation and page purpose should agree.
Keep release notes accessible to the reporting team. If tracking and templates change in the same week, analysts need to know. Otherwise a measurement difference may be celebrated as growth or blamed on search performance without the necessary context.
Distinguish immediate checks from delayed outcomes
Immediate validation asks whether the code now behaves as intended. Search validation asks whether the affected pages are discoverable and represented appropriately over time. Commercial validation asks whether the relevant buyer journey improves. These stages have different delays and should not be collapsed into one pass-or-fail date.
A fixed broken link can be confirmed quickly. A change in search visibility may take longer and have other causes. A change in revenue may take longer still. Show the stage of evidence available rather than reporting the final business effect before it can reasonably be observed.
Do not let a successful release become an unsupported SEO claim
A technical release can pass its acceptance checks before search performance changes. That proves the implementation behaved as intended; it does not prove the fix generated new demand.
Keep three records separate: the original fault, the deployed correction and the later search observation. If performance moves, review other changes and the affected page group before assigning credit. A site-wide traffic rise is weak evidence for a single canonical fix.
If the original fault was not demonstrated, revisit the diagnosis. If the release differs from the ticket, repair the implementation. If both are sound and search data has not caught up, wait for an appropriate follow-up. These are different states, and each deserves a different response.
Do not lose the enquiry while fixing discovery
A commercial template change can affect forms, analytics and routing as well as indexing. Put one complete enquiry rehearsal in the release checklist: arrive through the revised page, submit a valid test record, check the destination and confirm the expected owner. Keep test records distinguishable from commercial demand. The technical ticket can then close on verified implementation, while search and sales outcomes remain separate follow-up measures. A page that is easier to discover but silently loses enquiries has not become a better B2B acquisition route.
Sources and further reading
Google: URL Inspection tool: Indexed-page evidence and live inspection.
Google Search Central: canonical URLs: Signals for duplicate and similar URLs.
References checked 9 October 2026. Sources support the documented facts and tool behaviour; the recommendations and worked examples explain how I would apply them.
Technical fix acceptance sheet
Use the blank sheet to organise your own evidence and decisions. The column headings follow the diagnostic method in this guide.
Download the working sheet ↓CSV format. Opens in Excel, Google Sheets and other spreadsheet tools. Name, email, company and location required before downloading.
Was a step unclear or missing? Tell Amine what you were trying to do ↗. Your email can include the step, what you expected and what prevented you from using it.
Which technical fault is blocking an important journey?
Bring the affected URLs, the symptoms and any crawl findings. We can turn the audit into a ranked set of fixes with checks for completion.