Multilingual Website SEO Done Right: hreflang, URL Structure and a Translation Workflow

Two separate questions decide whether a multilingual site works in search. The first is what language a page is in. Google answers that itself: its multi-regional guidance says it uses the visible content of the page and does not use code-level signals such as lang attributes or the URL. A page whose main text is still in English is an English page, whatever its address or markup says.

The second question is which of several equivalent pages to show a given searcher. That is what hreflang is for. Google's documentation on localized versions describes hreflang as a way to tell Google that pages are localized variations of the same content, so that Search can point users to the right version for their language or region. Without it Google may still find the alternates, but Google recommends declaring them explicitly.

Adoption is growing quickly. The SEO chapter of the 2025 Web Almanac, which analyzes the HTTP Archive crawl, found hreflang on 20.3% of desktop pages and 19.7% of mobile pages, which the authors describe as roughly double the previous year's rate. More sites are declaring language versions, which also means more sites are getting the details wrong.

Every language version needs its own URL. Google's guidance compares four options and recommends against only one of them, URL parameters. The right choice depends less on SEO than on how many markets you serve and who will maintain the site.

Many sites try to be helpful by sending visitors to a language based on their IP address or browser. Google advises against it: avoid automatically redirecting users from one language version to another, and do not use IP analysis to adapt content, because IP location analysis is difficult and generally not reliable. A bilingual Montreal resident, a Japanese traveller in Toronto and a crawler all break those assumptions.

The pattern that works is simple: every language version is reachable at a stable URL, each page links to its counterpart in the other languages, and a home page or language selector can carry the x-default annotation for visitors whose language you do not serve. If you do suggest a language, use a dismissible banner rather than a redirect.

Google accepts hreflang in HTML link tags, HTTP headers or an XML sitemap, and says the three are equivalent. Pick one. Using all three gives no extra benefit and makes the set harder to keep consistent. HTML tags suit most sites; the sitemap suits very large sites; the HTTP header is for files such as PDFs. Whichever you choose, these rules from Google's documentation apply.

One of the most damaging mistakes on bilingual sites is a canonical tag on the French or Japanese page that points to the English page. A canonical tells Google which URL to index; pointing translations at English asks Google to treat them as duplicates and keep only the English URL. Google's canonicalization guide says that when you use hreflang, you should specify a canonical page in the same language, or the best possible substitute language if none exists.

In practice each language version carries a self-referencing canonical plus the full hreflang set. Two related details from the same guide: a canonical link that itself carries an hreflang attribute is ignored for canonicalization, and Google prefers URLs that are part of a reciprocal hreflang cluster when choosing canonicals. Google also notes that localized pages are only considered duplicates if the main content remains untranslated.

Most of these come straight from the common mistakes Google lists; the rest are what we check whenever we build or audit a bilingual site. Run the list before launch and after any change to routing, the CMS or the translation plugin.

Google recommends a single language for content and navigation on each page and warns against side-by-side translations. It also cautions that translating only the template, such as menus and footer, while the main content stays in one language creates a poor experience. Its spam policies list pages produced by scraping content and applying automated transformations such as translating as an example of scaled content abuse. Machine translation is a useful first draft; publishing it unreviewed across hundreds of pages is the risk.

The workflow we use for bilingual English–Japanese sites, including this one, looks like this:

Google does not use the HTML lang attribute, but people do. WCAG 2.2 success criterion 3.1.1, Language of Page, is Level A: the default language of each page must be programmatically determinable so that screen readers load the right pronunciation rules. Criterion 3.1.2, Language of Parts, is Level AA and covers passages in another language, such as a Japanese company name inside an English page. Set lang="ja" on Japanese pages and lang="fr-CA" on Canadian French pages even though it does nothing for ranking.

After launch, check the rendered HTML of a sample of pages in each language with the URL Inspection tool in Search Console, crawl the site with an hreflang-aware crawler to catch missing return links, and compare impressions by country and language in the performance report. Problems usually show up as the wrong language version ranking in a market, which is easier to fix in week one than after a year of mixed signals.