How to review machine-translated and localised content before it goes live

A site can now be translated into five languages in a day. A translation engine or a language model produces copy that reads well enough for nobody to question it, and that is the problem: nobody questions it. A page can be grammatically clean and still quote the home currency, offer a payment method nobody in the market uses, describe a returns policy that does not apply there, and target words that people in that country never type. Translation at scale, with little value added, is also a named example of abuse in Google's spam policies. The fix is a review process that spends human attention where a page is worth it and checks the rest by machine and by sampling.

The structural side of running several markets, from URL choice to hreflang, is covered in the international SEO guide.

Google's spam policies define scaled content abuse as generating many pages for the primary purpose of manipulating search rankings and not helping users, and they add that this applies no matter how the content is created. One of the listed examples is scraping feeds, search results or other content to generate many pages, including through automated transformations like synonymising or translating, where little value is provided to users.¹

When Google introduced the policy in March 2024, it said the policy built on its earlier one about automatically generated content, so that it could act on scaled content abuse whether the content was produced through automation, human effort or a mix of the two.² The method is not the test. A team of freelancers producing unchecked translations of every page in bulk is in the same position as a script.

Google's guidance on generative AI content goes further on review. Using generative AI tools to generate many pages without adding value for users may violate the scaled content policy, and all AI-generated content should be fact-checked and reviewed manually for accuracy before it is published. That review also covers metadata such as title elements, meta descriptions, structured data and image alt text.³ Many translation pipelines now run on language models, so I would treat this as the standard for translated pages too. The metadata point is the one most often missed, because translated titles and descriptions are generated in bulk and rarely read by anyone.

The policy also offers a way out for content you are not ready to stand behind: if you are hosting such content, exclude it from Search.¹ That becomes the bottom tier of the review model below.

Google already translates some results itself

For some languages, Google may translate the title link and snippet of a result that is not in the language of the search, and a user who clicks it sees a machine-translated version of the page. Google does not host the translated page, and the feature covers a list of languages that includes French, German, Spanish and Portuguese.⁴ The implication is my judgement, not Google's: an unreviewed machine translation of your English page offers a searcher little that this feature could not already give them. The value of a localised page comes from what a translation engine cannot supply, such as local prices, local terms and the words that market uses.

Half-translated pages are a separate problem. Translating only the boilerplate while keeping the bulk of the content in one language can create a bad experience when the same content appears several times in results with different boilerplate languages.⁵ Different language versions of a page are considered duplicates only if the primary content is in the same language.⁶ A page with a German menu and an English body is, to Google, a duplicate of the English page.

The W3C describes localisation as adapting content to meet the language, cultural and other requirements of a specific market. Its list of what that can involve includes numeric, date and time formats, currency, address and contact formats, varying legal requirements, and references that may be misread or seen as insensitive in another culture.⁷ A translator working sentence by sentence will catch few of these, because most of them are business decisions.

There is survey data on how much buyers care, from an analyst firm that researches the language services industry. CSA Research's 2020 survey of 8,709 consumers in 29 countries found that 76% preferred to buy products with information in their own language. The same survey found 65% preferred content in their language even if it was poor quality, and 66% used online machine translation.⁸ I read the first figure as the case for translating the pages people buy from. The second says buyers will put up with imperfect copy, which is a low bar for a page that also has to pass a search engine's spam policy.

Keyword research has to happen in each market

Translating a keyword list gives you correct words, which is a different thing from the words people search with. British English says mobile phone where American English says cell phone, and German speakers commonly say Handy. Spanish in Spain uses ordenador for a computer, where much of Latin America says computadora. A market that shares your language can still need its own research, and a market that does not share it always does.

Full human review of every page is rarely affordable, and no review at all is the pattern the spam policy describes. The middle ground is to decide, page by page, how much checking each one gets. I sort pages with two questions: what does it cost if this page is wrong, and how many people in this market will read it?

Tiers are not permanent. A tier 3 help article that starts drawing traffic from the market moves to tier 2. A tier 4 page that Search Console shows local searchers looking for gets translated. Review the tier list each quarter against the market's data.

Automated checks cannot tell you whether a translation is good. They are very good at finding pages that are obviously broken, which is where to start. Google determines a page's language from its visible content,⁵ so leftover source-language text on a translated page is the first thing to look for. These checks assume the market's pages have been fetched into a folder, for example with curl from the sitemap.

• Leftover English. Count common English words in the visible text of a German page: curl -s https://www.example.com/de/preise/ | sed 's/<[^>]*>/ /g' | tr -cs '[:alpha:]' '\n' | grep -ciwE 'the|and|with|your|for'. A handful is normal (brand names, code). Dozens means an untranslated block. In PowerShell: ((Invoke-WebRequest -UseBasicParsing https://www.example.com/de/preise/).Content -replace '<[^>]+>',' ' -split '\W+' | Where-Object { $_ -in 'the','and','with','your','for' }).Count.
• Placeholders that survived translation. grep -lF '{{' pages/de/*.html lists pages showing raw template variables, a common failure when a translation tool alters the placeholder syntax.
• The wrong currency. grep -l '£' pages/de/*.html lists German market pages that still show sterling. Check it against the structured data, which should carry the same price and currency as the page.
• Lang attributes. grep -ho '<html[^>]*lang="[^"]*"' pages/de/*.html | sort | uniq -c shows which lang values the German folder declares. Any value other than de, or a longer tag that starts with the de language subtag such as de-AT,¹⁴ is a template bug. Google does not use the attribute to detect language,⁵ but browsers and screen readers do, and the W3C advises always declaring it on the html element.¹⁵
• Titles and descriptions. Export them for the market with a crawler and have a native speaker read the list in one sitting. Reading them as a list is quick, and it catches the bulk-generated metadata that the generative AI guidance puts in scope for review.³
• Length outliers. A translated page far shorter than its source usually lost a section. Compare word counts per pair and read the extremes.

For the human sample, give reviewers a short error list (meaning changed, wrong term, locale error such as currency or date, awkward but correct) and log each error against the template it came from. If one template produces most of the errors, fix the template or its glossary and re-run the batch, instead of correcting pages one at a time. Only pages that pass go into the hreflang set. How to audit hreflang covers checking that set once it is live.

After launch, read Search Console by market. Filter the Performance report by country and compare the queries and pages with what you expected.¹³ Queries in the source language landing on the market's pages, or market pages with impressions and almost no clicks, point to vocabulary or titles that need work. The Search appearance filter also shows clicks and impressions from Google's translated results,⁴ which is a cheap way to spot a language where people already find you through Google's own translation and might be worth localising properly.

The Read skill in my open-source pack, run with its international profile, checks each locale for machine-translated boilerplate and a correct lang attribute. It is a quick first pass before human review.

A fictional scheduling software company has an English site of about 1,400 pages: 40 marketing pages, 300 help articles, 1,000 blog posts and a handful of legal pages. It is launching in Germany, Austria and France, with prices in euros. Search Console already shows German and French queries reaching its English help centre.

The company ends up with about 375 localised pages per language instead of 1,400, and every one of them has been checked by a person or a sample. The pages closest to sign-ups got the most attention, which is where the SaaS SEO guide would put it too. A shop would run the same tiers over categories, product templates and delivery pages, with the catalogue and feed questions covered in the ecommerce SEO guide.