When translated content hurts your rankings

Adding a language should never cost you rankings. When it does, the cause is almost always mechanical rather than editorial, and the business never finds out because nothing looks broken.

Here are the five ways I actually see it happen, in the order they cost you the most.

Does machine translation get me penalized?

No, and the sloppy version of this claim has been repeated so often that it now shapes budgets.

Here is the trace. Google's spam policies, read live, contain no clause about translation on its own. The nearest thing is one bullet inside scaled content abuse, and the qualifiers are the whole point: "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."

Read what that describes. Content that was not yours, turned into many pages, adding nothing. The policy's own definition of the abuse is "when many pages are generated for the primary purpose of manipulating search rankings and not helping users."

A restaurant running its five real pages through a translation tool and having a Spanish-speaking employee correct them before publishing is not in that policy. An earlier version of this article said Google's spam policies name automated translation without human review as an example of scaled content, which was how the rule read before Google consolidated its content policies. That is no longer the wording, and the difference matters, because the current wording turns on scale and on where the content came from.

The honest version is narrower and more useful. Unreviewed machine translation is a quality problem and a trust problem before it is ever a policy problem. It reads wrong to the exact customers you are courting, and respecting the community you are writing for starts with not sending them a machine. That cost lands before any ranking effect does.

Is a translated page duplicate content?

Almost never, and the penalty people are afraid of does not exist.

The claim to retire is the "duplicate content penalty." Google put it to bed on its own blog on 12 September 2008, in a post titled "Demystifying the 'duplicate content penalty,'" and the sentence is unambiguous: "There's no such thing as a 'duplicate content penalty.'" The post goes on to name what is actually penalized, which is scraping other people's content and republishing without adding value. Eighteen years later, agencies still quote the penalty to justify work.

Google's canonicalization documentation then draws the line for language versions precisely: "Different language versions of a single page are considered duplicates only if the primary content is in the same language (that is, if only the header, footer, and other non-critical text is translated, but the body remains the same, then the pages are considered to be duplicates)."

So a genuinely translated page is not a duplicate. A page where you translated the menu bar and the footer and left the body in English is. That is the actual rule, and it points at a build problem rather than a policy problem.

What breaks when both languages share one URL?

Only one version gets indexed, and you do not get to pick which.

If your language switcher swaps the text on the page without changing the address, search engines see one page. Whatever was there when the page was crawled is what exists. The other language is invisible, which means you have paid for content that cannot rank for anything.

Google's multilingual guidance is direct about the fix. It "recommends using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page." Each language gets its own address, usually a folder like /es/ or /ko/ on your main domain.

Once they have separate addresses, hreflang is the small tag set that connects them, and on a site this size it is a fifteen-minute job.

Why would a canonical tag delete my translated page?

Because a canonical tag pointing at the English version nominates the English page as the one Google should show.

Google lists rel="canonical" as "a strong signal that the specified URL should become canonical," second in influence only to a redirect. Point every Spanish page at its English counterpart and you have told Google, in the strongest annotation available short of a redirect, that the Spanish pages are not the version to serve.

The nuance worth knowing is that it is not absolute. Google's own documentation says "Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule." This is where the failure gets confusing. Some cross-language canonicals get honored and the pages vanish; others get overridden and the pages survive. The owner sees inconsistent results, concludes the tag is not the problem, and leaves it in place.

Each language version should carry a canonical pointing at itself. That is the whole rule, and it removes the coin flip.

Here is the audit, and the arithmetic is the useful part. List your second-language URLs. Say there are six. For each one check five things: does it have its own address, does its canonical point at itself, is it indexed in Search Console, does its hreflang partner point back, and is the conversion path translated to the end. That is 30 checks.

On a plugin-built bilingual site a typical first pass fails twelve of them, usually six self-canonical failures plus a cluster of English form fields. That is 40%derived of your checks failing. The six canonical failures are one line of code each. The form is an afternoon.

Then look at the number that decides everything: how many of the six are indexed. If the answer is two, four of your six pages do not exist as far as search is concerned, which is 67%derived of the work you paid for sitting invisible. Fix the canonicals first, because until they are right nothing else you do to those pages can be observed.

What about automatic redirects by location?

They hide half your site from search engines and irritate customers.

Redirecting a visitor to a language version based on their IP address feels helpful. Google's guidance says to avoid it: "Avoid automatically redirecting users from one language version of a site to a different language version of a site. For example, don't redirect based on what you think the user's language may be." It adds that these redirections "could prevent users (and search engines) from viewing all the versions of your site."

The crawler problem is specific and documented. Google warns that "most, but not all, Google crawls originate from the US" and that Googlebot "sends HTTP requests without setting Accept-Language in the request header." A system that decides what to show based on either of those signals shows Googlebot one version, forever. Google's own instruction on the geotargeting side is blunt: "Don't use IP analysis to adapt your content."

It also guesses wrong constantly. A Korean speaker in San Jose gets English. An English speaker traveling gets something else. Neither can easily get back.

Do this instead: serve the requested URL, and add visible links to the other language versions. Google suggests exactly that, "adding hyperlinks to other language versions of a page," so the customer chooses and the crawler sees everything.

The same principle applies to anything that changes what a visitor sees without changing the address. Businesses run into related problems with availability and hours, which is part of why a restaurant can appear to disappear from Maps at dinner time without anything actually being wrong with the listing.

What about pages that are only half translated?

They perform worse than either language on its own, and Google explains why.

Its multilingual guidance asks you to help it determine the page language "by using a single language for content and navigation on each page, and by avoiding side-by-side translations." It then names the exact failure: translating only the boilerplate while keeping the bulk of the content in one language "can create a bad user experience if the same content appears multiple times in search results with various boilerplate languages."

That is also the one case where your language versions really are duplicates, per the canonicalization rule quoted above. Half translated is not a partial win. It is the specific configuration that triggers the problem everybody was worried about in the first place.

The common version is a translated page with an English form, English buttons, and an English confirmation screen. The customer reads in their language right until the moment they were going to convert, then hits a wall. That is the worst possible place to put the wall.

Translate the whole path, including the form fields, the error messages, and the confirmation. If you cannot do the whole path, do a smaller page completely rather than a large page halfway.

The same completeness rule applies offline. If you collect reviews through a tablet or a code at the counter, that flow needs to work in both languages too, and a QR or kiosk review flow only works if it stays simple in whichever language the customer picked.

What does a healthy multilingual site look like?

Small, complete, and human.

Four or five pages per language, each written or edited by a person who knows the business. Separate URLs. Self-referencing canonicals. hreflang connecting the versions. No automatic redirects. Every path translated end to end.

That is a much smaller project than most translation proposals describe, and it outperforms the large version because none of it is filler.

The rest of the return comes from things that are not on your website at all. Your profile, your reviews, and the people who recommend you do more work than any page, which is the underlying point of building for a bilingual customer base rather than building a second website.

What to do this week

Open one translated page and view the source. Find the canonical tag. If it points at the English page, that is your fix and it is worth doing today.

Check whether your language switcher changes the URL. If it does not, you have one indexed page, not two.

Run the 30-check audit above and write the failure count down with today's date.

Search Console, coverage report, filter for your second-language URLs. Confirm they are indexed at all.

Turn off any automatic redirect based on location and replace it with visible links to the other version.

Then walk your own conversion path in the second language, from landing page to confirmation screen, and note every point where it switches back to English.

Questions about a translated page that is not showing up?

Email me at eric@seod.com with the URL of a translated page and I will check the canonical tag, the URL structure, and whether it is indexed, then tell you in one message which of these five problems you have. This is a five-minute technical check and it is the one I get asked for most.

I answer these personally. If the page is technically fine and the issue is the writing, I will tell you that instead.

Or keep reading more on multilingual and community marketing.