¿Qué es el JavaScript SEO?

El JavaScript SEO es la parte del SEO técnico que se ocupa de que una web construida con JavaScript pueda pasar por el rastreo, el renderizado y la indexación. No es una disciplina aparte: son las mismas preguntas de siempre, hechas sobre páginas cuyo contenido no está en el HTML que devuelve el servidor.

La diferencia práctica es de momento. En una página clásica, el HTML que llega ya trae el texto, los enlaces y las etiquetas. En una construida en el navegador, ese HTML puede ser casi vacío, y todo lo que importa aparece después, cuando el código se ejecuta.

Conviene decirlo sin alarmismo: Google ejecuta JavaScript y lo hace bien. El problema no es que no pueda, sino que lo hace en otro momento y con condiciones propias, y esas condiciones son las que hay que conocer.

Conviene aclarar de entrada qué no es. No es una cuestión de framework: el mismo framework puede producir una web perfectamente rastreable o una imposible, según cómo se haya montado la entrega. Culpar a la herramienta ahorra la pregunta importante, que es qué llega en la primera respuesta del servidor.

Tampoco es un problema nuevo. Lo que ha cambiado es la proporción: hoy casi cualquier sitio ejecuta algo de código en el navegador, y la diferencia entre uno sano y uno con problemas está en si ese código añade cosas o si sostiene todo lo que importa.

Google describe el proceso en tres fases: rastreo, renderizado e indexación. Entre la primera y la segunda hay una cola, y esa cola es el detalle que cambia todo lo demás.

Su documentación es explícita sobre dos cosas. Primera: toda página que responde con código 200 y no lleva una instrucción de no indexar entra en la cola de renderizado. Segunda: puede quedarse ahí unos segundos, pero también más tiempo. No hay una cifra fija, y por eso no conviene planificar como si la hubiera.

Y hay un camino de vuelta que casi nunca se dibuja: los enlaces que aparecen al renderizar se vuelven a leer y entran en la cola de rastreo y consumen presupuesto de rastreo. Un enlace que solo existe tras ejecutar el código no es invisible, pero se descubre una fase más tarde que uno escrito en el HTML.

Hay una condición en esa descripción que se lee por encima y decide casos enteros: entran en la cola las páginas que responden con código 200. Una que devuelve un error, o que es un soft 404 disfrazado de 200 con la plantilla vacía, recibe un trato distinto antes de que su código llegue a ejecutarse.

Y una consecuencia que ordena el resto del artículo: todo lo que decide si una URL merece pasar a la fase siguiente se lee ANTES de renderizar. Por eso el X-Robots-Tag, que viaja en la cabecera de la respuesta, llega siempre a tiempo, y una instrucción insertada por código puede no llegar.

El primer fallo, y el más caro, son los enlaces que no lo son. Un elemento que reacciona al clic por programación funciona para el visitante y no es un camino para nadie más; Google pide un enlace con su dirección dentro. Ahí es donde una sección entera acaba convertida en página huérfana.

El segundo son los recursos bloqueados. Si el robots.txt impide cargar los archivos de JavaScript, el renderizado ocurre igualmente pero sin ellos, y el resultado es una página de contenido pobre indexada. Es un caso que se diagnostica rápido y se pasa por alto durante meses.

Y el tercero son las etiquetas que llegan tarde. Un canonical o un noindex insertados por código pueden no tener el efecto esperado, porque la decisión de encolar para renderizar se toma antes con lo que había en el HTML inicial. Lo importante va en el HTML que entrega el servidor.

Un cuarto fallo aparece en los listados: la paginación construida solo con código. Si el botón de siguiente página no lleva detrás una dirección propia, la paginación no existe para el rastreador, y con ella desaparece la mitad del catálogo aunque cada ficha esté impecable.

Y un quinto, más difícil de ver: el contenido que se carga al hacer scroll o al abrir una pestaña. Es la misma familia que el lazy loading mal montado; si aparece solo cuando alguien interactúa, no está en la página que Google renderiza, porque nadie hace scroll ni pulsa nada durante ese proceso.

La comprobación básica es comparar dos versiones de la misma página: el HTML que entrega el servidor y el HTML después de ejecutar el código. Si el primero está casi vacío, ya sabes que todo depende de la segunda fase.

La inspección de URLs de Search Console enseña exactamente lo que Google renderizó, con los recursos que no pudo cargar y los mensajes de error de la consola. Es la única fuente que responde por Google y no por una simulación; conviene usarla antes que cualquier herramienta de terceros.

Y una comprobación que casi nadie hace: buscar en el HTML inicial los enlaces principales del enlazado interno. Si no están ahí, el descubrimiento del sitio entero depende de la cola de renderizado, y eso se nota primero en las secciones nuevas, que tardan más en aparecer en el índice.

Un método barato para la revisión diaria: pide la página como lo haría un cliente sin navegador y busca en esa respuesta el titular, un párrafo del cuerpo y tres enlaces de la navegación. Si los encuentras, esa página no depende de la segunda fase. Es una comprobación de un minuto que descarta la mitad de las sospechas.

Para lo que no pasa esa prueba, el análisis de logs añade la parte que falta: muestra si el rastreador llegó a pedir los archivos de JavaScript y con qué frecuencia vuelve. Un patrón revelador es que las URLs aparezcan rastreadas pero los recursos que necesitan para renderizarse casi nunca.

El primero es concluir que Google no ejecuta JavaScript. Lo ejecuta, y decirlo al revés lleva a decisiones caras, como rehacer una web entera cuando bastaba con arreglar los enlaces.

El segundo es el contrario: dar por hecho que, como lo ejecuta, no hay nada que vigilar. La cola existe, los recursos se bloquean solos con el tiempo y las etiquetas puestas por código siguen llegando tarde.

Y el tercero es mirar solo la portada. Suele ser la página mejor cuidada del sitio, la más cerca en profundidad de clic, y no representa al resto; los problemas de renderizado se concentran en las fichas generadas en serie, sobre todo en e-commerce, donde además son las que traen el tráfico.

Un cuarto error es medir con la herramienta equivocada y creerle. Cualquier servicio que renderiza con otro navegador, otra red y otros tiempos de espera puede dar un resultado distinto al de Google; sirve para orientarse, no para concluir. La inspección de URLs es la que responde por Google.

Y el último, el más costoso a largo plazo: resolverlo una vez y no volver a mirar. Basta un despliegue que cambie cómo se generan los enlaces para que una sección entera deje de descubrirse, y eso no lanza ninguna alarma — el sitio sigue funcionando perfectamente para quien lo visita con un navegador, que es precisamente por lo que nadie lo nota.