Key takeaways
- One URL per language, linked with reciprocal hreflang tags.
- Localise titles, descriptions and visible content. Translated slugs are optional, and published URLs should stay stable.
- Use structured data that matches the page’s visible content and purpose.
- Answer the main question early and test Core Web Vitals for each language. Neither guarantees rankings or AI citations.
Choose the URL structure
Give every language version a stable URL that search engines can crawl. Subdirectories such as /es/ are a practical default for one business website. Connect equivalent pages with reciprocal hreflang, check canonicals and localise titles and descriptions. Use the launch checklist below to test each language.
| Structure | Example | Good | Trade-off |
|---|---|---|---|
| Subdirectories | example.com/es/ | Easy to set up, one host, low maintenance | Geotargeting is less obvious, one server location |
| Subdomains | es.example.com | Easy to set up, can use different servers | Users cannot always tell a language from a country |
| Country domains | example.es | Clear geotargeting, easy to separate | Expensive, availability varies, targets one country |
| URL parameters | example.com?lang=es | Not recommended | Hard to segment and not obvious from the URL |
URL and hreflang structure
Give every language its own crawlable URL (for example /es/ and /uk/), link each version to all the others with hreflang, and add an x-default.
- Every version lists itself and all the others, and the pages point back at each other. Otherwise Google ignores the tags.
- Alternate URLs are fully qualified, with https.
- Language codes follow ISO 639-1 and region codes ISO 3166-1 alpha-2.
- Each language version has a canonical URL that points to itself.
- The same set of alternates appears on every version, whether you use HTML tags, headers or the sitemap, and one method is enough.
Do not redirect people by browser language
Google advises against automatically sending visitors to a language version based on a guess about their language. It can stop both people and search engines from reaching every version, and Googlebot usually crawls without an Accept-Language header. Offer a visible language switcher made of ordinary links instead.
Metadata and structured data
- Unique title and meta description per page and language, written for the local search and not translated word for word
- Translated Open Graph and social tags
- Organization schema with address, VAT and contact
- Service, FAQPage, Article and BreadcrumbList where relevant
- The inLanguage property on articles, and the real publication and update dates
Keep FAQ structured data consistent with visible questions and answers. Structured data describes your page. It does not guarantee a rich result or an AI citation.
Core Web Vitals on a multilingual site
Google's thresholds for a good experience, measured at the 75th percentile of visits and separately for mobile and desktop, are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less.
- Load only the fonts and character sets each language needs, because Cyrillic and Latin Extended add weight.
- Prerender or server-render the pages so that content is in the first response.
- Reserve space for text that grows when translated, so that buttons and cards do not shift.
- Keep images sized and compressed, and avoid loading translation scripts in the critical path.
Writing for AI answers
Start each page with its main answer, then support it with useful detail. Keep the subject and important terms consistent across the title, description, headings and body. Clear summaries help readers assess relevance, but no writing formula guarantees inclusion in AI answers.
- Put the answer first, then the reasoning.
- Use comparison tables and numbered steps, which are easy to quote.
- Cite primary sources for any claim about law or numbers.
- Let search and AI crawlers fetch your pages in robots.txt unless you have a reason not to.
Launch QA checklist
- Crawl the site and confirm every language page returns a 200 with no redirect chain.
- Check that each page's canonical points to its own URL.
- Validate hreflang reciprocity across all versions and the x-default.
- Confirm titles, descriptions and Open Graph tags are translated and unique.
- Check the sitemap lists every language version and nothing that redirects or is noindexed.
- Test the language switcher with JavaScript off.
- Validate structured data on a sample from each template.
- Run a Core Web Vitals test on a mobile connection for each language.
- Read a page in each language end to end for untranslated fragments.
- Submit the sitemap in Search Console and watch the page indexing report in the first weeks.
Send us your languages, key pages and current platform. We can review your multilingual site or scope a build with crawlable pages and localised metadata.
Discuss multilingual SEOFAQ
Do I need a separate domain per country?
No. Subfolders on a single domain are usually simpler and keep authority in one place.
Should translated pages have translated URL slugs?
It helps readers, but it is optional. If you translate slugs, keep them stable after publishing and make sure hreflang and canonicals use the final URLs.
Do I need an x-default?
It is recommended when you have several languages. It names the fallback page, often the English page or a language selector, for users whose language is not listed.
Sources
- Google Search Central: managing multi-regional and multilingual sites
- Google Search Central, Tell Google about localized versions of your page
- web.dev, Web Vitals
- Schema.org vocabulary
About the author
Erik Salo Akimov · Co-founder · Engineering
Erik runs engineering at ESADEX. He designs the platforms, infrastructure and security controls that sit behind client systems.
