Three days of measuring the request indexing quota in Search Console
Search Console limits, labels, and quotas change without notice — the quota here is not documented at all. Every number below is a snapshot from early October 2026, measured on my own Google account. Re-measure on yours before you plan around it.
Google Search Console’s “Request Indexing” has a daily quota. The help documentation confirms that a limit exists and never says how large it is; the number people repeat in forums — ten URLs a day — has no official source I could find. I spent three days measuring mine. The short version: the quota is shared by every property under one Google account rather than counted per site, the daily number floats, and it recovers hours before Pacific midnight. Here is what I actually logged.
The quota belongs to the account, not to the site
This is the finding that changed how I work, and it is the one I got wrong first. My earliest notes said the limit was counted per account, per property, per day — I assumed each site had its own budget. Cross-property testing disproved it. A small family of free tool sites is what I actually run — the eight of them are listed on my /tools page, and WordRoost is the newest — plus this blog, and when one site under my account had spent the day’s quota, a different site under the same account could not submit either.
The clearest single day is 2026-10-09. Sixteen requests succeeded that day, and they were spread across four different properties under one account: one site took one, another took six, this blog took eight, and a fourth took one. Property boundaries reset nothing. The pool was the account’s.
Two things that do not change the pool, which I tested specifically because both are common advice: the IP address you submit from, and whether you use an incognito window. Neither made any difference. The only action that gets you a different pool is a different Google account.
The daily number floats, so plan for a range
I have two clean samples of a full day’s capacity: 11 and 13. On a third day, 16 requests went through and the 17th was rejected. So “the quota” is not a fixed number you can memorise. Treat it as a range somewhere in the low teens, and stop guessing at an exact figure.
The shape of a batch tells you which end of that range you are on. On 2026-10-07 my blog’s batch submitted four URLs and the fifth was rejected — the account had already been used that day, so four was what remained rather than the day’s total. The next full batch, on 2026-10-09, submitted eight URLs with nothing left over. Same account, same tool, very different amounts available, because the pool depends on whatever else the account did that day.
Recovery happens before Pacific midnight
The advice I kept reading was to wait for midnight in Pacific time. My logs disagree. After one morning cap, the next day’s first submissions at 13:19 Beijing time went straight through. That is hours earlier than Pacific midnight, so I moved my working window to “any time after 13:00 Beijing” and stopped waiting until the evening.
I also tested the other popular claim, that the quota resets at 15:00 Beijing. It does not. On one day the first request at 14:31 was already rejected, a re-test at 15:00:54 was still rejected, and the pool only came back at 17:05. Recovery is not always generous either: one recovery gave exactly one submission before the cap returned.
The first click is a usable signal for how much is left
This is the small observation I rely on most now. When the quota is nearly gone, the first click on a URL returns a transient error — a generic message that there was a problem submitting the indexing request — and the second click succeeds. When the pool is fresh, the first click succeeds and there is no error at all.
Both batches fit the pattern exactly. The 2026-10-07 batch, running against a partly used pool, had a first-click error on all four URLs. The 2026-10-09 batch, running against a fresh pool, had zero errors across eight.
So if you are working through a batch and every first attempt fails, that is not a broken tool. It is the quota telling you it is nearly empty — and it is a good moment to write down where you stopped.
What I do now: stop at the cap, roll the rest, keep the screenshots
Three rules, all of them forced by these runs:
- Stop the moment the quota is hit. The remaining URLs go to the next day. Switching accounts to keep going is not worth it, for the reason in the next section.
- Screenshot every confirmation. The success state is the line saying the URL has been added to the priority crawl queue. A line you typed into your own log is not evidence; a screenshot is.
- Re-check read-only. After a batch, checking whether a URL is already indexed does not consume quota. Only the submit action does.
For cost: a four-URL batch ran about five minutes end to end, and an eight-URL batch about eight minutes. The clicking is not the bottleneck. The queue is.
A second account is not a second full quota
The obvious workaround is to keep a spare Google account and switch when the first one runs dry. I tried it, and it mostly does not work. Quota is attached to the account, and my spare accounts already carried properties of their own — so their budget for the day was partly spent before I arrived. On the worst day, a spare account’s very first request was rejected.
Keep a spare if you want one, but look at what else that account does before you count on it. An account with several properties under it is not a fresh account.
What I would tell anyone batching indexing requests
The quota is real, it is smaller than the folklore suggests, and it is not the thing worth optimising. What matters is knowing which pool you are drawing from and stopping cleanly when it is empty. Everything above is one account’s behaviour in one week of October 2026, not a documented Google promise — so measure your own before you build a schedule on it.
This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.