Machine-Translated Content and SEO: Where the Line Is

Machine-translated content is not banned by Google, and it is not automatically safe either. The deciding factor is what the published page does for a reader, not which tool produced the words. A translated page that was checked, corrected, and adapted for the people who will read it is a normal multilingual page. A thousand translated pages pushed live with nobody reading them is the pattern Google's spam policies describe as scaled content abuse.

This article answers the policy question and the practical one that follows it. First, how the rules actually read and where translation sits relative to them. Then the signals that separate acceptable from risky, a review workflow you can run at modest cost, and the technical setup that keeps unreviewed output from hurting the rest of your site. It does not cover why translated content tends to underperform on intent and phrasing, which is a separate problem from policy risk.

What Google's Policies Actually Say

Google's spam policies include a section on scaled content abuse. It targets producing many pages primarily to manipulate search rankings rather than to help people, and it says the method does not matter: human-written, automated, or a mix. Generating large volumes of pages that add little value to users is the behaviour being described.

Translation is not named as a violation in that section today, but the reasoning carries over directly. Older versions of Google's guidance on automatically generated content listed text translated by an automated tool and published without human review or curation as an example of spammy automation. The wording has since been reorganised around value and scale rather than around specific tools, yet the underlying logic is the same. If the only thing you did was run existing text through a translation engine and publish the output across hundreds of URLs, a reviewer looking at that site will see mass-produced pages with no added judgement.

Google has also been clear in its guidance on generative AI that using automation is not itself against the rules. The question is whether the content is created to help people or to rank. That framing is the one to hold onto. Machine translation is a production method, and methods are not penalised. Outcomes are.

Where Translation Crosses Into Scaled Content Abuse

There is no published threshold, and nobody outside Google can tell you a page count that triggers action. What you can do is compare your situation against the features that make a site look like the abusive case. These are judgement calls, not measurements, so treat them as a risk checklist rather than a verdict.

The pattern that draws attention is volume without review. A site that adds ten languages overnight, each with every page of the original, translated in one batch, looks very different from a site that launches one language with its twenty most important pages and expands as each set is checked.

• No human ever read the output. If no one fluent in the target language has looked at the page, nobody can vouch that it is correct, natural, or even on topic.
• Pages exist for keywords, not for readers. Translating a long tail of articles because a tool can, with no evidence that speakers of that language want them, is the core of the concern.
• Nothing was adapted. Currency, units, legal references, examples, and search terms are all still those of the source market.
• Quality is uneven and visible. Broken sentences, untranslated fragments, mistranslated product names, and leftover source-language text are what a manual reviewer sees first.
• The pages add nothing the source page did not. Duplicate value in a new language is still duplicate value unless the audience genuinely lacked access to the original.

What Human Review Changes

Review is the difference between a translation and a pipeline. Human involvement does three things. It corrects errors the engine cannot detect, it adapts the page to how people in that market actually search and buy, and it is a decision point at which someone can say a page should not be published at all.

It helps to be honest about what review is not. Skimming a page for obvious typos does not count. Neither does running a second machine pass and calling it quality assurance. A reviewer who is a fluent, preferably native, reader has to be able to change the wording, cut sections, and reject the page. If the only permitted action is approval, the step is decoration.

Review does not need to be heavy everywhere. Effort should follow importance. A pricing page, a legal notice, or a high-converting landing page deserves a full edit by a professional translator. A routine support article may be fine with post-editing, where the machine produces a draft and a language-competent person corrects it. A long-tail page that nobody on the team could review should raise the question of whether it should exist in that language at all.

A Practical Quality Assurance Workflow

A workflow that works for small teams has five steps, and each one produces something you can point to if you ever need to show that pages were curated rather than dumped.

Start by choosing which pages to translate and in what order. Pull the source pages that earn traffic or conversions in the home market, and confirm that the target market has a real use for them. Pages about a local regulation, a service you do not offer there, or a search behaviour specific to the source country should be skipped or rewritten from scratch, not translated.

• Prepare the source text. Machine translation amplifies ambiguity. Short sentences, consistent terminology, and no idioms or puns in the source produce a markedly cleaner draft.
• Build a glossary. List brand names, product names, and the key terms that must stay consistent or stay untranslated. Feed it to the engine where the tool supports it and hand it to the reviewer either way.
• Translate, then post-edit. The reviewer fixes meaning first, then flow, then search phrasing. They should check the title, headings, meta description, image alt text, and anchor text, since these are the pieces engines most often leave in the wrong register.
• Localise the page. Replace currency and units, swap examples for ones the market recognises, and check that calls to action make sense there. Verify the main keyword against how people in that market actually phrase it, because a literal translation of your English keyword is often not what anyone types.
• Record the decision. Keep a simple log with the date, reviewer, and outcome per page. It turns a vague claim of human oversight into something you can audit, and it lets you find weak batches later.

A Worked Example of Two Approaches

Take a site with 400 English articles that wants a Spanish version. The first team exports all 400 articles, runs them through a translation service, and publishes every result under a /es/ directory the same day. Nobody on the team reads Spanish. Titles are translated word for word, several product terms are rendered inconsistently, and dozens of articles discuss US tax rules that mean nothing to a Spanish-speaking audience.

The second team looks at its analytics and identifies 30 articles that already convert. A Spanish speaker reviews them against a glossary, rewrites titles using terms that appear in Spanish search results, removes two articles about topics that do not apply in Spanish-speaking markets, and publishes the set. Three months later, with evidence of how the pages perform, the team selects the next 30.

Both used machine translation. Only the first resembles the scaled, unreviewed production the policy is worried about. The second published fewer than one tenth as many pages and has a record of why each exists. That is the practical meaning of human review making translation acceptable: it limits scale to what can be supervised.

Technical Setup That Limits the Damage

Even careful teams end up with some pages that have not been fully checked. Technical controls decide whether those pages can drag down everything else.

Give each language its own crawlable URL, through a subdirectory, subdomain, or country domain. Google's guidance on multilingual sites recommends separate URLs for each language version and advises against serving translations dynamically through cookies or URL parameters that search engines cannot reliably crawl. Live in-browser translation widgets produce text that search engines never see as indexable content, so they neither help nor harm rankings.

• Use hreflang properly. Link every language version to its counterparts and back, include a self-reference, and add an x-default where appropriate. Errors in return links are the most common reason hreflang annotations are ignored.
• Use noindex for unreviewed drafts. If a page is live for users but has not been post-edited, keeping it out of the index removes it from the evaluation of your site while you finish the work. Remove the directive when the page passes review.
• Avoid blocking and then indexing. A noindex tag only works if the page can be crawled. Do not combine it with a robots.txt disallow for the same URLs.
• Keep canonical tags honest. Each language version should canonicalise to itself. Pointing a translation at the source-language page tells search engines to ignore the translation entirely.
• Watch the Page indexing report. In Search Console, filter by the language directory and look at how many pages are indexed, excluded as duplicate, or discovered but not indexed. A large excluded share is an early sign that the pages are being judged as low value.

Signals That You Have a Problem

Quality problems in translated sections tend to show up in patterns before anything dramatic happens. Crawled but not indexed pages accumulating in one language directory, impressions that appear and then vanish, and pages that rank for unrelated or nonsensical queries all point to content that search engines are not treating as useful. Bounce and engagement behaviour from visitors in that market may also look poor, although those figures are noisy and should be used only as supporting evidence.

If you suspect a problem, do not delete everything in a panic. Sample twenty pages at random and have a fluent reader score them on accuracy, naturalness, and usefulness. If most fail, pause expansion, noindex the weak set, and rework in priority order. If you ever receive a manual action notice in Search Console mentioning spam, follow the stated reasons, fix the pages in question thoroughly, and file a reconsideration request describing what you changed. Fixing only the examples Google cited, while leaving the same pattern across the rest of the site, rarely works.

The broader principle is to grow language coverage at the speed of your ability to check it. Translation engines have become good enough that the first draft is rarely the bottleneck. Review capacity is, and that is exactly the constraint that keeps a multilingual site on the right side of the line.