An international SEO strategy is an architecture decision first and a translation project second. For Indian SaaS and edtech companies selling into the US, MENA or Southeast Asia, the two questions that actually determine outcomes are: which domain structure you commit to, and whether your Indian English content is quietly competing against itself in en-US markets. Most guides on this topic are written by translation vendors, so they lead with hreflang syntax and never get to strategy.
Key Takeaways
- The ccTLD vs subfolder vs subdomain decision is largely irreversible in practice. Make it deliberately, before you have 500 pages.
- For most Indian SaaS and edtech companies under $10M ARR, subfolders on a single .com are the correct default.
- Hreflang solves duplication and targeting, not ranking. It tells Google which version to show, not that any version deserves to rank.
- The en-IN problem is real: Indian English pages competing against en-US pages for identical queries. Hreflang en-IN is worth implementing only under specific conditions covered below.
- Offshore trust signals, pricing presentation, entity information, support hours, named team, local proof, often matter more than technical SEO for conversion in US and MENA markets.
- Currency presentation is a conversion and a crawl problem simultaneously. IP-based currency switching without distinct URLs is the most common own-goal.
- This post stays architectural. Vernacular and Indic-language content strategy is a separate discipline with separate rules.
Architecture first. Every content decision downstream inherits this choice.
The Decision Nobody Makes Deliberately
Here is how it usually happens at an Indian SaaS company. The domain is a .com. Someone in sales wins a UK deal, so marketing spins up a /uk/ page. Then a partner in Dubai wants Arabic, so someone registers a .ae. Then the growth team launches blog.company.com because the CMS was easier. Eighteen months later you have three architectures, no hreflang, and a Search Console property structure nobody understands.
The architecture decision costs almost nothing to make correctly at the start and costs six figures to unwind at scale. Make it before you need it.
ccTLD vs Subfolder vs Subdomain: The Comparison
| Factor | ccTLD (example.ae) | Subfolder (example.com/ae/) | Subdomain (ae.example.com) |
|---|---|---|---|
| Geo-targeting strength | Strongest: automatic | Good, set in Search Console | Good, set in Search Console |
| Authority consolidation | Worst, each domain starts at zero | Best, all links feed one domain | Weak, treated as partially separate |
| Local trust perception | Highest in MENA and Europe | Moderate | Low |
| Setup and maintenance cost | Highest: registration, hosting, certs, legal | Lowest | Medium |
| Requires local entity/presence | Sometimes (.ae, .in restrictions) | No | No |
| Speed to launch a new market | Slow, weeks to months | Fast, days | Medium |
| Risk if a market fails | Stranded domain asset | Trivial, remove folder | Low |
| Server/CDN flexibility | High | Medium | High |
| Right for | Enterprise with local entities, MENA-heavy, regulated | Most Indian SaaS/edtech, content-led growth | Legacy stacks, separate tech per region |
| Rough breakeven | Above ~$20M ARR or a legally required entity | Default choice | Only when infra forces it |
The Honest Recommendation
Use subfolders on your primary .com. For an Indian company with limited link acquisition capability in foreign markets, authority consolidation is worth more than the marginal geo-targeting benefit of a ccTLD. You will not build enough links to a .ae to make it rank on its own within two years.
The exception is MENA. In UAE and Saudi markets, a .ae or .sa carries genuine buyer trust weight that a /ae/ folder does not, and if you already have a local entity, the cost calculation changes. If you're selling enterprise software into Gulf government or banking, take the ccTLD seriously.
Avoid subdomains unless your infrastructure genuinely forces them. They give you the worst of both: you still have to build authority separately, and you don't get the trust benefit of a local domain.
Language vs Country
Do not conflate these. /en/ targets a language. /ae/ targets a country. /ae/ar/ targets both. Decide which axis actually drives your differentiation:
- Selling identical product into US, UK, Australia? You need language-only structure, possibly with minor content variants. Country folders add complexity for no gain.
- Selling into UAE with Arabic content, different pricing and different compliance claims? You need country-plus-language.
- Selling into Singapore and Malaysia in English with different pricing? Country-only, same language.
Most Indian SaaS companies over-engineer this and end up maintaining twelve variants of a page that differ by one price string.
Hreflang: What It Does and Where It Breaks
Hreflang tells search engines which URL variant to serve to which language-region audience. It does not improve rankings, it does not consolidate authority, and it does not fix duplicate content in the sense people usually mean.
The Syntax, Briefly
Implement via HTML <link> tags in <head>, HTTP headers for non-HTML files, or XML sitemaps. Sitemaps scale best above a few hundred URLs.
<link rel="alternate" hreflang="en-us" href="https://example.com/us/pricing" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/pricing" />
<link rel="alternate" hreflang="en-in" href="https://example.com/in/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />Google's localised versions documentation is the authoritative reference; read it rather than a vendor blog post.
The Five Failure Modes I See Constantly
- Missing return links. If page A declares B as an alternate, B must declare A. Non-reciprocal annotations get ignored entirely. This is the most common failure by a wide margin.
- Self-referencing tag omitted. Every page in the cluster must include an hreflang tag pointing at itself.
- Wrong code order. It is
en-in, language then region.in-enis invalid and silently ignored. - Pointing at non-canonical or redirecting URLs. Hreflang must point at the canonical, 200-status URL. Chains break it.
- No x-default. Without it, unmatched users get whatever Google guesses. Set it to your global or US page.
Hreflang Does Not Rescue Weak Content
If your /uk/ page is your /us/ page with "color" changed to "colour", hreflang will correctly serve it to UK users: and it still won't outrank a genuinely UK-focused competitor. Hreflang is a routing instruction, not a quality signal.
The en-IN Problem
This is the section nobody writes, and it's the one Indian marketers actually need.
Indian English and American English pages competing for the same query is a self-inflicted wound.
What the Problem Actually Is
You are an Indian company. Your blog is written in Indian English, priced in rupees, with examples from Indian companies. It ranks well in India. Now you launch a US motion and create US-targeted pages on similar topics.
Three things go wrong:
- Google frequently shows your India-focused page to US searchers, because it's older, more linked and more established. Your bounce rate from US traffic is terrible and you blame the ads.
- Your two pages compete for the same query, splitting signals.
- US buyers land on a page with ₹ pricing and Indian case studies, and immediately read you as "not for us."
Is hreflang en-IN Worth Implementing?
Honest answer: it depends on whether you have genuinely different content, and most companies do not.
Implement en-IN hreflang when:
- You have materially different pages per market: different pricing, different case studies, different compliance claims, different product tiers.
- India is a meaningful revenue market you intend to keep serving, not a legacy artifact.
- You have the engineering capacity to maintain reciprocal annotations across the full page set as it grows.
Do not implement en-IN hreflang when:
- Your "India version" and "US version" differ only by currency symbol. Consolidate into one page with dynamic currency display instead.
- You have fewer than about 50 pages per market. The maintenance burden exceeds the benefit; canonicalise to one version and target with content.
- You're pre-product-market-fit in the new geography. Don't build architecture for a market you might exit in six months.
The Middle Path Most Companies Should Take
One canonical English page per topic, written in neutral international English, with:
- Currency and pricing switched by explicit user selection stored in a cookie, not by IP redirect.
- Case studies from multiple geographies within the same page.
- Region-specific landing pages only for genuinely region-specific offers: pricing pages, compliance pages, partner pages.
This gives you one strong page instead of three weak ones, which is almost always the better trade for a company under about 200 pages.
Neutral International English, Practically
Avoid: lakh, crore, "revert back", "do the needful", "prepone", "kindly", "passed out" for graduation, "cost only 5k". These read as unmistakably Indian to a US or UK buyer, and while none of them hurt rankings, they hurt conversion.
Also avoid over-correcting into American idiom you don't use naturally. Neutral, plain, direct English travels fine.
Currency and Pricing Presentation
The Technical Trap
The most common architectural mistake I see: IP-based currency switching that changes the displayed price without changing the URL. Googlebot crawls predominantly from US IPs, so it sees your USD price and caches it. Your Indian users see rupees. Your structured data emits one of the two arbitrarily, and rich results show the wrong currency to half your audience.
The fix: either distinct URLs per pricing region with proper hreflang and matching structured data, or a single canonical URL with one authoritative price in structured data and a clearly labelled, user-initiated currency selector.
The Positioning Trap
Indian companies routinely under-price into US markets by 60-80%, reasoning from Indian cost structures. The buyer does not read this as value. They read it as a quality signal, and a bad one: particularly in B2B SaaS, where an unusually low price triggers questions about longevity, support and security posture.
Price to the market you're selling into, not to your cost base. If you need a lower tier for price-sensitive segments, package it as a genuinely reduced tier, not as a discount on the same thing.
The Offshore Trust Problem
This is where Indian brands lose deals that SEO already won.
The buyer can tell where you are. What they need to know is whether that's a problem.
What Buyers Are Actually Worried About
Not your nationality. They're worried about: timezone coverage for support, data residency and compliance, whether you'll exist in three years, and whether a dispute has any practical remedy.
Signals That Address Those Worries
- Named humans. A team page with real names, real photos, real LinkedIn links. Anonymous companies read as risky everywhere, and disproportionately so across borders.
- Explicit support hours in the buyer's timezone. "Support available 9am-6pm ET" is worth more than "24/7 support" that isn't specific.
- Data residency statements. Where is customer data stored? Say it plainly on a dedicated page. For EU and MENA buyers this is often a gating question.
- Compliance artefacts. SOC 2, ISO 27001, GDPR posture: if you have them, they belong on a crawlable page, not just in a sales deck.
- Local customer logos and case studies. One US customer case study does more for US conversion than ten Indian ones.
- A real registered entity statement. If you have a US or Singapore subsidiary, say so in the footer. If you don't, say where you are honestly rather than obscuring it, obscuring it is worse than being offshore.
- Local phone presence. A US or UK number that actually gets answered.
What Not to Do
Do not fake local presence. A virtual office address in Delaware with no staff is transparent to anyone who checks, and getting caught costs you the deal and the reputation. Being clearly an Indian company with excellent, specific trust signals beats pretending badly.
Technical Foundations You Cannot Skip
Search Console Setup
Separate properties per subfolder or subdomain if you use them, plus a domain-level property. Set international targeting where applicable. Without this you cannot diagnose which market is failing. Google's managing multi-regional sites guidance covers the targeting mechanics.
Server Location and CDN
Serving US traffic from a Mumbai origin without a CDN is a Core Web Vitals problem before it's anything else. LCP under 2.5 seconds at the 75th percentile is hard across 200ms of transcontinental latency. Use a CDN with edge presence in every target market. This is cheap and non-optional.
Crawl Budget Across Variants
Six market variants of 400 pages is 2,400 URLs. If most of them are near-identical, you're spending crawl budget to have Google discover pages it will ignore. Another argument for fewer, stronger variants.
Avoiding Automatic Redirects
Never auto-redirect users by IP without an option to override. It breaks crawling, it infuriates travelling users, and Google explicitly advises against it. Search Engine Land has covered the recurring damage this causes to international visibility for years. Offer a dismissible banner suggesting the local version instead.
A Realistic Launch Sequence
Phase 1 (Months 1-2): Decide architecture. Subfolder unless there's a specific reason otherwise. Set up Search Console properties and international targeting. Deploy CDN.
Phase 2 (Months 2-4): Build the trust layer: team page, data residency, support hours, compliance page, local entity disclosure. This is content, not code, and it's the highest-conversion work.
Phase 3 (Months 4-8): Build genuinely market-specific pages: pricing, one or two localised landing pages, one local case study. Implement hreflang only across this small, genuinely differentiated set.
Phase 4 (Month 8+): Expand content depth in the winning market. Do not expand into market three until market two is producing revenue.
The single biggest failure I see is Phase 4 attempted at Phase 1: five markets launched simultaneously with translated content and no trust layer, generating nothing anywhere.
Frequently Asked Questions
Should I use a ccTLD or a subfolder for international SEO?
Subfolders on a single .com for most Indian companies, because authority consolidation matters more than marginal geo-targeting when you can't build local links yet. Consider ccTLDs for MENA markets where local domains carry real buyer trust, or when a legal entity requirement already exists.
Does hreflang improve rankings?
No. It controls which language-region version gets served to which audience and prevents variants from being treated as unintentional duplicates. Ranking still depends entirely on the content and links behind each URL.
Is hreflang en-IN worth implementing?
Only when you maintain genuinely different content for Indian and international audiences, different pricing, case studies or compliance claims, and have enough pages to justify the maintenance. If the versions differ by a currency symbol, consolidate to one page instead.
Why does my India page rank in the US instead of my US page?
Usually because it's older, better linked and has more engagement history. Hreflang helps signal intent, but if the US page is thinner, Google will keep preferring the established one. Strengthen the US page rather than relying on annotations.
Should I hide that we're an Indian company?
No, and attempts to do it are usually obvious. Address the underlying concerns instead: support hours in the buyer's timezone, data residency, named team, local references, compliance documentation. Specific transparency outperforms vague concealment.
How should I handle multiple currencies?
Either distinct URLs per pricing region with matching hreflang and matching structured data, or one canonical URL with a user-selected currency toggle and one authoritative price in structured data. Never IP-switch prices on a single URL without addressing what the crawler sees.
How many international markets should I launch at once?
One. Get it to revenue, learn what the trust and content requirements actually are, then take those learnings to the second market. Simultaneous multi-market launches from India almost universally underperform.
Do subdomains hurt international SEO?
They don't hurt so much as fail to help. You get partial authority separation without the local trust benefit of a ccTLD. Choose them only when infrastructure constraints genuinely require it.
What's the most common hreflang mistake?
Missing return links: page A declares B, but B doesn't declare A. Non-reciprocal annotations are ignored entirely, so the implementation silently does nothing. Validate reciprocity across the whole cluster, not page by page.
Does server location still matter with a CDN?
For static assets, no: the CDN handles it. For dynamic and API responses, origin location still shows up in INP and time-to-first-byte. Consider edge compute or a regional origin if your app is heavily dynamic in a distant market.
Should I translate content or write it natively?
Translate reference and documentation content; write marketing and conversion content natively for the market. Translated positioning copy reads as translated, and in competitive B2B categories that's a real disadvantage.
If you're an Indian SaaS or edtech company planning a global motion and the architecture question is still unresolved, that's the cheapest problem you will ever fix, and the most expensive one to leave alone. I write about organic growth for Indian brands at younusfardeen.com. Worth a look before you register that third domain.