Currently Available: Need a skilled Software Developer for your next project?

SEO, GEO and AEO

International SEO for Multilingual Websites

November 11, 2026 by Vincent Schmalbach

Choose the languages and countries you can serve before selecting URL patterns or commissioning translations. A site is multilingual when it publishes content in more than one language and multi-regional when it targets users in different countries. One site can do both, as Google’s guidance on multilingual and multi-regional sites explains.

Plan language and country separately. Create pages only where search demand matches an offer you can deliver.

Separate language and country

Language shapes communication, while country defines the market you serve. Spanish pages for Spain and Mexico use the same language, but they may need different wording, prices, currencies, payment methods, delivery details, or service terms. English pages for the United States and United Kingdom raise similar issues.

A locale combines a language and region for planning. For example, fr-CA identifies French for Canada. It does not select a URL structure or prove that a business serves Canadian customers. Before creating a regional version, check local search terms, spelling, units, currency, payment options, delivery, and service coverage.

One language version can serve several countries when the content and offer meet each audience’s needs. Create separate regional pages when differences change what visitors can buy, access, or need to know. For the editorial planning decision, see Managing Multi-Country Content Versions for SEO.

A language's wide use alone does not justify another locale. Confirm demand through customer inquiries, support requests, and search queries. Then confirm that you can deliver, accept payment, meet legal requirements, and provide service in that market.

Research local search intent

Research the wording people use in each target language and country, then identify the task behind each query. A searcher may want to compare plans, confirm delivery, find a nearby provider, or understand a product requirement. Map each meaningful need to a page that answers it.

Do not translate English keywords word for word. The same translated phrase can signal a different need in another market, while the same need can use different local wording. Native-language keyword research reveals both the terms people use and the information they expect.

Review local search results to identify the page types that appear and the tasks they help visitors complete. Local results reveal audience expectations, but they do not prove that a competitor’s wording or page layout caused its ranking. Avoid creating a URL for every keyword variation or locale label.

Choose a URL structure

Give every language or regional version a distinct, stable URL. Google recommends separate URLs because pages that change language based on cookies, browser settings, or similar signals can prevent crawlers from finding every version. Choose a structure you can operate consistently instead of assuming one format suits every site.

Compare the main options

Structure	Example	Main trade-off
Country-code domain	`example.de`	Gives a clear country signal and separates the country site, but adds domain, infrastructure, and maintenance costs. Check availability and registration requirements.
Subdomain	`de.example.com`	Separates a site area and supports separate hosting or operations. A label such as `de` may mean German or Germany, so make the target audience clear elsewhere on the page.
Subdirectory	`example.com/de-de/`	Keeps locale versions under one domain, which simplifies central management. Moving one locale to a separate domain later requires more work.
URL parameter	`example.com/?locale=de`	Makes the locale less visible to users and harder to segment by URL. Avoid parameters as the primary locale structure.

The trade-offs reflect Google’s guidance on managing multi-regional and multilingual sites. Confirm how Google classifies a domain ending before relying on it as a country signal. Some endings that resemble country-code domains are treated as generic domains.

Server location does not replace explicit locale signals. Google does not treat hosting location as definitive because hosting providers and content delivery networks serve sites from many locations. Google supports localized URL words and internationalized domain names. Use UTF-8 and correctly escape non-ASCII characters in links.

Keep locale URLs stable

Use consistent path patterns and link internally to the intended locale URL. Show visitors a language or region selector that links to every available version.

Do not redirect visitors solely from their IP address or browser language. Googlebot generally crawls from the United States and does not send an Accept-Language header, so automatic language switching can leave localized versions undiscovered. Google recommends separate URLs and links between language versions.

For pages aimed at distinct audiences, use stable URLs such as example.com/es-mx/ for Spanish in Mexico and example.com/es-es/ for Spanish in Spain. A path such as /de/ does not tell users whether the page targets German speakers worldwide or visitors in Germany. Use a consistent language-region pattern when that distinction matters.

When visitors need to choose a version, direct them to a stable selection page instead of silently replacing the URL they requested.

Create useful local pages

A localized page should tell readers what they can buy or use in their market and how to proceed. Translation alone does not make prices, terms, availability, or support relevant locally.

Adapt the actual offer

Give each regional page accurate information about the offer. The core product explanation on a subscription page can stay the same across markets, while its plans, billing currency, taxes, payment methods, and eligibility must match what customers can purchase in each one. A service page should explain where the service is available, how local customers contact the provider, and any regional limits or terms.

Create separate regional pages when the offer or the information needed to choose changes by market. Keep one shared page when the service and decision-making details are genuinely the same. Pages that only swap a place name or currency do not give readers useful local information.

Keep shared product facts consistent across locales. Have a subject-matter or legal professional review claims about regulated services and taxes, consumer rights, and other jurisdiction-specific obligations.

Clear product facts also help search engines interpret an offer. Make those facts clear before adding more SEO copy.

Write for local readers

Keep the main content and navigation in the page’s intended language. Google determines page language from visible content rather than from the URL or a code-level language declaration. Its guidance for multilingual sites advises against placing complete translations side by side on one page. Translating menus and buttons while leaving the main content in another language confuses readers and makes language targeting unclear.

Adapt titles, headings, calls to action, dates, units, examples, and product terms when local use requires different wording or formats. A fluent reviewer who knows the target market can catch terminology, tone, and cultural references that are technically translated but unclear or misleading. Page titles, descriptions, headings, and internal-link labels should describe the localized page rather than repeat generic English metadata.

Translate changing or user-submitted content only when the translated material is complete enough to help readers. A localized interface around essential untranslated content leaves readers unsure what the page covers.

Check the complete page

Review each locale URL as a customer in that market. Check the title, description, main content, navigation, prices, availability, and calls to action. Follow key links and complete forms or checkout. Inspect rendered pages for untranslated template text or English fallback content, especially in dynamically loaded sections.

Compare results by locale URL so strong performance in one market does not hide a weak page elsewhere.

Connect versions with hreflang

Hreflang annotations identify the language or regional URLs for the same page, helping Google select a URL suited to a searcher’s language or location. They do not guarantee which URL appears in results. Google supports hreflang in HTML, HTTP headers, and XML sitemaps. Its localized versions documentation specifies the supported syntax and methods.

Map equivalent pages

Connect only URLs that serve the same content or user task in different locales. An English article and its French and Canadian French versions belong in one set. If no Canadian French version exists, leave that locale out. Do not point hreflang to an unrelated page.

Every page in the set should list all relevant versions, including itself. Use each version’s canonical URL, and confirm every destination is live, crawlable, and intended for indexing.

When an article is available in English, French, and Canadian French, all three pages should return the same annotations:

fr identifies French, while fr-CA identifies French for Canada. Use a valid language code with an optional region code. A country code alone, such as CA, is not valid.

Check return links

Add a return link from each listed alternate. If the English page names the French page, the French page must name the English page with the correct language value. Without return links, Google may not recognize the relationship between the pages.

After publishing, inspect the rendered HTML, HTTP headers, or sitemap output. Flag invalid codes, redirecting URLs, error pages, non-canonical destinations, and missing return links. CMS locale settings do not prove that the live annotations are correct.

Use x-default as a fallback

Use x-default for a fallback URL when no listed language or region matches the searcher. A language selector or broadly applicable page gives visitors a useful next step.

x-default does not replace explicit language-region annotations or make an English page the default for every audience. Check that the fallback URL loads and explains the available choices, and that it does not automatically redirect visitors away from the version they selected.

Choose one implementation method

Use HTML link elements for web pages, HTTP headers for non-HTML files such as PDFs, or an XML sitemap. Choose the method your publishing setup can generate and verify reliably.

Keep canonicals aligned

A canonical tag identifies the preferred URL for duplicate or substantially similar content. Hreflang identifies equivalent pages for different languages or regions. Use canonicals to consolidate duplicates and hreflang to connect localized alternatives.

Give each distinct translation its own canonical URL. Do not point every language version to English.

Choose the right canonical

Give each translated page a self-referencing canonical when it has distinct language content and should appear in search results. If both English and French pages should rank, the French page should canonicalize to its preferred French URL and link to the English equivalent with hreflang. Google recommends selecting a canonical URL in the same language where possible for multilingual and regional sites.

For same-language regional pages, base the decision on the content. Keep separate canonical URLs when pages contain essential local differences, such as prices, offers, legal terms, or inventory. Use hreflang to identify those regional alternatives.

When same-language regional pages are substantially the same, select one preferred URL and keep the canonical and hreflang annotations consistent with that decision. Google covers this case in its guidance for multi-regional sites.

When page content is unchanged, canonicalize tracking-parameter URLs and accidental URL variants to the clean URL. If a page has permanently moved and the old URL should no longer be available, use a redirect rather than a canonical tag.

Regional pages do not need separate canonicals solely because they target different countries. Separate canonicals suit pages with independent local value. Near-duplicate pages require a consolidation decision; hreflang does not resolve duplicate-content signals.

Check the signals together

Each hreflang destination should load successfully and be the canonical URL for that language or region. Fix hreflang entries that point to redirects, error pages, noindex pages, or pages canonicalized to another locale.

Review the rendered canonical tag, final response URL, internal links, sitemap entries, and hreflang destinations together. A French page that canonicalizes to English while its internal links and hreflang annotations point to French sends conflicting signals.

Use Search Console’s URL Inspection tool to compare the declared canonical with Google’s selected canonical for a specific URL. This comparison helps diagnose that URL; it does not confirm that every locale is configured correctly.

For a deeper diagnosis, see how incorrect canonical URLs hide the page you want search engines to use.

Make every locale reachable

Each locale URL should load directly, show the intended language and market information, and remain available to visitors and search crawlers. A published URL fails when it redirects the visitor elsewhere, displays an empty template, or presents an unavailable product or service as available.

Test each live URL

In a clean browser session, open representative homepage, category, product or service, and support URLs for every target locale. Do not log in or rely on saved preferences. Record the HTTP status code and response, the final URL after redirects, the visible language, and market details. Also record the canonical URL, robots directives, and hreflang annotations.

Confirm that each page renders its main localized content and a valid offer for the stated market. Check the price, currency, stock status, delivery area, service eligibility, and contact details. A product page with no stock or delivery option for that market should state that clearly rather than appear purchasable.

Request locale URLs directly, without cookies or a prior visit. The requested version should load without a silent redirect based on IP address or browser language.

Check links and crawl access

Make every locale reachable through ordinary links, including a language or region selector and relevant internal navigation. When an equivalent page exists in another locale, the selector should link to that matching page rather than send every selection to a locale homepage. A sitemap helps search engines find URLs, but it does not replace internal links. Google recommends crawlable links to important pages.

Check that published pages are not blocked by robots.txt or marked noindex in HTML or HTTP headers. Review the live site after launch because staging controls, CDN rules, firewalls, and regional access restrictions sometimes remain active. For CDN or firewall failures, see how to diagnose crawler blocking.

Watch for hidden variants

Keep the locale selector available after navigation. Confirm that switching versions does not create a redirect loop. Show the selected locale in the URL and page content so visitors can verify which market’s information they are reading.

Use location detection to suggest a market with a notice or selector instead of forcing a redirect. Forced redirects prevent visitors from viewing the URL they requested and can limit search-engine access to alternate versions. Google advises against automatic language redirects. It also states that server location is not a definitive targeting signal and that Google ignores locational meta tags.

After a release changes routing, templates, navigation, or regional availability, run the checks again.

Every intended locale needs a working, crawlable URL, accurate market information, and internal links that visitors and crawlers can follow.

FAQ: Is a sitemap enough to make locale pages discoverable?
No. Include locale URLs in the sitemap and link to important locale pages through navigation and relevant internal links.

Migrate locale URLs safely

During a URL migration, map each language and market page to its own destination. When domains, locale codes, or URL paths change, preserve the connection between each old page and the new page serving the same audience.

Redirects, canonical tags, internal links, hreflang annotations, and sitemap entries should all identify the same final locale URL.

Map old pages to new

Before launch, inventory every locale URL. Record its language, target market, purpose, canonical URL, hreflang alternatives, and indexability. Create a redirect map that pairs each old URL with the closest new equivalent in the same language and market.

For example, an old Canadian French service page should redirect to its new Canadian French equivalent, not to a French homepage or English page. Keep the redirect map after launch so you can trace unexpected crawl requests and traffic.

When a regional product or service has ended and has no relevant replacement, return an appropriate error response instead of sending visitors to an unrelated product or generic homepage. Google may treat an irrelevant redirect as a soft 404.

Update every reference

Send each old URL directly to its final destination. Update internal links, canonical tags, hreflang annotations, and XML sitemap entries to use that final URL. Redirects preserve access to old URLs; they should not repair stale references across the site.

Each locale page intended to appear in search results must remain indexable and use the intended canonical, which commonly references itself. Hreflang annotations must connect equivalent language or regional pages and include reciprocal references.

Test direct paths, including trailing-slash variations, along with query parameters and locale selectors. Preserve parameters when they change page content or carry required information. Remove redirect chains and loops before launch.

For a focused sitemap check, see how to audit Yoast SEO sitemap output.

Verify after launch

Check representative pages in every market, including whether old URLs return a permanent redirect to one final destination. For each new URL, verify that it shows the intended language and regional offer and remains indexable. Confirm that its canonical is intended and its hreflang annotations are reciprocal.

Look for familiar failures: every locale redirects to one version, canonicals still use the old host, sitemaps list old URLs, return links are missing, or locale pages carry an accidental noindex directive.

Monitor crawl activity, indexing, Google-selected canonicals, traffic, and conversions by locale and page type. Investigate unexpected drops alongside demand, seasonality, and changes to the offer.

Compare performance by locale

Compare equivalent pages within each market before comparing markets with one another. The Search Console Performance report shows clicks, impressions, click-through rate, and average position by dimensions including query, page, and country.

Build a comparable view

Group landing-page URLs by intended locale, page type, and topic. Compare Mexico’s Spanish product page with Spain’s equivalent product page, rather than with either market’s homepage. Filter by country, then inspect the queries and landing pages behind the totals.

Treat language and country as separate dimensions. A country filter identifies where the search occurred; it does not identify the search language. Use query wording and each URL’s intended locale alongside country data. Markets that share a language still differ in demand, competitors, pricing, and product availability.

Average position is an aggregate across queries, not a fixed rank. A changing query mix shifts the average even when rankings for individual queries stay the same. Review position alongside impressions, clicks, and click-through rate. Raw clicks and average positions do not provide a fair comparison when search demand and result pages differ between markets.

Pair search visibility with leads that meet your sales criteria or completed purchases. Confirm that the destination serves the market before interpreting traffic or conversion trends. Search Console measures Google Search visibility and visits, while analytics records on-site activity through configured events and the site’s tracking and consent settings. The figures may differ. Google Analytics events record specific user interactions.

Record locale launches, translation edits, URL changes, pricing updates, and availability changes. These notes help distinguish business changes from technical issues, though timing alone does not prove cause.

Diagnose the wrong page

When Google shows an unexpected locale, note the query and country alongside the result URL and date. Check the page’s visible language, canonical URL, hreflang annotations, and reciprocal links. Also check redirects and internal links. Confirm that the intended page is live, indexable, and linked from the site. Google cannot select a version it cannot access or discover.

In URL Inspection, compare the declared canonical with Google’s selected canonical. Then check whether same-language regional pages contain market-specific terms, products, prices, or service details. Google’s localized-version guidance requires hreflang annotations to link relevant alternate versions back to one another.

One unexpected result does not establish a site-wide pattern. Look for repeated mismatches across queries and dates.

Keep comparisons consistent

Use stable locale, page-type, and topic groups in recurring reports. Review search measures alongside availability and local business outcomes. Record changes to URLs, content, tracking, pricing, and market coverage.

A rise after adding hreflang or updating a translation does not prove that change caused the result. Attribute the rise to the change only when a suitable comparison and supporting evidence support that conclusion. Search Console and analytics measure different activity, and neither shows whether an AI assistant gave an appropriate local answer.

Compare equivalent pages and search needs, then judge performance against the local offer and business outcome.

Does a country filter show search language? No. Use the page’s intended locale and query wording alongside country data; a country filter alone does not show search language.

Observe AI answers by locale

An indexed French page does not guarantee a link in a French-language AI answer, a recommendation, or a sale. For Google Search AI features, Google says a page must be indexed and eligible to appear with a search snippet before it is eligible as a supporting link. Those requirements establish eligibility, but a specific answer may still omit the page. See Google’s AI-features documentation.

Treat each answer as one observation for a specific language, market, search product, and date. The same underlying question asked in Canadian French and French for France may produce different answers because the wording, available sources, product availability, and user context differ. How AI search finds and selects website sources covers the broader source-selection process.

Record each observation

Compare questions with the same intent using natural wording in each language. Record the exact prompt, intended country or location, search or AI product, and date. Save the full answer and its linked sources. Note whether a link leads to the intended local URL or to a page for another language or market.

Check whether each linked page accurately states local prices, availability, and service coverage. An answer that names a brand but sends local customers to an unavailable offer has limited business value.

Keep a stable, comparable prompt set, and show the sample size and method beside each conclusion. Track brand mentions, source links, recommendations, site visits, and sales as separate outcomes. A mention does not establish a click, and a click does not establish a sale. Changing the questions between measurements can create a false appearance of improved visibility, as changing the prompt set affects visibility comparisons.

A shared source may serve several locales

One page may appear in answers for several locales when it genuinely serves those audiences. Compare the linked URLs and confirm that the page fits each market. A changed answer alone does not prove a ranking change or identify its cause.

When one locale is enough

For a website serving customers in more than one country, a locale is a language or regional version of a page. Adding one creates continuing work: local keyword research, translation review, content updates, technical checks, customer support, and accurate product or service details. Country-code domains also add infrastructure and maintenance needs. Google advises using an international URL structure that the business can manage consistently in its guidance on multilingual and multi-regional sites. Each localized page needs an owner who keeps its offer, terms, and availability current.

The case for staying focused

A separate locale is worthwhile only when it gives customers useful local value. If people in two countries use the same language, receive the same offer, and need the same information, one well-maintained page is more accurate than several near-identical regional pages.

Create a regional page when customers need different prices, terms, availability, service coverage, legal information, or support details. Changing the place name without changing the offer gives visitors little value and creates another page that can become inaccurate.

When demand is unproven or the business cannot serve a market, keep the site focused. Check local search queries and customer inquiries, then confirm that the business can fulfill orders, provide support, and honor every statement on the page before publishing an indexable regional version.

Counterargument: broader language coverage can reveal demand

A localized page may help a business test interest in a new market, especially when prospects already ask for local pricing or support. That test still requires a truthful offer. A page that implies local service, shipping, or legal availability that the business does not provide creates a poor customer experience and weakens trust. Gather demand through inquiries, paid campaigns, or sales data before building a permanent indexable locale.

Key Takeaways

Choose markets from real demand and service capacity. Plan language and country separately, then research local queries and create regional pages only when audiences need different content or offers.
Give each locale a stable, crawlable URL. Choose a domain structure you can maintain, link versions internally, and let visitors select their language or region without forced redirects.
Make every localized page accurate and useful. Match its language, prices, availability, terms, and support details to what customers in that market can access.
Connect true equivalents with reciprocal hreflang and aligned canonicals. Give distinct translations their own canonical URLs; use x-default only for a genuine fallback.
Test and measure by locale. Check access, redirects, indexability, canonicals, and alternate links before and after migrations. Compare relevant search and business outcomes within markets, and treat AI answers in each language and region as separate, dated observations.

FAQ

Do I need a separate domain for every country?

No. Country-code domains, subdomains, and subdirectories are all options. Choose the structure you can maintain consistently. Check whether the domain is available and what registration requires, and confirm that Google treats the domain ending as the country signal you expect.

How do I decide whether to create separate pages for two countries that share a language?

Compare local search wording, customer needs, and what you can provide in each market. Separate pages make sense when important details such as prices, products, delivery, service coverage, or support differ. If the content and offer are genuinely the same, one well-maintained page may be enough.

Should I translate keywords literally?

No. Research how people in the target language and market describe the need, then match each page to the task and result they expect. A translated phrase can have different meanings or search intent in another region.

Should every page use hreflang?

Use hreflang for pages that are genuine alternatives, such as versions of the same product page for different languages or markets. Each page in the set should list the relevant alternatives, including itself, and every other listed page should link back to that same list.

Should translated pages canonicalize to English?

No. Give each distinct translated page its own canonical URL when you want it eligible to appear in its language, and use hreflang to connect the alternatives. A canonical pointing every translation to English signals that English is the preferred version.

Does x-default replace hreflang?

No. The x-default label identifies a fallback for users who do not match a listed language or region. Keep explicit hreflang annotations for known versions, and point x-default to a useful destination such as a language selector.

How do I check that a locale page is reachable?

Open the URL in a clean browser session and confirm that it loads the intended language and market without relying on a previous cookie or login. Check the final URL after redirects, page content, canonical, indexing directives, and hreflang links. Also confirm that users can reach the page through site navigation.

What if a page has no equivalent in another language?

Do not invent an alternate or point hreflang to an unrelated page or locale homepage. Until a genuine equivalent exists, omit the page from the alternate set and state which versions the site offers.

How do I check a multilingual site migration?

Map each old URL to its closest new page for the same language and market. Then verify that redirects and canonicals point to the final destination. Check hreflang links, internal links, and sitemap URLs against that destination too. After launch, test representative pages in every locale for errors, redirect loops, accidental noindex settings, stale URLs, and missing return links.

Should I compare AI search answers across languages?

Yes. Treat each language and market as a separate observation. Record the exact question wording, location, search product, date, answer, and cited page. One answer in one locale does not establish visibility in another.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com