Next.js App Router versus Pages Router for a new project in 2026

Starting a new Next.js project in 2026? Use the App Router. That's the framework's own default recommendation, and it's where new capability, from Server Components to the current data fetching model, keeps landing first. The Pages Router still works, and Next.js has committed to supporting it. But it's no longer the router you reach for on day one.

What it is and why it matters

The App Router and the Pages Router are two different file-system routing conventions inside the same framework. The Pages Router, the original model, maps a file in pages/ to a route and renders components on the client by default, using data functions like getServerSideProps and getStaticProps. The App Router arrived in Next.js 13. It uses an app/ directory with page.js and layout.js conventions, and its pages are Server Components by default, meaning they can fetch data and render on the server before anything reaches the browser.

Next.js's migration documentation puts it plainly: the App Router is the default for new applications, because it gives you React's current feature set, Server Components, streaming and Suspense, that the Pages Router was never built around. At the same time, the same guide is explicit that pages/ development keeps getting bug fixes and security patches for multiple major versions, so an existing Pages Router app isn't at risk of being abandoned. That commitment matters if you're weighing a rebuild against a fresh, greenfield start.

The two routers also structure shared UI differently. The Pages Router centralizes global layout and document setup in pages/_app.js and pages/_document.js, files that apply to every route whether a given page needs them or not. The App Router replaces both with a single app/layout.js root layout, and layouts nest per route segment, so a dashboard section can define its own layout without touching the marketing pages sitting right beside it. For a new project, that nesting removes a category of shared-file merge conflicts Pages Router teams learn to work around rather than a limitation they choose on purpose.

How it works in practice

The core mechanical difference is the split between Server Components and Client Components. A Server Component fetches data close to the source, keeps API keys and tokens off the client, and reduces the JavaScript shipped to the browser, which helps first contentful paint. A Client Component, marked with the 'use client' directive, is what you reach for when you need state, event handlers, or a browser-only API like localStorage. The official guidance is to mark only the specific interactive piece, a search box, a like button, rather than an entire layout. Once a file carries 'use client', everything it imports and renders directly joins the client bundle.

Data fetching changes with it. getServerSideProps, getStaticProps, and getStaticPaths are gone from the App Router. In their place, an async Server Component calls fetch() directly, with cache options standing in for what used to be separate functions, and generateStaticParams replaces getStaticPaths for pre-rendering dynamic routes. Teams doing this migration alongside a technical SEO pass usually find routing choice and crawlability show up in the same audit. Our own technical SEO audit checklist for Next.js sites covers the rendering and indexing side of that work in more detail.

Tradeoffs and edge cases

The App Router isn't a free upgrade, and knowing where it bites matters more than knowing that it exists. The first surprise most teams hit is caching. Route Handlers in the App Router are statically cached by default, unlike Pages Router API routes, which stay dynamic unless you tell them otherwise. A Server Action that writes to a database won't update what users see until you explicitly call revalidatePath(). Forgetting that step is a common source of "my update isn't showing" bug reports.

Caching semantics have also moved release to release. As of Next.js 15, GET Route Handlers and the Client Router Cache switched from cached by default to uncached by default, after developer feedback that the earlier defaults caused confusion. Next.js 16 still routes fetch() and unstable_cache() calls through a separate Data Cache layer. If your team is used to the Pages Router's more implicit, version-stable caching model, budget time to read the current docs rather than carrying assumptions forward from an older tutorial.

There's also a real cost to mixing both routers in one app during an incremental migration, something Next.js supports and documents. Navigating between a route served by pages/ and one served by app/ triggers a hard, full-page navigation, and next/link prefetching doesn't cross that boundary. So the fast client-side transitions you expect inside one router don't carry over to the other. For a genuinely new project with no legacy pages/ code to preserve, none of that applies, which is the strongest case for starting on the App Router rather than migrating into it later.

None of this changes the calculus for a team with a large, working Pages Router codebase and no near-term need for streaming or Server Components. Rewriting a stable application just to chase a router is rarely worth the disruption on its own. The App Router earns its keep on new builds and on pages where the caching and bundle-size wins are worth the learning curve. A useful test: if you can name a concrete feature you want, partial prerendering, nested layouts, less client JavaScript on a slow page, the App Router is worth the ramp-up. If the answer is only that it's what the docs recommend, a stable Pages Router app can keep shipping as is.

For a new Next.js project in 2026, the App Router is the right default: it's where the framework's current features and ongoing investment live, and Next.js says so directly in its own docs. The one habit worth carrying into either router: caching semantics keep shifting release to release, so check the documentation's own last-updated date before you ship, not a two-year-old blog post. When we scope a new Next.js build at Kallos Labs, this is one of the first architectural decisions we walk through with a client, alongside our web development work.

Frequently asked questions

Should a new Next.js project in 2026 use the App Router or the Pages Router?

Use the App Router. Next.js's own documentation recommends it as the default for new projects because it gives access to Server Components, streaming, and the current data fetching model, and new framework investment lands there first.

Is the Pages Router deprecated?

No. Next.js has committed to supporting pages/ with bug fixes and security patches for multiple major versions, so existing Pages Router apps aren't at risk. They simply aren't where new capability arrives.

Can a project mix the App Router and Pages Router?

Yes, incrementally, and Next.js documents this as the supported migration path. The tradeoff is a hard, full-page navigation whenever a user crosses between a pages/ route and an app/ route, since next/link prefetching doesn't cross that boundary.

What is the biggest gotcha teams hit moving to the App Router?

Caching defaults. App Router Route Handlers are statically cached by default unlike Pages Router API routes, and Server Action mutations need an explicit revalidatePath call or the interface keeps showing stale data. Both are surprises for teams used to the Pages Router's more implicit model. The Pages Router isn't going away and remains a reasonable, low-risk choice for teams maintaining a large existing app, but it isn't the starting point for something new.