Answer in brief
The points worth carrying forward.
Download the SEO audit checklistA reusable CSV for technical, content, local and conversion checks.
- 01Audit the discovery-to-conversion chain, not an isolated list of tool warnings.
- 02Separate crawling, indexing, canonicalisation and ranking because each is a different system state.
- 03Validate templates and page groups at scale, then manually inspect representative URLs.
- 04Prioritise by affected demand, page value, scale, confidence, effort and dependency.
Section / 01
What a technical SEO audit should answer
The audit should explain which valuable pages search systems can reach and index, which version they interpret as canonical, what prevents understanding or usability, and which repairs deserve implementation first.
Begin with the business model, priority offers, target markets and page types. A blocked checkout, service template or location cluster can matter more than hundreds of harmless parameter URLs. The audit therefore needs commercial context before a crawler is configured.
Read the deeper explanation
Record the production host, protocol, preferred hostname, important subdomains, rendering method, content system, international variants and recent migrations. This baseline prevents a correct technical observation from becoming the wrong business recommendation.
- Priority pages and template groups
- Organic demand and conversion role
- Known migrations, redesigns and platform changes
- Analytics, Search Console, server-log and CMS access
- Teams that own code, content, design and release approval
Section / 02
Follow the crawl, render, index and canonical pipeline
Discovery normally begins through crawlable links, submitted sitemaps and URLs already known to the search engine. A URL can be discovered but blocked from crawling, crawled but not rendered usefully, rendered but excluded from indexing, or indexed under a different canonical. Treating all four states as a single indexability score hides the real cause.
Read the deeper explanation
Robots.txt manages crawler access; it is not a reliable instruction for keeping a URL out of search. For pages that should not appear, use an appropriate noindex instruction while allowing Google to crawl it, or protect private material with authentication. Google also describes canonical signals as hints rather than absolute rules, so internal links, redirects, sitemaps and canonical tags should agree.
| State | Audit question | Evidence to inspect |
|---|---|---|
| Discovery | Can a crawler find the preferred URL? | Internal links, orphan reports, XML sitemaps |
| Crawling | Is access allowed and efficient? | Robots rules, status codes, logs, crawl reports |
| Rendering | Does the rendered page expose the useful content and links? | Rendered HTML, resources, hydration and console failures |
| Indexing | Is the page eligible and selected for indexing? | Noindex, quality, duplicates, Search Console inspection |
| Canonicalisation | Which URL represents the content set? | Canonicals, redirects, links, sitemap and Google-selected canonical |
Section / 03
The 10-step technical SEO audit process
- 01
Define valuable page groups
Map services, products, locations, resources and conversion pages to templates and intended search demand.
- 02
Verify hosts and redirects
Test HTTP, HTTPS, www, non-www, trailing-slash and known legacy variants for one consistent destination.
- 03
Crawl like a search engine
Use a controlled crawl, inspect linked and orphan URLs, and compare the result with sitemaps, analytics and Search Console.
- 04
Classify status codes
Find broken internal links, redirect chains, soft errors, unstable responses and server failures by template and importance.
- 05
Test directives and canonicals
Compare robots access, robots meta, X-Robots-Tag, canonical tags, redirects and Google-selected canonicals.
- 06
Inspect rendering
Compare source and rendered output, important resources, navigation, lazy loading and client-side error states.
- 07
Review architecture
Measure click paths, breadcrumbs, contextual links, pagination and whether important pages receive descriptive internal links.
- 08
Evaluate page experience
Inspect responsive layout, interaction, Core Web Vitals evidence, accessibility fundamentals and intrusive friction.
- 09
Validate metadata and structured data
Check unique titles, descriptions, headings, visible entity facts and markup eligibility against page content.
- 10
Prioritise and regression-test
Turn findings into owned tickets with evidence, acceptance criteria, dependencies and pre/post-release validation.
Section / 04
Audit information architecture and internal links
A technically indexable page can still be weakly connected. Important pages should appear in useful navigation, category or hub structures and contextual links where the reader naturally needs the next answer. Descriptive anchor text helps people and search systems understand that relationship.
Read the deeper explanation
Look for orphan pages, competing URLs, infinite filters, broken pagination, inconsistent breadcrumbs and important content buried behind site search or JavaScript-only controls. The goal is not a universal three-click rule; it is a clear hierarchy that reflects customer decisions and concentrates internal authority around canonical pages.
Section / 05
Rendering, performance and page-experience checks
Performance is a user and conversion concern as well as a technical search concern. Diagnose the responsible template, component, asset or third-party script before prescribing generic compression or dependency removal.
- Confirm primary copy, links, images, forms and structured data are available in the rendered experience.
- Test representative templates on small mobile, tablet and desktop viewports rather than one homepage score.
- Use field data where available; lab tests help reproduce problems but do not describe every visitor.
- Reserve media dimensions, optimise delivery, reduce unnecessary scripts and test real interaction states.
- Check keyboard access, visible focus, labels, contrast, zoom, reduced motion and error recovery.
Section / 06
Prioritise fixes by business and search impact
| Factor | Question | Higher-priority signal |
|---|---|---|
| Value | Does the issue affect an important journey? | Revenue, lead, product or high-demand pages |
| Scale | How many useful URLs or templates are affected? | Systemic template or navigation failure |
| Severity | What state does it prevent? | Discovery, access, indexing or conversion blocked |
| Confidence | How strong is the evidence? | Reproduced issue with corroborating data |
| Effort | What must change and who owns it? | High-impact fix with limited dependencies |
| Risk | Could implementation create regressions? | Migration, canonical, redirect or rendering change |
Section / 07
Verify the release instead of closing the ticket
- 01
Test before release
Validate the fix in an environment that reflects production behaviour and includes representative templates.
- 02
Re-crawl the changed scope
Confirm status codes, directives, canonicals, rendering and internal links now match the acceptance criteria.
- 03
Inspect production URLs
Check actual responses, rendered content, analytics events, forms and search-engine inspection evidence.
- 04
Monitor the expected signal
Track coverage, crawling, impressions, qualified visits and conversions on a timeframe appropriate to the change.
Sources and maintenance
Primary references behind this guide.
Written by Rohan Neure. Published September 1, 2026 and last reviewed September 1, 2026. Product interfaces and policies can change; the linked first-party sources are the current reference points.
- 01Crawling and indexing overview ↗Primary source
Google Search Central · Discovery, crawling, rendering and indexing distinctions
- 02Canonicalization ↗Primary source
Google Search Central · Canonical signals and duplicate URL handling
- 03Build and submit a sitemap ↗Primary source
Google Search Central · Absolute canonical sitemap URL guidance
- 04SEO Starter Guide ↗Primary source
Google Search Central · Site organisation, links and search fundamentals
Related decisions
Continue with the closest useful path.
Questions answered
Frequently asked questions.
01What is a technical SEO audit?
It is a structured evaluation of how a website supports discovery, crawling, rendering, indexing, canonicalisation, understanding, page experience and conversion across its valuable page groups.
02How often should a technical SEO audit be completed?
Use continuous monitoring for critical failures and a deeper audit before and after migrations, redesigns, major template changes or when evidence shows organic performance and index coverage have changed.
03Which technical SEO audit tool is best?
No single tool represents the complete system. Combine a crawler with Search Console, analytics, URL inspection, browser rendering, performance evidence, server logs where available and manual journey testing.
04Does robots.txt remove a page from Google?
No. Robots.txt controls crawling, not guaranteed indexing. Google recommends noindex for eligible public URLs that should not appear, or authentication for private content.
05How long does a technical SEO audit take?
It depends on site size, rendering, templates, markets, historical migrations, access and the depth of manual validation. Scope by page systems and business risk rather than promising a universal duration.
Use the guide
Need priorities your team can actually implement?
Share the domain, priority offers and recent site changes. We will identify the technical, content and conversion constraints that deserve inspection first.
Use the secure enquiry form, WhatsApp, email or phone. Choose the route that is easiest for you.