App Router vs Pages Router: qual escolher no Next.js em 2026

Se você já abriu um projeto em Next.js e se deparou com duas pastas chamadas app e pages, provavelmente ficou em dúvida sobre qual usar. Essa é uma das perguntas mais comuns entre quem começa a estudar o framework hoje, e a resposta curta é: existe um roteador mais moderno, mas o antigo ainda funciona e tem casos de uso válidos. O objetivo deste guia é explicar, em linguagem acessível, o que cada roteador faz, como eles se diferenciam na prática e quando vale a pena usar um ou outro.

A ideia aqui não é defender tecnologia específica nem empurrar você para um lado. É mostrar, com base em documentação oficial e na experiência de quem trabalha com Next.js no dia a dia, como decidir com consciência. Se você está começando um projeto novo, migrando um sistema legado ou apenas estudando, este conteúdo foi escrito para ajudar nessa escolha.

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

O Next.js é um framework para React, que é a biblioteca mais popular para criar interfaces web hoje. O Next.js adiciona ao React recursos que, em projetos maiores, fazem muita diferença: renderização no servidor, geração estática, roteamento baseado em arquivos, divisão automática de código e integração com APIs. Em resumo, é um conjunto de ferramentas que tira do desenvolvedor boa parte do trabalho repetitivo de configurar um site moderno.

Por ser uma ferramenta em evolução, o Next.js já passou por algumas mudanças importantes. A maior delas, em se tratando de roteamento, foi a chegada do App Router, lançado como estável na versão 13.4, em maio de 2023, e continuamente aprimorado desde então. O sistema anterior, baseado em uma pasta pages, ficou conhecido como Pages Router e continua funcionando para manter a compatibilidade com milhares de projetos já publicados.

Ter dois roteadores não é um bug nem uma confusão proposital. É uma estratégia comum em frameworks que crescem rápido: manter o que está funcionando enquanto o novo amadurece. Quem tem projetos antigos em produção não é forçado a migrar, e quem está começando hoje pode escolher a abordagem mais atual.

O que é o Pages Router

O Pages Router é o sistema original do Next.js, usado desde as primeiras versões do framework. Nele, cada arquivo dentro da pasta pages representa uma rota do site. Um arquivo chamado pages/sobre.js se torna automaticamente a página /sobre. O arquivo pages/index.js é a página inicial. É um modelo simples, fácil de entender e que muita gente já conhece há anos.

Dentro desse modelo existem variações para lidar com dados. A função getStaticProps permite buscar dados em tempo de build, gerando uma página estática. Já getServerSideProps busca os dados a cada requisição, no servidor. Para rotas dinâmicas, basta criar um arquivo com colchetes, como pages/produto/[id].js, e usar getStaticPaths para informar quais caminhos devem ser gerados previamente.

O Pages Router também traz um arquivo especial chamado _app.js, que envolve todas as páginas e é útil para manter layouts, provedores de contexto e estilos globais. Há ainda o _document.js, para customizar o HTML base, e a pasta pages/api, que permite criar endpoints de API dentro do próprio projeto. Esse conjunto de padrões é conhecido, documentado e estável.

Vantagens do Pages Router

A maior vantagem do Pages Router é a maturidade. Depois de anos em produção, há um volume enorme de tutoriais, exemplos, bibliotecas compatíveis e soluções para problemas conhecidos. Se você trava em uma dificuldade, é muito provável que alguém já tenha passado por isso e publicado a resposta em algum lugar.

Outra vantagem é a simplicidade inicial. Para quem está aprendendo, o modelo mental é direto: arquivo vira rota, função busca dados, página renderiza. Não há muitos conceitos novos para absorver antes de colocar algo no ar.

A estabilidade também conta. Como esse roteador não recebe mais grandes mudanças, o comportamento dele hoje é o mesmo de meses atrás. Isso reduz surpresas em projetos de longo prazo.

Limitações do Pages Router

O Pages Router foi pensado em uma época em que o React funcionava de um jeito diferente. Hoje, com recursos como Server Components, streaming e layouts aninhados, ele mostra limitações estruturais. Para entregar esses recursos no Pages Router seria preciso reorganizar a base, e a equipe do Next.js preferiu construir algo novo em vez de adaptar o antigo.

Outra limitação é a separação menos clara entre o que roda no servidor e o que roda no cliente. No Pages Router, todos os componentes são renderizados no servidor por padrão e depois hidratados no navegador, sem uma divisão explícita. Isso não é necessariamente um problema, mas exige mais cuidado do desenvolvedor para evitar enviar código pesado ao cliente sem necessidade.

O que é o App Router

O App Router é o novo sistema de roteamento do Next.js, baseado na pasta app. Ele foi desenhado para tirar proveito dos React Server Components, um recurso que permite renderizar partes da interface no servidor sem enviar JavaScript ao navegador. O resultado prático são páginas mais leves, com tempos de resposta menores.

A estrutura básica também usa arquivos para definir rotas, mas com algumas diferenças. Dentro de app, cada pasta representa um segmento da URL e precisa ter um arquivo chamado page.js para que a rota exista. Por exemplo, a rota /sobre corresponde a app/sobre/page.js. A página inicial fica em app/page.js. Esse modelo é chamado de roteamento por segmentos.

Um dos recursos mais úteis do App Router é o suporte nativo a layouts. O arquivo layout.js envolve todas as páginas da pasta e das subpastas, e pode ser aninhado. Isso permite, por exemplo, ter um layout geral no site, um layout específico para a área de blog e um layout próprio para a página de artigo, tudo sem repetir código.

A busca de dados também mudou. Não há mais getStaticProps ou getServerSideProps. No App Router, os componentes de servidor podem buscar dados diretamente, usando async e await. A função fetch foi estendida para aceitar opções de cache e revalidação, o que permite controlar com precisão quando os dados devem ser atualizados.

Vantagens do App Router

A principal vantagem é a performance. Com Server Components, o servidor envia ao navegador apenas o HTML pronto e o JavaScript necessário para tornar a página interativa. Em sites com muito conteúdo, dashboards ou áreas autenticadas, isso reduz bastante o tempo de carregamento.

Outra vantagem é a organização. Layouts aninhados, loading states com loading.js, error boundaries com error.js e metadata por rota deixam o código mais estruturado e fácil de manter. Cada arquivo tem um papel bem definido dentro da pasta.

Há também ganhos em flexibilidade. O App Router suporta streaming de respostas, o que significa que o navegador começa a renderizar a página antes do servidor terminar de processar tudo. Em páginas com dados pesados, isso faz diferença na experiência do usuário.

Limitações do App Router

O App Router ainda está em evolução. A documentação é boa e tem melhorado a cada versão, mas alguns padrões e boas práticas só se consolidaram recentemente. Se você começou a aprender Next.js há pouco tempo, pode encontrar exemplos antigos que misturam conceitos ou usam abordagens já substituídas.

Há também um esforço de aprendizado maior. Os conceitos de Server Components, cliente e servidor, caching, revalidação e streaming exigem uma curva inicial. Para quem vem do Pages Router ou de React puro, pode levar algum tempo até se sentir confortável com o novo modelo.

Por fim, algumas bibliotecas e componentes ainda esperam ajustes para funcionar 100% no App Router, especialmente as que dependem de estado do navegador ou de APIs do lado do cliente. É um cenário que melhora a cada release, mas que exige atenção ao escolher dependências.

Comparativo direto: App Router vs Pages Router

Para facilitar a visualização das diferenças, a tabela abaixo resume os pontos mais relevantes entre os dois roteadores. Os dados refletem o estado do framework até a publicação deste conteúdo.

A tabela mostra que não há um roteador claramente superior em todos os critérios. Cada um tem pontos fortes, e a escolha depende do contexto do projeto.

Quando usar Pages Router

O Pages Router ainda é uma escolha válida em alguns cenários. Se você está mantendo um projeto antigo que já está em produção e funcionando bem, não há motivo urgente para migrar. Reescrever a base de um site apenas para usar o roteador mais novo raramente traz retorno proporcionado ao esforço.

Outra situação é quando você precisa de máxima compatibilidade com bibliotecas legadas ou quando a equipe já domina o modelo antigo e tem pouco tempo para aprender o novo. Em projetos curtos, com prazo apertado e pouca complexidade, a familiaridade com o Pages Router pode ser mais vantajosa do que a adoção do App Router.

Por fim, se você está ensinando Next.js para iniciantes e quer evitar a sobrecarga de conceitos, o Pages Router continua sendo um ponto de partida razoável. Os fundamentos de React continuam valendo, e migrar para o App Router depois é mais fácil do que parece.

Quando usar App Router

Se você está começando um projeto novo hoje, o App Router é a recomendação natural. É nele que os novos recursos são adicionados, é sobre ele que os exemplos mais recentes da equipe do Next.js são construídos e é o caminho que a comunidade vem seguindo nos últimos lançamentos.

Projetos que se beneficiam de Server Components são candidatos óbvios: sites com muito conteúdo, dashboards, áreas autenticadas, aplicações que processam dados sensíveis ou que precisam de SEO forte. Nessas situações, o App Router entrega uma arquitetura mais alinhada com o que o React propõe como boa prática.

Também vale considerar o App Router quando há expectativa de crescimento. Se o projeto vai ganhar funcionalidades com o tempo, ter uma base que já usa layouts aninhados, loading states e streaming desde o início evita retrabalho. Migrar no meio do caminho costuma sair mais caro do que começar certo.

Como migrar de Pages Router para App Router

A migração entre os dois roteadores pode ser feita de maneira gradual, e essa é uma das grandes vantagens do Next.js. Você não precisa reescrever o projeto inteiro de uma vez. É possível ter as duas pastas coexistindo enquanto a transição é feita página por página.

O processo recomendado pela documentação oficial começa pela instalação da versão mais recente do Next.js. Em seguida, cria-se a pasta app e move-se uma página de cada vez, ajustando imports, substituindo getStaticProps e getServerSideProps por busca direta no componente e adaptando a metadata para a nova API.

Para rotas que compartilham layouts, é recomendável mover primeiro as páginas mais simples, como páginas estáticas de conteúdo. Depois vêm as páginas dinâmicas, e por último as APIs internas, que continuam funcionando dentro da pasta app/api. Ao longo do caminho, testes e verificações de comportamento ajudam a evitar surpresas.

Esse modelo de coexistência é útil porque permite migrar com calma, sem precisar tirar o site do ar. É uma abordagem que respeita o trabalho já feito e dá tempo para a equipe se adaptar aos novos conceitos.

Erros comuns na comparação entre os dois roteadores

Um erro frequente é tratar a escolha como uma decisão puramente técnica, sem considerar o contexto do projeto e da equipe. Ambos os roteadores funcionam bem, e a escolha errada raramente é sobre qualidade de código, e sim sobre encaixe com a realidade de quem vai manter o sistema.

Outro erro comum é acreditar que o Pages Router ficou obsoleto ou que será removido em curto prazo. A documentação oficial mantém o suporte e não há anúncio de descontinuação. Projetos em Pages Router podem (e muitos devem) continuar como estão.

Também é comum confundir App Router com Server Components. São coisas relacionadas, mas não iguais. O App Router é a estrutura de pastas e roteamento, e os Server Components são um tipo de componente que pode ser usado dentro dessa estrutura. Dá para ter App Router sem usar Server Components em todas as páginas, e dá para ter Client Components sempre que houver interação.

Por fim, vale evitar a armadilha de querer usar o roteador mais novo em todo projeto só porque é o mais novo. Em alguns casos, a simplicidade do Pages Router é exatamente o que o projeto precisa.

Atenção: este conteúdo é informativo

Este material tem caráter informativo e educacional. Decisões sobre arquitetura de software envolvem variáveis específicas de cada projeto, como tamanho da equipe, prazo, orçamento, integrações e dependências. Recomendações aqui são baseadas em boas práticas gerais e em informações públicas disponíveis na documentação oficial do Next.js e em publicações técnicas reconhecidas. Para projetos críticos, vale conversar com um profissional especializado antes de tomar decisões definitivas.

Perguntas Frequentes (FAQ)

O App Router substituiu o Pages Router?

Não. O App Router é a evolução do sistema de roteamento, mas o Pages Router continua funcionando e recebendo suporte. Projetos existentes podem (e em muitos casos devem) permanecer no Pages Router. A escolha depende do estágio do projeto e das necessidades da equipe.

Posso usar os dois roteadores no mesmo projeto?

Sim. O Next.js permite manter as pastas app e pages no mesmo projeto. As rotas são resolvidas primeiro pelo App Router e, quando não há correspondência, o Pages Router é consultado. Isso facilita migrações graduais.

Qual roteador tem melhor performance?

Em geral, o App Router tende a entregar páginas mais leves, por causa dos Server Components e do streaming. Porém, a performance real depende de muitos fatores, como tamanho da página, complexidade dos componentes e otimizações específicas. Em páginas simples, a diferença pode ser pequena.

Preciso aprender Server Components para usar o App Router?

Não obrigatoriamente. Você pode usar o App Router com componentes tradicionais, marcados com "use client" no topo do arquivo, e ter um comportamento próximo ao Pages Router. Os Server Components ficam disponíveis para os casos em que realmente fizerem diferença.

Vale a pena migrar um projeto antigo para o App Router?

Depende. Se o projeto está estável, sem planos de grandes mudanças e a equipe está confortável com o Pages Router, a migração pode não trazer benefícios proporcionais. Já se há previsão de novas funcionalidades, reestruturação ou ganho de performance, migrar pode valer a pena.

Conclusão

A escolha entre App Router e Pages Router não é sobre qual é melhor em termos absolutos, e sim sobre qual é mais adequado para o seu contexto. O App Router é o caminho natural para projetos novos e para quem quer tirar proveito dos recursos mais recentes do React e do Next.js. O Pages Router continua sendo uma opção sólida, com anos de maturidade e uma base enorme de conhecimento público.

O mais importante é entender o que cada roteador oferece, avaliar as necessidades do projeto e tomar a decisão com base em informação. Se você está começando agora, comece pelo App Router e vá explorando os conceitos aos poucos. Se você mantém um projeto antigo, mantenha-o no Pages Router enquanto ele atender bem, e considere a migração quando houver um motivo real para isso.

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 experiência em frameworks modernos como Next.js. Fale com a gente e veja como podemos acelerar o seu projeto.

Referências consultadas

Para a elaboração deste conteúdo, foram consultadas fontes oficiais e publicações técnicas reconhecidas na comunidade de desenvolvimento web:

• Documentação oficial do Next.js.
• em https://nextjs.org/docs.
• seção App Router e Pages Router.
• incluindo o guia de migração entre os dois sistemas.
• Blog oficial do Next.js.
• em https://nextjs.org/blog.
• com anúncios de versões e recursos novos desde 2023.
• Documentação do React.
• em https://react.dev.
• com explicações sobre Server Components e o modelo de renderização atual.
• Conteúdo educacional da Rocketseat.
• em https://blog.rocketseat.com.br.
• com artigos e vídeos sobre Next.js em português brasileiro.
• Publicações da comunidade no Dev.to.
• em https://dev.to.
• com comparativos e experiências práticas de desenvolvedores que passaram pela migração.