Next.js App Router vs Pages Router: Why We Use App Router
App Router or Pages Router in 2026? Here is why we start every new Next.js project on App Router, what Next.js 16 changed, and the tradeoffs we accept.
Working through a similar problem? Tell us what you want to build.
Legacies is an independent digital product brand based in Bucharest, Romania, founded by Horia Stan and Alexandru Tălnaci, and for a few years now our starting point has been the same. Whether it is a one-page landing page or a full application, we start on Next.js with the App Router.
If you are choosing today, the short answer is App Router for anything new. It is the default in create-next-app, it is where every major Next.js feature lands, and since Next.js 16 its caching is far easier to reason about. Pages Router still works and is still patched, so existing apps do not need a panic migration.
Quick answer
- New project in 2026: use App Router. New features like Cache Components, Instant Navigations and root params are built for it.
- Existing Pages Router app that works: keep it, keep it patched, and migrate route by route when you touch those areas anyway.
- Biggest change since 2024: caching is now opt-in with
"use cache", so the confusing implicit caching of early App Router is gone. - Real tradeoff: a steeper learning curve around the server and client boundary, and a larger server surface to keep updated.
App Router vs Pages Router at a glance
Here is how the two compare for the kind of work we do: business sites that often grow into small applications.
| App Router | Pages Router | |
|---|---|---|
| Status | Default for new projects, gets new features | Supported, maintained, fewer new features |
| Rendering | React Server Components by default | Client components, data via getServerSideProps or getStaticProps |
| Layouts | Nested layout.tsx, shared UI stays mounted | _app and manual layout patterns |
| SEO | Built-in metadata export and generateMetadata | next/head per page |
| Mutations | Server Actions and Route Handlers | API routes |
| Caching | Opt-in with "use cache" and Cache Components | Static generation and ISR per page |
| Learning curve | Steeper | Gentler for developers used to classic React |
Both routers can live in the same project. That makes gradual migration realistic, which is the main reason we never tell clients to rewrite a working Pages Router app in one go.
Why we pick App Router for new products
One framework, every stage
A client starts with a presentation page. Six months later they want authentication, a dashboard, maybe an API for a partner. With App Router we do not switch stacks. We add routes. app/services/page.tsx and app/api/contact/route.ts live in the same project, with the same conventions.
That matters for budget as much as for code. A landing page can grow into a useful product without a forced rewrite. We can start with a clear public site, then add the small workflows a business actually needs as the work becomes more operational. If you are weighing that kind of path against site builders, our comparison of Wix vs WordPress vs a custom website covers when custom code is worth it.
Server Components cut client-side JavaScript
For content pages, like this blog, we render on the server. We read MDX files directly from the filesystem and send the browser only the HTML and CSS it needs. No separate CMS, no intermediary API for static content.
Less JavaScript in the browser usually means faster pages on mid-range phones, which is still how most people meet a small business online. It also means cleaner HTML for search engines and for the AI crawlers that now read business sites. We wrote about that shift in AI crawlers are changing what a business website is for.
Clear conventions, fewer decisions
Folder-based routing, layout.tsx for shared UI, a metadata export for titles and descriptions without extra libraries, loading.tsx and error.tsx for states that users actually see. The fewer infrastructure decisions we make per project, the more time is left for the part that matters: the product.
These conventions also help AI coding tools. Since Next.js 16.3, next dev writes a version-matched AGENTS.md block so coding agents read the docs that match your installed version. With predictable file conventions, agent output needs less correction.
What changed in Next.js 16
When we first wrote this post, the tradeoff section was mostly about caching confusion. A lot has changed since Next.js 16 shipped in October 2025.
Caching is explicit now
Early App Router cached aggressively and quietly. You would update data and wonder why the page did not change. Next.js 16 introduced Cache Components, built around the "use cache" directive. Caching is entirely opt-in. Dynamic code runs at request time by default, and you mark what should be cached.
This was the single biggest complaint we had, and it is largely fixed. Next.js 16.3 builds on it with Instant Navigations, which prefetch loading shells so server-rendered apps feel as responsive as single-page apps.
middleware.ts became proxy.ts
Next.js 16 renamed middleware.ts to proxy.ts. It runs on the Node.js runtime, and the old file is deprecated. The logic stays the same, but the name now says what it is: a network boundary. If you inherited an older project, this rename is one of the first things you will see in the upgrade guide.
Turbopack is the default bundler
Turbopack is now the default for development and production builds. In 16.3, dev server memory dropped by up to 90% on large apps and repeat builds can read from a disk cache. For a small studio that runs several projects side by side, that is noticeable every single day.
Edge runtime is on its way out
Route-level runtime = 'edge' is deprecated as of Next.js 16.3. Routes run on Node.js by default. We explain what that means for hosting decisions in most small sites do not need edge computing.
The tradeoffs we accept
App Router is not free. We think it is worth it, but here is what you sign up for.
A steeper learning curve
The split between Server Components and Client Components takes time to internalize. Where does state live? What can be imported where? Why does this component need "use client"? Once a team gets it, delivery speeds up. Until then, expect some friction.
A bigger server surface to maintain
This one is underrated. Server Components and Server Actions mean more code runs on your server, and that code is part of the attack surface. React2Shell, the critical remote code execution flaw from December 2025, affected App Router apps and not Pages Router apps, according to the official advisory. Several 2026 advisories also target Server Actions specifically.
That is not a reason to avoid App Router. It is a reason to treat updates as routine work. Our post on Next.js security patches as product maintenance has the patch routine we use.
Some libraries lag behind
Most popular React libraries work fine now, but a few still assume they run only in the browser. Usually the fix is wrapping them in a small client component. Occasionally it means picking a different library.
Should you migrate from Pages Router?
Our rule is simple: migrate when there is a reason, not because of a trend.
- Upgrade first, migrate secondGet your Pages Router app onto a supported, patched Next.js version. Security comes before architecture.
- Add new features in the app directoryBoth routers coexist. Build the next new section with App Router and let the team learn on fresh code.
- Move routes when you touch themWhen a page needs real work anyway, move it. Shared layouts and SEO metadata are often the first wins.
- Stop when the value stopsA stable Pages Router admin screen nobody touches can stay where it is for a long time.
How this shapes our client work
Every website and web app we build at Legacies starts on this foundation. A Website starts at 2,199 lei (about 415 EUR) and a custom Web App at 3,499 lei (about 665 EUR), both with a fixed quote within 48 hours. You can see the full list on our services page, or browse what we have built on our projects page.
Because the stack is the same across projects, handover is easier too. Another developer who knows modern Next.js can pick up the code without learning a custom setup first. If you are comparing studios, that is a question worth asking, and we listed more in how to choose a web design agency.
When to handle it yourself vs bring someone in
Handle it yourself if your team already ships React, you are starting fresh, and you can spend a week or two learning the server and client model on a small project first. The official docs are good, and the conventions reward patience.
Bring someone in if you need to ship a production app quickly, you are migrating a large Pages Router codebase with business logic in it, or nobody on the team owns upgrades and security releases. Getting the architecture right in the first month saves a lot of rework later.
Frequently Asked Questions
Should I use App Router or Pages Router in 2026?
For a new project, use App Router. It is the default in create-next-app, and new Next.js features like Cache Components, Instant Navigations and root params are built for it. Pages Router is still supported and patched, so an existing app that works does not need an urgent rewrite.
Is the Next.js Pages Router deprecated?
No. Pages Router is still supported in Next.js 16 and still receives security fixes. Most new features target App Router, though, so Pages Router is best seen as a stable option for existing apps rather than the starting point for new ones.
Is App Router good for SEO?
Yes. App Router renders on the server by default, which gives search engines and AI crawlers complete HTML. It also has a built-in metadata API for titles, descriptions, Open Graph images and canonical URLs, so you do not need an extra SEO library.
Can I use App Router and Pages Router in the same project?
Yes. Both routers can coexist in one Next.js project, with the app and pages directories side by side. That is the recommended way to migrate gradually: build new routes in App Router and move old ones when you are working on them anyway.
Is App Router caching still confusing?
Much less than before. Since Next.js 16, caching with Cache Components is opt-in through the use cache directive, and dynamic code runs at request time by default. The older implicit caching behavior that surprised many developers is no longer the model the framework is moving toward.
What replaced middleware in Next.js 16?
Next.js 16 replaced middleware.ts with proxy.ts. The logic stays the same, you rename the file and the exported function, and proxy runs on the Node.js runtime. The old middleware file still works for now but is deprecated.
Is Next.js App Router overkill for a small business website?
Not usually. A simple site built with App Router can be fully static and very fast, and it leaves room to add forms, logins or a dashboard later without changing frameworks. The main cost is that someone needs to keep the framework updated, which applies to any modern stack.