WPML hosting that keeps every language separate.
A multilingual site is several sites sharing one database. The mistakes are all variations of one thing: something meant for one language reaching a visitor reading another.
One site, several languages, no bleed.
Everything here is about keeping languages apart while they share a database.
Cache that knows the language
Cached pages are keyed by language, so a visitor reading German is never served the French copy because it happened to be cached first. Language is resolved before the cache lookup, not after.
A database sized for the multiple
Six languages means roughly six times the posts, the meta and the term relationships. Storage and query tuning start from that number rather than from the page count you would guess from the menu.
Alternate-language tags on the cached copy
Those tags have to be present on what most visitors actually receive, not injected by something that only runs on a cache miss. They are part of the cached response.
Translate on a copy
Clone the site to work through a new language without half-finished translations appearing live, then push it back when the language is complete.
Restore a language, not the site
Translation work is expensive to redo. Daily backups cover the full database, so a bad string import is recoverable.
The bugs are all the same bug.
Almost every multilingual problem is content from one language reaching a reader of another - in the cache, in a menu, in a search result, or in the tags search engines read.
- Cache entries separated per language
- Alternate tags present on cached responses
- Language switcher not cached across languages
- Search scoped to the active language
Six languages, one page load.
Multilingual sites are not slower because they are translated. They are slower when the database was sized for one language and the cache cannot tell them apart.
What we change for WPML
Multiply the content by the number of languages, then make sure the cache never confuses two of them. That is the whole job.
| Setting | What we do | Why |
|---|---|---|
| Cache key | Includes the active language | Without it the first language cached wins, and every other reader is served the wrong translation. |
| Language resolution | Happens before the cache lookup | Detecting language after a cache hit is too late, because the wrong copy has already been chosen. |
| Database sizing | Planned from posts multiplied by languages | A six-language site holds roughly six times the rows, and sizing from the visible page count under-provisions it. |
| Alternate-language tags | Rendered into the cached response | Tags injected only on a cache miss are absent for the majority of visitors and crawlers. |
| String tables | Kept in the object cache | Interface string lookups happen many times per render and are identical for every visitor in that language. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Does caching break language switching?
How much bigger is a multilingual database?
Do you support Polylang and TranslatePress too?
Will alternate-language tags be correct?
Serve every language properly.
Bring the multilingual site across - migration is free, every language included.