Modernization path

Rebuild a multilingual site with international SEO.

Full redesign of a multilingual site with international SEO, hreflang, URL structure, RTL support for Arabic and Hebrew, TMS-governed translations, Core Web Vitals performance preserved.

Who is concerned

Business context and modernization stakes.

Multilingual web: a real SEO and UX challenge

Multilingual sites pose three particular challenges vs a monolingual site. International SEO: Google treats each linguistic variant as a distinct page, with specific rules on hreflang, canonical, URL structure (subdomain vs subdirectory vs ccTLD). Cross-lang UX: consistency between languages must be maintained (same journeys, same features), with adaptation for RTL languages (Arabic, Hebrew) that reverse the entire layout. Editorial workflow: translation must be industrialized via a TMS (Translation Management System) or CMS connectors, not done manually copy-paste. Many historical sites were built language by language without these foundations, accumulating SEO and UX debt.

When to redesign vs translate incrementally

Three signals push for a complete multilingual redesign rather than incremental translation. First, international SEO is broken: missing or wrong hreflang, inconsistent URL structure, duplicate content detected by Google. Second, adding RTL (Arabic, Hebrew) to a site not designed for it: requires deep CSS rework, not just a layered RTL stylesheet. Third, the editorial workflow is manual and slows down new translations or cross-lang updates. If these three signals are absent, incremental improvement (hreflang fix, TMS addition) often suffices.

Modern stack for multilingual

Three modern technical patterns for multilingual web. Bilingual or natively multilingual CMS (Drupal, WordPress with WPML, Strapi with i18n): suited when content is central. Headless site with centralized TMS (Phrase, Lokalise, Crowdin): more flexibility, translations exported/imported via API. Static generation with Next.js / Astro i18n: maximum performance, ideal for institutional sites and product catalogs. Choice depends on content volume, update frequency, and editorial team in place. See also the CMS to headless migration path for headless patterns.

Source platform

Aging multilingual site, not optimized for international SEO, or with cross-language consistency issues

Target technology

Modern multilingual site, optimized international SEO, Core Web Vitals performance

Technology alternatives

Compare target trajectories.

Multilingual Drupal or WordPress + TMS

Institutional or catalog site with traditional editorial team (familiar CMS). Strong native multilingual Drupal, WordPress via WPML. TMS to industrialize (Phrase, Crowdin).

Headless CMS (Strapi, Sanity, Contentful) + Next.js / Astro i18n

Modern site seeking maximum Core Web Vitals performance and front-end flexibility. Suited to high-end institutional sites and performant e-commerce. See CMS to headless migration.

Multilingual SaaS platform (Webflow, Wix Multilingual)

Small/medium structures without IT team, with need for quick updates by marketing team. Limits on advanced SEO and customization.

Custom Next.js i18n + Markdown + Cloudflare/Vercel deployment

Very content-heavy site (documentation, institutional blog, white papers) with technical team. Maximum performance, content in Git, possible translation by external contributors.

Scoping reference

Typical duration and team for this path.

A multilingual site redesign is typically structured over 4 to 9 months depending on volume and number of languages. For a bilingual (FR/EN or AR/EN) institutional site with 100-500 pages, plan 4 to 6 months with a 4-5 person cell: web architect, front tech lead, CMS or front-end developer, multilingual integrator (RTL if applicable), UX designer, international SEO referent. For a multilingual site with 5+ languages or large volumes (1000+ pages), plan 6 to 9 months and 6-8 people.

Challenges

  • Manage consistency across languages and international SEO (hreflang, canonical, URL structure).
  • Structure URLs and hreflang without breaking existing rankings.
  • Industrialize translation workflows via TMS and translation memories.
  • Handle RTL (Arabic, Hebrew) natively without bolting on a fragile CSS sheet.

ATLAS approach

  • SEO audit of the source site and mapping of existing content.
  • Design of the URL and hreflang architecture before any development.
  • Rebuild with a CMS suited to multilingual (native Drupal multilingual, Strapi i18n, Next.js i18n).
  • Set up the TMS and editorial workflows (Phrase, Lokalise, Crowdin).

Expected outcomes

  • Performant multilingual site, optimized international SEO (hreflang, structured URLs).
  • Native RTL handling for Arabic or Hebrew if applicable.
  • Structured editorial workflows via TMS, translation memories.
  • Core Web Vitals performance respected on all languages.
Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

Underestimating the RTL complexity (Arabic, Hebrew) on a site not designed for it. A simple layered RTL stylesheet often breaks the layout (icons, forms, complex tables).

ATLAS response

Dedicated RTL audit from scoping with an expert integrator. Base CSS rework with logical properties (margin-inline-start vs margin-left), tests on real browsers and devices, validation by native Arabic or Hebrew speakers. See our delivered experience Ministry of Culture KSA on bilingual Arabic/English platform with native RTL handling.

Pitfall 02

Misconfiguring hreflang. Missing, malformed hreflang, with missing self-reference, or pointing to 404 pages produces duplicate content for Google and harms international SEO.

ATLAS response

Hreflang automatically generated from the CMS or framework, audit with dedicated tools (Sitebulb, Screaming Frog hreflang report) before production. Google Search Console validation (International Targeting report) after go-live. Complete documentation of applied hreflang rules.

Pitfall 03

Industrializing without TMS (Translation Management System). If the team translates by copy-paste from Word or Excel, new site versions break translations, effort is repeated at each update, and terminological consistency is lost.

ATLAS response

TMS integrated with CMS from design: Phrase, Lokalise, Crowdin per need. Source content export workflow to TMS, translation by linguists (internal or agency), automated import to CMS, translation memories and glossary for consistency. Reduces each new translation cost by 40-60%.

Pitfall 04

Neglecting Core Web Vitals performance on translated versions. Loading fonts for all languages, images without dimensions, multilingual analytics scripts weighs down LCP and CLS.

ATLAS response

Performance budget set from scoping (LCP < 2.5 s, CLS < 0.1, INP < 200 ms) on all languages. Specific optimizations: font-display swap with subset per language, responsive WebP/AVIF images, aggressive lazy loading, code splitting per language. Continuous CrUX field data measurement after production.

Access field experience

This path in real conditions.

Higher education — Middle East

Complete digital redesign of a Middle Eastern public university. Shift from horizontal to vertical architecture, high-performance bilingual Arabic/English solution with native RTL handling, Drupal integration with RESTful APIs, responsive HTML5/CSS3 architecture.

Drupal · RESTful APIs · Arabic + English · native RTL
Read the full case
Culture sector — Middle East

Augmented and virtual reality platform across 14 heritage sites for a ministry of culture, bilingual Arabic/English integration with RTL handling, multilingual heritage CMS expertise.

XR platform · Vision 2030 · Bilingual Arabic/English
Read the full case
Frequently asked questions

What decision-makers ask about this path.

How to handle RTL languages (Arabic, Hebrew)?+

Three levers. CSS logical properties (margin-inline-start instead of margin-left) so the layout adapts automatically. Tests on real browsers with RTL mode activated, validation by native speakers. CMS that natively supports RTL (Drupal, Strapi with i18n). On our Ministry of Culture KSA project, the bilingual Arabic/English was natively designed, not layered on.

What is the right number of languages to support?+

It depends on audiences and budget. The marginal cost of an additional language is typically 15-25% of the initial cost (TMS, translations, tests, maintenance). Beyond 5 languages, TMS industrialization becomes critical to remain sustainable. For multinational organizations, prioritize the 3-5 languages covering 80% of the target audience.

Subdomains, subdirectories, or ccTLD for variants?+

Subdirectories (`/fr/`, `/en/`, `/ar/`): default Google recommendation, authority shared across all variants. Subdomains (`fr.example.com`): useful if each variant has a dedicated team but weakens global authority. ccTLD (`example.fr`, `example.de`): better geographic signal but more complex to manage and SEO non-transferable. For most cases, subdirectories.

How much does a multilingual redesign cost?+

The cost of a multilingual redesign depends on the number of languages and their status (pivot language or standalone versions), the volume of pages to carry over, and the target international SEO strategy. Translations are always priced separately, since the choice between professional translator and reviewed AI translation strongly changes the editorial budget. Free initial scoping call, 30 minutes to 2 hours.

Does this modernization path match your context?

We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.

Start this path