Why do my new pages return 404 at the origin but 200 in the browser?

Your CDN may be serving a cached copy while the origin has stopped rendering the page. On one site, 41 new pages answered 404 at the origin after a sign out expired the cache, because the route was set never to render pages on demand, while the CDN kept serving stored 200 copies. Test the origin directly.

What does dynamicParams false do in Next.js?

It tells the route to serve only pages built in advance and never render a new one on demand. If something expires those cached pages, for example an action that revalidates the root layout, the route answers its 404 page even though the files exist. Remove the setting or stop the broad revalidation.

How should I test a deploy behind a CDN?

Request new pages from the origin directly as well as through the public address. A cached 200 at the edge can hide a 404 at the origin that crawlers and live assistant fetches will meet once the copy expires. Check a day of status codes for new pages after launch.

The Pages That Only Existed at the Edge

¶ WAR STORYTHE SYMPTOM

01Fine in the browser, broken underneath

On 30 October I shipped 41 example pages to a CV product. They looked right in the browser, so I moved on. A few hours later the server log said something else: the same addresses were answering 404 to a growing share of requests. Not all of them, and not to me, because I was being served the copy the content delivery network had stored after the first visit. Behind that copy, at the origin, the pages had stopped existing. If you only test through your CDN, you are testing the copy, not the site.

A sign out, then silence

Lining up the log against everything else that happened on the site, one event preceded the failures every time: a user pressing sign out. At 12:09:55 a sign out request, at 12:10:01 the first 404. The same pattern at 13:53:53, with 404s from 13:54:18. The sign out action told the framework that every cached page on the site was stale, a blunt instruction that had been harmless for months, because a stale page normally just gets rebuilt on the next request.

// HOW 41 PAGES VANISHED AT THE ORIGIN~~30 OCT 2026 · UTC~~

SHIPPED

41 new pages, one extra settingThe route was told never to render a page it had not built in advance.

12:09:55

Someone signs outThe sign out action tells the framework that every cached page is stale.

12:10:01

First 404 at the originThe page cannot be rebuilt on demand, so the server answers its 404 page, marked as a cache hit.

ALL DAY

The public address still worksThe content delivery network keeps serving its stored 200 copy to most visitors.

13:53:53

It happens againAnother sign out, another wave of 404s from 13:54:18. Now it is a pattern, not a fluke.

FIX

One line removed, then narrowedExpired pages render again on demand; sign out now only expires account pages. 41 of 41 answer 200.

The pages were fine on disk the whole time. The server simply refused to look for them.

¶ WAR STORYTHE CAUSE

02One setting that said never

Built in advance, never on demand

The new route was the only one on the site carrying a setting that tells the framework: only serve the pages you built in advance, never render one on demand. Once the sign out expired its cached copies, the framework went to rebuild them on demand, met that setting, threw an internal error and answered with the prebuilt 404 page instead. The HTML files were sitting on disk the whole time. A page can be present on disk, correct in the browser and missing for every crawler that misses the cache.

Who sees the hole

People mostly did not, because the network kept serving the stored 200 copy. The visitors who see the hole are the ones that bypass or outlast the cache: a crawler arriving after the edge copy expired, an assistant fetching the page live, anyone hitting a region with no stored copy yet. Those are exactly the readers a new page is built for. A page that answers 404 to Googlebot during its first week is a page that may not get a second visit soon. It is the inverse of what I wrote in the cache that hid my crawlers: there the cache hid real visitors from my log, here it hid a broken origin from me. A cache is a curtain, and it hides problems in both directions.

EXTRACTED — THE SENTENCE THIS ENTRY EXISTS FOR

Check the origin, not only the copy.

¶ WAR STORYTHE FIX AND THE RULE

03Fix the setting, then narrow the trigger

Two changes, in that order

First, the setting came out, so an expired page renders again on demand while unknown addresses still return a proper 404. Then the sign out action was narrowed to expire only account and admin pages, the only places it needs to touch. The test afterwards was the honest one: sign in with a throwaway account, sign out, and check that public pages stayed cached and all 41 new pages answered 200 from the origin. They did. Fix the thing that broke, then fix the thing that made it break, or you will meet it again on the next route.

The checks I now run after every deploy

Request new pages directly from the origin, bypassing the network, not only through the public address. Search the application error log for the specific internal error after any deploy that touches routing. And look at a full day of status codes for new pages a day after launch, because some failures only start when a user does something ordinary, like signing out. The purge story in the purge that broke half the fetches was a network failing in front of a healthy server. This was a healthy network in front of a failing server. Both were invisible from a browser.

If Search Console reports a burst of 404s on pages you know exist, check the origin before you dismiss it as noise; the triage in GSC says page with redirect separates the alarms that matter from the ones that do not.

Tomorrow: why I now write down every Search Console error the day I fix it.