Next.js SEO
How to Run a Technical SEO Audit on a Next.js Website
Audit a Next.js site for crawlability, status codes, metadata, canonicals, structured data, rendering, performance, sitemaps, and production failures.
A useful audit follows a URL from discovery to response, rendering, interpretation, and indexing. Checking whether a title tag exists is only one small part of that path.
Define the audit inventory
Collect known public routes from the sitemap, application route tree, content database, analytics, and search tooling. Group them by template: home, marketing, article, product, category, account, search, filter, and error pages. Template sampling finds systemic defects faster than reading random URLs.
Record the production origin, preferred protocol and host, trailing-slash rule, locales, and parameter policy. Without those decisions, a crawler report can identify differences but cannot tell which version is correct.
Check response and redirect behavior
Request each sample without browser JavaScript. Verify successful pages return 200, missing resources return 404 or 410, redirects use the intended permanent or temporary status, and redirect chains do not bounce through several hosts or URL shapes.
Look for soft 404s: a successful page that displays not-found messaging or an empty result. Test uppercase paths, old slugs, trailing slashes, query parameters, the bare domain, www, HTTP, and a random dynamic slug. Status behavior should be deliberate at every edge.
A small response audit
curl -I https://example.com/old-page
curl -I https://example.com/blog/known-post
curl -I https://example.com/blog/not-a-real-post
curl -I http://example.com/Compare raw HTML with rendered output
Fetch the original response and confirm that primary headings, body content, internal links, canonical tags, robots directives, and structured data are present. Then render the page in a browser to find hydration failures, client-only content gaps, and scripts that overwrite correct server output.
A Client Component is not automatically an SEO problem, but an empty application shell raises the cost and complexity of rendering. In the App Router, move public content back to Server Components and keep interactive controls at narrow boundaries.
Audit titles, descriptions, and canonicals
Export the final title, description, H1, canonical, robots value, and status for every URL. Find missing, duplicate, truncated, templated, or contradictory values. Review duplicates by intent: two pages can share a phrase without being duplicates, while two different titles can hide the same answer.
Canonical URLs should resolve successfully, use the preferred host and path policy, appear in internal links, and match sitemap entries. Flag canonical chains, canonicals to missing pages, and routes whose canonical changes after client hydration.
Audit crawler files and site architecture
Check that robots.txt is reachable, syntactically correct, and points to the intended sitemap. Make sure it does not accidentally block assets needed for rendering. Verify sitemap XML, canonical hostnames, meaningful modification dates, and the absence of private, redirected, noindex, or missing pages.
Follow internal links from the home page and key hubs. Important content should not depend only on a sitemap. Look for orphaned pages, broken links, excessive depth, generic anchor text, and category structures that fail to surface the strongest pages.
Validate structured data by template
Extract JSON-LD, parse it, and validate representative Article, Product, SoftwareApplication, and BreadcrumbList objects. Compare prices, availability, authors, dates, ratings, and URLs with the visible page and source record. Invalid markup is a defect; valid but misleading markup is a larger one.
Test edge records: missing images, products without offers, out-of-stock variants, articles with an organization author, and paths with special characters. Template validation should run when content is ingested as well as during the audit.
Measure performance and stability
Run lab measurements on representative templates, then compare them with field Core Web Vitals. Inspect slow server responses, layout shifts, oversized images, fonts, third-party scripts, and large client bundles. Test mobile viewports and a cold direct request, not only warm client navigation.
Performance work should preserve the page's job. Start with unnecessary client JavaScript, serial data waterfalls, missing image dimensions, and blocking third parties before removing useful content. Track results by route family so one fast home page does not hide a slow catalog.
Turn findings into release checks
Prioritize defects by reach and consequence: site-wide indexing blocks, broken canonicals, failed pages, and lost content come before small description improvements. Assign every issue an owner, affected template, reproduction, expected behavior, and verification method.
Adios makes the fix reviewable as a source change and verifiable as a release. Deploy the candidate, inspect build and runtime logs, run the URL sample against the generated HTTPS route, and confirm the health check. Promote only after the corrected redirects, metadata, HTML, sitemap, and structured data pass on the production build.
- —Block release on failed builds, unhealthy runtime, broken primary routes, or accidental noindex rules.
- —Regression-test one normal and one edge record per route template.
- —Keep the canonical domain on the healthy promoted release.
- —Repeat the focused audit after promotion and monitor server errors.