Estrategia de renderizado: ¿qué ve realmente el rastreador?

Una de las decisiones SEO principales en Next.js es cómo se renderiza cada ruta. Algunos rastreadores ejecutan JavaScript, mientras que otros pueden depender sobre todo de la respuesta HTML inicial. Tener el contenido clave en esa respuesta limita la dependencia de las capacidades de un rastreador concreto.

Regla práctica:

• Estático (SSG): páginas de marketing, documentación, blog. Lo más rápido, lo más barato, totalmente indexable.
• ISR (Incremental Static Regeneration): catálogos, listados, todo lo que cambia cada hora/día. La velocidad de lo estático con frescura controlada.
• SSR (renderizado dinámico): páginas personalizadas o de verdad en tiempo real. Indexables, pero con un TTFB más lento.
• CSR (solo cliente): dashboards e interior de la aplicación. Nunca para contenido que deba indexarse.

// app/blog/[slug]/page.tsx — ISR: HTML estático, regeneración cada hora
export const revalidate = 3600;

export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Compruebe lo que recibe el rastreador, no lo que muestra su navegador:

curl -s https://example.com/su-pagina | grep -i "frase-clave"

Si el contenido clave no está en esa respuesta, los rastreadores que no renderizan la página pueden omitirlo.

Cuidado con el renderizado dinámico accidental. Usar cookies(), headers() o searchParams en una página la pasa a SSR en silencio. No es letal para el SEO, pero cuesta TTFB y carga de servidor. Describimos estas trampas en detalle en el artículo Cómo funciona la caché en Next.js con App Router.

Checklist:

• Toda ruta indexable es SSG o ISR; SSR solo donde lo exija la personalización
• curl sobre el HTML en bruto confirma la presencia del contenido principal
• Sin llamadas a cookies()/headers() en páginas que deberían ser estáticas
• Los componentes de cliente sirven a la interactividad, no al contenido