Does Google really require a separate URL for each language, or can parameters suffice?

Why does Google emphasize distinct URLs for each language?

The main reason relates to indexing and geographic targeting. Google needs to accurately identify which language version to serve to which user, in which country. A single URL with server-side language detection or via JavaScript does not allow Google to correctly index each variant.

Each language version must be crawled, indexed, and ranked independently. Ranking signals (backlinks, engagement, authority) build up per URL. If all multilingual content shares the same address, Google cannot differentiate performance by language or apply the correct local relevance criteria.

Are URL parameters really advisable?

Mueller states that it is technically acceptable, but he does not say it is optimal. Parameters like ?lang=fr or ?hl=es work for crawling, but they present practical issues that Google does not mention here.

First, the management of hreflang becomes more complex and prone to declaration errors. Next, analytics platforms and certain SEO tools struggle with parameters, creating duplicate reporting. Finally, the user experience is less clear — a subdirectory /fr/ is immediately recognizable, while a parameter is not.

What’s the difference between subdomains and subdirectories?

Google theoretically treats both equivalently, but the transfer of authority differs in practice. A subdomain like fr.example.com is seen as a semi-distinct entity: backlinks to the main domain do not directly benefit subdomains.

In contrast, a subdirectory example.com/fr/ directly inherits the authority of the root domain. For a new language market without a dedicated link-building budget, this difference can delay positioning by several months. Subdomains are especially suitable when each language has its own team and independent SEO strategy.

• Distinct URLs required: a unique address for each language version, without exception
• Subdirectories preferred: better authority consolidation, simplified management
• Parameters accepted: technically valid but complex in maintenance and analytics
• Hreflang essential: regardless of the structure, hreflang tags are mandatory to avoid cannibalization
• Consistency across the site: do not mix subdomains and subdirectories by language

Is this statement consistent with field observations?

Yes, but it overly simplifies a more nuanced reality. In principle, Google does index all three structures. However, measured results in crawl budget, indexing speed, and authority transfer show significant differences between subdirectories and subdomains.

I have observed in multilingual migrations that subdomains require 3 to 6 more months to achieve the same positions as subdirectories with an equivalent strategy. Google never mentions this time aspect, which heavily weighs on business decisions. [To verify]: large-scale comparative tests on this point remain rare and Google declines to quantify the impact.

Why doesn’t Mueller explicitly discourage parameters?

Probably because some web giants (particularly in legacy e-commerce) still massively use parameters, and Google does not want to invalidate their historical implementations. But let’s be honest: no new multilingual architecture in 2023-2025 should start with parameters.

Concrete problems accumulate: difficulty in properly setting up Google Search Console by language, risk of duplicating URLs in sitemaps, confusion with analytics tracking parameters. And most critically: hreflang tags in HTTP headers become impossible to implement cleanly with parameters.

What nuances should be considered about ccTLDs?

Mueller does not mention geographic top-level domains (.fr, .de, .co.uk), which remain the most effective option for strong local targeting. A ccTLD sends the strongest geographic signal to Google, far beyond a simple subdirectory.

The trade-off? A ccTLD requires a dedicated SEO and technical budget per country: local hosting, multiple SSL certificates, distributed DNS management, domain-specific backlink strategy. This is an investment that only structures with true local ambition can justify. For others, subdirectories remain the best efficiency/complexity ratio.

What concrete steps should you take for a multilingual site?

First step: audit your current architecture. If you are already using parameters or language detection without distinct URLs, plan a migration to subdirectories. It’s a technical undertaking, but the return on investment is measurable within 6 months.

Second action: implement hreflang tags correctly. This is non-negotiable regardless of your URL structure. Each page must declare all of its language variants + the x-default version. Test with Search Console and tools such as Oncrawl or Screaming Frog to detect inconsistencies.

What mistakes should you absolutely avoid?

Never mix structures: French in subdirectory (/fr/), German in subdomain (de.example.com), English as a parameter (?lang=en). This inconsistency creates confusion for Google and dilutes targeting signals.

Another frequent pitfall: duplicating content without real adaptation. A word-for-word automatic translation with the same structure isn't enough. Google detects multilingual duplicate content and may deprioritize certain versions. Each language must have its own editorial strategy and local keywords.

How can you check if your implementation is compliant?

Use the Google Search Console segmented by property (one per language if subdomains, filters if subdirectories). Verify that each language version is indexed independently and that impressions/clicks are distributed according to the expected geographies.

Crawl your site with a tool configured to track hreflang. You should get zero incomplete hreflang chain errors, zero language conflicts, zero non-reciprocal returns. A single broken hreflang can demote an entire language section.

• Migrate to subdirectories if you are currently using parameters or server detection
• Implement hreflang tags on all pages, including paginations and filters
• Set up Google Search Console with a view by language (property or filter)
• Create an XML sitemap per language with full and absolute URLs
• Verify the consistency of inter-language canonical tags (no cross-canonical)
• Test user experience: the language selector must point to the correct URLs