2026
Multilingual IVF Platform
A fertility-care platform in English, Hindi, and Marathi from one Next.js codebase — locale routing and per-language SEO so each version is independently discoverable.
A healthcare platform for fertility (IVF) services, serving patients in English, Hindi, and Marathi from a single Next.js App Router codebase built on next-intl.
The engineering story isn't "the site has three languages" — it's the content architecture that makes language a routing dimension instead of three drifting copies, and the per-language SEO that makes each version findable by the people who search in it.
The default way multilingual sites die: the second language ships as a copy of the first, the third as a copy of the second, and within months they're three sites that disagree — worst case in healthcare, where the content is the product.
Discoverability compounds it. A patient searching in Hindi or Marathi should land on a Hindi or Marathi page ranked in its own right — not on an English page with a language switcher, and not on a locale page search engines treat as a duplicate.
How it fits together
One page tree under a locale segment. next-intl resolves the locale from the URL and feeds every page from per-locale message files; layout, routing, and components exist exactly once. Adding a language is adding a locale's messages and metadata — not duplicating pages.
Each locale renders its own metadata — titles, descriptions, canonical URLs, and hreflang alternates linking the versions — so search engines index three first-class page sets instead of one page set and two shadows.
Client project, built end to end.
- The locale-segmented App Router architecture and next-intl message structure.
- Per-language SEO: localized metadata and the alternate/canonical wiring that keeps each locale independently indexable.
- Deployment: hosting and domain configuration.
Language architecture
- English, Hindi, and Marathi from one codebase — a single page tree, per-locale content.
- New locales add without touching page structure.
Discoverability
- Per-language metadata and SEO so each locale ranks for searches in its own language.
- Locale-aware URLs a patient can read, share, and return to.
- Next.js App Routerlayouts + a locale segment give multilingual routing its natural shape
- TypeScriptbaseline choice
- next-intllocale resolution and message loading that follows the App Router's grain instead of fighting it
- Tailwind CSSbaseline choice
rationale is given only where the choice wasn't the obvious one.
Where it got difficult
Language as data, not structure
- symptom
Multilingual requirements pull hard toward per-language page trees — the path of least resistance that guarantees drift the moment content changes in one language and not the others.
- investigation
The question that settled the architecture: when a fourth language arrives, what should the diff look like? If the answer includes copied page files, the structure is wrong.
- root cause
Treating language as a property of pages instead of a dimension of routing.
- fix
A single page tree under a locale segment, with next-intl supplying per-locale messages. Content varies; structure doesn't. The fourth language is messages plus metadata, no new pages.
- tradeoff
Every piece of copy has to live in message files rather than inline JSX — more ceremony on day one, and the discipline only pays off from language two onward. Here, language two was the brief.
Three languages search engines respect
- symptom
Localized pages that exist but don't surface: searches in Hindi or Marathi resolving to the English pages, or locale variants competing with each other as duplicates.
- investigation
Discoverability per language is metadata work, not translation work — each locale needs its own titles and descriptions, plus explicit signals about how the versions relate.
- root cause
By default the locales look, to a crawler, like near-duplicates of one canonical site rather than three intentional versions.
- fix
Per-locale metadata generated with the pages, canonical URLs per version, and hreflang alternates declaring the relationship — each language indexable and rankable in its own right.
- tradeoff
SEO outcomes are observable, not controllable: the work sets the conditions and the ranking follows on the search engine's schedule, which is a longer feedback loop than any other part of the build.
- Internationalization is a data-modeling problem wearing a UI costume. Solve where content lives and how routes resolve, and the visible part mostly follows.
- In multilingual SEO the deliverable is independence: each language earning its own place in results, not borrowing the English version's.
- A translation workflow for the client — the architecture makes new content cheap to add in every language, but someone still has to notice when one locale falls behind.