Next.js App Router vs Pages Router: Which Should You Use in 2026?

If you're starting a new Next.js project, the routing decision is usually straightforward: use the App Router.

But that does not mean the Pages Router is obsolete.

Next.js still supports both. The App Router is the newer architecture, built around React Server Components. The Pages Router is the original model and continues to receive maintenance.

The real question is not:

"Which router is better?"

It is:

"Which router makes sense for this project, this team, and this year?"

This guide compares both approaches, explains what actually changes in practice, and gives you a migration path that does not put a working product at risk.

Quick answer

For most new applications in 2026, choose the App Router.

Choose the App Router if you:

• Are starting a new project
• Want Server Components and streaming
• Need nested layouts that survive navigation
• Are building a SaaS, dashboard, or content site
• Want to follow current Next.js documentation

Keep the Pages Router when:

• You have a stable production application
• Migration provides little business value
• Your team knows the existing codebase well
• A rewrite would compete with revenue work
• The app depends on libraries that still assume the Pages Router

The principle is simple: do not migrate because a newer architecture exists. Migrate when the new architecture solves a problem you actually have.

App Router vs Pages Router at a glance

| Area | App Router | Pages Router | |---|---|---| | Directory | app/ | pages/ | | Default rendering | Server Components | Client-side React | | Layouts | Built into routing | Manual or _app.tsx | | Data fetching | async Server Components | getServerSideProps, getStaticProps | | API endpoints | Route Handlers (route.ts) | API Routes (pages/api) | | Loading states | loading.tsx and Suspense | Manual state | | Metadata | generateMetadata | next/head | | New projects | Recommended | Usually not the first choice | | Existing projects | Can adopt gradually | No migration required |

Both are file-system routers. The difference is what happens around the file.

What the App Router actually changes

Server Components by default

In the App Router, a component is a Server Component unless you add "use client". That means it can read from a database, call an internal function, or format data without shipping that logic to the browser.

This is the biggest architectural shift. It is also where most migration mistakes happen. Developers move a file into app/, forget that it now runs on the server, and then wonder why useState or window throws an error.

A useful rule: keep data access on the server, and push interactivity to the smallest possible client boundary. Do not mark a whole page as a client component because one button needs a click handler.

Nested layouts

A layout in app/dashboard/layout.tsx wraps every route below it and does not re-render on navigation. For dashboards, documentation, and multi-step products, this removes a lot of duplicated shell code.

The Pages Router can achieve something similar with _app.tsx and component composition, but the App Router makes it part of the routing model.

Streaming and Suspense

The App Router can stream HTML as data resolves. A slow section can show a fallback while the rest of the page is already interactive.

That is an improvement for real products, but it is not free. You need meaningful loading states. A spinner that appears for 80 milliseconds is worse than no spinner at all.

Metadata colocated with routes

generateMetadata replaces most next/head usage. Metadata can read the same params as the page, which makes dynamic SEO pages less fragile.

What the Pages Router still does well

The Pages Router is not a legacy trap. It is a mature model with predictable behavior.

It is still a reasonable choice when:

• The application is stable and profitable
• The team is small and the roadmap is full
• Most pages are client-heavy by nature
• Third-party integrations assume the Pages Router
• You need a low-risk year, not a rewrite

A working Pages Router application is not technical debt. An unnecessary migration is.

How to migrate without breaking production

If you decide to migrate, do it incrementally. Next.js allows both routers to coexist, which means you can ship value while you move.

1. Create the app/ directory

Start with one route. Do not move the whole application in a single branch.

2. Move the simplest page first

Pick a static page with no complex data fetching. A legal page or an about page is a good test. Confirm routing, metadata, and styling before touching the homepage.

3. Convert data fetching

Replace getStaticProps with a Server Component that fetches directly, or with generateStaticParams for dynamic routes.

Replace getServerSideProps with a Server Component that reads the request through the appropriate Next.js APIs. Do not copy the old function and hope it works.

4. Replace next/head with generateMetadata

Metadata should be generated from the same source of truth as the page content. If you hardcode titles in two places, they will drift.

5. Add "use client" deliberately

Move the boundary down, not up. A page should stay a Server Component while a small form or menu becomes a Client Component.

6. Handle loading and error states

Add loading.tsx and error.tsx where the route needs them. Test with a throttled connection, not just on localhost.

7. Keep the old route until the new one is verified

Redirect only after the replacement is live, indexed, and passing the same checks. A broken redirect is worse than a slow migration.

8. Run the same quality gates

Type checking, linting, tests, and a production build should pass before and after. If your test suite only covers utilities, add at least one smoke test for the migrated route.

Common migration pitfalls

• Using hooks in a Server Component. Add "use client" at the smallest interactive boundary.
• Reading window during render. Browser APIs belong in effects or client components.
• Forgetting generateStaticParams. Dynamic routes need to know which paths to build.
• Duplicating layouts. Move shared shells into layout.tsx instead of importing them into every page.
• Ignoring caching. The App Router has different defaults. Verify that data is fresh when it needs to be.
• Migrating during a launch week. Sequence the work around revenue, not around excitement.

When migration is not worth it

Do not migrate if:

• The current application has no performance or maintenance problem
• You cannot describe the user-facing benefit in one sentence
• The migration would take more than a month of focused work
• You have no tests and no staging environment
• The team would be learning the router while shipping a critical release

A migration is an investment. Treat it like one.

A pragmatic decision rule

Use this sequence:

1. New project? App Router.
2. Stable project with a full roadmap? Stay on the Pages Router.
3. Stable project that needs nested layouts, streaming, or Server Components? Migrate one route at a time.
4. Project with no tests? Add a smoke test before you move anything.

The router is a tool, not an identity. The goal is software that ships, stays maintainable, and does not wake you up at night.

If you are still building your fundamentals, the migration will teach you more than any tutorial: routing, rendering, data flow, and caching all become concrete. Pair it with a real debugging practice and a project you actually ship. And if you want a head start on the frontend, the website templates in the store are built on the same App Router model.

Final thoughts

The App Router is the right default for new work. The Pages Router remains a valid home for applications that already work.

Migrate for a reason you can measure, in slices you can review, with tests that tell you when you broke something.

That is true for routers, and for most technical decisions.