Your existing URLs are not touched. Translated versions are added alongside them, so nothing you have already published moves or breaks.
Nothing changes on your original pages
example.com/pricing/ keeps working exactly as before, at the same URL, in the same language. Universally adds example.com/es/pricing/ next to it.
That means:
- No existing link, internal or external, breaks
- No existing search ranking is disturbed, because the page did not move
- Your source language stays at the root, with no prefix
What links a visitor follows
On a translated page, internal links are rewritten to keep the visitor in their language. From /es/pricing/, a link to /features/ becomes /es/features/, so browsing does not silently drop back to the source language.
Some paths should not be rewritten, such as asset URLs, API endpoints and feeds. Those are listed under Exclude Link Localization. See Exclude link localization.
How visitors reach a translated page
Through the language switcher, or by a link to the translated URL, or from search results, since translated pages are indexed in their own right.
There is no automatic redirect based on browser language. Nothing reads the browser's language preference, so a first-time visitor arriving at your root URL gets your source language whatever their browser asks for. If you want language-based redirection, it has to be implemented at your own edge or server layer.
This is deliberate rather than a gap: automatic language redirection is a common source of trouble, because it overrides an explicit choice and search crawlers see something different from users.
The language a visitor chose is remembered
A visitor's own choice is a different matter, and this is the behaviour to know about before you configure a cache.
Viewing any translated URL stores that language in a universally_lang cookie for 30 days. While it is set, a request to a URL with no language prefix is redirected to the same page in the stored language. So a returning visitor at your root URL does not get the source language, they get theirs.
The way back is the switcher's source-language link, which carries ?universally_switch=source. That clears the cookie and returns the visitor to the unprefixed URL. A plain link to the source URL does not clear it, so the redirect happens again.
The redirect is skipped for WordPress system paths (/wp-admin/, /wp-json/, wp-login.php and the rest), for anything that looks like a file (sitemap.xml, robots.txt, favicon.ico), and for paths under Exclude Pages.
Because the response at an unprefixed URL now depends on the visitor, this is the one Universally behaviour a full-page cache genuinely breaks. See Caching and CDNs.
Redirects Universally does perform
Five, and it is worth knowing them when you are debugging an unexpected 301 or 302:
| Redirect | Status |
|---|---|
| An excluded path requested at its translated URL, sent to the original page, query string preserved | 301 |
/es without the trailing slash, sent to /es/ |
301 |
| An unprefixed URL for a visitor with a stored language, sent to that language | 302 |
?universally_switch=source, sent to the clean URL after clearing the stored language |
302 |
| Any WordPress redirect on a translated page keeps the language prefix on its destination | unchanged |
See Exclude pages for the first one.
If you change a URL on your site
On WordPress this is mostly handled for you. The language prefix is removed before WordPress routes the request, so an existing redirect from /old-page/ to /new-page/ fires for /es/old-page/ too, and the prefix is put back on the destination: the visitor lands on /es/new-page/, still in Spanish. That covers redirect plugins and anything else that redirects through WordPress.
Two cases still need their own rule for the prefixed path:
- Redirects in your web server or CDN configuration, which see
/es/old-page/as it arrives - Redirects written in PHP with a raw
header()call rather than through WordPress