Nextjs Indexing: SSR, SSG and ISR Guide

Next.js indexing depends on one simple question: what HTML does Googlebot receive on the first request, and how fast does it arrive. This guide to nextjs indexing covers the three answers Next.js provides. Server side rendering builds the page on each request, static site generation builds it once at build time, and incremental static regeneration rebuilds static pages in the background on a schedule. All three can rank well when they are set up correctly, and all three can fail when caching, metadata, or data fetching gets in the way. This guide is for developers, site owners, and SEOs who run a Next.js site and want every important URL crawled, rendered, and kept in the index without drama.

You will learn exactly how each rendering mode maps to crawl behavior, how to configure server side rendering so it responds fast enough for heavy crawl, when static generation is the safer choice, how to use revalidation without causing index churn, how to wire App Router metadata, sitemaps, and canonical tags so each URL has one clear indexable version, which data fetching patterns slow down discovery, and how to measure time to index and fix gaps with Search Console and server logs. By the end you will have a repeatable checklist you can apply to any Next.js project, whether it has fifty pages or five million. If your background is client rendered React, start with our companion guide on getting React single page apps indexed correctly for the rendering baseline, then return here for the Next.js specifics.

Key takeaways

Next.js indexing works with SSR, SSG, and ISR, because Googlebot indexes the rendered HTML it receives, so the fastest mode that still serves complete content usually wins.
Server side rendering is best for personalized or fast changing pages, static generation is best for stable content at scale, and ISR sits between them for large catalogs that change on a schedule.
App Router metadata, one canonical URL per page, clean sitemaps with accurate lastmod values, and restrained blocking in robots.txt decide whether good rendering turns into stable indexation.
Data fetching choices, cache headers, and middleware redirects cause most Next.js index gaps, and server logs plus Search Console coverage reports point to the exact failing layer.

How Next.js rendering modes map to what Googlebot sees
SSR setup that indexes fastest
SSG setup and when static wins
ISR and revalidation without index churn
Routing metadata sitemaps and canonicals in App Router
Data fetching pitfalls that delay indexing
Fixing Nextjs indexing gaps with logs and Search Console
FAQ

Nextjs indexing guide showing SSR SSG and ISR mapped to Googlebot crawl and index flow

How Next.js rendering modes map to what Googlebot sees

Googlebot processes a Next.js page in two passes. The first pass fetches the raw HTML and queues the page for rendering. The second pass runs JavaScript, waits for network activity to settle, and captures the rendered DOM. Google documents this two pass model in JavaScript SEO basics, which is worth reading alongside your own fetch tests. The gap between those passes is the rendering queue, and it can last hours or days on large sites. Server side rendering and static generation shrink that gap to near zero because the first response already contains the full article text, headings, links, and metadata. Client side rendering stretches the gap because the first response is mostly a shell, and the content only appears after scripts run. That is why two Next.js pages with identical visible text can index days apart when one is server rendered and the other relies on the browser to fill in content.

Start by mapping every route in your app to its rendering mode. Open your App Router structure and list which segments use static rendering by default, which call dynamic functions such as headers or cookies, and which set explicit dynamic or revalidate options. A marketing page with no personalization should stay static. A pricing page that reads a cookie for currency should be dynamic. A product listing that updates hourly should use timed revalidation. Write this map in a simple table with columns for route pattern, mode, data source, and expected change frequency. This table becomes the reference for every later decision about caching, sitemaps, and crawl budget, because each mode creates a different contract with the crawler about freshness and response time.

Response time shapes crawl behavior more than most teams expect. Googlebot adjusts its request rate based on how fast your server answers and how often it hits errors. A server rendered route that answers in 150 milliseconds with warm caches invites steady crawling. The same route answering in 2.5 seconds with cold database queries on every hit teaches the scheduler to slow down, which stretches discovery of new URLs. Static routes have a natural advantage here because they can sit behind a content delivery network and answer in tens of milliseconds worldwide. If you choose server rendering for a large section, you accept responsibility for keeping its latency low under crawler parallelism, not only under single user tests. Load test the exact URLs crawlers hit, including paginated listing pages and filtered views, because those are the pages that reveal database bottlenecks first.

Status codes and headers complete the picture. A 200 response with complete HTML and a self referencing canonical tag is a clear invitation to index. A 200 response that actually renders a soft error message, a login wall, or an empty shell confuses the index and can push the URL into soft 404 or thin content states. Middleware that redirects based on geography, device, or missing cookies can split one logical page into several crawler visible variants, which dilutes signals. Audit what Googlebot receives, not what your browser shows after login. Fetch key templates with a plain HTTP client that runs no JavaScript, then compare that output with the rendered DOM from a testing tool. When both versions carry the same title, description, canonical, main heading, body text, and internal links, your rendering mode is doing its job. When they differ, fix the server response first before touching anything else, because no sitemap or internal link can compensate for an inconsistent first byte.

The practical consequence is straightforward. Treat rendering mode as an indexing control, not only a performance preference. Prefer static output for content that changes rarely, prefer timed revalidation for catalogs that change on a schedule, and reserve full server rendering for pages where freshness or personalization truly requires it. Document the choice per route, keep first byte fast, serve the same core content to crawlers and users, and confirm with both raw fetch tests and rendered tests. Teams that run this map rarely chase mystery deindexing, because every coverage warning in Search Console traces back to a known route with a known mode and a known owner. That clarity is the foundation for everything that follows in this guide, from cache tuning to sitemap design.

To see why this matters, consider a typical content site with 2,000 articles, 300 category pages, and 40 marketing pages. Serving all of them server rendered with uncached database reads keeps content fresh, but it also means every crawl wave triggers thousands of slow queries. Moving articles and marketing pages to static output while keeping only search and account pages dynamic often cuts median crawler response time by half or more, with no visible change for readers. The index effect shows up within weeks as faster discovery of new articles and fewer crawled but not indexed warnings on older ones. The lesson repeats across stores, directories, and docs sites. Static first where you can, dynamic where you must, and measured everywhere.

SSR setup that indexes fastest

Server side rendering earns its place when pages must reflect the latest data on every view, such as account dashboards, live pricing with per visitor rules, or editorial homepages that change hourly. The indexing goal for SSR is simple: answer every crawler request quickly with complete HTML, stable metadata, and consistent links, even under parallel load. The three levers are caching, data discipline, and edge placement. Cache what you can at the framework and CDN layers, fetch only what the page needs, and serve the response from as close to the visitor as your platform allows. Miss any lever and SSR turns into the slowest mode in your app, which is exactly what throttles crawl.

Start with the App Router cache model. Static rendering caches aggressively by default, while dynamic rendering runs per request unless you add caching around slow calls. Wrap shared data lookups with the framework cache helper so repeated renders within one request reuse results, and set fetch caching explicitly instead of relying on defaults you have not verified. For content that is the same for all visitors but must stay fresh, prefer short lived route level caching over fully dynamic rendering, because it preserves freshness while absorbing crawl bursts. For personalized fragments, stream them as separate suspense boundaries or client components around a fast static shell, so the indexable core arrives immediately and the personal widget fills in after. This pattern keeps the document title, headings, body, and links stable for the crawler while still serving tailored pieces to signed in users.

Data discipline decides whether SSR stays fast at scale. Audit every database query and upstream API call on your most crawled templates. Listing pages are the usual failure point, because one page can trigger dozens of lookups for products, prices, images, and reviews. Replace per item fan out with batched queries, cap related item counts on first paint, and defer secondary modules below the fold. Set timeouts and fallbacks so one slow upstream service degrades a single module instead of stalling the whole document. Log query counts and durations per route in production, then sort by crawler traffic to find the templates where small fixes produce the largest crawl savings. A single N plus one query removed from a category template can save millions of database calls per month on a large store, and the crawl rate improvement is often visible within days.

Edge placement and headers come next. Serve SSR responses through a CDN with rules that distinguish crawler safe cacheable HTML from truly personal responses. Cache anonymous page variants at the edge with short lifetimes, bypass cache only when auth cookies or personalization signals are present, and always send accurate cache control and vary headers so intermediate caches do not mix variants. Keep middleware lean, because every middleware redirect or rewrite runs before rendering and adds latency to every crawl request. Review middleware matchers so static assets, sitemaps, and robots.txt skip application logic entirely. Confirm the final status code per template, since middleware that returns redirects for missing trailing slashes or locale prefixes can double the request count for every URL the crawler discovers. When you audit codes, interpret them with MDN HTTP status definitions so the team shares one vocabulary for 200, 301, 404, 500, and 503 handling. One redirect per URL is tolerable, chains of two or three quietly burn crawl budget on sites with thin margins.

Errors deserve special attention on SSR routes because crawlers remember them. A template that throws under load returns 500 errors exactly when crawl interest peaks, which teaches the scheduler to back off. Add structured error boundaries so a failing recommendation module cannot sink the whole page, return proper 404 for genuinely missing IDs instead of 200 with an error message, and return 503 with a retry after header during planned maintenance instead of letting requests time out. Monitor five minute error rates per route and alert on crawler user agents separately from general traffic, because a one percent overall error rate can hide a twenty percent error rate on the paginated listing URLs that crawlers hit hardest. For a deeper look at how crawl capacity shapes discovery, read how Google decides what to crawl and index alongside your latency graphs, so rendering fixes and crawl capacity planning stay in one conversation.

Finally, test SSR the way crawlers experience it. Measure server timing with caching cold and warm, from multiple regions, under ten parallel requests, not one. Compare raw HTML to rendered DOM for title, description, canonical, headings, body word count, and link count. A solid nextjs ssr seo routine also confirms nextjs googlebot receives identical titles and links in raw and rendered HTML, because mismatches there explain most sudden coverage drops. Verify that pagination, sorting, and filters produce distinct URLs only when they deserve indexation, and that the rest carry canonical tags back to the primary view. When these checks pass, SSR becomes an indexing asset: always fresh, always complete, always fast enough to invite the next crawl wave.

SSG setup and when static wins

Static site generation is the most index friendly mode for content that does not change on every request, because the crawler receives a complete, fast, cacheable document with no database in the critical path. Product detail pages with stable descriptions, documentation, marketing pages, evergreen articles, and location pages are classic fits. The build step fetches data once, renders HTML, and deploys it to a CDN where it answers in milliseconds worldwide. That speed compounds across crawl waves. When ten thousand URLs each answer in 60 milliseconds instead of 800, the crawler covers more of your site per visit, revisits changed pages sooner, and leaves headroom for new URL discovery instead of spending its allowance waiting on your origin.

The main operational question for static is rebuild scope. Small sites can rebuild everything on every content change. Large sites cannot, because full builds take too long and delay freshness for the pages that changed. Solve this by splitting content into build groups with independent triggers. Docs rebuild on docs commits, product pages rebuild on catalog sync, marketing pages rebuild on demand from the CMS webhook. Keep a route manifest that records which group owns each URL pattern, and log build durations per group so slow groups get attention before they block launches. When a group grows past a few hundred thousand pages, consider moving its fastest changing subset to timed revalidation instead of pure static, which preserves static speed for readers while removing the rebuild bottleneck for editors.

Static does not mean stale metadata. Each statically generated page still needs a complete metadata story: one title under sixty characters, one description, one canonical URL, one set of Open Graph tags, and structured data where it fits. In App Router, define metadata per segment with the metadata API and generate it from the same data source as the page body, so titles never drift from content. Pay attention to paginated series and filtered views. A static category with fifty pages needs distinct titles and descriptions per page, correct prev and next signals through links, and canonical tags that point at each page itself when paginated pages deserve indexation, or back to page one when they do not. Decide the rule once, encode it in the template, and verify across ten sample pages before shipping, because pagination mistakes multiply across every static page in the series.

Images and fonts affect static indexing indirectly through Core Web Vitals and crawl efficiency. Use the built in image component with explicit sizes, remote image allowlists, and modern formats so pages stay light. Self host fonts or load them with display swap to avoid layout shift. Keep JavaScript bundles lean on content templates, because even static HTML gets parsed and checked for mobile usability, and heavy scripts slow the rendering pass that confirms links and structured data. Run field data checks on your most crawled static templates after each major dependency upgrade. A ten percent regression in largest contentful paint across one hundred thousand product pages is an indexing risk even when rankings look stable, because slower rendering narrows the margin for the next crawl wave.

Static also simplifies sitemaps and deployment safety. Because the page list is known at build time, you can generate sitemap files during the build with exact URLs and accurate lastmod timestamps from your CMS. Split sitemaps by content group, keep each file under fifty thousand URLs, and reference them from a sitemap index. Deploy with atomic releases so crawlers never catch a half updated site where new links point to pages that return 404 for a few minutes. Verify after each deploy by fetching a sample of new and changed URLs with plain HTTP, checking status codes, canonical tags, and lastmod alignment. When static output, metadata, media, sitemaps, and atomic deploys all line up, large sites stay indexed with minimal ongoing effort, which is why static wins wherever freshness rules allow it.

ISR and revalidation without index churn

Incremental static regeneration fills the gap between pure static and full server rendering. Pages serve as static files for speed, then refresh in the background after a set interval or on demand when content changes. For catalogs, directories, and news archives that update hourly or daily, ISR delivers static like response times without full rebuilds. A disciplined isr indexing schedule prevents churn: when revalidation settings are too aggressive, URLs flip between states, lastmod timestamps thrash, and crawlers see unstable signals that look like low quality. The fix is deliberate revalidation design where each route has one refresh rule tied to how its content actually changes.

Time based revalidation suits content with predictable rhythms. A deals page that updates every morning can revalidate every few hours. A reference article that changes monthly can revalidate weekly. Set intervals from measured change frequency, not guesses. Pull CMS edit history for each content type, compute the median time between meaningful changes, and set the interval to roughly half that value so pages refresh soon after typical edits without rebuilding constantly. Keep intervals consistent within a content group so sitemap lastmod values, cache headers, and crawler expectations agree. When one product template revalidates every minute while its sitemap claims weekly stability, the mixed signals waste recrawls on unchanged pages while starving pages that actually changed.

On demand revalidation suits event driven updates such as price changes, stock changes, or editorial corrections. Wire CMS webhooks or catalog sync jobs to revalidate only the affected paths plus their parent listing pages, and debounce bursts so a bulk import that touches ten thousand products triggers grouped revalidation instead of ten thousand simultaneous rebuilds. Secure the revalidation endpoint with a secret token, log every call with path and result, and alert when failure rates rise, because silent revalidation failures leave stale content served as fresh, which erodes trust in both users and crawlers. After each bulk update, sample revalidated URLs to confirm new content, correct status codes, and updated lastmod values before notifying any indexing workflow.

Watch for the subtle failure where revalidation returns errors and the framework keeps serving stale output indefinitely. This is safe for readers in the short term but dangerous for indexing when prices, availability, or article corrections never reach the crawler. Track the age of the currently served static file per route group, and alert when the 95th percentile age exceeds twice the configured interval. That single metric catches broken webhooks, expired tokens, and upstream API changes faster than any manual check. Pair it with a weekly diff that compares served HTML against source data for a random sample of URLs. When served age stays near the interval and diffs show expected changes flowing through, ISR is working. When age drifts or diffs stall, treat it as an indexing incident even if uptime dashboards stay green.

Nextjs indexing ISR revalidation cycle from static serve to updated index signal

Routing metadata sitemaps and canonicals in App Router

App Router gives you precise control over URLs and metadata, which directly controls indexation. Every public route should resolve to exactly one canonical URL with one title, one description, and one canonical tag pointing at itself. That sounds obvious, yet Next.js sites commonly expose the same content under trailing slash variants, locale prefixes, search parameter combinations, and old Pages Router paths left over from migration. Each variant splits crawl attention and risks duplicate without canonical warnings in Search Console. Lock the canonical form early: choose trailing slash behavior, choose lowercase paths, choose one locale prefix scheme, then enforce it with redirects and canonical tags generated from a single URL helper used by every template.

Metadata in App Router comes from the metadata API plus generated files such as sitemap and robots functions. Define titles and descriptions as close to the content as possible, ideally in the same segment that fetches the page data, so editors who change an article title automatically change its metadata. Keep titles specific and under sixty characters, front load the distinguishing term, and avoid repeating the site name on every paginated page. For paginated listings, append the page number in both title and description so each page has a distinct index identity when you want the series indexed. For filtered views with dozens of parameter combinations, set canonical tags back to the unfiltered URL and add noindex only when a view truly has no search value, because broad noindex on filtered templates often leaks onto primary pages through shared components.

Sitemaps deserve the same rigor as metadata. A clean nextjs sitemap generation workflow builds files from code with the sitemap function or a route handler, split by content type, and includes only URLs that return 200 with indexable canonical tags. Set lastmod from real content timestamps, not deploy time, so crawlers learn which sections change and how often. This discipline directly improves nextjs crawlability because crawlers spend visits on real pages rather than redirects and variants. Keep each sitemap file under the fifty thousand URL limit, compress large files, and list them in a sitemap index referenced from robots.txt. Submit the index in Search Console and monitor indexation ratios per sitemap file, because per file ratios reveal which content group needs attention. A product sitemap at eighty percent indexation alongside an article sitemap at thirty percent tells you exactly where to focus, which beats staring at site wide totals. Our XML sitemap best practices for faster indexing walks through file splitting and lastmod discipline with examples you can mirror in your sitemap function.

Robots control and redirects close the loop. Serve robots.txt from code so staging rules never leak to production, and keep its disallow list minimal. Blocking filter parameters, internal search, cart, and preview paths is normal. Blocking JavaScript bundles, stylesheets, or API routes that rendering needs is not, so audit every disallow against what the rendered page requests. Handle locale and trailing slash redirects with single hop permanent redirects, and test redirect chains from sitemap URLs to final landing URLs. A sitemap that lists URLs which immediately redirect teaches crawlers to distrust the sitemap, which slows discovery of genuinely new pages. After every routing change, crawl a sample of sitemap URLs and confirm one hop at most, correct canonical on landing, and matching metadata between sitemap entry and page.

Data fetching pitfalls that delay indexing

Most Next.js index delays trace back to data fetching, not to Google. The page looks fine in development with warm caches and fast local APIs, then slows down in production where every render fans out to CMS, commerce, reviews, and personalization services. The crawler experiences the slow production path, adjusts its request rate downward, and discovery stalls. The remedy is to fetch less on first paint, cache more between renders, and isolate slow sources so they cannot block the indexable core. Treat every upstream call on an indexable template as a liability that must justify its place in the critical path.

The most common pitfall is fetching personalized or secondary data inside the same server function that builds the main content. When the reviews service slows down, the whole product page slows down, including title, description, and body that were ready in milliseconds. Restructure templates so the indexable core renders from fast cached sources while secondary modules stream in through suspense boundaries with graceful fallbacks. Set explicit timeouts on every upstream call, and design fallbacks that still produce a complete indexable page, such as cached review counts instead of live review lists. Log upstream latency per dependency per route, and set alerts on the dependencies that sit on your most crawled templates. Fixing one slow dependency on a category template often lifts crawl speed across hundreds of thousands of URLs at once.

Cache configuration mistakes come second. Teams either cache too little, so every crawl request hits the origin database, or cache too much, so editors complain that changes never appear and respond by disabling caching entirely. Both extremes hurt indexing. The middle path is layered caching with clear ownership: framework data cache for shared lookups within a render, route or page level caching with short lifetimes for anonymous HTML, CDN caching for static and revalidated responses, and upstream response caching for slow CMS queries. Document the lifetime at each layer per content group, and expose a safe purge path for editors that clears specific URLs instead of the whole cache. When editors trust targeted purges, they stop demanding global no cache rules that silently destroy crawl performance.

A third pitfall is client side data that never reaches the server HTML. Price, availability, article body, or job details loaded only in browser effects may appear to users while remaining invisible in the first server response. For indexable content, that is a defect, not an optimization. Move indexable facts into server fetched props or server components, and reserve client fetching for interactive widgets that do not affect index identity. Verify by diffing raw HTML against rendered DOM for word count and link count on every template that mixes server and client data. If the raw HTML carries fewer than eighty percent of the visible words, restructure before worrying about sitemaps or internal links. For general background on how discovery interacts with crawl capacity, our sitemap automation guide on syncing new URLs automatically pairs well with this section, because fast server data plus accurate sitemaps is the combination that shortens time to index.

nextjs indexing diagram: ssr setup that indexes, isr and revalidation without, data fetching pitfalls that

Fixing Nextjs indexing gaps with logs and Search Console

Measurement turns rendering choices into index results you can defend. Start with Search Console coverage and page indexing reports split by content group, not site wide. Track valid indexed URLs, crawled but not indexed, discovered but not indexed, and alternate canonical warnings per sitemap file. A healthy Next.js section shows steady valid growth after launches, low discovered counts that clear within two weeks, and near zero alternate canonical surprises. When discovered counts stay high for a month, the problem is usually crawl capacity or weak internal links, not rendering. When crawled but not indexed stays high, the problem is usually thin server HTML, slow responses, or unstable canonical tags. That split tells you whether to fix links and sitemaps or to fix templates and data.

Add server side evidence to confirm. Parse CDN and origin logs for Googlebot requests by URL pattern, response time, status code, and cache hit ratio. Chart median and 95th percentile response times for your most crawled templates, and compare cache hit ratios between crawler and user traffic. Crawlers often hit deeper pagination and older content with colder caches, so their experience is worse than synthetic monitoring suggests. When log data shows crawler response times double user times on the same template, add edge caching or warm up routines for deep pages. When logs show repeated 500 errors or redirect chains on sitemap URLs, fix those before any content work, because error patterns suppress the crawl rate that everything else depends on. Keep a weekly log summary with one row per route group so trends are visible without digging through raw files.

Time to index is the metric that ties it together. For each launch batch, record publish time, first crawler visit from logs, and first indexed appearance from Search Console or site queries. Compute medians per content group and watch them over months. A docs site might index new pages in two days, a large store in six, a news section in minutes. The absolute number matters less than the trend and the spread. When medians drift upward while content quality holds steady, suspect latency regressions, cache changes, or middleware added without crawl review. When only one group slows down, suspect its template or data source. Share this table with engineering and editorial teams so indexing becomes a joint operational metric instead of an SEO mystery. Teams that track time to index catch template regressions in the same sprint, not the next quarter.

Fix gaps with a short ordered routine. First confirm the URL returns 200 with complete server HTML, self referencing canonical, and indexable robots directives. Then confirm it appears in the correct sitemap file with an accurate lastmod value and that the sitemap index is submitted and readable. Persistent nextjs index issues often trace to mixed signals where ssg vs ssr seo choices differ by route without documentation, so record the rendering mode per pattern before changing templates. Then confirm at least one crawlable internal link from an indexed page, preferably from a listing or hub page the crawler visits often. Then check that middleware, geolocation, or consent walls do not alter the response for anonymous requests. Work this list in order for every sample URL before changing templates, because most gaps close at step one or two. For stubborn patterns where Google discovers pages but never crawls them, our guide on why discovered pages stay unindexed gives the full diagnostic path with fixes ordered from quickest to most structural.

FAQ

Does Google prefer SSR, SSG, or ISR for Next.js sites?

Google does not prefer a mode by name. It prefers fast, complete, stable HTML with clear metadata and links. Static generation usually delivers that with the least operational risk, timed revalidation matches scheduled catalogs well, and server rendering fits fast changing or personalized pages when latency stays low. This is the core lesson of any practical nextjs seo guide for teams choosing modes by change frequency: verify with raw fetch and rendered tests. For broader rendering context beyond App Router, review a dedicated next.js seo indexing reference alongside your nextjs rendering seo checklist so server and client behavior stay aligned.

Why are my Next.js pages crawled but not indexed?

The usual causes are thin server HTML where content loads only in the browser, slow responses that suppress recrawls, unstable canonical tags across variants, or weak internal links that signal low priority. Compare raw HTML to rendered DOM for word and link counts, check response times in logs, confirm one canonical per URL, and add links from frequently crawled hubs. When the same template serves both queued and instant routes, confirm nextjs googlebot sees consistent headers across variants before rewriting content.

How do I handle paginated and filtered Next.js listings?

Give each paginated page a distinct title and description with its page number when the series deserves indexation, link pages in sequence, and keep self referencing canonical tags. For filtered views with little search value, canonicalize back to the primary listing and avoid broad noindex rules that can leak onto primary templates through shared components.

Should middleware redirect or rewrite locale and trailing slash variants?

Use single hop permanent redirects to one canonical form, keep the rule set small, and exempt sitemaps, robots.txt, and static assets from application middleware. Test every sitemap URL for chain length, because chains of two or three redirects quietly burn crawl budget on large sites.

How often should ISR revalidate for a product catalog?

Base the interval on measured CMS change frequency, roughly half the median time between meaningful edits for that content group. Use time based revalidation for predictable rhythms and on demand revalidation for event driven changes such as price or stock updates, with debounced grouped calls during bulk imports.

What is the fastest way to confirm a Next.js fix worked?

Pick ten sample URLs, record their status code, server HTML word count, canonical tag, sitemap membership, and internal referrer before the change. Redeploy, purge affected caches, revalidate where needed, then recheck the same fields plus log evidence of fresh crawler visits. When all ten pass and logs show fast 200 responses, expand the rollout to the full group.

Sources

https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Next.js and Indexing: SSR, SSG, and ISR Explained