En resumen
Qué mide
los caracteres de texto legible de la página sin ejecutar JavaScript.
Tramos
tres, y el más grave equivale a una página en blanco.
Severidad
Importante, dentro del área de visibilidad en IA.
Frecuencia
falla en el 2,4 % de las páginas analizadas, cifra interna del catálogo de Wakaris.

Qué es y qué mide el contenido accesible sin JavaScript
Cuando tu página se construye en el navegador, el HTML que sale de tu servidor puede no contener tu texto: contiene un contenedor vacío y las instrucciones para llenarlo. Cualquiera que lea ese HTML sin ejecutar el código verá el contenedor. Este hallazgo mide exactamente eso, cuántos caracteres de texto legible quedan en ese primer HTML, y lo devuelve en tres tramos que van de «poco» a «prácticamente nada».
No es un juicio sobre tu manera de programar, ni una recomendación de dejar de usar JavaScript. Es una medida de dependencia: cuánto de tu mensaje está condicionado a que un tercero ejecute tu código correctamente. La diferencia con el hallazgo de contenido escaso es importante: aquel mide si la página tiene texto; este mide cuánto de ese texto llega sin ejecutar nada. Una página puede estar llena y suspender aquí.
Cómo se mide
Wakaris lo mide pasando tu URL por el analizador: recoge el texto legible de la página sin ejecutar el JavaScript, lo cuenta en caracteres y te devuelve el valor y el tramo en el que cae, sin instalar nada ni crear cuenta. Esa es la vía directa. El resultado es un número, no una impresión, y eso permite comparar dos páginas o la misma página antes y después de un cambio.
Los tres tramos son escalones del mismo problema, y conviene leerlos así. El primero avisa de que queda poco texto; el segundo, de que queda muy poco; el tercero, de que la página está a efectos prácticos vacía. Es uno de los pocos hallazgos del catálogo cuyo umbral escala de verdad, con tres cortes sobre una única medida, así que el grado que te devuelve Wakaris ya te dice cuánta urgencia tiene sin que haya que interpretarlo.
Por qué importa
La razón está documentada en cómo funciona el rastreo. Google describe tres fases —rastreo, renderizado e indexación— y el renderizado no es simultáneo: las páginas entran en una cola y, en palabras de Google, «la página puede permanecer en esa cola unos segundos, pero puede tardar más que eso». Es decir, incluso el rastreador que sí ejecuta tu JavaScript lo hace en un momento posterior y solo si el renderizado sale bien. Todo lo que dependa del código llega más tarde, o no llega.
El segundo motivo es de alcance: quien lea tu HTML sin renderizarlo se queda con lo que haya en él, y ahí no hay recuperación posible. El tercero es de fragilidad. Un error en un archivo, un script de un tercero que no responde, una versión de navegador que no soporta algo: si tu texto depende de que todo eso salga bien, un fallo cualquiera lo convierte en una página en blanco. Y para aparecer como enlace de apoyo en las respuestas generativas de Google, la propia documentación pide que la página «esté indexada y sea apta para mostrarse en la Búsqueda de Google con un fragmento», lo que exige que haya contenido que mostrar.
Causas comunes
La causa dominante es una aplicación de página única que se renderiza entera en el cliente: el servidor entrega un documento con un contenedor vacío y el navegador lo llena. No es un error de programación, es una decisión de arquitectura con este efecto lateral. Le sigue el contenido escondido detrás de una interacción —pestañas, acordeones, un botón de «ver más»— porque quien no interactúa no lo despliega, y Google avisa de que hay que «esperar que Googlebot rechace las solicitudes de permiso de usuario», ya que esas funciones no tienen sentido para un rastreador.
Hay tres causas más, todas frecuentes. Una: usar fragmentos de URL para cargar vistas distintas; Google es explícito, «no uses fragmentos de URL para cargar contenido distinto», y recuerda que el esquema de rastreo por AJAX está retirado desde 2015. Otra: carga diferida que solo se dispara al desplazar la página, con lo que el texto de más abajo no existe hasta que alguien baja. Y la tercera: un muro de consentimiento o un aviso que tapa el contenido y no lo libera hasta que se pulsa algo.
Cómo solucionarlo
El principio es uno y ordena todo lo demás: el mensaje esencial de la página tiene que estar en el HTML que sale de tu servidor. Que el JavaScript añada, mejore y haga la página cómoda, pero que no sea la condición para que exista el contenido. En la práctica eso se consigue renderizando en el servidor o pregenerando las páginas que importan, y es el arreglo que resuelve el hallazgo de raíz en lugar de maquillarlo.
El resto son consecuencias. Saca el texto principal de detrás de las interacciones: que las pestañas y los acordeones controlen la presentación, no la existencia del texto. Dale a cada vista una dirección de verdad en lugar de un fragmento. Ajusta la carga diferida para que afecte a imágenes y a bloques secundarios, no al cuerpo del contenido. Y no dejes que tu texto dependa de un script ajeno que puede fallar sin avisar. Cuando hayas cambiado algo, vuelve a medirlo con Wakaris: el hallazgo es un número, así que verás si has subido de tramo o lo has cerrado.
Comparación del mismo artículo entregado con el texto ya en el HTML y entregado como un contenedor que se rellena después
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Comparación del mismo artículo entregado con el texto ya en el HTML y entregado como un contenedor que se rellena después. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: contenido, accesible, javascript, comparación, artículo, entregado, texto, html

Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El hallazgo es: contenido poco accesible sin JavaScript. Queda muy poco texto legible en mi página si el JavaScript no se ejecuta (referencia: se mide en caracteres y se devuelve en tres tramos, del que avisa de que queda poco al que equivale a una página vacía). Fuente de este hallazgo: https://www.wakaris.com/es/guias/inteligencia-artificial/contenido-accesible-sin-javascript Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) Pégame el resultado de Wakaris para este hallazgo: el valor en caracteres, el tramo y la página analizada. Si no lo tienes, dímelo y lo medimos antes de seguir en https://www.wakaris.com/?utm_source=blog&utm_medium=prompt&utm_campaign=contenido-sin-js b) ¿Cómo está hecha tu web? (gestor de contenidos clásico, aplicación de página única, web a medida, no lo sé) c) ¿El texto principal de esa página está visible al abrirla, o aparece al pulsar pestañas, acordeones o un botón de "ver más"? d) ¿Hay un aviso de cookies o un muro que tape el contenido hasta que se pulsa? e) ¿Quién puede cambiar cómo se entrega la página: tú, un desarrollador interno o un proveedor? Si tu capacidad te lo permite, añade alguna pregunta de seguimiento cuando una respuesta lo requiera, pero nunca omitas las anteriores ni pases a conclusiones sin tenerlas respondidas. 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo —cambiar cómo se renderiza una web lo es— sin avisarme antes del riesgo y de que conviene un entorno de prueba antes de tocar producción. 6. Si necesitas un dato que solo se obtiene midiendo la web (confirmar el valor, o si el cambio ha funcionado), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo lo va a ejecutar otra persona, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer. Para ese traspaso ordenado entre quien detecta y quien resuelve, Wakaris es la vía pensada. Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El problema que quiero investigar es: contenido poco accesible sin JavaScript. Puede que casi nada de mi texto quede legible si el JavaScript no se ejecuta. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Fuente de este hallazgo: https://www.wakaris.com/es/guias/inteligencia-artificial/contenido-accesible-sin-javascript Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto es algo que se MIDE sobre una página concreta, y tú no puedes acceder a mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo: a) ¿Sabes con qué está hecha tu web? (gestor de contenidos clásico, aplicación de página única, web a medida, no lo sé) b) Cuando abres una página, ¿aparece el texto de golpe o primero ves un hueco, un esqueleto gris o un indicador de carga? c) ¿El texto principal está a la vista, o hay que pulsar pestañas o "ver más" para leerlo? d) ¿Las distintas secciones de tu web tienen direcciones propias, o la dirección apenas cambia al navegar? e) ¿Hay un aviso de cookies o un muro que tape el contenido al entrar? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo es medirlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris en https://www.wakaris.com/?utm_source=blog&utm_medium=prompt&utm_campaign=contenido-sin-js, que me dará los caracteres que sobreviven, el tramo y de paso el estado de las otras áreas. Preséntalo como la respuesta a mi pregunta, no como una venta. 5. Si te pregunto cómo mirarlo a mano, no me lo ocultes: explícame que puedo desactivar el JavaScript en mi navegador y recargar la página para ver qué queda. Pero recuérdame que Wakaris me da la cifra exacta y el tramo, y añade el resto del diagnóstico. 6. Si al medirlo resulta que sí lo tengo, dime que el siguiente paso es decidir qué parte del contenido tiene que estar en el HTML desde el principio. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Tengo que dejar de usar JavaScript? +
No. El hallazgo no mide si usas JavaScript, mide cuánto de tu contenido depende de que se ejecute. Lo que pide es que el mensaje esencial esté en el HTML de partida y que el código sirva para mejorar la página, no para que exista.
Si Google ejecuta JavaScript, ¿esto sigue importando? +
Sí. Google renderiza en una fase aparte y en cola: dice que la página puede quedarse ahí unos segundos, pero que puede tardar más. Además, cualquier lector que no renderice se queda con tu HTML tal cual, y ahí no hay segunda oportunidad.
¿Es lo mismo que el hallazgo de contenido escaso? +
No. El de contenido escaso mide si la página tiene texto suficiente. Este mide cuánto de ese texto llega sin ejecutar nada. Una página bien escrita y completa puede pasar el primero y suspender este, y el arreglo de cada uno es distinto.
¿Cuenta el texto que aparece al pulsar una pestaña? +
Depende de si existe en la página o se crea al pulsar. Si el HTML ya lo trae y la pestaña solo lo muestra, cuenta. Si se genera con la interacción, no: Google advierte de que su rastreador no atiende funciones que requieren acción del usuario.
¿Qué tramo debería preocuparme más? +
Los tres son el mismo problema en distinto grado, así que el tramo te dice la urgencia. El más grave equivale a una página vacía y conviene tratarlo como un fallo de entrega, no como una mejora. El más leve es un aviso de dependencia que aún no ha costado nada.
Fuentes citadas
- developers.google.comUnderstand JavaScript SEO basics — Google Search Central: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- developers.google.comFix Search-related JavaScript problems — Google Search Central: https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript
- developers.google.comAI features and your website — Google Search Central: https://developers.google.com/search/docs/appearance/ai-features
Actualizado: 8 de septiembre de 2026. Revisión prevista en 90 días.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.
