A technical audit should explain which problems affect the site’s intended pages, how they can be reproduced, and what should be true after a fix. A long export of warnings leaves most of that work unfinished.
Start with the website’s purpose and page types. The investigation for an e-commerce catalogue is different from a small editorial site, even when both use the same crawler.
Define the intended indexed website
List the important page groups, their routes, language or regional versions, and owners. Identify pages that should be discoverable and indexable, alongside deliberate exclusions.
Include business-critical journeys: category to product, location to classified listing, or service page to enquiry. Record recent migrations, application changes, and known outages that may explain a change in the data.
For large sites, use the template and URL-pattern method to organise the work. It gives the audit a manageable set of shared rules and realistic exceptions.
Check host and indexing evidence
Review Crawl Stats for availability and response patterns. Review Page indexing against the intended policy. Separate correct exclusions from unexpected ones.
Choose representative examples and record the reported dates. Search Console describes recorded activity; the public site may already have changed. Use URL Inspection when an individual page needs a closer comparison.
Configure a crawl that answers the question
Choose Spider or List mode according to the input set. Record scope, user agent, rendering, robots handling, and rate. Check the first responses before scaling up.
Use the first-crawl workflow for standard fields. Review responses, metadata, canonicals, links, and content types by page group. Add custom extraction only for fields the investigation actually needs.
Compare a sitemap-based set with linked discovery when important pages seem absent. An incomplete or restricted crawl should be labelled accordingly in the findings.
Reproduce important findings in the browser
For an unexpected redirect or error, inspect the actual request sequence. For a missing link, inspect the generated anchor. For absent content, compare the returned HTML, live DOM, and relevant resource requests.
Use Network, JavaScript diagnosis, and the specific implementation guides instead of treating a crawler flag as the final explanation. Check mobile output and language relationships where those features exist.
Group and prioritise implementable work
Combine examples that share a demonstrated cause. State the affected template, evidence of scope, user or discovery effect, and confidence in the diagnosis.
Prioritise inaccessible important pages, widespread indexing conflicts, and broken discovery paths according to the site’s needs. Keep minor clean-up separate from problems blocking a core journey. Avoid claiming exact traffic gains from a technical fix without evidence.
Use the developer ticket method to record reproduction steps and acceptance tests. A useful ticket also says which neighbouring cases must keep working.
Recheck the public output
After deployment, request the source pages and destinations again. Confirm the actual HTML, headers, and content. Repeat the relevant crawl sample under comparable settings and retain the before-and-after evidence.
Monitor the appropriate Search Console state after recrawling. A code deployment, a successful live test, and an indexed page are separate milestones. Report each accurately.
My technical SEO audit service covers the investigation and prioritised requirements. For ongoing implementation support, technical SEO consulting includes working through fixes with developers and checking the resulting public pages.