Three plugins do this well: WPML, Polylang, and TranslatePress. Pick based on how many languages you need and whether you want to translate content manually or lean on machine translation. Whichever you choose, expect a small but real performance cost, and don't skip hreflang tags or search engines will serve the wrong language to the wrong visitors.
Picking a plugin
The three leaders solve the same problem differently.
- WPML is the most complete option. It handles posts, pages, custom post types, WooCommerce products, and even translates strings inside themes and plugins. It's paid only (no free tier), and it's the heaviest of the three: more database tables, more admin overhead, more to keep updated. Worth it for content-heavy multilingual sites with many post types.
- Polylang has a solid free tier that covers posts, pages, and categories. The paid version (Polylang Pro) adds custom post type support and better WooCommerce integration. It's lighter than WPML and a common pick for straightforward multilingual blogs and business sites.
- TranslatePress works differently: it translates the rendered page visually, in a live preview, rather than requiring you to duplicate content in the block editor. It also has native machine translation via Google Translate or DeepL, so you can machine-translate a whole site and then hand-edit the results. Good fit if you want a fast first pass and don't have a translator on staff.
If you're translating manually and want full editorial control over every string, WPML or Polylang. If you want a working multilingual site today and will refine translations over time, TranslatePress with machine translation gets you there faster.
The performance cost
Multilingual plugins add real overhead, and it's worth knowing where it comes from before you install one:
- Extra database queries. Every page load now needs to resolve which language the visitor is in, then fetch the matching translated content. WPML in particular adds join queries across its translation tables.
- More rows to cache. Each language is effectively a duplicate copy of your content. If you're running the LiteSpeed Cache plugin that comes with a Flashcloud WordPress install, make sure it's caching per-language variants correctly, not serving the wrong language from cache to a visitor who switched. Check the plugin's cache exclusion and vary-by-cookie settings after you add a multilingual plugin.
- Admin-side slowdown. WPML's admin screens get noticeably slower on sites with a few thousand posts across several languages, since every list view is now filtering and joining across translation tables.
- Machine translation calls. If you use TranslatePress with live machine translation instead of pre-translating and saving, translation happens at request time unless the result is cached. Always let it cache translated strings rather than calling the API on every page view.
None of this is a reason to avoid going multilingual. It's a reason to test page load times after setup and confirm your caching layer still works the way you expect.
Object caching helps here
If your Flashcloud WordPress install has Redis object cache active, the extra database queries from a multilingual plugin get cached in memory instead of hitting MySQL on every request. This is one of the bigger wins for multilingual sites specifically, since the query overhead is higher than on a single-language site.
hreflang basics
hreflang tags tell search engines which language and region a page is for, and which other pages are its translations. Without them, Google may show the wrong language version in search results, or treat your translated pages as duplicate content.
The tag looks like this in your page's :
A few rules that trip people up:
- Every language version needs to reference every other language version, including itself. If you have English, Spanish, and French versions of a page, all three pages carry three hreflang tags pointing to all three URLs.
- Use
x-defaultfor the fallback page shown to visitors whose language doesn't match any of your translations. - Language codes follow ISO 639-1 (
en,es,fr). Add a region with a hyphen if needed, likeen-gbvsen-us. - The URLs in hreflang tags must be absolute, not relative, and must match exactly (including trailing slash) what's actually served.
All three plugins generate these tags automatically once you've set up your languages, so you don't normally hand-write them. Still worth checking the page source after setup to confirm the tags are there and pointing to live URLs, not 404s.
URL structure
You'll also choose how language shows up in the URL: subdirectories (yourdomain.com/es/), subdomains (es.yourdomain.com), or separate domains entirely. Subdirectories are the simplest to set up and the most common choice, since they don't require any additional DNS or SSL configuration. If you go the subdomain route, remember each subdomain still needs SSL, though a Flashcloud install and its auto-issued Let's Encrypt certificate cover this without extra work as long as DNS points correctly first.
When to contact support
Multilingual setup itself is a plugin-configuration task, not something our support team configures for you. But if you're seeing cache-related bugs after adding a multilingual plugin (wrong language served from cache, stale translated content) or you're not sure whether Redis object cache is active on your account, open a ticket from Support → New ticket in the portal. Real humans review it, and they can confirm your caching configuration or help track down where a language is being served incorrectly.