Technical SEO Audit Methodology

Order of Investigation

Work from the most fundamental outward. A problem at an earlier stage makes everything after it irrelevant.

1. Can it be crawled? robots.txt, server errors, redirect chains, crawl budget
2. Can it be indexed? noindex tags, canonicals, indexation coverage in Search Console
3. Is it duplicated? URL variants, parameter handling, thin pages
4. Does it render? JavaScript dependency, content visible to the crawler
5. Is it fast? Core Web Vitals, field data, mobile performance
6. Is it structured? schema, headings, internal links, hreflang

Tools and What Each Reveals

Google Search Console is the only source of what Google actually does with your site. The Pages report shows exactly why URLs are excluded from the index. Start here.

A crawler — Screaming Frog or equivalent — simulates a crawl and surfaces broken links, redirect chains, missing metadata, duplicate titles and orphan pages at scale.

PageSpeed Insights and CrUX give lab and field performance data. Field data reflects real users and is what Core Web Vitals assessment uses.

Log file analysis shows how Googlebot really crawls — which pages, how often, and where crawl budget is wasted. Underused and often the most revealing.

Prioritising What You Find

Score each issue on impact and effort. Rough tiers:

• Critical — anything blocking indexation of commercially important pages; fix immediately
• High — duplicate content splitting signals, broken internal links at scale, severe mobile performance problems
• Medium — missing structured data, suboptimal internal linking, minor speed gains
• Low — cosmetic issues with no demonstrable ranking or user impact

Deliver the critical and high items as a short actionable list. Put the rest in an appendix.

Audit Cadence

A full audit annually, or before and after any significant site change. A lighter monthly check on Search Console coverage, Core Web Vitals and broken links catches regressions early.

Migrations, replatforming and redesigns warrant an audit before launch, not after. Problems found on a staging site cost a fraction of the same problems found in production after traffic has dropped.

Writing the Audit So It Gets Implemented

Most technical audits fail after delivery, not during. A hundred-item document arrives, nobody can start, and it is still open a year later.

What changes that:

Order by impact against effort, not by category. A section headed Crawlability is organised for the auditor. A list headed Do these four things first is organised for the person implementing.

State the business consequence, not the violation. "No canonical on paginated URLs" is a finding. "Product pages beyond page one are not being indexed, so roughly a third of the catalogue cannot be found in search" is a reason to schedule work.

Name the owner and the system for each item. Developer, CMS, server configuration, DNS. An audit that does not say who can fix a thing goes to whoever commissioned it and stops.

Separate the one-offs from the standing rules. Some items are fixes; others are things the next template must not do again. Only the second kind prevents recurrence.

And cap the first round at ten items. Ten done beats a hundred documented.

Verifying That a Fix Actually Landed

The step almost always skipped: confirming that what was deployed matches what was asked for.

Re-crawl the affected URLs specifically, not the whole site, and check the exact attribute you asked to change. Fixes are frequently applied to a template that covers fewer pages than you assumed.

Check the rendered HTML, not the source, where the change is JavaScript-dependent. A tag present in the source and absent after rendering has not landed.

Watch index coverage over the following weeks rather than the day after. Crawling and reprocessing take time, and declaring a fix failed after 48 hours is the most common false negative in technical SEO.

Keep a log of what changed and when. When rankings move two months later, the only way to connect cause and effect is a dated record — and the alternative is an argument nobody can settle.

Re-audit cadence: a full pass annually, a focused pass after any migration, template change or platform upgrade, and a standing crawl monthly to catch drift. The monthly crawl is what finds the problem before it is a project.

Sources

What each claim on this page rests on. Entries are typed so you can see which are primary.