TL;DR: Tu web “se ve” porque el navegador ejecuta JavaScript… pero Google puede estar viendo un HTML vacío, un loader infinito o contenido que nunca llega a renderizar. Resultado: páginas que no indexan, impresiones que se caen y keywords que no levantan. Abajo te dejo un diagnóstico rápido con Search Console (inspección + render + recursos bloqueados) y las salidas más sensatas: SSR o prerender (si aplica), más fixes puntuales.
El síntoma típico (y por qué confunde tanto)
Te pasa así: abres la web, navegas, todo carga bonito. “Listo, está ok”.
Y luego miras:
- Search Console con impresiones en caída,
- páginas “descubiertas/no indexadas”,
- o directamente… no apareces ni con
site:.
Ahí es cuando digo: alertas rojas.
Porque en JavaScript hay un detalle clave:
- El usuario ve el resultado final (después de que el navegador ejecuta JS).
- Google primero ve lo que recibe como HTML… y recién después intenta renderizar.
Si en ese camino algo falla (recursos bloqueados, render lento, links no rastreables, contenido detrás de interacción), Google se queda con una versión incompleta. Y no es que “te odie”: es que no lo pudo procesar bien.
Qué está pasando de verdad (explicación corta, de negocio)
Piensa en esto como 3 pasos:
- Google llega a la URL (crawl).
- Intenta “armar” la página (render).
- Decide qué indexa y cómo la entiende (index).
En un sitio clásico (HTML servido desde el servidor), ya en el paso 1 hay contenido.
En un sitio súper JS (SPA), a veces en el paso 1 solo hay un cascarón tipo:
- un
<div id="app"></div> - un loader
- y 30 scripts
Y si el render no se completa bien, Google se queda con el cascarón.
Diagnóstico: confirma si el problema es JavaScript (sin adivinar)
Paso 1 – Inspección de URL en Search Console (la herramienta que manda)
En Search Console:
- abre Inspección de URL,
- usa Probar URL publicada,
- y busca la parte donde te deja ver la página que Google “vio” (render).
Pregunta clave:
¿El contenido importante (H1, texto, enlaces internos) aparece en el render… o está vacío/incompleto?
Si en el render falta el contenido que convierte o posiciona, ya tienes la causa.
Paso 2 – Comparación rápida: “Ver código fuente” vs DOM renderizado
Haz esta prueba simple:
- Ver código fuente (view-source): ¿hay contenido real o solo el contenedor vacío?
- Inspeccionar elemento: ¿el contenido aparece recién después de que carga JS?
No es “malo” que aparezca después… pero si Google no lo alcanza a procesar, es un problema.
Paso 3 – Recursos bloqueados: el asesino silencioso
Cosas que he visto mil veces:
- robots.txt bloqueando carpetas de JS/CSS,
- assets cargados desde dominios con restricciones,
- APIs que fallan para Googlebot,
- errores intermitentes (5xx),
- scripts tan pesados que el render queda “a medias”.
Si el render depende de recursos que Google no puede cargar, Google ve una página coja.
Paso 4 – Render “tarde” (cuando llega, pero llega tarde)
Casos típicos:
- skeletons eternos,
- loading infinito,
- contenido que solo aparece cuando haces scroll (lazy load agresivo),
- tabs/acordeones donde el texto clave solo existe si haces clic.
Consejo práctico: si lo importante no está en el above-the-fold (o no existe sin interacción), Google puede no tomarlo como señal principal.
Paso 5 – Enlaces y rastreabilidad (cuando el interlinking depende de JS)
Esto también mata:
- menús que parecen links pero son botones sin
href, - enlaces generados solo por JS y que no quedan claros en el HTML renderizado.
Si Google no encuentra enlaces rastreables, le estás cortando las “calles” internas del sitio.
Causas típicas (las 7 más comunes, sin vueltas)
- SPA que entrega HTML vacío y todo depende de JS.
- Recursos bloqueados (robots.txt, permisos, CORS, assets externos).
- Render lento o incompleto (demasiados scripts, timeouts, errores).
- Contenido detrás de interacciones (tabs/acordeón que no renderiza por defecto).
- Lazy loading agresivo (Google ve el contenido principal tarde o nunca).
- Rutas/enlaces no rastreables (onclick sin href, “links falsos”).
- Diferencias raras entre lo que ve usuario vs bot (a veces parece cloaking “sin querer”).
Cómo solucionarlo (qué hacer según tu caso)
Opción A – SSR (lo ideal cuando SEO importa de verdad)
SSR = servir el HTML ya armado desde el servidor y luego hidratar con JS.
¿Por qué ayuda? Porque Google recibe contenido real desde el inicio.
Ideal para:
- páginas de servicio,
- categorías,
- landings,
- posts pilares,
- y cualquier URL “dinero”.
Si tu sitio es “moderno” pero vive del orgánico, SSR suele ser la jugada inteligente.
Opción B – Prerender (si no puedes SSR todo)
Prerender = generar HTML estático para rutas clave.
Útil cuando:
- no quieres tocar toda la arquitectura,
- pero sí necesitas que las páginas importantes sean indexables y rápidas.
Ideal para:
- home,
- servicios,
- categorías top,
- páginas de marca,
- contenido que más convierte.
Opción C – Arreglar recursos + render (cuando el problema es bloqueo/errores)
A veces no necesitas cambiar de enfoque; solo hay un bloqueo o una mala implementación:
- desbloquear JS/CSS si corresponde,
- asegurarte que el contenido crítico se renderiza sin scroll/interacción,
- convertir “botones” en enlaces reales donde toca,
- reducir scripts pesados y dependencias.
¿Y dynamic rendering?
Yo lo dejo como último recurso. Funciona, pero suele traer mantenimiento extra y te mete complejidad que después nadie quiere tocar.
Cuando esto pega más fuerte: ecommerce y sitios grandes
En sitios masivos, un fallo de render no te rompe “una página”. Te rompe miles.
Ejemplos:
- filtros que generan URLs que Google no puede procesar,
- categorías que se ven bonitas pero llegan vacías a bots,
- enlaces internos que dependen de JS y no quedan rastreables,
- render pesado que agota rastreo.
Si estás en ese escenario (ecommerce grande o catálogo con muchas URLs), ahí ya no es “arreglar un bug”: es SEO técnico a escala. Para eso existe nuestro servicio de SEO técnico para sitios masivos (cuando hay problemas grandes y hay que resolverlos con método).
Checklist express (10 minutos) para saber si es JavaScript
- Search Console → Inspección de URL → ¿el render muestra el contenido clave?
view-source:→ ¿hay contenido o solo un contenedor vacío?- ¿robots.txt bloquea rutas de assets importantes?
- ¿tus links internos existen como
<a href>? - ¿el contenido aparece solo después de scroll o clic?
Si 2–3 de estas fallan, ya sabes por qué “se ve” pero no posiciona.
Qué haría yo en un rescate real (proceso)
- Confirmo si el problema es render (Search Console + comparación HTML/DOM).
- Identifico rutas dinero y decido: SSR, prerender o fixes puntuales.
- QA: enlaces internos rastreables, indexación, sitemap, recursos.
- Monitoreo: impresiones, cobertura, errores.
Este tipo de problemas aparece muchísimo después de rediseños y migraciones (sobre todo cuando cambiaste de stack/CMS). Si estás en ese punto y quieres soporte de principio a fin para no caer en la “bomba post-lanzamiento”, acá está nuestro servicio de SEO y soporte para migraciones.
Negocio: el costo real de arreglar tarde
Lo caro no es “hacer SEO técnico”. Lo caro es:
- semanas sin impresiones,
- meses sin recuperar posiciones,
- y leads/ventas que no vuelven igual.
Si quieres ver rangos y cómo pensar esto en ROI (sin humo), aquí tienes una guía de Precios SEO.
Si tu web es moderna y el SEO se cayó, no empieces tirando cambios al azar. Primero confirmamos render, y después decidimos: SSR, prerender o fixes puntuales.
Si quieres un diagnóstico 1:1 (y que alguien te diga exactamente dónde está el bloqueo), lo reviso contigo como Experto en SEO Perú.
Y si estás buscando un enfoque integral (contenido + técnico + negocio), lo trabajamos como servicio SEO aquí.
FAQs
¿Google puede indexar sitios en React/Next/Vue?
Sí, pero depende de cómo esté servido el contenido. Si llega vacío o incompleto, vas a sufrir.
¿Qué es SSR y por qué ayuda al SEO?
Porque entrega HTML ya armado. Google recibe señales claras desde el inicio.
¿Prerender es lo mismo que SSR?
No. Prerender genera HTML estático para rutas específicas. SSR renderiza en el servidor bajo demanda (o con estrategias híbridas).
¿Cómo sé si Google ve mi contenido?
Inspección de URL en Search Console y revisa el render. Si no está ahí, no cuentes con que “lo ve”.
¿Qué pasa si bloqueo JS/CSS en robots.txt?
Puedes impedir que Google renderice correctamente. Si Google no puede cargar recursos críticos, entiende peor tu página.
