Translate your entire website in a few clicks
Going multilingual used to mean plugins, exported strings and a translation-agency invoice. Here is how to put your whole site in another language at the edge — and the three things that will bite you if you skip them.
A customer emailed us last spring with a problem we hear constantly. They sold industrial fittings, mostly to Denmark and Germany, and about a fifth of their traffic was quietly arriving from France and the Netherlands. Not enough to justify hiring translators. Far too much to keep ignoring. The site had roughly 4,000 product pages. Every quote they got back for translating it started with a comma in an uncomfortable place.
This is the situation edge translation was built for — and, to be fair about it, the situation where it is genuinely the right tool rather than a shortcut. Let us go through how it works, then the parts nobody mentions until you have already turned it on.
The old way, and why it hurts
Traditional localization happens at the application layer. Your CMS learns about every language, stores a copy of every page, and renders the right one per request. WPML and Polylang do this well, and if every word on your site is marketing copy that has to be signed off, that is the right answer and you should stop reading here.
The cost shows up in three places. Your database roughly doubles per language. Your admin gets slower, sometimes dramatically. And you acquire a permanent job: nothing can go live until it has been translated, so your English site and your French site drift apart the moment anyone gets busy.
Edge translation makes the opposite trade. You get automatic coverage of everything you have, including pages you have not written yet, in exchange for machine phrasing instead of a human editor's. For a 4,000-page fittings catalogue, that is not a compromise — it is the difference between having a French site and not having one.
What actually happens to a request
Your origin keeps serving exactly one version of your site: the one you already have. When a visitor asks for the French version, the request lands on the nearest edge server, which checks its cache for a French copy. If it has one, that is a normal cache hit and it comes back in single-digit milliseconds. If not, the edge fetches the page from your origin in the original language, translates the visible text, rewrites internal links so clicking onward keeps the visitor in French, stores the result, and returns it.
The important word is after. Translation happens after the page is fully built, on finished HTML, which is why it needs no plugins, no schema changes and no cooperation from your theme. It is also why it cannot see anything your theme did not put in the HTML — which brings us to the first thing that will bite you.
Three things that will bite you
1. JavaScript-rendered content arrives untranslated
The edge translates the HTML it receives. If your product grid is rendered client-side from an API after the page loads, that content is not in the HTML, so it stays in the original language. The page will look convincingly translated — navigation, headings, footer, all French — and then the product names will be in Danish.
Check a JavaScript-heavy page on day one, not after launch. If your framework can server-render those routes, do that. If it cannot, exclude those paths and be honest about it rather than shipping a half-translated page.
2. Text inside images stays in the original language forever
A text translator sees text nodes. It does not see the words baked into your hero banner, your infographic, or that PNG of a pricing table someone made in 2019 and nobody can find the source file for. Every multilingual site eventually discovers one of these, usually because a customer points it out.
3. Your brand names need protecting
Without a do-not-translate list, product names get translated inconsistently — "Site Accelerator" becomes one thing on the homepage and something else on the pricing page, and your support team spends a year fielding confused emails. Two minutes spent listing your brand terms, product names and any term of art prevents all of it.
Add legal pages to your do-not-translate list too, or exclude them entirely. Terms of service and privacy policies are documents someone signed off on in a specific language, and machine-translating them changes what you have promised.
Setting it up
Turn on translation and pick your languages
Start with two or three. Every language multiplies the number of cached objects you hold, and there is no prize for launching in twelve markets you cannot support.
Use path-based URLs
example.com/fr/. Not a query string, and never a cookie alone. This one is not a preference — see the next section.
Write your do-not-translate list
Brand names, product names, legal pages.
Add a language switcher and hreflang tags
Humans need the switcher. Crawlers need the hreflang.
Pre-warm the cache
The first visitor per page per language pays the translation cost. Crawl your own sitemap once per language and no real visitor ever waits.
The SEO part, which is where people go wrong
A translated site Google cannot see is a fancy toy. Three things decide whether it works.
Each language needs a real URL. Crawlers do not click language switchers and do not carry cookies. If French only exists behind a JavaScript toggle, French does not exist as far as search is concerned.
| Approach | Indexable? | Shareable links? | Verdict |
|---|---|---|---|
Path: /fr/ | Yes | Yes | Use this |
Subdomain: fr.example.com | Yes | Yes | Works, splits authority |
Query string: ?lang=fr | Patchy | Yes | Avoid |
| Cookie / JS switch only | No | No | Invisible to search |
hreflang has to be reciprocal. Every language version lists every other one, including itself, and each of those pages lists back. One-directional hreflang is the most common implementation mistake there is, and Google silently ignores annotations it cannot confirm from both ends — so it fails quietly, which is the worst way for anything to fail. Add an x-default for visitors who match nothing.
And machine translation is fine. Google dropped its blanket warning against it years ago; what it acts on now is content with no value to the reader, in any language. A machine-translated catalogue that helps a Spanish shopper buy the right fitting is useful. Forty auto-generated languages you have no intention of supporting is not. The distinction is whether the page was worth reading before you translated it.
What it costs you in speed
Almost nothing, once the cache is warm. The first hit per language pays the translation cost; every hit after that is a normal cached response from the edge nearest the visitor.
The real cost is cache footprint, not latency. Three languages means roughly three times the cached objects for the same pages, and a purge clears all of them. If you run a large catalogue, expect your cache hit ratio to dip for a day or two after switching languages on while the new copies get built. That is normal and it recovers on its own.
Questions we get asked
What is edge translation?
Edge translation is a CDN feature that translates a web page into another language on the edge server, after fetching the page from your origin and before returning it to the visitor. Your origin continues to serve a single language, and each translated page is cached per language, so the translation cost is paid once rather than on every request.
Is machine-translated content bad for SEO?
No. Google removed its blanket warning against machine translation years ago and now judges content on whether it is useful to the reader. Translated pages rank fine when they are genuinely helpful, have their own crawlable URLs, and carry reciprocal hreflang annotations. What gets acted on is thin, auto-generated content with no value — in any language.
Should I use subfolders, subdomains or query strings for languages?
Use subfolders such as example.com/fr/. They inherit the domain authority you have already built, are simple to configure at the edge, and are unambiguous for crawlers. Subdomains work but split authority across hostnames. Query strings such as ?lang=fr get indexed inconsistently, and a cookie or JavaScript-only switch is not indexable at all.
Does edge translation slow the site down?
Only for the first visitor to each page in each language. That request pays the translation cost while the page is fetched and processed. The result is cached at the edge, so every subsequent visitor gets a normal cache hit, typically under 20 milliseconds. Crawling your own sitemap once per language pre-warms the cache and removes the one-off cost entirely.
What does edge translation not translate?
Text inside code and pre blocks, terms on your do-not-translate list, words baked into images, and content injected by JavaScript after the page loads. The edge translates the HTML it receives from your origin, so anything not present in that HTML, or deliberately excluded, is delivered in the original language.
Can I hand-write some translations and machine-translate the rest?
Yes, and it is what most sites end up doing. Write your handful of high-value landing pages properly, and let edge translation cover the long tail of documentation, blog archives and product descriptions that would otherwise never be translated at all. Excluding specific paths from edge translation lets the two approaches coexist on one site.
The fittings customer, for what it is worth, turned it on for French and Dutch, spent an afternoon on their do-not-translate list, and left it alone. Their French traffic did not explode overnight — that is not how organic search works — but nine months later it was their third-largest market. The pages had been sitting there the whole time. They just had not been readable.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
