Contents
- Push 606 URLs, and Google says it doesn’t know 315 of them
- But saying the API does nothing would also be wrong
- Split by article age to make the comparison fair
- Push 95 URLs, then check again after 40 hours
- Those 35 URLs also exposed another bug
- Rereading Google’s documentation makes this unsurprising
- So what should you do instead of pushing the API
- How to check this on your own site
Google has an API called the Indexing API. You submit a URL to it, get back 200 OK, and according to most Vietnamese SEO guides, the page will get indexed faster. It sounds neat, and it’s free, with a limit of 200 URLs per day.
Marketing365 ran two scripts to push URLs automatically starting in early July. By 13/08/2026, 606 URLs had been pushed. That day I went back and checked each URL with the URL Inspection API — also a Google API — to see what the push had actually achieved. The result was not what I expected.
Push 606 URLs, and Google says it doesn’t know 315 of them
Of the 606 URLs pushed, 590 could be checked for status. The numbers were as follows:
315 (53,4%) URL is unknown to Google
172 (29,2%) Discovered - currently not indexed
101 (17,1%) Submitted and indexedThe first line is the hardest to swallow. URL is unknown to Google means Google says it does not know this URL. Not “it knows it but hasn’t ranked it yet,” and not “it crawled it and dropped it” — it simply doesn’t know it. None of those 315 URLs had any recorded crawl timestamp.
And each of those URLs had already been submitted to Google’s own Indexing API, with every submission returning 200. No errors, no warnings, nothing to fix.
But saying the API does nothing would also be wrong
Putting the two groups side by side is where it gets interesting. Among the 1,076 URLs that had never been pushed, the share of “Google doesn’t know” was 64.0%. In the pushed group, it was 53.4%. The “known but not indexed” group moved the other way: 29.2% in the pushed group versus 14.9% in the non-pushed group — nearly double.
In other words, the API does do one thing, just not the thing people advertise. It moves URLs from the “unknown” bucket to the “known” bucket. But from “known” to “indexed,” it stands aside: 17.1% in the pushed group, 19.0% in the non-pushed group.
Before concluding that the pushed group performed worse, one thing has to be said immediately: the two groups cannot be compared directly. The daily push script takes the newest posts, and newer posts naturally have not had time to get indexed yet. That means the “pushed” group is systematically younger than the “not pushed” group. The gap between 17.1% and 19.0% is mostly about article age, not the API.
Split by article age to make the comparison fair
The way to handle this is to pair each URL with its publication date, then compare only within the same age range. The backfill group is excluded because it was selected because it had not been indexed; comparing it would be cheating. What remains is the daily-push group versus the group that had never been pushed:
article age daily push never pushed
0-14 days 2/53 ( 4%) 0/147 ( 0%)
15-29 days 0/90 ( 0%) 8/372 ( 2%)
30-44 days 12/282 ( 4%) 23/273 ( 8%)
45-59 days 17/23 (74%) 165/271 (61%)Four lines, two leaning toward the pushed group, two leaning toward the non-pushed group. The 74% cell looks nice, but it only has 23 URLs; just a few status changes would move the number by more than ten percentage points. Read plainly, this table does not show any effect, but it is also not strong enough to say there is no effect. It only says: if there is a benefit, it is smaller than the noise.
Push 95 URLs, then check again after 40 hours
The table above is still observational data, full of noise. A cleaner test is to push one batch and then check that same batch again after a set period.
At 16:40 on 13/08, the backfill script pushed 95 URLs. At 19:55 the same day — about three hours later — I checked them once. On the morning of 14/08, about 40 hours after the push, I checked them again using the same method:
Read more: How to Optimize SEO-Friendly URLs for Your Website
after 3 hours after 40 hours
URL is unknown to Google 47 50
Submitted and indexed 35 35
Discovered - currently not indexed 12 9
Crawled - currently not indexed 1 1
number of URLs newly indexed: 0
number of URLs that fell from "known" back to "unknown": 4None of them got indexed. Four moved backward. The “already indexed” column stayed at 35 — and those 35 were already there in the three-hour check, which means they had been indexed before being pushed, not because of the push.
One honest caveat here: 40 hours is short. Google could absolutely process this batch after a few weeks. What this experiment rules out is “the API push gets pages indexed quickly” — it does not rule out “the API push eventually has some effect.” I will check this batch again after a month and update the article.
Those 35 URLs also exposed another bug
The backfill script chose URLs to push based on a saved index-status file, and that file was allowed to be up to 14 days old. Of the 95 URLs it selected as “not indexed,” 35 were already indexed when checked again — 36.8%.
That means more than a third of that day’s quota was spent on URLs that did not need pushing. The limit is only 200 URLs per day, and the site has more than a thousand URLs that Google doesn’t know about, so this waste is real. The lesson is not about the Indexing API but about something more familiar: if the data used to choose the work is old, the work chosen will be old too.
Rereading Google’s documentation makes this unsurprising
The most important point is that this is not a secret. Google’s official Indexing API documentation clearly says it is for pages with JobPosting or BroadcastEvent structured data — job listings and live-stream events, two types of content that expire very quickly. There is no line saying it can be used for blog posts or standard news articles.
The API still accepts your URL and still returns 200, because it does not inspect the content when it receives it. That 200 only means “request received,” not “something will be done with it.” For two months I read 200 as a promise, when it was only a receipt.
So what should you do instead of pushing the API
The numbers above do not say “turn the script off.” They say API pushing is cheap and fine to run in the background, but do not count on it in your plan. The real effort should go somewhere else.
The real bottleneck for this site is crawl speed: every day the sitemap grows by dozens of URLs while Googlebot can only read a few HTML pages — I measured that separately in the article 27 new pages added per day, Googlebot reads 8. When the crawl queue is already jammed, telling Google about one more URL does not solve anything; it only makes the queue longer.
Three things are more useful, in the order I would do them:
- Reduce the number of new URLs per day, or consolidate thin pages. A shorter queue is the only thing you can directly control.
- Add internal links pointing to pages sitting in the “Google doesn’t know” bucket. A path from a frequently crawled page is how Google learns about a URL, and that method has no quota.
- Track with Google Search Console, not with the API response code. Index status is the only thing worth watching.
How to check this on your own site
If you are also running an Indexing API push script, the lightest test is to open Search Console, go to URL Inspection, and paste in a few URLs that were pushed more than a week ago. If you see “URL is not on Google” along with a line saying it has never been crawled, then your script is behaving like mine: no errors, and no effect.
To do it properly, you need a bulk check with the URL Inspection API, split by article age like in the table above. The inspection quota is 2,000 URLs per day, enough for most mid-sized sites. What you need are two numbers for the same age range: the index rate of the pushed group and the index rate of the non-pushed group. If those two numbers are the same, you have just bought back the time you were spending on something that does not work.
