If a Next.js page is missing from Google, start with the affected URL and its Search Console status. The cause may be access restrictions, an indexing directive, a rendering failure, a conflicting canonical, or a page Google has not selected for indexing. The checks below help identify which condition applies to your page.
The framework examples use the App Router. For a Pages Router project, follow the same diagnostic sequence but inspect the metadata and routing implementation used by that project.
A page that is indexed but ranks poorly has a different problem from a page excluded from the index. Confirm the indexing state before treating low visibility as a technical exclusion.
1. Record what Google reports
Inspect an affected URL in Search Console. Record its indexing status, last crawl date, fetch result, and declared and Google-selected canonicals where available. Compare it with a working page using the same template.
The indexed report reflects Google's stored information. Test live URL checks the current page; it does not establish Google's canonical selection or guarantee indexing. Compare test and deployment timestamps before concluding that a fix failed. Google's URL Inspection documentation explains the distinction.
| Reported condition | First question to investigate |
|---|---|
| Blocked by robots.txt | Should this public URL be crawlable? |
| Excluded by noindex | Is an indexing restriction left over from staging? |
| Page with redirect | Is this an old address correctly pointing to its replacement? |
| Duplicate or alternate page | Is Google choosing the intended canonical? |
| Discovered, currently not indexed | Can Google reach the page through useful internal links, and is the server reliable? |
| Crawled, currently not indexed | Is the page useful and distinct, and does the fetched content match the intended page? |
2. Check the HTTP response and redirects
Request the exact public URL without being logged in. Check its status, redirect path, and final destination. A valid page should return its intended content, not a login screen or an error message disguised as a successful response.
A 308 is a permanent redirect, not inherently an indexing error. Fix loops, unintended destinations, and broken targets. Investigate persistent server errors and pages that return 200 while showing missing-content messages. Use Google's HTTP status guidance when interpreting responses.
3. Check robots.txt and unexpected noindex directives
Check production robots.txt, the page's robots meta tag, and the X-Robots-Tag response header. Check the deployed response, not just repository settings: hosting rules can add headers too.
A crawl block and noindex do different jobs. Google needs access to a page to see its noindex instruction. A missing robots.txt file is not itself evidence that crawling is blocked. Remove accidental restrictions on public pages; keep private staging environments protected. See Google's robots.txt introduction and noindex guidance.
Search Console says noindex, but it is not in your code
Compare the report's crawl date with the deployment you are checking. Inspect the deployed HTML and response headers for the exact affected URL, including hosting-level settings. Code search alone cannot establish what Google previously received. If the current response differs, verify that change in a live test and monitor the next crawl. Sparse initial HTML does not itself create a noindex directive.
In the App Router, also inspect branches that call notFound(). Next.js adds a robots noindex tag when that function runs. A failed CMS lookup or incorrect slug can therefore produce a directive that nobody explicitly wrote into the page metadata. Fix the data or routing condition if the page should exist; keep the not-found behavior for genuinely missing pages. If streaming has already started, the response can retain a 200 status, so the status alone is insufficient. See the Next.js notFound reference.
4. Check what renders beyond the loading screen
Examine the response HTML, the browser-rendered page, and the available HTML and resource diagnostics in Google's inspection tool. Look for the main heading, meaningful body content, and links.
Google can render JavaScript. Sparse response HTML alone does not prove that Google sees an empty page. If important content is missing from Google's rendered result, investigate failed requests, unavailable resources, authentication, and content that requires user interaction. Google's JavaScript SEO guide describes this processing.
In Next.js, 'use client' does not automatically mean "no server-rendered HTML". Client Components can participate in the initial server-rendered preview. Inspect components that disable server rendering or fetch essential content only after mounting, and verify the actual output before changing architecture. See Server and Client Components.
5. Check route metadata and canonical URLs
Check the canonical emitted for each affected route. Look for preview domains, obsolete paths, and a root canonical accidentally inherited by unrelated pages. Compare canonical signals with redirects, internal links, and sitemap URLs.
For App Router metadata, metadataBase supplies a base for URL fields. It does not create the intended canonical on its own: define alternates.canonical for the appropriate route and inspect the output. The Next.js metadata reference shows these separate settings.
If metadata appears missing from the initial <head>, check whether your Next.js version uses streaming metadata. With this feature, tags from generateMetadata can arrive later in the response. Next.js documents support for Googlebot inspecting the full DOM. Inspect the completed output and Search Console result before treating placement alone as a failure or disabling streaming.
Google can select a different canonical from the one you declare. Resolve conflicting signals rather than assuming the tag is a command; see Google's canonical guidance.
Example: an article points to the homepage canonical
Consider a hypothetical article at https://example.com/blog/widget-guide with its own substantial content. It returns 200 and renders correctly, but its canonical points to https://example.com/.
| Check | What to establish |
|---|---|
| Inspect the article output | Does the emitted canonical point to the homepage? |
| Inspect the route and parent layouts | Is a shared homepage canonical being inherited? |
| Compare another article | Is this a template issue or one route's metadata? |
| Correct the route metadata | Does the article now identify its intended canonical URL? |
| Check after deployment | Do the rendered canonical, internal links, and sitemap agree? |
For a static article route in the App Router, the relevant metadata can be as small as:
```tsx import type { Metadata } from 'next'
export const metadata: Metadata = { alternates: { canonical: 'https://example.com/blog/widget-guide', }, } ```
Replace the example domain and path with the intended public URL. Dynamic routes need a canonical derived from the actual route; do not copy this fixed URL into a shared layout.
This example identifies a conflicting signal to correct. Only a later indexed report can show Google's subsequent canonical choice; the code change does not establish that indexing has recovered.
6. Check discovery and the page's purpose
Link important pages from relevant public pages using ordinary crawlable links. Keep the sitemap aligned with the canonical URLs you want indexed. Submitting a sitemap is not proof that those pages will be indexed.
For App Router sites, inspect the deployed output of app/sitemap.ts and, if used, app/robots.ts. Check for preview hosts, removed routes, and missing published CMS entries. Creating these files is not a substitute for checking the URLs they return.
Then review the content itself. Does the page answer a distinct question, or repeat another service page with a different heading? Is it a complete page, or an empty CMS entry? If access, rendering, and canonicals are correct, another technical setting may not solve the problem.
For a young site, prioritize a coherent set of useful pages over publishing many near-duplicates. This is an editorial decision to investigate alongside the technical evidence, not a diagnosis based only on domain age.
7. Verify the fix and leave a record
After deployment, repeat the affected checks. Record the URL, old condition, change, deployment time, and live-test result. Request indexing where appropriate, then monitor the indexed report after another crawl. Repeated requests do not guarantee inclusion or a particular timeline.
For template-level issues, test more than one route, including a working comparison page. A homepage fix does not prove that product, article, and locale routes are correct.
What to send a developer for an indexing diagnosis
Share affected URLs, Search Console statuses and crawl dates, the date the issue appeared, and recent deployment or migration changes. Screenshots help, but exact URLs and response details make the investigation actionable. Do not share passwords or private tokens in a public issue.