Año pasado asumimos como cliente un sitio de e-commerce construido con Next.js que tenía 40.000 páginas de productos. Su tráfico orgánico había estado estancado durante seis meses. El contenido era sólido. El perfil de backlinks era saludable. Pero cuando analizamos sus logs del servidor, descubrimos que Googlebot estaba gastando el 60% de su presupuesto de rastreo en URLs de navegación facetada que devolvían contenido casi idéntico -- y el 40% restante llegaba a páginas renderizadas con JavaScript que el rastreador de primer paso de Google veía como conchas vacías.

Tres meses después de corregir el desperdicio de presupuesto de rastreo y los problemas de renderizado JavaScript, el recuento de páginas indexadas aumentó un 35% y las sesiones orgánicas crecieron un 28%. No fue magia. Fue fontanería.

Este artículo es el manual técnico que hubiéramos querido tener cuando comenzamos ese proyecto. Cubriremos la auditoría de SEO para JavaScript desde la perspectiva del renderizador, las trampas del indexado mobile-first que silenciosamente destruyen posicionamientos, y estrategias de optimización del presupuesto de rastreo que realmente mueven la aguja en sitios grandes.

Tabla de Contenidos

JavaScript SEO Audit, Mobile SEO & Crawl Budget Optimization

Cómo Procesa Google Realmente el JavaScript

Antes de poder auditar cualquier cosa, necesitas entender el pipeline de indexación de dos oleadas que utiliza Google. Esto no es teórico -- determina directamente si tu contenido se indexa en horas o en semanas.

Oleada 1: Rastreo del HTML en Bruto

Googlebot obtiene tu URL y examina la respuesta HTML inicial. En esta etapa no se ejecuta ningún JavaScript. Todo lo que está en el HTML en bruto -- tu etiqueta <title>, meta descripción, etiqueta canonical, enlaces internos, datos estructurados y contenido del cuerpo -- se procesa de inmediato.

Si tu página sirve un <div id="root"></div> casi vacío con un paquete JS voluminoso, Google ve... casi nada. La URL se envía a una cola de renderizado.

Oleada 2: La Cola de Renderizado

El Web Rendering Service (WRS) de Google recoge las URLs en cola y ejecuta JavaScript usando una instancia de Chromium sin interfaz gráfica. En 2026, WRS ejecuta una versión evergreen de Chromium, por lo que admite características modernas de JS. Pero aquí está el problema: la cola de renderizado introduce latencia. Dependiendo de la prioridad de rastreo de tu sitio y la asignación de recursos de Google, este retraso puede ir desde segundos hasta días -- a veces semanas para páginas de menor prioridad.

Por Qué Esto Importa

Cada página que requiere renderizado le cuesta a Google más recursos que una página HTML simple. Eso es un golpe directo a la eficiencia de tu presupuesto de rastreo. La propia documentación de Google afirma que el renderizado consume "muchos recursos" y que es posible que no rendericen todas las páginas. En un sitio de portafolio de 500 páginas, esto probablemente no importa. En un sitio de e-commerce de 50.000 páginas, es la diferencia entre ser indexado y ser ignorado.

// Lo que Googlebot ve en el primer paso con CSR:
<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
</head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>
// ¿Contenido? Cero. ¿Enlaces? Cero. ¿Datos estructurados? Cero.

Realizando una Auditoría de SEO para JavaScript

He realizado docenas de estas auditorías. Aquí está el proceso que consistentemente descubre problemas reales.

Paso 1: Comparar el HTML Renderizado con el HTML en Bruto

Este es tu punto de partida. Para cada plantilla de página crítica, compara lo que hay en la respuesta HTML inicial versus lo que aparece después de la ejecución de JavaScript.

Herramientas para esto:

  • La herramienta de Inspección de URL de Google Search Console (muestra tanto el HTML en bruto como el HTML renderizado)
  • El modo de renderizado JavaScript de Screaming Frog (configúralo para renderizar en la configuración del spider)
  • Chrome DevTools: desactiva JavaScript y recarga la página para ver qué queda

Lo que estás buscando:

Elemento Debe Estar en el HTML en Bruto Puede Depender de JS
Etiqueta <title> ✅ Sí ❌ No
Meta descripción ✅ Sí ❌ No
Etiqueta canonical ✅ Sí ❌ No
Encabezado H1 ✅ Sí ❌ No
Contenido principal del cuerpo ✅ Muy recomendable ⚠️ Arriesgado
Enlaces de navegación interna ✅ Sí ❌ No
Datos estructurados (JSON-LD) ✅ Sí ⚠️ Google dice que está bien, pero server-side es más seguro
Imágenes con texto alternativo ✅ Sí ⚠️ Arriesgado
Contenido de carga diferida debajo del pliegue ⚠️ Depende ✅ Generalmente bien

Paso 2: Buscar Errores de JavaScript

Abre Chrome DevTools, navega a cada plantilla de página y observa la pestaña Console. Los errores de JavaScript pueden silenciosamente impedir que el contenido se renderice. Los culpables habituales son:

  • Llamadas a API que fallan o superan el tiempo de espera (especialmente servicios de terceros)
  • Variables de entorno faltantes en compilaciones de producción
  • Errores de CORS que bloquean las solicitudes de datos
  • Desajustes de hidratación en aplicaciones React/Next.js
// Un patrón común que rompe el renderizado para Googlebot:
fetch('https://api.example.com/products')
  .then(res => res.json())
  .then(data => renderProducts(data))
  .catch(err => console.error(err)); // Falla silenciosamente, la página permanece vacía

Googlebot no reintentará las llamadas a API fallidas. Si ese fetch falla durante el renderizado, tu contenido no existe desde la perspectiva de Google.

Paso 3: Auditar los Enlaces Dependientes de JavaScript

Este punto perjudica constantemente a la gente. Si tus enlaces internos son generados por JavaScript -- especialmente la navegación activada por clics, la paginación de desplazamiento infinito o los menús inyectados dinámicamente -- es posible que Googlebot no descubra esos enlaces en absoluto.

Verifica que los enlaces de navegación críticos existan como elementos <a href="/ruta"> adecuados en el HTML inicial. Los enlaces creados con manejadores onclick, redirecciones window.location, o enrutamiento específico de framework que no produce etiquetas de anclaje reales son invisibles para los rastreadores en el primer paso.

Paso 4: Probar con la Prueba de Compatibilidad con Dispositivos Móviles de Google

Esta herramienta utiliza el mismo WRS que Google usa para la indexación. Te muestra exactamente lo que Google ve después del renderizado. Pasa tus plantillas clave por ella y busca contenido faltante, recursos bloqueados o problemas de diseño.

Auditoría de SEO Móvil: Más Allá del Diseño Responsive

Google completó el cambio a la indexación mobile-first para todos los sitios en 2024. Esto significa que la versión móvil de tu página es la que Google indexa. No la versión de escritorio. La versión móvil. Sin excepciones.

La mayoría de los desarrolladores piensan "usamos CSS responsive, estamos bien." Eso es lo mínimo. Una auditoría real de SEO móvil va más profundo.

Paridad de Contenido

Cada pieza de contenido en tu página de escritorio también debe estar presente y ser accesible en móvil. Esto incluye:

  • Contenido de texto completo (no truncado detrás de botones "Leer más" que requieren clics de JS)
  • Enlaces internos en menús de navegación (incluso si están contraídos detrás de un icono de hamburguesa, las etiquetas <a> deben estar en el DOM)
  • Marcado de datos estructurados (el mismo JSON-LD en móvil y escritorio)
  • Texto alternativo de imágenes
  • Meta etiquetas (canonical, robots, hreflang)

He visto sitios donde el mega-menú de escritorio contenía más de 200 enlaces internos, pero el menú hamburguesa para móvil cargaba sus enlaces dinámicamente mediante un evento de clic de JavaScript. Google estaba indexando la versión móvil y no veía ningún enlace de navegación. Su distribución interna de PageRank quedó destruida.

Core Web Vitals en Móvil

Las señales de experiencia de página de Google se miden en móvil. En 2026, estos umbrales siguen aplicándose:

Métrica Bueno Necesita Mejora Deficiente
LCP (Largest Contentful Paint) ≤ 2,5s ≤ 4,0s > 4,0s
INP (Interaction to Next Paint) ≤ 200ms ≤ 500ms > 500ms
CLS (Cumulative Layout Shift) ≤ 0,1 ≤ 0,25 > 0,25

Para sitios con mucho JavaScript, INP suele ser el problema. Los paquetes JS grandes bloquean el hilo principal, haciendo que las interacciones sean lentas. Esto es lo que hacemos habitualmente:

// Antes: Un paquete masivo
import { everything } from './megaModule';

// Después: División de código y carga diferida
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));

También presta atención al CLS causado por contenido inyectado dinámicamente -- anuncios, imágenes sin atributos de dimensión o fuentes que provocan cambios de diseño. Establece width y height explícitos en las imágenes y usa font-display: swap con fuentes precargadas.

Problemas de Renderizado en Móvil

Prueba tus páginas en dispositivos móviles reales, no solo en la emulación de dispositivos de Chrome DevTools. Los dispositivos reales tienen menos memoria, CPUs más lentas y conexiones de red más inestables. Una página renderizada con JavaScript que funciona bien en DevTools podría agotar el tiempo de espera en un teléfono Android de gama media -- y ese teléfono Android de gama media es lo que la mayor parte del mundo realmente usa.

Usamos BrowserStack y laboratorios de dispositivos reales para esto. La propia infraestructura de pruebas de Google funciona con hardware moderado, así que si tu página no puede renderizarse rápidamente en un Pixel 6, tienes un problema.

JavaScript SEO Audit, Mobile SEO & Crawl Budget Optimization - architecture

Presupuesto de Rastreo: Qué Es y Por Qué Importa

El presupuesto de rastreo es el número de páginas que Googlebot rastreará en tu sitio dentro de una ventana de tiempo determinada. Está determinado por dos factores:

  1. Límite de velocidad de rastreo: Qué tan rápido puede rastrear Google sin sobrecargar tu servidor
  2. Demanda de rastreo: Cuánto quiere rastrear Google según la importancia y la actualidad de la página

Para sitios con menos de 10.000 páginas y servidores rápidos, el presupuesto de rastreo generalmente no es una preocupación. Google llegará a todo. Pero una vez que tratas con 50.000+ URLs -- catálogos de e-commerce, sitios de contenido extenso, plataformas SaaS con contenido generado por usuarios -- el presupuesto de rastreo se convierte en una restricción real.

Señales de que Tienes un Problema de Presupuesto de Rastreo

  • Las páginas nuevas tardan semanas en indexarse
  • Google Search Console muestra una gran brecha entre "Descubierto - actualmente no indexado" y "Rastreado - actualmente no indexado"
  • Los logs del servidor muestran a Googlebot rastreando repetidamente páginas de bajo valor (URLs con parámetros, paginación antigua, resultados de búsqueda interna)
  • Tu sitemap XML tiene URLs que no han sido rastreadas en más de 30 días

Estrategias de Optimización del Presupuesto de Rastreo

Estas son las tácticas específicas que han movido la aguja en los proyectos en los que hemos trabajado. Están ordenadas aproximadamente por impacto.

1. Eliminar el Desperdicio de Rastreo

La corrección del presupuesto de rastreo con mayor retorno de inversión es dejar de que Google pierda tiempo en URLs que no deberían rastrearse. Los infractores habituales son:

  • Navegación facetada: /zapatos?color=rojo&talla=40&marca=nike genera miles de combinaciones de parámetros. Usa robots.txt para bloquear estos patrones o implementa etiquetas canonical adecuadas que apunten a la página de categoría base.
  • Páginas de resultados de búsqueda interna: /buscar?q=widgets+azules -- siempre bloquéalas en robots.txt.
  • IDs de sesión y parámetros de seguimiento: /producto?sid=abc123&utm_source=email -- manéjalos con etiquetas canonical o el manejo de parámetros en Search Console.
  • Paginación infinita: /blog/pagina/47 con dos publicaciones no vale la pena rastrearla. Usa noindex en páginas de paginación profunda.
# robots.txt - bloquear desperdicio de rastreo
User-agent: *
Disallow: /search
Disallow: /*?sid=
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /internal/

2. Corregir las Cadenas de Redirecciones

Cada redirección en una cadena consume un rastreo. A → B → C → D significa que Google usó cuatro rastreos para llegar a una página. Audita tus redirecciones y aplana las cadenas a saltos únicos. Screaming Frog facilita esto -- rastrea tu sitio y filtra por cadenas de redirección de más de un salto.

3. Servir Señales SEO del Lado del Servidor

Aquí es donde el SEO para JavaScript y la optimización del presupuesto de rastreo se intersectan. Cada página que requiere renderizado consume más recursos de rastreo. Al servir contenido crítico, meta etiquetas, etiquetas canonical y enlaces internos en la respuesta HTML inicial, reduces la carga en el pipeline de renderizado de Google.

Esta es exactamente la razón por la que recomendamos frameworks como Next.js con SSR/SSG o Astro para sitios críticos en SEO. Si estás evaluando opciones, echa un vistazo a nuestras capacidades de desarrollo con Next.js o servicios de desarrollo con Astro -- hemos construido sitios con ambos específicamente para resolver estos desafíos de renderizado.

4. Optimizar los Sitemaps XML

Tu sitemap debe ser una lista curada de páginas que quieres indexar, no un volcado autogenerado de todas las URLs de tu sitio. Reglas:

  • Solo incluye páginas que devuelven códigos de estado 200
  • Solo incluye URLs canónicas (no URLs que apunten con canonical a otra cosa)
  • Elimina las páginas con noindex
  • Incluye fechas <lastmod> precisas (Google las usa para priorizar el rastreo)
  • Divide los sitemaps grandes en grupos lógicos (productos, categorías, entradas de blog)

5. Mejorar los Tiempos de Respuesta del Servidor

La velocidad de rastreo de Google se adapta a la capacidad de tu servidor. Si tu servidor responde lentamente o arroja errores 500, Googlebot reduce su velocidad. Respuestas más rápidas = más páginas rastreadas por sesión.

Apunta a un Time to First Byte (TTFB) inferior a 200ms para tus respuestas HTML. Usa caché en el borde, CDNs y renderizado del lado del servidor eficiente. La generación estática (SSG) es el estándar de oro aquí -- un archivo HTML pregenerado servido desde una CDN es tan rápido como puede ser.

6. Gestionar la Inflación del Índice

El presupuesto de rastreo y el presupuesto de índice están relacionados pero son distintos. Google también mantiene un presupuesto de índice -- el hecho de que una página sea rastreada no significa que vaya a ser indexada. Las páginas con contenido escaso, contenido duplicado o señales de baja calidad son rechazadas.

Audita regularmente tu índice usando búsquedas site:tudominio.com y el informe de Páginas en Search Console. Si encuentras páginas indexadas que no deberían estarlo (páginas antiguas de campañas, URLs de prueba, páginas de etiquetas con poco contenido), elimínalas con directivas noindex o códigos de estado 410.

Server-Side Rendering vs. Client-Side Rendering para SEO

Vamos al grano. Aquí está la comparación práctica:

Enfoque Riesgo SEO Impacto en Presupuesto de Rastreo Esfuerzo de Implementación Mejor Para
Static Site Generation (SSG) Muy Bajo Mínimo -- HTML simple Medio Sitios de contenido, blogs, páginas de marketing
Server-Side Rendering (SSR) Bajo Bajo -- HTML listo en la solicitud Medio-Alto Contenido dinámico, e-commerce, páginas personalizadas
Incremental Static Regeneration (ISR) Bajo Bajo Medio Catálogos grandes que se actualizan periódicamente
Client-Side Rendering (CSR) Alto Alto -- requiere cola de renderizado Bajo (inicialmente) Aplicaciones detrás de autenticación únicamente
Dynamic Rendering Medio Medio Alto SPAs heredadas que no pueden ser refactorizadas

Para páginas críticas en SEO, el CSR casi nunca es la elección correcta. Si estás ejecutando una SPA de React y te preguntas por qué tus páginas no se indexan bien, probablemente esta sea la razón.

El dynamic rendering -- servir HTML prerenderizado a los bots mientras se sirve la SPA a los usuarios -- funciona pero es un dolor de cabeza de mantenimiento, y Google ha insinuado que prefieren que simplemente sirvas el mismo contenido a todos. Es un parche, no una solución.

Los frameworks que más usamos para construcciones enfocadas en SEO son Next.js (con sus capacidades híbridas SSG/SSR/ISR) y Astro (que no envía JavaScript por defecto y lo añade solo donde se necesita). Ambos te dan control total sobre lo que va en la respuesta HTML inicial. Si tu sitio actualmente funciona con un CMS headless y un frontend de JavaScript, este es exactamente el tipo de decisión arquitectónica en la que ayudamos a los clientes a través de nuestros servicios de desarrollo de CMS headless.

Herramientas y Flujos de Trabajo para Auditorías de SEO Técnico

Aquí está el kit de herramientas que realmente uso, no una lista patrocinada:

Rastreo y Renderizado

  • Screaming Frog SEO Spider ($259/año) -- El caballo de batalla. Activa el renderizado JavaScript, establece un agente de usuario personalizado de Googlebot y rastrea todo tu sitio. Compara el HTML renderizado con el HTML en bruto para cada URL.
  • Sitebulb ($152/año para escritorio) -- Mejor visualización que Screaming Frog. Excelente para explicar problemas de rastreo a partes interesadas no técnicas.
  • Chrome DevTools -- Gratis. Esencial para depurar problemas de renderizado JS, revisar solicitudes de red y perfilar el rendimiento.

Análisis de Archivos de Log

  • Screaming Frog Log File Analyser (incluido con la licencia de SEO Spider) -- Importa tus logs de acceso del servidor y ve exactamente qué URLs está visitando Googlebot, con qué frecuencia y qué códigos de estado está obteniendo.
  • Botify (precios empresariales) -- Si estás tratando con millones de URLs, Botify combina datos de rastreo, datos de log y datos de Search Console en un solo lugar. Caro pero vale la pena a escala.

Datos de Search Console

  • Google Search Console -- Gratis. El informe de Páginas muestra el estado de indexación de cada URL. El informe de Estadísticas de Rastreo muestra el comportamiento de Googlebot en tu sitio. Usa ambos.
  • Search Console API + BigQuery -- Para sitios grandes, exporta tus datos a BigQuery para análisis personalizados. Puedes cruzar datos de rastreo con archivos de log para encontrar páginas que Google está ignorando.

Pruebas de Rendimiento

  • PageSpeed Insights -- Usa datos reales del Chrome UX Report (CrUX) más datos de laboratorio de Lighthouse. Siempre prueba la versión móvil.
  • WebPageTest -- Más detallado que PageSpeed Insights. Usa la vista de tira de película para ver exactamente cuándo el contenido se vuelve visible.

Flujo de Trabajo

Para una auditoría típica de SEO técnico, este es el orden que sigo:

  1. Obtener 90 días de logs del servidor y filtrar por actividad de Googlebot
  2. Ejecutar un rastreo completo de Screaming Frog con renderizado JS activado
  3. Exportar datos de Search Console (páginas indexadas, estadísticas de rastreo, Core Web Vitals)
  4. Cruzar referencias: ¿Qué páginas están en tu sitemap pero no se están rastreando? ¿Cuáles se están rastreando pero no indexando? ¿Dónde está gastando más tiempo Googlebot?
  5. Probar de 5 a 10 plantillas de páginas clave para problemas de renderizado JS
  6. Ejecutar pruebas de rendimiento móvil en todas las plantillas
  7. Priorizar las correcciones por impacto × esfuerzo

Poniéndolo Todo Junto: Una Lista de Verificación de Auditoría

Aquí está la lista de verificación condensada que usamos internamente. Cópiala, adáptala, úsala.

SEO para JavaScript

  • Contenido crítico visible en el HTML en bruto (JS desactivado)
  • Título, meta descripción, canonical en el HTML inicial
  • Los enlaces internos son elementos <a href> reales en el DOM
  • Sin errores de JavaScript que bloqueen el renderizado
  • Datos estructurados presentes en el HTML inicial
  • Las llamadas a API que rellenan el contenido son fiables y rápidas
  • Tamaño del paquete inferior a 300KB comprimido para el hilo principal

SEO Móvil

  • Paridad de contenido completa entre móvil y escritorio
  • Enlaces de navegación móvil en el DOM (no inyectados por clic de JS)
  • LCP inferior a 2,5s en móvil
  • INP inferior a 200ms en móvil
  • CLS inferior a 0,1 en móvil
  • Objetivos táctiles de al menos 48x48px
  • Sin desplazamiento horizontal en viewports móviles
  • Meta etiqueta viewport presente y correcta

Presupuesto de Rastreo

  • Navegación facetada bloqueada o con canonical
  • Páginas de búsqueda interna bloqueadas en robots.txt
  • Sin cadenas de redirección de más de 1 salto
  • El sitemap XML contiene solo URLs indexables, canónicas con estado 200
  • TTFB inferior a 200ms para respuestas HTML
  • Sin páginas huérfanas (cada página importante está enlazada desde al menos otra página)
  • Paginación profunda gestionada (noindex o bloqueada más allá de la página 5-10)
  • El análisis del log del servidor muestra a Googlebot enfocado en páginas de alto valor

Si estás mirando esta lista y pensando "necesitamos ayuda" -- eso es lo que hacemos. Consulta nuestros precios o contáctanos directamente. Nos especializamos en construir y arreglar sitios headless donde exactamente estos problemas tienden a surgir.

Preguntas Frecuentes

¿Cómo afecta el JavaScript al presupuesto de rastreo? Las páginas renderizadas con JavaScript requieren que Google pase por un proceso de dos etapas: primero rastrear el HTML en bruto y luego poner en cola la página para su renderizado. Este paso de renderizado consume recursos adicionales de la infraestructura de Google, lo que significa que se procesan menos páginas tuyas en una sesión de rastreo determinada. Las páginas que sirven contenido en el HTML inicial son más baratas de procesar para Google, por lo que se rastrean e indexan más de ellas.

¿Puede Google renderizar frameworks modernos de JavaScript como React y Vue? Sí. El Web Rendering Service de Google ejecuta una versión evergreen de Chromium que admite JavaScript moderno, incluidos módulos ES, async/await y APIs DOM modernas. El problema no es la capacidad -- es el coste y la latencia. Google puede renderizar tu aplicación React, pero es más lento y consume más recursos que leer HTML simple. Para páginas críticas en SEO, debes servir HTML prerenderizado mediante SSR o SSG.

¿Cuál es la diferencia entre presupuesto de rastreo y presupuesto de índice? El presupuesto de rastreo determina cuántas páginas Google obtendrá de tu sitio en un período determinado. El presupuesto de índice determina cuántas de esas páginas rastreadas Google añadirá realmente a su índice de búsqueda. Una página puede ser rastreada pero no indexada si tiene contenido escaso, contenido duplicado, señales contradictorias o problemas de calidad. Necesitas optimizar ambos -- reducir el desperdicio de rastreo para que Google llegue a tus páginas importantes, y asegurarte de que esas páginas sean de suficiente calidad para merecer la indexación.

¿Cómo verifico si Googlebot puede ver mi contenido renderizado con JavaScript? Usa la herramienta de Inspección de URL de Google Search Console. Ingresa cualquier URL y haz clic en "Probar URL en vivo". Te mostrará el HTML renderizado que Google ve después de ejecutar JavaScript. Compara esto con el HTML fuente de tu página (Ver código fuente en tu navegador) para identificar el contenido que depende del renderizado JS. También puedes usar Screaming Frog con el renderizado JavaScript activado para auditar esto a escala.

¿La velocidad de la página en móvil afecta directamente al posicionamiento? Sí. Google usa los Core Web Vitals (LCP, INP, CLS) como señal de posicionamiento, y estos se miden en la versión móvil de tus páginas usando datos de usuarios reales del Chrome UX Report. Una página con malas métricas de rendimiento móvil no se posicionará tan bien como una página equivalente en otros aspectos con buenas métricas. El efecto es más notable para consultas competitivas donde múltiples resultados son similares en calidad y relevancia.

¿Con qué frecuencia debo realizar una auditoría de SEO técnico? Para la mayoría de los sitios, tiene sentido una auditoría completa cada trimestre, con monitoreo continuo de métricas clave en el intermedio. Si estás realizando cambios significativos -- lanzando nuevas plantillas de página, migrando a un nuevo framework o reestructurando la arquitectura de tu sitio -- realiza una auditoría antes y después. Configura alertas automatizadas en Google Search Console para errores de rastreo y caídas de indexación para detectar problemas temprano.

¿Cuál es la mejor estrategia de renderizado para SEO en 2026? Para la mayoría de los sitios, un enfoque híbrido usando un framework como Next.js o Astro te da los mejores resultados. Usa Static Site Generation (SSG) para contenido que no cambia con frecuencia, Server-Side Rendering (SSR) para páginas dinámicas o personalizadas, e Incremental Static Regeneration (ISR) para catálogos grandes que se actualizan periódicamente. Reserva el client-side rendering solo para funciones interactivas que no necesitan ser indexadas, como paneles de usuario o interfaces de administración.

¿Debo usar dynamic rendering para resolver problemas de SEO con JavaScript? El dynamic rendering -- servir HTML prerenderizado a los bots de los motores de búsqueda mientras se sirve una versión renderizada del lado del cliente a los usuarios -- es una solución provisional válida, pero no es una solución a largo plazo. Google lo ha calificado explícitamente como una solución alternativa en lugar de una recomendación. Añade una carga de mantenimiento porque básicamente estás manteniendo dos versiones de cada página. También conlleva riesgo: si tu detección de bots falla o tu servicio de prerenderizado falla, Google de repente ve páginas vacías. Un mejor enfoque es corregir la arquitectura subyacente adoptando SSR o SSG para que todos los usuarios -- humanos y bots -- obtengan la misma respuesta HTML.