--- title: Why a Multilingual WordPress Site Is a GEO Decision, Not a Translation Decision canonical_url: https://lolacore.com/multilingual-wordpress-geo/ last_updated: 2026-07-26T11:47:44+00:00 plugin_version: 1.2.3 --- # Why a Multilingual WordPress Site Is a GEO Decision, Not a Translation Decision The question's language decides who is eligible to be quoted ------------------------------------------------------------ A generative model answering a question in Italian does not translate the whole web and then pick the best source. It retrieves passages, and retrieval is filtered by language before quality is ever considered. Your English page can be the most accurate, best structured, most authoritative thing ever written on the subject. If the reader asked in Italian and no Italian version of that page exists, your page was never in the pool the model was choosing from. This is the part that gets missed when multilingual work is filed under "translation." It is not a ranking problem you can win with better content. It is an eligibility problem. You either have a page in the language of the question or you do not, and no amount of quality on the English side substitutes for that absence. That reframes the whole decision. Translating your site is not about serving readers who cannot read English. Plenty of them read English perfectly well. It is about existing inside the retrieval set of the model that answers them when they choose to ask in their own language, which is what people do by default when the answer is going to be about their own business. What the evidence actually supports, and what it does not --------------------------------------------------------- You will find a lot of numbers circulating on this topic. Most of them come from companies that sell translation, and several are constructed in ways that do not survive a close reading. We are not going to repeat them, because a claim you cannot verify is worth less than the mechanism you can reason about directly. The mechanism holds without the numbers. Retrieval is language-sensitive. Google's own documentation on international sites has said for years that language-specific URLs and correct `hreflang` annotation are how a search engine decides which version of a page belongs to which audience. Generative engines are built on top of the same retrieval and the same signals. Nothing about that requires a whitepaper to believe. What there is no good evidence for is the idea that switching on machine translation across an entire site produces a GEO benefit. The models are not counting your language versions. They are quoting passages that read as if a competent person wrote them for that audience. Literal translation of commercial copy is the fastest way to produce text that is technically in Spanish and semantically in nothing. The entity problem underneath the language problem -------------------------------------------------- There is a second effect that matters more for a product than for a blog. Across languages, a model is assembling a picture of what your product is. Same name, same price, same capabilities, same claims. When the Spanish page says one thing about pricing and the English page says another, when the product name gets softened in Portuguese because it sounded better that way, when the schema on one version omits what the others declare, you have not created four descriptions of one product. You have created four half-descriptions of something the model is now less sure about. Consistency across language versions is what lets a model treat all of them as the same entity and pool the authority. Inconsistency splits it. This is why the translation of a product site is a positioning exercise before it is a linguistic one: every term you own has to survive the crossing intact, and every term you do not own has to be rendered in the vocabulary the local reader actually uses. What has to be true technically ------------------------------- The technical requirements are unglamorous and non-negotiable. Each language lives at its own URL. Subdirectories are the usual answer for a WordPress site: `/es/`, `/pt-br/`, `/it/`. One language per page, never mixed. `hreflang` annotations connect the versions to each other and declare which one belongs to which audience, with a self-referencing tag on each. Canonical tags point to the page itself in its own language, not back to the English original, which is the single most common way a multilingual WordPress install quietly removes itself from the index. Schema.org markup declares `inLanguage` on each version and keeps the same entity identity across all of them. The sitemap includes every language version. Any competent WordPress translation plugin does most of this for you. [LolaCore for Polylang](https://lolacore.com/lolacore-for-polylang/) is the bridge we use on this site when Lola needs to keep linked versions and hreflang in step. The point is not which plugin you pick. The point is that if these signals are wrong, the content underneath them does not get read as what you intended, and you have paid the translation cost without collecting the benefit. What to translate, and in what order ------------------------------------ Not everything, and not the homepage first. Models quote passages that answer questions. That means documentation, how-to guides, comparison pages, use case pages, the things people phrase as questions when they type them into a chat window. A translated homepage is a brochure in another language. A translated documentation section is a set of retrievable answers in another language, which is what actually shows up in a generated response. For a WooCommerce store, the equivalent priority is product pages, category pages and the FAQs attached to them, because the questions people ask an AI model about a store are questions a product page answers. The homepage matters for the human who arrives after the model has already sent them. It is not what got them sent. The cost nobody prices in ------------------------- Here is the part that decides whether a multilingual site survives its first year. You publish a page in English. Then you publish it in three more languages. Then you change a price. Then you rename a feature. Then you rewrite the section that was not converting. Every one of those edits is now four edits, in four places, in four languages you may not all speak, with four sets of `hreflang` annotations that break silently if one version falls out of sync. Nobody abandons a multilingual site because translation is hard. They abandon it because maintenance is relentless and invisible. The English version stays current because it is the one you look at every day. The other three drift, quietly, until the Italian page is describing a product that no longer exists and the model is now confidently quoting an outdated claim about you in Italian to an Italian reader. That drift is a symptom of admin fatigue: the gap between the simple sentence in your head, "update the price on this page," and the number of screens and languages that sentence actually touches. [Here is what we mean by that.](https://lolacore.com/admin-fatigue/) The practical consequence is a rule that sounds conservative and is not: pick fewer languages than you think you can handle, and keep them synchronised. Four languages maintained beat eight languages published. A stale page in a language you cannot read is worse than no page, because it is still eligible to be quoted. Written from a site that does this ---------------------------------- None of the above is a projection. This site exists in English and Spanish, and the Spanish version of the page you are reading now is one click away in the language switcher. It was not machine-translated in bulk. Every page was transcreated through Polylang and [LolaCore for Polylang](https://lolacore.com/lolacore-for-polylang/), which means the terminology we own was carried across deliberately, and the terminology we do not own was rendered the way a Spanish reader actually says it. The synchronisation problem described in the previous section is the one we spend real time on. It is also why the next two languages are being planned rather than published.