What Happens When Your Translation Provider Goes Down?
When a translation provider has an outage, your own server usually keeps serving pages, but the translated layer may not appear. What visitors and search engines see depends on how the translation is delivered: a page can fall back to the source language, show a mixture of languages, render with missing text, or stall while it waits for a script. The difference between a minor blip and a serious problem is mostly decided by your architecture, not by the length of the outage.
Why does a translation layer have its own failure modes?
A multilingual site has two jobs: serve the page, and serve the page in the visitor's language. Many translation tools split those jobs across different systems. Your origin server delivers the original HTML, and a script, plugin call or proxy fetches or generates the translated text somewhere else, at the time of the request.
Every extra system on the request path is a place where something can go wrong. That is true of any third-party dependency, not just translation. The important question for a site owner is whether a failure in that dependency degrades gracefully or catastrophically. The sections below list the common failure modes and what each looks like from the outside.
What are the common ways a translation service fails?
| Failure mode | What it looks like to a visitor | What a crawler may see |
|---|---|---|
| Vendor script blocked or slow | Page shows source language, or waits, then switches late | Source-language HTML, or a partially translated render |
| API returns errors (4xx/5xx) | Missing strings, empty regions, or untranslated fallback text | Same, plus possible inconsistent content between crawls |
| Quota or rate limit exceeded | New or uncached pages stay untranslated while old ones work | Newly discovered pages indexed in the wrong language |
| Subscription lapsed or payment failed | Translations disappear, sometimes all at once | Language URLs may return the source language or an error |
| DNS or CDN fault | Requests to the vendor domain hang or fail to resolve | Fetch failures during rendering |
| Your own page breaks on a thrown error | Whole page fails to initialise, not only the translation | Broken or empty rendered HTML |
These are categories, not predictions: not every tool is exposed to every row. Section by section:
Script blocked or slow
Many translation tools load a JavaScript file from the vendor's domain. If that domain is unreachable, blocked by a corporate network, an ad blocker or a privacy extension, or simply slow, the script never runs. If the script was added as a render-blocking resource in the <head>, the browser may wait for it before painting anything. If it was loaded asynchronously, the page paints in the source language and stays that way.
The performance side of this is covered in translation plugin performance and Core Web Vitals.
API errors
Some setups call a translation API when a page is first requested, then cache the result. If the API returns an error and there is no cached copy, the code has to decide what to do. Good code shows the source text. Poor code throws an exception, prints a placeholder, or returns an HTTP 500 for the whole page. This is a code-quality question you can answer by testing, not by reading marketing pages.
Quota exceeded
Usage-based plans have limits. When a limit is reached, behaviour varies: the service may stop translating new content, return errors, or throttle. The dangerous variant is a partial failure. Old, already-translated pages still work, so nothing looks wrong on the pages you check, while new product pages or blog posts silently appear in the source language on your French or German URLs.
Lapsed subscription
A billing failure is the most avoidable outage and often the most severe, because it may remove everything at once. Whether translated URLs keep working after a plan ends is a contract and architecture question. It overlaps with the lock-in issues discussed in how to avoid translation vendor lock-in.
DNS and CDN problems
If the vendor's hostname fails to resolve, or its CDN has a regional fault, requests may hang until the browser times out rather than failing fast. A hanging request is usually worse than an error, because it holds up whatever is waiting for it. Even a perfectly healthy vendor can look "down" to visitors in a region with a routing problem.
What do visitors experience during a failure?
Visitors do not know or care which vendor is at fault. They see one of four outcomes:
- The source language. Acceptable if the page is usable, but a visitor who chose Spanish and gets English may leave.
- A mix of languages. Navigation in one language and content in another is confusing and looks broken.
- Empty or broken sections. Buttons, prices or form labels vanish. On a store, this directly affects the ability to buy.
- A slow or frozen page. Waiting for a dependency that never responds is the worst case, because there is no visible cause.
Impact is easy to reason about without invented numbers. Take the share of your traffic that arrives on translated URLs, multiply by the share of those visits that depend on the failing component, and multiply by the length of the outage. If you do not know your first number, your analytics' language and landing-page reports will give it to you. For a site where half of revenue comes from translated pages, even a short failure on a high-traffic day matters. For a site where translation is a courtesy for a few visitors, it matters much less. The point is to calculate it for your own site.
What do search engines see?
Google processes JavaScript sites in three phases, crawling, rendering and indexing, and Google's documentation notes that it does not render JavaScript from blocked files or pages. Pages that return a 200 status are queued for rendering, and Google indexes the rendered HTML. Two practical consequences follow.
First, if your translated text only exists after a vendor script runs, a failed script means the rendered HTML may be missing the translation when Google looks. Second, Google's documentation says rendering does not keep local storage, session storage or cookies between page loads, so any design that relies on a visitor's browser having stored something will not help Googlebot. See client-side vs server-side translation and SEO for the underlying trade-off.
Server errors are a separate matter. Google's documentation on HTTP errors says 5xx and 429 responses make its crawlers slow down, that content returned with those errors is ignored, and that URLs which persistently return server errors can eventually be removed from the index. The documentation does not give a fixed time limit, so avoid planning around a "safe" number of hours.
We could not find primary guidance on exactly how Google treats a page whose translation script intermittently fails. Treat that as an unknown, and test rather than assume.
How should a translation layer be built to survive an outage?
The principles are straightforward and apply regardless of tool:
- Source language is the floor. The original content should always be in the HTML, so a failure degrades to a readable page.
- No render-blocking dependency on third parties. Load translation scripts asynchronously and never let them gate first paint.
- Time out fast. A request that fails in a second is better than one that hangs for thirty.
- Keep your own copy. Translations that exist as files on your own site, or in a cache you control, cannot disappear when an account lapses.
- Cache with a stale fallback. HTTP caching supports serving a stale copy while the origin or CDN is failing; the mechanics are explained in static translation bundles and CDN failover.
- Alert on the translation layer itself. Monitoring that only checks whether the homepage returns 200 will not notice untranslated content.
We are building ResilientLang around this idea: it is designed to serve pre-built translation files from your own site and two CDNs, and to fall back to the original language, but it is not released yet.
How do you find out whether you are exposed today?
Do not wait for a real outage. Block the translation vendor's domains in your browser, throttle the network, and reload a few important pages in each language. Then check the rendered HTML as Google sees it using the URL Inspection tool. How to test translation failure provides a test matrix and a script you can reuse.
Key takeaways
- A translation outage rarely takes down your origin server, but it can remove or break everything that makes a page usable in another language.
- Hanging requests and render-blocking scripts are more damaging than clean errors, because nothing fails visibly.
- Search engines can only index what they can render; persistent 5xx responses are documented to cause URLs to drop out of the index.
- Estimate business impact from your own traffic share on translated URLs, not from generic statistics.
- The source language should always remain a working fallback, and your translations should exist somewhere you control.
Sources
- JavaScript SEO basics – how Google crawls, renders and indexes JavaScript pages, and blocked resources
- Fix Search-related JavaScript problems – rendering does not persist storage; aggressive caching; fingerprinting
- HTTP status codes, and network and DNS errors – how Google reacts to 5xx and 429 responses
- Cache-Control (MDN) – stale-if-error and stale-while-revalidate directives
- RFC 5861: HTTP Cache-Control Extensions for Stale Content – defines serving stale content during errors
Frequently asked questions
Will my website go down if my translation provider has an outage?
Usually the site itself stays up, because your own server is separate. What breaks is the translation layer. Depending on the design, visitors see the original language, a half-translated page, a blank area, or a slow page that waits on a script that never answers.
Does a translation outage hurt SEO?
It can, but the effect depends on what Google fetches during the failure. Google has documented that persistent 5xx errors can cause URLs to be dropped from the index, and that rendering depends on being able to fetch resources. Short, partial failures are less likely to matter than long ones, though we cannot give a safe duration.
What is the safest fallback when translations fail to load?
Show the original-language content that is already in the page, keep the language switcher usable, and avoid blocking rendering while you wait. A readable page in the source language is almost always better than a blank or broken one.
How can I tell whether my site depends on a single translation vendor at runtime?
Open the Network panel in your browser's developer tools, block the vendor's domains, and reload a translated page. If the page breaks, loses its translated text, or hangs, you have a runtime dependency. The guide on testing translation failure walks through this step by step.