[6.x] Astro includes prerendered redirect target pages in SSR bundle

[spaceemotion]

Astro Info

Astro                    v6.4.5
Node                     v24.15.0
System                   Linux (x64)
Package Manager          pnpm
Output                   static
Adapter                  @astrojs/vercel
Integrations             @astrojs/vue (v6.0.1)
                         @astrojs/markdoc

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When using output: 'static' with an adapter (hybrid mode), prerendered pages that are targets of redirects defined in astro.config are incorrectly bundled into the server function, massively inflating its size.

This means when the SSR environment queries its routes (isPrerender = false), every redirect's destination page gets included, even if that page explicitly contains an export const prerender = true.

The result is the entire page, its sources (static page dependencies, content collections, etc.) are being bundled into the server function. In our case: 68MB server bundle instead of ~1.4MB, because 4 static .astro pages pulled in all their dependencies.

What's the expected result?

Prerendered pages should not be bundled into the server bundle at all, they are static.

The cause seems to also be in the getRoutesForEnvironment method.
I verified that the following patch fixes the issue:

diff --git a/dist/vite-plugin-pages/pages.js b/dist/vite-plugin-pages/pages.js
index 1234567..abcdefg 100644
--- a/dist/vite-plugin-pages/pages.js
+++ b/dist/vite-plugin-pages/pages.js
@@ -11,7 +11,7 @@ function getRoutesForEnvironment(routes, isPrerender) {
     if (route.prerender === isPrerender) {
       result.add(route);
     }
-    if (route.redirectRoute) {
+    if (route.redirectRoute && route.redirectRoute.prerender === isPrerender) {
       result.add(route.redirectRoute);
     }
   }

Link to Minimal Reproducible Example

(none)

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

• Reproduced: Yes — confirmed via unit-level logic test that getRoutesForEnvironment unconditionally adds prerendered redirect targets to the SSR route set.
• Exploration: Yes — View branch
• Unit Test: Yes — packages/astro/test/units/redirects/environment-filtering.test.ts
• Priority: P4: important. This affects any hybrid-mode project (output: 'static' + adapter) that uses config-level redirects pointing to prerendered pages. It can inflate SSR bundles by orders of magnitude (reporter saw 68MB vs ~1.4MB), which impacts deploy times and cold-start performance on serverless platforms.

The root cause is in getRoutesForEnvironment in packages/astro/src/vite-plugin-pages/pages.ts. When filtering routes for the SSR build environment, redirect routes unconditionally add their redirectRoute (the target page) to the result set without checking whether the target's prerender flag matches the current environment. This was introduced in commit cb95536ef6 ("fix: include redirectRoute in environment route filtering"), which correctly identified that redirect targets need to be reachable but missed the prerender boundary check. At SSR runtime, redirects are handled by renderRedirect which only uses route metadata (segments, pathname) — it never loads the target page's component, so including it in the SSR page map is unnecessary.

I found a potential fix for this issue. The fix adds && route.redirectRoute.prerender === isPrerender to the condition, ensuring redirect target routes are only included in the environment that matches their own prerender flag. All 65 existing redirect tests pass with this change.

Try this fix

You can test this fix right now without waiting for a release:

npm i https://pkg.pr.new/astro@d3fd50e

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Reproduction

Confirmed via logic-level unit test. The getRoutesForEnvironment function in packages/astro/src/vite-plugin-pages/pages.ts was called with a route set simulating hybrid mode:

• A prerendered page (static-target.astro, prerender: true)
• An SSR page (ssr-page.astro, prerender: false)
• A redirect route (prerender: false, redirectRoute pointing to static-target)

When called with isPrerender=false (SSR environment), the prerendered static-target.astro was incorrectly included in the result set because of the unconditional if (route.redirectRoute) check.

Diagnosis

The bug was introduced in commit cb95536ef6 ("fix: include redirectRoute in environment route filtering"). The intent was correct — redirect targets should be reachable — but the implementation unconditionally adds route.redirectRoute without checking its prerender flag.

Key observations:

1. renderRedirect (in packages/astro/src/core/redirects/render.ts) only uses redirectRoute for URL generation (segments, pathname). It never imports or renders the target page's component.
2. The redirect handler in the fetch pipeline (packages/astro/src/core/fetch/index.ts) returns early with a redirect Response before any component loading occurs.
3. The pageMap (which getRoutesForEnvironment feeds into) is specifically about loading page components — route metadata is available regardless.
4. The prerender environment correctly handles prerendered pages independently.

Fix

Changed the condition in getRoutesForEnvironment from:

if (route.redirectRoute) {

to:

if (route.redirectRoute && route.redirectRoute.prerender === isPrerender) {

Added 4 unit tests covering all combinations of redirect/target prerender flags. All 65 existing redirect tests continue to pass.

Files changed:

• packages/astro/src/vite-plugin-pages/pages.ts — Added prerender check to redirect target filtering, exported getRoutesForEnvironment for testability
• packages/astro/test/units/redirects/environment-filtering.test.ts — New unit test file with 4 test cases

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[spaceemotion]

Houston basically confirmed that the fix I already have applied as a local patch works. I just did another deployment, and we're actually smaller (990KB) and faster (by about 30 seconds in build time) than with Astro 5 now!

[astrobot-houston]

The fix has been verified! A pull request has been created: #17061