Every few months a client asks me some version of the same question: “If we use AI to write our blog posts, will Google penalise us?” The short answer is no. The longer answer is that Google stopped caring how content is produced and started caring almost entirely about why it exists — and that shift is where most sites get themselves in trouble.
I have watched two sites in the same niche do the exact opposite things with AI. One lost roughly 60% of its organic traffic. The other grew. Neither outcome had anything to do with the model they used.
Google’s actual position, minus the panic
Google’s own documentation on generative AI content is unusually blunt: automation has been used to produce helpful content for years — sports scores, weather forecasts, transcripts — and using AI is not against the guidelines. What is against the guidelines is content produced primarily to manipulate rankings.
The policy that matters here is called scaled content abuse. It replaced the older “spammy auto-generated content” wording, and the change was deliberate. The old rule described a method. The new one describes an intent: generating many pages primarily to game search rankings rather than to help a reader. A human typing 400 thin pages by hand violates it. An AI writing one genuinely useful 1,200-word guide does not.
So the question “is AI content allowed?” is the wrong question. The right one is: would this page exist if search engines didn’t? If the honest answer is no, you have a problem, and it does not matter who or what typed it.
What actually got sites hit
The pattern in the sites I have audited after a traffic drop is remarkably consistent. It is almost never “we used ChatGPT.” It is some combination of:
- Volume with no editorial layer. 200 posts in six weeks, nobody on the team read more than a handful of them. This is the single biggest predictor.
- Programmatic near-duplicates. “Best plumbers in [city]” × 340 cities, where the only thing that changes is the city name and a stock photo.
- Zero first-hand input. The article summarises the top five results and adds nothing. No numbers from your own work, no screenshots, no opinion, no mistake you actually made.
- Confident factual errors. Wrong pricing, outdated API syntax, invented statistics with no source. This is where AI genuinely hurts you, because it is fluent while being wrong.
- Publishing into an existing mess. Sites already carrying thin, orphaned or cannibalising pages have no buffer when a core update lands.
Notice that four of those five would be problems even with a human writer on a content mill contract. AI did not create the failure mode. It just removed the cost that used to limit it.
The line I use: drafting versus publishing
Here is the distinction that has kept my own sites and my clients’ sites clean. AI is allowed to be involved in drafting. It is never allowed to be the last thing that touches the page before it goes live.
Concretely, that means AI is genuinely good at:
- Outlining a topic you already understand, so you stop staring at a blank editor
- Rewriting a paragraph you’ve rewritten four times and now hate
- Turning your rough bullet notes from a real project into readable prose
- Generating the boring-but-necessary parts: FAQ blocks, alt text drafts, meta descriptions, schema markup
- Catching gaps — “what did I forget to cover here?”
And it is genuinely bad at, or should not be trusted with:
- Any specific number, price, date, version number or statistic
- Opinion and judgement — the part readers actually come back for
- Deciding whether a topic deserves a page at all
- Technical instructions you haven’t personally run
Practically, my rule is that at least 30–40% of any published post has to be something a model could not have produced: a number from a project I ran, a decision I regret, a screenshot from my own dashboard, a client objection I have heard six times. That is the part that makes the page non-replaceable. Everything else is scaffolding.
A pre-publish checklist that takes ten minutes
I run every AI-assisted draft through this before it leaves draft status. It is short on purpose — a checklist nobody completes is worse than no checklist.
- Fact pass. Every number, name, date and code snippet gets verified against a primary source. Anything I can’t verify gets deleted, not softened.
- Experience pass. Does this page contain at least one thing only I could have written? If not, it isn’t ready.
- Duplication pass. Search my own site first. If an existing post covers 70% of this, I update that post instead of publishing a competitor to it.
- Read it out loud. Ten seconds of “in today’s fast-paced digital landscape” and the intro gets rewritten. That register is now a signal to readers, not just to algorithms.
- Attribution and disclosure. Real author byline, real bio. Google doesn’t require an AI disclosure, but the byline needs to belong to someone who genuinely stands behind the page.
Publish slower than you technically can
This is the recommendation people resist most. AI makes it trivially possible to publish daily. That does not mean you should — the constraint should be how much you can properly review, not how much you can generate.
Two posts a week that a knowledgeable person has actually read and corrected will outperform fourteen that nobody has. I would rather publish 40 solid posts a year than 400 unreviewed ones, because the 400 create a liability you then have to spend months pruning. I have run that pruning project for a client. Deleting 300 pages is much harder work than never writing them.
If you are going to scale, scale the review capacity first. Editorial throughput is the real bottleneck, and it always was.
The takeaway
Google is not running an AI detector and docking you points. It is measuring whether your pages help the person who landed on them, and it has gotten meaningfully better at that measurement. AI is a legitimate tool in that workflow — it is a bad drafting assistant to ignore and a terrible editor to trust.
Use it to remove friction, not judgement. Keep a human accountable for every published URL. Publish at the speed you can actually review. Do that, and the policy question stops being interesting, because you were never on the wrong side of it.
