Yesterday we ran Request Indexing on nine pages (the tenth was rejected by our own header — separate story, worth reading). This morning we went back to check what the request actually bought.
The first page we requested — one of our core app routes — shows a fresh crawl stamp: refetched at 11:51 AM on the day of the request. The stamp we saw before requesting read Oct 14. Same day as the click — we can't prove minutes, and we won't claim them.
And the index count? 208 pages indexed, 2,270 not, out of 2,478 known. Ninth straight day, exactly the same numbers.
That's the whole finding, and it sharpens what the button did this time: it coincided with a refetch. It did not buy an index entry. The page still sits at crawled-but-not-indexed with a newer crawl date than before — same shelf, fresher evidence for Google to decide with.
Two doors, and only one of them has a button:
- The crawl door: opened once, visibly, the same day we asked. One observation so far, not yet a pattern.
- The index door: opens on Google's side, on its own schedule, based on what the recrawl finds. No button exists for this one.
So the plan stops being "request harder" and becomes: keep the daily quota of requests going (ten a day, into the priority queue), and treat everything else as a page-quality problem. If fresh crawls plus sitemap plus internal links don't move these routes into the index over the next week, the queue was never the bottleneck — the pages were.
One operational note for anyone running this daily: the URL Inspection entry failed to open for us again today — the same failure that cost us four days before recovering yesterday. These tools fail quietly in both directions: requests that don't go out, and no error telling you they didn't. Log every request with a timestamp. The interface will not remember for you.
We'll report the index count every day it moves. And the day it doesn't, which is most of them so far.
Top comments (0)