Guides · Search
SEO localization: making translated pages findable in each market
SEO localization is the work of turning a translated page into a search result in its own market: the wording people there actually type, a page purpose that matches it, and a publication that search engines can read, with one URL per language, hreflang, a translated title and an approved text. This guide separates what the platform does on its own, what you configure, and what stays editorial judgement.
What SEO localization is, and what it is not
SEO localization is not local-business SEO: a map listing and reviews for a shop in one town are a different job. It is also more than translation. A page that ranks in English for one phrase was written around that phrase; its German reader may search for something else entirely. Three steps, in order:
- Research the wording per market. An English keyword translated literally is often not what people type. An illustrative example: an English page targets "translate a PDF without losing formatting"; the natural Finnish search is closer to "PDF kääntäminen" with "asettelu säilyy" as a secondary phrase, two words apart from the literal translation. That research is yours, or a translator's you hire by offer who knows the market; the platform does not do it for you.
- Adapt the page, not just the sentences. Headings, the example, the call to action and the expectation set in the first paragraph are rewritten around the researched wording. In the editor the translator sees the whole page in context and the termbase keeps the product names consistent.
- Publish in a way a search engine can read. One URL per language, hreflang with an x-default, a canonical per language, a translated title and description, rendered on the server, and only text a person approved. That is the part the platform does, described route by route below.
A translated page is a search result only when the server renders it, a person approved it, and the wording is what that market searches for.
- URL per language, with hreflang and an x-default, from the plugin and the proxy
- 1
- person marks a language ready before any of it is served to visitors or crawlers
- 1
- website routes, two of which render every language on the server
- 4
- languages, so the market decides the language list, not the tool
- 345
The route
When search visibility matters, use the plugin or the proxy
Two routes render every language on the server, which is what a crawler needs. The [WordPress plugin](/integrations/wordpress) serves each language under its own path for every post type, sets the html lang attribute, a canonical per language and hreflang with an x-default, translates the title, the description and the Open Graph tags, and defers to Yoast, Rank Math or AIOSEO where one is installed, which is where multilingual SEO on WordPress starts. The edge proxy does the same for any site on a subdomain you own: language paths, hreflang, canonical and og:url rewritten to the public host, translated title, meta and JSON-LD, served from the CDN edge. Setup for each is in [how to translate your website](/guides/translate-your-website).
- Language paths per post type
- hreflang + x-default
- Canonical per language
- Translated title, meta, OG, JSON-LD
Who does what
What the platform automates, what you configure, what needs judgement
Automated: language URLs, hreflang and canonical, translated title and meta, server rendering, approved-only serving, cache purge on publish, the language switcher. Configured by you: the language list, which locales are held back from search until reviewed, the paths excluded from translation, the switcher style. Editorial: the keyword research per market, the rewritten headings and calls to action, the decision which pages get a translator and which ship after your own read. The table is short on purpose: the first row is where tools differ, the third is where results differ.
- Automated: URLs, tags, rendering, serving
- Configured: languages, hold-backs, exclusions
- Editorial: research, headings, review
Sitemaps
Sitemaps that list the languages
Multilingual SEO needs sitemaps that list the language URLs. With the WordPress plugin and Yoast, the sitemap gains alternate entries for every language. Behind the proxy, each language gets its own sitemap at the language path, rewritten from your origin sitemap, plus a sitemap index, and the same for llms.txt. Submit the index once in Search Console; the proxy keeps the files current as pages change.
- Yoast alternates (plugin)
- /{lang}/sitemap.xml (proxy)
- Sitemap index
- /{lang}/llms.txt
Review before publication
A language is a search result only after a person said so
Nothing is served to a visitor or a crawler until a person marks it ready, per row or per language. A locale that is still in review can be held back from search engines: the proxy serves it with a noindex header and leaves it out of hreflang and the sitemaps, and the plugin applies the same setting from the server. A machine draft that a crawler indexed before anyone read it is the one multilingual SEO mistake that is hard to undo, and this is the mechanism that prevents it.
- Ready rows only
- Hold a locale back from search
- noindex until reviewed
- Out of hreflang and sitemaps meanwhile
Keeping it current
Changed text is re-translated; approved text stays
A page that ranks will be edited. When it is, only the changed sentences are translated again, a person marks them ready, the cache is purged, and the approved translations around them stay as they were, so a ranking page does not lose its text to a routine edit. The [continuous localization guide](/guides/continuous-localization) follows one page through a change.
- Changed sentences only
- Approved text kept
- Cache purged on publish
- Outdated rows flagged
Measure
Read the results per language, not per site
In Search Console, filter by page and by country: the language path makes each translated page its own row, so impressions, position and clicks are readable per market. Add one analytics event per translated page, such as a form or a trial start, so a page that ranks and converts is distinguishable from one that only ranks. Give a new language 28 days before reading anything, and 56 before changing it.
- One row per language path
- Filter by country
- One conversion event per page
- 28 days before reading
FAQ
SEO localization, answered
SEO localization is adapting a page so that it is found in another market: the wording people there search for, a page written around it, and a technical publication a search engine can read, with its own URL per language, hreflang, a translated title and a canonical. Translation alone is the middle third of it.
One URL per language, rendered on the server. Hreflang on every language page with an x-default. A canonical per language, never pointing all languages at the source. A translated title and description. Only reviewed text served to crawlers, with unreviewed locales held back. Sitemaps that list the language URLs. Keyword research per market before the translator starts. And patience: 28 days before reading the numbers.
Not for the publication part: the plugin and the proxy set the URLs, hreflang, canonical, title and meta on their own. The keyword research in each market and the rewritten headings are editorial work; do it yourself with Search Console and a keyword tool, or hire a translator who knows the market by offer and brief them with the phrases. Lionrapid supplies the software and the translators, not a consultancy.
No. A translated page is eligible to rank; whether it does depends on the wording, the competition in that market, the rest of the site and time. What the platform guarantees is the technical half: the page is served in a form a search engine can index, with the signals that tell it which language is which.
Both set hreflang for every language plus an x-default pointing at the source, and a canonical that points each language page at itself. The plugin also sets the html lang attribute and hands the canonical to Yoast, Rank Math or AIOSEO when one of them is installed; the proxy rewrites canonical and og:url to the public host and language path.
Yes. Hold the locale back: the proxy serves it with a noindex header and leaves it out of hreflang and the sitemaps, and the plugin applies the same setting from the server. Release it when a person has read the pages, and the signals appear on the next crawl.
Open a translated page and view its source: the html lang attribute, the hreflang set with x-default, the canonical pointing at itself, the translated title and description. Fetch the sitemap for the language path. Confirm every row on the page is marked ready and the locale is no longer held back. Then request indexing for the three pages that matter most.
The WordPress translation plugin renders each language on your server under its own path, sets lang, canonical and hreflang, translates title, meta and Open Graph, adds alternates to Yoast sitemaps, and purges the common cache plugins when a translation is published. Its page lists the settings and a pre-publication checklist.
Serve the first language the way a crawler can read it
Website routes are on every paid plan, from EUR 9.90 a month; every signup starts free with 3,000 words of documents.