Technical SEO Audit Checklist Template

Crawlability & Indexation Audit

Confirm that search engines can discover, crawl, and index the right pages, and nothing else.

Robots & Crawl Directives

• ☐ Confirm robots.txt resolves at the root domain and returns a 200 status, not a 4xx/5xx.
• ☐ Verify no Disallow rule is blocking CSS, JavaScript, or important content directories needed for rendering.
• ☐ Check that staging or development hosts are blocked from production, and that production is not accidentally disallowed site-wide (['Disallow: /']).
• ☐ Confirm a valid sitemap reference is declared in robots.txt.
• ☐ Review meta robots and X-Robots-Tag headers for unintended noindex or nofollow on indexable pages.
• ☐ Ensure pages you want indexed are not blocked by robots.txt (a disallowed URL cannot read its own noindex tag).

XML Sitemaps

• ☐ Confirm the sitemap lists only canonical, indexable, 200-status URLs: no redirects, no noindex, no blocked URLs.
• ☐ Verify the sitemap stays under the per-file limits (['50,000 URLs / 50 MB uncompressed']) and uses a sitemap index when needed.
• ☐ Check that URLs use absolute, consistent, https paths matching the preferred domain.
• ☐ Submit the sitemap in Search Console and confirm it is read without errors.
• ☐ Reconcile sitemap URL count against indexed count and investigate large gaps.

Canonicalization

• ☐ Confirm every indexable page declares a self-referencing canonical (absolute URL).
• ☐ Verify canonical tags point to live 200-status URLs, not redirects or 404s.
• ☐ Check for conflicting signals (canonical vs. noindex, canonical vs. hreflang, canonical vs. sitemap).
• ☐ Ensure parameter, faceted, paginated, and session-ID variants canonicalize correctly.
• ☐ Confirm only one URL version is canonical across http/https, www/non-www, and trailing-slash variants.

Index Coverage

• ☐ Review the Search Console Page indexing report and triage each Not indexed reason.
• ☐ Investigate Crawled: currently not indexed and Discovered: currently not indexed for quality or crawl-budget issues.
• ☐ Resolve Duplicate without user-selected canonical and Alternate page with proper canonical tag patterns.
• ☐ Use URL Inspection to confirm the rendered HTML, canonical, and indexability of key templates.
• ☐ Check server logs or the Crawl Stats report for spikes in 4xx/5xx responses and crawl waste.
• ☐ Confirm important pages are reachable via internal links, not only via the sitemap.

Site Architecture & Internal Linking Audit

Ensure your most important pages are shallow, well-linked, and receiving internal link equity.

Crawl Depth & Structure

• ☐ Run a full crawl from the homepage and record click depth for every URL.
• ☐ Confirm priority pages sit within a shallow depth from the homepage (['3 clicks or fewer']).
• ☐ Identify deep pages buried behind pagination, filters, or thin hub pages and flatten where appropriate.
• ☐ Verify a logical, consistent URL hierarchy that mirrors site sections.
• ☐ Confirm the primary navigation and footer expose top categories and key money pages.

Orphan & Dead-End Pages

• ☐ Cross-reference crawl data with the sitemap and analytics/log data to find orphan pages (URLs with no internal inlinks).
• ☐ Add contextual internal links to recover valuable orphaned content, or remove/redirect low-value orphans.
• ☐ Identify dead-end pages with few or no outbound internal links and add relevant links.
• ☐ Confirm paginated and filtered pages still expose crawl paths to underlying items.

Link Equity & Anchor Text

• ☐ Map internal inlink counts and flag high-value pages that are under-linked.
• ☐ Reduce links pointing to low-value URLs (login, cart, utility pages) that dilute equity.
• ☐ Use descriptive, varied, keyword-relevant anchor text instead of generic click here.
• ☐ Confirm important internal links are crawlable <a href> elements, not JavaScript-only click handlers.
• ☐ Fix internal links that pass through redirects or land on 404s so equity flows directly.

Breadcrumbs & Hub Pages

• ☐ Implement breadcrumb navigation on deep templates and mark it up with BreadcrumbList structured data.
• ☐ Ensure breadcrumb links are real anchors and reflect the true site hierarchy.
• ☐ Build or strengthen hub/category pages that link out to related cluster content.
• ☐ Confirm related-content and contextual modules link laterally between topically relevant pages.

Core Web Vitals & Performance Audit

Diagnose and prioritize the page-speed and stability issues that hurt user experience and rankings.

Field Data & Diagnostics

• ☐ Review the Search Console Core Web Vitals report and note URL groups failing on mobile and desktop.
• ☐ Prioritize field (real-user) data over lab scores; use lab tools only to reproduce and debug.
• ☐ Confirm targets: LCP at or under ['2.5s'], INP at or under ['200ms'], CLS at or under ['0.1'] at the 75th percentile.
• ☐ Audit representative templates (home, category, product/article) rather than only the homepage.

Largest Contentful Paint (LCP)

• ☐ Identify the LCP element on each key template and confirm it loads early.
• ☐ Preload the LCP image or font and avoid lazy-loading above-the-fold media.
• ☐ Serve hero images in modern formats with correct dimensions and responsive srcset.
• ☐ Reduce server response time (TTFB) via caching and a CDN.

Interaction to Next Paint (INP)

• ☐ Break up long JavaScript tasks and defer non-critical scripts.
• ☐ Minimize main-thread work from third-party tags, A/B tools, and chat widgets.
• ☐ Remove unused JavaScript and CSS, and code-split large bundles.
• ☐ Test real interactions (taps, menu opens, form inputs) on a mid-tier mobile device.

Cumulative Layout Shift (CLS)

• ☐ Set explicit width and height (or aspect-ratio) on images, video, and embeds.
• ☐ Reserve space for ads, banners, and dynamically injected content.
• ☐ Preload web fonts and use font-display to limit layout shifts from text swaps.
• ☐ Avoid inserting content above existing content after load.

Delivery, Caching & Mobile

• ☐ Eliminate render-blocking CSS/JS and inline only critical CSS.
• ☐ Enable text compression (gzip/Brotli) and long-lived cache headers for static assets.
• ☐ Verify HTTP/2 or HTTP/3 and a CDN are serving assets close to users.
• ☐ Confirm the mobile layout is responsive, with tap targets and font sizes sized for touch.
• ☐ Re-test after each fix and watch the field data over a full collection window before declaring success.

Structured Data & Rich Results Audit

Validate that your schema markup is accurate, eligible, and earning the rich results it qualifies for.

Schema Coverage & Type Selection

• ☐ Inventory which templates have structured data and which eligible templates are missing it.
• ☐ Match each page to appropriate types (['Article, Product, FAQPage, BreadcrumbList, Organization, LocalBusiness']).
• ☐ Prefer JSON-LD placed in the page source and keep one consistent markup format per page.
• ☐ Implement an Organization or site-level entity with logo and sameAs profiles where relevant.

Accuracy & Eligibility Rules

• ☐ Confirm marked-up content is visible to users on the page: no hidden or markup-only data.
• ☐ Include all required properties for each type and add recommended properties to strengthen eligibility.
• ☐ Ensure values are truthful and current (price, availability, ratings, dates) and reflect on-page content.
• ☐ Only use review/rating markup for genuine, on-page reviews and follow current self-serving review policies.
• ☐ Confirm entity references and IDs are consistent across related markup blocks.

Validation & Testing

• ☐ Run each key template through the Rich Results Test and a schema validator.
• ☐ Fix all reported errors and resolve warnings that block enhancements.
• ☐ Test the rendered HTML, since some markup is injected by JavaScript after load.
• ☐ Spot-check several real URLs per template, not just one example.

Monitoring & Maintenance

• ☐ Track each rich-result type in the Search Console Enhancements reports for new errors.
• ☐ Set up alerts or a recurring check after template, CMS, or plugin changes.
• ☐ Re-validate when guidelines change or a feature is deprecated.
• ☐ Keep a log of which templates emit which schema types and who owns them.

International SEO Audit

Make sure the right language and regional version of each page is served and indexed for the right audience.

hreflang Implementation

• ☐ Confirm every page in a language/region set links to all alternates, including a self-referencing hreflang.
• ☐ Verify return tags are bidirectional: each alternate links back to the others (no one-way references).
• ☐ Use valid language and optional region codes (['en, en-GB, es-MX']) in ISO format.
• ☐ Include an x-default tag for the global/language-selector fallback.
• ☐ Pick one delivery method (HTML head, HTTP header, or sitemap) and apply it consistently.
• ☐ Point hreflang URLs to live 200-status, indexable, canonical pages, never redirects or noindex pages.

Canonical & Indexation Interplay

• ☐ Ensure each localized URL is self-canonical, not canonicalized to another language version.
• ☐ Confirm hreflang and canonical do not contradict each other on the same page.
• ☐ Check that near-duplicate localized pages are not being collapsed to a single canonical.
• ☐ Verify localized pages appear in their own sitemaps with correct alternate references.

Geotargeting & URL Structure

• ☐ Confirm a clear, scalable structure for languages/regions (ccTLD, subdomain, or subdirectory) and apply it consistently.
• ☐ Set country targeting where appropriate and align it with your URL strategy.
• ☐ Avoid IP-based auto-redirects that block crawlers or trap users in the wrong version; prefer a language banner or selector.
• ☐ Localize content meaningfully (currency, units, contact details, spelling) rather than duplicating one language.

Validation

• ☐ Crawl the site with hreflang reporting enabled and resolve missing or broken return tags.
• ☐ Use the URL Inspection tool to confirm how alternates are detected.
• ☐ Spot-check several locales for correct rendering, indexability, and serving.
• ☐ Re-audit after adding new locales or templates.

Site Migration / Redesign Audit

Protect rankings and traffic before, during, and after a migration or redesign by verifying redirects and parity.

Pre-Launch Preparation

• ☐ Crawl the live site and export a complete inventory of indexable URLs, titles, metadata, and status codes as a baseline.
• ☐ Record baseline performance: top organic landing pages, rankings, traffic, conversions, and index coverage.
• ☐ Confirm the staging site is blocked from indexing and protected (auth or IP allowlist), but verify directives will be removed at launch.
• ☐ Build a complete redirect map from every old URL to its closest new equivalent.
• ☐ Prepare new XML sitemaps, robots.txt, and analytics/Search Console properties for the new structure.

Redirect Mapping

• ☐ Use permanent 301 redirects for changed URLs and avoid 302s for permanent moves.
• ☐ Map old URLs one-to-one to relevant new pages; avoid mass redirects to the homepage.
• ☐ Eliminate redirect chains and loops so each old URL resolves in a single hop.
• ☐ Preserve or migrate hreflang, canonical, and structured data to the new URLs.
• ☐ Plan for legacy parameters, media files, and any URLs with external backlinks.

Content & Technical Parity

• ☐ Verify titles, meta descriptions, headings, body content, and images carried over or improved.
• ☐ Confirm internal links point to new URLs directly, not through redirects.
• ☐ Check that canonical tags, structured data, and hreflang are correct on the new templates.
• ☐ Compare Core Web Vitals and key page speed before and after to catch regressions.

Launch & Post-Launch Validation

• ☐ At go-live, remove staging noindex/robots blocks and confirm the production site is crawlable.
• ☐ Submit new sitemaps and use URL Inspection to request indexing on priority pages.
• ☐ Re-crawl the new site to confirm redirects resolve, no critical 404s exist, and no template emits unintended noindex.
• ☐ Monitor index coverage, crawl stats, rankings, and traffic daily for the first weeks and watch for sustained drops.
• ☐ Keep redirects in place long-term and fix any newly discovered broken paths.

How often should I run a technical SEO audit?

For most sites, a comprehensive technical audit every quarter works well, paired with continuous monitoring in between. Large, frequently changing sites (big e-commerce or news publishers) benefit from monthly deep dives, while small, stable sites can often go six months. Beyond the schedule, always run the relevant audit module after any major event: a migration, redesign, CMS change, or template update, since those are when technical issues are introduced.

What is the difference between an audit and ongoing monitoring?

An audit is a point-in-time, comprehensive review where you systematically inspect crawlability, architecture, performance, structured data, and more to find and prioritize issues. Monitoring is the continuous, automated layer that watches for new problems between audits, tracking index coverage, broken links, status-code spikes, Core Web Vitals, and structured-data errors so regressions surface quickly. Audits set direction and uncover deep issues; monitoring catches new ones fast. You need both.

Are Core Web Vitals a ranking factor?

Yes. Core Web Vitals are part of Google's page experience signals and can influence rankings, especially as a tiebreaker between pages of similar relevance and quality. They are not a magic bullet (relevant, helpful content remains the dominant factor) so treat Core Web Vitals as a meaningful user-experience and ranking input to get right, not as a substitute for content quality and overall site health.

Does Google render JavaScript, and why does it matter for an audit?

Google can render JavaScript, but rendering happens in a second pass after the initial crawl and depends on resources being crawlable. If critical content, internal links, canonicals, or structured data only appear after client-side JavaScript runs, they may be discovered late or missed if scripts are blocked or fail. During an audit, always check the rendered DOM in addition to the raw HTML, and confirm your robots.txt allows the JavaScript and CSS needed for rendering.

Which technical issues should I fix first?

Prioritize anything that blocks crawling or indexing of important pages: accidental noindex tags, overly broad robots.txt disallow rules, broken or conflicting canonicals, server errors (5xx), and redirect chains or loops. These can remove pages from search entirely, so they outrank cosmetic fixes. After clearing crawl and index blockers, work down by severity through site architecture, Core Web Vitals, structured data, and international issues.

How long after fixing issues will I see results?

It varies by issue and how quickly search engines re-crawl the affected pages. Removing an index blocker can be reflected within days for high-priority URLs you request via URL Inspection, while broad changes across a large site can take weeks as recrawling completes. Field-based metrics like Core Web Vitals update only after a full data-collection window passes, so expect a delay before improvements appear in those reports. Re-crawl, validate, and monitor rather than assuming an instant change.