International SEO is the discipline of telling search engines, clearly and consistently, which version of a page belongs to which audience. That sounds simple. In practice it touches domain strategy, server configuration, content operations, pricing, analytics and the way a company is organised. Get the structure right and each new market compounds on the authority of the last. Get it wrong and every market cannibalises the others.
I write this from an Indian vantage point: exporters selling into the US and Europe, SaaS products chasing US and UK pipeline, D2C brands opening to the Middle East. The mistakes repeat, and they are almost always decided in the first two weeks, before anyone writes a word of content.
Start with the question nobody asks: country, language, or both?
Before any technical decision, I make the team answer one question: are we targeting a country, a language, or a specific combination? These are different problems and they call for different structures.
- Country targeting means you have a reason to serve a geographic market differently: pricing, shipping, legal terms, local support, local competitors. An exporter shipping to the US and the UK is country targeting even though both markets read English.
- Language targeting means the same offer, in different languages, regardless of where the reader is. A documentation site that serves Spanish speakers in Spain, Mexico and the US alike is language targeting.
- Language-plus-country is the full matrix: French for France and French for Canada, Arabic for the UAE and Arabic for Saudi Arabia. This is the most expensive to maintain and most companies should not start here.
The answer drives everything downstream. A SaaS company with one product, USD pricing and a global English audience often needs no international structure at all. A D2C brand that charges in AED, ships from Dubai and runs Arabic support is a genuine country-targeting project. Confusing the two is how companies end up with six near-identical English sites competing with each other.
ccTLD, subfolder or subdomain
This is the decision that is hardest to reverse, so I spend the most time on it. There are three honest options and each has a cost.
| Structure | Example | Geo signal | Authority | Where I use it |
|---|---|---|---|---|
| ccTLD | brand.ae, brand.co.uk | Strongest; the TLD itself is a country signal | Each domain starts from zero and builds its own | Large brands with local teams, local legal entities and budgets to build authority per market |
| Subfolder | brand.com/ae/, brand.com/uk/ | Needs Search Console geo-targeting and hreflang | Shared across the whole domain | Default for most Indian exporters, D2C brands and SaaS companies |
| Subdomain | ae.brand.com, uk.brand.com | Needs geo-targeting and hreflang | Partially shared; treated as closer to separate sites | When the hosting or platform genuinely cannot serve subfolders |
My default is subfolders on a single .com. Authority earned by the Indian site helps the UK folder from day one, and there is one set of infrastructure to keep healthy. ccTLDs are right when the company already operates as separate businesses per country with separate budgets. Subdomains are the compromise I accept only when the platform forces it; they get the worst of both worlds in authority sharing.
Hreflang: what it does and the ways it breaks
Hreflang tells Google "this page has equivalents in these other languages or regions". It does not improve rankings. It helps Google show the right version to the right searcher and reduces the chance of regional versions being treated as duplicates. That is the whole job, and I treat hreflang as a system to be tested, not a tag to be added.
It can live in the HTML head, an HTTP header (for PDFs and other non-HTML files) or an XML sitemap. For sites with more than a few thousand URLs I prefer sitemaps, because annotations can be generated from the database and validated as a batch.
Failure modes I check for first
Missing return links
If page A says B is its French equivalent, B must say A is its English equivalent. Hreflang is only honoured when the relationship is reciprocal. One-way annotations are ignored, and a single missing return link in a cluster can invalidate the whole set.
No self-reference
Each page should include itself in its own hreflang set. Teams building hreflang from a template often list "all the other versions" and forget the current one.
Invalid codes
Language uses ISO 639-1 and region uses ISO 3166-1 Alpha 2. "en-UK" is wrong; it is "en-GB". "ar-UAE" is wrong; it is "ar-AE". The error will not throw a warning on the page, it will simply be ignored.
Pointing to non-canonical or non-indexable URLs
Hreflang must point at the canonical, 200-status, indexable version of each page. Pointing at a URL that redirects, is noindexed or canonicalises elsewhere breaks the set.
Mismatched x-default
x-default tells Google which version to show when no language or region matches. It should be the global page or a language selector, not whichever version a developer happened to pick.
Hreflang injected by JavaScript
If the annotations only appear after client-side rendering, they are at the mercy of Google's render queue. I covered why that is a problem in the JavaScript SEO guide; for hreflang the safe path is server-rendered head tags or sitemaps.
I validate hreflang with a crawler that checks reciprocity across the full site, and re-run it after every template deployment. Hreflang breaks silently, usually during a release that had nothing to do with it.
Localisation is not translation
Translation converts words. Localisation converts the page: the keywords people actually type, the units and currency, the examples, the trust signals and the calls to action. The gap between the two is where most international content fails.
A concrete example from the exporter world. An Indian manufacturer of industrial fasteners wants to rank in the UK. Translating "fastener manufacturer in India" to British spelling achieves nothing. The UK buyer searches for "BS 3692 bolts supplier" or "metric hex bolts UK stock", wants prices in GBP with VAT noted, wants delivery times to a UK postcode and wants to see a UK phone number or at least a UK-hours support line. None of that is translation. It is keyword research done again, per market, followed by content written against that research.
The same applies to SaaS. A page that converts in India with "starts at ₹999/month" will not convert in the US by swapping the currency symbol; US buyers compare against different competitors and respond to different proof. I treat every target market as a separate content brief, not a translation job.
Currency, pricing and the duplicate-content question
Currency signals intent to serve a market, and it is also a trap. If the UK and US pages are identical except for the price, Google may treat them as duplicates and consolidate them. Hreflang reduces this risk but does not eliminate it, because it is a hint rather than a directive.
My approach to regional duplicates is a combination of three things:
- Correct hreflang with self-referencing canonicals on each regional version. Never canonicalise the UK page to the US page; that tells Google the UK page is not the preferred version, and it will act on that.
- Genuine regional differences beyond the price: shipping terms, local proof, local examples, local contact details, regionally relevant FAQs. If there is nothing to say differently, that is a sign the market does not need a separate page yet.
- Avoiding automatic creation of regional versions for every URL. Blog posts and documentation usually do not need a per-country copy. Product and commercial pages often do. I decide per section, not per site.
For Indian companies there is a specific nuance: the Indian version is usually the original and strongest page, and new regional versions are thin. Launch one market, prove it, then add the next.
Geo-redirects: do not do this
The most damaging pattern I see is automatic redirection based on IP. A visitor from the US lands on brand.com/in/ and is bounced to brand.com/us/. It feels helpful. It is not.
Googlebot crawls predominantly from US IP addresses. If every request from a US IP is redirected to the US version, Google will never see the Indian, UK or UAE versions. Your hreflang points to pages Google cannot reach, your regional pages fall out of the index, and the company concludes international SEO "did not work".
- US IP request
- Forced redirect to /us/
- Googlebot never fetches /ae/
- /ae/ drops from index
- Hreflang set invalid
The correct pattern is a non-blocking suggestion: detect the likely region, show a dismissible banner, remember the choice in a cookie, and never redirect a crawler or a first visit. This is part of what I check in a technical audit whenever a site has more than one region, because it is the single fastest way to make an entire market disappear.
Market selection for Indian exporters, D2C and SaaS
Not every market deserves a folder. I score candidates on four things before any build work.
Demand you can verify
Search volume in that market's language for the queries you can plausibly serve, checked in a tool set to that country, not global numbers.
Ability to fulfil
Can you ship, invoice, support and comply there? A page that ranks for "deliver to Dubai" with no Dubai logistics creates refunds, not revenue.
Competitive gap
Who ranks today, and is there a reason you can displace them: better price, better range, better content, better product? Price alone rarely moves rankings.
Operational commitment
Someone has to own the market's content, keyword set and reporting for at least a year. Without an owner the folder decays.
For SaaS companies targeting the US and UK from India, the usual answer is a single English site, USD pricing with an optional currency toggle, and a small set of market pages where terminology differs (for example, "GST invoicing" content for India, "VAT invoicing" for the UK). The SaaS SEO guide goes deeper on how that content sits within the funnel. For the Middle East, Arabic is a genuine language decision, and I would not attempt it with machine translation on commercial pages; the vocabulary of Gulf Arabic search differs from Modern Standard Arabic enough that native review is not optional.
Measuring by market, not by site
A single blended traffic number hides everything. One market growing and one shrinking looks like "flat". I set up measurement per market before launch so the baseline exists.
| What to measure | How | Why it matters |
|---|---|---|
| Impressions and clicks per folder | Search Console property per folder, filtered by country | Separates "Google shows the UK page to UK users" from "the UK page gets traffic from India" |
| Wrong-version impressions | Search Console: filter the Indian folder to country = GB and vice versa | High wrong-version impressions mean hreflang or canonicals are not doing their job |
| Indexed URLs per folder | Sitemap-level coverage report per regional sitemap | Catches a folder silently dropping out of the index |
| Revenue or leads per market | GA4 with a market dimension derived from the URL path, not from the user's geography | Ties the SEO effort to the business reason the market was opened |
| Rankings in-market | Tracker configured with the market's location and language, not a global default | Global rank checks are meaningless for a UAE page |
Before any of this is measured, the structural basics have to hold: self-referencing canonicals on every regional URL, hreflang generated from one source of truth and validated for reciprocity, a Search Console property per folder, server-rendered head tags, and a robots.txt check that no regional folder is accidentally disallowed. These overlap heavily with site architecture and canonical tag hygiene, because international SEO is technical SEO with a geography dimension added.
The "wrong-version impressions" check is the one I would keep if I could keep only one. If the Indian page is shown to UK searchers for UK queries, something structural is broken, and content work on the UK folder will not fix it.
International SEO is not a translation project. It is a structural decision followed by a content programme, per market, with its own measurement.
Frequently asked questions
Should an Indian company use a .in domain or a .com for international SEO?
If the ambition is global, the primary domain should be a generic TLD such as .com. A .in domain is treated as geo-targeted to India and that cannot be overridden in Search Console. Many companies keep the .in for the Indian market and build international folders on a .com, but that doubles the maintenance; one .com with an /in/ folder is usually simpler.
Does hreflang help rankings?
No. Hreflang helps Google show the correct regional or language version to the right searcher and reduces the risk of regional versions being treated as duplicates. Rankings still come from relevance, content quality and authority. A correct hreflang set stops you losing visibility; it does not create it.
Can I just machine-translate my site into other languages?
For low-stakes pages like help documentation, machine translation with light review is often acceptable. For commercial pages it is a false economy: the keywords people use differ from literal translations, and trust signals, pricing and examples need to be local. I treat each commercial market as a separate keyword research and content brief exercise.
Why did my regional pages disappear from Google after I added geo-redirects?
Googlebot crawls largely from US IP addresses. If visitors from the US are redirected automatically to the US version, Google never reaches the other regional pages, cannot verify the hreflang relationships and eventually drops the versions it cannot fetch. Replace the redirect with a dismissible suggestion banner and exclude crawlers from any geo logic.
How many markets should I launch at once?
One. Prove the structure works, the hreflang validates, the market can be fulfilled and the measurement is in place, then add the next. Launching many thin regional folders at once dilutes crawling and creates internal competition that takes months to untangle.
Do I need separate pages for the US and the UK if both are in English?
Only where something genuinely differs: price, shipping, legal terms, terminology, local proof. If the pages would be identical apart from spelling, serve one English page and use hreflang with en-US and en-GB pointing to the same URL only if your platform supports that cleanly; otherwise a single "en" page with x-default is the safer choice.
Where this connects
International SEO is technical SEO with a geographic dimension, so the structural checks here live inside my Technical SEO Audit Framework. The rendering risks around hreflang and canonicals are the reason I ran the JavaScript rendering test in the SEO Lab. The SaaS organic growth case study shows how a multi-market content programme fits into a wider system, and if you want this implemented rather than recommended, my technical SEO service covers the structure, hreflang and measurement end to end. For the broader map of how this fits with everything else, start at the SEO Roadmap.