Running a WordPress site in more than one language is a structural decision before it is a plugin decision. The plugin can be changed; the URL structure cannot, cheaply.
Choose the structure first
Subdirectories: example.com/fr/. One site, one installation, one certificate, and all languages share the domain's standing. This is the right default.
Subdomains, fr.example.com. More separate, needs certificate coverage for each, and each is treated as more independent.
Separate domains: example.fr. Strongest local signal in each country, and the most to maintain: separate certificates, separate DNS, and the standing of each built from nothing.
Subdirectories unless you have a specific reason. Separate domains make sense when you have genuinely separate operations in each country, with local addresses and local support, not merely translated pages.
Two plugin approaches
A translation plugin stores translations alongside the original content in one installation. Everything is in one place: one admin, one media library, one set of plugins.
Multisite with a site per language gives each language its own site in a network, which suits genuinely different content per market rather than translations of the same pages. Understanding multisite deals with what you are committing to.
For a translated version of one site, the plugin approach is simpler and easier to leave.
Machine translation is a starting point
Automatic translation is now good enough to be useful and not good enough to publish unreviewed.
It gets terminology wrong in ways that matter commercially: product names, legal wording, anything with a specific meaning in your industry, and reads as machine-produced to native speakers, which costs trust on exactly the pages where you are asking for money.
Use it for a first pass and have a person review anything that sells, explains a policy, or handles a complaint. Translate fewer pages properly rather than all of them badly.
hreflang, and getting it right
These tags tell search engines which version serves which audience, so the French page is shown to French readers rather than competing with the English one.
Three rules that cover most mistakes.
Every version lists every other, including itself. The tags must be reciprocal. A page that names another without being named back is ignored.
Use the right codes. Language alone (fr) or language and region (fr-CA). The region part is a country, not a language.
Add x-default for the version shown when nothing matches.
Any decent multilingual plugin generates these. Check the output rather than assuming, because a half-correct set is worse than none. It tells search engines something inconsistent.
Do not redirect by IP address
The mistake that causes real damage, and it is common.
Automatically sending visitors to a language version based on their location breaks two things. A search engine crawling from one country never sees the other versions, so they are not indexed. And a visitor who wants a different language cannot get to it.
Offer a suggestion instead; a dismissible banner saying a version exists in their language, and let the visitor choose. Make the language switcher visible on every page, not only the homepage.
Translate the URLs too
A French page at /fr/about-us/ has a French page with an English address.
Translated slugs read better and match what people search for. Most plugins support this, and it needs enabling deliberately.
Decide before publishing. Changing slugs later means redirects for every page in that language. Permalinks and .htaccess deals with the cost.
The parts people forget to translate
The content gets translated because it is visible. These do not.
Meta titles and descriptions, which are what appears in search results. Image alt text. Form labels and validation messages. Email templates. A French customer receiving an English order confirmation is a poor ending to a good experience. And the strings inside plugins, which need their own translation files.
Working through a checkout in each language is the fastest way to find all of them.
It costs performance
Multilingual plugins add database queries to every page load, and they are among the heaviest plugins you can install.
Caching has to be language-aware, or visitors get the wrong language served from cache, which is a worse failure than a slow page. Confirm your caching layer handles it rather than assuming. Caching layers deals with where that goes wrong.
Test speed after adding one, and budget more server capacity than the same site in one language needed.
Right-to-left languages need more than translation
Arabic and Hebrew reverse the layout, not just the text.
Themes vary in how well they handle this. Test a page with real content in place of a sentence, and check the parts that are usually hard-coded: navigation, forms and anything with an icon beside text.
Plan the maintenance
The part that decides whether this succeeds.
Every content change now needs doing in each language. Without a process, translations drift out of date and eventually contradict the original: a price or a policy that is right in one language and wrong in another is worse than not offering it.
Decide who translates updates and how quickly, before launching the second language. Two languages maintained properly beat five that are stale.
Decide which pages are actually translated
Translating everything is the assumption and it is rarely what the site needs or what anybody maintains.
curl -s https://example.com/sitemap.xml | grep -c 'loc' wp db query "SELECT post_type, COUNT(*) FROM wp_posts WHERE post_status='publish' GROUP BY post_type;" 2>/dev/null
Count what exists before committing. A site with several hundred pages becomes several hundred per language, and each one has to be kept current when the original changes.
Most sites need the pages that convert translated properly and the rest not at all. A partial translation done well is better than a complete one that drifts out of date within a year.
Check what the visitor is actually served
Language selection involves several mechanisms and they can disagree, producing a page in one language with navigation in another.
curl -s -H 'Accept-Language: de' https://example.com/ | grep -o '<html[^>]*>' | head -1 curl -sI https://example.com/de/ | head -1 curl -s https://example.com/de/ | grep -o 'hreflang="[^"]*"' | sort -u | head
The language attribute on the page must match the content, since that is what screen readers and search engines read.
The alternate links must be reciprocal. A page naming its German version while the German page does not name the English one is a common error that undoes the signal entirely.
Plan who keeps it current
A multilingual site is not a project that finishes, and the maintenance is the part that decides whether it was worth doing.
Every price change, every new page and every correction has to be applied in each language. Where nobody owns that, the secondary languages diverge and eventually contradict the original, which is worse than not offering them.
wp db query "SELECT post_modified, post_title FROM wp_posts WHERE post_status='publish' ORDER BY post_modified DESC LIMIT 10;" 2>/dev/null
Name the person and the process before adding the second language. If the answer is that translations will be updated when somebody notices, the honest choice is fewer languages maintained properly.