Instant Indexing

Two protocols exist for telling a search engine that a URL is new or changed, and they have almost nothing in common. Google's Indexing API is narrow and reaches Google. IndexNow is wide and reaches everyone else. This page runs both, because a site that wants to be found quickly needs both — and has until now had to buy one of them.

Two engines that fail in opposite directions

That last row is not a stylistic difference. Google's endpoints answer a CORS preflight with Access-Control-Allow-Origin and list authorization among the allowed headers, so a browser can sign and publish with no help from anyone. No IndexNow endpoint sends that header at all, and its bulk form posts JSON, which forces a preflight the endpoint answers with 405 — a browser can fire the request but cannot read a byte of the reply. Without a relay the honest status codes this page exists to show would be unreachable.

The Google tab keeps your key

Every service advertising instant Google indexing calls the same API, and every one of them has you upload a service-account key or connect an account so that their server can hold it. Google does not require that. It is a consequence of how they built theirs.

Here the credential never leaves the machine:

1. Paste the JSON key you downloaded when you created the service account.
2. The page parses it locally and signs a JWT with the Web Crypto API — RS256 over the PKCS#8 private key — entirely inside the tab.
3. That signature is exchanged for an access token at oauth2.googleapis.com/token, Google's own endpoint, scoped to indexing.
4. Each URL is published to indexing.googleapis.com/v3/urlNotifications:publish, four at a time, since there is no bulk endpoint.

collabstool.com sees none of it: not the key, not the token, not the URLs. Close the tab and the key is gone; the Forget key button clears it sooner.

One practical note. The key has to be in PKCS#8 form, which is what Google's console produces, beginning -----BEGIN PRIVATE KEY-----. An older -----BEGIN RSA PRIVATE KEY----- block cannot be imported by the Web Crypto API at all, and the page says that plainly rather than failing silently with a signing error.

Why the owner grant cannot be skipped

Google documents four prerequisites, and the third is the one people skip: add your service account as a site owner. Skip it and the API answers 403 PERMISSION_DENIED — Failed to verify the URL ownership for every URL, one request at a time, spending the day's quota to produce the same message 200 times.

In Search Console, open the property for the site, then Settings → Users and permissions → Add user. Paste the service account's email address — it ends iam.gserviceaccount.com — set the role to Owner, and save. Give it a few minutes to propagate.

There is no route around this, and it is the reason the whole category cannot be a genuine one-click service: if any caller could demand a crawl of any domain, the API would be a denial-of-service tool aimed at every website on the internet. A service that promises instant Google indexing without ever asking for that grant is doing one of three things — submitting to Bing and calling it Google, adding fake job-posting markup to your pages to unlock an API path never meant for them, or nothing at all. The second is a structured-data violation with a manual action attached, and it risks every other page on the domain.

Who reads an IndexNow submission

Bing is the entry worth pausing on. Its own search share is modest, but its index is licensed across a long tail of other surfaces, so a page that reaches Bing appears in places nobody thinks of as Bing. One request goes to the shared endpoint and is passed on to all of them.

Bing and Yandex published the protocol in 2021 and five engines read it today. Google trialled it after launch and never adopted it, which is the entire reason this page has two tabs rather than one.

The key file is the IndexNow mechanism

Anyone can send a URL to IndexNow, so the protocol needs a way to establish that the sender controls the domain they are submitting for. It uses a file:

1. Pick a key of 8 to 128 characters — letters, numbers and hyphens.
2. Serve it at https://yourdomain.com/KEY.txt, with the key as the whole body.
3. Send the key along with the URLs. The engine fetches the file and compares.

Placing a file at the root of a site is something only someone with access to it can do. That is the proof, and it is also why the key is not a secret — it is published by design, and treating it like a password is a category error that leads people to rotate it constantly and break their own submissions.

Where the file lives matters more than people expect. A CMS that routes unknown paths through its front controller will answer with an HTML 404 page served as a 200, which fails comparison and reports nothing back. A redirect from http to https, a trailing newline, or a CDN cache in front of an origin that does not have the file yet all fail the same silent way.

What the response codes mean

The 202 is where this whole category misleads people. IndexNow acknowledges receipt synchronously and validates the key later, so a submission made with a key that exists nowhere at all still comes back as 202 Accepted. A tool that renders that as a green tick is reporting the status of its own HTTP request, not the fate of your URLs. Worth knowing too that the engines are not uniform here: Seznam rejects a bad key immediately with a 403 while the shared endpoint returns 202, which is a useful diagnostic if the two ever disagree.

What actually moves Google

Two mechanisms exist, and this page runs one of them.

The Indexing API is what the Google tab calls, and it is the only push mechanism Google exposes. Google documents it for pages carrying JobPosting or BroadcastEvent structured data; it accepts other URLs and returns 200 for them, but Google makes no promise that they will be crawled. The cap is 200 publish requests per project per day, resetting at midnight Pacific time, and there is no bulk endpoint — one URL per request, which is why the tab sends four in parallel rather than 200 in sequence.

The Request Indexing button in Search Console is the other. It is real, it works, and it has no API behind it, which is precisely why it cannot be automated for you and why no service can press it on your behalf. It sits behind your own login on your own verified property, and Google allows roughly ten to twelve presses a day. For one important URL it is still the fastest honest route, and the Google tab links straight into URL Inspection with your address pre-filled.

Two doors stay shut, and any tool claiming otherwise is selling something. The URL Inspection API only reads: Google's own announcement describes it as returning the indexed information already available in the tool, and it has no submit method. The sitemap ping endpoint was removed in 2023, so there is nothing left to ping.

After both mechanisms, discovery is what governs everything else, and discovery follows links:

1. A sitemap that is submitted and whose lastmod only changes when the content does. Dates that move on every deploy teach the crawler to ignore them.
2. Internal links from pages already crawled often — a hub, a category, a related block. A URL that exists only in the sitemap can take weeks to be found.
3. A self-referencing canonical. A template that stamps every page with the homepage canonical will keep the entire site out of the index.
4. No noindex in the meta robots tag or the X-Robots-Tag header, which CMSs apply to drafts and archive pages by default and which is easy to leave behind after publishing.

Crawled is not indexed

Submission solves discovery and nothing after it. A page that is fetched and then left out of the index is usually answering one of these: it is thin, it duplicates another page Google prefers, it returns a redirect or a soft 404, or its content only exists after JavaScript runs and the second rendering wave has not reached it yet. The checklist below the submission form covers each with the specific thing to look at, because none of them is fixable by sending the URL again — and sending it again is exactly what a rate limit or a 200-a-day quota is there to stop.

Where the two tabs differ in plumbing: the IndexNow submission is relayed through this site's server, because every IndexNow endpoint refuses browser requests and the real status code is the whole point of that tab. Nothing is stored — no URL, host or key is logged, and the key is generated in your browser so this server never holds a copy. The Google tab needs no relay at all. It talks to Google directly, and this server is not part of that conversation in any way.