Indexing an 800-page store: 150 URLs a day, no quota burn
An 800-page catalogue is not an indexing problem you solve in one afternoon. Dumping the whole sitemap at Google in a day is how you burn your API quota, request crawls of pages that can never be indexed, and learn nothing about which ones landed. Here's the paced approach we ran on onespoonwitch.com instead.
Verified numbers. Page counts and the daily submission cadence come from the store's own Search Console property and IndexerNow batch history. Index outcomes are read from Google's URL Inspection API against that property — not from our own index or an estimate.
The problem
One Spoon Witch is an e-commerce site with more than 800 URLs — product pages, collections, and content. The catalogue existed, the sitemap was live, and Google simply had not got round to most of it. In Search Console the majority of those URLs sat in "Discovered — currently not indexed": Google knew the address, had scheduled nothing, and gave no reason.
The obvious move — request indexing on everything, at once — is the wrong one. Google's Indexing API allows roughly 200 requests per day per Cloud project. An 800-URL blast exhausts that in one go, leaves nothing for the pages published tomorrow, and tells Googlebot nothing useful about which pages matter. Worse, a bulk request that includes noindexed, canonicalised, redirecting or thin URLs asks Google to spend crawl budget on pages that were never going to be indexed — exactly the pattern that makes a site look low-quality to crawl.
So the goal was never "submit 800 URLs". It was: make sure each URL deserves to be indexed, then present them to Google at a rate that reads like a healthy, actively-maintained store.
What we ran
- 1
Pull the real URL list from the sitemap
The catalogue came in from the store's XML sitemap rather than a hand-pasted list, so nothing was missed and nothing was invented. The list was deduped and cleaned — tracking parameters, session IDs and trailing-slash duplicates stripped — because two versions of the same product page are two requests spent on one page.
- 2
Check indexability before spending a single request
Every URL was run through an indexability check first: does it return 200, is it blocked in robots.txt, does it carry a noindex, does it canonicalise to itself or somewhere else? URLs that failed were fixed or dropped. This is the step most bulk submitters skip, and it is the one that protects the account — you never ask Google to crawl a page you have already told Google not to index.
- 3
Pace at 150 URLs a day, not 800 in an hour
The cleaned queue was released at 150 URLs per day through Google's official Indexing API, running on the store's own Google Cloud project and its own quota — never a shared pool. 150 sits comfortably under the 200/day ceiling, which leaves headroom for new products and for re-submitting anything that needs a second pass. The whole catalogue cleared in roughly six days.
- 4
Mirror the same list to Bing and IndexNow
The identical list went to Bing via IndexNow, which costs nothing against the Google quota and also feeds the engines behind Copilot and several AI answer products. There is no reason to leave that traffic on the table while the Google queue drains.
- 5
Verify with URL Inspection, then re-queue what didn't land
Submission is a request, not a result. Each batch was re-checked afterwards through Google's URL Inspection API against the store's own verified property, so the coverage state of every URL — indexed, crawled — currently not indexed, discovered, excluded — came from Google itself. Anything still short of indexed went back into the queue behind the pages that had not been tried yet.
What changed
The catalogue moved from "Google has never looked at most of this" to a state where every URL has been explicitly presented to Googlebot, verified as crawlable first, and re-checked against Google's own coverage data afterwards. That is the part a store owner can control; the indexing decision itself always stays with Google.
The pacing mattered more than the volume. Spreading 800 URLs across roughly six days at 150 a day kept the store's daily API quota intact for newly published products, avoided the one-off spike pattern, and produced a clean per-day record of which batch each URL belonged to — so when a page did not get indexed, it was obvious which batch to look at and what those pages had in common.
Takeaways you can copy
- Never submit a URL you have not checked. A noindex or a bad canonical makes the request worthless before it is sent.
- Pace under the quota. 150/day against a 200/day ceiling leaves room for tomorrow's pages and for a second pass.
- Clean the list first — parameters and duplicates quietly double your spend on the same page.
- Submission is a crawl request, not an indexing guarantee. Verify with URL Inspection afterwards or you are flying blind.
- Send the same list to IndexNow. It costs nothing against your Google quota.
Run the same workflow on your URLs
Everything above runs on your own Google account, your own Cloud project and your own quota — never a shared pool. Start with the free bulk check to see which of your pages Google actually has.
Tools and guides used here
Frequently asked
Is submitting 150 URLs a day safe for a store's reputation?
Requesting a crawl of your own public, indexable pages is a normal, documented use of Google's Indexing API — it is the programmatic version of the "Request indexing" button in Search Console. The risk is not volume, it is content: repeatedly asking Google to crawl pages that are noindexed, thin, duplicated, or broken is what wastes crawl budget and teaches Google that your requests are not worth acting on. Check indexability first and pace inside your quota, and you are doing what the API is for.
Why 150 a day and not the full 200?
Google's Indexing API quota is roughly 200 requests per day per Cloud project. Running at the ceiling means a newly published product, or a page that needs re-submitting, has to wait for tomorrow. 150 keeps a working reserve.
How long does an 800-page catalogue take?
At 150 URLs a day the queue itself drains in about six days. How long Google then takes to act on those requests is Google's call and varies by site — which is why the workflow ends with a URL Inspection pass rather than an assumption.
Does this work on Shopify, WooCommerce and other platforms?
Yes — the workflow is platform-agnostic because it runs off your XML sitemap and Google's APIs, not off a CMS plugin. Anything that publishes a sitemap and lets you verify the property in Search Console works the same way.