Arquitectura SEO en Next.js 15: SSR, PPR y Server Components

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. 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. 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 en la red de Vercel. Si quieres que te citen en las respuestas de IA (Generative Engine Optimization, o 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. 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 %. 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. 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 <Suspense> 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 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, 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) van con SSG o ISR. Las páginas personalizadas o casi en tiempo real usan SSR o PPR con límites <Suspense> 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. Cada variante de idioma debe referenciarse a sí misma y a todas las demás.
• Insertar JSON-LD en el servidor: como <script type="application/ld+json"> directamente en el Server Component. Los datos estructurados están muy extendidos: en 2024, JSON-LD aparece en el 41 % de todas las páginas, 7 puntos porcentuales más que el 34 % de 2022. Renderizado en el servidor, también resulta legible para los crawlers de IA que no ejecutan JS.

Generar dinámicamente los archivos obligatorios

Next.js 15 sustituye los plugins SEO de terceros por archivos basados en convenciones:

• sitemap.ts: genera el sitemap XML de forma programática, incluido lastModified para cada URL como señal lastmod precisa.
• robots.ts: genera el robots.txt de forma dinámica, incluida la referencia al sitemap y reglas específicas para determinados user agents.
• Redirecciones 301: las redirecciones permanentes van en next.config (redirects()) o, si la lógica es dinámica, en el middleware (a partir de Next.js 16, proxy.ts). Usa el código de estado 308/301 para que se transmitan la autoridad de los enlaces y las señales de indexación.

Edge, CDN y caché para un TTFB bajo

Las páginas estáticas e ISR se sirven desde una ubicación edge de la CDN cercana al usuario, lo que minimiza el TTFB para tus visitantes. Esto se controla con revalidate (intervalo de tiempo), cabeceras cache-control y la revalidación bajo demanda mediante revalidatePath o revalidateTag. HTTP/3 reduce además la sobrecarga al establecer la conexión. Como Google tiene en Austria, en mayo de 2026, una cuota de mercado del 81,87 % y Bing, del 9,01 %, la optimización para Googlebot sigue siendo prioritaria, sin descuidar Bing.

Lanzar IndexNow con la revalidación bajo demanda

Cuando un trigger editorial revalida una página, en el mismo Route Handler se puede enviar un ping de IndexNow a Bing y Yandex. Esto acelera notablemente la indexación en esos buscadores: IndexNow aporta el 18 % de todas las URL nuevas que reciben clics en la búsqueda web, con más de 3,5 mil millones de URL enviadas al día. En Google, IndexNow no sustituye al rastreo, pero complementa con eficacia la visibilidad en el ecosistema de Bing.

Optimizar las Core Web Vitals con las herramientas integradas

Next.js 15 incluye las herramientas para las tres métricas CWV:

• next/image para LCP y CLS: ofrece formatos modernos, tamaños responsive y espacio reservado que evita desplazamientos del layout.
• next/font para CLS: aloja las fuentes en tu propio dominio y evita los desplazamientos del layout provocados por el cambio de fuente.
• Streaming y Suspense para LCP: renderizan primero el contenido crítico y dejan para después las fuentes de datos lentas.
• Server Components y code splitting para INP: reducen el JS del cliente y, con ello, el tiempo de procesamiento de las interacciones.

Atender de forma específica a los crawlers de IA y al GEO

El contenido renderizado en el servidor es el requisito básico para que ChatGPT, Claude y Perplexity capten un texto. El acceso de cada bot de IA se controla con robots.txt (mediante robots.ts), y un llms.txt opcional puede señalar los contenidos clave. Para que un texto se cite en las respuestas de IA, cuentan los datos concretos, las cifras con fuentes y las preguntas respondidas con claridad directamente en el HTML generado en el servidor.

Errores frecuentes

• Cargar el contenido en el cliente: obtener los datos solo en el cliente mediante useEffect/fetch hace que el contenido sea invisible para los grandes crawlers de IA y retrasa a Googlebot por la cola de renderizado.
• Olvidar metadataBase: fuera de Vercel, las URL de las imágenes OG apuntan a localhost en lugar de a tu propio dominio y rompen las vistas previas en redes sociales y, en parte, en herramientas de IA.
• hreflang incompleto: la falta de autorreferencia o de x-default provoca los errores de clúster documentados.
• Convertirlo todo en Client Component: un "use client" generalizado en la raíz desperdicia las ventajas de los Server Components e infla el bundle hacia el límite de 2 MB.
• Límites de Suspense demasiado amplios con PPR: si se marca demasiado contenido como dinámico, el shell estático se reduce y se pierde la ventaja en TTFB.
• Cadenas de redirecciones y redirecciones soft: las redirecciones del lado del cliente en lugar de 301/308 no transmiten correctamente las señales de indexación.

Métricas y medición

El efecto de la arquitectura se hace visible en indicadores concretos:

• Core Web Vitals (datos de campo): mide LCP, INP y CLS con los datos reales de CrUX/Search Console. Como referencia: a nivel internacional, el 48 % de los orígenes móviles y el 56 % de los de escritorio superan las tres Core Web Vitals; en móvil, el LCP está en verde en el 62 %, el INP en el 77 % y el CLS en el 81 %. Por tanto, el LCP es la métrica limitante en móvil, y justo ahí actúan SSG/PPR y el streaming.
• Tener en cuenta INP en lugar de FID: desde el cambio rige la métrica más estricta. A nivel internacional, en 2024 solo el 43 % de los sitios móviles tenía buenas CWV con INP, frente al 48 % con el antiguo FID. Eso hace especialmente relevante la optimización del INP mediante Server Components.
• Comprobar la diferencia de renderizado: compara el código fuente HTML servido (ver código fuente) con el DOM renderizado. Lo que solo está en el DOM no lo ven los crawlers de IA.
• Latencia de indexación: sigue en Google Search Console el tiempo que transcurre desde la publicación hasta la indexación, como indicador de la eficiencia del rastreo.
• Tamaño del bundle frente al límite de 2 MB: supervisa los bundles de JS y CSS por ruta.

Para profundizar

La arquitectura de Next.js 15 es potente, pero compleja. Así lo refleja la percepción de los desarrolladores: según la encuesta internacional State of JavaScript 2025, el 59 % de los encuestados usa Next.js, con un 21 % de opiniones positivas frente a un 17 % de negativas, y la creciente complejidad recibe críticas repetidas. La consecuencia práctica: elegir de forma deliberada la estrategia de renderizado para cada ruta, usar PPR con límites de Suspense bien acotados y generar de forma sistemática en el servidor los archivos SEO obligatorios (sitemap.ts, robots.ts, Metadata API, canonical, hreflang). Así se obtiene un sitio rápido para Googlebot, totalmente legible para los crawlers de IA y servido con buen rendimiento en toda Europa. Como siguientes pasos, conviene hacer una auditoría de renderizado (HTML frente a DOM), una medición de CWV con datos de campo y la conexión de IndexNow al flujo de revalidación.