Most publishing-cadence advice starts from output: three posts a week, one a day, whatever the calendar allows. That is the wrong end of the pipe. The only number that matters is how much of what you already published Google actually put in its index. This article shows how to turn that ratio into a hard throttle, using Google’s own Search Console reporting and free tools you already have.
How many posts should you actually publish?
Publish as many as Google is currently indexing. Take your mature posts (live 30+ days), divide indexed by total, and treat that percentage as your permission slip. Above your threshold, keep going. Below it, stop generating and fix indexing first. Volume is an output of index health, not an input.
There is no minimum posting frequency in Google’s published guidance, and Google’s large site crawl budget guide is aimed at very large sites; it says that crawl budget management is generally not something smaller sites need to worry about. What Google does penalize is scaled output with no value: the March 2024 spam policy update added scaled content abuse as a named violation in the Search Essentials spam policies. So the risk of publishing more is not a crawl cap. It is publishing faster than your content earns indexation.
What is indexed share, and how do you calculate it?
Indexed share is the percentage of your eligible URLs that Search Console reports as indexed. Count only posts old enough to have been fairly judged, exclude tags, archives and paginated pages, then divide. One number, recalculated on a schedule, becomes the gate that decides whether the next post gets written at all.
- Numerator: URLs under “Indexed” in the Page Indexing report.
- Denominator: live posts submitted in your sitemap, minus anything published in the last 30 days.
- Exclude: canonicalized duplicates, noindexed archives, and URLs you deliberately removed.
Google documents every one of these states in the Page Indexing report help page. Read the status names literally. They describe distinct stages of the pipeline, not degrees of the same failure.
How can you use AI for free to run this throttle?
Every part of this loop has a free path. Search Console is free and gives you the raw statuses. The free tiers of general assistants can read a pasted status export, group URLs by cause, and draft the fix list. If you want to know how to use AI for free here, the answer is diagnosis and triage, not generation.
- Search Console (free): export the Page Indexing table to CSV.
- Free AI chat tier: paste the CSV, ask it to bucket URLs by status and flag which ones share a template, a category, or an internal-link orphan pattern.
- Free scheduling: Windows Task Scheduler or cron to recompute the ratio weekly.
Worth stating plainly: the author is not a developer and cannot read code. Every failure in this system was diagnosed by pasting the error message back into an AI and asking what it meant. That is the same free capability, pointed at your own logs instead of at content.
What does the Page Indexing report actually show?
It shows each URL’s state in the pipeline, not a single quality score. Three states carry almost all the weight for a small blog: the indexed count, “Discovered – currently not indexed,” and URLs still reported as submitted after the posts were deleted. Read them as a ratio and you have your gate.
One framing note before the table: this is Google’s documented status vocabulary plus our hands-on experience running the report, not a timed study or a benchmark. We do not publish per-URL resolution times, and any indexed-share figure is site-specific — yours will differ by age, topic, and history, so treat the method as transferable and the numbers as your own to measure.
| Status | Where it lands in the ratio | What it usually means | What to do about it |
|---|---|---|---|
| Indexed | Numerator | Crawled and serving. This is the number the gate reads. | Nothing; the gate stays open |
| Discovered – currently not indexed | Denominator only | Google knows the URL from the sitemap but has not crawled it. Per Google’s docs, this is typically a crawl-scheduling decision, not a quality verdict yet. | Strengthen internal links and wait before rewriting |
| Submitted URL, page deleted or not found | Neither; remove it from both | Posts removed in your CMS but still listed in the sitemap. A reporting artifact of your own deletion, not a Google problem. | Regenerate the sitemap, then recompute |
Deleted URLs are the useful lesson. They inflate your denominator and quietly drag your ratio down until the sitemap regenerates. If you delete posts, verify the sitemap before you trust the gate. Note also that Google’s Removals tool hides a URL from results for about six months without removing it from the index, which is a different mechanism from deletion and should not be confused with it.
Is an index gate better than a fixed schedule?
An index gate is better because it fails in the safe direction. A fixed schedule keeps producing when nothing is being indexed, so you accumulate cost and thin-content risk with no upside. Manual review catches this, but only when someone remembers to look, which in practice is after the damage.
| Approach | What decides volume | How it fails | Best for |
|---|---|---|---|
| Fixed cadence | The calendar | Publishes into a wall; index share falls silently while output looks healthy | Editorial teams with human review at every step |
| Manual review | Whenever you check | Depends on attention; drifts during busy weeks | Very small sites you can still eyeball in one screen |
| Index-share gate | Indexed ÷ mature posts | Wrong denominator (stale sitemap) skews the ratio | Automated or high-frequency publishing |
What happens when the automation fails silently?
It reports success while doing nothing. Our engine publishes to WordPress on a daily schedule, and the failures we have actually hit at the verification step were an auth failure and a usage quota. In both cases publishing stopped while every scheduled task kept reporting success — which is the point worth passing on, rather than any uptime figure.
The gate is only as trustworthy as the pipeline feeding it. Two fixes came out of that:
- Split the verification gate across two different vendors. One vendor’s quota outage should not be able to stop the whole line.
- Alert even when the fallback succeeds. A silent recovery is how a long outage starts. If the primary path failed, you want to know that day, not next month.
- Keep the watchdog outside the system it watches. A monitor that runs inside the failing process reports the failure to nobody.
How do you know your niche is out of topics?
When the duplicate check rejects everything. Our engine blocks candidate topics that would cannibalize existing posts before generation starts. On one run, every candidate in the batch was rejected as overlapping. That is not a bug. It is the practical signal that a seed list is exhausted and needs widening, not that the engine is broken.
Read the two throttles together. A falling index share says the existing posts are not earning their place. A total duplicate rejection says there is nothing new to say inside the current scope. Either one alone should stop generation.
How do you set this up yourself?
Verify Search Console, define the mature-post window, compute the ratio, pick a threshold you will actually respect, and wire it to whatever produces your posts, even if that is just a note in your editorial calendar. The threshold matters less than enforcing it consistently over months.
Start at 60% if you have no history — that is a working policy, not a Google benchmark. Then adjust once you have three months of your own data, because the right threshold depends on your site’s age, topic competitiveness, and how aggressively you have been publishing. A brand-new site with a handful of posts should not be running a gate at all yet. It should be publishing and waiting.