International SEO Site Structure Guide
How to choose a URL structure for multiple countries, implement hreflang correctly, and keep country and language versions from competing with each other.
International SEO means giving search engines a URL structure, language tags and internal links clear enough that they show the right country or language page to the right searcher. Get that structure right once, and every later decision about schema, canonicals or content becomes a per-market variation of one working page.
That structure is one piece of a longer technical SEO checklist; this post covers the parts specific to running more than one country or language on the same site.
في هذه الصفحة
What's the right URL structure for multiple countries?
Three structures work: subdirectories on one domain (/us/, /ca/), subdomains (us.example.com), or separate ccTLDs (example.ca). They differ mainly in how much authority the sections share and how much they cost to run.
Subdirectories inherit the root domain's authority immediately, since search engines treat the whole site as one entity. Subdomains are treated as more separate, so a new one starts with less inherited trust and takes longer to build its own ranking history. Separate ccTLDs are the most distinct signal of local relevance but the most expensive to maintain, because each one needs its own hosting, SSL and often a local business registration to purchase in the first place.
There is a fourth option worth naming only to rule it out: a URL parameter such as ?country=us. Search engines treat parameter-based versions as the same URL with different query strings, not as separate pages, so this structure cannot reliably show different indexed content per country at all. It shows up occasionally in older sites and is worth replacing on sight.
| Structure | Best for |
|---|---|
| Subdirectories (/us/, /ca/) | Most sites; fastest authority sharing, simplest to run |
| Subdomains (us.example.com) | A market that needs separate infrastructure but not a separate brand |
| ccTLDs (example.ca) | A market with a strong local presence, a local entity, or regulation that requires it |
Unless you have a specific reason to split infrastructure, start with subdirectories. Moving from subdirectories to a separate domain later is a full migration; moving the other way is rare enough that almost nobody plans for it.
How does hreflang tell search engines which version to show?
Hreflang is a set of tags that says "this page has equivalent versions at these other URLs, in these languages." Each version lists every other version, including itself — a return-tag mismatch is the single most common way hreflang breaks.
List every version on every version
If /us/ links to /ca/ and /uk/, then /ca/ and /uk/ must each list /us/, /ca/ and /uk/ in return. A one-way link is treated as invalid and ignored.
Use the right codes
Language first, region second, hyphen between: en-US, en-GB, ar-AE. A region code with no language code is invalid.
Add x-default once
One version, usually the language-neutral landing page or your largest market, catches searchers who match none of your listed regions.
Put hreflang in one place consistently
The HTML head, the XML sitemap, or the HTTP header — pick one mechanism per site. Mixing two increases the odds they disagree with each other.
Test the finished set with a crawler that reports return-tag errors specifically, not just a validator that checks syntax. Syntax errors are rare; broken return links are common, and they are also the hardest to spot by eye, because each individual tag can look perfectly well-formed while the set as a whole is inconsistent.
The other place hreflang quietly breaks is a redirect. If /us/ redirects to /us/en/ after a URL structure change but the hreflang tags on every sibling page still point at the old /us/ path, search engines now have to follow a redirect to confirm each tagged version, which is slower and less reliable than a direct link. Update hreflang targets in the same deploy as any URL change that affects them, not as a follow-up task.
Do GCC countries need separate pages, or can one Arabic page cover them?
Only when the underlying offer is actually identical. Saudi Arabia, the UAE and Qatar share Arabic as a language but differ in currency, shipping rules and often regulation, so a single shared Arabic page is correct only if none of that varies for your business.
Where pages do split by country, each one still needs distinct structured data, not just a distinct URL. The structured data basics that describe an Organization or Product once at the site level need a country-specific equivalent per page — a shared schema block with one address or currency baked in will describe every country version incorrectly except the one it was written for.
This is easy to miss because the visible page content can be correctly localized while the structured data underneath it is still generated from a single sitewide template. Check the rendered JSON-LD on each country page directly, not just the visible text, since the two are produced by different parts of most content systems and can drift apart without either one throwing an error.
How do you stop country versions from being flagged as duplicate content?
Give each version at least one genuinely local signal: local pricing, a local phone number, a local case example, or region-specific FAQ content. A page that differs from its sibling only in the hreflang tag reads as a duplicate to a crawler, because functionally it is one.
The unique parts do not need to be large. A currency, a delivery estimate and one locally relevant paragraph are usually enough to make a page distinct, as long as those elements are not themselves templated with the country name swapped in and nothing else changed.
Watch for the specific failure mode where a template swaps the country name into a sentence but leaves every other fact identical — same delivery time, same phone country code, same example. Search engines and readers both notice that pattern quickly, and it earns none of the credibility that a genuinely local page does. If you cannot write one true, specific sentence about a given country, that is usually a sign the market does not yet warrant its own page, and a shared version is the more honest choice until it does.
How do you confirm each country version is actually being crawled?
Check server logs for the crawler's actual requests to each country path, not just Search Console's coverage report, which can lag by days. Log file analysis covers how to pull and read that data; for international sites, the specific thing to look for is whether every country folder gets crawled at a similar rate, or whether one is being ignored.
A folder that gets no crawl traffic almost always has a discovery problem: it is missing from internal navigation, missing from the sitemap, or only reachable through a redirect chain the crawler gave up following. Fix discovery before assuming the content itself is the problem.
A newer country version competes for crawl attention with every other section of the site, and a crawler with limited time per visit will spend it wherever internal links point most often. If the new country folder is only reachable from a footer link buried three clicks deep, it will be crawled far less frequently than a section linked from the main navigation on every page, regardless of how good the content is once someone actually reaches it.
Does page speed matter differently across regions?
Yes, more than most teams expect. A server or CDN edge located near one market can leave a distant market's version loading noticeably slower, which affects both user experience and the Core Web Vitals score search engines measure per page. Mobile page speed covers the diagnostic steps in full; for international sites specifically, check where your CDN's edge nodes actually sit relative to each target country before assuming the code is the bottleneck.
| Symptom | Likely cause |
|---|---|
| One country loads fine, others are slow | No CDN edge near the slow country's typical connection path |
| All countries are slow on mobile only | Unoptimized images or render-blocking scripts, unrelated to geography |
| Slow only on first visit, fast after | Missing cache headers for that region's edge node |
What's the single most common international SEO mistake?
Auto-redirecting visitors by detected location or browser language, with no way to switch. It breaks hreflang's whole purpose, because a crawler that gets redirected away from the URL it requested cannot confirm that URL's content, and it traps a real visitor who wants a different version than the one guessed for them.
Use a suggestion banner instead: detect the likely country, offer the switch, and let the visitor decline it. Every URL should remain reachable and crawlable regardless of where the request comes from.
The second most common mistake is close behind: launching every new country version at once with no staggered rollout, then having no way to tell which one is underperforming because they all shipped in the same week with no baseline to compare against. Launch one or two markets first, confirm hreflang, crawling and indexing are behaving the way you expect, and only then repeat the same checklist for the rest. A mistake caught on two country versions is a quick fix; the same mistake caught after ten versions have gone live is a much larger cleanup.
أسئلة يطرحها الناس
Do I need a separate domain for each country?
No. Subdirectories on one domain consolidate authority fastest and are the easiest structure to maintain. Separate ccTLDs or domains only earn their cost when a market needs its own hosting, legal entity or brand, not for SEO reasons alone.
Does hreflang improve rankings on its own?
No. It is a signal that tells search engines which version to show a given searcher, not a ranking factor. A page with perfect hreflang and thin content in that language still will not rank.
Can two countries share one Arabic page?
Only if the offer, pricing and terms are genuinely identical across those countries. The moment currency, shipping or regulation differs, sharing a page produces wrong information for at least one country, which costs more than the extra page did.
How long before a new country version gets indexed?
Once it is crawlable and linked internally, usually days to a few weeks, similar to any new section. Slow indexing after that point is almost always a crawl or hreflang problem, not a patience problem.
المصادر
- Managing multi-regional and multilingual sites — Google Search Central (checked 22 September 2026)
- Tell Google about localized versions of your page — Google Search Central (checked 22 September 2026)
Get your international site structure audited before you scale it
احجز استشارة مجانية مدتها 30 دقيقة مع إبراهيم وجيريمي. ننظر في موقعك أثناء الحديث، وتخرج بخطة مرتّبة حسب الأولوية.
من كتب هذا
Ibrahem HelalCo-founder
Leads strategy and delivery.
يعمل على: SEO, GEO
راجعه قبل النشر Jeremy Zava، Co-founder.
المزيد عن هذا
- Technical SEO: the complete checklist for 2026Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
- Structured Data Basics: JSON-LD ExplainedStructured data labels page content so search engines can parse it directly. JSON-LD is Google's recommended format; it earns rich-result eligibility, not rank.
- Log File Analysis for SEO: A Starter GuideLog file analysis reads your server's raw access logs to see exactly which URLs search engine crawlers requested, how often, and what they got back.
- Mobile Page Speed Optimization GuideWhy mobile pages load slower than desktop, which Core Web Vitals to fix first, and how to make pages usable on slow or unreliable mobile networks.