What a 10-language website actually involves

Short version: we rebuilt this site to run in 10 languages. The engineering is a one-time setup — routing, hreflang, locale detection. The ongoing work is translation quality and per-market SEO. Below are the actual numbers, because most writing on international websites is abstract and the specifics are what help you budget.

Most articles about building for multiple countries — including our own guide — talk in principles. This one is a teardown of a real system with every number attached: the site you're reading.

What "10 languages" means here

Six English-speaking countries share a single /en URL, placed in each country's results by hreflang alone — no duplicate pages. Spanish and Portuguese are each split into two genuinely different translations, because European and Latin-American variants differ enough in tone and vocabulary to matter for trust.

The numbers

• ~305 statically generated pages at the time of writing. Home, services (6 + index), work case studies (6 + index), blog, FAQ, and the not-found page — rendered once per locale at build time.
• ~170 URLs in the XML sitemap, each carrying its full hreflang cluster.
• 31 hreflang annotations on every page — one per language/region variant (including en-GB, en-US, de-AT, de-CH, es-MX, es-419 and so on) plus x-default.
• ~3,260 translated strings — 326 per locale, split across a UI dictionary and a longer page-content dictionary.
• First-load JavaScript: 199 kB for the homepage, 126–131 kB for content pages. Adding locales added zero runtime weight — only the active locale's strings ship to the browser.
• Blog: English only for now. The other locales show a localised "no articles yet" state and their post URLs return 404 rather than a thin machine-translated page.

How locale gets chosen

No IP redirection. In order of priority:

1. A NEXT_LOCALE cookie, if the visitor has already chosen or been assigned one.
2. The browser's Accept-Language header, matched to the closest supported locale.
3. A default (en).

Bare es resolves to Latin-American Spanish and bare pt to Brazilian Portuguese — the larger audiences — while es-ES and pt-PT are served only to browsers that specifically ask for them. Every page is reachable directly by URL (/de/, /ja/blog), so search engines crawl every locale without ever being redirected.

The translation process

1. Draft — first pass generated with an LLM, working from the English source dictionary.
2. Fluency review — a structured second pass on all five non-English language families, fixing the predictable machine-translation errors: UI labels translated as full sentences, calqued idioms ("this path is not in motion" rendered literally), wrong register, and a dangling adjective used as a noun ("static" as an ad-creative type). About 35 corrections across the six original locales.
3. Native sign-off — not yet done, and flagged as required before any paid campaign in a given market. This is the honest status: the translations are fluent and structurally correct, but a native speaker should read each one before it carries ad spend.

The point of the workflow is that steps 1 and 2 are cheap and fast, step 3 is targeted (you only pay for native review of markets you're about to invest in), and a sync process flags the other languages for update whenever the English source changes.

The one constraint we'd change

This site is on a .co.in domain. That's India's country-code TLD, and Google treats it as a strong signal that the whole site is for India. hreflang still disambiguates language for the other nine markets — a German searcher gets the German page — but it can't override the country signal. So the non-India markets sit under a lower ceiling than they would on a neutral .com or .co.

It's a deliberate trade-off: the domain was already established, migrating carries its own SEO cost and risk, and the India market is real. But if you're choosing a domain before going international, choose a generic TLD (.com, .co, .io) and use subdirectories. The ccTLD decision is the one that's genuinely hard to undo.

What this means for your project

• The engineering is a one-time cost. Routing, hreflang generation, locale negotiation, the dictionary system — build it once, correctly, and adding the eleventh language is a translation task, not an engineering one.
• Budget for translation quality, not hosting. Ten locales added no meaningful hosting cost. The real spend is the review workflow and per-market content.
• Don't machine-translate your blog. An empty localised blog with an honest "coming soon" beats 13 posts of untrusted auto-translation that a native reader bounces off.
• Decide the domain and the Spanish/Portuguese split before you build. Both are painful to change later.

If you're planning a multi-market site, start with the full guide, then tell us which markets you're targeting — international builds are one of the things we do most, and Ayurexim is a brand we took from a single market to international shipping.