An audit becomes useful when another person can reproduce its findings and verify the fixes. Start with the pages the business needs customers to find, then investigate how those pages are delivered.
To run a technical SEO audit, define the intended indexable pages, collect a representative crawl, compare it with search and site data, verify important findings manually, group shared causes, and create implementation tickets with acceptance tests. Recheck the deployed changes before evaluating search outcomes.
1. Define the decision and scope
Write down the domain, markets, platform, priority page types, and business journeys. State whether the review covers a migration, traffic decline, inherited website, or routine baseline. Each situation changes what evidence deserves attention.
List intended public landing pages separately from account screens, search results, tracking variants, and other utility routes. Without this distinction, your report can become a campaign to index pages nobody wants customers to land on.
Name the people responsible for SEO decisions, development, content, infrastructure, and commercial approval. Record access limitations immediately. Missing logs should be reported as a limitation, not replaced by an invented account of crawler behavior.
2. Capture a baseline
Save relevant Search Console and analytics exports with date ranges and filters. Record recent releases, migrations, tracking changes, campaigns, and seasonal events. Select comparable periods and segment by country, device, landing-page type, and brand demand where possible.
A fall in recorded sessions can be a measurement problem. A decline affecting one template after deployment suggests a different investigation from a broad decline in branded searches. Treat those patterns as clues and keep competing explanations open.
3. Configure a representative crawl
Document the crawler’s starting URLs, user agent, rendering mode, limits, exclusions, and date. Begin with enough coverage to understand templates before expanding expensive rendering or parameter crawling.
Compare a link-discovery crawl with known URLs from sitemaps and platform inventories. The difference can reveal isolated pages or obsolete URLs. Do not silently combine the datasets and lose the information about where each URL came from.
For JavaScript sites, compare representative initial HTML and rendered output. Google’s JavaScript SEO documentation describes its processing behavior. A successful browser screenshot alone does not establish that essential links and text are available to every crawler.
4. Check access and HTTP behavior
Test the homepage, a service or category, a detail page, pagination, and a deliberately missing URL. Expand the sample for distinct templates and languages.
Record final responses and redirect hops. Investigate recurring server errors and access blocks. Check that missing content returns an appropriate missing-resource response rather than a successful empty template. Google’s HTTP status guidance explains the distinction between a successful response and content that is actually eligible for indexing.
Do not replace every missing page with a homepage redirect. Determine whether a relevant successor exists. Keep a separate list of historical redirects so current navigation can point directly to the preferred destination.
5. Review indexing directives and canonicals
For intended landing pages, inspect robots directives in both HTML and response headers. Check access rules and whether Google can fetch the page to see its directives. A robots.txt block and a noindex instruction serve different purposes.
Compare canonical annotations, internal links, redirects, and sitemap entries. Investigate conflicts before applying a global template change. Google’s canonicalization documentation describes signals used to communicate preferred URLs; it does not promise selection of your nominated version.
Keep a page-purpose matrix. For each template, state whether it should be discoverable, crawlable, indexable, and included in the sitemap. This makes exceptions explicit and protects private or low-value routes from indiscriminate “fixes.”
6. Compare site evidence with Search Console
Use the Page indexing report to identify patterns and URL Inspection to investigate individual pages. Record the difference between a current live test and Google’s stored information from an earlier crawl.
A live test showing corrected HTML establishes current delivery. It does not prove that Google has processed the change, selected the page, or begun showing it for the intended searches. Keep these outcomes in separate columns.
Where available and proportionate, review relevant server logs and Crawl Stats. Verify crawler identity before interpreting user-agent strings as proof of Googlebot activity. Restrict the analysis to the infrastructure and retention period actually covered.
7. Examine architecture and template experience
Trace routes from navigation and useful hubs to priority pages. Check whether links use real destinations and understandable anchor text. Identify important pages that are absent from these paths.
Inspect mobile content parity, layout stability, and difficult interactions. Use field performance data to locate affected page groups and laboratory tests to investigate causes. Avoid treating one test score as an inventory of every user’s experience.
Review relevant structured data against visible content and current feature requirements. Verify that maintenance follows the underlying product, article, or business data. A manually corrected snippet that becomes stale next week is not a durable fix.
8. Group causes and prioritize work
A canonical defect repeated across thousands of URLs may be one engineering task. Several unrelated warnings on a rarely visited utility page may deserve little attention. Group findings by cause, affected template, and implementation owner.
Use a short priority statement: what customer journey is affected, what evidence supports the diagnosis, what would improve, what could regress, and how much effort is expected? Label confidence and dependencies. Do not disguise a subjective score as a forecast of traffic gain.
9. Write implementation-ready tickets
Use this ticket structure:
| Field | What to record |
|---|---|
| Observation | Reproducible behavior and test date |
| Scope | Example URLs and affected templates |
| Intended behavior | Specific page or system outcome |
| Proposed change | Bounded implementation recommendation |
| Dependencies | Teams, access, and related releases |
| Acceptance | Checks that establish correct delivery |
| Monitoring | Search and customer signals to follow |
| Rollback | Trigger and accountable owner |
Constructed example: a new category is missing from its parent hub. The ticket asks for a visible descriptive link in the category template, excludes discontinued categories, and tests desktop and mobile navigation. Acceptance is the delivered link and correct destination; subsequent indexing is monitored separately.
10. Validate after deployment
Retest representative affected and unaffected pages. Check HTTP responses, initial HTML, rendered output, internal navigation, and relevant conversions. Record the release identifier and evidence. Close the implementation ticket only when acceptance checks pass.
Monitor search processing over a suitable observation window. If the expected change does not follow, revisit the hypothesis rather than automatically repeating the same intervention. Maintain a smaller regression checklist for future releases.
Reusable audit checklist
Confirm scope; capture baseline; inventory templates; record crawl settings; test responses; inspect directives; align canonicals; review sitemap purpose; trace internal links; compare rendering; inspect relevant structured data; investigate field performance; group causes; assign owners; specify acceptance; retest deployment; monitor outcomes.
For the buying decision, read what a technical audit includes. For backlog decisions, use how to prioritize fixes. If your team needs specialist investigation, request a scoped audit.
Common questions
Can I audit a site myself?
Yes, particularly a small, stable site. Escalate infrastructure, rendering, migration, or template-wide changes when you cannot reproduce the issue or safely validate the implementation.
Which tool is best?
Choose tools according to the question. A crawler, Search Console, browser inspection, analytics, and logs provide complementary evidence; no single score replaces diagnosis.
Should every warning be fixed?
No. Verify whether it is a real problem for the page’s intended purpose, then prioritize by consequence and confidence.
Research checked October 25, 2026. Examples and planning frameworks are illustrative unless stated otherwise. Featured imagery is AI-generated editorial photography, not documentary evidence of clients or projects.
