App Router vs Pages Router no Next.js: como decidir em 2026

Next.js é um framework JavaScript usado para construir sites, lojas virtuais e painéis administrativos. Foi criado pela empresa Vercel em 2016 e, ao longo dos anos, virou uma das ferramentas mais usadas do mercado para projetos em React, a biblioteca de interface criada pelo Facebook, hoje Meta. Quem usa WordPress costuma pensar nele como um sistema de montar páginas com blocos. Já o Next.js é uma forma de programar a estrutura do site usando componentes, que são blocos reutilizáveis de interface, escrito em JavaScript ou TypeScript.

Em 2023, a Vercel anunciou uma atualização estrutural no Next.js conhecida como App Router. Antes disso, todo mundo que criava projetos com Next.js usava o que passou a ser chamado de Pages Router, o modelo tradicional. Hoje, quando alguém inicia um projeto novo, precisa escolher entre os dois. Esta escolha impacta diretamente a forma como o site é organizado, como ele carrega e até quanto vai custar manter.

A coexistência dos dois modelos acontece porque a Vercel decidiu não quebrar os projetos já existentes. Quem começou a usar Next.js antes de 2023 consegue manter o Pages Router nas suas aplicações mesmo com as versões mais recentes do framework. Quem começa agora pode adotar o App Router, mas ainda tem a opção de usar o modelo antigo, dependendo do que faz mais sentido para aquele caso específico.

Este artigo explica, em linguagem acessível, o que cada roteador faz, quais são as diferenças de verdade entre eles e quando cada um faz mais sentido para o seu projeto.

O que é o Next.js e por que ele tem dois roteadores

O Next.js é uma camada em cima do React. Quando alguém usa React puro, precisa resolver manualmente várias tarefas: dividir o código em arquivos, escolher como as páginas vão aparecer na URL, decidir se o site gera HTML no servidor ou no navegador e configurar a forma de carregar dados externos. O Next.js resolve essas decisões com convenções prontas, o que reduz bastante a complexidade de começar um projeto.

Essas decisões, porém, podem ser tomadas de formas diferentes. Por isso o framework passou a oferecer dois roteadores com abordagens distintas. O Pages Router é a forma clássica, com um modelo mental mais próximo de quem vem do WordPress ou do desenvolvimento tradicional. O App Router é a evolução, pensada para entregar páginas mais rápidas e organizadas por padrão.

Segundo a documentação oficial do Next.js (nextjs.org/docs), manter dois modelos ao mesmo tempo permite que a comunidade migre no próprio ritmo. Quem mantém projetos antigos não é forçado a reescrever tudo de uma vez. Quem começa agora tem acesso à tecnologia mais recente.

Pages Router: como o modelo antigo funciona

O Pages Router foi o jeito padrão de trabalhar com Next.js entre 2016 e 2023. Ele ainda existe, recebe manutenção e tem uma quantidade enorme de material publicado, fóruns, cursos e bibliotecas prontas.

Estrutura de pastas tradicional

No Pages Router, todo arquivo JavaScript ou TypeScript colocado dentro de uma pasta chamada pages/ vira automaticamente uma rota do site. Um arquivo pages/sobre.js gera a página seusite.com/sobre. Um arquivo pages/contato.js vira seusite.com/contato. A lógica é direta e fácil de visualizar para quem está começando.

Para criar rotas dinâmicas, parâmetros na URL que mudam de valor a cada acesso, como /produtos/camiseta-azul, o Pages Router usa arquivos com colchetes no nome, por exemplo pages/produtos/[slug].js. É um padrão simples de aprender e funciona bem em projetos pequenos e médios.

Como o Pages Router carrega dados

Existem três funções principais para carregar dados no Pages Router:

• getStaticProps: o conteúdo é gerado uma vez.
• no momento do build.
• e fica pronto para qualquer visitante. É indicado para páginas que mudam pouco.
• como páginas institucionais.
• getServerSideProps: o conteúdo é montado a cada requisição do visitante.
• no servidor. É útil quando a página precisa mostrar dados atualizados em tempo real.
• getStaticPaths: usado junto com rotas dinâmicas. Define quais combinações de parâmetros devem ser geradas no build e quais devem ser geradas sob demanda.

Esse modelo atende bem à maioria dos sites, mas tem um limite: tudo acontece no nível da página inteira. Se uma parte da página depende de dados e outra parte não, é preciso carregar as duas juntas.

Pontos fortes do Pages Router

Curva de aprendizado mais curta, ideal para quem está migrando de WordPress, Wix ou Webflow. Ampla documentação, farta literatura, muitos exemplos prontos no GitHub e cursos em português. Funciona bem com a maioria das bibliotecas de interface prontas para React. Compatível com integrações externas já testadas, como CMS headless (Strapi, Contentful, Sanity), gateways de pagamento e ERPs.

Limitações conhecidas

Não tem suporte nativo a layouts compartilhados entre rotas, sendo preciso usar padrões como _app.js e arquivos de layout manuais. Streaming e Suspense, recursos para entregar a página aos poucos, sem esperar tudo ficar pronto, não estão disponíveis da mesma forma que no App Router. Server Components não existem nesse modelo. Tudo é renderizado no cliente ou de forma tradicional no servidor, sem a flexibilidade que veio depois. Segundo a própria Vercel, o foco de novas funcionalidades e melhorias de performance está no App Router. O Pages Router segue funcionando, mas deixa de receber novidades mais profundas.

App Router: como o modelo novo funciona

O App Router foi apresentado oficialmente com o Next.js 13.4 em maio de 2023 e virou o padrão recomendado a partir do Next.js 14. Ele reorganiza a forma como a aplicação é construída, especialmente pensando em performance, modularidade e flexibilidade no servidor.

Estrutura de pastas baseada em rotas de arquivo

No App Router, em vez de uma pasta pages/, existe uma pasta chamada app/. Dentro dela, cada rota é representada por uma pasta, e dentro dessa pasta fica um arquivo chamado page.js ou page.tsx. Por exemplo, a pasta app/blog/page.tsx representa a rota /blog.

Para rotas dininhadas, o padrão continua sendo colchetes: app/blog/[slug]/page.tsx gera rotas como /blog/meu-artigo. Para gerar rotas estáticas em build, chamadas SSG, usam-se colchetes duplos com generateStaticParams. Rotas aninhadas, como /blog/tags/marketing, viram pastas aninhadas com seu próprio page.tsx.

Server Components e Client Components

A maior mudança do App Router é o conceito de Server Components. Por padrão, todo componente é renderizado no servidor, o que reduz a quantidade de JavaScript enviada para o navegador do visitante. Isso tende a melhorar o tempo de carregamento e o desempenho em dispositivos mais modestos.

Quando uma parte da interface precisa de interatividade no navegador, marca-se esse pedaço com a diretiva "use client" no topo do arquivo. Esse pedaço vira um Client Component e roda no navegador do visitante, como sempre foi no React tradicional.

Esse modelo permite misturar os dois tipos no mesmo projeto. Uma página pode ter o cabeçalho e o rodapé renderizados no servidor, e o carrinho de compras funcionando como Client Component, com JavaScript entregue só para a parte que precisa.

Streaming, Suspense e carregamento parcial

Outra característica do App Router é o uso de streaming. Em vez de esperar todos os dados estarem prontos para entregar a página inteira, o servidor pode enviar partes prontas enquanto outras ainda estão sendo processadas. O componente React chamado Suspense define quais áreas devem mostrar um indicador de carregamento até que os dados cheguem.

Esse comportamento reduz o tempo até o visitante ver a primeira informação na tela, métrica conhecida como First Contentful Paint, e melhora a experiência em conexões mais lentas.

Pontos fortes do App Router

Renderização mais granular, com possibilidade de misturar servidor e cliente por componente. Streaming nativo, com suporte a Suspense em qualquer nível da árvore. Suporte nativo a layouts aninhados, com layout.tsx, e a templates, com template.tsx. Server Actions, funcionalidade que permite enviar dados para o servidor sem criar uma API tradicional. Fetch de dados integrado, com cache automático, revalidação por tag e opção de buscar no servidor ou no cliente. Melhor integração com o futuro do React e com novos recursos publicados pela Meta e pela Vercel.

Limitações conhecidas

Curva de aprendizado mais íngreme, especialmente para quem nunca trabalhou com React Server Components. Algumas bibliotecas externas ainda estavam, em 2026, ajustando compatibilidade com o novo modelo. Debugar erros que envolvem o limite entre servidor e cliente exige mais atenção, porque o componente roda em ambientes diferentes. A documentação e o material de apoio em português ainda são menos abundantes do que para o Pages Router.

Comparativo direto entre App Router e Pages Router

Fonte: documentação oficial do Next.js (nextjs.org/docs) e notas de lançamento publicadas pela Vercel entre 2022 e 2026.

Quando usar cada roteador na prática

A escolha entre App Router e Pages Router depende de três fatores principais: idade do projeto, tipo de produto e maturidade da equipe. Alguns cenários ajudam a visualizar melhor.

Cenários em que o Pages Router ainda vale a pena

Sites institucionais pequenos e médios, com poucas rotas e conteúdo estático. Projetos legados que já estão no Pages Router e não precisam de reescrita imediata. Equipes que estão começando agora em React e preferem um modelo mais conhecido. Sites que usam CMS headless com integração via getStaticProps ou getServerSideProps e que funcionam bem assim há anos.

Cenários em que o App Router é a escolha certa

Projetos novos, sem código antigo para manter. Lojas virtuais com catálogos grandes e filtros personalizados, porque streaming reduz a espera. Painéis internos que misturam áreas pesadas no servidor e áreas interativas no cliente. Sites com forte preocupação de SEO e Core Web Vitals, porque o modelo favorece o First Contentful Paint. Projetos que planejam usar Server Actions para reduzir código de APIs intermediárias.

A recomendação geral da Vercel, reforçada em 2024 e 2025, é iniciar projetos novos já no App Router. O Pages Router continua sendo uma opção válida, mas com tendência de receber menos novidades.

O que muda na migração de Pages Router para App Router

Migrar não é uma tarefa trivial. Os dois modelos usam estruturas, formas de carregar dados e padrões de componentes diferentes. Em projetos grandes, a migração costuma ser feita em etapas, usando a estratégia de coexistência.

A Vercel publicou um guia oficial chamado "Upgrading from Pages to App Router", que cobre os pontos centrais:

• Como mapear a estrutura antiga em pages/ para a nova em app/.
• Como substituir getStaticProps, getServerSideProps e getStaticPaths por fetch com async no componente.
• Como mover dados do _app.js para um layout em app/layout.tsx.
• Como tratar cabeçalhos e cookies.
• que ficam disponíveis via a função headers() e o objeto cookies().
• Como tratar metadata.
• antes concentrada em next/head.
• agora distribuída via a função exportada metadata.

Quem decide migrar deve considerar:

• Estimativa de tempo realista.
• porque a migração raramente cabe em uma única sprint.
• Testes visuais e de regressão.
• para garantir que cada rota continua se comportando como antes.
• Auditoria de SEO.
• conferindo títulos.
• descrições.
• canonical.
• sitemap e robots em cada página.
• Monitoramento de erros e performance.
• sobretudo com ferramentas como Vercel Analytics.
• Lighthouse e Google Search Console.

Algumas empresas optam por não migrar de imediato, mantendo o Pages Router enquanto o App Router amadurece ainda mais no ecossistema. Outras encaram a migração como investimento de longo prazo e tratam como projeto à parte.

Como o roteador impacta SEO e performance do site

O roteador escolhido não muda o que o Google consegue indexar. Tanto App Router quanto Pages Router geram HTML no servidor, seja no momento do build ou a cada requisição, e esse HTML é o que os mecanismos de busca leem.

O que muda é o tamanho do pacote de JavaScript enviado ao visitante, o tempo até a primeira renderização e a forma como dados são atualizados. De modo geral, segundo a documentação oficial do Next.js e benchmarks publicados pela própria Vercel, além de análises técnicas em publicações como Smashing Magazine e LogRocket:

• Projetos em App Router costumam entregar menos JavaScript no carregamento inicial.
• porque os Server Components não enviam código para o navegador.
• O streaming tende a melhorar métricas como Largest Contentful Paint em conexões mais lentas.
• O Pages Router é totalmente compatível com prerendering.
• e projetos bem otimizados nele entregam excelentes métricas de performance.

Para quem avalia SEO de forma prática, o roteador é um fator relevante, mas não é o único. Boas práticas de SEO técnico, como títulos únicos, descrições atrativas, sitemap.xml e dados estruturados, valem para os dois modelos. A vantagem do App Router aparece quando o projeto é pensado para escalar e crescer em complexidade.

Perguntas Frequentes

O App Router vai substituir o Pages Router?

Não existe um anúncio oficial de descontinuidade. A Vercel mantém o Pages Router funcional e segue publicando correções e pequenas melhorias. O que existe é um direcionamento claro: o App Router é o modelo recomendado para novos projetos e concentra os novos recursos. Na prática, isso significa que o Pages Router tende a receber menos novidades daqui em diante, sem ser removido.

Posso usar App Router e Pages Router no mesmo projeto?

Sim. É possível coexistir usando pages/ e app/ ao mesmo tempo, como documentado pela Vercel. No entanto, essa abordagem exige cuidado: o Pages Router terá prioridade em rotas que se sobrepõem. Para evitar conflito, mantenha nomes de rotas diferentes nos dois diretórios, ou separe o projeto em fases de migração.

Server Components são obrigatórios no App Router?

Não são obrigatórios, mas são o padrão. Todo componente que não recebe a diretiva "use client" é renderizado no servidor por padrão. Quem prefere trabalhar como antes, com tudo no cliente, pode colocar "use client" nos componentes que interessam e manter o restante. A escolha fica a critério do desenvolvedor, considerando performance e SEO.

Vale a pena migrar um projeto pequeno do Pages Router para App Router?

Depende do tempo disponível e dos objetivos. Se o projeto está funcionando bem, com manutenção simples e poucos ajustes planejados, manter no Pages Router é razoável. Se o projeto deve crescer, ganhar novas funcionalidades ou precisar de Server Actions, migrar pode trazer benefício real. Em times pequenos, muitas vezes vale começar do zero no App Router do que migrar um código antigo.

Quais bibliotecas externas ainda têm restrição no App Router?

Até 2026, a maioria das bibliotecas populares de React já foi adaptada para funcionar com Server Components. Casos pontuais, como bibliotecas que dependem de APIs exclusivas do navegador, podem exigir wrapper Client Component ou ajustes específicos. Antes de começar um projeto novo no App Router, é prudente validar as integrações mais críticas, como gateways de pagamento, ferramentas de analytics e CMSs headless.

Conclusão

A escolha entre App Router e Pages Router depende do contexto do projeto, da experiência do time e da estratégia de longo prazo. Para projetos novos, o App Router é a escolha recomendada pela Vercel, com benefícios claros em performance, modularidade e suporte a novas funcionalidades. Para projetos legados ou equipes em transição, o Pages Router ainda cumpre bem seu papel e não precisa ser descartado às pressas.

Mais importante do que o roteador em si é construir um site rápido, acessível e bem estruturado para SEO. O framework é meio, não fim. Quem entende o que cada modelo oferece consegue tomar uma decisão consciente e evita retrabalho no futuro.

Se você precisa de ajuda para colocar isso em prática, a Baita Site tem uma equipe especializada em sites, e-commerce, sistemas e inteligência artificial, com domínio total de WordPress e de Next.js. Fale com a gente e veja como podemos acelerar o seu projeto.

Este conteúdo tem caráter informativo. Decisões técnicas devem ser tomadas com profissional especializado.

Referências consultadas, Vercel. Documentação oficial do Next.js. Disponível em

https://nextjs.org/docs. Acesso em: jul. 2026., Vercel. Notas de lançamento do Next.js. Disponível em: https://nextjs.org/blog. Acesso em: jul. 2026., Vercel. Guia de migração do Pages Router para App Router. Disponível em: https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration. Acesso em: jul. 2026., Meta. Documentação oficial do React. Disponível em: https://react.dev. Acesso em: jul. 2026., Meta. React Server Components, RFC. Disponível em: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md. Acesso em: jul. 2026., Google. Documentação de Core Web Vitals. Disponível em: https://web.dev/vitals/. Acesso em: jul. 2026., Mozilla. MDN Web Docs, Web Components e JavaScript Modules. Disponível em: https://developer.mozilla.org. Acesso em: jul. 2026.