To make a WordPress site multilingual, you give each language its own URL (for most sites, a language folder such as /de/), translate the content and have a person review it, and tell Google which pages are language versions of each other with hreflang annotations. WordPress does not support multilingual sites out of the box, so a translation plugin or platform does this work. Below we go through the decisions in order, from URL structure to e-commerce details.
URL structure: separate domains, subdomains or subfolders
The first decision is where each language version lives. Google’s guide to managing multi-regional and multilingual sites compares the options as follows (as of October 2026):
| Structure | Example | Pros | Cons |
|---|---|---|---|
| Country-code domain | example.de | Clear country targeting; easy to separate | Costs more, more infrastructure; one country only |
| Subdomain | de.example.com | Easy to set up; can use different servers | Unclear whether de means a language or a country |
| Subfolder | example.com/de/ | Easy to set up; low maintenance on one host | One server location; harder to separate later |
| URL parameter | example.com?loc=de | — | Not recommended by Google |
In our view, subfolders are the most practical choice for most corporate sites and small-to-medium online stores: one WordPress installation, one set of theme and plugin updates, one domain. This site works the same way, with Turkish pages at the root and English pages under /en/. Country-code domains make more sense when each country has its own product range, pricing policy and team.
Changing the structure later is a site migration that needs a 301 redirect for every old URL; we cover that in how to avoid losing SEO when migrating a website.
How hreflang works
hreflang tells search engines which pages are language or regional versions of each other. According to Google’s documentation on localized versions of your pages, there are three ways to do it: link elements in the page <head>, HTTP headers, or the XML sitemap. Google treats them as equivalent; using more than one adds maintenance, not benefit. On this site, every page’s Turkish and English versions are annotated with hreflang in the sitemap.
<link rel="alternate" hreflang="en" href="https://example.com/services/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/" />Language codes use ISO 639-1 (en, de, tr), optionally followed by an ISO 3166-1 Alpha 2 region code, as in en-GB. URLs must be fully qualified, starting with https://; relative URLs such as /de/leistungen/ are not accepted.
Return links and x-default
The rule people miss most often is that the annotations must be reciprocal. Each language version lists itself and every other version. If page A points to page B, page B must point back to A, or Google ignores the annotations.
x-default marks the page to show when a visitor’s language matches none of your versions. Google says it was designed for language selector pages but can be used on any page. The canonical tag of each version should also point to a page in the same language: Google’s documentation on consolidating duplicate URLs recommends specifying a canonical in the same language. Pointing every language’s canonical at the English page tells Google that the other versions are not the main pages.
Common mistakes
The usual mistakes, drawn from Google’s documentation:
- Missing return links. A new language links to existing pages, which never link back.
- Country code on its own.
bemeans Belarusian, not Belgium. A region code cannot be used alone. - Invalid region codes. Codes such as
UKorEUare not valid; for the United Kingdom, useen-GB. - Relative URLs. The
hrefmust be a full URL.
One more detail: Google works out a page’s language from its visible content, not from hreflang or the HTML lang attribute. So the body itself has to be translated.
Titles, descriptions, slugs and the language switcher
Google advises against translating only template text such as menus and footers while the main content stays in one language. Translate the whole page:
- Title: Google’s title link documentation asks for titles in the same language and writing system as the main content. If they do not match, Google may choose different text as the title link.
- Meta description: The snippet shown in search results should be in the target language too.
- Slug: Google’s URL structure guidelines recommend words in your audience’s language. The German page should live at
/de/leistungen, not/de/services. The same guide recommends percent-encoding non-ASCII characters in links; we simplify characters like ğ, ş and ı in our Turkish slugs to keep things clean. - Image alt text, form messages, emails: Everything a visitor sees after switching language should be in that language.
Do not redirect visitors automatically
Redirecting visitors by browser language or IP address looks convenient, but Google advises against both: its guide warns against redirecting based on a guess about the user’s language and notes that IP location analysis is generally not reliable. There is also a technical reason: according to Google’s page on locale-adaptive pages, Googlebot’s default IP addresses appear to be in the USA and it sends requests without an Accept-Language header. If you redirect, Google may never see some of your language versions.
Instead, put a language switcher on every page that leads to the same page in the other language, not to the home page. Use language names written in their own language (“Deutsch”, “Türkçe”) rather than flags; a flag stands for a country, not a language. Avoid solutions that switch language with a cookie and keep the same URL; Google recommends a separate URL for each language version.
Machine translation and human review
Machine translation is fast and inexpensive, but publishing it unreviewed carries two risks. The first is quality: brand names, technical terms and product features can be mistranslated. The second is search: Google’s spam policies list generating many pages through automated transformations, translation included, with little value for users among the examples of scaled content abuse.
A workflow that holds up in practice:
- Prepare the whole site with machine translation.
- Define a glossary for brand names and fixed terms.
- Have a person review the pages with the most traffic and conversions: home, service and product pages, checkout.
- Leave legal content such as terms, privacy and returns policies to a professional translator.
WordPress’s multilingual documentation lists the approaches plugins take: a separate post per language, all languages in one post, machine-translating the generated page for later editing, or widgets that send visitors to an external translation service. With the last one, the translation has no URL of its own on your domain, so it misses Google’s recommendation of a separate URL per language. When comparing tools, check the folder structure, built-in hreflang, translation of titles, descriptions and slugs, human editing and WooCommerce support.
We built our own product, Dynamic Translator, for this need. It opens WordPress and WooCommerce sites to more than 110 languages without a separate site: it translates with AI through Google Cloud Translation and DeepL, opens the result to human editing, and sets up language folders (/tr/, /en/), hreflang, translated meta data and translated slugs. It comes in Free, Pro and Agency plans. We describe the product in the Dynamic Translator case study.
Currency, prices and files in e-commerce
In an online store, a language is not a market: a visitor on your English pages could be in the UK, Germany or the Gulf. Before launch, decide on:
- Currency: Is currency tied to the language or to the country? Should visitors be able to choose?
- Prices: Converted at the exchange rate or set by hand for each market? Converted prices produce odd figures like €20.37, so set a rounding rule, and make shipping and tax follow the same logic at checkout.
- Downloadable files: If you sell manuals, catalogs or digital products, a customer who buys on the English pages should receive the English file. That means storing the language of each order.
- Emails: Order confirmations and shipping notices should go out in the language the customer shopped in.
Language versions of non-HTML files such as PDFs can be annotated with hreflang too; Google notes that the HTTP header method suits these files. Dynamic Translator has two WooCommerce add-ons for these needs: Local Pricing for local prices and Localized Downloads for delivering files by language.
Frequently asked questions
Does hreflang improve rankings?
Google’s documentation presents hreflang as a way to show users the most suitable language version; it does not promise a ranking boost. Set up correctly, it helps Google show your German page to someone searching in German.
Do I have to translate every page into every language?
No. Google says that if maintaining the full set is difficult, you can leave out some languages, and it will still process pairs of pages that link to each other. Do not add an untranslated page to the hreflang set; it sends visitors to content in the wrong language.
Can I move from subdomains to subfolders?
Yes, but it is a change of URLs: 301-redirect every old URL to its new counterpart and update hreflang and the sitemap.
Conclusion
A multilingual WordPress site rests on four things: its own URL for each language, reciprocal hreflang with full URLs, content translated from titles to slugs, and a language switcher instead of redirects. Online stores add currency, price and file decisions.
If you are planning new languages, we would be glad to look at your current setup with you. Our SEO and digital visibility service covers multilingual SEO, and our web and mobile app development service covers the WordPress and WooCommerce implementation.
