Should we translate our whole website?

Not as a first move, and the reason is a budgeting one as much as a linguistic one. A full-site translation attempted in one pass spreads a fixed amount of review time evenly across every page, including the ones a buyer will never reach before deciding — so the pages that decide the sale end up getting the same attention as the archive, which is exactly backwards. Start with the decision path, and let the rest follow once something specific asks for it: a live deal, or interest arriving unprompted in that language.

Which pages should be translated first?

Pricing, the product or solution pages that explain what the offering does and for whom, and proof such as case studies and comparisons. The harder follow-up is when a translated page stops counting as translated. A workable threshold: it is current if every claim, price, and product name on it still matches the source page it came from; if any of those has moved, the translation is stale no matter how recently anyone reviewed it. That test also settles ownership, since whoever owns the source page is the only person who knows the moment it changed.

Is machine translation good enough for marketing pages?

As a first draft, yes — it is a fast way to see roughly what a page would say in another language. Publishing that raw output on a pricing or product page without a native editor's pass is a different decision and a riskier one: a buyer is reading that page while working out whether to trust the company with money, and a mechanically obvious sentence in that position works against the one thing the page exists to do. Save raw output for internal use and lower-stakes pages.

How do we know a market is worth translating more of the site for?

Watch for pull rather than assuming it — but pull has a failure mode worth naming, because one loud deal can generate every signal a real pattern generates, and generate all of them from a single account. A request tied to one opportunity justifies translating the specific asset that opportunity needs, and nothing past it. What justifies more of the library is repetition from sources that do not know about each other: different accounts, different channels, different weeks. Whoever owns revenue in that market is the right person to make the call, since they are the one who can tell a pattern from a single persistent customer.

Website translation: how much is enough

Guide · SEO / AEO / GEO · 6 min read · last verified 2026-08-11

Reviewed before publication Editorial board Independent commercial review

In shortHow much of a site to translate for a market you have already chosen is a scope decision, not a percentage: pricing, product, and proof pages go first because they are by definition the ones a buyer crosses between a question and a…

Translate the pages a buyer reads between a question and a decision — pricing, product, and proof — before translating anything else, and leave the blog and long-tail library in the source language until there is a measurable reason to move it. The question here is depth inside one market, not which markets to be in at all: choosing where to expand is a separate decision, made earlier and on other evidence, and everything below assumes it has already been made. Inside a market already chosen, a fully translated site nobody maintains creates a problem a smaller maintained one does not, because a careless page in a buyer's own language is not a neutral gap. It sits exactly where a decision gets made. "How much is enough" is a scope question before it is a budget question: how much of the path between a buyer's question and their decision currently exists in the language of a market the company has committed to.

The pages that earn translation first

Three kinds of pages sit close enough to a buying decision that a buyer in another language is likely to read them before talking to anyone: pricing, the product or solution pages that explain what the thing does and for whom, and proof — case studies, comparisons, whatever a buyer uses to check a claim against reality. There is nothing to prove about why those three go first. They were just defined as the pages standing between a question and a decision, so sitting close to the decision is what makes them that set — not a separate finding about how sales work. The same definition carries the warning attached to it: a page read while someone is deciding is also a page whose rough edges are read while someone is deciding. Translating it badly and repairing it later means the repair arrives after the reading that counted. A buyer who cannot find your price in their own language has an easy alternative sitting one tab away: a competitor whose page they can read without doing the translating themselves.

What can wait for pull

The blog, the long-form guides, the archive — none of it needs to exist in a second language before launch, and treating it as though it does is how a translation budget gets spent on the wrong pages first. A trigger worth acting on is pull you can already point to: inbound inquiries arriving in that language, a sales team asking for a specific asset because a live deal needs it, a support queue showing tickets from a market not yet formally entered. Ranking which markets deserve that kind of attention at all is a different decision — where to expand internationally first works through the pull signals that make it — and this piece assumes the market is already chosen, asking the narrower question of how much of the existing library needs to follow it. Translating the archive because it exists, rather than because someone asked for it in that language, is effort spent on a guess.

Raw machine translation on a commercial page is a visible risk

Machine translation has a legitimate role: it is a fast way to see roughly what a page would say, and a reasonable starting point for a native editor to correct. Publishing its raw output on a pricing or product page — the ones read while a buyer decides whether to trust a company with money — is a different act. A sentence that has obviously come straight out of a machine, sitting next to a real price, does not read as "in progress." It reads as unattended, on a page whose entire job was to be trusted. That cost is easy to leave out of the calculation when the fast option is sitting right there: the fluency of a commercial page is itself a signal, and an obviously mechanical one works against the same trust the page exists to build. Whether the AI systems assembling an answer in that language currently weigh page fluency the way a human reader does is not something to assume either way — it is worth checking against the pages you have already published rather than guessing, and whatever the answer is today, it can move as the underlying systems change. The human reaction does not wait on that question being settled.

Enough is a threshold, not a percentage

Neither easy answer holds up. Translating everything spends real budget on pages that sit far from any decision, before the pages closest to one are even solid. Translating nothing leaves the decision pages themselves in a language part of the buying committee may not read comfortably. The threshold that holds instead: enough means every page a buyer in that market crosses between asking a question and making a decision, kept current, in a market the company is committed to — not a percentage of the sitemap, and not a one-time project with a finish line. A market you have merely noticed does not clear that bar. A market with a rep quoting live deals in it does.

Deciding what moves next

Once the core pages exist in a language, the next candidate is whatever pull identifies, not whatever comes next alphabetically in the content library. The signals are the same ones that justified the first pages; what changes is the size of the unit they justify. The first decision covered a set of pages. Every decision after it covers one page, with its own reason attached — a smaller decision, and therefore one that is easier to make without noticing you made it. Treat each addition as its own justification rather than letting scope drift back toward "the whole site" a page at a time without anyone deciding that on purpose. How to manage localization workflows takes over from there — the glossary, the translation memory, the reviewer who owns the market rather than grading the vendor's own work — once something has been decided worth translating. The decision itself is this piece's subject, not that pipeline.

Checking whether it worked

Translating the core pages is an intervention, and like any intervention it is worth checking rather than assuming it landed, not inferring a result from the fact that the pages now exist. Whether a market's AI answers shifted after the core pages went live is a re-scan question — the same fixed buyer questions, asked again once enough time has passed, against a before-reading kept on record rather than remembered after the fact. A locked, per-market benchmark like the one Magrios keeps is built for exactly that comparison, though the underlying discipline works by hand too: a saved reading and a calendar date to check it again. Presence can lag either way, and it can fail to move at all if the machine-legibility signals and the local third-party sourcing behind it were never put in place. That execution and measurement layer, including how engines currently seem to treat parallel-language content, has its own guide: how to localize content for AI visibility. One level above both of them sits how to appear in AI answers in non-English markets, which is about which languages to hold ground in at all rather than how deep to go inside one. Each picks up from a different point than this piece ends at, and asks the question this one does not: whether the page, once published, is being found.