Why multilingual site architecture matters for sustainability

Serving content in multiple languages introduces repeated variants of pages. Each variant can increase bandwidth, edge compute, and origin responses when caches are not aligned with how language is delivered. That additional work translates to higher energy use and larger network transfer. The technical choices that control which page variant a user gets also determine how well caches can reuse responses. The goal is to provide correct language versions while maximising cache reuse at edge and browser layers.

Two separate concerns to keep clear

Language selection for users and language signals for search engines are related but distinct. Hreflang attributes tell search engines which URL corresponds to which language or region. Runtime language negotiation determines which response a given user receives. Treating these two concerns separately makes it easier to optimise caches without breaking SEO.

Basic design options and their sustainability trade offs

There are three common URL strategies for multilingual sites. The choice affects cache fragmentation and origin traffic.

1. Language in the path for example example.com/en/page. This keeps language visible in the URL and produces distinct cacheable resources per URL. It is easy to cache at edge and in browsers because each language variant has its own URL.
2. Language subdomain for example en.example.com. Similar to path based approach for caching. DNS and CDN configuration add operational work but do not inherently fragment caches more than path based URLs.
3. Content negotiation without language in the URL where the same URL serves different content based on Accept-Language header or cookies. This reduces the number of unique URLs but increases the complexity of cache keys and often causes cache misses because responses vary by header values.

From a sustainability perspective, language in the URL or subdomain typically yields higher cache hit ratios at edge and browser layers, because the same key maps to identical content regardless of who requests it. When language is negotiated dynamically, caches must vary by headers or cookies which fragments cache space and increases origin requests.

How headers and cache keys interact

Two headers are central when you control variation at runtime. The first is Accept-Language which a browser sends to signal preferred languages. The second is Vary which the server uses to tell caches which request headers affect the response. If you must perform language negotiation at runtime, instruct caches with a Vary header that lists the relevant request header names. Vary instructs CDNs and intermediary caches to store separate cache entries for each unique value of the listed headers.

Vary is powerful but costly. A server that responds with Vary Accept-Language causes caches to keep multiple versions of the same resource keyed on the Accept-Language value. That increases cache storage and reduces reuse between users with different language preferences. Where practical, using distinct URLs for each language avoids the need for Vary and typically produces fewer origin requests.

Cache Control and freshness

Use Cache-Control to declare how long a response is fresh at edge and browser layers. Longer freshness reduces origin traffic. For content that rarely changes for a given language variant, favour longer max age values at the CDN and shorter values for browser if you need controlled client refresh. For pages that require personalised elements, separate the personalised fragment from the main content so the main content remains aggressively cacheable.

Hreflang for search engines without harming caches

Hreflang links are intended for search engines and do not affect runtime cache keys. You can publish hreflang annotations across language specific URLs without changing how caches store responses. That means you can continue to serve language variants on separate URLs and let search engines find the mapping through link headers, sitemap entries, or page header link elements.

A practical pattern is to keep hreflang declarations on each language specific page and ensure each language URL is fully cacheable. Do not try to rely on Accept-Language negotiation to satisfy hreflang needs for search indexing. Search engines crawlers discover hreflang through the URL map you provide and will treat each declared URL as a distinct resource for indexing.

Edge translation and on the fly rendering: when it pays and when it does not

Some teams consider translating at the edge so a single origin can store one source canonical and generate language variants closer to the user. This pattern can reduce origin compute if the edge caches generated variants and serves them repeatedly. The trade offs depend on cache key design and cache hit rates.

If the edge produces language variants and those variants are exposed under distinct URLs, caches can store them and reuse them effectively. If the edge uses the same URL and varies by request header, the same cache fragmentation issues apply. Edge generation that immediately increases the number of cacheable language specific URLs can be efficient, but only if traffic per language is substantial enough to justify storing those variants on the edge.

Personalisation, cookies and the cacheability problem

Personalised fragments often cause teams to add cookies or query strings which in turn bust caches. Separate personalised sections from the main content using client side requests to small endpoints or using edge side includes so the main page remains a large cacheable HTML payload. This reduces origin work and network transfer for the majority of users who receive the same base content.

Practical implementation checklist

Follow these steps to align multilingual correctness with cache efficiency and lower origin load.

1. Decide URL strategy. Prefer language in the path or subdomain when you want predictable caching and clear search signals.
2. Serve each language variant on its own URL for content that is static or changes infrequently. Use hreflang declarations on those URLs for search engines.
3. If you must negotiate language at runtime, keep Vary headers minimal and document which request headers the CDN should consider. Consider normalising Accept-Language values at the edge to a small set of keys to reduce cache fragmentation.
4. Use Cache-Control to set appropriate freshness at edge and browser levels. Keep the main HTML aggressively cacheable when possible and move personalization to separate, small requests.
5. Avoid cookies or query string parameters that alter the full page response unless they are necessary. When you must vary by query string, configure your CDN cache key to ignore non significant parameters and only include those that change the page body.
6. Measure cache hit rate and origin request count per language. Monitor bytes served from origin versus edge. Use those metrics to evaluate whether dynamic translation or static language builds are more efficient for your traffic mix.

How to measure the sustainability impact of caching changes

To estimate the impact of caching changes on energy and emissions, track the reduction in origin requests and bytes transferred from origin to edge. Each origin response includes server work and network transfer. Measuring origin request count and average response size gives a practical proxy for reduced energy use. Combine these measurements with published carbon intensity factors for hosting locations if you need an approximate CO2 estimate. Do not overstate precision; present ranges and document the assumptions behind any conversion from bytes or CPU to emissions.

Common pitfalls and how to avoid them

One frequent mistake is relying on Accept-Language negotiation without controlling Vary and cache keys. The result is severe cache fragmentation and a near constant stream of origin requests. Another pitfall is mixing URL strategies in a way that creates duplicates for the same language content. Keep a single canonical URL per language and ensure hreflang and canonical declarations are consistent.

Avoid placing critical language choice behind a cookie or a heavy client side detection flow that delays caching. If language detection must happen on the client, ensure the server response is still cacheable independently and that the client request for the language specific fragment is small and cacheable.

Decision criteria for choosing a pattern

If your traffic is evenly distributed across languages and each language receives significant traffic, prefer separate URLs per language. That maximises cache reuse. If you have one dominant language with small numbers of other language users, consider serving the dominant language as the default and offering small client side fetches for the minority languages to avoid storing many rarely used variants on the edge.

When your content changes frequently and you cannot afford long cache lifetimes, focus on reducing response size and moving stable fragments into aggressively cached assets. For sites with heavy personalization, adopt edge side includes or modular APIs so the primary page remains cache friendly.

Operational runbook for rollout

Implement changes in stages with measurement gates.

1. Record baseline metrics: overall cache hit ratio, edge versus origin bytes, origin request rate by URL pattern, and Accept-Language distributions in logs.
2. Choose initial pattern for a subset of pages or a low traffic section. Apply URL based language variants and configure hreflang entries for those pages.
3. Compare cache hit ratio and origin request count for the test set against baseline. If origin traffic drops and search indexing remains consistent, expand rollout.
4. If using runtime negotiation, deploy normalisation rules at the edge that map Accept-Language values to a small set of canonical keys before the CDN computes cache keys.
5. Continue to monitor search console signals for indexing issues and measure real user metrics for page load to ensure UX is unchanged.

What to document for future teams

Keep a short technical note that describes the chosen URL strategy, cache key rules at the CDN, which headers are included in the cache key, and where hreflang declarations are generated. Record the measurement queries used to compute cache hit ratio and origin traffic. This documentation speeds troubleshooting when translations or caching regressions appear.

Next steps to apply these ideas

Start by auditing a representative sample of pages and compute the current edge cache hit ratio for each language variant. If you find high fragmentation tied to header variation or cookies, prioritise moving language variants to separate URLs or normalising header values at the edge. Use small test rollouts and measurable gates to expand changes while preserving search visibility and user experience.