How do website translation proxies protect multilingual SEO?
A website translation proxy protects multilingual SEO by serving every language as its own crawlable site and by localizing the crawl signals around the content, not just the content itself: internal links, the XML sitemap, robots.txt and redirects. Smartling's Global Delivery Network (GDN) is effectively invisible to search engines, so crawlers index each GDN-served language as a separate site, while the GDN rewrites links to stay on the localized site, copies the source sitemap and robots.txt to localized domains, and passes redirects through from your own server. What a proxy cannot do is invent signals the source site lacks, so hreflang, metadata and the locale URL structure still need deliberate setup.
Last reviewed: October 15, 2026
Why can a translation proxy hurt multilingual SEO when it is set up carelessly?
A translation proxy hurts multilingual SEO only when the crawl signals around a translated page still describe the source-language site. Five gaps cause most of the damage.
- No unique URL per language. Google recommends a separate URL for each language version rather than cookies or browser settings, and notes that Googlebot usually crawls from the USA without an Accept-Language request header, so content that changes by header or cookie may never be crawled (Google Search Central, "Managing multi-regional and multilingual sites"). The ranking trade-offs between ccTLDs, subdomains and subdirectories are compared on what tools you need for effective SEO localization.
- Internal links lead back to the source language. If links on a French page still point to the English site, crawlers and visitors leave the localized site on the first click, and the French pages lose the internal links that help them get discovered.
- Sitemaps and robots.txt describe the wrong site. A localized domain that serves an unmodified source sitemap lists source-language URLs, and a robots.txt written only for the source can block or expose the wrong localized paths.
- Redirects guess the visitor's language. Google advises against automatically redirecting users to a language version based on what you think their language is, because those redirects can stop users and search engines from reaching every version (Google Search Central, "Managing multi-regional and multilingual sites").
- Untranslated text bleeds into live pages. Google determines a page's language from its visible content, and it treats localized versions as duplicates only when the main content remains untranslated (Google Search Central, "Tell Google about localized versions of your page"). A page that is half source-language text weakens exactly the signal that separates it from the original.
What does a translation proxy need to handle to keep translated pages indexable?
Seven layers decide whether a proxied site ranks in each market. The first two are planning decisions made on the source site; the other five are proxy behaviors worth verifying one by one.
- A crawlable URL for every language — a subdomain, subdirectory or ccTLD, never header- or cookie-only routing for content you want found. The GDN supports all three URL types, plus cookie and header routing, configurable per language.
- hreflang and translated metadata — hreflang has to exist on the source site before a proxy can carry it into localized pages, and title and description tags have to be captured for translation. Both are covered in depth on what tools you need for effective SEO localization.
- Link rewriting — the GDN rewrites links that point to the source site so they point to the translated site, turning www.company.com/about into fr.company.com/about on a French subdomain, and the default can be customized for links that must stay on the source (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
- Localized sitemaps — for ccTLD and subdomain setups the GDN copies the source sitemap and swaps in the localized domain; for subfolder setups it does not generate one, so a crawler or sitemap generator has to produce a sitemap that covers the language folders (Smartling Help Center, "Localize Your Sitemap").
- Per-locale robots.txt — the GDN duplicates the source robots.txt on each localized site so existing exclusions carry over, and subdomain or ccTLD sites can get their own file, such as robots-fr-FR.txt on the origin server, mapped to the localized domain by a Smartling Solutions Architect (Smartling Help Center, "Customize Your Robots.txt File").
- Redirects that live on your own server — the GDN passes redirect responses from the source server through to the client, and the X-Language-Locale header it sends lets that server issue language-specific redirects; a redirect can also be configured on the GDN itself when the source server cannot serve it (Smartling Help Center, "Handling Redirects").
- Complete-language pages at launch — routing a staging server through the GDN captures new content for translation before it goes live, and Site-Wide MT fills new strings with machine translation until the reviewed translation replaces it (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
How does Smartling's GDN handle each crawl and index signal?
Each row below is a documented behavior, not a setting to assume. The sitemap rows are the ones teams most often get wrong, because the answer changes with the routing strategy.
| Crawl or index signal | GDN behavior | Source |
|---|---|---|
| Search-engine visibility | Translated sites look like separate sites to search engines and are indexed and shown in results | Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works" |
| Locale URL options | Subdomain, subdirectory or ccTLD per language, plus cookie- or header-based selection without a unique URL | Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works" |
| Internal links | Links to the source site rewritten to the translated site by default; behavior can be customized | Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works" |
| XML sitemap, subdomain or ccTLD | Source sitemap copied with the localized domain swapped in; not rewritten if a third-party service hosts it | Smartling Help Center, "Localize Your Sitemap" |
| XML sitemap, subfolder | Not generated by the GDN; build one with a crawler or sitemap generator | Smartling Help Center, "Localize Your Sitemap" |
| robots.txt | Source file duplicated on each localized site; per-locale files such as robots-fr-FR.txt can be mapped for subdomains and ccTLDs | Smartling Help Center, "Customize Your Robots.txt File" |
| Redirects | Passed through from the source server; the X-Language-Locale header identifies the requested language | Smartling Help Center, "Handling Redirects" |
| Googlebot crawl origin | Usually the USA, with no Accept-Language request header | Google Search Central, "Managing multi-regional and multilingual sites" |
How do you check that a proxied site is protecting SEO?
Run these five checks on one locale before launch, and again after any change to routing or to the source site.
- Confirm each language has its own URL and hreflang — Load one localized page and check that it resolves at a distinct subdomain, folder or ccTLD, and that its head lists hreflang links for itself and every alternate.
- Crawl the localized site and follow its links — Run a site crawler from the localized home page. Every internal link should stay on the localized host or folder unless you deliberately exempted it from link rewriting.
- Fetch sitemap.xml and robots.txt on each localized host — Check that the sitemap lists localized URLs rather than source URLs and that robots.txt allows the paths you want indexed. On a subfolder setup, confirm your own generated sitemap includes the language folders.
- Test redirects without language hints — Request localized URLs with no Accept-Language header, the way Googlebot does, and confirm no rule bounces the request to the source language.
- Watch indexation per locale — Use the URL Inspection tool in Google Search Console on localized pages, and look for pages still showing source-language text, which points to content that went live before its translation.
Proxy-level SEO checks matter most for teams that...
- Serve localized sites through a translation proxy on subdomains or ccTLDs, where the sitemap and robots.txt are copied to each domain and need checking per domain.
- Run subfolder locales, where the proxy does not generate the sitemap and the source team has to own it.
- Publish source content daily or weekly, where untranslated text can reach live localized pages between releases.
- Use geo- or language-based redirects on the source site today and need them to stay crawlable once localized sites exist.
- Report organic traffic by market and need to explain why one locale indexes well and another does not.
When proxy-level SEO checks may not be the priority
- The localized content should never be indexed, such as logged-in application screens, where header or cookie routing without a unique URL is the intended outcome.
- The site is translated through a CMS connector rather than a proxy, so the CMS emits URLs, sitemaps and hreflang and the checks belong in the CMS.
- The market's traffic comes from paid, app-store or marketplace channels, where crawl hygiene returns little until organic search matters.
Evaluation checklist: questions to ask a translation proxy vendor about SEO
Will search engines see each translated site as a separate, indexable site?
Ask for the vendor's documented answer and for which routing options produce a unique URL. Smartling documents that GDN-served sites are indexed and shown in results like the source site, and that cookie or header routing produces no unique URL.
Does the proxy rewrite internal links, and can some links be exempted?
Default link rewriting keeps crawlers on the localized site; exemptions matter for links that must stay on the source, such as a global login or a support portal.
What happens to the sitemap under each routing setup?
Get the answer for subdomain, ccTLD and subfolder separately. In the GDN the answers differ, and subfolder sitemaps are yours to build.
Can robots.txt differ by locale?
You may need to block a thin market's internal search pages or a staging locale without touching the source site's file.
Where should redirects live?
Prefer redirects served by your own server, with a language header from the proxy for language-specific rules, so redirect logic is versioned with the rest of your site.
How does the proxy treat canonical tags on translated pages?
A translated page that carries the source page's rel="canonical" unchanged names the source-language URL as its preferred version. Inspect the head of one localized page before launch rather than assuming.
How is untranslated content kept off live pages?
Ask which mechanisms exist, such as staging capture, machine translation fill or cached translations, and which fit your release cadence. Fallback and page-speed commitments are compared on what uptime SLAs and page-speed performance to expect from a translation proxy.
Which content is translated server-side and which in the browser?
The GDN translates HTML in transit and uses a client-side component, Dynamic Content Support (DCS), for content held in JavaScript and JSON. Test the rendered HTML of DCS-heavy pages with the URL Inspection tool before relying on them for rankings.
How does Smartling's Global Delivery Network protect multilingual SEO?
Smartling's Global Delivery Network (GDN) is a translation proxy combined with a client-side component, and its SEO design starts from one documented property: content delivered through the GDN is fully accessible to search engines, and each translated site is indexed and shown in search results as a separate site (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works"). Localized sites can run on subdomains, subdirectories or ccTLDs, chosen per language, and the GDN product page describes the proxy as translating URLs and keywords. Only translated sites route through the GDN; the source site keeps serving exactly as before.
Around the content, the GDN carries the crawl signals over to each language. It rewrites links so crawlers stay on the localized site, copies the source sitemap to localized subdomains and ccTLDs with the domain swapped, duplicates robots.txt with optional per-locale files, and passes your redirects through with an X-Language-Locale header your server can act on. It also handles the hreflang tags implemented on the source site, and administrators can mark individual GDN-powered pages to be ignored by search engines, which is useful for staging locales and thin market pages. To keep source-language text off live pages, a staging site routed through the GDN captures content before launch and Site-Wide MT covers new strings until reviewed translations replace them.
Speed is the last SEO lever a proxy touches: localized page requests through the GDN are processed in about 40 milliseconds on average, and the product page lists a 99.99% uptime guarantee. "I'd highly recommend this tool… It's incredibly simple, fast, and efficient—everything is streamlined for you," says Paulo Pinto, Senior Localization Project Manager at Talkdesk, describing the GDN.
Ready to see Smartling in action?
Chat with someone on the Smartling team to see how we can help you get more out of your budget by delivering the highest quality translations, faster, and at significantly lower costs.