Google's guidance on AI-generated content has been consistent and is frequently misquoted. The position is not that generated content is disallowed. It is that content produced primarily to manipulate rankings — by any method, automated or manual — is against the spam policies.
That distinction matters, because it means the question to ask about a generated article is not "will this be detected?" It is "does this help the person who searched for it?"
Here is the checklist we use to keep the answer to that second question yes.
Editorial controls
Have a reviewer, and give them authority to kill drafts. The single largest difference between generated content that performs and generated content that does not is whether anyone was allowed to say no. A review step that only ever approves is not a review step.
Give the model something it cannot invent. Your own data, your own support tickets, your own benchmarks. An article assembled from what a model already knows competes with every other article assembled the same way. An article containing your numbers does not.
Kill the filler. Generated drafts pad: restating the question, previewing what the article will cover, summarising what it just covered. Cut all of it. The reader came for the answer.
Write titles by hand, or check every one. Titles are where generated content most obviously reads as generated — the "Ultimate Guide to X: Everything You Need to Know" pattern is a signal to readers, whatever it does for rankings.
Attribution and transparency
- Name a real author or a real team.
authorin yourBlogPostingschema should resolve to a page that describes who they are. - Show
datePublishedanddateModified, and make them true. Bumping the modified date without changing anything is a habit that outlives its usefulness quickly. - If a piece is substantially machine-drafted and lightly edited, saying so costs you very little and is increasingly what readers expect.
Technical controls
One canonical URL per idea. Generated content multiplies, and near-duplicate articles compete with each other. Before publishing, check whether the draft overlaps an existing page. If it does, improve the existing page instead.
Set rel=canonical explicitly, including on the canonical page itself.
Self-referencing canonicals are cheap insurance against parameterised
duplicates.
Keep the sitemap honest. lastmod should reflect real edits. A sitemap
where every URL changed today, every day, is ignored.
Internal-link on publish, not later. A new article with no inbound internal links is crawled late and forgotten early. Link it from at least one existing page as part of publishing.
Mark it up as BlogPosting with headline, description, author,
datePublished, dateModified and mainEntityOfPage. Validate the output —
malformed JSON-LD is discarded silently.
Volume controls
The failure mode is almost never a single bad article. It is a hundred adequate ones published in a week.
Two guardrails worth enforcing:
- Cap publishing rate to something a reviewer can actually read. If nobody read it, nobody should have published it.
- Prune. Pages that get no impressions after two indexing cycles are not waiting to break through. Improve them or remove them. A smaller site of pages that perform beats a large site with a long tail of nothing.
The short version
| Do | Don't |
|---|---|
| Add proprietary data | Restate what the model already knew |
| Review with authority to reject | Approve by default |
| One canonical page per idea | Publish overlapping variants |
| Publish at reviewable volume | Ship a hundred drafts a week |
| Prune non-performers | Let the long tail rot |
Nothing here is specific to AI. It is the same standard applied to any content operation — generation just makes it possible to violate it much faster.
NOPPBO builds the technical half of this list into publishing: canonical tags, schema, sitemap accuracy and internal linking are handled when a post goes out. The editorial half is still yours, and should be.
Related: Programmatic SEO: What It Is, and When It Actually Works.