Multilingual SEO: URL structure, hreflang without errors, and when a language isn't worth publishing

The short answer

Multilingual SEO comes down to four things. Give every language its own URL, usually a subdirectory such as /es/. Connect each page's language versions with reciprocal hreflang annotations that include the page itself and an x-default. Keep every language URL crawlable, with no automatic redirects between them. And publish only the languages you can write and keep up well.

Google recommends separate URLs per language, detects a page's language from its visible text rather than its lang attribute, and may ignore hreflang annotations that lack return links. The bigger risk is quality: machine translation published at scale without review. On 14 October 2026 we retired 15 machine-translated languages from dardo.studio, 795 of its 954 URLs, which brought about four search clicks a week.

Multilingual or multi-regional?

Google's guide to managing multi-regional and multilingual sites separates the two:

• A multilingual site offers content in more than one language, such as a Canadian business with English and French versions. Google tries to match the searcher's language.
• A multi-regional site targets users in different countries, such as a manufacturer shipping to Canada and the United States. Google tries to match the searcher's locale.

Many sites are both. The difference decides your hreflang codes: language only (es) when one Spanish version serves everyone, language plus region (es-MX, es-CO) only when the pages really differ by country, in prices, shipping, legal text or offer.

URL structure: the four options

Google lists four ways to build locale-specific URLs and recommends against one:

For most businesses, subdirectories are right: one domain, one analytics setup, one place to build authority. dardo.studio uses /en/, /es/ and /pt/.

Three details from the same guide:

• Some country domains count as generic. Google treats .co, .io, .ai, .me and .tv, among others, as generic top-level domains, so a .co domain doesn't signal Colombia.
• Translated slugs are fine. Localized words in URLs are allowed; use UTF-8 and escape the URLs properly in links.
• Don't switch language on one URL. Google recommends separate URLs rather than cookies or browser settings that change the language of the same address.

hreflang: syntax and rules

hreflang tells Google that a set of pages are language or regional versions of each other, so it can show the right one. Google's localized versions documentation, last updated 21 September 2026, accepts three equivalent methods: <link> elements in the HTML head, an HTTP Link header (useful for PDFs) and an XML sitemap. Using more than one brings no benefit in Search and is harder to keep consistent.

This is the set on our Spanish contact page, copied from the live HTML. The English and Portuguese versions carry the same four lines:

<link rel="alternate" hreflang="en" href="https://dardo.studio/en/contact/">
<link rel="alternate" hreflang="es" href="https://dardo.studio/es/contacto/">
<link rel="alternate" hreflang="pt" href="https://dardo.studio/pt/contato/">
<link rel="alternate" hreflang="x-default" href="https://dardo.studio/en/contact/">

The rules Google sets for every method:

• Each version lists itself and all the others, so the set is identical on every page in it.
• URLs are fully qualified, with https://. Relative paths don't count.
• Return links are required. If two pages don't both point to each other, Google ignores the tags.
• x-default names the fallback for searchers whose language matches none of your versions. Google designed it for language selector pages, but it works on any page; ours points to the English version.
• Codes are ISO 639-1 for the language, optionally followed by ISO 3166-1 alpha-2 for the region. Scripts can use ISO 15924 (zh-Hant).

We publish hreflang both in the HTML and in our sitemap. That only stays safe because both are generated from the same CMS data; with hand-maintained tags, pick one method.

hreflang codes that fail

es-419 deserves the warning: many sites use it to mean "Latin American Spanish", and Google's documentation says it isn't supported. Use es for one Spanish version, or country codes if you really have country versions.

The common hreflang errors

• Missing return links. Page A lists B, but B doesn't list A, so both annotations may be ignored. It usually happens when one language has a page the other lacks, or when slugs change in one language only.
• A canonical pointing to another language. Google's canonicalization guide says that with hreflang, each page's canonical should be in the same language. A Spanish page canonicalized to its English version tells Google the Spanish page is a duplicate. Give every language version a self-referencing canonical.
• hreflang pointing at redirects, 404s or noindexed pages. Point every annotation at the final URL that answers 200, is indexable and is its own canonical. A crawler gets nothing useful from an alternate that redirects elsewhere.
• Template-only translation. Google treats localized pages as duplicates only when the main content stays untranslated. A page with a Spanish menu and an English body isn't a Spanish page.
• A lang attribute that contradicts the text. Google ignores lang when it detects language, but screen readers rely on it: WCAG 2.2 success criterion 3.1.1 (Level A) requires each page's language to be programmatically determinable. Set it correctly anyway.

A quick hreflang checker

Search Console's International Targeting report is deprecated, although Google says it still uses hreflang. Google's documentation points to third-party tools such as Merkle's hreflang tag tester, which checks one live page. For a quick check of your own, this script fetches a page, then fetches each alternate and confirms it answers 200 and links back:

page="https://dardo.studio/es/contacto/"
for alt in $(curl -s "$page" | grep -o '<link rel="alternate" hreflang="[^"]*" href="[^"]*"' \
             | sed 's/.*href="//; s/"$//' | sort -u); do
  code=$(curl -s -o /dev/null -w '%{http_code}' "$alt")
  back=$(curl -s "$alt" | grep -c "hreflang=\"[^\"]*\" href=\"$page\"")
  echo "$alt  status=$code  links_back=$back"
done

Run on 17 October 2026, it printed status=200 links_back=1 for all three versions. It assumes the attribute order shown above; adjust the pattern to match your HTML.

Redirects by language: what Google warns against, and a safe pattern

Google's guidance is direct: avoid automatically redirecting users from one language version to another based on what you think their language is, because it can stop users and search engines from seeing every version. Its page on locale-adaptive pages explains why: Googlebot's default IP addresses appear to be in the US, and it sends requests without an Accept-Language header. A site that picks content by IP or browser language may show Google only one version. Google also calls IP location analysis generally unreliable.

Redirecting by language is still useful at addresses that don't belong to one language. This is how dardo.studio does it:

• Language URLs never redirect. /en/contact/, /es/contacto/ and /pt/contato/ always answer 200, sit in the sitemap and carry the hreflang set.
• Language-neutral addresses pick a version. /contact/ or /contacto/, the forms we use in shared links, answer with a temporary redirect chosen from the visitor's Accept-Language, marked Vary: Accept-Language and never cached.
• A client with no language preference gets the address's own language. Googlebot sends none, so /contacto/ takes it to the Spanish page, not the English one.

$ curl -sI https://dardo.studio/contact/ -H "Accept-Language: pt-BR"
HTTP/2 302
location: https://dardo.studio/pt/contato/

$ curl -sI https://dardo.studio/contacto/
HTTP/2 302
location: https://dardo.studio/es/contacto/
vary: Accept-Language, Cookie

The neutral addresses stay out of the sitemap and hreflang. Google's redirect documentation says a temporary redirect isn't a signal that its target should be canonical, so the language URLs carry that weight themselves, through self-referencing canonicals, sitemap entries and internal links. A banner offering another language is gentler than any redirect when a visitor lands on the "wrong" version.

Translation quality: when machine translation becomes a risk

Google's spam policies, last updated 28 August 2026, define scaled content abuse as many pages generated mainly to manipulate rankings rather than help users, however they're made. Their examples include scraped content run through automated transformations such as translating. Translating your own pages isn't named, but the test is the same: does each page add value for its readers?

Google's staff have answered the question directly. In the June 2024 SEO office hours, Gary Illyes said a low-quality automatic translation may hurt rankings, and recommended that a native speaker review and fix it. John Mueller said there is no markup to label automatic translations: if you're happy with the pages, index them; if not, add noindex. Bing's Webmaster Guidelines say large-scale generated content without oversight or editorial review may be excluded from indexing.

There's also a fallback you don't have to build. Google may translate search results itself, showing a translated title and snippet, for searches in 21 languages including Arabic, French, German, Hindi, Korean, Portuguese, Spanish and Thai. For a language you can't do well, a good page in your main language may reach those searchers through that feature. That's our reading of the feature, not a promise Google makes.

Our decision: retiring 15 machine-translated languages

On 14 October 2026, dardo.studio stopped publishing 15 machine-translated languages: French, German, Italian, Dutch, Swedish, Polish, Ukrainian, Russian, Arabic, Hindi, Thai, Japanese, Korean and Simplified and Traditional Chinese. They made up 795 of the site's 954 URLs and brought about four search clicks a week. Every one of those pages now answers with a single 301 to its English version, and anything else under a retired language goes to the English home:

$ curl -sI https://dardo.studio/fr/blog/apparaitre-reponses-ia/
HTTP/2 301
location: https://dardo.studio/en/blog/appear-in-ai-answers/

Our reasons:

1. We couldn't stand behind them. We work in English and Spanish, so we couldn't review the other 15, and Google's own staff say low-quality automatic translations can hurt.
2. Most of the site, almost none of the value. Five in six of our URLs brought about four clicks a week between them.
3. A 301 rather than a 404 or 410. Google says to use a permanent redirect when you're sure it won't be reverted. A visitor following an old French link lands on the same content in a language we write, instead of an error.
4. Fewer languages, written properly. We kept English and Spanish, the languages we work in, plus Portuguese for Brazil.

It's a decision, not a result: three days in, there is no outcome data. What to watch: whether the retired URLs leave Google's index, and whether the English pages gain impressions from those countries. The redirects follow a per-page map, the same approach as a site migration; our redirect map generator builds one from two sitemaps, and the website migration SEO checklist covers the rest of a URL change.

Checklist: launching a new language

For a two-language site between English and Spanish, our guide to a bilingual English–Spanish website covers costs, translation rates and ranking in Spanish in the US.

What to do next

Run the hreflang check above on your three most important pages, then go through the checklist for each language you publish. If you'd like Dardo to plan or rebuild a multilingual site, with copy written for each market and hreflang generated from one source, see multilingual websites.