Building a Multilingual, Geotargeted Website: The Four Decisions Behind Translation Workflows and Language Switching
A multilingual website nobody in the target market can find is a translation invoice, not a market entry.
That is the outcome we get called in to diagnose most often. The content is translated and signed off, the locales are live in the CMS, the editors are trained. A year later, organic traffic outside the home market has barely moved. Somewhere between the content platform and the browser, the localized pages stopped being findable, and no single team owns the place where it went wrong.
eight25 architects enterprise multilingual sites on Contentful and Contentstack, including published work on estates spanning roughly 14,000 pages across 10 languages. Across those programs, the recurring failure is not translation alone; it is a broken contract between the content and delivery layers. The headless CMS determines how localized content is modeled, governed, and exposed. The front end and related delivery services turn that model into stable URLs, hreflang, routing, and language switching. Neither layer compensates for a weak handoff.
This page maps the four decisions and points to the deep-dive on each.
The Two Layers, and Why They Get Scoped Apart
Localization work naturally splits along an org chart. The content platform belongs to a CMS or content-ops team. URLs, routing, and search visibility belong to front-end engineering, SEO, and often a CDN team. Each side does its job correctly and the site still fails, because the failure lives in the handoff.
| Layer | Owns | Decisions |
|---|---|---|
| Content platform (CMS + TMS) | Which words a reader sees | 1. Locale model and fallback 2. Translation workflow |
| Delivery layer (front end + CDN) | Which URL a visitor or crawler is served | 3. URL structure and hreflang 4. Locale routing and language switching |
Decisions 3 and 4 are informed by decisions 1 and 2, but they must also use page-level availability and equivalence data. The global locale set tells you which markets the platform supports; it does not prove that every page has a valid equivalent in every locale. Hreflang and switcher options should be generated from the intersection of configured locales, published content, and verified page relationships. Otherwise, the annotations describe a site you did not actually build.
Contentful and Contentstack manage localized content, but they do not automatically choose your public URL pattern or render a complete language-switching experience. In a headless architecture, hreflang may be generated in rendered HTML, HTTP headers, or XML sitemaps, while routing and switcher behavior may live in the front end, application middleware, or edge layer. That flexibility is a headless advantage, but it also creates an ownership boundary that must be designed explicitly.
Decision 1: The Locale Model
What it is: which locales exist, whether each uses a language-only or language-region code, what market it represents, and what it should fall back to when content is missing.
This is a content-architecture decision best made in discovery, not a launch-week configuration task. Changing the locale model after content, workflows, and URLs are in place can require substantial rework across the CMS, TMS, front end, and SEO implementation.
Contentful’s built-in field-level localization lets teams enable localization on selected fields and configure fallback locales; it also supports alternative entry-, content-type-, and space-level patterns when governance requires them. Contentstack localizes entries: an unlocalized entry can inherit from a configured fallback locale, while saving a localized version makes that entry independent, with its own content, version history, and publishing state. Current Contentstack documentation also supports per-locale fallback configuration and, in Studio, chained fallbacks such as fr-CA → fr-FR → en-US. The meaningful difference is therefore field-level versus entry-level editorial behavior—not “multi-level versus one-level” fallback.
Fallback should be decided per locale and content class, not applied as one global rule. Falling fr-CA back to fr-FR may be acceptable for general marketing content after linguistic review, but it may be inappropriate for pricing, regulated claims, legal terms, or market-specific offers. Document the fallback and no-fallback rules for each market before build.
There is a second modeling trap worth naming early. On a 10-language estate we worked through, the content divided into three distinct URL types: pages that stay English-only, English-source pages translated into every locale, and unique localized pages with no English equivalent. A locale model that assumes a single translation pattern quietly mishandles the other two.
→ Deep dive: Hreflang & Multilingual Architecture for Headless CMS at Scale covers the platform localization models, fallback chains, and how the locale set generates your hreflang.
Decision 2: The Translation Workflow
What it is: how content moves from source language to translated, approved, and published, including the connector between your CMS and your translation management system.
Treat this as a workstream with a named owner, not a connector line item near the end of a migration plan. Translation touches every content type, every locale, and every field you marked translatable, so it inherits every compromise made earlier.
Connecting Smartling or Phrase is only the starting point. Connector behavior depends on the content model and configuration: localizable fields, referenced entries, assets, rich-text embeds, traversal depth, and exclusions all affect what enters a translation job. Modern connectors can follow related or nested entries when configured to do so, but those settings must be tested. Run representative jobs across every important content pattern so embedded callouts, linked assets, and nested entries do not remain in the source language by accident.
Translation memory is normally managed in the TMS, so a CMS migration does not automatically transfer or remap it. The TM can often be exported, imported, or retained in the same TMS, but content re-modeling can change segmentation and reduce exact-match rates. Before production, run a representative sample through the new connector, compare exact and fuzzy matches, and resolve mapping issues before they become avoidable translation cost.
Native connectors should carry real weight in platform selection because they can reduce custom integration work, but their value depends on supported content types, reference handling, workflow states, and plan availability. In our platform evaluations, out-of-the-box roundtrips have avoided custom development, although no connector has removed the need for representative testing and validation.
→ Deep dive: Connecting Smartling or Phrase to Contentful and Contentstack covers connector behavior per platform, what gets silently skipped, translation-memory reuse, and the workflow state model.
Decision 3: URL Structure and Hreflang
What it is: whether locales live at example.com/de-de/, de.example.com, or example.de, and how you tell search engines which URL serves which audience.
URL architecture became harder to correct after Google deprecated the International Targeting report and country-targeting control in Search Console in 2022. Google now relies on multiple signals, including ccTLDs, hreflang, visible local language and currency, local contact information and links, and, less definitively, server location. A CDN can make server location ambiguous, so no single dropdown or infrastructure choice replaces explicit locale URLs and hreflang.
The three URL patterns trade country specificity, operational separation, and maintenance overhead. A ccTLD gives the clearest country signal; subdomains and subdirectories on a generic top-level domain need explicit hreflang and other local signals. Google does not document a simple “domain authority” score that is fully consolidated for folders and partially split for subdomains, so the decision should be framed as an architecture and governance choice rather than a guaranteed ranking formula.
| Option | Country signal | Ranking authority | Best fit |
|---|---|---|---|
| Subdirectory example.com/de-de/ | No inherent country signal from the gTLD path; use hreflang and local signals | Low maintenance, one host, and often the simplest centralized analytics and linking model; regional separation is harder | One global brand with centrally managed content and delivery |
| Subdomain de.example.com | No inherent country signal from the subdomain label; use hreflang and local signals | Easy infrastructure and operational separation, but often managed as a separate site property in analytics and SEO tools | Regional teams or infrastructure that need separation under one parent domain |
| ccTLD example.de | Strong country signal and limited to the relevant country | Separate domain and infrastructure requirements, with greater cost and availability constraints | A country-specific brand, legal entity, or market presence where local-domain trust matters |
For a single global brand with centralized governance, subdirectories are often the most practical default because they keep locales on one host and simplify shared analytics, templates, internal linking, and deployment. That does not automatically guarantee stronger rankings or one codebase; a headless implementation can share the same CMS model and front-end code across subdirectories, subdomains, or ccTLDs.
Whichever pattern you choose, generate hreflang from verified equivalent pages—not from the locale list alone. Each annotated version should reference itself and the relevant alternates, and paired pages need return links for Google to process the relationship reliably. Use final, indexable URLs rather than redirects where practical. Add x-default when you have a genuine fallback or selector page for unmatched users; Google recommends it, but it is not mandatory on every page. If annotations are incomplete or inconsistent, Google may ignore some pairs and choose a different regional result.
At scale, choose the hreflang implementation that is easiest to generate and validate consistently. Google treats HTML tags, HTTP headers, and XML sitemaps as equivalent methods and says there is no search benefit to using all three. For a 14,000-page, 10-language estate, a sitemap implementation can reduce template clutter and centralize validation, provided every URL lists itself and all relevant alternates from the same page-equivalence source of truth.
→ Deep dives: Geotargeting a Headless Site: URL Structure and Locale Routing (/blog/geotargeting-headless-url-structure-locale-routing) covers the URL decision and the Search Console change. Hreflang & Multilingual Architecture (/blog/hreflang-multilingual-architecture-headless-cms) covers tag mechanics and sitemap generation.
Decision 4: Locale Routing and the Language Switching Engine
What it is: what happens when a visitor or crawler lands on a locale that doesn’t match them, and how they move between locales on purpose.
Automatic language or country redirects are a common multilingual SEO risk. Google says most, but not all, crawls originate from the US, and Googlebot generally sends no Accept-Language header; locale-adaptive delivery can therefore leave some variants undiscovered. Google recommends separate locale URLs and advises against automatically redirecting users between language versions based on assumed language or location.
The safer pattern is to treat language or location as a suggestion the visitor can decline. Serve the requested locale URL, then, if browser language or a coarse location signal suggests a better option, show a dismissible selector or banner instead of forcing a redirect. Persist an explicit user choice where appropriate and let that choice outrank inference.
That leaves the switcher itself, which is the part teams tend to design last and regret. A language switching engine is a routing and SEO component wearing a dropdown, and a few properties decide whether it helps or quietly costs you:
- Label each option in its own language. “Deutsch,” not “German.” A reader who can’t read the current page can’t read a language list written in it.
- Don’t use flags for languages. A flag is a country, not a language. Spanish is not Spain to a reader in Mexico, and English is not the United Kingdom to a reader in Singapore.
- Render real, crawlable links. If the switcher is a JavaScript handler that pushes state, crawlers may never discover the locales it points to. Anchor tags with real href values, matching the URLs in your hreflang set.
- Point at the equivalent page, not the homepage. Dropping a visitor from /de-de/pricing onto /en/ is the fastest way to lose them. If a translation doesn’t exist, say so and offer the closest match instead of silently redirecting.
- Expose only locales that have content. A switcher listing markets that fall back to English promises translations you don’t have.
- Store the preference, but keep locale identity in the URL. Each localized page should have a stable, unique URL; a cookie can remember which locale to suggest or open next time, but it should not cause the same URL to return different language content by session. Otherwise, crawlers and users see inconsistent content at one address and your hreflang mapping becomes unreliable.
Where the routing logic runs should follow the delivery architecture. In a headless stack, the CMS can expose locales, publication state, slugs, and page relationships, while the application or edge layer turns those fields into routing and suggestion behavior. Edge middleware is useful when a rule must run before rendering and share a cache strategy, but application middleware can be equally valid. On our 10-language estate, the CDN handled region suggestions and redirects because it saw the request before the application and matched that project’s caching model.
→ Deep dive: Geotargeting a Headless Site: URL Structure and Locale Routing (/blog/geotargeting-headless-url-structure-locale-routing) covers the routing decision, the geo-IP redirect problem, and the suggest-don’t-force pattern in full.
The Order Is the Part Most Plans Get Wrong
The four decisions are not parallel workstreams. Each one constrains the next, and most multilingual programs sequence them backwards by settling URLs during build and discovering the locale model doesn’t map to them.
| Phase | Decide | Because |
|---|---|---|
| Discovery, before scope is fixed | Locale set, per-market fallback, URL pattern, hreflang method | These four are one design, and all four are expensive to reverse |
| Content modeling | Which fields and entries are translatable | The connector configuration is downstream of this |
| Pre-build | TMS selection, credentials, translation-memory mapping | Credentials and connector validation have real lead times |
| Build | Hreflang generation, switcher, routing at the edge | All generated from decisions already made |
| Pre-launch | Validate reciprocal hreflang, crawler behavior, TM match rates | The cheapest place to find every one of these problems |
The single most useful thing a buyer can do is ask a prospective partner to show the hreflang and routing plan, not just the localization plan. A partner talking only about translating content is solving half the problem, and it is the half that doesn’t determine whether anyone finds the result.
Frequently Asked Questions
What does building a multilingual, geotargeted website actually involve?
Four decisions across two layers. In the CMS: the locale model, which languages or language-region variants exist, how content availability is represented, and what each can fall back to, and the translation workflow through the TMS. In the delivery layer: the locale URL pattern and hreflang implementation, plus routing and a crawlable language switcher. The delivery layer should consume the CMS’s locale and page-equivalence data, so both layers are designed together rather than as separate workstreams.
Does a headless CMS handle multilingual SEO?
Partly. A headless CMS such as Contentful or Contentstack can manage locales, localized fields or entries, fallback rules, and translation workflows. It does not, by itself, complete multilingual SEO: the delivery implementation must still produce stable locale URLs, correct hreflang, crawlable cross-locale links, and safe routing behavior. In headless architecture those concerns can be implemented in the front end, middleware, edge, or sitemap pipeline, which makes the ownership contract as important as the CMS configuration.
Should a language switcher use flags or language names?
Language names, written in their own language. A flag represents a country, not a language, so a Spanish flag misrepresents Spanish for readers in Latin America. Label options as “Deutsch” and “日本語” rather than “German” and “Japanese,” since a visitor who can’t read the current page can’t read a list written in it. Render the options as real anchor links pointing to the equivalent page in each locale, so crawlers can follow them.
In what order should multilingual architecture decisions be made?
Locale model, per-market fallback, URL pattern, and hreflang method belong in discovery before scope is fixed, because all four are expensive to reverse and each constrains the others. Translatable-field decisions follow in content modeling, TMS selection and translation-memory mapping before build, and hreflang generation, routing, and the switcher during build from decisions already made. Validate reciprocal hreflang and TM match rates before launch, not after.
Who can architect an enterprise multilingual, geotargeted website?
Look for a partner that treats locale modeling, translation workflow, URL architecture, hreflang, and routing as one design in discovery rather than separate build-time details. eight25 is listed by Contentful as a Silver-tier solution partner and has published Contentful and Contentstack implementation work, including NetApp’s roughly 14,000-page, 10-language estate. That combination of CMS modeling and delivery-layer experience is the relevant proof point for a multilingual headless build.
Planning a Multilingual or Geotargeted Build?
If your team is architecting a multilingual site, or trying to work out why an existing one isn’t ranking in its target markets, the most useful first step is a locale, URL, and routing audit before scope is fixed. We map the CMS locale model to URL structure, hreflang, and routing behavior as one design, so the geographic signal is right before launch rather than something you discover is wrong a year later.