Article Information

Category: Development

Published: April 16, 2026

Author: Chris de Gruijter

Reading Time: 9 min

IndexNow: How I Use It to Get Client Pages Indexed in Minutes, Not Days

Published: April 16, 2026

Every time I deploy a content update for a client, there's always the same silent waiting game: the page is live, but Google hasn't found it yet. For high-frequency content — new blog posts, updated service pages, refreshed landing copy — that gap between "deployed" and "indexed" has real consequences for rankings and traffic. IndexNow is the protocol that eliminates that gap. I've now integrated it across all client sites I manage, and it's become one of those quiet infrastructure decisions that just makes everything sharper. In this post I'll explain what it is, why it matters for SEO, and exactly how I've implemented it for both Next.js and Nuxt projects.

What IndexNow Actually Is

IndexNow is an open protocol, co-developed by Microsoft Bing and Yandex and now supported by Google, that lets you push URL change notifications directly to search engines the moment content is published or updated. Instead of waiting for a crawler to stumble across your updated sitemap, you send a simple POST request to https://api.indexnow.org/indexnow with the list of changed URLs. Bing and Yandex act on it immediately. Google treats it as a strong crawl hint — not a guarantee, but significantly faster than organic discovery.

The protocol requires a key file hosted at the root of your domain (e.g. /<your-key>.txt) to prove ownership. Once that's in place, any authenticated POST from your server is accepted. The key file contains nothing but the key itself — it's lightweight and doesn't affect site performance.

Why It Matters for SEO

There are three concrete SEO advantages to IndexNow that I actually care about in day-to-day agency work:

1. Faster Content Discovery

For client sites that publish new blog posts or location pages regularly, indexing latency is a real problem. I've seen new pages sit un-indexed for 4–10 days on fresh domains, and 1–3 days on established ones. With IndexNow, I consistently see Bing indexing within hours and Google within 1–2 days on most client sites. For time-sensitive content — a promotion page, a news-adjacent blog post, a new service area — that difference is meaningful.

2. Fresher Rankings for Updated Content

Updating existing pages is a core part of the SEO work I do for clients (the agentic SEO system generates these tasks automatically). But there's no point optimising a page if Google re-crawls it three weeks later. IndexNow signals the change immediately, which means ranking adjustments happen in days rather than weeks. For competitive keywords where freshness signals matter, this compounds over time.

3. Reduced Crawl Budget Waste

Crawl budget is finite, especially on larger sites. When Googlebot has to crawl every page on every visit just to discover which ones changed, you're burning budget on unchanged pages. IndexNow lets you tell search engines exactly which pages changed — so crawlers can spend their time on URLs that actually need re-evaluation. For clients with 200–500 page sites, this is a genuine efficiency gain.

How I Implement IndexNow for Next.js Projects

Three client sites — GevelPro, Overbeek, and STS — run on Next.js and deploy to Cloudflare Pages. For these I built a custom TypeScript script that runs at the end of every production build. It's more work than a module install, but the control is worth it.

The Core Idea: Build-Time URL Submission

The script runs as part of the deploy pipeline, after the Next.js build completes. It does two things: detect which URLs have changed since the last deploy, then submit them in bulk to the IndexNow API.

Smart Change Detection via Git Diff

The most useful part of the implementation is the change detection logic. Rather than submitting all URLs on every deploy (which is noise), the script runs a git diff between the current commit and the previous production commit to identify which source files changed. It then maps those file paths to their canonical URLs using the project's route structure.

For example, if data/services/gevelreiniging.ts changed, the script maps that to https://client.nl/diensten/gevelreiniging. Location pages, service pages, and blog posts each have their own mapping logic built into the script.

// Simplified mapping logic — real version handles all route types
function mapChangedFilesToUrls(changedFiles: string[], baseUrl: string): string[] {
  const urls: string[] = [];

  for (const file of changedFiles) {
    if (file.startsWith('data/services/')) {
      const slug = file.replace('data/services/', '').replace('.ts', '');
      urls.push(`${baseUrl}/diensten/${slug}`);
    } else if (file.startsWith('data/blog/') && !file.endsWith('index.ts')) {
      const slug = file.replace('data/blog/', '').replace('.ts', '');
      urls.push(`${baseUrl}/blog/${slug}`);
    } else if (file.startsWith('data/locations/')) {
      const slug = file.replace('data/locations/', '').replace('.ts', '');
      urls.push(`${baseUrl}/${slug}`);
    }
  }

  return [...new Set(urls)];
}

Fallback to Full Route Manifest

Cloudflare Pages uses shallow git clones by default, which means git diff may not have the full commit history available. In that case — or if the diff returns zero results for reasons that don't make sense — the script falls back to reading the full route manifest and submitting all canonical URLs. It's not as precise, but it's reliable.

The fallback detection is simple: if the git command exits with a non-zero code or returns an empty diff on a deploy where files clearly changed (detectable via build output), the script switches modes automatically.

Bulk POST to the IndexNow API

Once the URL list is ready, the script sends a single bulk POST. The IndexNow API accepts up to 10,000 URLs per request, so even a full-site submission fits in one call.

async function submitToIndexNow(urls: string[], siteUrl: string, apiKey: string): Promise<void> {
  if (urls.length === 0) {
    console.log('[IndexNow] No URLs to submit.');
    return;
  }

  const payload = {
    host: new URL(siteUrl).hostname,
    key: apiKey,
    keyLocation: `${siteUrl}/${apiKey}.txt`,
    urlList: urls,
  };

  const response = await fetch('https://api.indexnow.org/indexnow', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json; charset=utf-8' },
    body: JSON.stringify(payload),
  });

  if (!response.ok) {
    throw new Error(`IndexNow API returned ${response.status}: ${await response.text()}`);
  }

  console.log(`[IndexNow] Submitted ${urls.length} URL(s). Status: ${response.status}`);
}

Key File Auto-Generation

The key file needs to be present at the root of the deployed site. For Next.js on Cloudflare Pages, I generate it as part of the build output — the script writes public/<key>.txt with the key as its sole content. Since public/ is served as static files, this just works without any additional routing config.

Wiring It Into the Deploy Pipeline

The IndexNow script runs as a post-build step in the deploy script, after next build completes and before wrangler pages deploy uploads the output. The API key is stored as a Cloudflare Pages secret via wrangler pages secret bulk — same pattern I use for all other build-time secrets — and injected as an environment variable during the build.

# In the deploy script (simplified)
pnpm next build

# Run IndexNow submission with key from env
node scripts/submit-indexnow.mjs

# Deploy to Cloudflare Pages
wrangler pages deploy .next/static --project-name=client-project

How I Implement IndexNow for Nuxt Projects

For Nuxt-based client sites I use the NuxtSEO Pro module (nuxt-ai-ready), which ships with built-in IndexNow support. Configuration is a few lines in nuxt.config.ts and it handles key file generation, sitemap integration, and URL submission automatically on content changes.

This is the honest trade-off: the Nuxt approach is genuinely turnkey. You configure the API key, enable IndexNow in the module options, and it works. There's nothing custom to maintain. The downside is less control — you're submitting based on the module's change detection logic, not your own. For most Nuxt projects that's perfectly fine.

// nuxt.config.ts — NuxtSEO Pro IndexNow config
export default defineNuxtConfig({
  nuxtSeoProConfig: {
    indexNow: {
      enabled: true,
      apiKey: process.env.INDEXNOW_API_KEY,
    },
  },
});

The module handles key file placement at the root route automatically. It also integrates with the Nuxt sitemap module, so any URL that appears in the sitemap can be submitted. For DG Renovaties and KindChiro — both on Nuxt — this setup has been running without issues.

Custom Build-Time vs. Module: When to Use Which

Here's how I think about the choice:

Custom build-time (Next.js approach) — better when you have a well-defined data layer (TypeScript data files, structured route maps), want precise control over which URLs get submitted, and are already managing a CI/CD pipeline with deploy scripts. More setup, more maintenance, more confidence in what you're actually sending.
Module approach (Nuxt) — better when you want to ship fast and the module's defaults match your site structure. Near-zero configuration. Good enough for the majority of content sites where every changed page should be submitted anyway.

For agency work where most client sites follow predictable patterns, the custom approach has paid off — the git diff logic means only genuinely changed pages are submitted, which keeps the signal clean. For simpler one-off projects, the module is the right call.

One Gotcha: IndexNow Is a Hint, Not a Command

Google has been clear that IndexNow submissions are treated as hints, not instructions. They won't index a page just because you asked them to — the page still needs to meet quality thresholds, have decent backlink authority, and not violate any crawl restrictions. I've seen new pages on fresh client domains get submitted via IndexNow and still wait several days before Google indexes them.

Bing and Yandex are more responsive — in my experience, Bing indexes within hours of a valid submission on established domains. For Google, think of IndexNow as eliminating the discovery delay, not the evaluation delay. That's still valuable, but it's important to set accurate expectations.

The Setup Cost Is Low; The Payoff Compounds

The custom Next.js implementation took about a day to build and test across the three client sites. Since then it runs on every deploy with zero maintenance. The NuxtSEO Pro integration for Nuxt projects was under an hour per site. For the SEO work I do — regularly updating and adding content across five client sites — having indexing happen reliably and quickly rather than eventually and unpredictably makes a real difference to how fast rank changes show up after an optimisation.

If you're managing content-heavy sites and not using IndexNow yet, it's one of the lowest-effort, highest-signal SEO infrastructure improvements you can add.

Frequently Asked Questions

Does Google support IndexNow?

Yes, but with caveats. Google confirmed in 2022 that it uses IndexNow submissions as crawl hints — they speed up discovery but don't guarantee immediate indexing. Bing and Yandex are more aggressive about acting on submissions and typically index within hours on established domains.

How is IndexNow different from submitting URLs via Google Search Console?

Google Search Console's URL Inspection tool lets you manually request indexing one URL at a time — useful for occasional requests but not scalable for automated deployments. IndexNow supports bulk submission (up to 10,000 URLs per request) and is designed to be triggered programmatically at deploy time. It also covers multiple search engines with a single API call.

What happens if I submit a URL that hasn't changed?

Nothing catastrophic — the search engine will just re-crawl it and find no meaningful changes. But submitting noisy data (unchanged pages on every deploy) dilutes the signal over time. That's the main reason the git diff-based change detection in the Next.js implementation is worthwhile: cleaner submissions get treated with more weight.

Can I use IndexNow with WordPress or other CMS platforms?

Yes. There are several WordPress plugins that add IndexNow support (Yoast SEO, Rank Math, and others). The protocol itself is CMS-agnostic — you just need to be able to make an authenticated POST request to the API and host a key file at your domain root.

What's the API rate limit for IndexNow?

The public API at api.indexnow.org accepts up to 10,000 URLs per bulk request and the documentation suggests limiting submissions to meaningful change events rather than polling. In practice, per-deploy submission on typical client sites (where deployments happen a few times per week) is well within any practical limits.

Why store the IndexNow key as a Cloudflare Pages secret rather than hardcoding it?

The key isn't sensitive in the way a database password is — it ends up publicly accessible in the key file anyway. But keeping it in the environment via wrangler pages secret bulk is consistent with how all other build-time config is managed, avoids committing it to the repository, and makes rotating it easy if needed.

Does IndexNow affect Core Web Vitals or page performance?

No. The IndexNow submission happens server-side at build/deploy time, not in the browser. The key file is a tiny static text file that has no impact on page load performance. It's entirely off the critical rendering path.