I published over a hundred blog posts in two weeks. Here is the risk I walked into.

I built a static blog generator at the start of September 2026 and used it to publish more than a hundred articles across six sites inside about a fortnight.

That is a sentence that gets you applause on one part of the internet and a manual action on another.

The interesting thing is that the line between those two outcomes is not the number, and I had assumed it was.

1. What I built

A dependency-free Python static site generator. Markdown in, server-rendered HTML out, one command per site.

It writes post pages, an index, RSS, a sitemap and a JSON-LD graph into whichever repo owns that domain. Six domains run off it.

The engineering took a few days. That part was fine and it is not what this post is about.

2. The policy I should have read first

Google's scaled content abuse policy was formalised in the March 2024 spam policy update. It targets generating many pages primarily to manipulate search rankings, with little or no value added for users.

I read it after I had shipped most of the content, which is the wrong order.

The relief, when I did read it, was that the definition turns on purpose and outcome rather than method or speed. Google has been consistent that it is not about whether software helped or how fast you went.

So volume is not the offence. That was the assumption I had been quietly worried about and it was wrong.

3. The complication: the real line is much closer than the policy sounds

Reading it carefully made me less comfortable, not more.

The reported pattern behind enforcement is volume publishing with no editorial review, thin factual depth and no first-hand experience. Sites matching that profile have reportedly seen heavy traffic losses.

Two of those three were things I could point at and say I had handled. Every article had a named source next to every external number, and a person read each one.

The third is the one that got close. First-hand experience is thin when you are writing the fortieth article in a week, and the temptation to produce article thirty-eight as a slightly rotated version of article twelve is enormous, because it is the fastest remaining move.

I did not always resist it.

4. The test I use now

Would a different person, with a different problem, search for each of these?

Three articles on one subject are legitimate when they are what changed, what it costs you, and what to do about it. Those are three people at three moments.

Three phrasings of the same answer are one article and two liabilities, and the two liabilities drag on the first one because the site now looks like it is filling a keyword list.

I have deleted and merged since. That felt like losing work and it was the work paying for itself.

5. Why the ceiling should be lower than the target

I had a number in my head for how many articles a week the system could produce.

Treating that as a quota is the failure mode, because the system can always produce one more and the marginal one is always the weakest.

The honest version is that the capacity is a ceiling and the output should be whatever genuinely clears the bar, which is usually much less.

Finishing a week with forty strong articles instead of two hundred and fifty is the correct outcome, and it does not feel like it at the time.

6. What I would do differently

Read the policy before building the machine, not after.

Write the deduplication test into the process rather than applying it afterwards, because afterwards means deleting work you are attached to.

And set a rule that no article ships without one thing in it that could only have come from having done the work. A number I own, a mistake I made, a decision with a date on it. That rule alone would have killed about fifteen of the pieces I published, all of which were the weakest ones.

7. The part I cannot tell you yet

Whether any of it worked.

The pages are a fortnight old. Search Console on these properties was verified but still returning nothing useful as of mid-September 2026, so I have no query data to read.

Anyone who publishes a hundred articles and reports results two weeks later is reporting noise with a chart around it. I would rather say the honest thing and write the follow-up in six months.

That follow-up will be more useful than this post, and it will only be useful if I do not pre-announce the conclusion now.

The short version

• Read the scaled content abuse policy before you build anything that publishes at volume.
• The policy turns on purpose and outcome, not on speed or whether software helped.
• Volume is not the risk. Near-duplicates at volume are the risk.
• Test every new article against whether a different person would search for it.
• Treat your production capacity as a ceiling and never as a quota.
• Require one first-hand element per article, and kill the ones that fail it.
• Do not report results two weeks in. Wait, then report them honestly.

I write these up as they happen rather than once they have a tidy ending.