IndexNow Cloudflare Workers Setup: Auto-Ping Bing on Publish

I’d been manually pasting URLs into Bing Webmaster Tools every time I published a post, which is exactly as tedious as it sounds. IndexNow Cloudflare Workers automation fixes that by pinging Bing (and Yandex, Seznam, Naver, and a few others) the moment new content goes live, without you touching a dashboard.

So here’s the plan: get your IndexNow key verified, build a small Worker that submits URLs automatically, and wire it to fire on publish instead of running it by hand.

Quick Answer

• Generate an IndexNow key, host it as a plain text file at https://yourdomain.com/{key}.txt.
• Send a GET or POST request to https://api.indexnow.org/indexnow with your URL and key — this single endpoint distributes to all participating search engines.
• A Cloudflare Worker can hold your key as a secret and submit URLs automatically when triggered by a webhook, cron, or your CMS.
• Don’t put the raw key in client-side JavaScript — keep it server-side in the Worker, not exposed in a browser request.
• Use Workers KV to track which URLs you’ve already submitted, or you’ll end up re-pinging the same pages every run.

Why This Setup Goes Wrong

Most of the failures here aren’t really about IndexNow itself — they’re about the small details around key hosting and host matching.

Key file hosting is the single most common point of failure. The key file has to live at the root of the domain you’re submitting URLs for, and it has to return a plain text response with exactly the key string, nothing else — no HTML wrapper, no extra whitespace, no trailing newline issues from some static site generators. If your key file returns a 404, or your CMS serves it with a content-type that confuses the validator, the submission silently fails or comes back with an error you won’t immediately understand.

Host mismatch between the key location and the submitted URL. If your key file is hosted at example.com/abc123.txt but you’re submitting URLs for blog.example.com, that’s a different host as far as IndexNow’s validation is concerned. This trips people up on sites with a subdomain blog or a staging-to-production domain switch they forgot about.

Exposing the key in client-side code. It’s tempting to just fire a fetch request straight from your CMS’s frontend JavaScript on publish. Don’t — anyone with browser dev tools open can grab your key and spam submissions under your domain, which can get your key flagged or your domain’s IndexNow access throttled.

Cloudflare Workers’ execution model catching people off guard. Workers are stateless and short-lived by default. If you’re trying to batch up a bunch of URLs and submit them in one go without using KV or Durable Objects to track state between invocations, you’ll lose that state between runs and either re-submit duplicates or miss new ones entirely.

How IndexNow Submission Actually Works

There are two ways to submit, and picking the wrong one for your use case is a common unforced error.

For a blog publishing one or two posts at a time, the single-URL GET is honestly fine. If you’re doing a bulk migration or backfilling old posts, the bulk POST saves you a lot of round trips.

Step-by-Step Setup

Step 1: Generate and host your IndexNow key

Generate a random string, 8 to 128 characters, alphanumeric and hyphens only. You can use Bing’s key generator on the IndexNow site, or just run something like this locally:

bash

openssl rand -hex 16

Host that exact string as plain text at https://yourdomain.com/yourkey.txt. If you’re on WordPress, drop a static file in the site root via FTP or your hosting file manager — don’t route it through a PHP template that might add whitespace or headers you didn’t intend.

Step 2: Create a new Cloudflare Worker

bash

npm create cloudflare@latest indexnow-worker
cd indexnow-worker

Pick the “Hello World” Worker template when prompted, then open src/index.js.

Step 3: Store your key as a Worker secret, not in the code

bash

npx wrangler secret put INDEXNOW_KEY

Paste your key when prompted. This keeps it out of your repo and out of the deployed source, which matters if this repo is ever public.

Step 4: Write the submission logic

javascript

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    const { url } = await request.json();
    if (!url) {
      return new Response("Missing url", { status: 400 });
    }

    const host = new URL(url).hostname;
    const key = env.INDEXNOW_KEY;
    const keyLocation = `https://${host}/${key}.txt`;

    const submitUrl = `https://api.indexnow.org/indexnow?url=${encodeURIComponent(url)}&key=${key}&keyLocation=${encodeURIComponent(keyLocation)}`;

    const response = await fetch(submitUrl, { method: "GET" });

    return new Response(
      JSON.stringify({ status: response.status, ok: response.ok }),
      { headers: { "Content-Type": "application/json" } }
    );
  }
};

Step 5: Deploy and grab your Worker URL

bash

npx wrangler deploy

You’ll get a URL like indexnow-worker.yourname.workers.dev. That’s the endpoint you’ll call from your publish workflow.

Step 6: Wire it to fire on publish

This is the part that varies most depending on your CMS. For WordPress, the cleanest route is a small functions.php hook that fires on publish_post or transition_post_status, sending a POST to your Worker URL with the post’s permalink. For a static site generator, this usually fits better as a step in your build/deploy pipeline instead of a webhook — fire it right after deploy completes, looping over whatever’s new in that build.

What Actually Worked For Me

My first attempt just had the Worker hit IndexNow directly with no error handling, and it looked fine in testing — until I noticed posts weren’t actually showing up faster in Bing’s index. Spent a while assuming the Worker itself was broken, checked logs, redeployed twice. Wasn’t that.

Turned out my key file was being served by a caching plugin that added a Content-Type: text/html header instead of text/plain, and IndexNow’s validator apparently cares about that more than I expected — not 100% sure why it’s that strict, but it is. Found this by accident, actually, while checking the response headers in browser dev tools for something unrelated, and noticed the mismatch. Bypassed the cache plugin for that one static file, confirmed text/plain came back, and submissions started actually getting acknowledged with the right response codes after that.

And so the lesson, which feels almost too simple in hindsight: don’t just check that the key file loads — check the actual headers it’s served with.

Advanced Fixes and Edge Cases

Deduplicating submissions with Workers KV. Without this, a cron-triggered Worker checking your sitemap will re-submit every URL every run, which wastes calls and can look like spam behavior to the API. Store submitted URLs with a timestamp in KV, and skip anything submitted in, say, the last 24 hours:

javascript

const alreadySubmitted = await env.SUBMITTED_URLS.get(url);
if (alreadySubmitted) return;
await env.SUBMITTED_URLS.put(url, Date.now().toString(), { expirationTtl: 86400 });

Cron Triggers for sitemap-diff submission. Instead of relying on a CMS webhook, a Worker on a Cron Trigger (e.g. every 30 minutes) can fetch your sitemap.xml, compare against what’s stored in KV, and submit only what’s new. This is more resilient than webhook-based triggering since it doesn’t depend on your CMS firing the hook correctly every time.

Debugging via wrangler tail. If submissions seem to silently vanish, run npx wrangler tail while triggering a test publish — it streams live logs from the deployed Worker and will usually surface the actual HTTP status IndexNow returned, which is more useful than guessing.

Rate limiting on your end. IndexNow doesn’t publish a hard documented rate limit for normal usage, but submitting the same URL repeatedly in a short window can get throttled. If you’re backfilling hundreds of old URLs, space the bulk POST batches out rather than firing them all in one loop.

Prevention Tips

• Test your key file’s headers directly with curl -I https://yourdomain.com/yourkey.txt after any caching or CDN config change — caching layers are the most common thing that silently breaks this later.
• Keep the key as a Worker secret, never commit it to a public repo.
• Log submission responses somewhere you’ll actually check, even just a simple KV counter, so a silent failure doesn’t go unnoticed for months.
• Re-verify host matching any time you move content between subdomains or migrate hosting.

FAQ

Do I need a Cloudflare Worker at all, or can I just call the API directly from my server? You don’t strictly need a Worker — any server-side environment that can make an HTTP request works. Workers are convenient if you’re already on Cloudflare or want a lightweight, fast-deploying endpoint without managing your own server.

Does IndexNow guarantee faster indexing? No, it speeds up discovery, not ranking or guaranteed indexing. Bing still applies its own quality and crawl decisions after discovery.

Can I use the same key for multiple domains? Generally each domain needs its own key file hosted on that domain, even if you reuse the same key string across them.

Why does my submission return 200 but the page still isn’t indexed days later? A 200 just confirms IndexNow received and validated the submission — it doesn’t mean Bing decided to index the page. That’s a separate, slower process.

Is this worth setting up for a small blog, or is it overkill? From what I’ve seen, it’s worth it mainly if you publish frequently. For a blog posting once a month, the manual Bing Webmaster Tools submission is honestly just as fast.

Editor’s Opinion

This is one of those setups that takes longer to get right than it looks like it should, mostly because of header and caching gremlins that have nothing to do with IndexNow’s actual API. Once it’s working it’s genuinely “set and forget” though, and way better than remembering to manually submit every post. Don’t skip the KV dedupe step if you’re going the cron route — learned that one by watching my submission log fill up with the same five URLs over and over.