WordPress Multilingual Sites

WordPress has no idea that two posts are the same post in different languages. Everything a translation plugin does is built on top of that gap: it invents the relationship, the language switcher, the URL scheme and the fallbacks. Which plugin you pick matters far less than the four decisions below, all of which are expensive to change afterwards.

Decision one: the URL structure

Subdirectories keep one domain, one certificate, one hosting bill and one accumulating body of search authority. Separate domains split all of that, and are justified when each market has its own team, catalogue, prices and legal entity — a business decision that happens to have a URL consequence, not the other way round.

The query parameter option appears in older plugins and should be rejected outright: it is fragile in caching, ugly to share, and treated poorly by search engines.

Decision two: who translates, and what happens next time

This is the decision that kills multilingual sites, and no plugin solves it.

• Human translation produces content worth reading and costs money every time the source changes.
• Machine translation is instant, free at small volume, and reads as machine translation to a native speaker on exactly the pages where that matters — pricing, trust, legal.
• The hybrid — machine first pass, human editing on the pages that carry revenue — is what most working sites actually do.

Then ask the harder question: when the English page is edited next month, who updates the other five? A multilingual site is not a launch, it is an ongoing obligation proportional to the number of languages. Two well-maintained languages beat six stale ones, and stale translations are worse than no translation because they misinform confidently.

Decision three: what actually needs translating

More than the post content:

• Post and page bodies, titles and excerpts.
• Slugs, so URLs are readable in each language.
• Menus, widgets and site title.
• Categories and tags, which are separate objects.
• Theme strings shipped by the theme, and plugin strings.
• Form labels and validation messages, which are usually the last thing anyone checks — a specific gap on contact forms.
• Media alt text, and any text baked into images.
• Transactional email, if the site sells anything.
• Legal pages, which may need to differ rather than be translated.

The strings that are not in the database — those hard-coded in a theme or plugin — are handled through translation files or a string-translation interface. Themes that were not built for translation make this disproportionately painful, which is one more criterion for judging a theme.

Decision four: plugin or multisite

Two architectures, with different failure modes.

One site, a translation plugin. All languages share the database, the media library, the plugin set and the design. This is simpler and is right for most sites.

A multisite network, one site per language. Each language is a separate site with its own content, users and plugins, linked loosely. This suits genuinely divergent markets and costs you a network to run — see WordPress multisite.

The plugin route has a real lock-in worth stating: the language relationships live in the plugin's own tables. Change plugins later and you are migrating those relationships, which ranges from "there is a converter" to "re-link everything by hand". Choose once, deliberately, and treat it like the hosting decision rather than like installing a widget.

The technical details that actually break

hreflang. Every language version needs to declare the others, and each should declare itself. Missing or one-directional hreflang is the most common reason the wrong language ranks in the wrong market. Any competent plugin emits it; verify rather than assume, and treat it as part of the SEO checklist.

No automatic redirects by IP. Sending a visitor somewhere based on their location, with no way back, is the most disliked pattern in multilingual web design and it hides your other languages from crawlers. Offer a switcher; let people choose.

Caching per language. A page cache that ignores the language cookie or path will serve French to English visitors. Confirm the cache and the translation plugin know about each other before launch — the symptom looks like changes not showing.

404s from missing translations. Decide the fallback: show the source language, redirect to the language home, or hide the item from that language's navigation. Not deciding produces 404 errors in the languages nobody tests.

Fonts and layout. Some languages need character ranges your font does not include, and translated text runs longer than English by a noticeable margin. Both are design work — choosing fonts covers the subsetting question. Right-to-left languages need the theme to support the direction, which many do not.

Common mistakes

• Launching six languages with a team that can maintain two.
• Machine-translating the checkout and legal pages.
• Automatic redirection by IP address with no visible switcher.
• Translating posts but not slugs, menus or forms, producing a half-translated experience.
• Choosing a plugin on price without checking what leaving it involves.

Verify

Load each language's home page in a private window and confirm the language switcher reaches every other language and back. View source and check hreflang lists every version, including itself. Follow one product or article through: title, slug, category, menu, form labels, confirmation email. Then edit the source page and see what the plugin does — the honest test of a multilingual setup is not launch day, it is the first update.