A client came to us last year with 4,300 indexed URLs and 190 of them earning any organic traffic at all. The rest were programmatic city-plus-service pages, generated in a weekend, each one 400 words of paraphrase with the town name swapped. Traffic had fallen roughly 70% since the previous March. They wanted to know which AI detector Google was running against them.

None. That was never the mechanism. The pages died because 4,100 of them said nothing that wasn’t already on the web, and Google’s spam policies have an explicit name for that: scaled content abuse. Your ai content seo problem is almost never that a machine wrote the words. It’s that nobody added anything.

This is the version of the article written after cleaning up three of these messes, so it’s less about what Google’s blog says and more about what actually moves rankings back.

The policy line everyone misquotes

Google’s guidance on AI-generated content has barely changed since it was published in February 2023: “our focus on the quality of content, rather than how content is produced, is a useful guide.” People read that as permission. It isn’t. It’s a statement about where the measurement happens.

The enforceable text lives in the spam policies, not the blog post. Scaled content abuse is defined as generating many pages primarily to manipulate rankings rather than help users, and the policy explicitly says this applies regardless of whether automation, humans, or both were involved. That last clause exists precisely so that “a human edited it” isn’t a defence.

Two more policies matter and get ignored. Site reputation abuse, enforced from May 2024 and tightened that November, kills third-party content published on a strong domain to borrow its authority. And expired domain abuse covers buying a dead charity domain and pointing a content farm at it. All three were announced together. That grouping tells you how Google thinks about this: same behaviour, three delivery mechanisms.

Where AI content SEO actually breaks down

There is no seo ai penalty in the sense people imagine, where a classifier scores your prose and docks you points. Public AI detectors are unreliable enough that universities have stopped trusting them, and Google has no incentive to build a ranking signal with that false positive rate. What exists instead is worse, because it’s harder to argue with.

Here’s the failure pattern we see on audit, in order of frequency:

1. Volume without differentiation. Forty articles a month, each a competent summary of the top five results. No page is individually spammy. The aggregate is. Site-level quality assessment means the good pages get dragged down with the rest.
2. Factual drift. Model output includes a plugin version that doesn’t exist, a pricing tier that changed in 2024, a WordPress function deprecated two releases ago. One of these is an error. Twenty across a site is a reliability signal for human quality raters, whose guidelines explicitly cover inaccurate content.
3. Structural sameness. Identical H2 patterns, identical intro shape, identical closing paragraph across every post. This isn’t penalised directly, but it correlates hard with having no original input, and it makes the content boring enough that engagement metrics and link acquisition both collapse.
4. Crawl dilution. Thin pages consume crawl budget. On a 4,000 URL site with mediocre server response, Googlebot spends its allocation on pages nobody wants and re-crawls your genuinely good pages every 40 days instead of every three.

Note what isn’t on that list: word count, “AI-sounding” phrasing, or whether you disclosed use of a model. We’ve published machine-assisted pages that rank in position two for competitive commercial terms. The difference was always input, never generation.

Information gain is the whole game

Google holds a patent on ranking by information gain, and whether or not that specific implementation ships, the concept describes observed behaviour well. A page that only restates what the existing corpus contains adds nothing to the index.

The test we apply before publishing anything is blunt: could a competent model produce roughly this page with no access to our files? If yes, it doesn’t go out.

Things that pass the test, all of which we’ve used on client content:

• Numbers you measured yourself. “TTFB went from 780ms to 190ms after moving object cache to Redis on a 4 vCPU box” is unfalsifiable by a model because it happened on your server. Our WordPress performance playbook is built almost entirely from figures like that.
• Failure accounts. What broke, what the error message said, what the fix cost.
• Screenshots and original diagrams, especially of interfaces that changed recently.
• Named trade-offs. “This is the wrong choice if your team is under three people” carries more weight than balanced coverage of both options.
• Direct quotes from people who did the work, attributed, with a role.

This is also why using AI as a research and drafting layer works fine while using it as a publishing layer doesn’t. The model accelerates the part you already understand and quietly destroys the part you don’t. We draw the same distinction in using AI to write code you can actually maintain.

Getting cited instead of just ranking

Ranking and being cited are now separate outcomes. Pew Research Center’s analysis of real browsing behaviour in 2025 found users clicked a result on roughly 8% of visits to pages showing an AI summary, compared with about 15% without one. Informational queries lose clicks. Commercial and navigational ones hold up much better.

Retrieval for AI Overviews and AI Mode happens at passage level, not document level. The practical consequences are concrete:

• Answer the question in the first 60 to 80 words under the heading. Not after three paragraphs of context.
• Write headings as the query, not as a clever label. “How long does a WordPress migration take” gets retrieved. “The Migration Timeline Question” does not.
• Keep entities explicit in each section. Pronouns referring back three paragraphs break chunk-level comprehension because the chunk gets extracted alone.
• Tables get cited disproportionately for comparison queries. A real HTML table, not an image of one.

Ignore llms.txt. It was proposed in September 2024, it’s a reasonable idea, and as of now no major search or answer engine consumes it. Google has said so directly. Shipping one costs nothing and does nothing.

The technical layer that still matters

Crawler control is the one genuinely new technical decision. Blocking training crawlers does not remove you from AI Overviews, because those use regular Googlebot. Google-Extended only governs Gemini model training and grounding.

# robots.txt: opt out of model training, stay fully indexed in Search
User-agent: Google-Extended
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

OAI-SearchBot powers ChatGPT search citations. Blocking it removes you
from those answers entirely, which is usually not what you want.
User-agent: OAI-SearchBot
Allow: /

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap_index.xml

On structured data, keep it boring and accurate. Article markup with a real author that resolves to a real person page, correct datePublished and dateModified, breadcrumbs, and Product or Organization where they apply. FAQ rich results have been restricted to government and health sites since August 2023, so marking up FAQs is for machine comprehension now, not for SERP real estate. Any decent theme ships this correctly; CanvasWP handles it at the template level, but verify with the Rich Results Test rather than trusting the plugin.

One rule we enforce hard: never bump dateModified for a typo fix. Fake freshness is detectable by diffing crawls, and it trains Google to distrust your dates.

The editorial gates we actually use

Machine assistance is fine. Unsupervised publishing is not. Our pipeline has four gates and a post never skips one:

1. Input gate. Before drafting, the brief must contain at least two facts not present in any top-ten result. Usually a measurement, a client outcome, or a version-specific detail. No facts, no article.
2. Draft gate. Model output is treated as an outline with prose attached. Anything numeric gets verified against a primary source or deleted. This catches roughly one bad fact per 800 words, consistently.
3. Voice gate. A human rewrites the opening and the closing entirely. Those two sections carry the most signal about whether a person was involved, and they’re also what raters read first.
4. Index gate. Two weeks post-publish, check Search Console for impressions. Zero impressions on a page after 30 days means either it’s a duplicate of something you already have, or it targets a query nobody makes. Consolidate it.

If you’re running an internal model over your own documentation rather than the open web, the calculus is different and much more favourable, which we covered in building a knowledge assistant on your own docs. Grounding in proprietary material is exactly the information gain search engines reward.

If you’ve already been hit

Check Search Console Manual Actions first. If there’s a manual action for scaled content abuse, you have a clear remediation path and a reconsideration request. If there isn’t, you have an algorithmic quality demotion, and those only lift on core updates, which means eight weeks to eight months.

Find the dead weight. On WordPress:

# List published posts under 400 words, with IDs, worst offenders first
wp post list --posttype=post --poststatus=publish --field=ID \
  | xargs -I{} sh -c 'printf "%s %s\n" "{}" "$(wp post get {} --field=content | wc -w)"' \
  | awk '$2 < 400' | sort -k2 -n

Cross-reference that list against Search Console clicks over 90 days. Anything short with zero clicks goes: 301 it to the closest relevant page if one exists, otherwise return 410 so Google drops it fast rather than re-crawling a 404 for months. Do it in one pass, not in trickles. Partial cleanups don’t shift site-level assessments.

Expect the number to be uncomfortable. On that 4,300 URL site we cut to 240 pages, added original photography and real pricing to the survivors, and recovered about 60% of previous traffic over two core updates. The remaining 40% was never real demand. It was pages matching queries that no longer send clicks to anyone.