International SEO: Technical SEO lessons from production

Your e-commerce platform works well in English, but now you're expanding to India, Brazil, and Southeast Asia. Suddenly you're juggling multiple languages, currencies, and regional preferences—and search engines need to understand your architecture. International SEO: Technical SEO lessons from production means getting the mechanics right: URL structure, language tags, translated metadata, and user choice—not forced redirects. Get this wrong and you'll confuse both Googlebot and your customers.

Why international SEO matters for your architecture

When you serve content in multiple languages or regions, search engines need to know which version to show to which user. Without clear signals, Google will either:

• Index the same content multiple times (diluting ranking authority)
• Show the wrong language version to users (damaging conversion and trust)
• Crawl inefficiently, wasting your crawl budget on duplicate content
• Struggle to understand which version is canonical for each locale

We've seen this play out in production across travel platforms serving 15+ languages and ride-hailing services managing regional compliance. The teams that nailed technical international SEO scaled faster and cheaper. The ones that treated it as an afterthought burned crawl budget and lost organic traffic when they launched new markets.

URL structure: Subfolders are your best friend

You have three main options for URL structure: subdomains (en.example.com), country-code TLDs (.co.uk, .de), or subdirectories (/en/, /ta/, /pt-br/). For most teams, subfolders are the easiest to manage, crawl efficiently, and scale.

Why subfolders win:

• Single domain authority builds across all versions (better for smaller sites)
• Easier to implement hreflang annotations
• Simpler to manage SSL certificates and server configuration
• Lower operational overhead than managing multiple domains
• Better for shared infrastructure (CDN, caching, analytics)

Here's what a typical structure looks like:

example.com/en/products/wireless-headphones
example.com/ta/products/wireless-headphones
example.com/pt-br/products/wireless-headphones
example.com/de/products/wireless-headphones

Use ISO 639-1 language codes (en, fr, de, ta, hi) and ISO 3166-1 region codes (US, GB, IN). For regional variants like Portuguese in Brazil, use the combined code: pt-br, pt-pt. This clarity matters for both crawlers and your team.

Subdomains and country-code TLDs have their place — if you're running truly regional services with local servers, compliance requirements, or separate brands in each market. But start with subfolders. You can always restructure later; moving domain authority is painful.

hreflang: Tell Google about every language version, including itself

The hreflang tag is how you tell Google "this page has versions in other languages, and here's where to find them." Without it, Google assumes each language version is independent, competing content.

The critical rule: annotate every version, including the default language. Many teams forget to include an hreflang self-reference, which creates ambiguity.

Here's the correct pattern in your HTML head:

<link rel="alternate" hreflang="en" href="https://example.com/en/products/wireless-headphones" />
<link rel="alternate" hreflang="ta" href="https://example.com/ta/products/wireless-headphones" />
<link rel="alternate" hreflang="pt-br" href="https://example.com/pt-br/products/wireless-headphones" />
<link rel="alternate" hreflang="de" href="https://example.com/de/products/wireless-headphones" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/wireless-headphones" />

Notice the x-default tag at the end. This tells Google: "If the user's language doesn't match any of my listed versions, show them this one." Use it to point to your most generic or English version.

Where to put hreflang:

• HTML head tags (the simplest, works for most sites)
• XML sitemap (if you have hundreds of language variants)
• HTTP headers (for non-HTML content like PDFs)

We recommend starting with HTML head tags. They're transparent, debuggable, and work reliably across hosting setups.

Common implementation gotcha: If you're serving the same URL for multiple languages (say, /products/headphones serves English to US users and Tamil to Indian users based on IP detection), you cannot use hreflang. The page itself must have a unique URL per language. This is why content negotiation based on IP is problematic—we'll cover that next.

Translate everything: Metadata is as important as body text

Translation isn't just about the product description or article body. Google ranks on title tags, meta descriptions, image alt text, structured data, and URL slugs. If those are in English while the body is in Tamil, you signal confusion about what the page is actually about.

Here's what needs translation:

• Page title (60 characters): "Wireless Headphones – Premium Sound" → "வயர்லெஸ் ஹெட்ஃபோன்கள் – சிறந்த ஒலி"
• Meta description (155 characters): Summarizes the page in the target language
• URL slugs: Use readable keywords in the target language or keep them in English if your site uses English as the canonical language (this is a design choice)
• Heading tags (H1, H2, H3): First mention of keywords should be translated
• Structured data (JSON-LD): Include translated name, description, and breadcrumb labels
• Image alt text: Describe images in the page's language
• Internal link anchor text: Use translated keywords where relevant

Here's a realistic example of translated structured data for a product:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "வயர்லெஸ் ஹெட்ஃபோன்கள்",
  "description": "இந்த பாதுகாப்பான ஹெட்ஃபோன்கள் 30 மணிநேர பேட்டரி ஆயுட்டை வழங்குகின்றன।",
  "image": "https://example.com/images/headphones.jpg",
  "brand": {
    "@type": "Brand",
    "name": "AudioTech"
  },
  "offers": {
    "@type": "Offer",
    "price": "4999",
    "priceCurrency": "INR"
  }
}

The investment in full translation pays off. We've seen sites that translated only body content rank significantly lower for product category pages in new markets—because Google's snippet generation and relevance signals were confused by English metadata.

No forced redirects: Suggest a language; don't force it

This is where many teams create crawl nightmares. The temptation is strong: detect the user's IP, browser language, or regional headers and redirect them to the "right" version. Sounds helpful, right?

The problem: Googlebot gets redirected too. If Googlebot from the US visits your Indian subdirectory and gets redirected to /en/, Google may never index your Tamil content. Worse, redirects consume crawl budget and confuse hreflang signals.

The correct approach: Show content in the URL path; offer suggestions, not redirects.

Here's what we recommend:

1. Default to a neutral version: If a user lands on example.com without a language path, show your homepage with a language selector banner (not a redirect).
2. Respect user choice: Once they choose /ta/, store that choice in a cookie or URL parameter. Don't redirect based on IP on subsequent visits.
3. Allow direct access: Let users visit /de/ directly without redirection, even if they're not in Germany.
4. Use optional detection in the browser: Client-side JavaScript can suggest a language using navigator.language, but always let users override it.

Here's a lightweight implementation pattern:

<!-- Root page (example.com/) -->
<!-- Show language selector -->
<div class="language-selector">
  <p>Choose your language:</p>
  <a href="/en/">English</a>
  <a href="/ta/">Tamil</a>
  <a href="/pt-br/">Português</a>
  <a href="/de/">Deutsch</a>
</div>

<script>
// Optional: Suggest a language based on browser settings
const userLang = navigator.language.split('-')[0];
const supportedLangs = ['en', 'ta', 'pt', 'de'];
if (supportedLangs.includes(userLang)) {
  console.log(`Suggested language: /${userLang}/`);
  // Do NOT redirect; let the user decide
}
</script>

In production SaaS platforms, we've used a lightweight cookie to remember language choice and avoid showing the selector on every visit. This respects user intent while allowing full crawler access.

Common mistakes in international SEO implementation

Mistake 1: Forgetting the x-default hreflang. Without it, Google doesn't know which version to show to users in unlisted regions. Always include it.

Mistake 2: Mixing URL structure approaches. Don't use subfolders for some languages and subdomains for others on the same site. Pick one structure and stick with it. Mixing confuses both Google and your team.

Mistake 3: Redirecting based on IP. We mentioned this, but it deserves repeating: IP-based redirects break international SEO. Users in India visiting your UK site should be able to access /uk/ content if they want. Googlebot especially needs direct access to all versions.

Mistake 4: Partial translations. Translating only body text while leaving titles, meta descriptions, and structured data in English creates a fragmented signal. Commit to full translation or don't launch in that language.

Mistake 5: Using auto-translation without review. Google Translate is a great starting point but not production-ready. Idioms, cultural references, and product names need human review. A mistranslation damages trust and ranking credibility in that market.

Mistake 6: Not testing hreflang with Google Search Console. Use the "International Targeting" report in GSC to verify Google sees your hreflang annotations correctly. If annotations are malformed or missing URLs, Google ignores them silently.

Key takeaways

• Use subfolders (/en/, /ta/, /pt-br/) for URL structure. They're simpler to manage than subdomains and preserve domain authority.
• Annotate every language version with hreflang, including an x-default tag. Without it, Google treats each version as competing content.
• Translate metadata (titles, descriptions, alt text, structured data) alongside body content. Rankings depend on it, and partial translation sends mixed signals.
• Never force redirects based on IP or headers. Use URL paths to serve languages; offer suggestions with language selectors, not automatic redirects.
• Test your setup in Google Search Console's International Targeting report. Verify hreflang annotations are recognized and your crawl structure is clean.
• Plan for regional currencies, payment methods, and compliance (GDPR, data residency) alongside language content. International success is technical and product-level.