The four decisions that determine whether a multilingual WordPress site compounds or stays a footnote.

Most WordPress sites that need multilingual support reach for Weglot, the dominant SaaS player in the space—and when handled correctly, its front-end scraping magic is incredibly convenient. But the tooling discussion often misses the much harder problems: the technical, compliance, and information architecture (IA) choices that come with a multilingual rollout. How your URLs are structured, how you prevent translated content from decaying out of sync, how you quarantine customer PII from being scraped by a third-party service, and how you route visitors without shattering your page caching or destroying your SEO. The wrong choices on any of these can trap an agency in maintenance hell or trigger legal compliance liabilities. Here is the realistic architectural blueprint and the choices that actually move the needle.

Multilingual WordPress sits in a tooling category that’s been settled for years: Weglot, WPML, Polylang, TranslatePress, MultilingualPress, and a handful of smaller players. Weglot is the most widely deployed and the easiest to set up (cloud SaaS, integrates with any theme). WPML is the most feature-complete (lives in WordPress, supports any post type). Polylang is the most lightweight. All of them work well in the right context.

What matters more, and rarely gets discussed in tooling reviews, is the set of architectural decisions a multilingual rollout forces a site to make. URL structure, translation workflow, content currency, tooling fit, and SEO equity. Getting these right is what determines whether the multilingual investment compounds or stays a footnote.

The URL-structure decision.

There are three patterns for multilingual URLs, each with different SEO and UX implications:

• Subdirectory: /en/, /fr/, /es/. All languages share the same domain. SEO authority concentrates. This is the default and recommended pattern for most sites.
• Subdomain: en.example.com, fr.example.com. SEO authority is more fragmented. Useful when each language version is genuinely a different operational entity (different country team manages it, different legal disclosures, different brand voice).
• Separate ccTLDs: example.com, example.fr, example.es. Maximum localization signal to Google for local-market SEO. Highest cost: separate domain registrations, hosting, SSL, and legal entities. The right call only for businesses with dedicated country teams and country-specific operations.

For most multi-language sites, subdirectories are right. The exception is large multi-region businesses with country-specific brand voice and operations, where the ccTLD pattern’s overhead is worth it.

Choosing your translation stack.

The translation tooling market splits roughly into two architectural camps, and both are legitimate.

The cloud-hosted camp—Weglot is the most widely deployed, with several competitors in the same family—runs the translation layer as a service. The site sends content to the vendor, the vendor returns translated versions, and visitors get served the appropriate language based on detection logic the vendor manages. Configuration is fast, the editorial workflow is straightforward, and the vendors offer Data Processing Agreements (DPAs) that cover the GDPR/CCPA compliance posture the same way Google Analytics, Stripe, HubSpot, and most other production SaaS vendors do. For teams that want multilingual as a managed service layer outside WordPress, this is the path of least resistance, and the one most multilingual sites end up running on.

The WordPress-resident camp—WPML, Polylang, TranslatePress, MultilingualPress, and a few others—runs the translation layer as plugins inside the WordPress install. Translations live in the WordPress database, language switching happens in PHP, and the translation workflow is part of the existing editorial process. Configuration takes longer and the editorial workflow has more moving pieces, but the multilingual layer lives on the same infrastructure as everything else on the site.

Both camps support proper hreflang, per-language sitemaps, translated metadata, and the SEO discipline covered below. Both camps have well-documented compliance paths. The decision between them isn’t which is “safer”—it’s which fits the team and the site:

• Editorial preference. Teams that want translation managed outside WordPress lean cloud. Teams that want everything inside WordPress lean resident.
• Existing infrastructure. Sites already running a complex WordPress stack often prefer keeping multilingual in-stack. Sites that intentionally minimize plugins prefer offloading.
• Audience profile. Some industries with strict data-residency requirements (healthcare, finance, certain government-adjacent work) make the decision based on the audit. For most general-purpose business sites, either path works.
• Team capacity. Resident options need more in-house WordPress fluency. Cloud options need less.

The wrong move is picking either one on instinct without doing the audit. The right move is doing the audit and picking the option that fits—which more often than not is Weglot, because it’s mature, well-supported, and the operational model fits how most teams actually work.

The translation-currency problem.

Static translations made once at launch decay. The English content evolves, the translated content doesn’t, and the user experience in non-English languages slowly drifts out of sync. Six months in, the German translation is showing services the company stopped offering and missing services that launched last quarter.

The patterns that work to keep translations current:

• Per-page freshness tracking. The CMS tracks when the source English page changed and flags the corresponding French page as needing review.
• Automated machine translation on update. When the English content is updated, a translation API automatically generates a draft update for the translated versions; the team reviews and approves before they go live.
• Professional review for high-value pages. Marketing-critical pages (homepage, services pages) get human review; long-tail blog content rides on the auto-translation.

The maintenance pattern is the part most multilingual rollouts under-invest in, and it matters more than the tooling choice. Either camp above supports a healthy maintenance pattern; neither one enforces one.

The auto-detection vs. explicit-picker trap.

When a visitor lands on the site, what language do they see?

• Explicit picker first (recommended). The visitor is served the default language and uses a clear toggle to switch. This is the safest architectural pattern. It plays perfectly with server-side page caching and ensures Googlebot (which crawls from US IPs without language headers) can index every version of your site.
• Auto-detect via IP or Browser Headers. If you attempt to force auto-redirects in PHP, you can instantly break your page caching and trap Googlebot in redirect loops, destroying your SEO. If you absolutely must auto-route users based on location, it needs to be handled at the edge (e.g., Cloudflare Workers) before the request hits the WordPress origin. Even then, auto-detection is often wrong for multilingual users or expats.

The SEO-equity question.

Each language version is its own SEO surface. Google ranks each language separately. The right architecture lets each version accumulate authority independently:

• hreflang tags. Every page in every language has hreflang tags declaring the alternates. This tells Google “these pages are the same content in different languages” and prevents them from competing with each other in search results.
• Per-language sitemaps. Each language has its own XML sitemap, referenced from robots.txt.
• Translated metadata. Page titles, meta descriptions, and image alt text get translated, not just the body content.
• Locale-appropriate URLs. The French version’s URLs are in French where it makes sense (/fr/services/architecture-plateforme rather than /fr/platform-architecture).

When this is worth doing.

Multilingual makes sense when:

• The site serves audiences whose first language is meaningfully different from the site’s default language.
• The non-default-language audiences are large enough that translation pays back (rough rule of thumb: 10%+ of total traffic from a non-default language audience justifies translation for that language).
• The brand has the operational discipline to sustain translated content currency.

It’s overkill when:

• The non-default-language audience is small and English fluency is high in those markets.
• The site’s content changes too frequently for translation maintenance to keep pace.
• The legal/regulatory environment doesn’t strictly require it.

For sites where multilingual genuinely matters, the architectural decisions outlined above are what determine whether the investment compounds. The tooling choice is the starting line, not the finish line.

A recent regional automotive dealership engagement shows what these architectural decisions look like in practice: the URL structure, hreflang, and translated-metadata work that turns multilingual from a translation overlay into a search-engine surface with its own ranking lift.

See Data Privacy & Compliance for how multilingual fits with the broader privacy posture.