The biggest number in my case studies is 1,006 submissions across 118 days for one baby products store. People read that and imagine some heroic technical rescue. The reality is more interesting and much more boring: it is a routine, executed daily, for four months. Here is what a job like that actually looks like from the inside, in enough detail that you could decide whether you want it done on your own site.
What 1,006 submissions actually means
It is not one big push. Search Console does not allow one big push. The number is what you get when you sit down every day for four months and submit the handful of URLs that matter most that day, then write down what you did.
Divide it out and the average day is around nine submissions. Some days it is a dozen. Some days it is three, because only three URLs were worth spending the quota on. The total is a byproduct of the routine, not a target I was aiming at. I have never once decided to hit a submission count. I decide which URLs need attention, and the count is whatever it ends up being.
The starting state
The store runs on WooCommerce and the catalogue is around 410 URLs: products, categories, the pages that hold them together. Catalogues that size behave differently from a ten-page site. There is always something new, something discontinued, something restocked, something renamed. The sitemap is never finished, so the index never settles.
Google’s index for a catalogue like this moves in both directions. Pages get indexed. Then, days or weeks later, some of them quietly drop back out. Not all at once and not for one reason. Products go out of stock and come back. The platform updates. Google re-evaluates a page it already had and decides it no longer wants it. A few pages fall here, a few there, the way pages always drop: with no notification, visible only if somebody is looking.
Most owners are not looking. This owner was, which is the only reason the job exists.
Why the daily cap decides everything
Search Console limits manual submissions to roughly a dozen URLs per day. That single constraint shapes the whole engagement. On a 410-URL catalogue you cannot submit your way out of a problem in a week. You are rationing a small daily allowance across a large surface, forever.
Which turns the job into a question you have to answer every morning: of everything not currently indexed, which handful matters most today?
That question has a real answer, and it is not “the oldest ones first”.
The priority order
New products that earn revenue go first. A product page that nobody can find is a product that does not exist, and the sooner it is in the index the sooner it can start paying for itself.
Pages that dropped since yesterday go second, and only once whatever dropped them is fixed. Resubmitting a page that is still broken is how people burn a month of quota and conclude that indexing requests do not work. The submission is the last step, not the first.
Everything else waits its turn through the sitemap. The long tail of a catalogue does not need manual attention if crawling is healthy, and spending scarce daily slots on pages Google will reach anyway is the most common waste I see when I take over an account.
Then, and this is the part that makes the rest possible, every submission gets a row on the ledger with a date.
What a day actually looks like
Pull the current status of the catalogue. Compare it against yesterday. Three things come out of that comparison: what flipped to indexed, what is still pending, what fell back out.
The first group gets closed off. The second group gets left alone, because resubmitting a pending URL does nothing except waste a slot. The third group gets investigated before it gets resubmitted, because a page that dropped once will drop again if the cause is still there.
Then I pick the day’s handful, submit, and write the rows. That is the whole day. Fifteen minutes when the catalogue is calm, considerably longer when something structural has changed and forty URLs shifted status at once.
Repeat that 118 times and you get 1,006 submissions, a catalogue that mostly stays indexed, and a store owner who can open a sheet on any given day and see exactly what his money bought.
The ledger is the product
Indexing work is invisible when it is working. Nothing happens. Pages that would have quietly disappeared simply do not. There is no dramatic before and after screenshot to send, because the win is an absence.
That is a genuine commercial problem for anyone selling this work, and the ledger is my answer to it. Per-URL rows, with dates and statuses, turn an invisible service into something checkable. The owner does not have to take my word for the fact that I worked on Tuesday. He can look at Tuesday.
It also keeps me honest in the other direction. When a URL sits at not indexed for three weeks, that row is sitting there too. I would rather have the uncomfortable conversation with the record in front of both of us than write a summary that quietly rounds the number up.
Drops are the part owners never see
The single most useful thing this arrangement produces is not the submissions. It is catching pages that were indexed, got dropped, and would have stayed dropped.
Nobody gets an email when that happens. There is no alert. A product page that was bringing in orders in March can be out of the index by May, and the first signal most owners get is a revenue dip they attribute to seasonality. On this account, drops are caught because somebody compares the catalogue against yesterday, every day, and resubmits once the cause is dealt with.
That is the difference between a one-time push and monitoring, and it is why the one-time packages and the monthly ones exist as separate things. A push is right when there is a specific blocker to clear. Monitoring is right when the catalogue is big enough that things will keep going wrong.
Why it became a monthly arrangement
The store is on my monthly plan now, and the owner has ordered seven times, which is the stat I am proudest of on the whole site. Not because seven orders is a large amount of revenue. Because of what it means: the reporting was honest enough that continuing was an easy decision, month after month.
I have no way to promise anyone a specific indexed percentage, and I do not try. What I can promise is that the work happens daily, that the record is per URL, and that when something is not working you will hear it from me before you notice it yourself. Seven orders from one account is the closest thing I have to evidence that this is worth paying for.
If you are considering this for your own catalogue
Two honest checks. First: is your problem a blocker or a size problem? If a few dozen pages are held back by one fixable cause, you want a one-time job, not a subscription. Second: does anyone currently look? If the answer is no, the drops are already happening and you simply have not seen them yet.
The full numbers for this store are in the case study, the statuses I check every morning are explained in the crawled and not indexed guide, and the packages that run this way, one-time and monthly, are on the indexing page.