SEO Best Practices for Multilingual Websites

This playbook covers the minimum foundation to pick a scalable structure, implement hreflang + canonicals safely, localize on-page signals beyond translation, and keep crawling/indexing/performance stable across locales.

Step 1 — Pick the right URL structure and language targeting model

Make the structure decision first. It drives templates, sitemaps, analytics, and how easy it is to scale.

Default recommendation: use subdirectories for most SMB to mid-market sites:

• https://example.com/en/
• https://example.com/es/

Subdirectories are usually simplest operationally: one domain, consolidated authority, one technical stack.

When other options make sense:

• ccTLDs (e.g., https://example.es/): strongest country association, but highest cost/ops (separate domains, authority split).
• Subdomains (e.g., https://es.example.com/): more separation than folders, but more deployment and measurement complexity.

Next, choose language-only (en, es) vs language-region (en-GB, pt-BR). Use the smallest set that reflects real differences in content, pricing, legal terms, or intent.

Rule to enforce sitewide: one language/region per URL. Don’t auto-swap language content on the same URL based on browser/IP. Google needs stable URLs to index.

Step 2 — Implement hreflang + canonicals correctly (the non-negotiables)

hreflang tells search engines which URL to show for a given language/region. It’s a selection signal, not a direct ranking boost.^[1] Each locale page still needs to be indexable and useful.

Pick one hreflang source of truth:

• HTML <head>, or
• XML sitemap

Don’t output both unless you can guarantee they’ll never drift.

Hreflang rules that prevent most errors:

• Bidirectional: if en points to es, es points back to en.
• Self-reference: each page lists itself.
• Correct ISO codes: language (en, es) and optionally region (en-GB).
• Add x-default when appropriate: a selector page or fallback.
• No equivalent page: omit that hreflang (don’t point everything to the homepage).

Minimal HTML head example (en, es, x-default):

<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/producto/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/language-selector/" />

Canonicals answer a different question: which URL is primary when content is duplicate or near-duplicate.

• For real multilingual pages, each language page should canonicalize to itself.
• Avoid canonicals that point all locales back to the source language; that often collapses indexing.
• Only canonical across languages if pages are truly duplicate (uncommon in localization).

Validation I do after shipping:

• Spot-check a sample cluster for reciprocity and self-references.
• Inspect rendered HTML (verify what’s actually served).
• Use Search Console URL Inspection to confirm selected canonical and indexability.^[2]

Step 3 — Localize on-page SEO (not just translate)

If you translate copy but keep English search phrasing, you’ll miss intent and lose CTR.

Minimum standard per locale:

• Write unique titles and H1s that match local keyword phrasing (not literal translations).
• Localize meta descriptions to local terminology, units, and norms.

Example pattern:

• EN title: “Project management software for agencies”
• ES title: “Software de gestión de proyectos para agencias” (or the market variant people actually search)

Decide a URL slug policy and stick to it:

• Translated slugs: /es/gestion-de-proyectos/
• Consistent slugs: /es/project-management/

Either can work. What fails is mixing languages inside one locale.

Internal linking should reinforce targeting:

• Keep nav/footers language-consistent (no English global nav on Spanish pages).
• Localize anchor text; don’t reuse English anchors sitewide.
• Use a language switcher that links to the equivalent page (not just homepages) so crawlers discover alternates.

Also check basics: localize meaningful alt text, keep structured data text in-page language, and set the HTML lang attribute (e.g., lang="es").

Step 4 — Control crawling, indexing, and performance across locales

Multilingual sites multiply risk. One bad rule can wipe out entire directories.

Indexation rules to lock down:

• Don’t put noindex on language alternates unless you truly don’t want them indexed.
• Confirm key templates return 200, aren’t blocked by robots, and aren’t canonicalized away.

Robots.txt and rendering: don’t block JS/CSS needed for rendering. When I run multilingual audits, broken rendering is a common reason language switchers and internal links disappear for Google.

Sitemaps:

• Submit language-specific sitemaps or a combined one.
• Include only canonical URLs.
• If you use sitemap-based hreflang, keep it there (don’t also emit HTML hreflang).

Duplicate management (multiplied by locale): keep parameter/faceted behavior consistent and don’t let auto-generated thin pages (search results, endless filter combos) become indexable by default.

Performance matters across regions. Core Web Vitals are evaluated per URL and can vary by geography due to latency and device mix.^[3] Use shared templates, compress images, and consider CDN/edge caching so distant users don’t get slow localized pages.

Conclusion

Multilingual SEO works when your signals stay consistent. Start with a scalable URL structure (subdirectories are the usual default), decide whether you’re targeting language-only or language+region, then implement hreflang with reciprocity plus self-referencing canonicals per locale.

After that, localize the on-page signals that drive relevance and clicks: titles, headings, slugs, and internal links. Keep indexation clean with renderable templates, canonical-only sitemaps, and deliberate duplicate controls. Finally, avoid two repeat offenders: forced geo/IP redirects and cross-language canonicals that collapse your alternates into a single indexed page.

Sources

1. Google Search Central: Localized versions of a page (hreflang)
2. Google Search Console Help: URL Inspection tool
3. Google Search Central: Understanding Core Web Vitals and Google search results