Technical SEO Audit Checklist for React and Next.js Websites

Purpose

Use this checklist to audit a React or Next.js page from the rendered document outward. It helps separate metadata issues from deeper crawlability, rendering, routing, internal‑linking, structured‑data, performance and indexability problems.

Who This Is For

• Developers responsible for React or Next.js templates.
• Technical SEOs reviewing JavaScript‑heavy websites.
• Technical leads who need a concise audit frame before launch or remediation work.

When to Use This

• Before a launch or migration.
• When pages are crawled but not indexed.
• When rankings or traffic changed after a technical release.
• When a team needs to separate content issues from rendering and routing issues.

How to Use This Resource

Work through each section with rendered evidence. Do not sign off from source code or browser screenshots alone when the issue depends on what crawlers can fetch, render and validate.

Technical SEO Checklist

The sections are ordered from discovery and crawlability through to rendered output, structured data and performance. Work through them with the deployed page, rendered HTML and crawl evidence available, rather than relying only on source code or local screenshots.

Rendered HTML

• What to check: Search‑critical content, links, headings, metadata and JSON‑LD are present in server‑rendered or crawler‑visible HTML.
• Why it matters: JavaScript‑heavy sites can look complete in the browser while crawlers receive thin or delayed content.
• How to validate it: Compare view‑source, fetched HTML, rendered DOM and crawler output for priority templates.
• Common failure pattern: The audit reviews the hydrated page only and misses missing HTML in the initial response.

Indexability

• What to check: Noindex, robots, canonical, status‑code and redirect signals agree for each priority URL.
• Why it matters: Conflicting indexability signals can prevent valuable pages from being indexed or consolidated correctly.
• How to validate it: Crawl the site, inspect headers, check robots directives and confirm Search Console URL inspection for representative pages.
• Common failure pattern: A noindex from staging or a canonical to an old route remains after launch.

Metadata

• What to check: Titles, meta descriptions, Open Graph fields and page‑level summaries are unique, useful and template‑safe.
• Why it matters: Metadata helps identify the page, supports sharing and exposes CMS fallback mistakes quickly.
• How to validate it: Compare generated metadata across templates, categories and edge‑case CMS entries.
• Common failure pattern: A default title or description silently appears across multiple high‑value pages.

Canonical URLs

• What to check: Canonical URLs are absolute, stable, self‑referential where appropriate and not polluted by staging hosts or query strings.
• Why it matters: Canonical drift can weaken URL identity and cause search engines to select the wrong page.
• How to validate it: Inspect rendered head output, crawl canonical targets and test paginated or parameterised variants.
• Common failure pattern: A canonical helper normalises the visible route differently from the deployed route.

Routing and Status Codes

• What to check: Routes return appropriate 200, 3xx, 4xx or 410 statuses, including trailing‑slash and normalisation variants.
• Why it matters: Search engines and users need consistent URL behaviour, especially in Next.js applications with rewrites and redirects.
• How to validate it: Fetch route variants, inspect headers and compare redirects against the intended route registry.
• Common failure pattern: Client‑side routing hides a server‑side 404, or a rewrite makes duplicate pages appear valid.

Redirects

• What to check: Legacy URLs, changed slugs and normalised variants redirect cleanly without chains or loops.
• Why it matters: Redirects preserve user paths and link equity when routes change.
• How to validate it: Test redirect maps, crawl known legacy URLs and check high‑value backlinks where data is available.
• Common failure pattern: Redirects are added for obvious URLs only and miss case, slash, query or encoded variants.

Sitemap and Robots Rules

• What to check: Sitemap output includes valid indexable URLs only, and robots rules match the production environment.
• Why it matters: Discovery files should reinforce the route plan rather than leak stale or blocked URLs.
• How to validate it: Check sitemap XML, robots.txt, generated route data and Search Console sitemap submission results.
• Common failure pattern: The sitemap includes CMS drafts, test routes or old article URLs.

Internal Links

• What to check: Navigation, breadcrumbs, cards and body links use crawlable anchors with descriptive text and valid hrefs.
• Why it matters: Internal links shape discovery, topical context and commercial journeys.
• How to validate it: Crawl links, review rendered anchors and compare important clusters against service and article priorities.
• Common failure pattern: A card is clickable by JavaScript but has no crawlable anchor in the rendered HTML.

Structured Data

• What to check: JSON‑LD is valid, specific, visible‑content backed and consistent across service, article, project and breadcrumb templates.
• Why it matters: Structured data improves entity clarity and can support eligible search features, but it does not guarantee rankings or rich results.
• How to validate it: Run Rich Results Test and Schema Markup Validator checks, then compare schema to visible evidence.
• Common failure pattern: Schema is copied from another template and claims content, offers or FAQs that are not visible.

Images and Media

• What to check: Important images have dimensions, appropriate alternatives, optimised delivery and social metadata where needed.
• Why it matters: Poor media handling can hurt performance, accessibility, sharing and template consistency.
• How to validate it: Inspect rendered media attributes, generated image sizes, alt text and Open Graph image output.
• Common failure pattern: Hero images are visually correct but missing dimensions or have generic alt text.

Hydration Issues

• What to check: Hydration does not remove, reorder or duplicate search‑critical content, links or structured data.
• Why it matters: Crawlers, users and analytics can see inconsistent pages when hydration changes the document after load.
• How to validate it: Compare initial HTML, hydrated DOM and console warnings for priority templates.
• Common failure pattern: A client component overwrites server‑rendered content with an empty loading state.

Pagination and Faceted Content

• What to check: Pagination, filters and parameterised routes have deliberate crawl, index and canonical handling.
• Why it matters: Faceted URLs can create crawl traps, duplicates or inaccessible content when left to defaults.
• How to validate it: Crawl filtered routes, inspect canonicals and check whether important paths are linked and indexable.
• Common failure pattern: Useful listing pages are hidden behind client‑side filters, while low‑value parameter variants are indexable.

Core Web Vitals

• What to check: LCP, CLS and INP risks are reviewed in the context of real templates, assets and third‑party scripts.
• Why it matters: Performance regressions can affect users and commercial pages even when the framework choice is sound.
• How to validate it: Use Lighthouse, field‑data context, image checks and interaction review for priority pages.
• Common failure pattern: A migration reduces HTML risk but adds slower client‑side interaction and unstable layouts.

Monitoring and Validation

• What to check: The site has a repeatable way to monitor crawl errors, indexation, schema validity, performance and conversion health.
• Why it matters: An audit should leave a team with a way to detect regressions after the report is finished.
• How to validate it: Review Search Console, logs, analytics, uptime checks, build output and schema validation reports.
• Common failure pattern: Findings are fixed once, but no owner notices when the CMS or template drifts later.

Common Failure Patterns

• The audit checks metadata but not rendered HTML.
• Client‑side links and content are assumed to be crawlable.
• Schema validates once but is not compared with visible page content.
• Performance is reviewed separately from template and rendering decisions.
• Findings do not create owners, validation methods or monitoring checks.