Navigating the Next.js App Router’s aggressive caching mechanism can be incredibly frustrating when a simple URL parameter triggers full dynamic rendering. Here is how to keep your pages statically cached while still using searchParams for minor UI text updates.

Next.js App Router: Caching Static Pages with searchParams (Without Losing Your Mind)

I remember the exact moment my team at TechResolve nearly rolled back a massive Next.js 14 migration. We had a gorgeous, perfectly static landing page serving from our edge nodes in about 12ms. Then, marketing asked for a tiny change: they wanted to read a ?ref=twitter parameter to display “Welcome Twitter fam!” instead of the default “Welcome!”. A well-meaning junior dev added searchParams to the main Server Component, merged the pull request, and suddenly our edge cache hit rate tanked to zero. CPU spikes triggered alarms on prod-next-web-01 and prod-next-web-02, and our 12ms response time ballooned to 850ms during a traffic surge. All because Next.js saw that one parameter and silently nuked our static caching.

If you are reading this, you are probably in the same boat. You have a static page, you need a tiny piece of dynamic text from the URL, and you do not want to sacrifice your caching to get it. Let us fix it.

The “Why”: The Silent Dynamic Opt-In

Before we patch the leak, you need to understand why the ship is sinking. The root cause is Next.js’s underlying rendering philosophy for the App Router. The moment you access searchParams in a Server Component, Next.js makes a hard assumption: “I cannot cache this at build time because I have absolutely no idea what the user will put in the URL query.”

Because it cannot predict the query string, it aggressively opts the entire route out of Static Rendering and falls back to Dynamic Rendering. It makes sense logically on a framework level, but it is brutal when 99% of your page is heavy static marketing material and only a single <span> tag needs to change.

Pro Tip from the Trenches: Next.js does not care if you only use the query parameter for a single word on the page. Server-side searchParams is a binary switch. Once flipped, the whole page becomes dynamic.

Solution 1: The Quick Fix (The Client-Side Escape Hatch)

If you need to get this fixed before your next stand-up, this is the way. We simply stop asking the Server Component to read the query parameters and offload that tiny job to the client browser.

By keeping your main page as a Server Component (without mentioning searchParams) and isolating the dynamic text in a Client Component, your page remains completely static at build time.

"use client";

import { useSearchParams } from 'next/navigation';

export default function GreetingText() {
  const searchParams = useSearchParams();
  const source = searchParams.get('ref');

  if (source === 'twitter') {
    return <span>Welcome Twitter fam!</span>;
  }
  
  return <span>Welcome!</span>;
}

Now, just drop <GreetingText /> into your static Server Component. Next.js will cache the HTML, and the client will fill in the blank. Warning: Remember to wrap this component in a <Suspense> boundary in your server component, otherwise Next.js might still de-opt the page during the build!

Solution 2: The Permanent Fix (Static Route Segments)

The Quick Fix is great, but relying on client-side JavaScript for text rendering can cause layout shift or SEO issues if search engines care about that specific text. The “correct” architectural fix is to stop using query parameters for known variables and use Dynamic Route Segments instead.

If marketing only has a set list of referral partners (Twitter, LinkedIn, Facebook), change your URL strategy from /landing?ref=twitter to /landing/twitter. Then, use generateStaticParams.

// app/landing/[source]/page.tsx

export function generateStaticParams() {
  return [
    { source: 'twitter' },
    { source: 'linkedin' },
    { source: 'facebook' },
  ];
}

export default function LandingPage({ params }: { params: { source: string } }) {
  // This page is 100% statically cached at build time!
  return (
    <div>
      <h1>Welcome {params.source} users!</h1>
      <p>The rest of this heavy static content loads instantly.</p>
    </div>
  );
}

This is my preferred method. It satisfies the cache gods, keeps response times at 10ms, and requires zero client-side JavaScript.

Solution 3: The ‘Nuclear’ Option (Middleware Rewrite Hack)

Sometimes you cannot change the URLs. External ads are already running, the business refuses to change the ?ref= structure, and you absolutely cannot use client-side rendering due to strict Core Web Vitals targets. This is where we get a little hacky.

We use Next.js Middleware to intercept the incoming request at the Edge, strip the query parameter, and rewrite the request to a hidden static route under the hood.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const url = request.nextUrl.clone();
  const ref = url.searchParams.get('ref');

  // If the query param exists, rewrite to our pre-rendered static paths
  if (url.pathname === '/landing' && ref) {
    // Hide the query param from the Next.js server component entirely
    url.searchParams.delete('ref');
    // Secretly route them to the static segment we built in Solution 2
    return NextResponse.rewrite(new URL(`/landing/${ref}`, request.url));
  }

  return NextResponse.next();
}

This is a bit of a dark art. The user’s browser still shows /landing?ref=twitter, but your Next.js server treats it as a request for the highly-cached, static /landing/twitter page. We actually deployed this on prod-next-web-01 last quarter to bypass a rigid legacy marketing system, and it saved our infrastructure.

Which One Should You Choose?

I always tell my juniors to evaluate the trade-offs. Here is my mental cheat sheet:

Stop letting Next.js bully you into dynamic rendering. Take control of your caching strategy, wrap those client components in Suspense, and keep your servers sleeping peacefully!

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions