What is Pages Router (Next.js)?

What is Pages Router (Next.js)?

Pages Router is the original routing architecture in Next.js, available since the framework's initial release in 2016. It maps files inside the /pages directory directly to URL routes — pages/about.tsx becomes /about. Data fetching happens through exported functions like getStaticProps (static generation), getServerSideProps (server-side rendering), and getStaticPaths (dynamic route pre-rendering). Pages Router uses a _app.tsx wrapper for global layout and _document.tsx for custom HTML structure. Despite the introduction of App Router in Next.js 13.4 (May 2023), Pages Router remains fully supported in Next.js 15 and isn't deprecated. It's still the right choice for teams maintaining existing codebases or those who prefer a simpler mental model without React Server Components.

How it works

Pages Router uses a convention-over-configuration approach. Every .js, .jsx, .ts, or .tsx file in the /pages directory becomes a route:

pages/
  index.tsx        → /
  about.tsx        → /about
  blog/
    [slug].tsx     → /blog/:slug
    index.tsx      → /blog
  [...catchAll].tsx → matches any nested path

Each page component can export one async data-fetching function:

// pages/blog/[slug].tsx
export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);
  return { props: { post }, revalidate: 60 };
}

export async function getStaticPaths() {
  const slugs = await fetchAllSlugs();
  return {
    paths: slugs.map((slug) => ({ params: { slug } })),
    fallback: 'blocking',
  };
}

export default function BlogPost({ post }) {
  return <article>{post.title}</article>;
}

The revalidate: 60 enables Incremental Static Regeneration (ISR), which re-generates the page at most once every 60 seconds. This was a major innovation when shipped in Next.js 9.5 (July 2020).

API routes live in pages/api/ and map to serverless functions. pages/api/hello.ts becomes /api/hello. The request/response signature mirrors Node's http module, extended with helpers like res.json().

Global layouts wrap around _app.tsx, but nested layouts require manual composition — one of the key pain points that motivated App Router's design.

When to use it

Pages Router is far from dead. Here's when it makes sense:

Use Pages Router when:

• You have an existing Next.js project built before 13.4 and migration cost isn't justified
• Your team doesn't need React Server Components or streaming SSR
• You want the simplest possible mental model for data fetching
• You're building a marketing site or blog where getStaticProps + ISR covers 90% of needs
• Third-party libraries you depend on haven't adopted Server Components compatibility

Consider App Router instead when:

• You're starting a greenfield project in 2026
• You need nested layouts with independent data loading
• You want granular streaming and Suspense boundaries for large pages
• You're building a complex dashboard where partial rendering matters

We've shipped Pages Router on 50+ projects over the years. For content-heavy sites, it's still fast to build, predictable, and well-documented.

Pages Router vs alternatives

The honest take: App Router is more powerful, but Pages Router is more predictable. If your project doesn't need Server Components, Pages Router has fewer footguns.

Real-world example

We built a SaaS documentation site with 1,200+ pages using Pages Router and getStaticProps with ISR set to 120 seconds. Build time with static generation was around 3 minutes on Vercel's build infrastructure. Each page hit Lighthouse performance scores of 95-100 consistently because every page was pre-rendered at the edge. The content team pushes updates to a headless CMS (Sanity), and ISR picks up changes without a full rebuild. We considered migrating to App Router but the effort would've been 3-4 weeks of engineering time with no measurable user-facing improvement — so we didn't. That's the right call for most existing Pages Router projects.