International SEO: why your translated site ranks in one language
Most multi-language sites are an English site with a translation layer. They rank in English and nowhere else, and the reason is structural rather than linguistic.
Most international sites are one site with a translation layer bolted on. They rank in their original language and almost nowhere else, and the teams running them usually conclude the translation was not good enough. It rarely is the translation.
The problem is that the pages were planned once, in one market, and then rendered into other languages. A page can be translated perfectly and still answer a question nobody in that market is asking.
Translation is not localisation
Buyers in different markets do not search for the same things in different words. They search for different things.
A German industrial buyer researching a component looks for a norm reference, a datasheet, a tolerance. An American buyer researching the same component looks for a use case and a customer story. Translate the American page into German and you get a fluent page that answers a question the German buyer did not ask. It will rank for nothing, because nothing is what it was built to answer.
This shows up clearly in keyword data once you stop translating your keyword list. Run the research natively in each market and the two lists overlap far less than anyone expects. In our own research for a DACH audience, the highest-volume German terms in a category regularly have no meaningful English counterpart, and the reverse holds too.
The practical consequence: research keywords in each market, in that market’s language, from that market’s search engine. Then decide what pages you need. Sometimes the answer is the same page. Often it is a different page, and occasionally the market does not want that page at all.
Hreflang is a cluster, not a tag
Hreflang is where most implementations fail, and they fail quietly.
The rule people remember is that each page points at its counterparts in other languages. The rule they forget is that the counterparts have to point back, and that every page in a cluster has to include a self-reference. A cluster where one page does not return the link is not a partially working cluster. Google treats the whole group as unreliable and falls back to guessing, which is exactly the outcome hreflang exists to prevent.
Three failure modes account for most broken clusters:
Hand-maintained tags. Someone adds a fourth language and updates three of the twelve pages. The cluster silently degrades.
Tags pointing at redirects. The counterpart URL changed, the hreflang still names the old one, and the signal is now pointing at a hop rather than a page.
Tags pointing at pages that do not exist. A market has no equivalent page yet, but the tag was generated for all locales anyway.
The fix is to generate hreflang from your content, never to write it by hand. Give every piece
of content a stable identifier that is the same across languages, group on that identifier,
and emit the cluster from the group. Then a page that does not exist in a locale cannot be
named, and a page that moves takes its cluster with it. On this site that identifier is a
field called translationKey, and the build fails if any cluster is not reciprocal.
Decide your URL structure once, and for the right reason
Subdirectories, subdomains and country domains all work. The differences that matter in practice are not the ones usually argued about.
Country-code domains send the strongest geographic signal and cost the most to run. Every domain starts its authority from zero, which means five markets means five sites to earn links for. This is the right choice when the markets are genuinely separate businesses with different legal entities, pricing and inventory.
Subdirectories keep one domain’s authority working for every market. A link earned by the English site helps the German pages. For most companies below enterprise scale this is the correct answer, and it is the one we use here.
Subdomains sit awkwardly between the two. They are treated as close to separate sites for authority purposes, without the geographic clarity of a country domain.
The decision that actually costs money is changing it later. Pick on how separate the businesses are, not on which option a blog post said was best.
Language and market are different axes
/de/ is a language. Germany, Austria and Switzerland are markets. Spanish is a language.
Colombia, Mexico and Spain are markets that share it and disagree about vocabulary, currency,
payment methods and law.
You do not need a page per market. You do need to decide, once, which market each language version is written for, and then write it for that market rather than for the language in general. A Spanish page arguing about advertiser verification rules in finance, cash on delivery, and marketplace commission is addressing Latin America. The same page translated from a European Spanish original addresses nobody in particular.
Say the choice out loud in your content brief. On this site, English addresses the United
States, German addresses DACH, and Spanish addresses South America, and the form of address
differs too: the German pages use the informal plural, the Spanish pages use the formal
usted, because that is what corporate buyers in those markets expect. Those are content
decisions, and no translation tool will make them for you.
The maintenance problem nobody plans for
A three-language site is not three times the work at launch. It is three times the work forever, and that is the part that breaks.
Every price change, every new service, every legal update now happens three times. Teams handle the launch fine and then drift: the English site gains six pages over a year, the German site gains one, and the cluster quietly stops matching.
Two things keep it honest. First, treat locales as separate content that shares a structure, not as translations that must stay in lockstep, so a market can legitimately have a page the others do not. Second, make the drift visible. Generate the hreflang clusters, and fail the build when one is incomplete. Then a page added in one language and not the others is a decision you made rather than a defect you shipped.
What to check on your own site this week
Four things, in order of how often they are broken:
- Pick one page and confirm every hreflang counterpart returns the link, and that the page names itself. If it does not, the cluster is doing nothing.
- Take your top twenty keywords in your primary market and check whether the other markets were researched natively or translated from that list.
- Check whether any hreflang tag points at a URL that redirects.
- Count the pages per locale. If one language has drifted well ahead of the others, decide whether that was deliberate.
None of this requires a replatform. Most international SEO problems are structural, they were introduced by a process rather than a technology, and a process is the thing you can change on Monday.