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 mode | Content in first HTML? | Good for | SEO risk |
|---|---|---|---|
| Static generation | Yes | Marketing pages, docs, articles | Stale content if rebuilds are rare |
| Incremental regeneration | Yes | Large catalogs, frequently edited pages | Short delay before updates appear |
| Server rendering per request | Yes | Personalized or fast-changing pages | Slower responses if data is slow |
| Client-side fetch after load | No | Dashboards behind a login | Public 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.
- InventoryCrawl the old site and export top pages by clicks from Google Search Console. Mark which pages bring traffic or links.
- 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.
- BuildRecreate titles, headings, internal links and schema on the new templates before polishing design.
- Test on a protected staging siteCrawl staging, compare against the map, check status codes and canonicals. Keep staging noindexed.
- 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
| Work | Typical time |
|---|---|
| SEO review of an existing Next.js site | 1 to 2 weeks |
| Fixing metadata, sitemaps, redirects and rendering | 2 to 4 weeks, depending on the number of templates |
| Migration from another platform | 6 to 12 weeks including testing and monitoring |
| Search Console effect after launch | Weeks 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?
Does Google index client-side rendered React?
Should I use the App Router or the Pages Router?
Why are my preview URLs showing up in Google?
How do I handle SEO for multiple languages in Next.js?
Keep exploring
Next.js and headless development, only where it pays off
A headless build separates your content from the website that shows it. That is powerful and costs more to run, so we start by checking whether you…
ComparisonNext.js vs WordPress: which should you build on?
WordPress is a ready-made publishing system. Next.js is a framework for building exactly the site or product you design. One gives you speed to…
GuideSEO for Next.js: what to set up and what breaks
Next.js can produce very crawlable pages, but only if each route is rendered, tagged and linked on purpose. This guide covers the setup and the…
Is your Next.js site invisible to Google?
Send us the domain and we will quote a review after a short call.