Google’s spam policies page was last updated on 28 August 2026. The section that matters for anyone generating pages reads:
Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.
Under it, the list of examples. One of them names the thing a spinner does:
Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users
Synonymizing is listed next to translating as an obfuscation technique. If you run a spintax engine, that sentence is about your tool, and the question is not whether Google frowns on it in the abstract. It is whether the pages you produce are the pages that sentence describes. That turns out to be measurable, and the measurement points somewhere uncomfortable: the metrics people use to prove their pages are “unique” reward exactly the pattern Google names.
How it is enforced, as far as Google says
Three spam updates rolled out in 2026, each listed on the Search Status Dashboard with its duration: 24 to 25 March, 24 to 26 June, and 18 to 21 August. The August incident page says only that it applies globally and to all languages. Google does not publish which policy an update leans on, and the Manual Actions report in Search Console has no entry named scaled content abuse. It appears once, inside the entry for major spam problems, next to the older entry for thin content with little or no added value.
What Google does say is how the policy is meant to be read. From the March 2024 post that introduced it:
This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it’s created.
And, on the question everyone asks:
Our new policy is meant to help people focus more clearly on the idea that producing content at scale is abusive if done for the purpose of manipulating search rankings and that this applies whether automation or humans are involved.
The method is not the offence. The pages are. So the useful question is what a synonymizer actually does to a set of pages, in numbers.
Fifty pages, one skeleton
The pool is fifty city pages for one service, a plumber, about 70 words each, the shape of a thousand programmatic sites. The skeleton has 32 places where a synonym set can be switched on, three options each. The engine is the open @spintax/core, the metric is built from the same two ingredients its n8n node uses to judge pool uniqueness: five word shingles over normalised text, and Jaccard similarity between shingle sets. Here it is taken between every pair of pages and averaged. A pair of identical pages scores 1.000; pages with no five word run in common score 0.
| Synonym slots switched on | Mean pairwise similarity | What changed on the page |
|---|---|---|
| 0 | 0.599 | only the city name, four times |
| 4 | 0.511 | four phrases |
| 8 | 0.434 | |
| 16 | 0.300 | |
| 24 | 0.142 | |
| 32 | 0.037 | nearly every other word |
At 32 slots the fifty pages share almost nothing a shingle metric can see. On paper the skeleton can produce 3 to the power of 32 distinct renders, about 1.85e15. Every one of them says the same thing. Not one carries a fact the others lack, and a reader who has seen one has seen all of them. That is the row the policy example describes, and the number that looks like success, 0.037, is the number of the offence.
Now the other direction. Same skeleton, no synonyms at all, but five facts per city bound to variables: the postcode, the year the branch opened, jobs completed, typical arrival time, the local rating.
| Pool | Mean pairwise similarity |
|---|---|
| Five facts per city, no synonyms | 0.405 |
| Facts, three sentence forms per slot, sentence order permuted | 0.051 |
The factual pages score worse on uniqueness than the synonymized ones, 0.405 against 0.037. By the metric, the pages that tell a reader in Boise something about Boise are the suspicious ones, and the pages that tell every city the same thing in different adjectives are clean. A uniqueness score measures variation density. It does not measure whether a page has anything to say.
The deletion test
There is a test that does. Replace every value that came from data with a placeholder and measure again. What survives is the template, and the template is what the reader gets on every page.
| Pool, values deleted | Mean pairwise similarity |
|---|---|
| 32 synonym slots | 0.071 |
| Five facts, no synonyms | 1.000 |
| Facts plus sentence forms and order | 0.103 |
The factual pool collapses to 1.000: with the facts gone it is one page under fifty names, and that is honest, because the facts were the page. The synonymized pool stays at 0.071 with nothing in it, which is the whole point. It was never carrying information, so removing information does not change it.
The rule that falls out of this is short. Delete every value that came from data. If what is left is fifty pages, you built fifty pages of synonyms and Google’s example names them. If what is left is one page, you have one template and a dataset, and the pages are worth exactly what the dataset is worth. The whole experiment is one file, measure.mjs, which needs Node and the engine from npm and renders the pool in about a second:
npm install @spintax/core@0.6.1
node measure.mjsWhere the line runs
| Pattern | Google’s example | What the engine can tell you |
|---|---|---|
| One skeleton, synonym slots, a city name | synonymizing as obfuscation | nothing useful: the score goes down as the offence goes up |
| One skeleton, per page facts from a dataset | a template around data; the policy asks whether the data helps | the deletion test says how much of the page is data |
| Several skeletons, facts, permuted structure | the same question, with better prose | pool uniqueness and lint, form only |
| Thousands of pages, any of the above, no one reads them | “many pages generated for the primary purpose of manipulating search rankings” | nothing: scale of intent is not in the text |
The third party case studies of the August update, published by GSQi on 31 August, describe sites of the last kind: programmatic pages across countries with AI written sections, one site with over 1.5 million indexed URLs and about 85 percent programmatic content. Those are their tracking numbers, not Google’s, and none of the reports say which policy was applied. They do describe the shape, and the shape is the top row of the table at scale.
Where it breaks
Everything above measures form. A shingle metric can be gamed by a spinner in an afternoon, which is the first result. The deletion test cannot be gamed by a spinner, but it can be satisfied by garbage data: a dataset of made up ratings and invented arrival times passes it and is worse than synonyms. Lint finds a word repeated across two slots and a pronoun that lost its noun; it does not find a claim that is false.
And no metric knows why the pages exist. Google’s definition turns on purpose, “the primary purpose of manipulating search rankings”, and purpose is not in the text. A catalogue with a thousand products has a thousand pages because it has a thousand products. A site with a thousand cities has a thousand pages because someone typed a thousand cities into a spreadsheet. The engine renders both.
What spintax is for, then
The reading that survives the numbers is that spintax is a packaging layer for data, not a substitute for it. Variables, conditionals and plural agreement exist so that one template can say a true thing about each of a thousand records without the grammar falling apart; the authoring guides on spintax.net teach it in that order, data first, synonyms last. A template with thirty synonym slots and one variable is the case the policy describes. A template with five variables and three sentence forms is a product feed with prose on it. The same arithmetic runs the other way in cold email, where the question is how few groups a sending volume can get away with; that one is measured on its own.
The tooling follows the same line. The n8n node’s uniqueness operation reports the shared shingle footprint of a pool, and its documentation is blunt about what the number can and cannot do: one template scores 0.962, six templates of the same pool size score 0.017, and adding variants of the same template cannot fix it, because the skeleton is fixed by the template. That is the 32 slot row again, from the other side.
Where the manual path runs out
For one template and a spreadsheet, the deletion test and the script above are the whole job: render, delete, compare, read a few pages by hand. It gets harder when the pool is built in a pipeline, a model drafts the template, a feed supplies the facts, and nobody reads page 812. That is the point where the check has to live inside the pipeline rather than after it, and it is what the Spintax node for n8n does: validate the draft, render the pool, lint every render, measure the pool’s uniqueness, and route what fails back to the model with the offending token named. The engine underneath is the same open package this article measured with. Its uniqueness check reports a pool footprint and the near-duplicate pairs, two different aggregations from the pairwise mean quoted here, so read its numbers on their own scale. The deletion test is not built into it; that one stays a script you run.