Loading…
Loading…
Google's Indexing API returns 200 for every URL you submit, including the ones it will never use. That is the most time-wasting trap in the indexing space.

You publish a post and you want search engines to know about it now. The first question everybody asks: just call Google's Indexing API, right?
No. And the reason is worth knowing, because getting this wrong produces no error at all.
Google's own documentation says that endpoint serves JobPosting and BroadcastEvent embedded in a VideoObject, meaning livestreams. A personal site or an engineering blog is neither.
The trap is that submission still succeeds. Send an ordinary article URL and you get back 200. It looks like it worked. In reality the call sits outside the supported use-cases, Google deprioritises it, and it has revoked API quota from sites doing exactly this. John Mueller restated the scope publicly in 2025: a lot of spammers misuse the Indexing API this way, so the recommendation is to stick to the documented and supported cases.
The old google.com/ping?sitemap= endpoint is not an option either. Google retired it in June 2023.
So for Google the only route is the route Google asks for: a correct sitemap with honest lastmod values.
This site's sitemap uses a fixed STATIC_LASTMOD constant for static pages rather than new Date().
Writing new Date() is easier and looks impressively fresh. What it actually tells a crawler is that every page on the site changed, on every deploy. After a few rounds of that your lastmod field carries no information, and crawlers learn to ignore it. Nobody penalises you. You have simply thrown away a signal.
Bing, Yandex, Naver, Seznam and Yep all take direct submissions. One POST to api.indexnow.org covers them, because it fans the notification out to the other participants. No OAuth, no signup, no quota to manage.
Setup is short enough to be suspicious. You invent the key yourself, 8 to 128 characters of letters, digits and dashes:
openssl rand -hex 16
Put it in an environment variable, redeploy, done. The ownership-proof file appears on its own at /indexnow-key.txt.
This detail made me stop when I first read the protocol. An IndexNow key has to be public: engines must be able to fetch it from your domain to confirm you control that domain. That fetch is the authentication.
So why not name it something public-prefixed and be done?
Because that prefix has a side effect people rarely think about: the value is inlined into the JavaScript bundle shipped to browsers, at build time. Which means rotating the key requires rebuilding and redeploying the entire client. Keep it server-side and rotation is a single environment variable edit. Not a security argument, an operational one.
Two rules I had to learn by getting them wrong.
First, never submit a draft. A draft's page answers 404, and submitting URLs that 404 is the fastest way for a domain to lose standing with this protocol.
Second, a post you just deleted should be submitted. That sounds backwards, but it is the documented way to get a removal noticed: the engine recrawls, receives the 404, and drops the page. Skip it and that URL lingers in results until the next natural crawl, which could be weeks.
Finally, make the call after the response has already gone out to the user. A network round trip to a search engine has no business sitting inside the wait of somebody who just pressed Publish.
No comments yet — be the first!