We took a blog from 84 posts to 1,360 in five days, across six languages. The biggest single day was 515 posts. Google's verdict, measured in Search Console the morning after the last batch: 69 indexed, 43 discovered and not indexed, the rest not even discovered. Publishing is not the bottleneck. Here is what actually was.
"Discovered, currently not indexed" is a verdict, not a bug
That status is Google saying it knows the URL exists and has decided not to spend crawl budget on it. No console setting changes that. I went through every togglable thing in Google Search Console, Bing Webmaster Tools and Yandex Webmaster to be sure. What each console gave us:
| Action | Effect |
|---|---|
| Resubmit sitemap | Bing went from 11 known URLs to 1.1K |
| Raise Bing crawl rate to max | more requests allowed, not more indexing |
| IndexNow ping | 1,068 URLs accepted in seconds |
| Yandex recrawl queue | 150 URLs per day, hard cap |
| Google request-indexing | ~10 URLs per day, hard cap |
All of it is discovery. None of it is authority. A thousand pages that nothing links to are a thousand pages Google will get around to eventually, or not.
The mistake that cost the most
Every one of those 1,360 pages was reachable only from one hub. The hub listed all of them, so it looked fine. It is not fine.
A hub with 250 cards divides whatever authority it has by 250. To reach a post, a crawler loads a 257 KB page and walks a flat list. There is no path between posts, so nothing pulls a crawler deeper than one hop from the hub.
What we changed: a ring, not a top-six
The obvious fix is a "related posts" block. The obvious implementation is wrong.
If every post links to the top six in its group, six pages collect a thousand inbound links and the rest collect zero. That is a funnel, not a mesh.
A ring fixes it. Sort the group, then post i links to posts i+1 … i+6, wrapping around:
list.sort((a, b) => a.slug.localeCompare(b.slug));
for (let i = 0; i < n; i++) {
const picked = [];
for (let k = 1; k <= 6 && k < n; k++) picked.push(list[(i + k) % n]);
related.set(list[i].slug, picked);
}
Every post now has exactly six outgoing and about six incoming links. A crawl that starts anywhere reaches everything. Internal links per page went from 10 to 16, and no page is an orphan by construction rather than by care.
Sort by slug, not by date. Dates change when you move a post, and a date-ordered ring rebuilds itself completely on the next publish, changing every internal link on the site at once.
The other thing worth doing
Structured data you already qualify for. Our engine supported FAQPage from day one through a frontmatter field. Out of 1,360 posts, 40 had filled it, carrying 42 questions between them. A capability that 97% of your own content walks past is close enough to a missing one.
The articles already had question-shaped subheadings with an answer paragraph under each. Google's rule for FAQPage is exactly one thing: the question and the answer must be visible on the page. They were. So the schema is now derived from the rendered article instead of a field:
const re = /<h[23][^>]*>([\s\S]*?)<\/h[23]>\s*<p[^>]*>([\s\S]*?)<\/p>/gi;
Only headings that actually end in a question mark qualify. Turning a statement into a question would mean marking up something the page does not say. Result: 1,157 pages carrying 8,217 questions, none of it invented.
What we are still waiting on
Honest ending: none of this has moved rankings yet, and it would be a lie to claim otherwise a day later. Discovery is fixed, the mesh is built, the schema is real. The remaining gap is external links, which no amount of engineering produces.
If you are in the same position, the order that matters is: make every page reachable from more than one place, submit properly once, then go get links. The consoles are the smallest of the three.
We write this stuff up while building Zugo, which turns a written description into a working game, site or app. More of the measured kind on the blog: what AI builders cannot do and how long a build actually takes.
Top comments (0)