More posts does not mean more indexed pages.
That sounds obvious until you are looking at Search Console after a publishing sprint. The library is bigger. The sitemap has more URLs. The CMS says the posts exist. The archive pages load. And the indexed-page count still moves sideways, or worse, down.
The easy story is that Google is being slow. Sometimes that is true. It is also not a useful operating model.
A better model is this: search visibility is not an inventory counter. It is a crawl-trust pipeline.
A page has to exist. Then it has to be reachable. Then the URL identity has to be unambiguous. Then the discovery surfaces have to agree. Then the search engine has to crawl it, interpret it, select it for indexing, and keep it there. Publishing only affects the first step. Everything after that is a systems problem.
The useful correction: indexed pages are not a post counter
A published post is an inventory object. An indexed page is a search-system outcome.
Those are different things.
Google describes Search as a sequence of crawling, indexing, and serving/ranking. Crawling is discovery. Indexing is understanding and storing eligible content. Ranking is choosing what to show for a query. A page can exist and still fail to move through that sequence cleanly. It can be published but undiscovered. Discovered but ambiguous. Crawled but canonicalized somewhere else. Indexed briefly and then dropped. Useful to a human reader but weakly connected to the rest of the site.
That distinction matters because the wrong metric creates the wrong fix.
If you treat indexed pages as a post counter, the answer to a low indexed count is always “publish more.” If you treat indexed pages as the output of a crawl-trust pipeline, the answer becomes “prove the pipeline agrees before increasing production.”
That is the operator move. Do not argue with the dashboard. Reconstruct the path a crawler has to take.
The crawl-trust pipeline
The pipeline has six practical stages:
- Inventory: the content exists as a public URL.
- Accessibility: representative routes return clean 200 responses and are not blocked.
- Identity: canonical URLs, redirects, trailing slashes, and URL variants point to the same answer.
- Discovery: sitemaps, RSS, archive pages, navigation, and internal links expose the URL.
- Selection: the search engine decides the page is worth indexing instead of ignoring, merging, or dropping it.
- Verification: your system checks the public web after publishing instead of trusting the CMS write.
Most publishing systems over-invest in stage one. They can create content. They can serialize frontmatter. They can make a route appear. They can show a green deploy.
That is not enough.
Google’s sitemap documentation is careful about this. A sitemap helps Google crawl a site more intelligently; it is not a guarantee that every submitted URL will be crawled or indexed. Google’s canonicalization documentation is just as important: when duplicate or variant URLs exist, Google chooses a canonical URL. That means URL construction is not a cosmetic detail. It is identity.
When identity and discovery drift, your site can look healthy from inside the publishing system and confusing from the outside.
The mistake is assuming “URL exists” means “URL is legible.”
What a real audit can reveal
A useful audit does not start with content quality takes. It starts with boring public readback.
How many public post routes return 200?
How many post URLs are in the sitemap?
Do sitemap URLs match the canonical route shape?
Can archive pagination traverse the same inventory?
Do representative pages contain noindex by accident?
Do RSS, sitemap, archive pages, and post routes describe one coherent site, or four slightly different versions of the site?
That is the kind of check that turns vague Search Console anxiety into a concrete systems problem.
In a public bd-site audit captured in GitHub issue #62, the useful evidence was not mystical. It was mechanical. The site had public post routes returning 200. The post sitemap listed the post inventory. But the sitemap URLs had a double slash in the post path shape, and archive pagination exposed its own behavior. That does not prove one single cause for indexation by itself. It does prove the thing that matters operationally: the discovery layer deserved inspection before anyone blamed the content calendar.
That is the right level of lesson. Do not overclaim that a malformed sitemap URL is always why Google did or did not index a page. Do claim that a publishing system should not emit route-shape disagreement and then expect search visibility to be a simple function of output volume.
The public web is the source of truth. Not the CMS. Not the queue. Not the deploy log. The public route, the sitemap, the archive, the canonical tag, and Search Console have to be reconciled.
Why more content can make the gap more visible
More content is not bad. Thin volume is bad. Unverified volume is worse.
A larger library stress-tests assumptions that a small site can hide.
If the sitemap has a URL construction bug, every new post repeats it. If archive pages are weakly linked, deeper posts become harder to discover. If canonicals are inconsistent, each new route adds another chance for identity drift. If the publishing system stops at “file written” or “API returned success,” every new post adds inventory without proving visibility.
This is why the “just publish more” advice breaks down for agentic publishing.
Agents are very good at increasing production throughput. They can draft, format, tag, upload, and schedule faster than a human editor. That is useful only if the verification layer scales with the production layer.
Otherwise, autonomy creates a bigger blind spot. The system gets better at making posts and not much better at proving those posts became part of the discoverable web.
The fix is not to slow everything down to human-only publishing. The fix is to make readback part of the publishing contract.
A post is not done when the writer finishes. It is not done when the API accepts the payload. It is not done when the deploy turns green.
For an AI-native publishing system, the minimum done-state is: public route works, metadata is coherent, sitemap/RSS/archive surfaces agree, the page is eligible for indexing, and the system can show evidence.
The operator checklist
When indexed pages are lower than expected, do this before commissioning another batch of posts.
First, count the public inventory. Fetch the live post list, or crawl the public archive, and confirm how many routes actually return 200.
Second, sample the routes like an external crawler. Check status codes, redirects, canonical tags, noindex, robots behavior, and whether the page renders the body you think it renders.
Third, compare discovery surfaces. Sitemap, RSS, archive pages, category/tag pages, and internal links should point to the same canonical URL shape. Small differences matter: protocol, host, trailing slash, duplicate slash, encoded characters, and date/slug mismatches all create ambiguity.
Fourth, separate sitemap inclusion from indexation. A sitemap is a hint and a discovery surface. It does not grant index status. Use it to debug what you are asking Google to crawl, not as proof that Google accepted the page.
Fifth, inspect canonical decisions. If duplicate or variant URLs exist, assume Google may consolidate them. Your job is to make the preferred version boringly obvious.
Sixth, fix the system before increasing the library. If the discovery layer is wrong, more posts multiply the defect. If the discovery layer is right, more posts have a cleaner path into search.
Seventh, close the loop in Search Console. Submit the corrected sitemap, inspect representative URLs, and watch coverage over time. Do not expect instant movement. Do expect the system to stop contradicting itself.
The checklist is not glamorous. That is the point. Search visibility is often lost in unglamorous disagreement between surfaces that each looked fine in isolation.
What this changes about publishing with agents
Agentic publishing should not be judged by whether it can produce another article.
That bar is too low.
The real question is whether the system can produce an article, place it correctly into the public site, and verify that the discovery layer agrees. If it cannot, the agent is only automating inventory. It is not automating publishing.
This is the same pattern that shows up everywhere in AI operations: green status is not shipped work. A completed task is not a verified outcome. A generated artifact is not a live system state.
For content, the distinction is especially easy to miss because the artifact feels like the product. The post exists. The prose is done. The route loads. It looks finished.
But the brand value compounds only when the work becomes findable, citeable, linkable, and durable. That requires a publishing system that treats crawlability and readback as first-class outputs.
More posts can help. But only after the pipeline can carry them.
Until then, more posts do not mean more indexed pages. They mean more inventory waiting for the rest of the system to prove it deserves to be seen.
Sources
[1] Google Search Central, “In-depth guide to how Google Search works.” https://developers.google.com/search/docs/fundamentals/how-search-works
[2] Google Search Central, “What is a sitemap?” https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview
[3] Google Search Central, “How to specify a canonical URL with rel=canonical and other methods.” https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
[4] berryhill/bd-site public GitHub issue #62, sitemap and indexability audit context. https://github.com/berryhill/bd-site/issues/62