What you will learn
- How a translation proxy differs from rebuilding a site in each language
- How language routing and addresses should work for visitors and search
- Which content a proxy handles well and which it handles badly
- How glossaries and review keep proxy translations consistent
- What happens when the original site changes a page
What this project is
A proxy sits between the visitor and the original site. When a visitor requests a page in another language, the proxy fetches the original page, replaces its text with translations from its store, and serves the translated result, usually from a language subdomain or path. The original site's code, design, and hosting stay untouched, which is why teams choose a proxy for a first multilingual launch or for a site they cannot easily rebuild. The trade is control: the proxy can translate text it can see, but it cannot easily restructure a page, change an image, or fix a layout that breaks when translated text runs longer.
Search and routing decide whether the translated site actually brings visitors. Each language version needs its own address, proper language signals for search engines, and a way for visitors to switch languages without losing their place. Content that changes often, such as prices, stock, and legal notices, needs rules about what is translated, what is pulled live from the original, and what is never translated. Without those rules, a proxy will serve a beautifully translated page with an outdated price or a legal notice in the wrong language, and the business will learn about it from a customer.
Core features
Build routing, language signals, and the translation store first, on a small set of pages. A proxy that serves the wrong language at the wrong address will do more harm than a slow translation workflow.
- Language routing with subdomains or paths, plus a visible language switcher
- A translation store with memory, glossaries, and review states per page
- Search signals per language version so each version can be found independently
- Rules for content that must stay live, must never translate, or must be reviewed per market
- Automatic detection of changed source pages, flagging their translations for review
- Exclusion controls for pages, sections, and elements that should not be translated
- Caching and performance handling so translated pages load as fast as the original
How it is built
Start with a staging copy of the site and a handful of representative pages, prove routing, translation, and search signals, then roll out page by page rather than translating the whole site at once.
- Connect the proxy to a staging copy and define language routing and addresses
- Build the translation store with memory, glossaries, and review states
- Add changed-page detection and per-page publish control
- Add search signals, sitemaps, and language switcher behaviour
- Add performance, caching, and rollout reporting, then expand page by page
Tech considerations
A proxy has to keep up with a live site that changes without warning, and it has to do so without slowing the site or breaking its interactive parts. Forms, checkout flows, and dynamic content are the usual trouble spots, because translated text alone does not make a form work in another language.
- Original pages that change without notice, leaving translations stale
- Interactive parts such as forms, search, and checkout that need more than translated labels
- Layout breakage when translated text runs longer or reads right to left
- Search duplication or missing language signals that hide translated pages
- Performance loss if every translated page is built from scratch on each visit
- Third-party widgets and embedded content that the proxy cannot translate
Challenges and honest limits
The failure to prevent is a translated site that looks complete but is quietly out of date: new products, changed prices, and updated legal text still showing old translations. Changed-page detection and a visible staleness report are not optional extras; they are the controls that keep a proxy honest after launch day.
- Translated pages left live after the original page changed
- Checkout or form steps translated as labels but not tested end to end
- Legal or pricing text translated when it should have been market-specific
- Language versions with no search signals, so visitors never find them
A translation proxy does not rebuild a site, fix its layout, or make its checkout work in another language. It translates the text it can reach, under rules the team sets, and interactive or market-specific parts still need direct work on the original site or a dedicated integration. Confirm scope with a quote for your site platform and page set.
Who it is for
This project fits businesses that need a multilingual site quickly, teams that cannot rebuild their current site, and agencies offering translation as a managed service on top of existing sites.
It is not a good fit for a site being rebuilt anyway, or for a store whose checkout and catalogue need market-specific handling. In those cases, a native multilingual build or a catalogue localization tool will serve better than a proxy layer.
Frequently asked questions
How does a translation proxy work?
The proxy fetches the original page, replaces its text with stored translations, and serves the result at a language address, while the original site keeps running unchanged.
Will search engines find the translated pages?
They will if each language version has its own address and proper language signals. Without those signals, translated pages may be hidden, duplicated, or attributed to the wrong language.
What happens when I update my site?
The proxy should detect changed pages and flag their translations for review, so updated content does not keep serving an old translation. That detection step is essential after launch.
Can a proxy translate my checkout?
It can translate labels, but a checkout that works in another language also needs correct currency, payment options, shipping rules, and legal text per market, which often need direct work beyond translation.
Is a proxy a permanent solution?
It can be, for content sites that change slowly. For sites being rebuilt, or stores with complex market logic, it is often a bridge to a native multilingual build.