Technical SEOFor teams planning sites, compare international SEO subfolders and subdomains by hosting, ownership, hreflang, migrations, and Search Console reporting.
11 min read
Choosing between subfolders and subdomains affects how your teams publish localized pages and maintain them after launch. Changing that choice later means changing URLs, links, and search signals. The international SEO subfolders versus subdomains decision therefore deserves an operational answer before development begins.
We recommend subfolders when shared publishing and maintenance suit your business. Subdomains make sense when regional operations need greater separation. Either choice needs distinct localized URLs, accurate page relationships, and a workable launch plan. Start by defining the audience each version will serve.
Article summary
Decide whether each version targets a language, a country, or both. That choice determines which pages you need before you decide where they belong.
Google Search Central describes multilingual websites as offering content in multiple languages. Multi-regional websites explicitly target people in different countries. Your website can do both, but those audiences need clear definitions.
Consider a French-language publication serving readers across several countries. Its broad French edition has a different purpose from a French edition written specifically for Canada. Giving both versions identical editorial briefs would leave their intended audiences unclear.
Define each edition through regional content planning before assigning URL labels. This gives editors a reason to create a separate page and someone responsible for maintaining it.
For each planned version, record these audience decisions:
Country targeting has consequences. Google says it can improve rankings in the intended country at the expense of results in other locales or languages. Choose that narrower audience deliberately when the page genuinely serves it.
A directory label such as /fr/ does not determine the page's language. Google identifies language through visible content. Keep the main text and navigation clearly in the intended language.
Google also considers country signals beyond your URL label. A country-code domain, such as Germany's country-specific domain, is a strong signal. Local addresses and phone numbers can help identify the audience, as can local currency and links from local websites.
Server location is another signal, although Google describes it as non-definitive. Avoid making hosting geography the sole reason for creating a country edition. The page should have a clear purpose for the people it targets.
Google Search Central says Google Search works with either structure and recommends choosing according to your long-term plans. We would make this decision around publishing, hosting, and ownership.
A subfolder places localized pages beneath the main hostname. A subdomain gives the localized version its own hostname beneath the root domain. That difference creates useful operational choices without establishing an automatic ranking winner.
Google's international website guidance describes these practical differences between the structures:
| Subfolders | Subdomains | |
|---|---|---|
| Example URL | example.com/fr/ | fr.example.com |
| Server locations | One shared location | Separate locations possible |
| Site separation | Harder to separate | Easier to separate |
Subfolders suit a business that wants localized pages maintained on the same host. Google describes this arrangement as low-maintenance. A shared publishing operation has less reason to create separate hostnames solely because it adds languages.
Subdomains become more attractive when a regional team needs a more separate site setup or a different server location. The operational separation should solve a specific problem. Ask the regional owner to describe that problem before approving the structure.
Use these conditions to make the international SEO subfolders versus subdomains choice:
URL labels still need a shared meaning. A label might describe a language or a country, and Google notes that either structure can be ambiguous. Document your convention so future teams apply it consistently.
Plan the relationship between equivalent pages alongside the architecture. A hreflang setup checklist helps turn those relationships into a repeatable publishing task.
Where regional pages share the same language and substantially duplicate each other, use a deliberate duplicate URL resolution process. Decide which page is preferred while preserving the intended regional relationships.
Give each localized version a distinct, crawlable URL, then connect equivalent pages accurately. These requirements apply whichever hostname structure you choose.
Google recommends separate URLs for language versions. Pages that change language only through cookies or browser settings can leave some variations undiscovered. A visitor should be able to open the intended version through its own address.
Locale-adaptive delivery changes what a page displays according to the visitor. Google warns that Googlebot may fail to discover every variation through this arrangement. Separate URLs give each version an address that can appear in navigation and search.
Google advises against automatically redirecting visitors between language versions. Offer visible links that let people choose another version. This also accommodates someone whose preferred reading language differs from the language suggested by their location.
For example, a reader opening a translated product guide should be able to choose the equivalent guide in another language. Sending that reader to a general homepage creates another search task. Map language links at page level wherever an equivalent version exists.
During review, open a localized page directly and follow its language links. Confirm that the visible text matches the intended audience and the destination matches the original page's purpose.
Hreflang connects a page with its language or regional alternatives. It acts like a cross-reference between editions. Your team still needs to produce and review the localized content.
Google supports HTML tags, HTTP headers, and XML sitemaps as equivalent implementation methods. Choose the method your publishing setup can maintain consistently. Google says implementing all three provides no Search benefit.
Build the alternate set in this order:
Google specifies an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region code. For example, en-GB identifies English for the United Kingdom.
Use x-default when a selector or fallback page should serve unmatched language settings. This optional fallback belongs where your visitor journey needs it.
Every alternate set should describe the same group of equivalent pages. Reciprocal references let each version point back to the others. Google allows alternate URLs on different domains, so either architecture can support these relationships.
Treat canonical selection as a separate decision about duplicate content. A canonical identifies the preferred URL among duplicates. Google does not treat translated main content as duplicate content merely because it is localized.
Same-language regional duplicates need more care. Google's guidance recommends choosing a preferred version and using canonical signals alongside hreflang. Decide which URL is preferred, then keep the regional alternate relationships accurate.
Review these relationships whenever an editor adds or removes an edition. A newly published alternative needs references from the existing versions. A removed page also needs its outdated references addressed across the remaining set.
Keep visitor navigation aligned with those decisions. A language selector should describe the destination clearly, while its link should reach the corresponding localized content. Assign this review to the person approving the page for publication.
For a new launch, prepare the localized URLs and reporting before publication. For an existing site, add a page-by-page migration plan before changing its structure.
Google's site-move guidance starts with an old-to-new URL map. Each old page needs an intended destination. Preserve that mapping as a working document shared by the people responsible for content and implementation.
Keep the destination specific. If a localized article moves to another hostname, its redirect should lead directly to the corresponding article. Review the mapping before anyone activates redirects, because this is where content owners can catch wrong destinations.
Use this sequence to organize the move:
301 or 308 redirects where technically possible, with each old URL pointing directly to its final destination.A path-only move within the same domain falls outside the Change of Address process. Use the URL mapping and redirects to handle that change. Avoid redirect chains, which send visitors through intermediate destinations.
Google recommends retaining redirects for as long as possible, generally at least one year. Include that retention period in the implementation brief so later maintenance preserves the move.
A Search Console Domain property covers the domain's subdomains and protocols. It uses DNS verification. This gives you an aggregate view when your international setup spans several hostnames.
A URL-prefix property covers the specified prefix, including its protocol. Separate URL-prefix properties can provide narrower views of individual paths or hostnames. Choose the scope according to the part of the site you need to assess.
For a migration, monitor both old and new URLs. Review indexing and search queries, and investigate crawl errors. Assign someone to follow these reports after launch so the migration remains an active responsibility.
Google expects possible temporary ranking fluctuations while it recrawls and reindexes moved pages. Its guidance says most URLs on a medium-sized site may take a few weeks or more to move.
Larger sites can take longer, depending on URL volume and server speed. Schedule post-launch monitoring accordingly. Keep the URL map available so anyone investigating an old address can find its intended replacement.
For a fresh international launch, use the same reporting logic without an old-URL migration. Make the locale owner responsible for reviewing the intended portion of the site. Aggregate reporting and locale-specific reporting answer different operational questions.
Select publishing tools after you have agreed on the URL structure and page ownership. Separate content production from localization review and technical configuration when assessing what you need.
Aranx, WPML, and TranslatePress are named options to evaluate against your publishing requirements. Begin with the task you need completed. A product shortlist becomes useful when each option faces the same concrete brief.
Aranx researches website and competitor context, supports keyword research and content scheduling, and generates AI articles with custom images. It publishes to WordPress, Shopify, and custom CMS connections. It also supports multiple website management.
Those capabilities address content planning and publishing work. Assign localization review and technical URL configuration explicitly within your operation. Your implementation plan needs a named owner for hreflang and redirects regardless of the content-production workflow.
Apply these criteria when evaluating Aranx alongside WPML and TranslatePress:
Use a representative publishing task to make the evaluation concrete. Ask how your team would plan a localized article and send it for market review. Then trace who publishes the approved version and maintains its relationship with other editions.
Record the handoffs as well as the writing work. If one team approves content while another controls URLs, both need a shared publication record. Include the destination and responsible owner so an approved article reaches its intended edition.
For the international SEO subfolders versus subdomains decision, the useful workflow is one your team can sustain across editions. Judge tool fit against those responsibilities and your CMS. Keep the architecture decision grounded in the hosting and organizational needs already established.
Approve a market-to-URL map before developers build routes or editors begin producing localized pages. Assign one owner who can resolve disagreements about audiences and destinations.
Use one entry per planned language or country version. A spreadsheet is sufficient if the people approving the launch can read and maintain it. Include these fields:
For an illustrative approval entry, consider a Spanish-language help article intended for readers in Spain. Its owner should name the proposed address and corresponding article in the existing edition. That entry gives development a destination and editorial a defined assignment.
Ask the publishing owner and technical owner to approve the same map. Resolve any edition that lacks a clear audience or a responsible team before implementation. Development can then proceed against an agreed route pattern, with page relationships already assigned.
No. Google Search Central says Google Search is fine with either subfolders or subdomains and recommends choosing the setup that fits the site’s long-term plans. Operationally, subfolders are low-maintenance on the same host, while subdomains allow different server locations and easier site separation.
Hreflang should use an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region code, such as en-GB. The x-default value is a fallback for a selector or page serving unmatched language settings, not a universal requirement.
No, a URL such as /fr/ does not tell Google the page language. Google determines language from visible content, not the URL or lang attribute, so the main content and navigation should be clearly in the intended language.
No, an international website should not automatically redirect visitors between language versions. Google advises using distinct language URLs with links that let visitors choose another version; it also recommends separate URLs rather than changing language only through cookies or browser settings.