--- title: "Arquitectura SEO en Next.js 15: SSR, PPR y Server Components" description: "Arquitectura SEO en Next.js 15: App Router, Partial Prerendering (PPR), Server Components y la Metadata API para la máxima visibilidad en IA." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/arquitectura-seo-en-nextjs-15-ssr-ppr-y-server-components" category: "SEO & GEO" topic: "SEO técnico" updated: "2026-10-28T13:09:06.610Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Arquitectura SEO en Next.js 15: SSR, PPR y Server Components La arquitectura SEO de Next.js 15 combina el App Router con React Server Components y Partial Prerendering (PPR) para servir el contenido desde el servidor como HTML ya generado. Los Server Components envían cero JavaScript al cliente, mientras que PPR entrega un shell estático desde la CDN y transmite después las partes dinámicas como HTML en streaming. Así, las páginas resultan legibles tanto para Googlebot como para los crawlers de IA que no ejecutan JavaScript. ## De un vistazo - Ninguno de los grandes crawlers de IA renderiza JavaScript; por eso, el HTML generado en el servidor es un requisito básico para el GEO y la visibilidad en IA. - Para el trabajo SEO nuevo, el App Router con Server Components es preferible al Pages Router, porque los Server Components envían cero JavaScript al cliente. - Elige de forma deliberada para cada ruta: SSG/ISR para páginas de contenido, SSR/PPR solo cuando el contenido sea realmente dinámico o personalizado. - PPR entrega un shell estático desde la CDN para lograr un TTFB/LCP bajo y transmite después en streaming las partes dinámicas como HTML, que también pueden leer los crawlers sin JS. - La Metadata API genera en el servidor el title, el canonical, el hreflang (de-AT/de-DE/x-default) y Open Graph; para ello, metadataBase es obligatorio. El JSON-LD se inserta como etiqueta script directamente desde el Server Component. - sitemap.ts y robots.ts sustituyen a los plugins de terceros; las redirecciones 301 van en next.config o en el middleware (a partir de Next.js 16, proxy.ts). - El límite de Googlebot, reducido a 2 MB por recurso, convierte los bundles ligeros y centrados en el servidor en una obligación de SEO. En Next.js 15, la elección de la arquitectura de renderizado decide si una página es legible por igual para los buscadores clásicos y para los crawlers de [IA](https://blckalpaca.at/es/glosario/ia). El App Router con React Server Components y Partial Prerendering (PPR) traslada la generación de contenido al servidor. De ello depende que Googlebot, ChatGPT, Claude y Perplexity lleguen a captar el contenido completo de una página. Este artículo sitúa las distintas estrategias de renderizado y muestra qué estrategia necesita cada ruta. ## Por qué la arquitectura de renderizado decide la visibilidad El hallazgo clave procede de un análisis del tráfico de crawlers en la red de Vercel: [ninguno de los grandes crawlers de IA (GPTBot, ClaudeBot, Meta-ExternalAgent, PerplexityBot, Bytespider) renderiza JavaScript; en ChatGPT el 11,50 % y en Claude el 23,84 % de las solicitudes corresponden a archivos JavaScript, pero no se ejecutan](https://vercel.com/blog/the-rise-of-the-ai-crawler). Solo Gemini (a través de la infraestructura de Googlebot) y AppleBot renderizan por completo. Para cualquier página cuyo contenido se genera en el cliente mediante JavaScript, esto significa que los crawlers de IA ven un cascarón vacío. Estos crawlers de IA ya no son un fenómeno marginal. [GPTBot, Claude, AppleBot y PerplexityBot generan en conjunto unos 1,3 mil millones de peticiones al mes, algo más del 28 % de los 4,5 mil millones de peticiones de Googlebot](https://vercel.com/blog/the-rise-of-the-ai-crawler) en la red de Vercel. Si quieres que te citen en las respuestas de IA ([Generative Engine Optimization, o GEO](https://blckalpaca.at/es/servicios/geo)), tienes que servir tu contenido desde el servidor como HTML ya generado. El Googlebot clásico también penaliza el renderizado del lado del cliente, aunque de forma más sutil. Googlebot renderiza JavaScript, pero en una segunda oleada: las páginas que requieren renderizado acaban, además de en la cola de rastreo, en una cola de renderizado. Un estudio internacional muy citado cuantifica la consecuencia: [Google necesitó 313 horas para las páginas renderizadas con JavaScript frente a 36 horas para HTML puro, es decir, unas nueve veces más](https://www.onely.com/blog/google-needs-9x-more-time-to-crawl-js-than-html/). En sitios grandes, esto retrasa considerablemente la indexación de contenidos nuevos y actualizados. A esto se suma un límite técnico estricto. [Googlebot ya solo rastrea los primeros 2 MB por recurso en lugar de los 15 MB anteriores, una reducción del 86,7 %](https://ppc.land/google-slashes-web-crawl-limit-by-86-7-as-cost-pressures-mount/). El límite se aplica por recurso, es decir, por separado al HTML, al bundle de JavaScript y al CSS. Con bundles de cliente sobredimensionados se corre el riesgo de que se corten scripts decisivos. ## Cómo funcionan SSG, SSR, ISR y PPR: comparativa SEO Next.js 15 ofrece cuatro estrategias de renderizado. La elección para cada ruta depende de lo dinámico que sea el contenido y de la rapidez con la que deba estar actualizado. - **SSG (Static Site Generation):** La página se genera como HTML durante el build y se sirve desde la CDN. El mejor TTFB y LCP posibles, ideal para los crawlers de IA, porque el contenido completo está en el HTML desde el primer momento. Adecuado para artículos de la base de conocimiento, páginas de servicios y entradas de blog. - **ISR (Incremental Static Regeneration):** Como SSG, pero la página se regenera tras un intervalo de tiempo (`revalidate`) o mediante un trigger bajo demanda. Combina la entrega estática con la actualidad editorial, por ejemplo para listas de precios o indicadores de stock. - **SSR (Server-Side Rendering):** La página se renderiza en el servidor en cada solicitud. Necesario cuando el contenido depende del usuario o de la solicitud (geotargeting, tests A/B). El contenido está en el HTML, pero el TTFB depende del tiempo de ejecución del servidor. - **PPR (Partial Prerendering, experimental en Next.js 15):** Combina lo estático y lo dinámico dentro de una misma ruta. Un shell estático se prerrenderiza durante el build y se sirve desde la CDN; las partes dinámicas se transmiten después en streaming como HTML. Desde el punto de vista arquitectónico, PPR es el enfoque más interesante para el [SEO](https://blckalpaca.at/es/glosario/seo). El shell estático (cabecera, contenido principal, pie de página) está disponible de inmediato en la respuesta HTML inicial y garantiza un TTFB bajo y un LCP rápido. Los fragmentos dinámicos situados dentro de límites `` se transmiten después en streaming desde el servidor y se insertan también como HTML en la misma respuesta. Lo decisivo para la rastreabilidad: el contenido transmitido es HTML, no JavaScript cargado después en el cliente. Un crawler que no ejecuta JS recibe el contenido completo en cuanto termina el stream. Los [Server Components](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/renderizado-de-javascript-y-crawlers-de-ia-la-brecha-de-visibilidad) son la base de todo esto. Se renderizan exclusivamente en el servidor y envían cero JavaScript al cliente para su propia lógica. Esto reduce drásticamente el volumen de hidratación, lo que repercute directamente en el INP (Interaction to Next Paint), y reduce el tamaño de los bundles de JS respecto al límite de 2 MB. La interactividad se añade de forma selectiva en los bordes mediante Client Components (`"use client"`), no de forma generalizada en toda la página. Next.js 16, [publicado el 21 de octubre de 2025](https://nextjs.org/blog/next-16), trae dos cambios relevantes para este artículo. El flag `experimental.ppr` ha desaparecido; allí, Partial Prerendering funciona mediante Cache Components (`cacheComponents: true` en `next.config`). El archivo de middleware pasa a ser `proxy.ts` y `middleware.ts` se considera obsoleto. La lógica SEO de este artículo no cambia: el shell estático y las partes transmitidas en streaming llegan al crawler como HTML. ## Buenas prácticas para la arquitectura SEO en Next.js 15 ### Elegir de forma deliberada la estrategia de renderizado para cada ruta La regla general: tan estático como sea posible, tan dinámico como sea necesario. [Las páginas de contenido (base de conocimiento, blog, servicios)](https://blckalpaca.at/es/servicios/agencia-seo) van con SSG o ISR. Las páginas personalizadas o casi en tiempo real usan SSR o PPR con límites `` bien acotados, de modo que el shell relevante para el SEO siga siendo estático y solo se transmitan en streaming las partes realmente dinámicas. ### Aprovechar al máximo la Metadata API en el servidor El App Router genera los metadatos en el servidor mediante el objeto `metadata` o la función `generateMetadata`. Lo importante: - **Definir metadataBase:** Sin `metadataBase`, Next.js resuelve las rutas relativas de las imágenes de Open Graph y Twitter contra un valor de respaldo que, fuera de Vercel, es localhost. Las URL de las imágenes serán absolutas, pero apuntarán a una dirección a la que ningún crawler puede acceder. Por eso, define siempre la URL base con tu dominio de producción. - **Canonical por ruta:** defínelo mediante `alternates.canonical` para evitar contenido duplicado por variantes de parámetros o de rutas. - **hreflang para la región DACH (Alemania, Austria y Suiza):** genéralo mediante `alternates.languages` con `de-AT`, `de-DE` y `x-default`. Es propenso a errores: un estudio internacional reveló que [el 31,02 % de los sitios web multilingües contiene directivas hreflang contradictorias y el 16,04 % de los clústeres hreflang no tiene etiquetas autorreferenciales](https://searchengineland.com/study-31-of-international-websites-contain-hreflang-errors-395161). Cada variante de idioma debe referenciarse a sí misma y a todas las demás. - **Insertar JSON-LD en el servidor:** como `