Technical SEO Audit

Overview

A useful technical SEO audit proves where discovery, crawling, rendering, indexing, canonicalization, or page experience breaks. It does not produce a hundred-tool checklist with no evidence or promise rankings from passing a score.

When to Use

• Important pages are not indexed or organic traffic dropped unexpectedly.
• A site migration, domain change, redesign, CMS change, or URL rewrite is planned.
• Search Console reports indexing, structured-data, sitemap, or Core Web Vitals issues.
• Programmatic pages need crawl-budget and duplicate-control review.
• The user asks for a technical SEO audit, crawl audit, indexation audit, or SEO migration QA.

Authoritative Foundations

• Google Search Essentials: evaluate technical eligibility, spam-policy risks, crawlable links, and people-first page signals without claiming that compliance guarantees indexing or ranking.
• Google Search Central — Crawling and Indexing: separate crawl controls from index controls; robots.txt manages crawling, while noindex or access control manages index exclusion.
• Google Search Central — Canonicalization and Sitemaps: treat redirects and rel=canonical as stronger canonical signals than sitemap inclusion, and include only preferred canonical URLs in sitemaps.
• Google Search Central — Structured Data Guidelines: validate only markup that represents visible page content and report rich-result eligibility rather than promising presentation.
• web.dev — Core Web Vitals: evaluate field data at the 75th percentile against LCP ≤2.5s, INP ≤200ms, and CLS ≤0.1, segmented by mobile and desktop where data exists.

Prerequisites

• Site or representative URL set, target market, and business-critical page types.
• Search Console access when available; otherwise state that index evidence is limited.
• Crawl permission and a bounded request rate suitable for the site.
• Deployment, framework, CMS, CDN, and migration context.
• A clear distinction between production, staging, authenticated, and blocked surfaces.

Step-by-Step Process

1. Define the audit universe

Build a sample by page type and business value. Record hostname variants, protocols, locales, parameters, staging hosts, and known legacy paths. Do not infer sitewide health from the homepage.

2. Test access and response behavior

Check DNS/TLS, redirect chains, final status, HTML response, robots directives, X-Robots-Tag, and authentication. Flag soft 404s, redirect loops, mixed canonical targets, and indexable staging pages.

3. Trace discovery and crawling

Review robots.txt, XML sitemaps, internal links, orphan candidates, pagination, faceted URLs, and rendered link elements. Distinguish blocked crawling from excluded indexing.

4. Reconcile indexing and canonical signals

Compare declared canonical, sitemap URL, internal-link target, redirect target, hreflang cluster, and Search Console-selected canonical. Group conflicts by template so fixes address root causes.

5. Inspect rendered content and metadata

Compare raw HTML with rendered output for title, description, canonical, headings, primary content, links, and structured data. Note client-side delays or errors that hide decisive content.

6. Validate structured data

Check syntax, required properties, visible-content agreement, URL consistency, and feature-specific eligibility. Use the Rich Results Test or equivalent evidence when available.

7. Evaluate performance with field-first evidence

Prefer CrUX or Search Console field data; use lab tests for diagnosis. Report LCP, INP, and CLS by template and device. Do not average away a failing 75th percentile.

8. Prioritize fixes

Score each issue by affected valuable URLs, severity, confidence, effort, and dependency. Separate blocking indexation defects from enhancements and monitoring work.

9. Create verification cases

For every priority fix, define a pre-change failing URL, expected observable result, test method, owner, and post-deploy monitoring window.

Output Format

Deliver:

1. Executive status and evidence limits.
2. Crawl/index funnel with counts by page type.
3. Issue register with example URLs and reproduced evidence.
4. Canonical/sitemap/internal-link conflict matrix.
5. Rendered metadata and structured-data findings.
6. Core Web Vitals table using field and lab evidence separately.
7. Prioritized remediation backlog.
8. Release verification and monitoring plan.

Quality Check

• Every issue includes at least one reproducible URL or source report.
• Crawl, indexing, ranking, and rich-result eligibility are not conflated.
• robots.txt is not recommended as a guaranteed deindexing mechanism.
• Canonical recommendations align redirects, internal links, and sitemaps.
• Field and lab performance data are labeled separately.
• Core Web Vitals thresholds use LCP 2.5s, INP 200ms, and CLS 0.1 at p75.
• Fixes are prioritized by business impact and affected templates, not tool severity alone.
• No ranking or rich-result outcome is guaranteed.

Common Pitfalls

Pitfall	Why it fails	Fix
Treating a crawler score as the audit	Scores hide evidence and business impact	Show affected URLs, templates, and search-state evidence
Blocking a URL in robots.txt to remove it	A blocked URL can remain indexed without a snippet	Allow crawling long enough to process noindex, or require authentication
Fixing canonicals only in HTML	Conflicting sitemaps and links keep sending mixed signals	Align redirects, canonicals, sitemaps, and internal links
Using only Lighthouse lab data	Lab runs do not represent the user distribution	Lead with field data and use lab traces for diagnosis
Adding schema unrelated to visible content	Violates eligibility guidelines	Mark up accurate, visible, feature-supported content only

Execution Artifacts

• references/framework-notes.md — Current technical thresholds and source routing
• templates/output-template.md — Evidence-first technical SEO audit
• scripts/check-output.py — Audit completeness validator

Related Skills

• seo-strategy for keyword, content, and authority planning.
• pseo-strategy for template-scale indexation and duplicate control.
• pillar-pages for internal-link and topic-cluster architecture.
• tracking-plan for analytics measurement that remains separate from indexation evidence.