JavaScript SEO en la practica: que indexan realmente Google, Bing y Yandex

JavaScript no va a desaparecer del desarrollo web. El problema es otro: mucha gente sigue dando por hecho que, si una pagina se ve bien en el navegador, Google y el resto de buscadores la van a entender igual de bien. No siempre pasa.

Para salir de la teoria, esta pieza se apoya en un experimento sencillo: una pagina cuyo contenido clave dependia casi por completo de JavaScript del lado del cliente. La idea era ver que recogia cada buscador, cuanto tardaba en hacerlo y donde empezaban las limitaciones reales.

Si trabajas con React, Vue, Next.js, Nuxt o cualquier stack con renderizado mixto, esto te toca de lleno. Y si ademas quieres validar tu HTML renderizado antes de publicar, SEO Analyzer te sirve como punto de partida para revisar que ven los crawlers y donde se esta perdiendo senal SEO.

El punto de partida: la indexacion en dos fases

Google no procesa una pagina JS-heavy en una sola pasada. Lo normal es que trabaje en dos olas:

1. Primero rastrea e indexa el HTML inicial.
2. Despues, cuando hay recursos disponibles, renderiza JavaScript y vuelve a evaluar lo que aparece en el DOM final.

Ese desfase es importante. Si el contenido critico solo existe despues de ejecutar JS, no entra en la primera ola.

Eso explica por que algunas paginas se indexan con snippets raros, titulos incompletos o descripciones improvisadas, y solo dias despues se corrigen. O no.

Como estaba montado el experimento

La pagina de prueba era deliberadamente extrema.

• El HTML inicial era casi vacio.
• El <title>, el H1, la meta description y el cuerpo principal llegaban por JavaScript.
• Los datos se cargaban por AJAX.
• El Article schema tambien se inyectaba con JS.

En otras palabras: si el buscador no ejecutaba JavaScript, apenas tenia algo util que indexar.

1$(document).ready(function () {
2  $.ajax({
3    url: '/api/get-article-data',
4    success: function(data) {
5      $('title').text(data.title);
6      $('h1#main-title').text(data.h1);
7      $('meta[name="description"]').attr('content', data.description);
8      $('#article-content').html(data.body);
9
10      var script = document.createElement('script');
11      script.type = 'application/ld+json';
12      script.text = JSON.stringify(data.schemaData);
13      document.head.appendChild(script);
14    }
15  });
16});

El objetivo era simple: si los snippets del buscador cambiaban respecto al HTML inicial, sabriamos que la segunda fase habia ocurrido de verdad.

Lo que si podian renderizar las herramientas de Google

Antes de mirar la SERP, tiene sentido probar si el renderizado funciona en herramientas controladas. En este caso, la prueba de resultados enriquecidos de Google si fue capaz de generar el DOM final y leer los elementos inyectados por JavaScript.

Eso era una buena senal, pero no una garantia de indexacion inmediata. Poder renderizar no significa renderizar ya.

Primera fase: lo que aparecio al principio en la SERP

Pocas horas despues de enviar la URL, Google, Bing y Yandex ya mostraban la pagina. Pero lo que ensegnaban no venia del contenido renderizado, sino del HTML inicial.

Ese punto es clave. La pagina estaba "indexada", si, pero no en la forma en que el usuario la ve al cargarla por completo. Lo que gano la primera carrera fue el HTML de salida, no el JavaScript.

Para SEO, esta diferencia importa mucho cuando dependes de:

• noticias o contenido sensible al tiempo
• landings nuevas que necesitas mover rapido
• titles y descriptions que no puedes dejar a medias
• contenido critico que no puede esperar varios dias en cola

Segunda fase: Google acaba llegando, pero no corre

Tras unos dias, Google si termino procesando el contenido renderizado. Una busqueda site: mostraba ya texto que originalmente solo existia tras ejecutar JavaScript.

La lectura practica es bastante directa: Google puede trabajar con contenido CSR, incluso cuando llega via AJAX, pero eso no significa que lo haga enseguida.

Para muchos proyectos ese retraso es aceptable. Para otros no:

• medios
• ecommerce con cambios frecuentes
• paginas de captacion nuevas
• sitios que dependen de indexacion rapida

Bing y Yandex: aqui es donde se ve la brecha

Durante el experimento, Bing y Yandex no mostraron la misma soltura que Google con el contenido generado en el cliente. Seguian anclados a lo que podian leer del HTML inicial.

Eso no deberia sorprender a nadie que haya trabajado con JS SEO fuera del ecosistema puro de Google. La capacidad de renderizado cambia bastante entre buscadores, y en mercados con motores regionales la diferencia se nota aun mas.

Si tu estrategia depende solo de que "Google ya renderiza JS", te puedes llevar una sorpresa cuando el trafico no venga solo de Google.

La salida intermedia: dynamic rendering

Como prueba adicional, se configuro dynamic rendering. El principio es conocido:

• al usuario normal se le sirve la pagina habitual con JS
• al crawler se le devuelve una version HTML ya renderizada

Despues de eso, Yandex si actualizo el snippet y paso a mostrar el contenido pre-renderizado.

No es una solucion elegante para todo. Tampoco es la primera opcion en un proyecto nuevo. Pero sirve para demostrar algo util: cuando le das al crawler HTML final listo para leer, el problema se reduce mucho.

Lo que este test deja claro

1. Google puede renderizar JS, pero eso no elimina el riesgo SEO

La gran confusion suele ser esta: "Google puede renderizar" se convierte en "da igual como entregue el contenido". No es lo mismo.

Puede renderizar, si. Pero:

• hay cola
• hay retraso
• no todo se procesa con la misma rapidez
• lo que no esta en el HTML inicial pierde inmediatez

2. El HTML inicial sigue siendo tu red de seguridad

Si una pieza es importante para SEO, conviene que estas partes ya existan en la respuesta inicial:

• <title>
• meta description
• H1
• texto principal
• enlaces clave
• datos estructurados importantes

Eso es lo que mejor resiste entre buscadores, y tambien lo que menos depende de una segunda ola incierta.

3. SSR y SSG siguen siendo la opcion mas estable

Si tienes margen tecnico, SSR o SSG siguen siendo el enfoque mas seguro para contenido critico. No porque CSR sea "malo", sino porque no deberias ponerle una cola de renderizado delante a tu title, a tu body principal y a tu enlazado importante.

4. Dynamic rendering es un parche util, no el destino ideal

Puede salvar un proyecto heredado o una migracion complicada. Pero tambien suma complejidad operativa y exige control fino para no acercarte a problemas de cloaking o inconsistencias.

Recomendaciones practicas para equipos SEO y front-end

Si esta prueba la aterrizas a proyectos reales, la lista corta seria esta:

1. No dejes el contenido critico exclusivamente en manos del JS cliente.
2. Prueba siempre que ven los crawlers, no solo lo que ve el navegador.
3. Usa SSR o SSG si el contenido necesita indexarse rapido.
4. Reserva CSR para capas de interaccion, no para la base semantica de la pagina.
5. Si trabajas con stacks heredados, valora pre-render o dynamic rendering como transicion.

En proyectos propios, una revision rapida con SEO Analyzer y una comprobacion de metadata con Meta Tag Generator te ayudan a detectar enseguida si el HTML inicial ya sale con lo minimo imprescindible.

Cierre

El experimento no dice que JavaScript sea enemigo del SEO. Lo que dice es algo bastante mas incomodo: depender del renderizado del lado cliente para exponer contenido clave sigue siendo una apuesta con retrasos, diferencias entre buscadores y demasiadas suposiciones.

Si quieres una regla simple, quedate con esta: deja la experiencia rica al JavaScript, pero entrega el significado SEO esencial en HTML desde el principio. Cuando haces eso, Google te entiende antes, otros buscadores sufren menos y tu equipo duerme mejor.