Google gives you no API for the Request Indexing button, so my daily job prints me a clicklist

by

I automated my site's indexing checks this month and hit a wall that surprised me. The Search Console API will inspect URLs, report coverage state and resubmit sitemaps. The separate Indexing API only accepts job postings and livestream pages. The one thing everyone actually wants, the Request Indexing button, has no API at all.

So my daily job does everything the API allows, inspects up to 160 URLs, resubmits the sitemap, then writes a shortlist of URLs stuck in Discovered or Crawled but not indexed. The last step is me clicking Request Indexing by hand off that list.

Has anyone found a legitimate way around this, or is the manual click just the toll Google charges?

129 views

Add a comment

Replies

Best

have you faced this problem too?

  It is my own site in the post, so yes, daily. The push to automate came after a content overhaul left about 85 blog URLs sitting in the waiting queue for weeks. The API checks freed me from rechecking them one by one, but the button itself still wants a human.

have you ever comapred manual and automation indexing results?

  No clean split test, but my logs lean one way. URLs left to the sitemap alone sat in Discovered for weeks, while the ones I hand requested usually got crawled within a day or two. The verdict after the crawl was the same either way, which matches what Clemente said above. The click buys speed, not approval.

have you ever missed important pages because of indexing delays?

  Yes, the expensive version. After a content overhaul this month about 85 rewritten posts sat unindexed for weeks, so all that rewriting work earned nothing while it waited. That gap is what pushed me to build the daily job in the first place.

what would you automate if this API existed?

  The handoff, not the click. The job already scores every stuck URL by value, so with an API it would submit the top ten each morning and then check a week later which ones actually got indexed, closing the loop without me. The click itself is trivial. The part worth automating is never forgetting to do it.

how do you manage manual indexing?

  The script ranks the shortlist and I paste each URL into the inspection bar at the top of Search Console, then hit Request Indexing. The practical ceiling I have measured is about ten accepted requests a day per property, nine on my best logged day, so the ranking matters more than the clicking. Money pages first, old blog posts last.

do you rly more on sitemaps or manual requests?

  Sitemap as the baseline for everything, manual requests as triage for the few pages that actually earn money. The quota is roughly ten accepted a day anyway, so it forces that split whether you plan it or not.

have you automated any part of your SEO workflow?

  Most of it, this thread is one output of that. A scheduled job runs every afternoon, pulls coverage for about 160 URLs from the Search Console API, resubmits the sitemap, checks the rest of my five domains, and writes one report ending in the shortlist of URLs worth a manual request. The only steps left by hand are the clicks Google refuses to expose and the judgement calls, like which stuck page deserves a rewrite instead of a request.

I've accepted that the last click is still manual. I just wish Google was a bit more consistent here. Everything else is automated until that final step.

No legitimate way around it, and the absence looks deliberate to me. A submit endpoint with real intent behind it becomes a spam surface the day it ships, which is also why the Indexing API stayed scoped to job postings and livestreams. IndexNow is a genuine API but it feeds Bing and Yandex, so it is worth running for Bing coverage and not worth counting as a Google fix.

What changed how I read that clicklist is what the click actually buys. Discovered and not indexed is usually a judgement about the URL rather than a queue position, so a manual request buys one crawl and often the same verdict after it. When I ran this on my own site the real finding was upstream: we were returning 200 for pages with nothing on them, so Google was queueing URLs that should never have existed. Removing those moved more than any submission would have.

One thing I would add to your job: log how many days each URL sits in Discovered before it moves. The duration separates a crawl budget problem from a quality one, and it is the one signal the API hands you for free.

  The 200 for empty pages finding matches mine almost exactly. My version was empty category hub pages, real HTML with nothing in them, and noindexing them plus dropping them from the sitemap moved the queue more than any batch of manual requests did. Fair point on logging days in Discovered, that duration is data the job already sees and currently throws away.

@abdullah_javaid3 The manual click is the toll, and I'd resist automating past it even if Google exposed the endpoint. Clemente's read is right: the button is a proof-of-human rate limiter, and the value isn't the click, it's that the quota forces you to rank. An API with the same ~10/day ceiling would just move the rationing into your code, which you've already built.

Where I'd point the automation instead is the loop you described to Vincent - submit, then check a week later which URLs actually got indexed - because that's the part a script does better than a person, who forgets. One thing worth adding there, and it's the same lesson from the agent thread you commented on: verify the outcome against the world, not against the fact that you clicked. "Requested" and "indexed" are different states, and the only one that matters is the one you read back from the Coverage report days later. A job that logs "submitted 10" is grading its own homework; a job that logs "of the 10 submitted Monday, 6 were indexed by Friday, 4 still Discovered" is the one that tells you whether the ranking was any good.

And Clemente's days-in-Discovered signal is the input that makes the ranking self-correcting. If a money page sits in Discovered for three weeks despite a manual request, that's not a queue problem you can click your way out of - it's the crawl-budget-vs-quality split, and the duration is what separates them. Feed that back into the scoring and the shortlist stops recommending pages the click was never going to fix.

 Really like how you distinguish requested from indexed as separate states worth tracking.

The days-in-Discovered signal for splitting crawl budget from quality issues is smart.

Would love a feature that auto-flags pages stuck past a set threshold for review.

12
Next
Last