Multilingual WordPress Website Examples (and What to Copy)

Four live multilingual WordPress sites, checked in September 2026: how each structures its language URLs, sets up hreflang and labels its language switcher, which patterns are worth copying, and one to avoid.
Get started
Take the tour
No card details No commitment

· Updated · Alex B · Blog

Summarize this post with: 8 min read
ChatGPT ChatGPT Perplexity Perplexity Grok Grok Google AI Google AI

Good multilingual WordPress websites share three habits. Every language lives on its own URL. Each page uses hreflang tags to tell search engines about its other language versions. And visitors can switch language from any page without losing their place. The four live examples below get there in different ways, one with a subdomain per language and others with plain subfolders, and one of them shows something you should not copy.

We checked each example’s live HTML in September 2026. All four run on WordPress (their pages load assets from wp-content), and we recorded the URL structure and hreflang setup of each. Sites change, so treat the details as a snapshot.

Key takeaways

  • Subfolders (example.com/de/) are the most common and simplest structure for multilingual WordPress sites. Subdomains suit large language communities that are managed separately.
  • Good sites include a self-referencing hreflang tag, the full set of alternates, and an x-default fallback.
  • Language switchers work best when they show language names in the language itself (Deutsch, Español) and appear on every page.
  • A regional site with different content in each country is a different thing from a translated site. Do not add hreflang between pages that are not equivalents.
  • A multilingual plugin and a hosted translation service can produce the same result. Judge the output rather than the tool.

Why look at real examples

A guide tells you what to do. A live site shows you what the finished thing looks like. When you study an example, check four things:

  1. URL structure. Where does the German version live?
  2. Hreflang. View the page source and search for hreflang. Are all language versions listed, including the page itself and an x-default?
  3. Language switcher. Where is it, how are the languages labelled, and does it keep you on the same page?
  4. Translation depth. Are the navigation, footer, buttons, dates and metadata translated, or only the body text?

Example 1: WordPress.org local sites (one subdomain per language)

WordPress.org runs a separate local site for each language community: German at de.wordpress.org, Spanish at es.wordpress.org, and so on.

What we found:

  • Each language has its own subdomain with its own lang attribute (<html lang="de"> on the German site).
  • The German homepage lists 156 distinct hreflang values, one for every local WordPress.org site, so search engines can match each searcher with the right community.
  • Each local site is run as its own space, with local news and content, rather than as a mirror of the English one.

The part worth copying: if each language has its own team, content and priorities, subdomains keep them apart while hreflang ties the equivalent pages together.

The part not to copy blindly is the scale. More than 150 language versions is a community project with volunteers in every language. Most businesses should start with two or three languages and do them well.

Example 2: the Mozilla Blog (subfolders with an x-default)

Mozilla’s blog at blog.mozilla.org keeps each language edition in a subfolder, including English (/en/) and German (/de/).

What we found:

  • The German homepage declares three hreflang alternates: en → /en/, de → /de/, and x-default → /en/.
  • The lang attribute on the German pages is de-DE.

For most sites this is the cleanest pattern to copy. Every language is a subfolder on one domain, so the site’s authority stays in one place, and x-default tells search engines which version to show people whose language is not covered. Our hreflang guide explains why the x-default line matters.

Example 3: TranslatePress.com (subfolders with language and region codes)

TranslatePress makes a WordPress translation plugin, and its own website is a multilingual WordPress site in English, Spanish, German, French and Italian.

What we found:

  • English sits at the root (translatepress.com/) and the other languages in subfolders (/es/, /de/, /fr/, /it/).
  • It lists each language twice in hreflang, once with a language-only code (es) and once with a language-region code (es-ES), plus x-default pointing to the English root.
  • The language switcher is present on the page and labels languages by name.

The part worth copying: keeping the original language at the root and adding translations in subfolders is easy on an existing site, because none of your current URLs change.

One thing to think about before you copy the rest. Listing both es and es-ES for the same URL is valid, but it only helps if you might later create separate versions for other regions (for example es-MX). If you have one version per language, language-only codes are enough. Our list of hreflang language codes helps you pick the right ones.

Example 4: Microsoft Source regional newsrooms (a regional site, not a translated one)

Microsoft’s news site runs on WordPress and has regional editions. You reach the German edition from news.microsoft.com/de-de/, and it lands on a regional page with a ?lang=de parameter.

What we found:

  • The German edition uses <html lang="de-DE"> and carries German-language stories.
  • We did not find hreflang tags in the head of the German page we checked.

That is correct for a regional newsroom, which is a separate publication and not a translation of the English site. Many German stories have no English equivalent, so hreflang between the regional pages would be wrong. Follow the same rule on your site: link equivalent pages with hreflang, and leave out pages that exist in only one market. Don’t copy the URL format, though. Google lists URL parameters such as ?lang= as “not recommended” for multilingual sites and prefers subfolders, subdomains or country domains (Google Search Central).

What the best multilingual WordPress sites have in common

PracticeWhy it mattersHow to check on your site
One URL per languageSearch engines index URLs; a language that only appears via a cookie or script may never be indexedOpen the translated page in a private window; the URL should be different
Complete, reciprocal hreflangStops language versions from competing and sends searchers to the right oneView source, search for hreflang, confirm every version lists every other and itself
x-defaultGives a fallback for unsupported languagesLook for hreflang="x-default"
Correct lang attributeHelps browsers, screen readers and translation toolsCheck the <html lang="…"> value on each version
Visible language switcherVisitors can correct a wrong guess; Google recommends linking language versionsSwitch languages from a deep page and confirm you stay on the equivalent page
Translated metadataTitles and descriptions are what searchers see firstCheck the <title> and meta description on a translated page

For a longer checklist, see our guide to best practices for WordPress multilingual websites.

How to build a site like these on WordPress

There are two broad ways to do it.

The first is a multilingual plugin that stores translations in WordPress, such as WPML, Polylang or TranslatePress. You create or translate each page inside WordPress, and the plugin handles URLs and hreflang. You get full control, at the cost of more setup, especially with page builders, custom fields and WooCommerce. See our comparison of Weglot, WPML and ConveyThis for how these approaches differ.

The second is a hosted translation service with a WordPress plugin, such as ConveyThis. You install the plugin and choose languages, and the service translates your pages and serves them on language URLs. You then review and edit the translations.

With ConveyThis for WordPress, the result matches the patterns above:

  • Each language is served on its own URL: subfolders by default on WordPress, or subdomains if you prefer.
  • Hreflang tags are added automatically, and page titles, meta descriptions and JSON-LD are translated.
  • A language switcher is added to every page. You choose flags or no flags, and whether languages are labelled in English, in their own language, or by code.
  • A visual editor, glossary and translation memory let you refine translations in context and keep terms consistent.

The plugin has 1,000+ active installs on WordPress.org and is rated 4.4/5 from 145 ratings. For live sites that use ConveyThis, on WordPress and elsewhere, see our customer examples.

Frequently asked questions

What is the best URL structure for a multilingual WordPress site? For most sites, subfolders (example.com/de/). They keep every language on one domain and are the simplest to maintain. Subdomains make sense when each language is run as a separate site.

How can I tell whether a multilingual site is built on WordPress? View the page source and look for paths containing wp-content or wp-includes. Some sites hide these, so their absence does not prove a site is not WordPress.

Do I need a separate WordPress install for each language? No. A multilingual plugin or a translation service can serve all languages from one WordPress install. WordPress Multisite is an option when each language is a separate site with its own content.

What makes a language switcher good? It is visible on every page, labels languages in their own language (Deutsch, not German), keeps the visitor on the equivalent page, and never forces a redirect based only on browser settings.

To set your WordPress site up the same way, try ConveyThis free with one language and 5,000 words.

Share:
G2 High Performer Spring 2023
G2 Easiest Setup Fall 2024
G2 Best Support Spring 2025