The IndexNow key

When you publish, Geoffy pings the search engines that support IndexNow — Bing and Yandex among them — so your new content is fetched in minutes rather than whenever a crawler next comes past.

IndexNow proves you own what you are submitting by fetching a key file from your own host. The key authorises only the directory it sits in. That one sentence is the whole reason this page exists.

What the namespace covers, and what it does not

Mounting the Geoffy namespace serves the key at /apps/geoffy/{key}.txt. That authorises everything under /apps/geoffy/: your buying guides, the plain-text product twins, and the Geoffy sitemap.

It does not authorise your product pages. Those live at your own template path — /products/whatever — which is outside that directory. So without the step below, every product-page ping is discarded.

This failure is completely silent

Nothing errors, nothing 404s, and no dashboard field turns red. The submission is accepted by our side, rejected by the engine's ownership check, and dropped. The only symptom is that your product pages are indexed slowly, which looks like normal crawl latency. Do this step even though nothing will complain if you skip it.

Serve the key at your root

You own your filesystem, so this is one static file. Your site's settings in Geoffy show your IndexNow key. Save it as a file named after itself, at your site root:

public/{key}.txt

So a key of a1b2… becomes public/a1b2….txt, served at https://yourdomain.com/a1b2….txt. The file's only contents are the key itself.

The filename is the key, and that is on purpose

It looks odd, and it is IndexNow's design rather than ours: serving a file whose name is the key is how you prove to a search engine that you control the host you are submitting URLs for.

This file is meant to be public — that is the mechanism

It is not a credential, and treating it as one is how this breaks. A search engine reading the file is precisely how your domain is proved, so it has to be readable by anyone. Do not put it behind authentication, a login wall, a geo rule or a bot filter: a 401, a 403 or a challenge page there fails the ownership check exactly as a missing file would, and just as silently.

It is also not worth protecting. The key only ever says "recrawl these pages on this domain", and the engine then reads whatever your pages already say — there is nothing to inject, remove or redirect. It is useless on any other host, since an engine offered it elsewhere fetches the file there and finds nothing. And every site gets a different key, so yours reveals nothing about anyone else's.

Check it

curl -s https://yourdomain.com/{key}.txt

It must return the key and nothing else. A catch-all route answering with your home page and a 200 fails the ownership check exactly as a 404 would, so read the body rather than the status.

Next.js specifics

public/{key}.txt is served at your site root by Next’s static file handling, with no route and no configuration. That is all this needs.

Do not reach for a route handler here. A app/[key].txt/route.ts would work, but the filename is your key, so the route would either hardcode a secret-looking value in your repository or fetch it on every request. A static file in public/ is the right shape.

If your deployment does not serve public/ at the root — some custom servers and some edge configurations do not — check with:

curl -s https://yourdomain.com/{key}.txt

The body must be the key and nothing else.