Next.js Page Visible in the Browser but Missing From Google

01

Preconditions

Identify the exact stack before changing code.

Record the Next.js version; App Router or Pages Router; deployment platform and adapter; route path and dynamic parameters; rendering mode; middleware or proxy behavior; final HTTP status; initial HTML; rendered HTML; canonical, robots, title, and description; sitemap and robots output; and deployment and cache timestamps.

Do not use the local development server as proof of production behavior. Production rendering, caching, environment variables, and edge routes can differ.

Check the final response after redirects.

02

Ordered process

1. Fetch the deployed route directly.

Confirm:

• intended status;
• content type;
• no authentication;
• no preview-domain redirect;
• no X-Robots-Tag: noindex;
• no middleware rewrite to a generic shell;
• correct host and path normalization.

A visually working client route can still return a 404, a redirect, or a generic 200 app shell.

1. Inspect the initial HTML.

Search for:

• the unique title;
• main heading;
• primary content;
• canonical;
• robots directives;
• structured data;
• crawlable links.

Next.js supports the static metadata object and dynamic generateMetadata. These exports are supported in Server Components. When metadata can be resolved during prerendering, Next.js includes it in the initial HTML. Metadata and OG images^[1] generateMetadata^[2]

If the metadata exists only after a client effect, the route is bypassing the framework’s strongest search-facing path.

1. Check Server and Client Component boundaries.

A Client Component can render interactive controls. It should not force all primary page data and metadata into a client-only request without a reason.

Inspect whether:

• the page component is unnecessarily marked 'use client';
• public data is fetched only in useEffect;
• the server response contains a loading state;
• a client hook controls whether the main content exists;
• an error boundary hides a server-data failure;
• content depends on browser-only state.

Move stable public content and metadata into server rendering or prerendering where practical. Hydrate interactivity around that output.

1. Verify dynamic metadata.

A dynamic route may use:

export async function generateMetadata({ params }): Promise<Metadata> {
  const product = await getProduct((await params).slug)
  return {
    title: product.title,
    description: product.summary,
  }
}

Check what happens when:

• the fetch fails;
• data is missing;
• the slug is invalid;
• the API requires a private environment variable;
• the route is cached with old data;
• parent metadata merges unexpectedly.

Do not return a generic title for every dynamic page because the metadata fetch quietly failed.

1. Check canonical URL construction.

Use the framework’s metadata fields intentionally and provide a stable public base URL when resolving relative canonical values.

Verify:

• production host;
• HTTPS;
• trailing-slash convention;
• dynamic path parameters;
• locale or market paths;
• no localhost or preview host;
• one canonical tag.

A deployment environment variable that still points to preview can make every page canonicalize away from production.

1. Check robots metadata.

Next.js can generate robots metadata through route metadata and through the app/robots.ts or static robots.txt convention. robots.txt metadata file^[5]

Inspect:

• page-level robots metadata;
• layout defaults;
• environment-specific noindex logic;
• response headers from the host or CDN;
• generated robots.txt;
• whether public routes are accidentally disallowed.

Do not attempt to remove an initial noindex with client JavaScript.

1. Handle missing routes with notFound().

For a missing resource, use notFound() from the server route when appropriate. Next.js documents that notFound() terminates the segment, renders the not-found UI, and injects a noindex robots tag. notFound^[3]

A missing product should not render the normal page shell with 200 and an empty client message. That creates soft-404 risk.

1. Handle moved routes with redirects.

Use a redirect when a real replacement exists. Next.js’s redirect() returns redirect behavior depending on context; ordinary rendering uses a temporary redirect unless a permanent redirect API or routing configuration is chosen. redirect^[4]

Verify the exact production status rather than assuming the function name implies a permanent move.

1. Check data fetching and errors.

Inspect server logs and route output for:

• API 401, 403, 404, 429, or 5xx;
• missing build-time data;
• environment-variable mismatch;
• request timeout;
• stale cache;
• runtime region differences;
• unsupported Node API in an edge runtime;
• partial rendering after a rejected promise.

A client browser may retry successfully while a crawler’s first request receives incomplete output.

1. Verify sitemap generation.

Next.js supports static or generated sitemap.xml metadata files. sitemap.xml metadata file^[6]

Confirm the sitemap:

• lists public canonical routes;
• does not list dynamic routes that return not found;
• uses the production host;
• updates when inventory changes;
• excludes preview, draft, and private URLs;
• returns valid XML.

1. Check caching and deployment identity.

Record the exact release commit and deployment.

Look for:

• stale HTML after code changed;
• stale route data;
• missing revalidation;
• CDN cache serving old robots or canonicals;
• one deployment on the custom domain and another on preview;
• client chunks from a different release;
• immutable assets deleted too early.

A correct repository does not prove the public edge serves the same commit.

1. Compare Google-rendered output.

Google processes JavaScript through crawling, rendering, and indexing. Understand the JavaScript SEO basics^[7]

Use URL Inspection to compare:

• initial and rendered content;
• screenshot;
• loaded resources;
• canonical and robots;
• last crawl;
• current live state.

03

Failure cases

• Everything is a Client Component. Main content exists only after hydration and an API call.

generateMetadata fails silently. Dynamic pages share a generic title.

The canonical uses a preview host. Production pages point away from themselves.

A missing object renders 200. The route becomes a soft 404.

redirect() is assumed permanent. The actual response is temporary.

Robots logic keys off the wrong environment variable. Production inherits preview noindex.

The sitemap lists nonexistent dynamic routes. Google repeatedly fetches errors.

Only local development is tested. Production caching and edge behavior remain unknown.

A stale deployment is inspected. The team debugs code that is not live.

04

Completion criteria

The route is ready when:

• the custom-domain URL returns the intended status;
• initial HTML contains meaningful content and metadata;
• Client Components do not gate the page’s public subject;
• generateMetadata handles data and failure states;
• canonical URLs use the production host;
• robots metadata and robots.txt agree;
• missing resources use real not-found behavior;
• moved resources use the intended redirect status;
• dynamic sitemap inventory matches real routes;
• caches and deployment identity are verified;
• Google-rendered HTML contains the expected page;
• the page has crawlable inbound links.

Once these conditions pass, the page is technically eligible. Indexing and ranking remain separate decisions.

References

Sources behind this record

1. Metadata and OG images — Next.js (accessed July 26, 2026)
2. generateMetadata — Next.js (accessed July 26, 2026)
3. notFound — Next.js (accessed July 26, 2026)
4. redirect — Next.js (accessed July 26, 2026)
5. robots.txt metadata file — Next.js (accessed July 26, 2026)
6. sitemap.xml metadata file — Next.js (accessed July 26, 2026)
7. Understand the JavaScript SEO basics — Google (accessed July 26, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.