You might be in the same spot as a site owner who posted to r/SEO in September. Their visitors come from all over, many of them already let the browser auto-translate pages, and running the content through DeepL before serving it was an option. They asked whether a page served in the reader's own language would rank better than one the browser translates on the fly.
Two replies in that thread were the useful ones, and each covered half of the answer. One said yes, as long as native speakers review the translation. The other said to put each language on its own URL with hreflang, and to make every version useful by itself. You need both halves. This guide covers the hreflang setup that tells Google which DeepL page is which, and the review rules that decide whether a page should be indexed at all.
HREF lang for deepl translated pages
Hey everyone, I have a webiste with an international audience. Often times my users auto-tranlsate the pages with their browser. I could translate the content before serving the page using deepl (wich I think translate better). If a webpage...
Google allows machine translation, with one condition
If you've read Google's policy wording, you may be more worried than you need to be. Google's spam policies do put "translating" on the list of automated transformations that can count as scaled content abuse. That only applies when pages exist "for the primary purpose of manipulating search rankings" and "little value is provided to users."
In June 2025, Reddit was found ranking with millions of AI-translated pages. A Google spokesperson told Search Engine Land at the time that its "policies do not strictly define content that has been translated by AI as spam." So the method itself is allowed. What remains is whether your pages have value, and Google has addressed that as well.
A year before the Reddit story, John Mueller put it plainly. His view was that if translated pages use the right wording for your audience and you think "they're good for your users, then making them indexable is fine." Where some pages fall short, he suggested noindexing those particular pages rather than blocking translated content across your whole site.
You'll still run into older advice telling you to block machine-translated pages with robots.txt, mostly in 2020-era posts and tweets. Google removed it from its documentation around the time of the Reddit story, so don't base a workflow you build in 2026 on it.
What hreflang does and doesn't do
Hreflang tells Google that a group of URLs are language or regional versions of one page, which lets it show a German searcher your German page. It won't judge quality, so a weak DeepL page with perfect tags is still a weak page. It won't detect language either, because Google's guide says Google "doesn't use hreflang or the HTML lang attribute to detect the language of a page."

The rules people trip over are few. Every version has to list itself along with every other version, and an x-default line tells Google where to send searchers who match none of them. Language codes come from ISO 639-1. You can follow one with a region code from ISO 3166-1, so de and de-AT both work, while a country code on its own doesn't. Anything outside those standards isn't supported, and that includes es-419 for Latin American Spanish.
Say your pricing page exists in three languages. Each of the three pages carries the same four lines:
<link rel="alternate" hreflang="en" href="https://example.com/pricing/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/tarifs/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
You don't need to worry about case. On September 23, Google changed every hreflang example in that guide from lowercase region codes to uppercase ones. Search Engine Roundtable pointed out straight away that nothing changes, because Google accepts both.
Google has updated the localized versions of your page help document to change all the hreflang examples from lowercase codes to uppercase codes. It doesn't matter because the hreflang value is case-insensitive; Google accepts lowercase and uppercase… https://t.co/G1xqhUhfHe
SE Roundtable@seroundtableSep 23, 202626 content formats. Published on your domain. Matched to your brand.
Guides, comparisons, listicles, case studies, and more. RankControl generates content that gets cited by ChatGPT, Perplexity, Claude, Gemini, Grok, Google AI Mode, and Google AI Overviews.

A DeepL workflow that hreflang can rely on
Most of what goes wrong happens in the setup around the translation. We'd work in this order:
- Put every language on its own URL, like
/de/and/fr/. Google's multi-regional guide tells you to avoid redirecting people between language versions automatically. If your site swaps languages by cookie or IP, crawlers may only ever see one version. - When you send HTML to DeepL, set
tag_handlingtohtml. DeepL's docs say that without it, tags "are treated as regular text," which is how links and headings come back broken. - Mark product names, code samples and legal text with
translate="no"or anotranslateclass, and DeepL will leave them untouched. - Build a glossary of your brand and product terms. DeepL keeps a separate dictionary for each language pair, so ten languages means ten term lists you have to keep in sync.
- Translate the title tag and meta description together with the body, since searchers see those before anything else.
- Put the full hreflang set on every version, either in the page head or in your XML sitemap.
- Make each page's canonical point at itself, never at the English original.
- Confirm that every URL in the set returns a 200 status.
The mistakes we found on live sites
We nearly left step 8 off as too obvious, until we checked the hreflang on three multilingual sites on September 26. Jimmy Fairly, an eyewear brand, lists 24 hreflang entries on its homepage. One of them tags /fr-us/ as fr-ca, the French-Canadian version. That URL came back as a 404 when we fetched it, both as a normal browser and with Googlebot's user agent. So the French-Canadian alternate in the set leads to an error page.
The same set contains hreflang="en-fr". You'd be forgiven for reading that as a typo, but it's valid: English for France, a sensible pairing for a store that serves English speakers there.
Bigblue, a French logistics company, has a clean, reciprocal set with an x-default on both its English and French homepages. Its French page even translates the headline, "Accélérez votre logistique," yet the title tag was left in English. That's step 5 missed on a setup that's otherwise careful.
Don't assume your own set is clean, either. Ahrefs checked 374,756 domains that use hreflang in 2023 and found at least one issue on about two thirds of them. A technical SEO on r/TechSEO shared the four problems they run into most in audits. Three of them are mechanical: missing return links, invalid codes like en-UK, and canonicals pointing at another language. The fourth they described as "technically correct tags on weak localized pages."
Hreflang mistakes I keep finding in audits
On multilingual and European ecommerce sites, hreflang is rarely "missing." The setup is usually there. It just sends messy signals. The 4 mistakes I see most: Missing return links. The French page points to the German page, but the German...
Echo pages: correct tags, wrong words
That fourth problem gets past every validator. Our name for it is echo pages: translated pages with flawless hreflang that repeat the English page line for line in another language, keywords included. Audit tools pass them, and then they collect very few impressions, because the translated keyword isn't what local buyers type.
A perfect literal translation from DeepL won't save you from an echo page. A commenter in a different r/SEO thread gave a clean example: a person in Germany isn't searching for the literal German translation of "gallery wall planner," since they use a different phrase entirely.
If you want to see the alternative, look at Personio. On its English site the headline is "Championing every side of HR's evolution," while the German site opens with "HR und Lohnbuchhaltung endlich vereint," which means HR and payroll finally united. Those are two different pitches for two different markets, and hreflang still connects the two sites correctly.
To catch echo pages, compare the search volume for your translated keyword with the volume for the phrase locals actually use. Then, after a couple of months, open Search Console, look at impressions for each language folder, and review the folders sitting near zero first.
Which DeepL pages to review, noindex or skip
Your pages don't all need the same treatment. The table gives a simple rule for each page type.
| Page type | Before it's indexed |
|---|---|
| Pricing, product and top landing pages | Native review of keywords, title, currency and examples |
| Blog posts with real local search demand | Native review, or rewrite from local keyword research |
| Blog posts with no local search demand | Leave untranslated, or translate and noindex |
| Help docs | DeepL plus a check of UI labels against the localized product |
| Legal pages | A professional translator |
If you noindex a page, take it out of the hreflang set at the same time, because every alternate in a set should be indexable. A set that points at noindexed pages sends Google mixed signals, and that tends to show up as an hreflang error in crawler reports.

Your competitors are getting cited by AI. You're not.
Every day without citation tracking is a day your competitors pull ahead in ChatGPT, Perplexity, and Claude.
What AI engines do with translated pages
Hreflang is a Google Search signal, and we found no Google statement linking it to AI Overviews or AI Mode. AI engines that run their own searches choose sources in their own way. We ran a small test on September 26 with two German queries and one Spanish one, all about project management and CRM software.
Through its API, Perplexity cited localized /de/ and /es/ pages from large English-first vendors, next to German companies' own sites. OpenAI's model with web search, also through its API, cited English pages for both German queries without a single /de/ URL, plus one Spanish help article for the Spanish query. That's three queries on one day, so read it as a snapshot. It does line up with the habit of citing English sources that we covered in our international AEO guide.
You may also come across a bigger figure: a "431% gap" in AI citations between translated and untranslated ecommerce sites. The research came from Weglot, which sells a translation plugin, and its CMO published it on DeepL's blog. Both companies sell the fix that number argues for, so read it with that in mind.
When translation isn't the right tool
You can run all of this yourself. For each new language, budget a day or two of engineering for the URLs, tags, sitemaps and glossary, plus native-review hours for every page on your must-review list. Within a couple of months, Search Console will show you which folders turned into echo pages.
The other route is to skip translation for the pages that have to win searches. RankControl's multilingual content starts from what buyers search in each market's own language and writes natively in it. It covers 23 languages across 33 markets, with one language per workspace. It doesn't translate anything, and since the articles aren't translations of one another, you have no hreflang set to maintain. AI visibility tracking then checks up to 50 of your buyers' questions every week on seven engines.
If you want to see where you stand before you decide, run a free check of your brand in AI answers.
200+ SaaS teams already track their AI citations.
They know exactly when ChatGPT mentions their brand, and when it stops. Do you?










