Technical SEO Audit Framework

A page cannot rank until it has been fetched, crawled, rendered, indexed, served fast enough to be useful, and then measured so you know whether any of that is still true next month. I call these the Six Gates, and the mnemonic is ACRISM: Access, Crawl, Render, Index, Serve, Measure. Every technical problem I have ever found on a site belongs behind one of those gates, and the order matters, because a failure at an earlier gate makes every later finding irrelevant. There is no point tuning Core Web Vitals on a template that Googlebot cannot reach.

1. Access
2. Crawl
3. Render
4. Index
5. Serve
6. Measure

When to use this

Use the Six Gates when you need a technical audit that produces a short, ordered list of work rather than a 90-page PDF. It fits three situations particularly well: a new engagement where you need to find the few things that are actually holding the site back; a migration or replatform, where you run the gates before and after; and a large site, in the tens of thousands of URLs or more, where template-level thinking beats page-level thinking.

It is less useful on a ten-page brochure site, where a pass through the technical SEO guide and a crawl is enough. The framework earns its keep when one wrong rule can affect thousands of pages at once, the problem I describe in technical SEO at scale.

The Six Gates

Each gate has four parts: the inputs you gather, the actions you take, the outputs you produce, and the checks that tell you the gate is clear. I run them in order and I do not move to the next gate until I have at least a working picture of the current one.

1. Gate 1: Access. Can a crawler reach the URL at all?

   Inputs: robots.txt, server logs, CDN and WAF configuration, DNS and TLS setup, a list of known URL patterns. Actions: fetch every template as Googlebot, test robots rules with the robots.txt tester, look for bot-blocking at the CDN or firewall, check that HTTP resolves to HTTPS in one hop. Outputs: a list of blocked or rate-limited patterns, with the rule that causes each. Checks: every important template returns 200 to a Googlebot user agent from more than one location, and nothing critical sits behind a disallow or a challenge page.

2. Gate 2: Crawl. Is crawl budget spent on pages that matter?

   Inputs: a full site crawl, server logs segmented by bot, XML sitemaps, the internal link graph. Actions: compare what the crawler finds with what Google actually requests, find parameters and facets that multiply URLs, measure click depth per template, find orphans. Outputs: a crawl waste report by URL pattern and a depth distribution per template. Checks: the pages you care about are in the sitemap, linked from somewhere, and appear in logs; the pages you do not care about are blocked, noindexed or consolidated. Mechanics are in the crawlability and indexability guide.

3. Gate 3: Render. Does the content exist after JavaScript runs, and before?

   Inputs: raw HTML and rendered DOM for each template, the URL Inspection tool, a JavaScript crawl. Actions: diff the raw HTML against the rendered page for title, canonical, main content, internal links, and structured data; find anything that only exists client-side. Outputs: a render-dependency table listing which elements need JavaScript on which templates. Checks: primary content and links are present in the initial HTML, or there is a tested server-side or pre-rendering path. Google renders JavaScript in a second wave, and anything that depends on that wave is slower and more fragile; see my JavaScript rendering experiment and the JavaScript SEO guide.

4. Gate 4: Index. Is the right version of each page in the index, and only that version?

   Inputs: Search Console page indexing report, canonical tags, hreflang, meta robots, duplicate clusters from the crawl. Actions: reconcile indexed URLs with the URLs you want indexed, find canonical conflicts (a canonical pointing at a redirect or a noindexed page, or one Google overrides), check pagination and sort variants. Outputs: an index gap list (wanted but missing) and an index bloat list (present but unwanted). Checks: the count of indexed pages is close to the count of valuable pages, and Google's selected canonical matches yours on sampled URLs. The canonical tags guide explains the common conflicts.

5. Gate 5: Serve. Is the page fast and stable enough for a mobile user in India on a mid-range phone?

   Inputs: field data from Chrome UX Report, lab data per template, a waterfall for each key template, image and font inventory. Actions: measure LCP, INP and CLS per template rather than per page, find the single largest cause of each, check caching headers and image formats. Outputs: a per-template vitals table with the root cause for each failing metric. Checks: field data passes on the templates that carry most traffic, and the fix list names a specific resource or script, not "optimise images". See the Core Web Vitals guide.

6. Gate 6: Measure. Will you know when any of the above breaks again?

   Inputs: Search Console, analytics, log access, a crawl schedule. Actions: set a recurring crawl with diffing, alerts on indexed page count, 5xx rate and robots.txt changes, a monthly template-level vitals check. Outputs: a monitoring sheet that names each check, its owner and its threshold. Checks: someone other than you would notice a problem within a week. Most audits skip this gate, which is why the same bugs reappear after every deployment.

Worked example (hypothetical)

Imagine a D2C furniture store in India with around 40,000 URLs: product pages, category pages, filter combinations, a blog and a support section. This is a made-up example, not a client.

At Access, every template returns 200, but the CDN's bot protection serves a challenge page to requests without a browser fingerprint from a few regions. That is one finding, and it is a serious one. At Crawl, logs show that most Googlebot requests are going to colour-and-size filter URLs that are canonicalised but still crawlable; product pages sit at click depth five or six because the category pagination is the only route to them. At Render, the product description and the "related products" links are injected by a client-side script, so the raw HTML has a price and an image and almost nothing else.

At Index, Search Console shows far more indexed URLs than there are products, because sort parameters are indexed with self-referencing canonicals. At Serve, the product template fails LCP on mobile because the hero image is a full-size PNG behind a carousel script. At Measure, there is nothing: the last crawl was done by an agency a year ago.

Six findings, six gates. Without a scoring model, engineering would start with the image, because it is visible and familiar. With the model below, they start with the CDN rule and the filter crawl, because those decide whether anything else gets seen.

Prioritisation: the impact-by-effort matrix

I score each finding on three things. Impact (1 to 5) is how much organic performance changes if it is fixed. Reach (1 to 5) is how many valuable URLs it touches, usually a function of template. Effort (1 to 5) is engineering cost including testing and release. Score is Impact times Reach, divided by Effort. The matrix sorts itself, and the conversation with engineering becomes about the inputs rather than my opinion.

The buckets are deliberately coarse: above about 7 is "do now", 3 to 7 is "plan into the next cycle", below 3 is "later, or never". The inputs are judgement calls, and that is fine; two people can disagree about one input and resolve it instead of arguing about the whole list. When scores tie, the earlier gate wins, because it is upstream.

Common failure modes

Run it yourself

• List every template on the site and assign a representative URL to each.
• Access: fetch each representative URL as Googlebot from two locations; test robots.txt against the key patterns.
• Crawl: run a full crawl; pull at least four weeks of bot logs; compare the two; record depth per template and orphan count.
• Render: diff raw HTML and rendered DOM for each template; note every element that only exists after JavaScript.
• Index: reconcile indexed count with valuable URL count; sample canonical decisions; list gaps and bloat.
• Serve: pull field data per template; identify the single largest contributor to each failing metric.
• Measure: set a recurring crawl, index-count alert, 5xx alert and robots.txt change alert; name an owner for each.
• Score every finding with Impact, Reach and Effort; sort; sanity-check the top five with the engineering lead.
• Ship the top bucket, then re-run the affected gates before touching the next bucket.

If you would rather I ran this on your site and worked through the fixes with your team, that is what my technical SEO service and SEO audit service are for. The technical SEO and content architecture case study shows the framework applied end to end.

FAQ