App Router frente a Pages Router de Next.js para un proyecto nuevo en 2026

¿Vas a empezar un proyecto nuevo con Next.js en 2026? Usa el App Router. Esa es la recomendación por defecto del propio framework, y es donde llegan primero las novedades, desde los Server Components hasta el modelo actual de obtención de datos. El Pages Router todavía funciona, y Next.js se ha comprometido a mantenerlo. Pero ya no es el router al que recurres el primer día.

Qué es y por qué importa

El App Router y el Pages Router son dos convenciones de enrutamiento por sistema de archivos distintas dentro del mismo framework. El Pages Router, el modelo original, asigna un archivo en pages/ a una ruta y renderiza los componentes en el cliente por defecto, usando funciones de datos como getServerSideProps y getStaticProps. El App Router llegó con Next.js 13. Usa un directorio app/ con las convenciones page.js y layout.js, y sus páginas son Server Components por defecto, lo que significa que pueden obtener datos y renderizarse en el servidor antes de que nada llegue al navegador.

La documentación de migración de Next.js lo dice sin rodeos: el App Router es el valor por defecto para las aplicaciones nuevas, porque ofrece el conjunto de funciones actual de React, Server Components, streaming y Suspense, sobre el que el Pages Router nunca se construyó. Al mismo tiempo, la misma guía es explícita al decir que el desarrollo de pages/ sigue recibiendo correcciones de errores y parches de seguridad durante varias versiones mayores, así que una aplicación existente con Pages Router no corre el riesgo de quedar abandonada. Ese compromiso importa si estás evaluando una reescritura frente a un inicio nuevo desde cero.

Los dos routers también estructuran la interfaz compartida de forma distinta. El Pages Router centraliza la configuración global de layout y documento en pages/_app.js y pages/_document.js, archivos que se aplican a cada ruta la necesite o no. El App Router sustituye ambos por un único layout raíz, app/layout.js, y los layouts se anidan por segmento de ruta, de modo que una sección de panel de control puede definir su propio layout sin tocar las páginas de marketing que están justo al lado. Para un proyecto nuevo, ese anidamiento elimina una categoría de conflictos de fusión en archivos compartidos que los equipos de Pages Router aprenden a sortear en lugar de una limitación elegida a propósito.

Cómo funciona en la práctica

La diferencia mecánica central es la separación entre Server Components y Client Components. Un Server Component obtiene los datos cerca de la fuente, mantiene las claves de API y los tokens fuera del cliente, y reduce el JavaScript enviado al navegador, lo que ayuda al first contentful paint. Un Client Component, marcado con la directiva 'use client', es lo que usas cuando necesitas estado, manejadores de eventos o una API exclusiva del navegador como localStorage. La guía oficial recomienda marcar solo la pieza interactiva específica, un cuadro de búsqueda, un botón de me gusta, en lugar de un layout entero. En cuanto un archivo lleva 'use client', todo lo que importa y renderiza directamente pasa a formar parte del paquete de cliente.

La obtención de datos cambia con ello. getServerSideProps, getStaticProps y getStaticPaths desaparecen del App Router. En su lugar, un Server Component asíncrono llama directamente a fetch(), con opciones de caché que sustituyen a lo que antes eran funciones separadas, y generateStaticParams reemplaza a getStaticPaths para pre-renderizar rutas dinámicas. Los equipos que hacen esta migración junto con una auditoría técnica de SEO suelen descubrir que la elección de router y la rastreabilidad aparecen en la misma revisión. Nuestra propia lista de verificación de auditoría técnica de SEO para Next.js cubre con más detalle el lado del renderizado y la indexación de ese trabajo.

Ventajas, desventajas y casos particulares

El App Router no es una mejora gratuita, y saber dónde muerde importa más que saber que existe. La primera sorpresa que se lleva la mayoría de los equipos es el caché. Los Route Handlers del App Router se guardan en caché de forma estática por defecto, a diferencia de las rutas de API del Pages Router, que siguen siendo dinámicas salvo que se indique lo contrario. Una Server Action que escribe en una base de datos no actualizará lo que ven los usuarios hasta que llames explícitamente a revalidatePath(). Olvidar ese paso es una fuente común de reportes tipo "mi actualización no se ve".

La semántica de caché también ha cambiado de versión en versión. Desde Next.js 15, los Route Handlers GET y la Client Router Cache pasaron de estar en caché por defecto a no estarlo, tras comentarios de desarrolladores que indicaban que los valores por defecto anteriores generaban confusión. Next.js 16 sigue dirigiendo las llamadas a fetch() y unstable_cache() a través de una capa de Data Cache separada. Si tu equipo está acostumbrado al modelo de caché más implícito y estable entre versiones del Pages Router, dedica tiempo a leer la documentación actual en lugar de arrastrar suposiciones de un tutorial antiguo.

También existe un costo real al mezclar ambos routers en una misma aplicación durante una migración incremental, algo que Next.js admite y documenta. Navegar entre una ruta servida por pages/ y otra servida por app/ provoca una navegación completa y dura, y el precargado de next/link no cruza ese límite. Así que las transiciones rápidas del lado del cliente que esperas dentro de un router no se trasladan al otro. Para un proyecto realmente nuevo sin código heredado en pages/ que conservar, nada de eso aplica, lo cual es el argumento más sólido para empezar en el App Router en lugar de migrar hacia él más adelante.

Nada de esto cambia el cálculo para un equipo con una aplicación grande y estable en Pages Router y sin necesidad a corto plazo de streaming o Server Components. Reescribir una aplicación estable solo para perseguir un router casi nunca compensa la disrupción por sí sola. El App Router se gana su lugar en construcciones nuevas y en páginas donde las ventajas de caché y tamaño de paquete valen la curva de aprendizaje. Una prueba útil: si puedes nombrar una función concreta que quieres, prerenderizado parcial, layouts anidados, menos JavaScript de cliente en una página lenta, el App Router vale el esfuerzo de adaptarse. Si la única respuesta es que es lo que recomienda la documentación, una aplicación estable en Pages Router puede seguir funcionando tal cual.

Para un proyecto nuevo de Next.js en 2026, el App Router es la opción correcta por defecto: es donde viven las funciones actuales del framework y la inversión continua, y Next.js lo dice directamente en su propia documentación. El hábito que vale la pena llevar a cualquiera de los dos routers: la semántica de caché sigue cambiando de versión en versión, así que revisa la fecha de última actualización de la propia documentación antes de publicar, no una entrada de blog de hace dos años. Cuando definimos el alcance de una construcción nueva en Next.js en Kallos Labs, esta es una de las primeras decisiones arquitectónicas que revisamos con un cliente, junto a nuestro trabajo de desarrollo web.

Preguntas frecuentes

¿Un proyecto nuevo de Next.js en 2026 debería usar el App Router o el Pages Router?

Usa el App Router. La propia documentación de Next.js lo recomienda como valor por defecto para proyectos nuevos porque da acceso a Server Components, streaming y el modelo actual de obtención de datos, y las nuevas inversiones del framework llegan primero allí.

¿El Pages Router está obsoleto?

No. Next.js se ha comprometido a mantener pages/ con correcciones de errores y parches de seguridad durante varias versiones mayores, así que las aplicaciones existentes con Pages Router no corren riesgo. Simplemente no es donde llegan las nuevas funciones.

¿Se pueden mezclar el App Router y el Pages Router en un mismo proyecto?

Sí, de forma incremental, y Next.js documenta esto como la ruta de migración admitida. La contrapartida es una navegación completa y dura cada vez que un usuario cruza entre una ruta de pages/ y una de app/, ya que el precargado de next/link no cruza ese límite.

¿Cuál es el mayor problema con el que se topan los equipos al pasar al App Router?

Los valores de caché por defecto. Los Route Handlers del App Router se guardan en caché de forma estática por defecto, a diferencia de las rutas de API del Pages Router, y las mutaciones con Server Actions necesitan una llamada explícita a revalidatePath o la interfaz sigue mostrando datos desactualizados. Ambas cosas sorprenden a los equipos acostumbrados al modelo más implícito del Pages Router. El Pages Router no va a desaparecer y sigue siendo una opción razonable y de bajo riesgo para los equipos que mantienen una aplicación grande existente, pero no es el punto de partida para algo nuevo.