Página indexada sin contenido

TL;DR — «Página indexada sin contenido» significa que la página sí está en el índice de Google, pero Google no pudo leer contenido útil. No equivale a un bloqueo de robots.txt ni suele resolverse escribiendo más. Una causa frecuente es que el servidor o la CDN bloquee silenciosamente a Googlebot y le entregue una respuesta vacía, aunque la página se vea bien; compruébelo como una posibilidad, no como la única.

Qué significa este estado

Abra el informe Indexación de páginas de Google Search Console, dentro de «Indexación». Puede aparecer el estado “Page indexed without content.” (traducción) «Página indexada sin contenido». A veces se abrevia como «Indexada sin contenido».

La clave es que la página sí está indexada: Google la encontró y la añadió al índice, pero no pudo leer su contenido. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report La documentación de Google menciona como posibles causas el encubrimiento o un formato no indexable, y aclara que no es lo mismo que bloquear la página con una regla disallow de robots.txt; ese caso tiene su propio motivo en el informe.

Por eso se diferencia de otros dos estados que suelen confundirse con este:

• «Descubierta: actualmente sin indexar»: Google conoce la URL, pero no la ha indexado.
• «Rastreada: actualmente sin indexar»: Google la rastreó, pero decidió no indexarla.

En ambos casos la página no está en el índice. Una «Página indexada sin contenido» sí está, pero Google no pudo leer nada útil.

Por qué no suele ser lo que parece

La suposición natural es «Google no puede leer mi JavaScript». A veces es cierto, pero John Mueller ha señalado como causa más habitual un servidor o CDN que bloquea a Googlebot: el alojamiento, firewall o sistema antibots le entrega una respuesta vacía mientras los visitantes normales ven la página completa.

Por eso resulta engañoso: la página se ve perfecta en su navegador y parece que el informe se equivoca, pero Google recibió algo distinto.

Cómo comprobar qué vio Google

Use Inspección de URLs en Search Console pegando la URL en la barra superior. Después:

1. Pulse Ver página rastreada para consultar lo que obtuvo el rastreo indexado; ese es el registro asociado al estado.
2. Ejecute también Probar URL publicada, pero interprete bien el resultado: Google incluye este estado entre los que la prueba en directo no puede volver a comprobar. Un resultado «válido» solo indica que la herramienta puede acceder ahora a la página; no demuestra que el estado indexado haya desaparecido.

Si el rastreo indexado aparece vacío pero el navegador muestra la página completa, Googlebot recibió contenido diferente o ninguno. Probablemente se trate de un bloqueo del servidor, CDN o protección antibots, o de encubrimiento; no de redacción.

Para consultar todas las causas, el diagnóstico paso a paso y por qué curl no reproduce ciertos bloqueos de Googlebot, abra la pestaña Avanzado.

TL;DR — «Página indexada sin contenido» indica que la URL está en el índice, pero Googlebot no pudo leer contenido útil. No equivale a «Rastreada/Descubierta: actualmente sin indexar» ni a un bloqueo de página mediante robots.txt. Aunque se suele culpar a JavaScript, en un caso de enero de 2026 Mueller apuntó a un bloqueo de bajo nivel del servidor o CDN, a menudo basado en IP y dirigido a Googlebot, imposible de reproducir con curl o un rastreador externo. Otras ramas son el encubrimiento, un renderizado vacío, contenido condicionado a clics o un formato no compatible. Diagnostique con los datos indexados de Ver página rastreada; una prueba en directo «válida» no demuestra que el estado se haya resuelto.

Qué dice realmente la documentación de Google

La documentación del informe Indexación de páginas es breve: el estado “Page indexed without content” (traducción) «Página indexada sin contenido» indica que la página está en el índice, pero Google no pudo leer el contenido. Como ejemplos cita que se haya encubierto para Google o que use un formato que Google no puede indexar, y recomienda inspeccionar la URL y revisar los detalles de cobertura. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Consulte las pestañas Documentación oficial y Citas para ver el texto literal y los enlaces directos.

Conviene precisar dos aspectos que muchas guías mezclan:

• Google dice «no pudo leer el contenido»; no describe un «objeto vacío» interno que almacene. «Entrada vacía» es solo una abreviatura del efecto visible, no un mecanismo documentado.
• Este estado no equivale a un disallow de robots.txt para la página, que tiene su propio motivo. robots.txt puede intervenir indirectamente si bloquea un recurso crítico —JS o CSS necesario— y deja vacío el renderizado.

Mantenga clara esa diferencia para no confundirlo con estados «sin indexar» ni con un bloqueo de robots.

No dé por hecho que es JavaScript

Esta es la corrección más importante del artículo.

Muchas guías tratan «indexada sin contenido» como un problema de renderizado o JavaScript. John Mueller cuestionó esa idea en un caso concreto de r/TechSEO: una página de inicio cayó aproximadamente de la posición 1 a la 15 tras aparecer este estado. Explicó que normalmente significa que el servidor o CDN impide que Google reciba contenido y que no está relacionado con JavaScript. Añadió que suele ser un bloqueo de bajo nivel, a veces basado en la IP de Googlebot, por lo que resulta casi imposible probarlo fuera de Search Console. El entorno afectado era, según el relato, Webflow con Cloudflare. (Se parafrasea una observación transmitida por terceros, no una cita verificada; es un caso documentado, no una estadística de frecuencia.)

El «normalmente» de Mueller describe ese intercambio, no un orden universal. La documentación de Google tampoco clasifica las causas; solo menciona encubrimiento y formato no compatible. Recorra estas ramas según la evidencia y deje que la respuesta recibida por Googlebot determine la correcta:

• Respuesta del servidor, CDN o WAF: la capa de red deja a Googlebot sin contenido, a menudo según la IP y sin señales externas. Es la causa documentada por Mueller.
• Entrega específica por cliente (encubrimiento): Googlebot recibe contenido distinto o vacío. Puede ser encubrimiento intencional —una infracción que exige intención manipuladora— o una diferencia accidental de configuración; esta última es un fallo de entrega, no una infracción demostrada.
• Formato o analizador: la respuesta no usa un formato indexable o el encabezado Content-Type no coincide con el contenido.
• Fallo de renderizado o recursos: JavaScript falla, agota el tiempo o depende de un recurso bloqueado y deja vacío el HTML renderizado.
• Contenido tras una interacción: solo aparece después de un clic o desplazamiento.
• Salida realmente vacía: la página no genera nada.

JavaScript es una rama que debe comprobarse, no la explicación predeterminada ni una causa con prioridad fija sin pruebas propias.

Por qué puede perjudicar el posicionamiento

En el caso citado, el propietario afirmó que la página cayó aproximadamente de la posición 1 a la 15. Es un relato individual, no una estadística verificada, pero es un resultado plausible si Google conserva una versión ilegible de una página que antes posicionaba. Investigue pronto este estado cuando afecte a una URL importante.

El bloqueo del servidor o CDN en detalle

Esta causa recibe poca atención porque cuesta verla. Una regla antibots o WAF, una lista de IP permitidas, un límite agresivo de solicitudes o un ajuste de seguridad actualizado puede considerar abusivo a Googlebot y devolver un cuerpo vacío, un desafío o un estado distinto de 200, pero solo a las IP de Googlebot. El equipo y los rastreadores externos acceden desde IP normales y ven la página real.

Esa es la trampa: no puede reproducir con curl ni con un rastreador de escritorio un bloqueo de Googlebot basado en IP. No usan sus rangos. Las herramientas de Search Console, que obtienen la página como Google, son la referencia fiable.

Si lo sospecha, verifique qué solicitudes pertenecen realmente a Googlebot mediante DNS inverso y directo o los rangos publicados. Revise después la gestión de bots de la CDN, las reglas de firewall/WAF, listas de IP y límites de solicitudes. La pestaña Scripts incluye los comandos.

Antes de cambiar nada, correlacione la respuesta indexada de Ver página rastreada con los registros de eventos de CDN/WAF y del servidor de origen en la misma ventana. Busque el identificador de solicitud, la categoría del cliente y la regla o límite que denegó la petición. Cambie solo la ruta, categoría o regla más específica que haya confirmado, tras una revisión de seguridad. Permitir de forma general todos los rangos de Google no es una práctica segura respaldada por las fuentes y amplía la superficie de ataque. Después, confirme en los registros que Googlebot recibe una respuesta completa y vuelva a revisar el informe tras un rastreo posterior. Google no publica un calendario fijo: hay que seguir comprobando, no esperar a un “check back on day X,” (traducción) «vuelva a comprobar el día X».

La causa de renderizado o JavaScript (cuando sí es JS)

Cuando el problema sí es el renderizado, Google rastrea el HTML inicial y luego un Chromium sin interfaz ejecuta JavaScript. Solo puede indexar lo que termina en el HTML renderizado. Si el contenido se genera en el cliente y el proceso falla, agota el tiempo o depende de una solicitud que Google no realiza, el resultado puede quedar vacío.

Un caso importante es el contenido condicionado a una interacción. Como expliqué en mi guía de SEO para JavaScript, los elementos que solo cargan tras un clic son problemáticos: Google no hace clic. Lo mismo ocurre con contenido que aparece al desplazarse o tras otra acción. Si el contenido principal exige un toque, suponga que Google no lo tiene.

La solución habitual es renderizar en el servidor o prerenderizar, garantizar que el contenido esté en el HTML renderizado y exponer la navegación mediante enlaces reales <a href> en vez de controladores que solo responden a clics. Véase SEO para JavaScript.

Diagnóstico: Inspección de URLs es la clave

El diagnóstico esencial es Inspección de URLs, pero usa dos fuentes distintas. Google separa los datos indexados —lo visto en el último rastreo de indexación— de una prueba en directo —una obtención actual de Google-InspectionTool—. No responden a la misma pregunta:

El flujo correcto es:

1. Ver página rastreada (datos indexados). Lea el HTML renderizado, la respuesta HTTP y los recursos asociados. La falta de algunos campos también aporta pistas.
2. Compare con su navegador. Si el renderizado indexado está vacío pero la página publicada está completa, hay un bloqueo o una entrega específica por cliente, no falta de texto.
3. Ejecute Probar URL publicada e interprétela bien. No confirma directamente que este estado se haya borrado. Un fallo de acceso sí es evidencia; «válida» significa «accesible ahora», no «resuelta». Evidence for this claim URL Inspection can show Google's indexed/crawled information and supports a live test for the current accessible version. Scope: Google Search Console URL Inspection; live test results can differ from the indexed version. Confidence: high · Verified: 2026-07-14 Google: URL Inspection tool
4. Lea la respuesta y los recursos. Un estado distinto de 200, un desafío o recursos críticos bloqueados apuntan a la causa.

Como los bloqueos por IP no aparecen desde fuera, no confíe en curl ni en un rastreador externo para dar la página por correcta. Search Console obtiene como Google y, para este estado, necesita los datos indexados además de la prueba actual.

Cómo distinguir las causas

Referencia rápida de estados y causas que suelen confundirse:

Mitos que debe abandonar

• «Añada 600 palabras y se arreglará». Si Google no recibió contenido, añadir texto que no puede leer no cambia nada.
• «Es JavaScript». A veces, pero Mueller apuntó normalmente a un bloqueo de servidor o CDN. No empiece por esa suposición.
• «Puedo reproducirlo con curl». No si el bloqueo depende de la IP de Googlebot.
• «Es igual que Rastreada/Descubierta: sin indexar». No; esas URL no están indexadas y esta sí.
• «Basta con solicitar la indexación». Sin corregir el bloqueo o renderizado, solo volverá a confirmar una página vacía.

Después de corregirlo

Cuando Ver página rastreada vuelva a mostrar contenido real, use Validar corrección o Solicitar indexación para promover otro rastreo y compruebe que el renderizado contiene el contenido. Validar sin corregir solo provoca otro fallo.

Dónde encaja este estado

Es un estado del informe Indexación de páginas, dentro de la fase general de indexación de Google —rastrear → renderizar → indexar → servir—. Los estados «sin indexar», duplicados/canónicos y bloqueos/errores fallan en puntos distintos. Para la mecánica de JavaScript, consulte renderizado y SEO para JavaScript; para el conjunto, el centro del informe Indexación de páginas.

Resumen de IA

Versión condensada de la pestaña Avanzado:

• Significado: la URL sí está en el índice, pero Googlebot no pudo leer contenido útil. Google menciona encubrimiento o formato no indexable y excluye un bloqueo de página mediante robots.txt.
• No equivale a «Rastreada/Descubierta: actualmente sin indexar», ni a un bloqueo de robots.txt, ni a 401/403; todos tienen motivos propios.
• No suele ser JavaScript. En un caso de enero de 2026, Mueller apuntó a un bloqueo de servidor/CDN de bajo nivel, a menudo por IP y dirigido a Googlebot, que no se reproduce con curl. Es un caso, no una clasificación estadística.
• Ramas guiadas por evidencias: servidor/CDN/WAF, entrega específica por cliente, formato, renderizado/recursos, contenido tras interacción o salida vacía.
• Puede costar posiciones: un usuario informó de una caída aproximada del 1 al 15; es un relato individual, no una cifra verificada.
• Empiece por Ver página rastreada en los datos indexados. La prueba en directo no vuelve a probar este estado y «válida» solo significa accesible ahora.
• Verifique Googlebot, correlacione registros y cambie únicamente la regla confirmada tras revisión de seguridad; no permita rangos completos por defecto.
• Más palabras no arreglan contenido ilegible. Tras corregir, use Validar corrección o Solicitar indexación y siga comprobando; no hay plazo fijo.

Documentación oficial

Documentación de fuentes primarias sobre este estado y las herramientas de diagnóstico.

Google

• Informe Indexación de páginas — Ayuda de Search Console: contiene la definición literal “Page indexed without content” (traducción) «Página indexada sin contenido» y los ejemplos de encubrimiento o formato no compatible.
• Herramienta Inspección de URLs — Ayuda de Search Console: explica Ver página rastreada, Probar URL publicada, HTML renderizado, captura, respuesta HTTP y recursos.
• Conceptos básicos de SEO para JavaScript: por qué solo se indexa el contenido del HTML renderizado y cómo comprobarlo.
• Resumen de rastreadores y sistemas de obtención de Google: user-agents y rangos IP publicados de Googlebot.
• Verificar Googlebot y otros rastreadores: comprobación DNS inversa y directa.

Bing / Microsoft

• Bing Webmaster Tools — Inspección de URLs: Bing usa otros estados y no tiene un equivalente exacto, pero ofrece una vista similar de obtención y renderizado para Bingbot.

Citas de la fuente

Texto publicado en la documentación de Google. Cada enlace lleva directamente al pasaje citado en la página de origen.

Google — definición del informe Indexación de páginas

• “This page appears in the Google index, but for some reason Google could not read the content.” (traducción) «Esta página aparece en el índice de Google, pero por algún motivo Google no pudo leer el contenido». — Page Indexing report, Search Console Help. Ir a la cita

Google — JavaScript y el HTML renderizado

• “To make sure that Google can still see your content after it’s rendered, use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.” (traducción) «Para asegurarse de que Google siga viendo su contenido después de renderizarlo, use la prueba de resultados enriquecidos o la herramienta Inspección de URLs y consulte el HTML renderizado». — Conceptos básicos de SEO para JavaScript, Google Search Central. Ir a la cita

Árbol de decisión para el diagnóstico

Recórralo de arriba abajo. El objetivo es dejar de suponer que «es JavaScript» y decidir según lo que Googlebot recibió realmente.

Paso 1 — Confirme que es este estado. ¿La página está en el grupo Indexadas del informe, y no en «Rastreada» o «Descubierta: actualmente sin indexar»? Si está sin indexar, el problema es otro.

Paso 2 — Observe qué obtuvo Googlebot. Inspección de URLs → Ver página rastreada → lea el HTML renderizado y la respuesta HTTP del estado. La captura solo existe en la prueba en directo.

• El renderizado contiene el contenido → el registro quizá esté obsoleto; pruebe la URL publicada, valide o solicite indexación.
• Está vacío, recortado o equivocado → continúe.

Paso 3 — Compare con su navegador. Abra la URL publicada.

• Vacía para Google, completa para usted → hay bloqueo o encubrimiento, no un problema de contenido. Vaya al paso 4.
• Vacía para ambos → hay un problema de renderizado o contenido. Paso 5.

Paso 4 — Rama de bloqueo o encubrimiento. Revise la respuesta HTTP y los recursos para detectar estados distintos de 200, desafíos o recursos bloqueados. Verifique Googlebot por DNS o rangos publicados y audite la gestión de bots, WAF/firewall, listas de IP y límites. Correlacione los registros, cambie solo la regla responsable tras revisión de seguridad y no permita todos los rangos. curl y los rastreadores externos no reproducen un bloqueo por IP.

Paso 5 — Rama de renderizado o contenido. ¿Se renderiza en el cliente, exige clic/desplazamiento o usa un formato no compatible? Corrija con SSR/prerenderizado, HTML renderizado y enlaces reales <a href>; Google no hace clic. Si la página está realmente vacía, esa es la causa.

Paso 6 — Valide. Solo cuando Ver página rastreada muestre contenido real, use Validar corrección o Solicitar indexación y vuelva a inspeccionar.

Lista de diagnóstico de «Página indexada sin contenido»

Sígala en orden: prioriza bloqueos y renderizado, no el número de palabras.

• Confirmé que la URL está en Indexadas, no «Rastreada/Descubierta: sin indexar».
• Ejecuté Inspección de URLs → Ver página rastreada y leí el HTML renderizado y la respuesta HTTP.
• Recordé que la captura solo pertenece a la prueba en directo.
• Busqué estados distintos de 200, desafíos o intersticiales en la respuesta.
• Comprobé recursos JS/CSS críticos bloqueados.
• Comparé la URL publicada en mi navegador con el renderizado indexado.
• No interpreté una prueba en directo «válida» como prueba de resolución.
• Si Google la ve vacía y yo completa, investigué bloqueo o entrega específica, sin asumir encubrimiento intencional.
• Descarté un bloqueo de página por robots.txt y respuestas 401/403.
• Verifiqué Googlebot mediante DNS o rangos publicados.
• Correlacioné registros de CDN/WAF, origen e identificadores para cambiar solo la regla confirmada tras revisión de seguridad.
• No di por buena la página mediante curl o un rastreador externo.
• Si era renderizado, confirmé contenido en el HTML renderizado, sin clic/desplazamiento y con enlaces <a href> reales.
• No intenté arreglarlo simplemente «añadiendo 600 palabras».
• Tras una corrección real, ejecuté Validar corrección o Solicitar indexación y volví a inspeccionar.

Verifique que sea realmente Googlebot

Si sospecha un bloqueo del servidor o CDN, confirme primero que las solicitudes de los registros son realmente de Googlebot; muchos bots falsifican el user-agent. Use DNS inverso y directo, pues Google no publica un atajo.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Si la búsqueda inversa no termina en un dominio de Google o la directa no coincide con la IP original, no es Googlebot. También puede cotejar la IP con los rangos publicados por Google (googlebot.json).

Compare usted mismo el HTML inicial y el renderizado

Esto no reproduce un bloqueo de Googlebot basado en IP, porque la solicitud no sale de Google. Sin embargo, detecta rápidamente una brecha de renderizado en el cliente: si el HTML inicial está casi vacío y se completa tras ejecutar JS, el contenido depende de un renderizado que puede fallar.

macOS / Linux — obtenga el HTML inicial y observe cuánto contenido real contiene:

# Raw HTML as a plain GET (what a crawler sees before rendering)
curl -sL https://example.com/page/ -o raw.html

# Rough "is there content?" check — count visible-ish characters
# (a near-empty body here on a content page is a red flag for CSR)
wc -c raw.html

# Optional: render with a headless browser to compare, if you have Chrome installed
# (Chrome path varies; this dumps the post-JS DOM)
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --dump-dom https://example.com/page/ > rendered.html
wc -c rendered.html

Windows (PowerShell)

# Raw HTML as a plain GET
Invoke-WebRequest -Uri "https://example.com/page/" -OutFile raw.html
(Get-Item raw.html).Length

# Render with headless Chrome to compare (adjust the Chrome path as needed)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --headless --disable-gpu --dump-dom "https://example.com/page/" > rendered.html
(Get-Item rendered.html).Length

Una gran diferencia entre raw.html y rendered.html indica dependencia de JavaScript. Un raw.html pequeño y casi vacío puede quedarse sin contenido si JS falla. En cualquier caso, confirme con Ver página rastreada en Inspección de URLs: es la obtención que refleja lo que recibió Googlebot.

Errores que hacen perder tiempo con este estado

Estos errores dirigen hacia una causa equivocada o destruyen las pruebas necesarias para encontrar la correcta.

Reescribir la página antes de consultar Ver página rastreada. Añadir palabras corrige contenido escaso. Si Google no recibió ningún contenido, el texto adicional tampoco llegará al índice. Consulte primero Ver página rastreada y escriba más solo si el renderizado es escaso, no vacío.

Suponer que es JavaScript y corregir directamente el renderizado. Es la conjetura habitual, pero Mueller señaló normalmente un bloqueo del servidor o CDN. Dedicar un ciclo a SSR o prerenderizado cuando el problema es una regla WAF no elimina el estado y desperdicia trabajo en la capa equivocada.

Dar la página por correcta con curl o un rastreador externo. Un bloqueo por IP no aparece desde su IP ni desde la de un rastreador. Una respuesta limpia de curl no revela qué recibió Googlebot. Probar URL publicada en Inspección de URLs sí obtiene la página como Google.

Pulsar repetidamente Solicitar indexación sin corregir nada. Volver a enviar una página bloqueada solo confirma el mismo renderizado vacío. Solicitar indexación o validar tiene sentido después de que Ver página rastreada muestre contenido real.

Considerar seguro un cambio de CDN/WAF porque su navegación no cambió. La gestión de bots, listas de IP y límites pueden afectar solo a los rangos de Googlebot. «A mí me funciona» no prueba qué ve Google. Verifique sus solicitudes en los registros o con Inspección de URLs antes y después de cualquier cambio.

Confundirlo con «Rastreada/Descubierta: sin indexar», robots.txt o 401/403. Cada caso tiene un motivo propio. Los dos primeros significan que la página no está indexada; un disallow o un 401/403 real también tienen estados específicos. Aquí la página sí está indexada, pero es ilegible. Mejorar enlaces internos, prioridad del sitemap o robots no corrige la causa real.

Llamar «encubrimiento» a toda diferencia entre bots y usuarios. La política de spam exige intención de manipular. Una respuesta vacía accidental por una CDN mal configurada es un fallo de entrega, no prueba de infracción. La etiqueta equivocada lleva a responder a una acción manual en vez de corregir la configuración.

«Página indexada sin contenido»: referencia rápida

Qué es

No lo confunda con estados próximos

Ramas de causas: siga la evidencia, no un orden fijo

Qué herramienta responde a cada pregunta

Prompts de IA listos para copiar

Sirven para diagnosticar con resultados reales, no para adivinar desde una descripción. Pegue la salida de las herramientas y confirme siempre la lectura de la IA con Inspección de URLs antes de actuar.

Diagnostique la causa probable a partir de Inspección de URLs

I'm diagnosing a "Page indexed without content" status in Google Search Console.
Here's what I have:
- Rendered HTML from View Crawled Page: [paste it, or "blank"]
- HTTP response status/headers from View Crawled Page: [paste them]
- What the live page looks like in my own browser: [describe or paste raw HTML]
- Whether Test Live URL shows the same result: [yes/no + what it showed]

Based only on this evidence, rank the most likely cause among: (1) a server/CDN/WAF
block targeting Googlebot, (2) cloaking, (3) a JavaScript rendering failure,
(4) content gated behind a click or scroll, (5) a genuinely blank page or
unsupported format. Explain which specific detail above points to your top pick,
and tell me what additional evidence would confirm or rule it out. Don't assume
JavaScript is the cause by default.

Audite una configuración de CDN/WAF en busca de una regla que bloquee Googlebot

Here is a description of my CDN/WAF setup: [paste your bot-management settings,
rate-limit rules, IP allowlist/denylist entries, and any custom firewall rules].
Google's crawler IP ranges are published at
https://developers.google.com/static/search/apis/ipranges/googlebot.json.
Identify any rule that could return an empty response, a challenge page, or a
non-200 status to Googlebot's IP ranges specifically, even if normal visitor
traffic is unaffected. List each suspect rule and what to check or relax first.

Redacte una escalación al proveedor de alojamiento o CDN

Draft a short, specific support ticket to my hosting/CDN provider. Context: Google
Search Console shows "Page indexed without content" for [URL]. Google's own
View Crawled Page tool shows an empty/blocked response, while the page loads fully
in a normal browser — which points at a server or CDN-level block on Googlebot's
IP ranges, not a content or JavaScript issue. Ask them to check bot-management,
WAF, and rate-limiting logs for requests from Google's published crawler IP ranges
around [date/time], and to confirm whether any rule is blocking or challenging
those requests.

Demuestre que Googlebot recibe contenido ahora

«Cambié la regla WAF» o «corregí el renderizado» no son pruebas. Importa lo que Googlebot reciba en la siguiente obtención; estas pruebas verifican ese resultado.

Prueba 1 — Confirme la corrección en lo que Google inspecciona

• Prueba — Inspeccione la URL y ejecute primero Probar URL publicada. No vuelve a probar el estado indexado, pero confirma acceso actual y ofrece una captura. Lea después HTML renderizado y respuesta HTTP; compare con Render Gap si el problema era el renderizado en cliente.
• Resultado esperado — HTML y captura contienen el contenido real, igual que para un visitante, con respuesta HTTP 200.
• Interpretación del fallo — Si sigue vacía, recortada o sin 200, el bloqueo, diferencia de entrega o fallo de renderizado continúa. No valide todavía. Esto confirma acceso actual, no la actualización del estado indexado.
• Ventana — La prueba en directo es inmediata; el estado indexado cambia tras un rastreo futuro, cuyo calendario no se publica.
• Retroceso — Si sigue vacía o sin 200, revise las ramas de causa en vez de repetir Solicitar indexación.

Prueba 2 — Las solicitudes confirmadas de Googlebot reciben un 200 completo

• Prueba — Extraiga registros recientes de servidor/CDN, aísle IP confirmadas por DNS o rangos publicados y use Log File Analyzer para separar Googlebot real de user-agents falsos. Compare estados y tamaños.
• Resultado esperado — Solicitudes confirmadas devuelven 200 y un cuerpo completo, no un desafío, cuerpo vacío ni otro estado.
• Interpretación del fallo — Si siguen bloqueadas o vacías, la regla modificada no era la causa o no se relajó lo suficiente.
• Ventana — Observe varias visitas; Google no publica un calendario fijo.
• Retroceso — Si el tráfico confirmado sigue bloqueado, vuelva a auditar las reglas antibots y no suponga que el primer cambio bastó.

Prueba 3 — El estado deja de repetirse

• Prueba — Ejecute Validar corrección en Indexación de páginas y vuelva a comprobar periódicamente el contenido con Google Index Checker.
• Resultado esperado — La validación pasa y las comprobaciones siguen mostrando contenido real indexado, sin volver a quedar vacío.
• Interpretación del fallo — Un fallo o reaparición suele indicar un problema intermitente de bloqueo o renderizado.
• Ventana — No hay plazo fijo de rastreo o validación; revise hasta que el informe se actualice.
• Retroceso — Si reaparece «indexada sin contenido» tras validar, considérelo sin resolver y reinicie desde la prueba 1.

Póngase a prueba: Página indexada sin contenido

Cinco preguntas breves sobre el estado «Página indexada sin contenido» de GSC. Elija una respuesta en cada caso y compruébela.

Registro de cambios