How to Fix Indexing Issues in Nuxt

Google crawled your page but hasn't indexed it. The Page indexing report supplies statuses. A status alone may not explain the cause; inspect the affected response and content.

Understanding Page Indexing Status

Search Console’s Page indexing report lists indexing states and exclusion reasons. See the full list for every reason. Start with crawled-not-indexed, discovered-not-indexed, and the excluded statuses below.

Indexed: your page is in Google's index. This is a prerequisite for appearing in AI Overviews, which cite from the same index Google Search uses rather than a separate crawl.

Discovered - currently not indexed: Google found your page, often via your sitemap, but hasn't crawled it yet.

Crawled - currently not indexed: Google crawled your page and chose not to index it.

Excluded by robots.txt: your robots.txt file blocks Google from accessing the page. Crawl blocking can prevent fetching content or metadata. A linked blocked URL can still appear in search without its content.

Blocked by noindex tag: the page has a noindex meta tag, so Google won't index it or use it as an AI Overviews source.

Duplicate without user-selected canonical: Google identified a duplicate without a user-selected canonical preference. It may choose a canonical automatically.

Soft 404: the page returns a 200 OK status but reads like a "not found" page to Google. Return a real 404 for missing content instead.

Fixing "Crawled - Currently Not Indexed"

Google does not expose a specific cause for every crawled-not-indexed URL. Compare the affected pages, response states, and reported canonicals before selecting a repair.

Thin or Low-Quality Content

Inspect whether the page provides useful, original content. An indexing state alone does not prove a quality problem. AI features require an indexed page eligible to show a snippet.

Fix: add substantial, original content. Use Schema.org to describe the page's purpose to both crawlers and LLMs.

Duplicate Content

Duplicate URLs can consume crawling resources; Google may consolidate equivalent versions automatically. See the Duplicate Content guide for a full detection and resolution workflow.

Fix: implement canonical tags pointing to the primary version:

<script setup lang="ts">
useHead({
  link: [
    { rel: 'canonical', href: 'https://yoursite.com/primary-page' }
  ]
})
</script>

Too Many Similar Pages

Compare variant content before deciding whether it is equivalent or distinct. Consolidate equivalent URLs with consistent canonical signals. Use noindex for exclusion, and keep pages crawlable so Google can read their metadata. Do not blanket-exclude all filters or query URLs.

Poor Internal Linking

Crawlable links help Google discover pages and help readers navigate. Missing links are worth repairing, but do not prove why Google declined to index a URL. See the internal linking guide.

Low Site Authority (E-E-A-T)

Do not infer a trust score or a stricter indexing threshold from this status. Build useful content and relevant relationships for readers. See the backlink guide for supported approaches.

Fixing "Discovered - Currently Not Indexed"

Site Too New

Google publishes no fixed timeline for crawling new sites. A new domain alone does not establish the cause of an indexing delay.

Fix: submit your sitemap, request indexing for critical pages via URL Inspection, and keep publishing regularly.

Crawl Budget Issues

Google's crawl-budget guidance targets sites with 10,000+ pages updated daily, or 1M+ pages updated weekly, though it calls these rough estimates rather than hard thresholds. Server speed affects the budget directly: "if the site slows down or responds with server errors, the limit goes down."

Fix: speed up your server. There's no official crawl-budget millisecond threshold, but web.dev's TTFB guidance puts "Good" at under 800ms. Enable caching, use a CDN, optimize database queries, and monitor response times in Search Console's Crawl Stats report.

Caching public content can improve response reliability. Do not apply shared API caching blindly to authenticated or personalized responses. Follow the rendering guide for deployment-aware cache boundaries.

Choose crawl restrictions from your actual content policy. Keep pages crawlable when Google needs to read canonical or noindex metadata. Authentication protects private routes; robots rules do not. Add useful internal links instead of relying solely on a sitemap.

Verifying SSR in Nuxt

Nuxt renders pages on the server by default, which helps indexing. Verify it's working:

Check the Server Response

For routes needing initial HTML, inspect View Source. Otherwise compare successful rendered output. This command inspects only the initial response:

# Check if content is in server-rendered HTML
curl -s https://yoursite.com/page | grep "expected content"

If your content isn't there, check that:

1. The route has no unintended ssr: false route rule
2. Data fetching uses useAsyncData() or useFetch(), not a client-only method
3. nuxt.config.ts doesn't set ssr: false globally

Verify Data Fetching

<script setup lang="ts">
// CORRECT: data available during SSR
const { data: products } = await useFetch('/api/products')

// WRONG: only loads on client, Google might miss this
// onMounted(() => {
//   (async () => {
//     products.value = await $fetch('/api/products')
//   })()
// })
</script>

Handle Client-Only Content

This template excerpt requires an app-owned LazyProductList component. A loading message does not expose the actual catalog; render useful initial content when discovery requires it:

<template>
  <div>
    <h1>Product Catalog</h1>
    <ClientOnly>
      <LazyProductList />
      <template #fallback>
        <p>Loading 500+ products from our catalog...</p>
      </template>
    </ClientOnly>
  </div>
</template>

Test Rendering Modes

Nuxt supports hybrid rendering. Check your route rules match what each route needs:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    // Static pages (prerendered)
    '/': { prerender: true },
    '/about': { prerender: true },

    // Dynamic pages (SSR)
    '/blog/**': { swr: 3600 },

    // Client-only pages (if genuinely needed)
    '/dashboard/**': { ssr: false }
  }
})

Then confirm what Google sees:

1. Search Console → URL Inspection
2. Enter your page URL, click "Test Live URL"
3. Click "View Tested Page" → "Screenshot"

Compare the screenshot to your actual page. A successful live test shows Google’s tested rendering. Differences can reflect data, timing, resources, or personalization; SSR alone does not guarantee identical screenshots.

AI Visibility Gaps

Indexing does not guarantee an AI appearance. Check eligibility and readability separately; these checks do not diagnose why a page was absent:

• Markup alone does not guarantee AI inclusion. Google requires the same SEO fundamentals for its AI features.
• Check that the site is included in Search generative AI features in Search Console
• Review headings and readable content for people; an absent AI appearance does not prove a formatting problem
• A nosnippet tag: this also blocks the page from AI Overviews, since AI features use the same snippet controls as regular search results

Requesting Re-Indexing

After fixing an issue, request re-indexing via URL Inspection:

1. Search Console → URL Inspection
2. Enter the fixed URL
3. Click "Request Indexing"

URL Inspection checks one URL at a time. To check the index status of up to 50 URLs at once, use the free bulk index checker, which reads the same URL Inspection API.

A crawl request doesn't guarantee inclusion: "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. Our systems prioritize the fast inclusion of high quality, useful content." Google's crawlers also revisit indexed pages on their own to pick up changes, so save manual requests for infrequent, important changes.

Google’s Indexing API only covers JobPosting pages or VideoObject pages containing a livestream BroadcastEvent. Ordinary content uses sitemaps and supported URL Inspection procedures. An app-owned API wrapper with unvalidated arbitrary input is not supplied here.

Google must crawl a page before processing its content for indexing. The reported Google process timings describe separate stages, whose delays can accumulate. A recent fix or accepted request starts no guaranteed indexing countdown.

Monitoring Progress

Track indexing status changes over time:

1. Search Console → Page Indexing
2. Check the "Not indexed" count weekly
3. Look for status changes from "Crawled - not indexed" to "Indexed"

Google re-evaluates pages on its own schedule, not on demand, so there's no fixed timeline for a status change to show up.

Use reported statuses to group investigation. A product integration cannot supply a cause Google does not expose.

Checklist