IndexNow demands a simple proof of ownership: a {key}.txt file responding at your domain root — https://yourstore.com/a1b2c3….txt — with the key as its only content. Without it, every submission bounces with a 403. On your own server it takes two minutes. On a SaaS platform like Tiendanube, where you can't upload files to the root or touch the server, it looks impossible. It isn't: the solution lives at the network edge.
Cloudflare is the network that speeds up and protects a huge part of the internet; if your store uses a custom domain, your DNS very likely goes through it already. A Worker is a mini-program that runs on Cloudflare's servers, before traffic reaches your store. You can tell it: "when someone requests exactly this URL, answer it yourself; let everything else through".
That turns the impossible problem into a trivial one: the key file doesn't need to exist on your store — Cloudflare answers it for you.
A first instinct is hardcoding the key in the Worker's code. It works, but breaks elegantly: if the key ever rotates (reinstall, migration), you have to edit Cloudflare again. Our approach removes that maintenance forever:
yourdomain.com/{key}.txt and its www variant. Mind Cloudflare's restriction: the wildcard is only allowed at the end of the path, so a pattern like /*.txt is rejected. The broad alternative is yourdomain.com/*, which survives a key rotation but sends all your site's traffic through the Worker.robots.txt and everything else pass through untouched.text/plain. If the key rotates tomorrow, the Worker serves the new one with nobody touching anything.Cost: zero. The free Workers plan includes 100,000 daily requests and this URL gets a handful of search-engine visits per week.
During a real store's onboarding we hit a ghost: the Worker perfectly configured, correct routes, and the root domain returning 404 while www worked flawlessly. The cause, invisible in any tutorial: the root domain had A records pointing straight to the platform's IPs. With that setup, Cloudflare routes apex traffic directly to the platform's SaaS infrastructure (which also uses Cloudflare) and your own zone — Workers included — gets bypassed, even though the proxy shows as active.
The fix is surgical: replace those A records with a proxied CNAME @ → yourstore.mitiendanube.com (as www usually is). The change is instant, reversible, and the store keeps serving exactly the same — but traffic now flows through YOUR zone and your Workers run. If your key verifies on www but not on the bare domain, you know where to look. The rest of the Cloudflare configuration that weighs on your visibility — cache, firewall, AI bots — is covered in our technical guide to Cloudflare for SEO and GEO.
Everything above can be configured manually in 10-15 minutes if you're comfortable with Cloudflare (and if you're not, start with the jargon-free setup guide). IndexNow Connect turns it into a checklist: the built-in guide uses your real domain and key, shows screenshots of every Cloudflare screen (with the exact buttons), gives you the ready-to-paste snippet, diagnoses live what your domain is responding — including the A-records case — and verifies the key automatically once everything is in place.
No. With scoped routes the Worker only runs when someone requests the key file; the rest of your traffic never touches it — and that URL gets a handful of search-engine visits per week.
No: the free plan includes 100,000 Worker requests per day, thousands of times more than that URL will ever consume.
Nothing: the architecture is key-agnostic. The Worker looks up the current key on every request, so a rotation (reinstall, migration) never requires touching Cloudflare.
Yes, as long as your domain uses Cloudflare for DNS: the requirement is being able to create the Worker route on your zone. The live diagnosis in IndexNow Connect tells you whether your domain is ready.
Connect your store for free → — the free plan includes the full guide and 500 URLs per month.