Four bulk drops: what the publish dates in 3,038 pages reveal

Of the 3,038 pages we read, 974 carry a machine-readable publication date. Plotted by month, they do not describe a content programme. They describe four events.

The drops

• 217 pages on 4 May 2026. One competitor’s entire tools section, every page, one day.
• 102 pages on 16 April 2026. The same company’s comparison section.
• 57 pages on 18 September 2025. The same company’s integrations section.
• 152 pages in June 2026, 52% of them on a single day, from a different company.

For the three sections above, the figure is not “mostly”. It is 100% of dated pages in that section sharing one date.

A fourth company put 37 pages out in September 2026 and 19 in August, which is the closest thing to a ramp anywhere in the corpus, and it is a two-month-old site.

What this does not tell you

It does not tell you bulk publishing fails. There is no traffic data anywhere in this corpus and we are not going to manufacture an inference.

It is worth stating clearly, because the temptation runs the other way. We had already decided to publish slowly. Finding that nobody else does is exactly the kind of result that feels like vindication and is not evidence of anything.

What it does tell you

Two things, both narrow.

First, it is a decision you cannot reverse. A 217-page day is visible in your sitemap forever. If it turns out to have been a mistake, the remedy is removing pages, which is slower and more painful than never having added them.

Second, it is the pattern the guidance describes. Google’s spam policies on scaled content abuse are explicit about generating many pages primarily for ranking rather than for people, and a section arriving complete in one day is the most legible possible signal that the pages were produced as a batch rather than as answers to individual questions.

Whether that signal is acted on, we cannot see from here.

What we are doing

Our cap is 150 URLs per deploy, and the practical rate is much lower than that.

The honest arithmetic: at ten to twenty minutes of human review per page, and around five focused hours a week, sustainable throughput is twenty to thirty pages a week. Going faster means hiring reviewers or lowering the bar, and lowering the bar removes the only reason our pages would be worth reading.

That number is not a strategy. It is just what the work costs, and every schedule we have written that ignored it has been wrong.