Design Technical Seo Audit

---
name: design-technical-seo-audit
description: Use when auditing a website's technical SEO health to identify crawlability, indexation, Core Web Vitals, and structured data problems that suppress organic search rankings.
source: Google Search Central documentation (2024); Moz "The Beginner's Guide to SEO" (2023); Ahrefs "Technical SEO Guide" (2024); John Mueller Google technical SEO guidance; Google Core Web Vitals documentation
tags: [seo, technical-seo, audit, crawlability, core-web-vitals]
verified: true
---

# Design a Technical SEO Audit

Systematically inspect a website's technical foundation — crawlability, indexation, page speed, structured data, and canonicalization — to identify and prioritize issues suppressing organic search performance.

## Why This Is Best Practice

**Adopted by:** Every major SEO agency (Moz, Ahrefs, Semrush, Search Engine Land), Google's own Search Advocate team, and in-house SEO teams at enterprises like HubSpot, Shopify, and The New York Times.
**Impact:** Ahrefs (2024) finds that 90.63% of pages get zero organic traffic, and technical issues are the primary cause for pages that have content but no rankings; Google's Core Web Vitals rollout (2021–2023) demonstrated that pages meeting CWV thresholds see ranking improvements of up to 10% in competitive SERPs; Moz research shows that fixing crawl budget issues on large sites produces organic traffic increases of 15–40% within 90 days.
**Why best:** Technical SEO is the foundation that content and link-building strategies depend on. A page with excellent content and strong backlinks that cannot be crawled or indexed earns zero organic traffic. Auditing technical issues before investing in content or links is the highest-leverage sequence for organic growth.

Sources: Google Search Central — "Search Console Help," "Core Web Vitals" (2024); Moz — "The Beginner's Guide to SEO" (2023); Ahrefs — "Technical SEO: The Definitive Guide" (2024); Mueller, John — Google Search Advocate guidance (ongoing, via Google Search Central blog and YouTube).

## Steps

1. **Start with Google Search Console** — GSC provides ground-truth data from Google's own crawler. Review: Coverage report (indexed vs. excluded vs. errored URLs), Core Web Vitals report (LCP, FID/INP, CLS scores), Mobile Usability issues, and Manual Actions. Every critical finding in GSC represents a confirmed Google-visible problem — prioritize these above findings from third-party tools.

2. **Crawl the site with a technical crawler** — Use Screaming Frog SEO Spider, Sitebulb, or Ahrefs Site Audit to crawl all accessible URLs. Configure the crawler to match Googlebot's behavior: respect robots.txt, follow redirects, crawl as a desktop and then a mobile user agent. Export the full URL list with status codes, meta tags, canonical tags, and response times.

3. **Audit crawlability and robots.txt** — Review robots.txt to confirm it does not accidentally block critical resources: CSS files, JavaScript files, or important URL paths. Test `robots.txt` against your key URLs using Google's robots.txt tester in Search Console. Identify crawl traps: infinite URL spaces generated by faceted navigation, session IDs in URLs, or calendar pages generating millions of thin URLs.

4. **Audit indexation signals** — For each URL, verify: (a) canonical tag points to the correct self-referencing or canonical URL; (b) meta robots is set to `index, follow` for pages intended to rank; (c) the page is not excluded from Search Console's Coverage report. Check for orphaned pages (pages with no internal links) — they cannot be discovered by crawlers even if technically indexable.

5. **Identify and fix redirect chains** — Every redirect adds latency and dilutes PageRank passed through the chain. A redirect chain is: A → B → C (should be A → C). A redirect loop is: A → B → A (causes indexation failure). Screaming Frog flags both. Fix by updating all links to point directly to the final destination URL and collapsing chains to single-hop redirects.

6. **Audit duplicate content** — Duplicate content confuses Google's canonicalization decision and splits ranking signals. Sources of duplication: HTTP vs. HTTPS, www vs. non-www, trailing slash vs. no trailing slash, URL parameter variants, printer-friendly page versions, and paginated content without proper canonical handling. Resolve with explicit canonical tags, 301 redirects to the canonical variant, and parameter handling rules in GSC.

7. **Measure Core Web Vitals against field data thresholds** — Google uses field data (Chrome User Experience Report) for ranking signals, not lab data. Check CrUX data via PageSpeed Insights and GSC's Core Web Vitals report. Targets: LCP ≤ 2.5s (Largest Contentful Paint); INP ≤ 200ms (Interaction to Next Paint); CLS ≤ 0.1 (Cumulative Layout Shift). Identify the specific elements causing failures: LCP is typically a hero image or large text block; CLS is caused by images without dimensions, injected banners, or web fonts causing layout shifts.

8. **Audit structured data implementation** — Use Google's Rich Results Test and Schema Markup Validator to check for errors in structured data. Verify: JSON-LD is the preferred format; schema types match the page content (Article, Product, FAQ, HowTo, BreadcrumbList); required properties are present; no misleading or spammy markup that violates Google's structured data quality guidelines. Valid structured data enables rich snippets, which improve CTR by 20–30% in search results.

9. **Audit internal linking and site architecture** — Map internal link equity distribution using your crawler's internal link report. Pages that should rank (commercial pages, landing pages) must receive sufficient internal links from high-traffic, high-authority pages. Identify: pages with zero internal links (orphans), pages buried more than 3 clicks from the homepage (poor crawl depth), and pages with excessive outbound internal links that dilute passed equity.

10. **Produce a prioritized findings matrix** — Categorize every finding by: (a) impact on rankings (High/Medium/Low); (b) effort to fix (Hours/Days/Weeks); (c) breadth (affects 1 page / 10 pages / 1,000 pages). Prioritize High Impact × Low Effort × High Breadth issues first. Present to developers as a ticket-ready specification with exact URLs, expected fix, and acceptance criteria. Schedule a re-crawl 30 days after implementation to validate fixes.

## Rules

- Always cross-reference crawler findings against Search Console data — crawler tools find potential issues; GSC confirms which issues Google has actually encountered.
- Do not fix crawl issues and content issues simultaneously — fixing technical issues first establishes baseline performance; content changes before technical issues are resolved produce results that cannot be attributed to either change.
- Validate robots.txt changes in a staging environment before deploying — a single misconfigured disallow rule can deindex an entire site within one crawl cycle.

## Common Mistakes

- **Fixing symptoms instead of root causes** — A redirect chain is a symptom; the root cause is internal links pointing to old URLs. Fixing the redirect chain without updating internal links means the chain will regenerate as new content is published.
- **Ignoring mobile crawl performance** — Google uses mobile-first indexing. A site that performs well on desktop Lighthouse but fails mobile CWV thresholds will have its mobile performance scored, not its desktop performance. Always audit mobile separately.
- **Over-indexing on crawl tool scores** — Screaming Frog and Ahrefs assign issue severity based on generic rules. An issue flagged as "critical" by a tool may be irrelevant for a specific site architecture. Apply judgment: does this issue affect pages that Google needs to index and rank?
- **Neglecting crawl budget on large sites** — Sites with 100,000+ URLs face crawl budget constraints. Google will not crawl every URL on every crawl. Auditing crawl budget waste (thin pages, pagination, duplicate parameter URLs consuming crawl budget) is critical for large-scale sites but irrelevant for small sites.

## Examples

**LCP fix:** An e-commerce site's hero image was loading via JavaScript after page render, producing LCP of 4.2s. Moving the image to an `<img>` tag with `fetchpriority="high"` and preloading it via `<link rel="preload">` reduced LCP to 1.8s — below the 2.5s threshold — with a corresponding ranking improvement within 6 weeks.

**Canonical fix:** A news site had both `example.com/article/` and `example.com/article` (without trailing slash) indexed as separate URLs. Adding a canonical tag to all trailing-slash variants pointing to the canonical non-trailing-slash URL consolidated ranking signals and improved position 1–3 rankings by 18% within 60 days.

## When NOT to Use

- For brand-new websites with fewer than 50 pages — start with content and link building; technical issues at this scale have minimal ranking impact.
- When the primary traffic problem is poor content quality or insufficient backlinks — technical fixes cannot compensate for a content strategy gap; diagnose the primary constraint first.