Página indexada sin contenido: en el índice y aun así invisible
En el informe «Indexación de páginas» de Google Search Console, ver una URL pasar a «indexada» parece una victoria. «La página se ha indexado sin contenido» archiva esa victoria entre las falsas buenas noticias: la página está en el índice y no va a posicionarse en nada, porque Google la leyó vacía.
Es el único estado en el que Google admite no saber: la página figura en el índice, pero su contenido sigue siendo ilegible «por algún motivo» que la propia herramienta no concreta. Quedan entonces tres preguntas que lo deciden todo. ¿Por qué Google recibe vacío donde un navegador muestra una página completa? ¿Por qué añadir texto no cambia nada cuando el problema no es la cantidad? ¿Y cómo distinguir este estado del Soft 404, que cierra la puerta antes incluso del índice?
Tres preguntas que separan la página realmente vacía de la que Google simplemente no consigue leer.
Qué significa «Página indexada sin contenido»
«Página indexada sin contenido» significa que tu URL figura en el índice de Google, pero que Googlebot no pudo extraer ningún contenido de ella durante el rastreo. La página existe para Google, sin materia aprovechable detrás. Resultado: está indexada e incapaz de posicionarse en la menor consulta.
«Esta página aparece en el índice de Google, pero por algún motivo Google no ha podido leer el contenido. Puede deberse a que la página esté encubierta o que tenga un formato que Google no puede indexar.» — Google, informe «Indexación de páginas», categoría «Advertencia».
Lo que vuelve singular a este estado es esa confesión de incertidumbre. Google no apunta a una causa precisa como hace con un Soft 404 o un bloqueo por robots.txt. Constata un desfase: la URL respondió, fue retenida, pero el renderizado no entregó ningún contenido aprovechable. La pelota vuelve a tu tejado, sin diagnóstico adjunto. Es justamente esa ambigüedad la que hace difícil de tratar el estado, y lo que sigue sirve para despejarla.
Por qué es una falsa victoria, no un fallo de visualización
Una página «indexada sin contenido» ocupa una línea en el índice, pero sin ninguna señal de relevancia que ofrecer. Google solo ha indexado un cascarón. Sin texto aprovechable, ninguna consulta puede activarla: está técnicamente presente y comercialmente ausente.
La trampa está en la palabra «indexada». En el informe tranquiliza, cuando aquí no garantiza nada. Una página puede quedarse meses en este estado, contada entre tus URLs indexadas, sin generar jamás una impresión. Crees la zona cubierta, y el tráfico esperado no llega.
A eso se suma el rastreo gastado para nada. Googlebot vuelve con regularidad a comprobar una página de la que sigue sin sacar nada. Sobre un puñado de URLs, el efecto es insignificante. A escala de una plantilla entera que sirve vacío de forma sistemática, es presupuesto de rastreo derrochado en páginas muertas, en detrimento de aquellas que de verdad quieres ver indexadas. Entender por qué Google recibe vacío empieza por identificar cuál de las cuatro causas posibles te afecta.
Las cuatro causas: del vacío real al bloqueo invisible
Cuatro familias de causas conducen a este estado, y apenas tienen nada en común. Tres responden a un problema de lectura, donde Google recibe vacío aunque la página exista. Una sola corresponde a una página realmente vacía. Identificar la familia correcta condiciona todo lo demás: una corrección aplicada a la causa equivocada no produce ningún efecto.
«Yo veo el texto, Googlebot no»: renderizado JS y recursos bloqueados
Es el caso más frecuente del lado del código. Tu contenido no existe en el HTML inicial: lo inyecta JavaScript tras la carga. Si la ejecución falla, expira o depende de recursos que Googlebot no recupera, el renderizado se queda congelado en una página vacía. El mismo mecanismo se da cuando tus archivos CSS y JS están bloqueados por el robots.txt: Google rastrea el HTML, no puede cargar lo que construye la página y solo obtiene un esqueleto. Tú ves una página completa en tu navegador, Googlebot ve el armazón anterior a la inyección.
«Google recibe vacío»: servidor, CDN o firewall
Aquí el problema no está en tu código, sino en el camino entre Googlebot y tu servidor. Un firewall de aplicación (WAF), una protección anti-bot o una regla de CDN demasiado agresiva puede servir una respuesta vacía a Googlebot mientras entrega la página completa a un visitante humano. Según una aclaración reportada de John Mueller a principios de 2026, el renderizado JavaScript rara vez sería la única causa de este estado: muy a menudo, es el servidor, el CDN o una capa de filtrado lo que devuelve vacío a Google. Conviene tomarlo como una puntualización útil, no como una verdad absoluta: ambas familias de causas coexisten, y es el diagnóstico por síntoma el que decide. Cuando la respuesta del servidor se degrada por completo, pasas además a otro estado, tratado en Error del servidor (5xx).
La página está realmente vacía o es demasiado pobre
El caso más sencillo, y el único que «añadir contenido» corrige de verdad. La página responde, su HTML es legible, pero apenas hay nada dentro: una plantilla sin cuerpo, una ficha nunca rellenada, una categoría sin productos, un contenedor a la espera de unos datos que nunca llegaron. Google lee lo que hay, y lo que hay no basta para constituir un contenido.
Cloaking, voluntario o accidental
El cloaking consiste en servir a Googlebot una versión distinta de la que ve el usuario. Voluntario, es una infracción de las directrices de Google. Accidental, es mucho más frecuente: una detección del user-agent mal configurada, una redirección condicional, una variante servida según la IP o la geolocalización que priva a Googlebot del contenido real. El resultado es el mismo, una versión vacía del lado de Google.
| Síntoma observado | Causa probable | Qué comprobar |
|---|---|---|
| Contenido visible en el navegador, ausente del HTML de origen | Renderizado JS o recursos bloqueados | HTML de origen frente a HTML procesado, robots.txt sobre los archivos CSS/JS |
| Página completa para ti, vacía para Googlebot | Servidor, CDN o firewall | Respuesta servida al user-agent Googlebot, reglas de WAF y CDN |
| HTML legible pero casi sin nada dentro | Página realmente vacía o demasiado pobre | Presencia de un cuerpo de contenido real en la plantilla |
| Versión de Google distinta de la versión del visitante | Cloaking, a menudo accidental | Detección del user-agent, redirecciones condicionales, reglas por IP |
El falso remedio: no, añadir 600 palabras no lo arregla
Añadir contenido solo corrige uno de los cuatro casos: el de la página realmente vacía. En los otros tres, el problema es la lectura, no la cantidad. Si Google recibe vacío por culpa del renderizado o del servidor, 600 palabras más siguen siendo igual de ilegibles: enriqueces una página que Googlebot sigue sin ver.
Es el reflejo más persistente ante este estado, y el más contraproducente. La palabra «contenido» en el nombre orienta de forma natural hacia la idea de un déficit de texto. Pero el estado no dice «contenido insuficiente», dice que Google no consigue leer el contenido existente. El matiz es decisivo. Mientras no hayas comprobado lo que Googlebot recibe de verdad, añadir texto equivale a llenar un cubo agujereado.
El enfoque correcto invierte el orden: primero confirmar si Google recibe o no contenido, y solo después decidir si hay que añadirlo. Todo parte del diagnóstico, nunca del enriquecimiento a ciegas.
Medir el alcance: cuántas de tus URLs están afectadas
Antes de corregir, conviene saber cuántas páginas están afectadas y cuáles. El informe «Indexación de páginas» sí lista el estado, pero no se filtra sobre tu propia lista de URLs estratégicas: imposible aislar con facilidad, entre tus páginas que cuentan, las que se sirven vacías a Google. Es justamente esa carencia la que la inspección en masa cubre.
La herramienta de Inspección de URL de la Search Console da ese veredicto oficial, pero una URL cada vez: auscultar una lista entera a mano resulta impracticable. IndexProbe retoma el mismo dato oficial de Google y lo aplica a la lista de URLs que le proporcionas, o que construyes desde la GSC, para aislar en un solo análisis las que están en estado «Página indexada sin contenido». Hablas entonces de páginas precisas, fechadas en el último paso de Googlebot, entre las URLs que analizas, sin extrapolar al conjunto del sitio.
💡 ¿Cuántas de tus páginas están indexadas sin contenido, y cuáles? IndexProbe inspecciona tu lista de URLs vía la API de Search Console y devuelve, por página, el veredicto de indexación oficial de Google, fechado en su último paso. Probar IndexProbe en acceso anticipado →
Ver lo que Googlebot recibe de verdad: la pestaña «HTML procesado»
Para decidir entre una página vacía y una página mal leída, mira lo que Google recibió realmente. En la Inspección de URL de la Search Console, abre el resultado de la indexación, luego «HTML procesado» y la captura de pantalla: ese es el renderizado obtenido por Googlebot. Si está vacío mientras tu navegador lo muestra todo, tienes un problema de lectura.
Una precaución capital: la prueba en vivo (Live Test) no reproduce este estado. La prueba en vivo vuelve a lanzar un rastreo en el instante presente, con un comportamiento de renderizado y unas condiciones de red que pueden diferir de las del momento en que Google indexó la página vacía. Una página puede mostrarse perfectamente en la prueba en vivo y seguir «indexada sin contenido» en el índice.
El dato que cuenta es, por tanto, la versión indexada, no la prueba en vivo. Compara de forma sistemática el HTML de origen (lo que el servidor envía de partida) con el HTML procesado (lo que obtiene Google tras el renderizado). Si el texto aparece en el origen pero desaparece tras el procesado, sospecha de un bloqueo de recursos. Si falta ya desde el origen, el culpable es el renderizado JavaScript o el servidor. Ese diagnóstico decide la corrección que hay que aplicar.
Corregir según la causa, no a ciegas
No existe una corrección única, sino una corrección por causa, en espejo de la tabla de síntomas. El diagnóstico del HTML procesado ya te ha orientado: aplica la reparación que corresponde a la familia identificada, y solo esa. Corregir al azar es arriesgarse a enriquecer una página que Google no lee, o a reescribir un servidor cuando el problema viene del JavaScript.
Si la causa es el renderizado JS o unos recursos bloqueados, haz que el contenido principal esté presente ya en el HTML inicial (renderizado en el servidor o prerrenderizado), y desbloquea los archivos CSS y JS necesarios para la visualización. Comprueba además que ningún recurso decisivo tenga prohibido el rastreo: el asunto se solapa directamente con Bloqueada por robots.txt.
Si la causa es el servidor, el CDN o el firewall, identifica la regla que sirve vacío a Googlebot y autoriza a su user-agent a recibir la versión completa. Suele tratarse de una protección anti-bot o de una regla de WAF demasiado amplia.
Si la página está realmente vacía o es demasiado pobre, ahí, y solo ahí, produce un contenido sustancial y único, o retira la página del índice si no tiene vocación de posicionarse.
Si la causa es un cloaking accidental, suprime la lógica que sirve una versión distinta según el user-agent, la IP o la geolocalización, para que Google reciba lo que ve el usuario.
No confundir con Soft 404 ni «Indexada aunque bloqueada por robots.txt»
Tres estados próximos engañan incluso a los SEO veteranos, porque todos tocan la lectura del contenido. La diferencia se reduce a una sola pregunta: ¿está la página en el índice y, en tal caso, se ha leído su contenido? «Página indexada sin contenido» está en el índice con un contenido ilegible. Un Soft 404 no está. Una página indexada aunque bloqueada por robots.txt está sin haber sido leída.
| Página indexada sin contenido | Soft 404 | Indexada aunque bloqueada por robots.txt | |
|---|---|---|---|
| ¿En el índice? | Sí | No | Sí |
| ¿Contenido leído? | No, ilegible tras el renderizado | No, tratada como no encontrada | No, rastreo bloqueado |
| Causa | Renderizado, servidor, página vacía o cloaking | Página percibida como inexistente pese a un código 200 | Rastreo prohibido por el robots.txt |
| Corrección | Hacer el contenido legible para Googlebot | Devolver un contenido real o un 404 franco | Desbloquear la URL en el robots.txt |
Para profundizar en cada uno, consulta Soft 404 e Indexada aunque bloqueada por robots.txt. Quédate con la frontera: aquí, Google retuvo la página pero no pudo leer nada de ella tras el renderizado, frente al Soft 404 que la juzga inexistente y al bloqueo por robots.txt que la indexa sin haberla rastreado jamás.
Comprobar que la corrección ha funcionado
Una corrección solo se valida cuando Google ha vuelto a rastrear la página y ha cambiado su veredicto. El estado no cambia en el instante en que despliegas la corrección: hay que esperar al próximo paso de Googlebot. El buen indicador no es tu navegador, sino la evolución del estado entre dos inspecciones de la misma URL.
Seguir ese cambio en una página se hace a mano en la Inspección de URL. Seguirlo en diez, cien o mil páginas corregidas a la vez exige comparar dos estados en el tiempo. Ese es el papel de la vista Comparación: relanzar el análisis sobre la misma lista después de la corrección, y leer cuántas URLs han pasado de «indexada sin contenido» al estado plenamente sano, «Enviada e indexada», página por página y con la fecha del último paso de Googlebot.
💡 Comprueba que tus correcciones pasan del lado de Google. IndexProbe devuelve, para la lista de URLs que le proporcionas o que construyes desde la GSC, el veredicto de indexación oficial fechado en el último paso de Googlebot, y la vista Comparación pone dos análisis lado a lado para seguir el cambio de estado, página por página, sin extrapolar al conjunto del sitio. Probar IndexProbe en acceso anticipado →
Preguntas frecuentes
¿Qué significa «Página indexada sin contenido» en Search Console?
Este estado significa que tu URL está en el índice de Google, pero que Googlebot no pudo leer ningún contenido aprovechable durante el renderizado. La página existe para Google, sin materia detrás, así que no se posiciona en ninguna consulta pese a estar indexada.
¿Por qué Google no lee el contenido de una página que mi navegador muestra bien?
Porque Googlebot no recibe lo mismo que tú. Un renderizado JavaScript que falla, unos recursos CSS o JS bloqueados, un firewall que sirve vacío al robot o un cloaking accidental pueden entregar una página vacía a Google mientras tu navegador lo muestra todo.
¿Qué diferencia hay entre «Página indexada sin contenido» y un Soft 404?
«Página indexada sin contenido» está en el índice, con un contenido que Google no pudo leer. Un Soft 404 no está en el índice: Google trata la página como no encontrada pese a su código 200. Uno está indexado e ilegible, el otro queda excluido.
¿Añadir texto corrige este estado?
Solo si la página estaba realmente vacía. En los otros tres casos, renderizado, servidor o cloaking, el problema es la lectura, no la cantidad: Google recibe vacío, y todo texto añadido sigue siendo ilegible para él. Diagnostica primero, enriquece después.
¿El renderizado JavaScript es siempre el culpable?
No. El renderizado JavaScript es una causa frecuente, pero según una aclaración reportada de John Mueller a principios de 2026, a menudo es el servidor, el CDN o un firewall lo que devuelve vacío a Googlebot. Ambas familias coexisten: solo el diagnóstico del HTML procesado permite decidir.