A technical SEO audit should identify problems that prevent useful pages from being discovered, indexed, consolidated and served reliably. It should not be a tool export presented without business context.
The useful output is a decision register. Each finding needs an affected URL set, evidence, business impact, recommended fix, owner, test and priority. That lets developers, marketers and business owners work from the same version of the problem.
Matt's 15 years of SEO review experience has reinforced one practical rule: confirm the symptom before prescribing a site-wide change. A small robots, canonical, redirect or template decision can affect thousands of URLs, so representative testing and rollback planning matter.
Scope the audit and protect the live website
Start by defining the canonical host, important templates, priority services, target markets and systems that create public URLs. Record staging environments, alternate domains, subdomains, content platforms, ecommerce filters and third-party tools that can change rendering or navigation.
Use read-only access first. Before changing redirects, canonicals, robots rules or templates, confirm who can approve and deploy the fix, how it will be tested and how it can be reversed. A technically correct recommendation can still damage the business if it removes a needed page or breaks a buying path.
- Confirm the preferred protocol, hostname and public production environment.
- List the website platform, rendering model, CDN, analytics and consent systems.
- Identify priority page types and representative URLs for each template.
- Record recent and planned migrations, redesigns, domain changes and platform releases.
- Obtain read-only Search Console and analytics access where available.
- Separate production, staging, preview and development hosts.
- Agree who approves changes, who deploys them and how rollback works.
- Take a dated baseline crawl and preserve the audit configuration.
Check crawl access and index eligibility
Google's minimum technical requirements state that Googlebot must not be blocked, the page must return a successful HTTP response and the page must contain indexable content. Meeting those requirements makes a page eligible, but does not guarantee indexing or ranking.
Compare what the business wants indexed with what search engines can actually access. Use Search Console reports and URL Inspection alongside a crawl, server responses and rendered page checks. A robots.txt rule can prevent crawling, while a noindex directive needs the crawler to access the page to see it.
Robots access
Review robots.txt rules for important paths, blocked resources, obsolete directives and differences between user agents.
Robots metadata
Check meta robots and HTTP headers for noindex, nofollow, nosnippet and other directives on representative templates.
Authentication and gates
Confirm that public pages do not require a login, cookie state or browser action before their main content becomes accessible.
Indexable content
Verify that the main text, headings, links and media context are present in the rendered HTML Google can process.
Index reports
Investigate examples from indexed, excluded, crawled but not indexed, discovered but not indexed and error groups rather than treating every excluded URL as a fault.
Validate status codes, errors and redirects
Every important page should return the response intended for its current state. A live page normally needs a successful response. A permanently moved page needs a relevant permanent redirect. A removed page with no replacement should return a genuine not found or gone response rather than a visually empty page that still reports success.
Follow redirect chains from internal links, sitemaps and high-value external backlinks. Redirect users to the closest relevant replacement, not automatically to the homepage. During a migration, maintain a complete old-to-new URL map and test it before launch.
- Priority live URLs return successful responses without intermittent server errors.
- Permanent moves use a server-side permanent redirect to a relevant destination.
- Internal links and sitemap entries point directly to final URLs rather than through redirects.
- Redirect chains, loops and protocol or hostname inconsistencies are removed.
- Removed URLs return a real error response unless a close replacement exists.
- Custom error pages help users recover but preserve the correct error status.
- Migration redirects, canonicals and internal links agree on the preferred new URL.
- High-value inbound links are identified so their destination can be preserved or updated.
Consolidate duplicate and parameterised URLs deliberately
Duplicate URLs can be created by tracking parameters, print versions, uppercase paths, trailing slash rules, faceted navigation, product variants and several routes to the same content. Decide which version should be shown in search, then align redirects, canonical annotations, internal links and sitemap entries where appropriate.
A canonical annotation is a signal, not a command to merge unrelated pages. Check whether the declared canonical is indexable, returns a successful response and contains substantially equivalent content. Investigate cases where Google selects a different canonical because they often expose conflicting site signals.
Protocol and host
Choose one secure canonical host and redirect other public variants consistently.
Path rules
Apply consistent casing, trailing slash and index filename behaviour.
Parameters and filters
Document which combinations provide unique customer value and which only sort, track or duplicate existing content.
Cross-domain copies
Review syndicated or duplicated content across owned domains and choose the version the business intends to maintain.
Pagination and variants
Make every useful page accessible while avoiding one canonical rule that hides genuinely distinct products or content.
Audit site architecture, internal links and sitemaps
A logical site structure helps people and search engines understand how pages relate. Important commercial pages should be reachable through crawlable links, supported by relevant guides and described with anchor text that makes the destination clear.
An XML sitemap should contain the canonical URLs the business wants indexed. It can help discovery, but Google states that a sitemap does not guarantee indexing or improve ranking by itself. Treat sitemap errors as symptoms and keep the source page, canonical and internal links aligned.
- Every priority page is reachable through a standard crawlable link.
- Navigation reflects customer tasks and the intended page hierarchy.
- Internal anchor text describes the destination without repetitive keyword stuffing.
- Orphan pages are either linked into the useful structure, consolidated or removed.
- Broken internal links and links to redirected URLs are corrected at the source.
- Breadcrumbs match the visible hierarchy and use valid structured data where implemented.
- The XML sitemap contains only preferred indexable URLs with accurate modification dates when available.
- Sitemap URLs return success, declare themselves canonical and are not blocked or marked noindex.
- Large sites split sitemaps into useful groups that make indexation problems easier to isolate.
Test rendering and indexable page content
Modern search engines can render JavaScript, but rendering still adds systems and failure points. Compare the initial response, rendered page and what URL Inspection shows. The main content and links should not depend on an interaction, unsupported browser state or failed client request.
Check template-level headings, titles, descriptions, canonicals, language, images and structured data. Make sure fallback states and error boundaries do not turn valid pages into thin or duplicated output when an API fails.
- The initial and rendered page expose the same primary purpose.
- Main headings, copy and crawlable links appear without requiring a click or scroll event.
- Server and client rendering do not produce conflicting titles, canonicals or robots directives.
- Lazy-loaded images and content retain meaningful alternative text and layout space.
- Structured data matches visible page content and the correct entity.
- Soft error states do not return a success response with no useful content.
- Pagination, filters and search results work with stable crawlable URLs where indexation is intended.
- International versions use accurate language and regional relationships if they exist.
Review real user performance and page experience
Use field data where available because it reflects real users, devices and networks. Core Web Vitals cover loading, interactivity and visual stability, but a technical review should also consider reliability, accessibility, mobile usability and whether heavy scripts interfere with the buying task.
Prioritise template and component fixes that improve many valuable pages. A faster score is useful when it represents a better experience, not when measurement scripts or important content have simply been removed without considering the business requirement.
Loading
Review the main visible content, image delivery, fonts, caching, server response and code required before the page becomes useful.
Interactivity
Identify long main-thread work, heavy third-party scripts and event handlers that delay a response to user input.
Visual stability
Reserve space for images, embeds, banners and dynamic components so content does not move unexpectedly.
Business safeguards
Test forms, calls, navigation, consent controls, checkout and analytics after every performance change.
Turn findings into a verified implementation queue
Prioritise by affected value, severity, scale, confidence and implementation risk. A blocked revenue page usually matters more than hundreds of harmless parameter URLs. A site-wide template fix deserves stronger testing than an isolated metadata update.
For each item, include evidence and a definition of done. Test a representative sample before deployment, crawl or inspect the result after deployment and monitor Search Console and business systems for unintended effects.
- Finding names the exact symptom and affected URL pattern.
- Evidence includes response, directive, rendered output or report example.
- Impact explains the customer and search consequence without guaranteeing a ranking gain.
- Recommendation states the desired behaviour rather than prescribing untested code.
- Owner and dependency identify who can complete and approve the work.
- Test covers representative templates, devices and edge cases.
- Rollback path is documented for high-impact changes.
- Deployment date and changed files or settings are recorded.
- Post-release verification checks crawlability, rendering, analytics and conversion paths.
- Resolved findings remain in a decision log for future migrations and audits.
Sources and further reading
Primary and authoritative sources used to support the factual guidance in this resource.
- Source 01Google Search technical requirements, opens in a new tabGoogle's minimum crawl, response and indexable content requirements.
- Source 02How Google Search works, opens in a new tabOfficial explanation of crawling, rendering, indexing and serving search results.
- Source 03Google canonical URL guidance, opens in a new tabOfficial guidance on redirects, canonical annotations and sitemap canonical signals.
- Source 04Google sitemap guidance, opens in a new tabOfficial requirements and recommendations for building and submitting sitemaps.
- Source 05Google site move guidance, opens in a new tabOfficial migration guidance for redirects, canonicals, links, sitemaps and monitoring.
- Source 06Web Vitals, opens in a new tabOfficial web.dev guidance on measuring loading, interactivity and visual stability with field data.