SEO for International Websites: Choose Between Hreflang, Folders, and Country Domains
Expanding into new markets can create duplicate pages, confusing signals, and missed local search demand. Learn how to choose an international URL structure and implement hreflang so search engines can serve the right version to the right audience.
Choose your international URL structure first, then use hreflang to connect equivalent language or regional pages. These are not competing options: subfolders, subdomains, and country-code domains determine where pages live; hreflang helps search engines understand which version is intended for which audience. For a centrally managed business expanding into several markets, subfolders on a generic domain are often the simplest starting point. Country domains become more compelling when markets operate independently and local identity matters enough to justify the extra work.
The right decision depends less on the number of countries on your roadmap than on what changes between them. Before choosing URLs, identify differences in language, products, pricing, shipping, support, and publishing responsibility. That inventory tells you whether you need translated pages, regional versions, or genuinely separate websites.
Separate Language Targeting from Country Targeting
Language targeting answers which language a visitor reads. Country targeting answers which market a page serves. A Spanish-language article may help readers across many countries without needing a separate version for each one. A product page, however, may need distinct Spanish versions for Spain and Mexico if availability, currency, delivery terms, or product specifications differ.
Use language-only versions when the same content and service genuinely work across markets. Add regional versions when a visitor's country changes the usefulness or accuracy of the page. Do not create dozens of nearly identical country pages simply because your analytics report visitors from those countries. Every additional version creates publishing, quality assurance, and maintenance obligations.
Language-only targeting: /es/ can serve a broadly applicable Spanish resource library.
Language-and-country targeting: /es-mx/ can serve Spanish-language pages with Mexican pricing and delivery information.
Multiple languages within one country: a Canadian operation might need both /en-ca/ and /fr-ca/.
One language across several countries: English pages for the United States and United Kingdom may need separate versions when products, terminology, or commercial terms differ.
Folder names do not establish targeting by themselves. A path called /fr/ does not make English content French. Search engines assess page content and other signals; hreflang labels should accurately describe the audience that the page actually serves.
Compare Subfolders, Subdomains, and Country-Code Domains
Subfolders: a practical default for centralized teams
Subfolders place international content within one domain, such as example.com/de/ or example.com/de-at/. They usually suit teams sharing a CMS, design system, analytics setup, and technical release process. Keeping content within one site can simplify internal linking, technical governance, and the work of building recognition for one domain.
The trade-off is shared infrastructure and responsibility. A platform limitation or faulty template can affect every market. Local teams may also struggle if they need independent merchandising or publishing workflows that the central CMS cannot support. Subfolders are not an automatic ranking advantage, and localized pages still need useful content, discoverable links, and market relevance.
Subdomains: useful separation with additional coordination
Subdomains such as de.example.com provide a distinct hostname while retaining the main brand domain. They can make sense when a regional site needs a different platform, deployment schedule, or hosting configuration. They are a technical and organizational choice, not a shortcut to geographic targeting.
Expect to coordinate crawling rules, sitemaps, tracking, navigation, and template quality across hosts. Search engines can understand relationships between subdomains, but do not assume that links or recognition earned by one host will make every regional host equally competitive. Choose this structure because operational separation solves a real problem, not because a subdomain is presumed to rank better.
Country-code domains: strong local identity at a higher operating cost
Country-code top-level domains, such as example.de for Germany, generally provide a clear geographic signal and can reinforce a local brand presence. They suit businesses with established country operations, distinct catalogs, or teams responsible for their own marketing and customer experience. Some country-code extensions are treated as generic by search engines, so verify the treatment of the extension you are considering.
The costs extend beyond domain registration. Each domain needs technical maintenance, content governance, monitoring, and promotion. Naming availability and registration eligibility can vary. A country domain also does not solve multilingual needs within that country: a local site may still require language folders and hreflang annotations.
Check your existing domain before expanding. Putting international folders under a country-specific domain can send a mixed message about the site's intended geography. If you already use a country domain, compare the cost of separate market domains with the disruption of moving to a generic domain before making a structural change.
Choose a Structure Based on Operations and Market Goals
Start with the least complex structure that supports the business requirements you can actually fund. A small team testing demand in two additional languages has different needs from a retailer with country-specific stock, local marketing teams, and independent checkout systems. The structure should support those differences without multiplying work unnecessarily.
Map the audience: list each required language and country combination, and explain what changes for that audience.
Map ownership: identify who approves translations, maintains commercial details, resolves technical issues, and monitors performance.
Test platform capabilities: confirm support for localized URLs, metadata, canonicals, hreflang, sitemaps, currencies, and navigation.
Estimate ongoing work: include content updates, domain administration, tracking, redirects, and quality assurance, not just launch costs.
Choose subfolders when one team and platform can serve the markets effectively; consider subdomains when technical independence is necessary; consider country domains when local operations and identity justify separate sites.
Record exceptions: a hybrid setup can be workable, but every exception should have a business reason and a clear maintenance owner.
Hypothetical example: a software company has one product, one CMS, and a central editorial team. It wants German and French translations but has no country-specific purchasing terms. Language subfolders are a reasonable starting point. A retailer with separate German and French inventory, local teams, and distinct fulfillment operations may have a stronger case for country domains, provided it can maintain and promote them.
Do not migrate a healthy international setup solely to match a preferred pattern. Changing domains or paths introduces redirect work, possible traffic volatility, and operational risk. If the current structure supports users and can be maintained reliably, fixing content and targeting errors may be more valuable than rebuilding URLs.
Implement Hreflang Without Creating Conflicting Signals
Hreflang identifies alternate language or regional versions of a page. It can connect URLs across folders, subdomains, and separate domains. It does not translate content, force indexing, or guarantee that a particular URL will appear for every user in a market. Its purpose is to help search engines choose an appropriate alternate when equivalent versions exist.
Build page-level alternate groups
Create a mapping between equivalent pages before generating annotations. A German product page should reference the corresponding French and English product pages, not their homepages. Each participating page should list itself and the other alternates, and those alternates should link back through their own hreflang annotations. If a translation does not exist, omit that alternate rather than sending users to an unrelated page.
Use supported language codes, optionally followed by a supported country code. For example, en is English, en-GB is English for the United Kingdom, and fr-CA is French for Canada. A country code alone is not a valid hreflang value, and UK is not the country code to use for the United Kingdom. Keep a validated locale list in your CMS rather than allowing editors to enter codes freely.
Align hreflang, canonicals, and indexing controls
Alternate URLs should normally be crawlable, indexable, return a successful response, and use self-referencing canonicals when you want them indexed independently. Do not canonicalize every localized page to the global English version: that asks search engines to consolidate pages that hreflang presents as distinct alternatives. For substantially duplicated regional pages in the same language, decide whether separate indexing is genuinely needed and review the canonical strategy rather than applying a blanket rule.
Reference final absolute URLs, including the correct protocol and hostname, rather than redirecting or obsolete addresses.
Keep noindex pages, blocked URLs, errors, and unrelated destinations out of alternate groups.
Use x-default when you have a suitable fallback, such as a neutral language selector or global page; it is optional and does not replace language annotations.
Choose a maintainable delivery method: HTML head annotations, XML sitemaps, or HTTP headers for appropriate resources such as PDFs.
If you publish annotations through multiple methods, ensure they agree. Multiple implementations are not required and can create avoidable inconsistencies.
Give users a visible language or country selector that links to accessible URLs. Avoid mandatory IP-based redirects that prevent visitors or crawlers from reaching other versions. A dismissible location suggestion is usually less disruptive. Keep each localized page available at a stable URL rather than changing its entire language only through cookies or browser preferences.
Audit International Pages for Indexing and Targeting Errors
Audit one complete user journey in each market before relying on a sitewide crawl. Start with a search landing page, follow category and product links, switch language, and continue toward the main conversion. This often exposes problems that valid hreflang markup cannot fix, such as navigation returning users to the global site or a checkout that does not support the advertised destination.
Discovery: confirm localized pages have crawlable internal links and appear in the appropriate XML sitemaps. Hreflang is not a substitute for navigation.
Access and rendering: check response codes, robots.txt, noindex directives, login barriers, and whether important localized content is available to search engines.
Canonical selection: compare declared canonicals with search-engine-selected canonicals using URL inspection where available. Investigate unexpected consolidation.
Content quality: inspect titles, headings, body copy, product details, structured data, and supporting information for incomplete or incorrect localization.
Market experience: verify currency, stock, delivery eligibility, contact details, and form behavior. A correctly targeted page can still be commercially unusable.
Prioritize errors by scope and impact. A template that canonicalizes an entire language folder to another market deserves attention before an isolated missing annotation. After fixing a systemic issue, recrawl representative templates and inspect a sample of URLs. Search engines need time to recrawl and reassess pages, so a deployment is not proof that indexing has already changed.
A wrong-market URL appearing in search does not prove that hreflang is broken. Check whether the intended page is indexed, sufficiently localized, internally linked, and relevant to the query. Canonical selection and content similarity can also affect which version appears.
Measure Visibility and Traffic by Market
Build reporting around intended audiences rather than domains alone. For each locale, track search impressions, clicks, query patterns, landing pages, organic visits, and meaningful conversions. In Google Search Console, combine country filters with page filters to examine which URLs receive visibility in each market. Country data reflects user location, not a definitive statement of language preference.
Review country and landing-page combinations for signs of mismatches. If a global English page receives most clicks from a market with a dedicated local version, investigate the underlying queries and the local page's indexing before changing annotations. Some cross-market traffic is legitimate, especially for multilingual users and broadly useful informational content.
Segment branded and non-branded searches so existing brand demand does not hide weak discovery in a new market.
Compare equivalent page groups, such as product categories or guides, rather than sites with very different content inventories.
Use market-specific keyword samples when monitoring rankings, with consistent location, language, and device settings.
Check analytics configuration across domains and subdomains; broken cross-domain measurement can distort sessions and conversion attribution.
Annotate launches, migrations, major content releases, and tracking changes so performance shifts have context.
Evaluate conversions against actual market availability and account for seasonality, promotional activity, and consent-related measurement gaps.
Your next step is to create a locale map: one row for each intended audience, with its language, country scope, URL location, content owner, and commercial differences. Use that map to choose the simplest workable structure, then pilot one complete set of equivalent pages. Validate indexing controls, canonical tags, hreflang, navigation, and reporting before expanding the same pattern across the site.