Technical SEO audit checklist
A useful audit connects every finding to affected URLs, the responsible template, commercial risk and a test that can prove the fix.
Written and reviewed by Jon Goodey. Updated 20 August 2026.
The short answer
A technical SEO audit checks whether important pages can be discovered, rendered, indexed, understood and maintained without creating duplication or migration risk. Prioritise findings by affected demand and template reach, then validate the live result.
Turn crawl findings into verified repairs
Before crawling: protect the baseline
- Export priority landing pages and queries from Google Search Console.
- Record organic enquiries, revenue or other useful outcomes by landing page.
- Identify URLs with external links, historical traffic or campaign use.
- Record the current sitemap, robots rules, canonical pattern and redirect behaviour.
- List recent releases, migrations and known platform constraints.
This baseline prevents a tidy-looking architecture from deleting an established route that still carries demand or authority.
1. Crawlability and discovery
- Robots.txt returns successfully and references an existing sitemap.
- Priority pages are linked through crawlable HTML links.
- Important URLs are not blocked by robots rules, authentication or accidental nofollow.
- Pagination, filters and parameters do not create uncontrolled crawl spaces.
- Orphan URLs are compared with sitemap, Search Console and analytics sources.
2. Rendering and JavaScript
- The rendered page contains the main text, heading, links and canonical.
- Navigation and internal links do not depend on interactions a crawler may not perform.
- Server and client rendering do not produce materially different content.
- JavaScript errors, hydration failures and consent tools do not hide the journey.
- Images and media have stable dimensions, descriptive alternatives and appropriate loading behaviour.
3. Indexation and canonicalisation
- Indexable pages return the intended successful status.
- Redirects, errors, staging routes and success pages are excluded from the sitemap.
- Each indexable page has one self-referencing canonical unless a deliberate alternative is documented.
- Canonical targets are indexable, equivalent and not redirected.
- Duplicate location, parameter, print and protocol variants are controlled consistently.
- Search Console exclusions are sampled and matched to the intended rule.
4. Architecture and internal links
- Priority services and topics are reachable without excessive depth.
- Anchor text describes the destination and avoids repetitive keyword stuffing.
- Informational guides link to the relevant service and services link back to useful guides.
- Similar pages have distinct intent rather than competing for the same query.
- Redirected or broken internal links are corrected at source.
- Breadcrumbs reflect the visible hierarchy and use valid structured data.
5. Metadata, headings and content signals
- Each indexable page has one useful title, description and H1.
- The title reflects the page intent without removing established relevant terms.
- Headings make the answer structure understandable out of context.
- Dates, authors, organisations and service relationships are accurate and visible.
- Claims have a source, permission and clear comparison period.
- Thin location or variant pages are reviewed against actual search and business value.
6. Structured data and entities
- JSON-LD parses without errors and matches visible content.
- The organisation and founder use stable identifiers across pages.
- Service, article, breadcrumb and FAQ data are only used where appropriate.
- Addresses, social profiles and business details match the verified source.
- Schema does not include invented ratings, reviews, prices or results.
7. Performance and experience
- Use field Core Web Vitals where enough data exists, supported by laboratory diagnosis.
- Identify the element or script causing LCP, INP or layout shift rather than reporting the score alone.
- Test mobile navigation, forms, keyboard use, focus, contrast and reduced motion.
- Remove or defer third-party code that has no proportionate user value.
- Confirm that optimisation does not remove essential content or tracking consent.
8. Migration and release controls
- Map every material old URL to an equivalent destination or an intentional gone response.
- Test redirects without chains, loops or broad redirection to the homepage.
- Compare staging and production metadata, canonicals, robots and structured data.
- Preserve analytics and Search Console access before launch.
- Crawl immediately after release and monitor priority URLs until reprocessing stabilises.
How to prioritise the findings
| Priority | Condition | Example |
|---|---|---|
| Critical | Prevents valuable pages being accessed or indexed | Site-wide noindex or broken rendering |
| High | Affects a priority template or creates migration loss | Wrong canonicals across service pages |
| Medium | Reduces clarity, efficiency or experience | Weak internal links to a growing topic hub |
| Low | Small isolated improvement with limited reach | One redundant redirect on a low-value URL |
Every item should name the evidence, affected URLs, owner, recommended change and acceptance test. For implementation support, see technical SEO and AI search visibility services. Teams that want to build this capability internally can use SEO training.
Questions people ask
What is included in a technical SEO audit?
A technical SEO audit should cover crawlability, indexation, rendering, canonicals, redirects, duplication, architecture, internal links, sitemaps, structured data, performance and template-level causes.
Which technical SEO issues should be fixed first?
Prioritise issues that prevent valuable pages being discovered, rendered or indexed, followed by changes affecting important templates and migrations. Scores without affected URLs and commercial context are not enough.
Can a crawler complete the whole audit?
No. A crawler is important, but it cannot replace rendered-browser checks, Search Console evidence, analytics, server information, source code inspection or understanding the business purpose of a page.
How often should a technical SEO audit be run?
Run a focused review before and after material releases or migrations, and schedule broader checks according to the rate of site change. Continuous monitoring is useful for large or frequently changing sites.
Does technical SEO affect AI Overviews?
Technical access and clear structure help systems retrieve and understand a page, but AI visibility also depends on direct answers, identifiable expertise, source quality and corroboration.
A practical first conversation
Bring the work that is causing the problem.
Tell us what the team is trying to improve, what it has already tested and where confidence breaks down. We will suggest a proportionate next step.
Talk it through with Jon