JavaScript SEO: cuando tu web carga, pero Google no la ve

JavaScript SEO es la disciplina que evita una paradoja muy moderna: una web que se abre bien en el navegador, luce rápida, responde, anima botones, despliega menús y, sin embargo, llega incompleta al índice de Google. No hablamos de magia negra ni de una conspiración del algoritmo con capucha. Hablamos de algo más prosaico: cómo Google rastrea, renderiza e interpreta una página cuando buena parte del contenido, los enlaces, los datos estructurados o incluso los títulos dependen de JavaScript. Google sí ejecuta JavaScript con una versión moderna de Chromium, pero eso no convierte cualquier aplicación web en automáticamente comprensible, indexable y competitiva. El matiz pesa. Mucho.

La clave es esta: cargar no significa ser rastreable, y ser rastreable tampoco garantiza ser indexado o bien posicionado. Google organiza el proceso en fases de rastreo, renderizado e indexación; durante ese camino puede encontrar bloqueos en robots.txt, respuestas HTTP incorrectas, enlaces que no son enlaces de verdad, canonicals contradictorios, contenido que aparece solo tras una acción del usuario o scripts que fallan como una persiana vieja a media mañana. El resultado suele ser cruel porque no siempre rompe la web ante los ojos del cliente. Rompe la versión que ve Googlebot. Y esa versión, para un negocio digital, es la que paga la fiesta.

Durante años se repitió que Google “no entendía JavaScript”. Era una verdad cómoda, de esas que sobreviven en auditorías copiadas y pegadas. Hoy es inexacta. Desde el salto al Googlebot evergreen, Google usa un renderizador basado en Chromium actualizado, capaz de ejecutar muchas funciones modernas de la plataforma web. Eso incluye JavaScript contemporáneo, componentes web y APIs que antes eran terreno pantanoso. Pero conviene no confundir capacidad con infalibilidad. Que Google pueda renderizar no significa que vaya a gastar recursos sin límite en una arquitectura que le obliga a hacer doble trabajo. Googlebot es un rastreador, no un becario infinito encerrado en un sótano con café frío.

El problema se agrava porque muchas webs actuales nacen desde el entusiasmo del framework y no desde la realidad del rastreo. React, Vue, Angular, Next.js, Nuxt, SvelteKit o cualquier arquitectura híbrida pueden convivir perfectamente con el SEO, claro. El drama aparece cuando la página inicial entrega un HTML casi vacío, una carcasa elegante y poco más, mientras el contenido importante llega después mediante llamadas de API, hidratación, rutas del cliente y estados que Google debe reconstruir. Para el usuario con buen móvil y fibra, aquello parece un tren japonés. Para un crawler con recursos asignados, puede parecer una estación a oscuras.

Google renderiza JavaScript, pero no firma cheques en blanco

Google procesa las páginas JavaScript pasando primero por el rastreo. Ahí descarga el HTML inicial, comprueba si puede acceder según robots.txt, extrae enlaces presentes en atributos href y decide qué pasa después. En páginas clásicas o renderizadas en servidor, ese HTML ya contiene buena parte de la carne: texto principal, enlaces internos, títulos, productos, categorías, migas de pan. En muchas single-page applications, en cambio, el primer HTML se parece a una habitación vacía con un cartel que dice “vuelva cuando cargue el bundle”. Google puede volver, ejecutar JavaScript y analizar el DOM renderizado, pero ya hemos añadido una segunda escena a la película.

El documento oficial de Google es claro en un punto que suele pasar de puntillas: las páginas con código 200 suelen entrar en la cola de renderizado, y esa cola puede resolverse en segundos o tardar más, según recursos disponibles. Después, un Chromium sin interfaz ejecuta el JavaScript, genera HTML renderizado y Google vuelve a extraer enlaces e indexar contenido desde esa versión. Dicho en castellano de oficina: si el contenido crítico solo existe después de ejecutar scripts, estás obligando a Google a hacer una digestión más pesada. No siempre será un desastre. Pero es una dependencia. Y en SEO técnico las dependencias invisibles son como goteras: no se notan hasta que el techo ya huele raro.

La primera recomendación sensata no es prohibir JavaScript, sino rebajar su protagonismo en lo esencial. El contenido principal, los enlaces internos importantes, el título, la metadescripción, el canonical, los datos estructurados clave y los estados HTTP deberían existir de forma robusta, preferiblemente desde el HTML inicial o mediante renderizado en servidor o generación estática. El JavaScript puede enriquecer, filtrar, animar, personalizar, ordenar, medir, comparar. Perfecto. Pero si el texto que vende una categoría, los productos que deben posicionar o los enlaces que descubren la arquitectura dependen de que todo el cliente se hidrate sin tropiezos, la web se ha convertido en una lámpara bonita conectada a un alargador dudoso.

Aquí entra el gran malentendido de muchas auditorías: ver el código fuente y ver el DOM renderizado no son lo mismo. El código fuente enseña lo que el servidor entrega al principio; el DOM renderizado muestra lo que queda después de ejecutar JavaScript. Google puede usar la segunda versión, sí, pero para diagnosticar problemas conviene mirar ambas. Una categoría de ecommerce que en el navegador muestra 40 productos puede entregar en el HTML inicial tres div, un app-root y un archivo JavaScript de medio megabyte. Una ficha de producto puede enseñar precio, stock, opiniones y variantes al usuario, mientras el HTML inicial apenas ofrece el nombre del sitio y una promesa de carga. Fantástico para el frontend. Bastante menos fantástico para quien necesita señales limpias.

Los errores que hacen invisible una web sin romperla

El error más frecuente en JavaScript SEO no es una pantalla en blanco. Ojalá. Eso se detecta rápido, con gritos en Slack y capturas de pantalla. El error habitual es más fino: contenido parcial, enlaces que no se descubren, canonicals que cambian tarde, páginas de error que responden 200, imágenes cargadas solo al hacer scroll, filtros que generan rutas imposibles, botones que parecen enlaces pero no lo son. Todo funciona “para mí”, frase peligrosísima en cualquier reunión técnica.

Google solo puede descubrir enlaces de forma fiable cuando son elementos a con atributo href. Un botón con un onclick, un div disfrazado de tarjeta enlazable o una navegación que depende de fragmentos tipo #/categoria puede ser cómoda para el desarrollador, pero no es una señal clara de rastreo. La documentación de Google recomienda usar la History API en aplicaciones de una sola página y evitar fragmentos para cargar contenido diferente, porque los fragmentos no funcionan como URLs independientes y fiables para Googlebot.

El segundo clásico es el soft 404 en SPA. La web recibe cualquier ruta, responde 200 y deja que JavaScript decida si existe el producto, la categoría, el artículo o el perfil. Si no existe, pinta una página de “no encontrado” muy mona, con su ilustración simpática y su botón de volver. Pero el servidor ha dicho 200. Para Google, aquello puede parecer una página válida con contenido pobre o duplicado. Google recomienda usar códigos HTTP significativos, como 404 para páginas inexistentes o 401 para contenido detrás de login, y en aplicaciones renderizadas en cliente propone redirigir a una URL que responda 404 o aplicar noindex en páginas de error.

El canonical dinámico merece su propio rincón de vergüenza. Google admite que un canonical se puede inyectar con JavaScript, pero recomienda establecerlo en HTML cuando sea posible y evitar contradicciones entre el canonical inicial y el que se cambia después. Cuando una página nace con un canonical, luego JavaScript lo modifica, otro script añade un segundo canonical y el CMS aporta un tercero por deporte, no estamos optimizando: estamos montando una tertulia dentro del head. Google advierte que múltiples canonicals o implementaciones contradictorias pueden producir resultados inesperados. “Inesperados”, en documentación técnica, suele significar “luego no vengas llorando”.

Otro punto delicado es el noindex. Si una página llega con noindex en el HTML inicial y JavaScript intenta quitarlo después, la jugada puede salir mal porque Google puede detectar ese noindex y saltarse el renderizado o la ejecución posterior. Es una trampa fina: el equipo cree que el script corrige la directiva, pero el robot quizá nunca llegue a ejecutar esa corrección. Para una migración, una preproducción mal cerrada o una plantilla heredada, este detalle puede convertir medio sitio en una persiana bajada.

La caché también juega. Googlebot cachea agresivamente recursos para reducir peticiones, y el Web Rendering Service puede ignorar cabeceras de caché. Por eso Google recomienda fingerprinting en archivos JavaScript y CSS, de modo que cada cambio importante genere un nombre distinto, como main.2bb85551.js. Parece una minucia de build, pero no lo es: si Google renderiza una página con un JS antiguo y un HTML nuevo, o al revés, aparecen errores fantasmas. La web del usuario va bien; la del bot queda descosida.

Renderizado en servidor, estático o cliente: no todo vale igual

La discusión entre SSR, SSG y CSR se ha llenado de siglas, y las siglas, como los ambientadores baratos, a veces tapan el olor sin limpiar nada. CSR, o renderizado en cliente, significa que el navegador recibe una base mínima y construye la página con JavaScript. SSR, renderizado en servidor, genera el HTML completo cuando llega la petición. SSG, generación estática, crea HTML por adelantado durante el build. Las tres opciones tienen usos legítimos. Lo absurdo es aplicarlas igual a una home corporativa, una app interna, una categoría con 10.000 productos, una ficha indexable y un dashboard detrás de login.

Para SEO, el criterio práctico es bastante terrenal: cuanto más importante sea una URL para captar tráfico orgánico, más contenido útil debería estar disponible sin depender de una larga coreografía de scripts. El renderizado en servidor puede entregar HTML completo y reducir viajes adicionales de datos y plantillas en el cliente. Web.dev señala que el SSR suele producir un First Contentful Paint rápido y puede ayudar a reducir bloqueo del hilo principal al enviar menos JavaScript al dispositivo, aunque también puede aumentar el Time to First Byte si el servidor tarda en generar la respuesta. No hay milagro gratis. Hay ingeniería.

La generación estática funciona especialmente bien para páginas previsibles: artículos, landings, categorías poco volátiles, documentación, comparativas, páginas locales, guías de producto. Entrega HTML ya preparado, rápido, cacheable, fácil de rastrear. El renderizado en servidor encaja mejor cuando la página necesita datos actualizados en cada petición o una personalización controlada. El renderizado en cliente, por su parte, tiene sentido para interacciones secundarias: filtros visuales, módulos de recomendación, comparadores, dashboards privados, configuradores o capas que no sostienen la indexación principal. El conflicto nace cuando el CSR se usa por inercia para todo, como quien echa picante a un café.

Las arquitecturas híbridas modernas han rebajado la guerra santa. Next.js, Nuxt, Astro, Remix o SvelteKit permiten mezclar generación estática, renderizado en servidor, streaming, islands architecture, componentes de servidor y pequeñas islas de interacción. La dirección razonable es menos “todo JavaScript” y más HTML primero, JavaScript después. No por nostalgia noventera, sino por resiliencia. El HTML sigue siendo el idioma base del rastreo, de la accesibilidad, del rendimiento y, cada vez más, de la visibilidad en sistemas que no renderizan con la paciencia de Google.

Un ejemplo concreto: una tienda online que depende de JavaScript para pintar sus fichas de producto puede mostrar al usuario título, precio, valoración, disponibilidad y descripción. Si el HTML inicial solo contiene el contenedor vacío, Google quizá lo vea tras renderizar. Pero otros crawlers no. Y aunque Google lo procese, cada ficha exige más recursos. Si esa misma tienda sirve desde el servidor el nombre, descripción, precio, imagen principal, breadcrumbs, canonical, marcado Product y enlaces a categorías relacionadas, el JavaScript queda para cambiar variantes, actualizar stock, abrir galerías o calcular financiación. La diferencia no es estética. Es orgánica.

Ecommerce, filtros y scroll infinito: donde JavaScript se cobra la factura

El ecommerce es el laboratorio donde JavaScript SEO deja de ser una preocupación elegante y se convierte en dinero. Categorías, filtros, paginaciones, variantes, tallas, colores, opiniones, precios dinámicos, disponibilidad por tienda, recomendaciones, carga incremental. Todo pide interacción. Todo pide velocidad. Y todo, mal diseñado, puede esconder justo las URLs que deberían traer tráfico.

Google explica que la paginación, los botones de “cargar más” y el scroll infinito pueden mejorar la experiencia, pero exige que el crawler pueda encontrar el contenido. Y aquí está el golpe: Google rastrea normalmente URLs presentes en atributos href; no hace clic en botones ni dispara funciones JavaScript que requieren acciones del usuario para actualizar el contenido. Una categoría con 800 productos y un botón “ver más” que solo carga mediante evento de clic puede enseñar 800 productos al visitante y apenas una fracción a Google. El escaparate sigue abierto, pero el almacén queda detrás de una puerta sin manilla.

Para que el scroll infinito sea indexable, Google recomienda que cada bloque de contenido tenga una URL persistente y única, que el contenido de esa URL sea estable, que no dependa de fórmulas relativas como ?date=yesterday, y que exista enlazado secuencial entre páginas. La History API permite actualizar la URL cuando el usuario avanza, pero esa elegancia visual no sustituye una arquitectura rastreable.

Los filtros son otro charco. En muchos catálogos, JavaScript permite combinar color, talla, precio, marca, envío, disponibilidad y ordenación. Maravilloso para la conversión; mortal para el rastreo si genera millones de combinaciones indexables sin control. La respuesta no es bloquear todo como quien apaga la luz del edificio. La respuesta es decidir qué facetas merecen URL indexable, qué combinaciones deben quedar fuera, qué parámetros deben canonicalizar, cuáles se enlazan internamente y cuáles viven solo como interacción. Una categoría “zapatillas running mujer” quizá merece URL propia. “zapatillas running mujer azul talla 38 descuento 15% orden precio ascendente” probablemente no necesita desfilar por Google con banda y ramo.

Las imágenes lazy-loaded también tienen su propia letra pequeña. Google recomienda cargar el contenido cuando entra en el viewport y no depender de acciones como clic o scroll manual, porque Google Search no interactúa con la página como un usuario. También advierte contra aplicar lazy loading a contenido visible inmediatamente al abrir la página, ya que puede retrasar lo que el usuario ve primero. Traducido: cargar tarde lo secundario es eficiencia; cargar tarde lo esencial es torpeza perfumada de modernidad.

Core Web Vitals: el JavaScript que se ve y el que pesa

JavaScript SEO no es solo indexación. También es rendimiento. Un sitio puede ser perfectamente rastreable y, aun así, arrastrar una mochila de scripts que machacan la experiencia. Desde marzo de 2024, INP sustituyó a FID como Core Web Vital de interactividad, con el objetivo de medir mejor la capacidad de una página para responder rápido a las acciones del usuario. Esto importa especialmente en webs cargadas de JavaScript, donde el hilo principal puede quedar bloqueado por bundles pesados, hidratación excesiva, terceros indiscretos y componentes que se despiertan todos a la vez como una clase de primaria después del recreo.

Los Core Web Vitals no son una estampita para pegar en un informe. LCP, INP y CLS ayudan a detectar si el usuario ve rápido el contenido principal, si puede interactuar sin latencia irritante y si la página no salta como una rana al cargar anuncios, imágenes o módulos tardíos. En JavaScript SEO, el rendimiento se cruza con el rastreo porque las decisiones de arquitectura afectan a ambos mundos. Si el servidor entrega HTML útil, el usuario ve antes la página y Google recibe señales más claras. Si todo depende de ejecutar un paquete enorme, el usuario espera, el bot renderiza más trabajo y el equipo termina mirando PageSpeed Insights como quien consulta el parte meteorológico antes de una boda al aire libre.

El exceso de JavaScript suele venir de muchas pequeñas concesiones. Una librería para un carrusel que podría resolverse con CSS. Un tag manager convertido en trastero. Tres herramientas de analítica midiendo casi lo mismo. Un chat que carga en todas las páginas, incluidas las informativas. Scripts de afiliación, mapas, píxeles, personalización, tests A/B eternos. Cada uno pesa poco en la reunión donde se aprueba. Todos juntos forman una mudanza. Y lo peor: parte de esa carga no aporta nada al contenido indexable.

La solución no consiste en perseguir un 100 verde como si fuera una medalla olímpica. Consiste en ordenar prioridades: reducir JavaScript no crítico, dividir código, diferir terceros, hidratar solo componentes interactivos, usar imágenes con dimensiones definidas, cachear bien, servir HTML útil y medir con datos de campo. CrUX, Search Console y PageSpeed Insights ayudan, pero la lectura debe ser adulta. Un dato de laboratorio puede orientar; un dato real de usuarios cuenta cómo respira la web en móviles modestos, redes mediocres y navegadores cansados.

La nueva frontera: Google no es el único que mira la web

Durante años, JavaScript SEO se pensó casi exclusivamente para Google. Tiene sentido: Google concentraba el gran teatro de la búsqueda orgánica. Pero el mapa se ha llenado de otros ojos. Rastreadores de IA, asistentes, motores de respuesta, sistemas de entrenamiento, buscadores conversacionales. Y aquí el HTML inicial vuelve a cobrar importancia con una sonrisa de veterano.

Un análisis publicado por Vercel sobre tráfico de rastreadores de IA observó que grandes crawlers vinculados a OpenAI, Anthropic, Meta, ByteDance y Perplexity no renderizaban JavaScript en sus mediciones, aunque algunos sí descargaban archivos JavaScript como texto. El mismo análisis señalaba que Gemini usa infraestructura de Google, con capacidad de renderizado, y que AppleBot también puede procesar JavaScript mediante un crawler basado en navegador. El matiz es enorme: Google puede ver una SPA tras renderizar; muchos rastreadores de IA pueden quedarse solo con el HTML inicial.

Esto no significa que haya que rediseñar internet para cada bot de moda. Tampoco que toda web deba perseguir menciones en respuestas generativas como pollo sin cabeza. Significa algo más sólido: si tu contenido crítico vive en HTML inicial, eres más visible para más sistemas. Si solo aparece tras JavaScript, dependes de que el rastreador ejecute, espere, entienda estados y reconstruya contexto. Google puede hacerlo a menudo. Otros no. La vieja recomendación de progressive enhancement vuelve con gabardina nueva: primero contenido y enlaces; después interacción.

Para SEO y GEO, esta diferencia cambia la conversación. La visibilidad ya no se limita a diez enlaces azules, mapas y snippets. También importa si una máquina puede extraer con claridad quién eres, qué vendes, qué sabes, qué precios das, qué entidades mencionas, qué comparativas sostienes y cómo se relacionan tus páginas. El marcado estructurado ayuda, pero no arregla una página hueca. Los datos estructurados generados por JavaScript pueden funcionar en Google si se renderizan correctamente y se validan, pero para un ecosistema más amplio conviene que lo esencial no dependa siempre de esa segunda capa.

Hay una lectura estratégica bastante incómoda para algunos equipos: el frontend no puede diseñarse de espaldas al contenido. Una web orientada a captación orgánica no es una app privada. No basta con que el usuario final “lo vea”. Deben verlo los sistemas que descubren, clasifican, resumen, recomiendan y citan. En un internet cada vez más intermediado por respuestas automáticas, hacer que el contenido exista pronto, claro y enlazado no es conservadurismo técnico. Es supervivencia editorial y comercial.

Cómo diagnosticar el problema sin caer en teatro técnico

La auditoría de JavaScript SEO empieza con una comparación sencilla y bastante reveladora: HTML inicial, DOM renderizado y versión inspeccionada por Google. Search Console, la inspección de URL, la prueba de resultados enriquecidos, crawlers con renderizado JavaScript y logs de servidor permiten ver si Googlebot accede a recursos, si encuentra errores, qué enlaces descubre, qué contenido queda en el DOM y qué diferencias hay entre usuario y bot. Google recomienda usar herramientas como URL Inspection y Rich Results Test para ver recursos cargados, excepciones de JavaScript, salida de consola y HTML renderizado.

Una señal roja es que el HTML inicial no contenga el contenido principal. Otra, que los enlaces internos importantes no existan como a href. Otra, que el servidor responda 200 para páginas inexistentes. Otra, que Search Console muestre “descubierta, actualmente sin indexar” o “rastreada, actualmente sin indexar” en patrones concretos de plantillas JavaScript. No siempre será culpa del renderizado; Google insiste en que no garantiza rastreo, indexación ni publicación aunque una página cumpla requisitos técnicos. La calidad, duplicidad, señales canónicas y utilidad del contenido también cuentan. Pero cuando el problema se concentra en plantillas CSR, rutas SPA, paginaciones infinitas o recursos bloqueados, conviene dejar de mirar al algoritmo como si fuera un horóscopo.

Los logs son especialmente útiles porque separan intuición de realidad. Permiten comprobar qué pide Googlebot, con qué frecuencia, qué códigos recibe, si descarga recursos JavaScript y CSS, si se atasca en redirecciones, si malgasta rastreo en URLs con parámetros o si ignora secciones profundas. En ecommerce grande, esta lectura puede ser más importante que una captura bonita de Lighthouse. Lighthouse te dice cómo se comporta una página en un escenario. Los logs enseñan cómo respira el sitio cuando los bots entran por todas las puertas, incluso por las que ya creías cerradas.

También hay que mirar el renderizado desde móviles. Google usa mobile-first indexing, y muchas webs sirven experiencias distintas según dispositivo, ancho, user agent, geolocalización o consentimiento. Ahí aparecen fantasmas: banners de cookies que tapan contenido, menús móviles que esconden enlaces, componentes que no se montan en determinados breakpoints, recursos bloqueados por CDN, APIs que devuelven datos distintos si no hay cookie, personalizaciones que dejan a Googlebot con una versión pobre. La web no está rota. Solo tiene varias personalidades, y una de ellas no posiciona.

Cuando Google ve la página, pero no entiende el negocio

El objetivo de JavaScript SEO no es que Google ejecute scripts. Es que entienda la página. Y entender significa varias cosas a la vez: contenido principal claro, intención reconocible, entidades consistentes, enlaces internos coherentes, metadatos limpios, canonical sin pelea, datos estructurados válidos, imágenes accesibles, estados HTTP honestos, rendimiento razonable y una arquitectura que no esconda lo relevante detrás de gestos humanos.

Una página puede estar indexada y seguir siendo débil. Por ejemplo, una ficha de producto donde Google ve el nombre y la imagen, pero no las opiniones, el precio, el stock o las variantes. Una categoría donde descubre la primera tanda de productos, pero no las siguientes. Un artículo donde el cuerpo aparece, pero los enlaces relacionados se cargan tarde y no se rastrean. Una página local donde la dirección y el horario dependen de una API que falla para el bot. Una comparativa SaaS donde las tablas se pintan tras interacción y el HTML inicial no aporta casi nada. En todos esos casos, el diagnóstico “está indexado” es demasiado pobre. Estar en el índice no equivale a competir.

El remedio suele tener menos glamour que el problema. Servir HTML significativo. Usar enlaces reales. Cuidar códigos de estado. Evitar canonicals dinámicos contradictorios. Hacer que las rutas importantes tengan URLs limpias y persistentes. No depender de fragmentos. Validar datos estructurados. Mantener una política de caché con fingerprinting. Reducir JavaScript no esencial. Auditar terceros. Probar con herramientas de Google y con crawlers que rendericen. Revisar logs. Y, sobre todo, decidir qué partes de la experiencia son contenido y cuáles son decoración interactiva. Esa frontera, mal trazada, es donde se pierde tráfico.

JavaScript no es enemigo del SEO. El enemigo es tratar una web pública como si fuera una aplicación cerrada donde basta con que el usuario autenticado llegue a ver algo tras varios pasos. En SEO, la primera impresión no es solo visual; es semántica, técnica y rastreable. Googlebot no compra, no hace scroll con curiosidad, no acepta permisos de cámara, no pulsa todos los botones y no espera eternamente a que una API tímida responda. Tiene trabajo. Mucho.

El HTML vuelve a tener razón

La web moderna no necesita menos JavaScript por nostalgia, sino mejor JavaScript por higiene. JavaScript SEO no pide renunciar a frameworks, componentes, experiencias ricas ni interfaces rápidas. Pide colocar las piezas en el orden correcto: primero lo que debe existir para usuarios, buscadores y sistemas de respuesta; después lo que mejora, personaliza o embellece. Una web puede ser sofisticada sin ser opaca. Puede moverse sin esconderse. Puede parecer una aplicación y comportarse, para el rastreo, como un documento claro.

La frase incómoda es sencilla: si Google no puede ver bien tu contenido, el usuario orgánico quizá nunca llegue a verlo. Y en 2026 el problema ya no se limita a Google. Los rastreadores de IA, los asistentes y los motores de respuesta han ampliado el público invisible de una página. El HTML inicial, los enlaces limpios y el renderizado robusto vuelven a ser esa fontanería que nadie aplaude cuando funciona, pero que todos maldicen cuando falla. El SEO técnico, al final, tiene mucho de eso: tuberías. Poco brillo, mucha consecuencia.