Reviewed by the Ayouhuo project owner · Updated July 13, 2026 · Editorial principles

Architecture model branching from one root into two language page groups and CDN nodes
One root handles entry selection while two stable language groups are delivered through the CDN. Original Ayouhuo illustration created with AI assistance.

Separate three different decisions

Multilingual projects often combine the first language a visitor sees, the permanent URL for each language, and what a CDN can cache. This rebuild compared several approaches and settled on a simple rule: the root chooses a language, while real content lives at stable language URLs.

This is one tested design, not the only valid architecture. It fits a new corporate site with explicit language versions and CDN delivery.

Give content stable language URLs

Chinese pages live under /zh/; English pages live under /en/. Once a visitor opens one of those URLs, the server does not redirect them again based on browser language.

Each page uses a self-referencing canonical. When a complete counterpart exists, hreflang connects the language pair. A visible language link lets people switch without changing browser settings.

This gives search systems separate URLs to crawl and gives visitors a link that will not change language the next time it opens. Google likewise recommends separate URLs for language versions.

Use the root only for language selection

At /, the server first reads a language the visitor previously selected, then considers the browser's language. A clear signal receives a temporary 302 to /zh/ or /en/. Without a reliable signal, the root returns a bilingual selector.

That selector is x-default: the default destination when the site cannot choose a language. It is not a third language version.

The redirect is temporary because language preference can change. Unprefixed deep URLs do not duplicate the content, so every article or service retains one official URL per language.

Negotiation cannot be the only discovery path

Google warns against relying only on inferred-language redirects because people and crawlers may miss another version. Stable language URLs, reciprocal page links, hreflang, and visible switching remain necessary. The root is an entry, not the only route to content.

The root selects a language while stable language pages handle indexing and CDN caching
Reorganized from Google multilingual guidance and this site’s implementation tests; original Ayouhuo illustration, AI-assisted.

Why the root cannot use normal page caching

The root can return different results for different visitors. If a CDN stores the first response, later visitors may all receive the same language. The root therefore returns:

Cache-Control: private, no-store
Vary: Accept-Language, Cookie

private, no-store means the negotiated result must not be stored. Vary records the request signals used to select it. The origin web server also avoids page response caching so the mistake cannot happen before the CDN.

How regular pages are cached

Explicit language pages, CSS, JavaScript, and images do not vary by visitor. The tested cache policy returns:

Cache-Control: public, max-age=3600, s-maxage=2592000

The browser stores a response for one hour; a shared cache may store it for thirty days. After the hour, ETag or Last-Modified allows revalidation without downloading an unchanged file. APIs, private lead results, 404s, and server errors are not cached.

These durations are project choices, not universal defaults. News, frequently changing prices, and another CDN need their own policy.

What implementation testing found

Automated tests cover four root visits: a prior Chinese choice, a prior English choice, a first visit with a browser language, and no reliable signal. They also confirm that explicit /zh/ and /en/ pages never negotiate again.

One test caught a small real defect: a redirect with no query parameters could still end with a question mark. The page worked, but the URL was untidy. Automated checks now cover both preservation of real parameters and removal of the empty marker.

Long CDN caching requires release invalidation

A thirty-day shared cache does not prevent same-day publishing. Alibaba Cloud CDN can invalidate an old cached URL so the next request retrieves the new response. Specific files can also be prefetched when needed.

The release deploys and verifies the origin first, submits the CDN refresh, waits for completion, and then checks content, status, and cache headers at the edge. A failed refresh blocks release completion.

Browser and CDN caches are separate. Purging the CDN does not remove the one-hour copy already stored in a visitor's browser. An urgent asset replacement may need a new filename or a different browser-cache policy.

Pre-release checklist

  • /zh/ and /en/ return content without another language redirect.
  • / behaves correctly for saved choices, Chinese and English browsers, and no signal.
  • Every page identifies itself as canonical and references only complete counterparts.
  • The root, APIs, private results, and errors are not cached.
  • HTTP and host redirects happen once while preserving paths and real query parameters.
  • Release checks cover both the origin and the CDN edge.

Sources and boundaries

The official sources establish URL and CDN behavior. The directory structure, durations, negotiation order, test cases, and redirect defect come from this implementation.

Check whether your website has these foundations

Use 15 questions to review content, evidence, technology, languages, and enquiry paths. Submit the site when a deeper review is needed.