Fixes Next.js App Router indexing issues: canonical and generateMetadata, noindex leaks, sitemap/robots routes, static rendering, internal linking, and Search Console coverage. Use when a Next.js site wastes crawl budget or shows discovered-not-indexed URLs. Not for site-wide SEO audits of non-Next stacks (seo-audit), schema-markup chairs, or programmatic keyword-page factories.
Fixes Next.js App Router indexing issues: canonical and generateMetadata, noindex leaks, sitemap/robots routes, static rendering, internal linking, and Search Console coverage. Use when a Next.js site wastes crawl budget or shows discovered-not-indexed URLs. Not for site-wide SEO audits of non-Next stacks (seo-audit), schema-markup chairs, or programmatic keyword-page factories.
Fix Google Search Console coverage issues, canonical problems, sitemap errors, and crawl budget waste in Next.js apps. This skill walks through a full seven-step audit covering canonical tags, noindex leaks, sitemap health, static rendering, internal linking, redirects, and robots.txt.
When to Use
A Next.js site shows Google Search Console coverage issues: duplicate canonicals, accidental noindex, crawl waste, or "discovered – not indexed" URLs.
You are auditing sitemap, robots.txt, redirect chains, internal-linking, or static-rendering problems before an SEO release.
You need framework-specific examples for Next.js App Router metadata, generateMetadata, robots.js, and sitemap routes.
A client or stakeholder reports dropped indexed page counts or coverage report regressions.
Prerequisites
Runtime: Node.js 18+ and Next.js 13+ (App Router) project locally.
Access: Codebase read/write access, deployed URL, and ideally Google Search Console property access.
Windows host (primary): Commands below are PowerShell-first. Where a Unix equivalent is useful (e.g., curl on WSL), it is noted. PowerShell aliases: curl maps to Invoke-WebRequest unless curl.exe is explicitly called.
Tools:ripgrep (rg) recommended for fast code search. Install via winget install BurntSushi.ripgrep.MSVC or use Select-String as fallback.
No live secrets: All URLs and keys in examples use yourdomain.com / YOUR_KEY placeholders.
Procedure
Understanding Search Console Coverage States
Before fixing anything, map the Search Console report to the correct state:
In Next.js App Router, robots in the root layout applies globally. Only set it there if you want the whole site affected.
// app/layout.js — only set robots if you need sitewide controlexportconst metadata = {
// ✓ Allow indexingrobots: { index: true, follow: true },
// ❌ This would noindex the entire site:// robots: { index: false }
};
2.3 — Check deployed pages for noindex headers and meta tags:
# Check HTTP headers
curl.exe -sI https://www.yourdomain.com/blog/my-post | Select-String 'x-robots|noindex'
# Check meta tags in HTML
curl.exe -s https://www.yourdomain.com/blog/my-post | Select-String 'noindex'
7.3 — Verify deployed robots.txt matches your config:
curl.exe -s https://www.yourdomain.com/robots.txt
Confirm the output contains Allow: / and the Sitemap: line. If it shows Disallow: on important paths, fix app/robots.js and redeploy.
Pitfalls
Root layout noindex nukes the entire site. A single robots: { index: false } in app/layout.js deindexes every page. Always check the root layout first when indexing drops sitewide.
Relative canonical URLs. Google may ignore canonical: '/blog/my-post'. Always use absolute URLs with consistent scheme and subdomain.
Trailing-slash inconsistency. If some canonicals end with / and others don't, Google treats them as duplicates. Pick one policy and enforce it sitewide.
Dynamic pages without generateStaticParams. Pages marked λ in build output may not render metadata in the initial HTML, causing Google to miss SEO tags.
Redirect chains. A → B → C wastes crawl budget and dilutes link equity. Flatten to A → C. Verify the destination itself does not redirect.
Disallow: on important paths in robots.txt. Even if pages have canonical tags, if robots.txt blocks crawling, Google cannot see the canonical. Never Disallow paths you want indexed.
Sitemap not submitted to Search Console. A valid sitemap at /sitemap.xml does nothing if Google does not know about it. Submit it explicitly.
Orphan pages with zero internal links. Sitemap inclusion alone is not enough. Google prioritizes pages with real internal links. Add contextual links from related content.
Changing URL structure without redirects. If you change slug patterns or domain, add 308 redirects before deploying. Failing to do so causes mass "Not found 404" in Search Console.
Treating "Alternative page with proper canonical" as an error. This is expected behavior — non-preferred duplicates correctly pointing to the canonical. Do not "fix" these.
Verification
Run through this checklist after applying fixes:
All important pages have absolute canonical URLs (https://www.yourdomain.com/...)
No important pages accidentally noindexed (checked root layout + individual pages)
Sitemap routes return HTTP 200 with Content-Type: application/xml
Sitemap submitted to Google Search Console and status is "Success"
Important pages statically generated (● or ○) in npm run build output
No redirect chains (A→B→C flattened to A→C)
robots.txt allows important content (Allow: /, no Disallow on indexable paths)
Every important page has ≥1 internal inbound link
generateStaticParams added for dynamic routes with known slugs
Quick verification commands:
# 1. Canonical check on a live page
curl.exe -s https://www.yourdomain.com/blog/my-post | Select-String 'rel="canonical"'
# 2. Noindex check on a live page
curl.exe -s https://www.yourdomain.com/blog/my-post | Select-String 'noindex'
# 3. Sitemap returns 200
curl.exe -sI https://www.yourdomain.com/sitemap.xml | Select-String '200'
# 4. robots.txt is accessible
curl.exe -s https://www.yourdomain.com/robots.txt
# 5. Build output shows static pages
npm run build 2>&1 | Select-String '○|●|λ'
# 6. No redirect chains
curl.exe -sIL https://www.yourdomain.com/old-url
Limitations
Does not guarantee Google will index a page; final indexing decisions remain with the search engine.
Requires access to the codebase, deployed URLs, and ideally Google Search Console data for confident diagnosis.
Treat recommendations that change URL structure, redirects, or canonical policy as production-impacting and review them before deployment.
Search Console data has a 2–3 day reporting delay. Wait at least 72h before re-checking coverage after fixes.
