Tu web puede verse perfecta en el navegador y, aun así, ocultar a Google productos, textos, enlaces internos o metadatos críticos. Los problemas de Resolución de problemas de SEO por JavaScript aparecen cuando Google no puede descubrir, cargar o interpretar contenido esencial, por lo que debes comparar HTML inicial, DOM, Search Console y logs antes de cambiar la arquitectura.
Índice
Anuncio
Diagnostica el bloqueo antes de cambiar código
Comprueba qué contenido llega sin JavaScript y localiza una URL afectada antes de modificar código.
Localiza una URL con una señal clara
Abre Google Search Console, entra en Inspección de URLs, pega la dirección completa y revisa el estado de indexación. Anota si aparece como «Rastreada, actualmente sin indexar», «Descubierta, actualmente sin indexar», «Excluida por la etiqueta noindex» o «Error de servidor (5xx)». Compara una URL correcta, una afectada y una página de negocio prioritaria para no atribuir a JavaScript una caída causada por redirecciones, contenido o canonicals erróneas.
Compara fuente y DOM en Chrome
Abre la URL en Chrome y pulsa Ctrl+U en Windows o Cmd+Option+U en Mac para ver el código fuente. Busca el H1, una frase principal, un producto y un enlace interno relevante. Después abre DevTools con F12, entra en Elements y busca los mismos elementos en el DOM. Si están en el DOM pero no en la fuente, dependen de CSR: el navegador los crea tras descargar y ejecutar scripts.
Ordena el impacto por prioridad comercial
Crea una lista con URL, tipo de página, tráfico previo y síntoma detectado. Prioriza categorías, fichas de producto, servicios, localizaciones y artículos que ya recibían visitas desde Google. Comprueba si hubo rediseño, actualización de tema, plugin de minificación, migración, cambio de CDN o ajuste del banner de cookies en las últimas semanas: esa fecha suele señalar el origen técnico.
Descarta recursos bloqueados y rutas invisibles
Revisa peticiones fallidas y confirma que Googlebot puede cargar recursos y descubrir rutas importantes.
Revisa robots, CDN y seguridad
Escribe tudominio.es/robots.txt y busca reglas Disallow que afecten a /wp-content/, /wp-includes/, archivos .js, rutas API o directorios del tema. Revisa también CDN, firewall y plugin de seguridad para detectar bloqueos por país, desafíos JavaScript, límites de peticiones, reglas anti-bot o cookies obligatorias. No bloquees globalmente /wp-json/ si WordPress usa la API REST para productos, bloques, precios o filtros.
Convierte botones en enlaces rastreables
Inspecciona navegación, filtros, paginación y tarjetas de producto. Un enlace rastreable debe ser un elemento <a> con atributo href y una URL real, no un div, botón o evento onclick. Prueba abrirlo en una pestaña nueva y pegar la URL en incógnito: si no funciona, puede ser invisible para Googlebot y otros buscadores.
Detecta hidratación y carga tardía
Busca errores rojos en Console, como «hydration failed», «mismatch», «undefined» o errores de jQuery. Recarga con una conexión lenta simulada desde Network y observa cuándo aparece el contenido principal. Si categorías o fichas críticas tardan varios segundos en mostrar texto o productos, revisa scripts retrasados, llamadas API y recursos bloqueados.
Contrasta HTML, captura y datos indexados
Compara HTML inicial, DOM, captura de Google y respuesta HTTP para confirmar qué procesa el buscador.
Busca señales SEO dentro del HTML
En el HTML inicial y en la prueba de Search Console, busca <title>, meta name="description", meta name="robots", rel="canonical", hreflang y application/ld+json. Una canonical tardía o duplicada puede hacer que Google elija otra URL; los hreflang deben apuntar a versiones reales, equivalentes e indexables en cada idioma.
Usa esta tabla para decidir el fallo
| Prueba | Debe mostrar | Señal de error | Acción inmediata |
|---|---|---|---|
| Código fuente | H1, texto, enlaces y canonical | Contenedor vacío o «Cargando» | Valorar SSR, SSG o prerenderizado |
| DOM de Chrome | Mismo contenido que la fuente | Contenido solo tras scripts | Revisar CSR, API y errores de consola |
| Search Console | Captura y recursos sin errores | Pantalla incompleta o recurso bloqueado | Quitar bloqueo en robots, CDN o firewall |
| Respuesta HTTP | Estado 200 y HTML coherente | Soft 404, 403 o 5xx | Corregir plantilla, servidor o ruta |
Mide rendimiento sin ocultar el contenido
Pega la URL en PageSpeed Insights y revisa LCP, INP y CLS. Un LCP inferior a 2,5 segundos es una referencia útil, pero una página rápida con H1 ausente, canonical rota o enlaces no rastreables mantiene un problema de SEO técnico.
Para una auditoría de SEO para JavaScript, no basta con comparar dos vistas de la página:
- revisa el código fuente recibido desde el origen, la respuesta HTML que entrega la caché o el CDN, el DOM tras el renderizado de JavaScript y la prueba en vivo de Google Search Console. El HTML inicial debe incluir, como mínimo, el contenido SEO crítico, enlaces y metadatos
- el DOM confirma qué añade el renderizado del lado del cliente
- y la prueba en vivo permite detectar recursos que Googlebot no carga
Si el origen contiene el H1 pero la respuesta del CDN no, purga o corrige la regla de caché. Si ambos lo incluyen y falta en la prueba, investiga scripts, API, robots.txt o bloqueos de seguridad.
Lee los logs para ver a Googlebot de verdad
Consulta logs para verificar qué URL solicita Googlebot, qué respuesta recibe y con qué frecuencia vuelve.
Encuentra errores que gastan rastreo
Agrupa las peticiones por estado HTTP:
- 200 indica respuesta correcta
- 301 y 302 son redirecciones
- 404 señala rutas inexistentes
- 429 indica límites de peticiones
- y 500, 502 o 503 indican fallos de servidor
Repeticiones de 5xx reducen la frecuencia de rastreo, por lo que debes revisar consumo de PHP, memoria, base de datos, WP-Cron y extensiones con llamadas externas.
Detecta respuestas distintas al bot
Compara tamaño de respuesta, estado HTTP y URL final entre Googlebot y un navegador normal. Una diferencia grande puede proceder de caché, geolocalización, consentimiento o reglas de seguridad. El renderizado dinámico solo es aceptable si bots y usuarios reciben contenido principal, enlaces y metadatos equivalentes.
Documenta una muestra útil
Guarda muestras de 7 a 14 días antes y después del cambio con URL, hora, agente, código, bytes enviados, tiempo de respuesta y recurso solicitado. Así separarás una recuperación real de una variación diaria de rastreo y podrás demostrar si Googlebot recibió una respuesta rota antes de renderizar.
Elige el renderizado según cada tipo de URL
Escoge una arquitectura que entregue HTML útil según valor SEO, frecuencia de cambio y recursos técnicos.
Decide con esta comparación práctica
| Modelo | HTML inicial | Actualización | Caso adecuado |
|---|---|---|---|
| CSR | Escaso o vacío | Inmediata desde API | Paneles privados y extras no indexables |
| SSR | Completo en cada petición | Inmediata | Catálogo cambiante y rutas críticas |
| SSG | Completo y cacheable | Al publicar | Servicios, blog y páginas estables |
| ISR | Completo y regenerable | Cada cierto número de minutos u horas | Catálogo amplio con cambios moderados |
| Prerenderizado | Completo en URLs elegidas | Tras cada cambio | Corrección temporal de SPA |
| Renderizado dinámico | Equivalente para bots | Depende de caché | Puente temporal, no solución por defecto |
Aplica un árbol de decisión simple
Elige CSR para paneles privados y extras no indexables; para URLs indexables, utiliza SSR, SSG, ISR o prerenderizado según la frecuencia de cambio.
Mantén equivalentes las versiones
Revisa que SSR, SSG o prerenderizado incluyan el mismo H1, precio, disponibilidad, texto, imágenes relevantes y enlaces que recibe el usuario. Valida sitemap XML, canonicals y paginación: una arquitectura nueva no resuelve URLs duplicadas, filtros indexables sin control ni páginas pobres.
Anuncio
Corrige conflictos de WordPress sin romper ventas
Corrige el síntoma confirmado en staging y valida cada modificación antes de publicar.
Resuelve soft 404 y rutas SPA
Una soft 404 ocurre cuando el servidor responde 200, pero Google interpreta que la página parece vacía, inexistente o sin valor. Revisa URL en incógnito, estado HTTP, texto visible y canonical. Si un producto ya no existe, devuelve 404 o 410 cuando corresponda, o aplica 301 a una alternativa realmente equivalente.
Repara API, lazy load y paginación
Si desaparecen productos, precios o bloques, identifica en Network la llamada Fetch/XHR fallida. Un 401 o 403 suele indicar permisos, firewall o cookies; un 500 apunta a PHP, base de datos, memoria o conflictos. Mantén paginación HTML con URLs y enlaces href, aunque JavaScript mejore después la experiencia de infinite scroll.
Revisa señales generadas por scripts
Busca una sola canonical, meta robots correcto y Schema.org coherente en la fuente y en Search Console. Los datos Product deben reflejar precio y disponibilidad visibles. Los banners de consentimiento no deberían ocultar contenido editorial, enlaces ni navegación básica hasta aceptar cookies.
Usa un diagnóstico por síntomas para evitar cambios de arquitectura innecesarios:
- una URL con estado 200, plantilla vacía y aviso de soft 404 suele requerir contenido útil o un 404/410 real
- un mensaje de hydration mismatch se confirma en Console y suele resolverse igualando los datos renderizados en servidor y cliente
- productos ausentes se verifican en Network mediante una petición API con 401, 403 o 500 y exigen corregir permisos, firewall o servidor. Si una ruta SPA solo funciona tras pulsar un botón, crea una URL accesible con un enlace
<a href> - si el lazy loading no carga contenido al abrir la página, muestra los elementos prioritarios sin interacción y conserva paginación HTML rastreable
Dudas habituales
¿Google puede rastrear una web con JavaScript?
Sí, Googlebot puede ejecutar JavaScript, pero no garantiza que procese recursos al instante ni descubra enlaces tras una interacción. Las URLs importantes deben ofrecer HTML útil, enlaces con href y respuestas HTTP correctas.
¿Cómo sé si Google ve mi contenido dinámico?
Compáralo en código fuente, DOM de Chrome, prueba en vivo de Search Console y logs del servidor. Si solo está en el DOM, comprueba durante 7 a 14 días si Google lo rastrea e indexa correctamente.
¿Debo quitar JavaScript de WordPress?
No hace falta quitar JavaScript. Evita que H1, texto principal, enlaces, canonical o datos estructurados dependan exclusivamente de un script que puede fallar o cargarse tarde.
¿Qué plugin causa más fallos de renderizado?
No existe uno único. Los conflictos aparecen a menudo en plugins de caché, minificación, retraso de scripts, seguridad, cookies y filtros de WooCommerce.
¿Cuánto tarda Google en reflejar el arreglo?
La prueba en vivo puede mostrar cambios en minutos, pero la indexación depende del siguiente rastreo. Vigila cobertura, impresiones y clics durante varias semanas.
¿El renderizado dinámico penaliza en Google?
No penaliza si bots y usuarios reciben contenido equivalente. Úsalo como puente temporal, porque mantener dos rutas de entrega aumenta riesgos de caché desactualizada y diferencias.
Valida el despliegue y prepara la reversión
Publica un cambio cada vez y confirma que Google recibe una versión completa, estable y rastreable.
Sigue un calendario de comprobación
Durante las primeras 24 horas, revisa errores 4xx y 5xx, recursos JavaScript y formularios comerciales. A los 3 o 7 días, consulta logs de Googlebot y solicita indexación solo para URLs prioritarias. A las 2 semanas, compara impresiones, clics, indexación y exclusiones; a las 4 o 6 semanas, revisa rendimiento y resultados comerciales.
Define el punto de reversión
Conserva la configuración anterior y una copia de seguridad verificada. Si aparecen errores de checkout, formularios, 5xx, caída de HTML o pérdida de funciones esenciales, revierte el último cambio y restaura el servicio. Escala a un especialista si hay arquitectura headless, miles de URLs SPA, diferencias entre bots y usuarios o conflictos que afecten a pagos.
Anuncio
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
- ¿Qué es la solución de problemas de SEO en JavaScript? — clickrank.ai
- ▷ Optimiza el JavaScript en WordPress ◁ Sin ser experto — sergiocanales.com
- Cómo solucionar problemas de javascript en seo paso a ... — sedestral.com
- Cómo solucionar errores de JavaScript — aioseo.com
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.