Multilingual SEO best practices: pick the languages before the tags

Multilingual SEO best practices usually start at the hreflang tag. The expensive decision is earlier: a four-row score that ranks candidate languages against data you already have, and a table of the page types not worth translating at all.

Implementation6 min read2358 views
Multilingual SEO best practices: pick the languages before the tags

Most multilingual SEO best practices start at the tag and stop there. The expensive decision comes earlier: which languages, in what order, and which pages you do not translate at all. Rank the languages against data you already have, translate the smallest set that can be maintained, and only then wire up the annotations.

Before you start

You need two exports: Search Console impressions and clicks by country for the last 12 months, and whatever your business calls a conversion, also by country. Without both, every language decision below becomes a guess about a market you have not seen. If the site is too new to have either, translate nothing yet — an untranslated site that ranks is worth more than five languages nobody arrives from.

Why multilingual SEO best practices start before the translation

A translated page is not a one-time cost. It is a page that has to be updated every time the original changes, checked when a price moves, and eventually judged the same way as the original. Twelve languages means twelve copies of every future edit, forever.

There is also a hard technical floor. Google's guidance on multi-regional sites, last updated 2025-12-10 and read 2026-08-22, says: "You can help Google determine the language correctly by using a single language for content and navigation on each page, and by avoiding side-by-side translations." A half-translated page — English navigation, translated body — is the case that guidance is warning about.

The right number of languages is the number you can still update in a year.

How to rank the languages

Score each candidate language on four things, zero to two points each, then translate down the list until the maintenance cost stops being comfortable.

  1. Existing demand. Impressions from countries where that language is dominant, over 12 months. Two points if the country is already in your top ten by impressions.
  2. Existing conversion. Two points if that country has ever converted, one if it has traffic but no conversions, zero if neither.
  3. Support capacity. Two points if someone can answer an email in that language within a working day. Zero if nobody can.
  4. Maintenance load. Two points if the pages you would translate change less than quarterly. Zero if they change weekly.

Run the score on paper before anyone opens a translation tool. Four rows and a candidate list of five languages takes about twenty minutes, and the output is a ranked list you can defend to whoever is paying for it. The point of scoring rather than arguing is that three of the four rows come from exports you already have, so the disagreement moves from taste to data.

Six points or more goes in the first wave. Four or five waits for the second. Below four, the language does not pay for its own upkeep, and adding it costs you the attention the first wave needed. The support row is the one people delete from the scoring, and it is the one that decides whether translated traffic turns into anything.

The deliverable: what to translate, what to leave

Not every page type earns a translation. This table is the second half of the decision.

Page typeTranslateWhy
Product and pricingYes, firstThe pages the decision is made on
Core how-to guidesYesThey earn search traffic and age slowly
Docs and referenceYes, if support can follow upUntranslated docs plus translated marketing sends the wrong signal
News and release notesNoDated content that will never be updated again
Field tests and one-off data postsNoThey stop being current; a stale translation is worse than none
Legal and termsOnly with reviewA machine-translated contract is a liability, not a page

Docs are the row that gets argued about. Translating marketing pages while leaving the documentation in English produces a visitor who converts in one language and then cannot use the product in it, which is a support problem before it is an SEO problem. If support cannot follow up in that language, the honest sequencing is to fix that first and translate second.

The rule underneath the table: translate pages whose value is stable, skip pages whose value is a date. That is the same boundary used to decide whether a page belongs in a handbook at all, and it is worth revisiting on the pages you already have in deciding whether to refresh, merge or delete old pages.

The hreflang self-check

Six items, all from Google's own documentation on localized versions, last updated 2025-12-22 and read 2026-08-22. Run them after the pages exist, not before.

CheckWhat Google says
Return links"If page X links to page Y, page Y must link back to page X"
Self-referenceInclude one link element "for each page variant including itself"
Language code formatISO 639-1, with an optional ISO 3166-1 Alpha 2 region
Region code validityReserved codes are ignored — EU, UN and UK "doesn't have an effect on Google Search"
FallbackAdd an x-default for unmatched languages
Link back to the strong oneLink new language pages bidirectionally to the "originating/dominant language(s)"

The region code row catches more sites than it should. UK is not a valid region code for the United Kingdom in this context; the assigned one is GB, and Google's documentation states plainly that the reserved ones have no effect. If your annotations were hand-written, check that row first. In our own crawl of 27 large homepages, only 10 declared hreflang at all and 2 of those omitted x-default, so the failure rate on this is not a beginner problem.

Where this goes wrong

Three patterns, and each one collides with something Google has published rather than with an opinion.

  • Redirecting visitors by IP address. Google's multi-regional guidance says to avoid automatically redirecting users between language versions, and separately: "Don't use IP analysis to adapt your content." A language switcher is the supported pattern.
  • Machine-translating the whole site in one afternoon. It produces pages nobody on your team can proofread, in languages nobody on your team can support, and every one of them is now yours to maintain.
  • Treating hreflang as the project. The annotation tells Google which version to show; it does not make a bad translation rank. It is the last step, not the work.

What this chapter cannot decide for you

It cannot tell you the revenue a language will produce. Nobody can, before the pages exist, and any tool that quotes you a number for it is extrapolating from someone else's site. The scoring above ranks candidates against evidence you already hold; it does not forecast.

It also does not apply to a site with no international traffic at all. If your last 12 months are 95% one country, the honest answer is that multilingual SEO best practices are not your bottleneck this quarter, and the same effort spent on the pages you already rank for will pay back sooner. Where that effort should go is the subject of the QueryWin handbook path.

Common questions

How many languages should a small site translate into?

As many as score six or more on the four rows above, which for most small sites is one or two. The constraint is maintenance, not translation cost — the first edit after launch is when the real bill arrives.

Is machine translation bad for SEO?

Google does not publish a rule banning it, so we are not going to invent one. What its documentation does say is to keep one language per page and avoid side-by-side translations, and its helpful content guidance asks whether automation use is disclosed. Unreviewed output tends to fail the second question rather than the first.

Do I need hreflang if I only have two languages?

Google states it might still find alternate versions without it, but that it is usually best to indicate them explicitly. With two languages the annotation is four lines total, so the cost of doing it properly is close to zero.

Should each language live on a subdomain, a subfolder or its own domain?

Google's guidance suggests a URL structure that makes the site easy to geotarget, and does not name one winner. Pick the one your stack can actually maintain, because moving later costs more than choosing imperfectly now.

Part of the QueryWin handbook · Level 2

Multilingual SEO best practices: pick the languages before the tags