Technical SEO audit: a 20-item production checklist
A 20-item technical SEO audit you can run in half an hour on production: crawlability, indexing, multilingual setup, performance and AI crawler access.
By Roozbeh Nazari · CEO
Most technical SEO audits sit on a shelf because they are too long to run. A hundred-item list gets produced once, nobody runs it a second time, and six months later the status of every item is unknown. The twenty items below are designed for the opposite: a set an experienced person can run on production in roughly half an hour and repeat at the end of every sprint.
The list is an abbreviated audit, not a complete one. For a broader control set you can look at our technical SEO audit checklist; the twenty items here are the subset of that list which breaks most often in production. We run the comprehensive version as part of our technical SEO service.
Crawlability: 1-5
The first five items check whether the search engine can reach the site at all. If there is an error in this layer, none of the items below it matter.
- 1. Is robots.txt reachable in production and returning the expected content? A blanket disallow rule copied over from staging is the most common single-line catastrophe.
- 2. Are important templates not blocked by robots.txt? In particular, check whether the broad patterns written for search, filter and basket paths also cover content pages.
- 3. Are the server response codes correct? An existing page should return 200, a removed page 410 or 404, a moved page 301. Soft 404 setups that return 200 for a missing page are looked for separately.
- 4. Is the XML sitemap current and does it contain only indexable pages? A page that appears in the sitemap while carrying noindex is a contradictory signal.
- 5. Are there redirect chains in the internal link graph? Having links point directly at the final address preserves both crawl budget and user time.
Indexing and canonicalisation: 6-10
The second group checks whether the reached page enters the index and which version is treated as canonical.
- 6. Does the canonical tag point at itself, or at the homepage because of a template error? Every page canonicalising to a single address is the classic symptom of a template variable wired wrongly.
- 7. Are parameterised addresses indexed as separate pages? When sort and filter parameters are not canonicalised, the same content multiplies across dozens of addresses.
- 8. Do page titles stay unique when generated from a template? Large sets of pages carrying the same title leave the deduplication decision to the search engine.
- 9. Are the noindex tags intentional? Tags added before launch and not removed after it are the most common silent error in new sections.
- 10. Is the pagination setup consistent? Each listing page should have its own address, and those addresses should be reachable through internal links.
Multilingual setup: 11-14
The third group applies only to sites publishing more than one language, but it is the layer holding the most expensive errors on those sites.
- 11. Are the language declarations reciprocal? One page pointing at another without the other pointing back causes the declaration to be disregarded.
- 12. Does each page declare itself as well? A page missing its own self-reference is not evaluated as a member of the language group.
- 13. Are the language and region codes valid? Writing a country code where a language code belongs invalidates the whole group with a single character.
- 14. Is there automatic language redirection? Forced redirection based on browser language leads crawlers to see a single language version and leaves the others undiscovered.
Performance: 15-17
The fourth group checks page experience metrics against field data. Real user data, not lab measurement, is the basis.
- 15. Is Largest Contentful Paint below the target threshold in field data? The measurement is read across the 75th percentile of page loads, not from a single test.
- 16. Is Interaction to Next Paint within the acceptable range? This metric degrades particularly on form- and filter-heavy pages.
- 17. Is Cumulative Layout Shift below the threshold? Images without declared dimensions and late-loading components are the main causes of this metric.
Structured data and AI access: 18-20
The last group checks the page’s machine readability and the access policy for the newer generation of crawlers.
- 18. Is the structured data error-free and consistent with the content visible on the page? Markup declaring information that is not on the page is a mismatch that needs fixing.
- 19. Was the access policy for AI crawlers set deliberately? The relevant user agents should be addressed explicitly in robots.txt; leaving the default is also a decision, but it should be recorded.
- 20. Is server-rendered content readable without scripts running? Main content that only materialises client-side raises both crawling and indexing risk.
The output of the twenty items is not a report but a status table: each item is marked passed, failed or not applicable, and the failed items enter the sprint queue with their reasoning. Which items broke on the next run of the same list is the cheapest available indicator of the site’s technical debt trend.
How to run the list
The value of the twenty items comes not from a one-off audit but from repeatability. The arrangement that works in practice is to run the list in the same order after every release and mark the result as one of three states: passed, failed, not applicable. The "not applicable" option is what keeps the list alive; forcing an irrelevant item to be assessed turns the audit into a ritual that gets abandoned over time.
The running order is not arbitrary. Crawlability items come first because an error in that layer invalidates every measurement below it: there is no point arguing about canonical correctness on a blocked template. By the same logic, performance items come after indexing items; the load speed of a page that is not indexed is not the priority problem.
How the result table is stored matters too. Recording each run with its date and release number shows retrospectively which item broke in which release. An item failing on two consecutive runs is not an isolated error but a process problem, and the fix is not code but adding a checkpoint.
From audit to sprint queue
The place an audit most often fails is where the finding does not turn into work. Every failed item should carry three pieces of information into the queue: which template it affects, how the fix will be verified, and what happens if it is not fixed. Without the third, the item always loses the prioritisation argument.
Grouping items by template rather than one by one also speeds things up. Four separate findings affecting the same template, opened as four separate work items, require loading the context four times; gathered into one item they close in a single pass. The audit list is run item by item but transferred to the queue template by template.
The audit list stays the same regardless of the size of the site, but the running frequency changes. On a product shipping several releases a week the list cannot be run on every release; in that case the crawlability and indexing groups are wired to automated checks and the remaining groups are run by hand at the end of the sprint. The criterion for choosing what to automate is not the importance of the item but how often it breaks.