You want to translate a website and are looking for options, but you always come to the same conclusion: a proxy or a translation API.
The problem is that none of them work well by default. Forms are not translated. Dynamic content remains in the original language. SEO does not improve because Google still only sees one version of the site. And when you try to solve this, new problems arise.
This article explains how each approach works, where each breaks down, and what to consider before choosing.
How a Translation API Works
A translation API accepts text and returns it in another language. DeepL, Google Cloud Translation, Amazon Translate. You send a request — you get a translation.
To use this on a website, someone needs to embed the API into the code:
- A developer for initial integration
- Custom logic for caching and updating translations
- Payment for each call (by characters or tokens)
- Support with every website change
What doesn't happen automatically: The API doesn't know what text is on your website, when it changes, or how to display it. You need to build this yourself. The API is just a translation engine; everything else is integration work.
For projects with their own technical teams and very specific requirements, this might make sense. For an agency that needs to launch a multilingual site in a few days, this is too much overhead.
How a Translation Proxy Works
A translation proxy sits between your website's server and the user's browser. When someone visits mycompany.com/ru/, the request goes through the proxy, which translates the content on the server and returns the already translated page.
No need to touch the website code. Setup is a matter of DNS, not development.
In practice:
- Static and dynamic content is translated before it reaches the browser
- Each language's URLs are real: /ru/, /fr/, /de/
- When the source content is updated, translations are updated automatically
- SEO works from day one
Real limitations: not all translation proxies translate dynamic content. JavaScript-based ones insert translations in the browser — this means SEO suffers, and forms remain untranslated. Only server-side translation proxies avoid these problems.
Real Problems When Translating a Website
Before choosing between a proxy and an API, it's worth understanding where each approach breaks down in specific situations.
Forms
Forms are one of the most problematic points. Field text, error messages, and confirmations are usually generated dynamically. With a client-side API, this text appears with a delay or not at all. The same applies to JavaScript proxies. Only a server-side proxy consistently translates forms.
Dynamic Content (JavaScript)
Product catalogs, real-time prices, JavaScript-generated text — all of this appears in the browser after the page loads. Client-side API and JavaScript proxies cannot translate what is not yet in the HTML. Result: partially translated pages.
SEO
According to official Google Search Central documentation, content rendered via JavaScript may be indexed with significant delay or not consistently indexed. If translations depend on JavaScript, Google may not see them — or see them weeks later.
With a server-side proxy, Google receives an already translated page. Each language version has a real URL, hreflang, and a place in the index.
E-commerce
In an online store, the catalog, prices, purchase buttons, and confirmation pages must be translated. A purchase process that is half in another language will not convert. And a catalog that Google does not index will not attract organic traffic.
Direct Comparison
So, what to choose?
Direct API makes sense when there is a technical team, time for integration, and specific requirements: complex web applications, translation of user-generated content, document translation pipelines.
JavaScript proxy is easy to install, but it has the same SEO and dynamic content issues as a client-side API. It only works well for very simple static sites.
Server-side proxy is the natural choice for existing sites that need to add languages without changing code, with working SEO from day one and dynamic content support.
The problem is that most proxies on the market work in the browser, not on the server.
Is there an alternative?
Some solutions combine the best of both approaches: they work as a server-side proxy — without changing the site's code — but use advanced translation models that consider context, not just text.
What this means in practice:
- Pages are not duplicated in the CMS
- Dynamic content is translated just like static content
- SEO works from the start: real URLs, automatic hreflang, sitemap for each language
Multify works exactly like this. It connects at the DNS level, translates everything on the server, and automatically generates an SEO structure for each language version.
Frequently Asked Questions
Is a translation proxy slower than a direct API?
Not necessarily. A well-implemented proxy caches translations and delivers already processed content. The added delay is minimal and usually unnoticeable to the end-user.
Can a proxy be used with any web platform?
Most translation proxies work with any website that can be routed through DNS: Tilda, WordPress, Webflow, or custom development. The specific integration depends on the service used.
Are proxy translations automatically updated when content changes?
Yes. When content on the source site changes, the proxy detects the change and applies the updated translation. No manual intervention, file export, or import is needed.
What happens to content that doesn't need to be translated?
Translation proxies usually allow you to set exclusion rules: specific URLs, CSS selectors for elements, or text patterns that should remain in the original language. Multify offers this option.
