SEO and AI search
Web
AI
Resources
WorkAboutStart a project

Next.js SEO

Next.js SEO: how to make a React site easy for Google to read

Next.js can produce very fast, crawlable pages. It can also hide content from crawlers if the wrong rendering choice is made. This is how we check.

In short

In short: for SEO, render important content on the server (static or server-rendered), set titles, descriptions and canonicals with the metadata API, generate sitemap and robots files in code, return real 404 status codes, and block preview deployments from indexing. Most Next.js ranking problems are rendering or redirect mistakes, not framework limits.

Start with where the content is rendered

Google can run JavaScript, but it does so in a second step, after the first fetch. Content that only appears after client-side code runs is slower to be seen and easier to lose. The first question on any Next.js audit is therefore simple: if I view the raw HTML response for this URL, is the main content in it?

Rendering modeContent in first HTML?Good forSEO risk
Static generationYesMarketing pages, docs, articlesStale content if rebuilds are rare
Incremental regenerationYesLarge catalogs, frequently edited pagesShort delay before updates appear
Server rendering per requestYesPersonalized or fast-changing pagesSlower responses if data is slow
Client-side fetch after loadNoDashboards behind a loginPublic pages built this way can look empty to crawlers

Rule of thumb: anything you want to rank should be static or server-rendered. Anything behind a login does not need SEO at all.

Metadata, canonicals and structured data

In the App Router, titles, descriptions, canonical URLs and social tags are set through the metadata API, either as a static object or generated per route from your data. We use one helper so every page gets a unique title and description, a canonical that matches the preferred URL, and an alternates block when there are language versions.

  • Canonicals must be absolute and consistent with your trailing-slash setting.
  • Query-string variants such as sort and filter parameters should canonicalize to the clean page.
  • JSON-LD goes in the page as a script element, built from the same data that renders the page, so the two cannot drift apart.
  • Open Graph images are generated per page rather than one image for the whole site.

Our schema markup generator shows what common markup looks like before you wire it into code.

Sitemaps, robots and redirects

Both the sitemap and robots.txt can be generated by route files, so they stay in step with your content. The sitemap should list only canonical, indexable, 200-status URLs. Last-modified dates should reflect real changes, not the build time.

Redirects live in the framework configuration or in middleware. A permanent redirect from the configuration returns a 308 status, which Google treats the same way as a 301 for our purposes. What matters more is the mapping. Redirect chains from old domains, http to https, non-www to www and trailing slash fixes should collapse into one hop wherever possible.

Soft 404s are a known trap. If a not-found state is triggered after the response has started streaming, the status code may already be 200. Test your missing-page routes with a header checker, not just by eye.

Mistakes we find repeatedly

  • Preview deployments reachable and indexable, creating duplicate copies of the site on temporary hostnames.
  • A global layout that sets one title and description for every page.
  • Internal links built with click handlers instead of real anchor links, so crawlers cannot follow them.
  • Images and fonts loaded without the framework's optimization, hurting Core Web Vitals.
  • Language versions with no hreflang or with hreflang pointing at redirected URLs.
  • Heavy client-side components wrapped around content that could be rendered on the server.
  • Middleware that redirects crawlers differently from browsers, usually by accident.

Fixing these seldom needs a rewrite. It needs someone to look at the real HTML and headers for a sample of every template.

A worked example: moving a WordPress site to Next.js

Suppose a marketing site on WordPress with 300 URLs moves to Next.js with a headless CMS. The safe route has five stages.

  1. InventoryCrawl the old site and export top pages by clicks from Google Search Console. Mark which pages bring traffic or links.
  2. MapPair each old URL with a new one. Keep slugs the same where possible. Every removed page gets a redirect to the closest relevant replacement.
  3. BuildRecreate titles, headings, internal links and schema on the new templates before polishing design.
  4. Test on a protected staging siteCrawl staging, compare against the map, check status codes and canonicals. Keep staging noindexed.
  5. Launch and watchSubmit the new sitemap, check indexing and impressions daily for two weeks, and fix gaps quickly.

If you are still deciding between the two, read Next.js vs WordPress. For a build on this stack, see our headless Next.js development service.

Timeline and what we can show

WorkTypical time
SEO review of an existing Next.js site1 to 2 weeks
Fixing metadata, sitemaps, redirects and rendering2 to 4 weeks, depending on the number of templates
Migration from another platform6 to 12 weeks including testing and monitoring
Search Console effect after launchWeeks to a few months

We have no published case study of a Next.js SEO project, so we do not show results here. What we can show is the process and a fixed quote after a short call. Start on the contact page.

Updated 30 October 2026

Questions, answered

Is Next.js good for SEO?
Yes, when public pages are statically generated or server-rendered and metadata is set per route. It is not good for SEO if public content only loads in the browser after JavaScript runs.
Does Google index client-side rendered React?
It can, but it takes an extra rendering step and can fail or lag. For pages you want to rank, render the content on the server.
Should I use the App Router or the Pages Router?
Both can be made SEO-friendly. New builds should generally use the App Router because the metadata API and server components make correct SEO easier. Existing Pages Router sites do not need to be rewritten for SEO alone.
Why are my preview URLs showing up in Google?
Preview deployments sit on public hostnames. Check that they send a noindex header or are behind authentication, and remove any that were indexed.
How do I handle SEO for multiple languages in Next.js?
Use locale-based routes, a self-referencing canonical per language and reciprocal hreflang tags. Our hreflang generator tool can help you check the output.

Is your Next.js site invisible to Google?

Send us the domain and we will quote a review after a short call.