Guides · Websites
How to translate your website into other languages
Four routes put another language on a website, and the right one depends on what you can change: a WordPress plugin that renders every language on your server, an edge proxy that serves translated pages on a subdomain you point at it with one DNS record, a script tag for any site you can edit, and an API for a site you build. This guide shows how to translate your website by each route, what it takes to set up, and how the translation is reviewed by a person before visitors see it.
Four ways to translate your website, and when to pick each
- WordPress plugin. Pick this when the site runs WordPress. The page is translated on your server before it is sent, under
/lang/URLs with real language attributes, hreflang tags and translated titles and descriptions, so search engines index every language (the plugin page). - Edge proxy. Pick this when you cannot or would rather not touch the site. Enter the site URL and the origin host, add the CNAME shown for the subdomain at your DNS provider, and visitors on that subdomain receive translated pages cached at the edge; your origin is untouched. WordPress, WooCommerce, Shopify, Webflow, Next.js, Drupal, Magento, Squarespace and Wix are recognized automatically with fitting defaults (setting it up).
- Script tag. Pick this for any site where you can edit the HTML: one tag before the closing head renders a language switcher and translates in the visitor's browser.
- API and SDK. Pick this for a site or app you build: strings are keyed by locale, namespace and key, synced from your code, and served cache-first by the SDK (the developer API).
Whichever route you choose, the strings discovered on your site flow into the same CAT editor, where a person reviews them with memory, termbase and live checks, and a language you have not approved yet can be held back from search engines until you have.
Every route feeds the same editor: a person reviews, then the language goes live.
- routes onto your site: plugin, proxy, script tag, API
- 4
- platforms the proxy recognizes automatically, with defaults for each
- 9
- DNS record to put the proxy on a subdomain of your own domain
- 1
- languages in the catalog, with a switcher for your visitors
- 345
Choosing
Match the route to what you can change
If the site is WordPress, the plugin gives you server-rendered pages per language and the best search-engine result. If you cannot change the site or want nothing installed, the proxy serves translated pages on a subdomain with one DNS record. If you can edit the HTML of any site, the script tag is one line. If you build the site, the API and SDK make the languages part of the code. All four come with every paid plan, so you translate your website on the route that fits, not the one a tool dictates.
- WordPress: the plugin
- No access to the site: the proxy
- Any editable site: the script tag
- Your own build: API and SDK
WordPress
Every language rendered on your server, indexed by search engines
The plugin translates each page on your server before it is sent and serves it under its own language URL with hreflang and translated meta, so a search engine reads real pages, not a script. Translations you have not reviewed stay unpublished until you approve them, and the plugin is MIT-licensed.
- Server-rendered /lang/ URLs
- hreflang and translated meta
- Review before publishing
- MIT-licensed plugin
The proxy
Translated pages on your own subdomain, origin untouched
Enter the site URL and the origin host, apply the defaults the platform detection suggests, and add the CNAME at your DNS provider for the subdomain you chose; until the record resolves the subdomain keeps serving what it served before, so nothing breaks while you wait. Pages are translated once, cached at the edge and purged automatically when a translation changes; signed-in areas, admin paths and APIs are passed through untranslated.
- Site URL and origin host
- One CNAME at your DNS
- Cached at the edge, purged on change
- Admin and signed-in paths excluded
Script tag and API
One line for any site, or strings in your code
The script tag carries your publishable key and your language list, renders a switcher and translates in the visitor's browser on any site you can edit. The API and SDK key strings by locale, namespace and key, sync them from your code or a JSON file, and serve them cache-first in Node, the browser and React, with signed webhooks when translations are ready.
- One script tag
- Language switcher
- REST API and SDK
- Signed webhooks
Review
Reviewed by a person before visitors see it
Strings discovered on your site land in the CAT editor with translation memory, termbase and the 18 live checks. Machine translation on models we host fills the first draft, quality estimation scores every segment, and you or a translator you hire by offer reads what matters. A language you have not approved yet can be held back from search engines per locale until you have. Translate your website once, and the memory fills every page that repeats a line.
- Memory, termbase, 18 checks
- Quality estimation per segment
- Hire a translator by offer
- Hold back a language until approved
Keeping it current
A changed page costs the change, not the site
When a page changes, the changed strings are marked pending and translated again; the reviewed ones stay as they were, and the edge cache is purged on its own. A source word is counted once against the served-word cap however many languages you serve, sites are unlimited, and the [cost guide](/guides/website-translation-cost) puts numbers on all of it.
- Changed strings only
- Cache purged automatically
- Source words counted once
- Unlimited sites
FAQ
Translating a website, answered
Pick the route that fits what you can change: the WordPress plugin if the site runs WordPress, the edge proxy with one DNS record if you cannot touch the site, a script tag for any site you can edit, or the API for a site you build. Each one sends the discovered strings into the same editor, where a person reviews them before the language goes live.
Add the target languages to the project. Every route serves all of them: the plugin renders a URL per language, the proxy and the script tag offer a switcher, and the API serves each locale. A source word is counted once against the served-word cap however many languages you add.
Yes, two ways. The edge proxy serves translated pages on a subdomain you point at it with one DNS record, with your origin untouched; the script tag translates in the visitor's browser on any site where you can add one line of HTML.
The WordPress plugin renders every language on the server under its own URL with hreflang and translated titles and descriptions, so each language is a real indexable page. Languages you have not approved yet can be held back from search engines per locale until you are ready.
A plan from EUR 9.90 a month including VAT, machine translation inside the plan allowance and then EUR 10 per 10,000 words, and a translator for the pages you choose at the rate agreed in the offer. The cost guide works through three sites.
Yes. The script tag and the proxy render a language switcher you style in the settings, floating or as buttons, with flags and names and your brand colour, and the WordPress plugin serves each language under its own URL.
The changed strings are marked pending and translated again, the reviewed ones stay as they were, and the edge cache is purged automatically so the fresh translation goes live without you doing anything.
A visitor-side widget translates on the fly, so the wording is never reviewed, the terminology varies from visit to visit, and search engines index nothing. The routes above give you reviewed pages with memory and termbase behind them, and for the plugin, real indexable pages per language.
Translate your website into a second language this week
Website routes come with every paid plan, from EUR 9.90 a month; every signup starts free with 3,000 words of documents to try the editor.