Guide · Indexing
IndexNow: notifying the engines
By default, an engine discovers your changes on the day it comes back — and it's the engine that picks that day. IndexNow reverses the direction: you announce that an address has changed, instead of waiting. It's an open protocol, it's free, and it comes down to a single file placed at your site root. But you still have to announce what deserves it: this guide tells you what to submit, when to submit it, and what difference it makes.
What the key proves
The mechanism is deliberately simple. A text file placed at the site root contains a key. The submission cites that same key. The engine checks that the file exists at that address and that it matches. That's all: the only action required is to place that file, and the key stands in for an account. What the key proves is your authority over the domain rather than your identity — only someone who can write to the site root can place that file there. Thanks to this proof, the domain remains announceable by you alone.
A single key can serve several domains, provided each one serves the corresponding file. That's what we do for all of the company's domains: one key, one file per domain, and the same procedure everywhere.
What to submit, and when to submit it
The temptation is to announce a lot. Accuracy beats volume. A notification is an assertion: this address has changed. Six rules are enough to make each of these assertions hold true.
01
An address that has genuinely changed
The notification says one thing only: this address has changed since the last visit. It's worth exactly what that fact is worth. So submit the addresses whose text has genuinely moved — a republication with identical text leaves the other pages alone.
Why: A true signal beats silence, and silence beats a false signal: a notification has to be true to carry weight.
02
Addresses open to crawling
The notified engine will read the address the moment robots.txt opens the path for it. So check that the path is allowed: the notification then leads the engine straight to your page.
Why: Lift the block first, announce second. Order matters: the notification invites the engine in, and it's robots.txt that opens the door for it.
03
Pages that request indexing
The "noindex" directive lives in the HTTP header or in the page itself. It often survives a go-live: set during staging, it stays in place until the day someone removes it.
Why: Announce the pages that request indexing themselves: your two signals then say the same thing.
04
The address the page gives itself
When a page's canonical address points to another page, you're asking the engine to keep that other one — so announce that one. The submission concerns the address you declare as primary.
Why: Announce the authoritative address, the one the page gives itself, to the letter.
05
Pages whose response is verified
This is our prerequisite: before announcing, we sample a few pages from the sitemap and check that they do respond with a 200. It's that response that proves a site is live; the served sitemap, for its part, lists what it contains.
Why: A perfectly formed file can list dead addresses. Checking it takes a few seconds, and that's what sends engines to live pages.
06
A notification after go-live
Our publishing flow sends the notification last, once the site is live and verified. The visiting reader then finds the page at the announced address, in its current-day version.
Why: The sequence is simple: publish, verify, announce. In that order, every time.
Two signals that contradict each other
The clearest example is our own. On 27 August 2026, our sitemap declared "modified on 17 August" on six pages out of seven, while IndexNow was telling the engines that those very pages had just changed. The two signals contradicted each other, and our tools validated both: each one, taken alone, was perfectly well formed.
The fix applied to what comes before the announcement. A script now dates the sitemap on a genuine text difference: a page keeps its date as long as its text stays identical. And the announcement goes out afterwards, once the site is live and verified. The lesson fits in one sentence: IndexNow carries far as soon as it rests on signals that are already accurate.
What it changes, and what it leaves in place
What it changes: the engines that support the protocol are notified the moment you publish, instead of finding out on their next visit. You take back control of when the announcement happens.
What it leaves in place: the announcement is addressed to the engines that have adopted the protocol, while Google discovers your changes at its own crawling pace — one more reason to keep an accurate sitemap, which does serve every engine. And the announcement stops there: telling an engine that a page has changed tells it to go read the page again, and leaves the judgement to it. What it reads is still your page: its title, its canonical, its directives, its text.
That is exactly the split SEO Records follows. The module corrects the signals at the moment the page is served, and knows how to notify the engines when a page changes. The option is enabled by you, and the admin shows you exactly what will be sent before you decide — because an announcement you have reviewed is an announcement you control. The module is available from €199 per year.
Verify before announcing
The first four rules above can be read on the page itself. The Checker reads them for you, free of charge, in about ten seconds: it reads your page exactly as it is served, and your site stays exactly yours. The Audit SEO Records goes further: it reads your entire sitemap, page by page, and hands you the dated findings — enough to know what deserves to be announced.