El 13/02/2026 John Mueller respondió a un caso donde un autor atribuía a “Google AI” un mensaje en las SERP que afirmaba que un sitio estaba offline. La explicación fue más prosaica: la página servía texto temporal tipo “not available” en el HTML inicial y lo reemplazaba luego con JavaScript. Google leyó lo primero que recibió y por eso mostró esa información en los resultados (fuente: Search Engine Journal, 13/02/2026).

Qué pasó, en términos técnicos

La página entregó un placeholder en el HTML y dependió de JavaScript del lado del cliente para cambiar ese texto cuando el navegador ejecuta el script. Si el motor de búsqueda inspecciona la versión no renderizada —por tiempo o por cómo se procesa el rendering— queda registrada la versión con el mensaje de indisponibilidad. Mueller aconsejó no usar JS para cambiar texto crítico y poner la información correcta en el HTML base o en un renderizado en servidor.

Por qué esto importa para negocios y SEO

Primero, porque Google sigue siendo la vía central de descubrimiento de tráfico: más del 90% del mercado de búsquedas global está en manos de Google (StatCounter, 2024). Cuando el contenido que define disponibilidad o estado de producto vive solo en JS, se corre el riesgo de que la página ofrezca señales contradictorias a usuarios y buscadores. Segundo, JavaScript es ubicuo: más del 95% de los sitios incluyen JS en sus páginas (W3Techs, 2024), y esa misma omnipresencia hace que los errores de implementación sean comunes.

Un punto temporal: la adopción de renderizado cliente-lado creció en los últimos años frente a prácticas más conservadoras de server-side rendering, y eso aumentó la exposición a este tipo de fallos vs. hace cinco años (W3Techs historical). La diferencia no es solo técnica: tiene impacto directo en conversión y en cómo se percibe la disponibilidad de producto en ecommerce.

Diagnóstico y buenas prácticas concretas

  1. Verificar con Search Console —URL Inspection— y con herramientas que simulan el renderizado de Google. No confiar en el ojo humano solo. Google documenta que crawling, rendering e indexing son procesos separados y que el rendering puede producirse después del crawl (Google Search Central).

  2. Priorizar contenido crítico en el HTML inicial. Si el estado de stock o disponibilidad se muestra primero como placeholder, el buscador puede indexar eso. Renderizado del servidor (SSR), prerendering o Server-Side Rendering híbrido (ISG/SSG) evitan la dependencia completa del cliente.

  3. Evitar arreglos a salto de mata. El autor del blog removió un pop-up por intuición; las soluciones por deducción sin diagnóstico pueden introducir bugs nuevos. Cambios deben instrumentarse y medirse: antes/después en Search Console, comparativa de impresiones y clicks, y seguimiento de URLs afectadas.

Qué implica para la estrategia de ecommerce

Esto refuerza la idea que ya venimos sosteniendo: el SEO en ecommerce es una inversión a mediano plazo y se gana cuidando arquitectura, intención y medición. Si la experiencia técnica no garantiza que el contenido que queremos que indexen esté presente en el HTML servido, entonces estamos optimizando métricas de vanidad. En un mercado donde Google concentra más del 90% de búsquedas (StatCounter, 2024) y la mayoría de sitios usan JavaScript (W3Techs, 2024), la prioridad es coherencia entre lo que ve el usuario y lo que ve el buscador.

Cierre: principio antes que táctica

La historia no es un misterio de AI; es un recordatorio de que la tecnología es un canal, no la estrategia. Un buen mensaje mal distribuido pierde; un buen stack técnico mal diseñado también. Antes de acusar a Google o a modelos de lenguaje, diagnostiquemos: inspección de URLs, pruebas de renderizado, y cambios medidos. Es la única forma de convertir esfuerzo técnico en resultados de negocio sostenibles.