Does Nuxt Bridge share SSR cache keys between Nuxt 2 and Nuxt 3 routes?

Short answer

No — but not because keys are isolated per runtime. Under Nuxt Bridge there is only one server runtime, so there are no separate "Nuxt 2 keys" and "Nuxt 3 keys" to share or isolate. Cache keys are generated by whichever caching layer you configured (Nitro route rules, a serverMiddleware cache module, a CDN, or a reverse proxy), and those keys are almost always derived from the request URL — sometimes plus selected headers — never from which framework style authored the route.

Correcting the premise

The question assumes Bridge runs webpack-based Nuxt 2 pages and Vite-powered Nuxt 3 pages as two coexisting runtimes. That isn't how Bridge works. Bridge is a compatibility layer on top of a single Nuxt 2 application: it backports Nuxt 3 features (composables, useFetch-style APIs, Nitro, Vite as an optional builder) into that one app. All requests are rendered by one server pipeline. Composables and server APIs you add via Bridge run inside the same Nuxt 2/Nitro context and inherit whatever caching configuration the host app defines — there is no automatic per-runtime isolation because there is no second runtime.

What actually composes the key

Because keys are URL-based, a legacy page and a migrated route can only collide if they resolve to the same path — and that is a routing conflict, not a caching bug. The realistic failure mode during incremental migration is different: you migrate a route, the rendered output changes, but a shared cache layer (Nitro storage mount, CDN, or proxy) still serves the old response because its key — the URL — didn't change. A related common trap: many cache layers ignore query strings by default, so two requests that should differ get the same cached entry.

How to verify your effective key scope

1. Enable caching (routeRules with swr/cache, or your module/CDN equivalent) on one test route.
2. Render it, change the route's implementation, and re-request. A stale response confirms the key doesn't include anything that changed.
3. Send requests with varying query strings and headers and observe hit/miss behavior to learn exactly which inputs form the key.
4. Inspect your Nitro storage mount (or CDN cache-key settings) directly to confirm the key composition.

Enforcing isolation during migration

• Namespace Nitro storage mounts so migrated and unmigrated sections write to different cache prefixes.
• Add a build or deployment identifier (or a custom header) to your CDN/proxy cache key, so a deploy that changes rendered output invalidates old entries.
• Disable swr caching on routes being migrated until their output is verified, then re-enable.
• Purge the cache for any route whose implementation changed, rather than waiting for TTL expiry.

Caveats

Exact key inputs depend on which cache layer you use and its version, and Bridge/Nitro behavior evolved across releases — check your versions against their changelogs before relying on a specific key composition. If you're seeing stale content that survives a purge and namespace change, the one diagnostic that would change this advice is which cache layer is actually serving the stale response (Nitro storage vs. CDN vs. proxy), since the fix lives in that layer's configuration.