A multilingual website needs to deliver the right translated content to the right visitors without sacrificing speed. This is where caching multilingual websites becomes essential, helping translated pages load faster while reducing repeated requests to your server. However, caching multiple language versions can introduce challenges such as stale translations, wrong-language content, and inconsistent results for search engine crawlers.
In this guide, we’ll explore the most common multilingual caching issues and explain how Cloudflare and Varnish handle translated content. Keep reading to choose the right caching strategy, prevent cross-language cache hits, and build a reliable setup for your multilingual website.
Key points: Multilingual website caching with Cloudflare & Varnish
Separate language versions
Use language-specific URLs or cache keys to ensure each translated version is stored and served separately. This helps prevent users from receiving content in the wrong language.
Prevent cache conflicts
Varnish and Cloudflare must account for language information from URLs, headers, or cookies. Proper configuration prevents cross-language cache hits and ensures visitors receive the correct translation.
Keep translations fresh
Set appropriate cache TTLs and purge affected caches whenever translations are updated. This prevents outdated content from remaining visible to visitors.
Why multilingual caching matters?
Multilingual websites can have multiple cached versions of the same page because each language may contain different content and URLs. Caching these translated versions allows the website to reuse existing responses instead of repeatedly processing the same content for every request. This can reduce requests to the origin server, improve page load times, and provide a faster experience for visitors.
However, multilingual caching needs to keep each language version properly separated. If the caching system does not distinguish between language variants, a visitor requesting a French page could receive a cached English version instead. Similarly, when a translation is updated, an older cached response may continue to be displayed until it expires or is invalidated.
Caching also plays a role in how search engine crawlers access multilingual pages. Each language URL should consistently return its corresponding translated content so search engines can properly understand and index the localized versions. A reliable caching setup should therefore work alongside SEO signals such as hreflang, canonical URLs, and language-specific metadata.
How to build a multilingual website caching strategy
A good multilingual caching strategy ensures that visitors consistently receive the correct language version while keeping pages fast and reducing server requests. The first step is deciding how your website identifies each language and how the caching system uses that information.
URL and subdomain routing
Language-specific URLs are one of the simplest ways to make multilingual caching predictable. Each language has its own URL, so the cache can store and serve each version separately. For example, example.com/fr/ can represent the French version, while example.com/de/ represents the German version.
Language-specific subdomains work similarly. A website might use fr.example.com for French and de.example.com for German. Because the language is included directly in the URL, visitors and caching systems can easily identify which version to serve. Common URL structures include:
- example.com/fr/
- example.com/de/
- fr.example.com
- de.example.com
Header-based language detection
Websites can also determine a visitor’s preferred language through HTTP headers, particularly the Accept-Language header the browser sends. For example, a browser configured for French may send Accept-Language: fr, allowing the server to automatically select the French version.
However, header-based detection requires careful cache configuration. If the cache only considers the page URL and ignores the language header, it could store one language version and return it to visitors with a different language preference. The cache key or Vary behavior must therefore account for the relevant language information. For example:
- Accept-Language: en
- Accept-Language: fr
- Accept-Language: de
Cookie-based language detection
Another approach is storing the visitor’s language preference in a cookie. Once a visitor selects a language, the website can save that choice and use it for subsequent requests. This can provide a more consistent experience, especially when visitors manually choose a language rather than relying on their browser settings.
The challenge is that cookies can complicate caching. If the cache does not distinguish requests based on the language cookie, visitors may receive a cached page intended for another language. The caching layer should therefore be configured to vary or bypass caching when necessary. For example:
- language=en
- language=fr
- language=de
Choosing a caching strategy
The best caching strategy depends on how your website handles language selection. URL-based language routing is generally easier to cache because each language has a unique URL. Header- and cookie-based detection can still work, but it requires more careful configuration to ensure cached responses are separated correctly.
Before choosing an approach, consider the number of languages, how visitors select languages, and how frequently translated content changes. The goal is to make language detection and cache behavior work together, rather than letting the caching layer treat every request as the same page. Key factors to consider:
- Language-specific URLs
- Cache key configuration
- Header and cookie handling
- Cache TTL
- Cache invalidation
- Translation update frequency
- Search engine crawling
How Varnish caches multilingual and translated content
Varnish Cache works as a reverse proxy between visitors and the origin server. When a visitor requests a page, Varnish checks whether a valid cached response is available. If it finds a matching response, it serves the cached content without sending the request back to the origin. If no suitable response exists, Varnish forwards the request to the origin, receives the response, and can store it for subsequent requests.
For multilingual websites, Varnish needs to distinguish between requests that should return different language versions. The language information must therefore be considered when Varnish determines whether a cached response can be reused. This prevents the cache from treating different translations as the same response.
Language-specific cache keys
Varnish needs a way to distinguish cached responses that represent different language versions. When the language is already included in the URL, each URL can naturally map to a different cache entry. When the language is determined by a request header, cookie, or another request value, the Varnish configuration needs to incorporate that information into its caching logic. For example, a multilingual site might distinguish cached responses using:
- /en/about/ → English cache entry
- /fr/about/ → French cache entry
- Accept-Language: en → English variation
- Accept-Language: fr → French variation
- A language cookie → Visitor’s selected language
The exact implementation depends on how the website determines the language. The key requirement is that requests producing different translated responses must not resolve to the same cached object.
Preventing cross-language hits
A cross-language cache hit occurs when Varnish returns a cached response for one language to a visitor requesting another. For example, a visitor requesting a French page could receive an English response if both requests are treated as the same cacheable resource.
To reduce this risk, Varnish should only reuse a cached response when the language variation is known and matches the request. If the language cannot be determined reliably, the response should be handled carefully rather than stored as a shared cache entry. Important safeguards include:
- Avoid caching responses with ambiguous language information
- Handle language cookies and headers consistently
- Test cache hits and misses for different language requests
- Verify language switching after caching is enabled
Varnish cache invalidation
Cache invalidation removes or marks cached content as no longer valid. This is important when the original content or its translation has been updated. Without invalidation, Varnish may continue serving an older cached version until its configured TTL expires.
For multilingual websites, invalidation should account for all affected language versions. If an English page and its French translation are updated, the corresponding cached responses should be cleared or refreshed so visitors do not see outdated content. Common approaches include:
- Purging specific URLs
- Purging multiple language versions
- Using cache TTLs
- Automatically purging after content updates
- Refreshing affected translated pages
How Cloudflare caches multilingual content at the edge
Cloudflare works as an edge caching layer between visitors and your origin server. When a visitor requests a page, Cloudflare checks whether a cached version is available at an edge location. If a valid response exists, it can be served directly from the edge instead of requesting the page from the origin server. If no cached response is available, Cloudflare retrieves the content from the origin and can cache the response for subsequent requests.
For multilingual websites, this process needs to account for the requested language. Cloudflare must be able to distinguish between different language versions so that a cached English response is not served to someone requesting the French version. This makes language-aware cache configuration important when translated content is delivered through different URLs, headers, or cookies.
Separating language versions
Cloudflare can cache different language versions separately when each version has a distinct URL. For example, /en/, /fr/, and /it/ can represent English, French, and Italian content. Because the language is included directly in the URL, each version can have its own cache entry, making it easier to manage and purge individual language versions. For example:
- example.com/en/products/
- example.com/fr/products/
- example.com/it/products/
Cloudflare cache keys and language variations
Cloudflare needs to distinguish requests whenever different language inputs can produce different responses. With URL-based language routing, this separation happens naturally because each language has its own URL.
More attention is required when the language is determined by the Accept-Language header or a cookie. If these values affect the translated response but are not handled by the caching configuration, requests for different languages may be treated as the same resource. This can result in one language being served to visitors requesting another.
For most multilingual websites, URL-based routing is easier to manage because the language is directly visible in the URL. Header- and cookie-based detection can also work, but they require additional configuration to ensure that different language responses are not incorrectly shared.
Cache TTLs and purging
A cache TTL (Time to Live) determines how long Cloudflare keeps a cached response before it expires. A longer TTL can improve performance because content remains cached for longer, while a shorter TTL allows changes to become available sooner.
For multilingual websites, TTLs should reflect how frequently the content and translations change. Frequently updated pages may need shorter TTLs, while stable pages can generally use longer ones. When a translation changes, the affected language version should be purged or refreshed rather than waiting for the TTL to expire. This helps prevent visitors from receiving outdated translations. The caching strategy can include:
- Short TTL for frequently updated content
- Longer TTL for stable pages
- URL-specific cache rules
- Manual cache purging
- Automatic purging after updates
Best practices for caching multilingual websites
A well-planned caching setup can make multilingual websites faster without causing visitors to receive the wrong or outdated translation. The key is to make your translation system and caching layer work together, while clearly separating each language version.
Combine translation and caching
Translation and caching should work together as part of the same content delivery process. The translation layer determines which localized version should be returned, while the caching layer stores that response for subsequent requests. The important consideration is timing: the language should be determined before the response is cached. This ensures that the cache stores the translated response that was actually requested rather than an ambiguous version that could be reused for another language.
For websites that use automatic translation, a translation solution such as Linguise can simplify this process by automatically generating localized content while allowing the translated pages to work with the website’s existing caching setup. This can be useful for websites with multiple languages, where manually managing translated versions and keeping them synchronized with cached content can become more complex.
Best practice: Make sure your translation system and caching layer agree on how language versions are identified before enabling full-page caching.
Use language-specific cache keys
Each translated response should map to the correct cache variation. URL-based language structures make this easier because each language already has a distinct URL, while header- or cookie-based setups require additional cache configuration.
Best practice: Prefer language-specific URLs where possible, such as:
- /en/about/ → English
- /fr/about/ → French
- /de/about/ → German
This provides a clear separation between language versions and reduces the risk of cross-language cache hits.
Set cache-control and TTLs
Cache-Control headers and TTLs determine how browsers, CDNs, and reverse proxies handle cached content. Setting them correctly helps balance website performance with the need to deliver fresh translations.
Pages that rarely change can usually stay cached for longer, while frequently updated content should use shorter TTLs. The right setting depends on how often your website content and translations are updated.
Best practice: For example, you could use a longer TTL for a static multilingual landing page and a shorter TTL for product or news pages that change frequently. Always test the configuration to make sure updated content becomes available when expected.
Purge caches after updates
When content or translations change, purge or refresh the affected cached responses instead of relying solely on TTL expiration. This helps ensure visitors receive the latest version across all affected languages.
Best practice: Include cache invalidation in your content update workflow and make sure all affected language versions are covered.
Test cached multilingual pages
Testing is important because caching problems are not always visible during normal browsing. A page may look correct when accessed directly but return the wrong language when served from a cached response.
Test each language version after configuring or changing your caching rules. Check both first-time requests and subsequent requests to confirm that the correct cached response is consistently returned.
Best practice: Test scenarios such as:
- Opening the same page in different languages
- Reloading a cached page
- Switching between languages
- Updating a translation
- Checking the page after a cache purge
- Crawling language-specific URLs
Multilingual caching checklist
Before putting your multilingual caching setup into production, use a simple checklist to verify that language detection, caching, and content updates work together correctly.
Best practice checklist:
- Give each language version a unique URL or cache variation
- Use language-specific cache keys
- Configure appropriate Cache-Control headers
- Set TTLs based on content update frequency
- Purge affected language versions after updates
- Test cached pages in every supported language
- Check for wrong-language responses
- Check for stale translated content
- Verify language-specific URLs with search engine crawlers
Conclusion
Caching multilingual websites effectively requires a balance between website performance and delivering the correct, up-to-date language version to every visitor. By using language-specific cache keys, appropriate TTLs, and reliable cache invalidation, you can reduce server requests while preventing wrong-language and stale content.
For a simpler way to manage translated content, register with Linguise and streamline your multilingual website workflow with automated translation while keeping your localized content fast and manageable.
