Next.js App Router vs Pages Router: Which to Use in 2026

Honestly, the App Router Isn't for Every Project

Honestly, the App Router shipped with Next.js 13 and it's been three years of developers either loving it or quietly reverting to Pages Router on deadline night. That's not a knock on Vercel's engineering. It's just reality.

The App Router introduced React Server Components, nested layouts, the app/ directory, and a completely different mental model for data fetching. Big changes. And like any big change, it solved some real problems while creating a fresh batch of new ones.

So before you migrate a 60-page production app or start a greenfield project, let's actually look at what each router does well — and more importantly, where each one will make your life worse.

What Actually Changed: App Router Architecture in Next.js 14 and 15

The Pages Router works the way most React developers learned routing: a pages/ directory, file-based routing, getServerSideProps or getStaticProps for data, and a single _app.tsx wrapping everything. It's predictable. You know where things live.

The App Router flips the default. Every component in app/ is a Server Component unless you explicitly mark it 'use client'. Data fetching happens inside components with async/await directly — no more getServerSideProps. Layouts nest. Suspense boundaries are first-class. It's a fundamentally different composition model.

Next.js 15 hardened a lot of the rough edges. Caching became opt-in instead of opt-out (a huge change from 14), fetch no longer caches by default, and the use cache directive landed as an experimental API. If you're starting fresh today, you're working with a much more stable App Router than the one that launched.

React Server Components: The Real Reason to Switch

Server Components are the core reason to care about the App Router. They run on the server, have zero client-side JavaScript cost, and can directly access databases, file systems, or internal APIs without exposing credentials to the browser. That's genuinely useful.

Think about a dashboard that renders 40 rows from a database. With Pages Router you'd hit an API route, wait for JSON, ship it to the client, and hydrate. With Server Components you query Postgres directly in the component, render HTML on the server, and send nothing to the client bundle. The component just... doesn't exist in the browser.

There's a catch though. The 'use client' boundary is non-obvious when you first hit it. Pass a Server Component as a prop to a Client Component and you'll get confusing errors. Context providers — which are everywhere in most React apps — have to live in Client Components. Third-party libraries that assume a browser environment break silently. You'll spend real time debugging things that worked fine in Pages Router.

Caching in App Router vs Pages Router: A Concrete Comparison

Caching is where Pages Router wins on simplicity. You set revalidate in getStaticProps and it just works. ISR, full page cache, cache tags — it's a well-documented model that's been stable for years.

App Router caching in Next.js 15 is better than it was, but it still has four layers to reason about: the Request Memoization cache, the Data Cache, the Full Route Cache, and the Router Cache on the client. Each one has different invalidation rules. Getting them wrong means serving stale data in production while your logs show everything is fine.

Here's a minimal example showing the difference in data fetching patterns:

// Pages Router — getServerSideProps
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/products')
  const products = await res.json()
  return { props: { products }, revalidate: 60 }
}

export default function ProductsPage({ products }) {
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>
}

// App Router — Server Component with Next.js 15 opt-in caching
export default async function ProductsPage() {
  // No cache by default in Next.js 15+
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 60 }
  })
  const products = await res.json()
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>
}

The App Router version is less code. But the caching behavior is invisible until something goes wrong.

When Pages Router Is Still the Right Call

Pages Router isn't legacy code waiting to be deleted. Vercel has explicitly committed to supporting it long-term, and there are real scenarios where it's the better choice right now.

If you're maintaining a large existing app with hundreds of pages, a custom _document, complex middleware, and dozens of third-party packages that haven't tested App Router compatibility — migrating is a serious risk for unclear gain. The Pages Router works. It's fast. It handles ISR, SSR, and static pages just fine.

If your team has junior developers or you're working with developers who come from a non-React background, the Pages Router mental model is easier to transfer. getServerSideProps is straightforward. React Server Components require unlearning how React state and context work, and that takes real time.

And if you're choosing a UI framework for your React project, know that most component libraries still have smoother integration stories with the Pages Router. Empire UI components work in both, but 'use client' wrappers add friction when mixing interactive components with Server Components in nested layouts.

When App Router Is Clearly Worth It

New projects with a team that knows React well. That's the short version. App Router's benefits compound over time — nested layouts reduce duplication, Server Components shrink bundle sizes meaningfully, and Suspense lets you stream parts of the page independently.

Performance is measurable. A marketing page using Server Components with no client JavaScript for the above-the-fold content can load noticeably faster than the same page hydrated from a Pages Router build. If you care about Core Web Vitals — and you should for SEO — the App Router gives you more precise control over what JavaScript ships.

Parallel Routes and Intercepting Routes are genuinely novel. You can render a modal that has its own URL, shows on top of the current page, and falls back gracefully to a full page on direct navigation. That's hard to replicate cleanly in Pages Router. Same with independent loading states per route segment using loading.tsx.

If you're comparing Next.js against other frameworks before committing, take a look at how Next.js stacks up against Remix and Next.js vs Astro in 2026 — the routing philosophy differences matter a lot for which mental model fits your team.

Migrating from Pages Router to App Router: What It Actually Takes

You can run both routers simultaneously in the same Next.js app. Anything in pages/ uses Pages Router. Anything in app/ uses App Router. That's the migration path Vercel recommends — incremental, route by route.

In practice, the hard parts are: replacing getServerSideProps and getStaticProps, converting Context providers to 'use client' and moving them up the tree, auditing every third-party library for RSC compatibility, and rethinking any auth setup that relied on _middleware or cookie parsing in getServerSideProps.

Expect a route that takes two hours to migrate cleanly, and two more hours of debugging subtle rendering differences. For a 20-route app that's a sprint. For a 200-route app it's a quarter of work. Factor that honestly. And while you're at it, think about whether your theme toggle implementation will need updates — dark mode via CSS variables plays much nicer with App Router than solutions that relied on document manipulation inside getServerSideProps.

The Honest Verdict for 2026

App Router is the future of Next.js. That's not opinion — it's where Vercel is putting development effort. New features land in App Router first. If you're starting a project today that you expect to maintain for three or more years, you should probably start with App Router.

But 'should probably' isn't 'must'. Pages Router is stable, well-understood, and works with essentially every React package without friction. For small teams shipping fast, for agencies with tight deadlines, for apps where the complexity of Server Components would slow everyone down — Pages Router is a legitimate choice, not a compromise.

What's the actual decision criteria? Ask two questions. First: does your team have the bandwidth to learn RSC properly, including debugging boundaries and caching? Second: will your project actually benefit from streaming, nested layouts, or Server Component bundle reduction? If both answers are yes, go App Router. If either is no, stay on Pages Router until the answer changes.

And whichever router you pick, Empire UI components work with both — just remember to add 'use client' to any component that uses hooks, event handlers, or browser APIs when you're inside the App Router.

FAQ

Read next