The root loading.tsx that turned every redirect into a 200

Last week, our SEO consolidation shipped in code and did nothing on the wire. /faq/draft-work should have 308'd to /tools/draft-work#faq-…. Instead it returned a normal 200 OK and rendered the FAQ page as usual. Same story for notFound() on invalid slugs — Google was seeing 200 on a soft-404 page instead of a real 404. The redirect logic was correct. The response header was lying.

The problem

Linkgo (linkgo.dev) is a Next.js 15 app. As part of an organic-search recovery, we'd merged code that permanently redirects zero-demand FAQ pages onto their parent tool page, so the whole <details> block renders there as a canonical anchor. About 497 URLs were queued up for that redirect. In dev, the redirect worked. In prod, it didn't. Curl was blunt:

$ curl -sSI https://linkgo.dev/faq/draft-work
HTTP/2 200
content-type: text/html

permanentRedirect('/tools/draft-work#faq-draft-work') sits at the top of app/faq/[slug]/page.tsx, above any data fetch. There is no way that code returns 200 by design. But it did — every time, deterministically. notFound() had the same problem: invalid slugs also came back as 200 with a rendered FAQ shell, which Google Search Console had been quietly labeling as soft-404 for weeks.

Why it happened

Next.js redirect(), permanentRedirect(), and notFound() all work by throwing a special error object that the framework catches and translates into an HTTP status. That translation is a header write. Once headers have been committed to the wire, nothing downstream can change them — a thrown redirect after commit is silently no-op-ed to a 200 body.

We had, at the root of the app, this file:

// app/loading.tsx
export default function RootLoading() {
  return <GlobalNavSkeleton />
}

A file called loading.tsx at the root of a Next app/ tree wraps every route in a Suspense boundary. That boundary streams the loading fallback down to the browser as soon as the request is received. For any route marked force-dynamic — which our FAQ and tool pages are, because they read fresh data — the fallback goes out with 200 OK on the very first byte, before the route handler has had a chance to run. By the time permanentRedirect(...) throws further down, the response is already 200-committed. Next has nowhere to put the 308.

The subtlety is that this is not documented as a caveat of loading.tsx. It's a downstream consequence of streaming Suspense boundaries meeting force-dynamic pages meeting redirect/notFound semantics. Locally, on hot-reload, timing sometimes hides it. Under prod load, it's 100%.

What we tried first

We spent a day looking at the wrong things. The redirect predicate was audit-logged, so we knew it was firing. Next up we suspected middleware — nothing there. Then a stale route cache — nope. Then dynamic segment collision — no. We even tried redirect() vs. permanentRedirect() under a temp diagnostic branch just to see if the 307/308 distinction mattered. It did not. Both returned 200.

The turning point was building a fresh create-next-app (Next 15.5.19, our exact version) and porting exactly one file at a time into the empty app until the redirect broke. Bisection took about twenty minutes. The offender was app/loading.tsx. Add it back — 200. Delete it — 307. That was the entire signal.

The fix

- // app/loading.tsx
- export default function RootLoading() {
-   return <GlobalNavSkeleton />
- }
+ (file removed)

One deletion. The moment the file was gone in a preview deploy:

• /faq/draft-work returned 308 Permanent Redirect to /tools/draft-work#faq-draft-work.
• Invalid slugs returned 404 Not Found.
• The 497 queued consolidation redirects went live on the next deploy.
• Sitewide soft-404 impressions in Search Console started decaying within a few days.

The trade-off was real. The root loading.tsx was there for a reason — a global skeleton that appeared during any client navigation. Deleting it means the initial-nav loading affordance is gone. Our answer was to be surgical: add loading.tsx back only in route segments that never call redirect(), permanentRedirect(), or notFound(). Marketing pages, the homepage, static docs — fine. Anything under /faq/[slug], /tools/[slug], /category/[slug], or any dynamic segment that might redirect — leave it alone.

Before and after

Verification was mundane: a spreadsheet of ~50 slugs, curl each one, confirm the status. /faq/draft-work → 308, /faq/definitely-not-a-real-thing → 404, /tools/draft-work → 200, all rendering correctly with the merged FAQ block SSR'd into the page.

What we learned

Three things, in decreasing order of transferability.

• Streaming boundaries and force-dynamic pages compose badly with redirect(). Any Suspense boundary that streams to the wire before the wrapped route runs will hard-cap the response at 200. If you're in a Next.js app that uses force-dynamic on segments that also throw redirects, audit every loading.tsx above them.
• Trust curl over trust the framework. For weeks the redirect predicate showed up cleanly in application logs. The audit said "redirect fired". The HTTP response header said "200". When a log and a header disagree, the header wins — that's what the internet actually sees.
• Bisect against a fresh scaffold. When a bug is deterministic in your app and impossible in a demo, the fastest path is to reconstruct the demo one file at a time. Not the fun way to spend an afternoon, but it converts "I don't know" into "I know exactly which file" in a bounded number of steps.

What's next

The fix unblocks the FAQ → tool-page consolidation, but it doesn't solve the underlying reason we had 4,000+ thin FAQ pages to consolidate in the first place. That's a separate lever — a demand-based indexability gate that only surfaces FAQs with demonstrated search demand, with a grace window for new ones. That work shipped alongside this fix and is worth its own post; the short version is that reversibility (noindex,follow, never 410) matters more than we initially thought when Google is doing the demoting rather than the crawling.

We're also adding a loading.tsx linter check to CI: if the file appears above any segment that calls redirect/permanentRedirect/notFound, fail the build. Cheaper than another twenty-minute bisection.

---

Try Linkgo

Linkgo is a curated directory of AI tools, agents, MCPs, and models — browse the catalog at linkgo.dev.

Website