"Bloqueada por robots.txt": ¿error o bloqueo intencionado? (Search Console)
En el informe "Indexación de páginas" de Google Search Console, «Bloqueada por el archivo robots.txt» no suele provocar ninguna inquietud. La mayoría de esas URLs se apartaron del rastreo a propósito —páginas de administración, carrito, filtros— y el informe muestra exactamente cuáles. El bloqueo cumple su función.
El tema se vuelve menos evidente cuando se mira de cerca. ¿Cómo detectar, en una lista de cientos de bloqueos legítimos, la página estratégica atrapada por una regla Disallow demasiado amplia? ¿Por qué una URL bloqueada al rastreo termina a veces indexada igual? ¿Y bloquear una página en el robots.txt basta de verdad para sacarla de Google?
Tres preguntas simples en apariencia, cuyas respuestas separan los bloqueos sanos de los problemas reales.
¿Qué significa "Bloqueada por robots.txt"?
Significa que Google renunció a rastrear la URL porque una regla Disallow de tu robots.txt se lo impide. La página, por tanto, ni se rastrea ni se indexa: el bloqueo hizo exactamente lo que se le pedía. En la mayoría de los casos, no es un error.
En la práctica, Googlebot vio la URL —a menudo mediante un enlace o tu sitemap— pero no la descargó: se detuvo en la directiva Disallow que la cubre. Search Console lista las URLs afectadas, y la inspección de URL indica qué línea del robots.txt se aplica. Así que ya sabes qué está bloqueado; queda decidir si debía estarlo.
La pregunta nunca es «cómo hago desaparecer este estado», sino «¿estas páginas debían estar bloqueadas?».
Un rastreo bloqueado no juzga la página
Primer malentendido a despejar: este estado no dice nada sobre la calidad de la página. Google no la leyó. No comparó su contenido, no evaluó su relevancia, no decidió que no merecía la indexación. Se detuvo en la puerta, porque tu robots.txt se lo pidió.
Eso lo diferencia de los estados de calidad como Explorada, actualmente no indexada, donde Google sí leyó la página antes de descartarla. Aquí no hay veredicto: hay una instrucción que Google siguió.
La consecuencia práctica: si una página importante cae en este estado, su contenido nunca es lo que hay que corregir. Es el bloqueo.
¿Es un problema? Depende de tu intención
No hay una respuesta única. Depende de lo que quisieras hacer con la página. Dos casos, dos decisiones opuestas. Mientras no distingas entre ambos, no puedes aplicar la corrección correcta.
Caso A: el bloqueo es intencionado, todo va bien. Páginas de administración, carrito, proceso de compra, cuentas de cliente, resultados de búsqueda interna, páginas de filtros y ordenación infinitas, entorno de preproducción… Las bloqueaste para ahorrar presupuesto de rastreo y mantener esas URLs fuera de Google. Verlas listadas en «Bloqueada por robots.txt» es exactamente el resultado esperado. No hay nada que corregir.
Caso B: una página útil está bloqueada por error. Una página que querías en Google queda atrapada por una regla Disallow demasiado amplia, o por un bloqueo heredado de una preproducción nunca retirado. Mientras esté bloqueada, Google no puede rastrearla, así que nunca se posicionará bien. Aquí el objetivo es el opuesto del caso A: retirar el bloqueo para que Google pueda por fin leer la página.
Distinguir A de B es todo el trabajo. Y antes de abordarlo, conviene despejar una confusión que hace perder muchísimo tiempo.
"Bloqueada" vs "Indexada aunque bloqueada": no las confundas
Dos estados de Search Console hablan de robots.txt y se confunden constantemente. La diferencia se reduce a una pregunta: ¿Google acabó indexando la URL pese al bloqueo?
| Estado GSC | ¿Rastreada? | ¿Indexada? | Qué significa |
|---|---|---|---|
| Bloqueada por robots.txt | No | No | Google respeta el bloqueo. La página no aparece en los resultados. El bloqueo funcionó. |
| Indexada aunque bloqueada por robots.txt | No | Sí | Google encontró la URL en otro sitio (enlaces, sitemap) y la indexó sin leerla. Aparece, a menudo sin descripción. |
El estado de este artículo es el «limpio» de los dos: el bloqueo se sostiene, la página queda fuera del índice. Si, por el contrario, tus páginas bloqueadas aparecen igual en Google, te enfrentas al otro estado, que pide un enfoque muy distinto: lo detallamos en «Indexada aunque bloqueada por robots.txt».
Esta distinción revela una trampa clásica: el robots.txt no es una herramienta de desindexación. Bloquear el rastreo impide que Google lea la página, no necesariamente que la liste si se entera de ella por otro lado. Google lo dice con claridad: el robots.txt «no es un mecanismo para mantener una página fuera de Google». Para sacar una página del índice, la herramienta es la etiqueta noindex —y para que Google vea ese noindex, la página justamente no debe estar bloqueada al rastreo. (Un artículo dedicado al estado «Excluida por la etiqueta noindex» está en camino.)
Por qué una página útil acaba bloqueada (caso B)
Cuando una página que querías indexar cae en este estado, la causa es casi siempre una regla robots.txt demasiado amplia u olvidada. Los desencadenantes más frecuentes:
- Una regla
Disallowdemasiado general.Disallow: /blogbloquea no solo/blog, sino todo lo que empieza por esa ruta, incluido/blog/mi-articulo-clave. Un prefijo mal delimitado arrastra páginas que querías conservar. - Un comodín mal controlado. Los patrones con
*(p. ej.Disallow: /*?) bloquean familias enteras de URLs. Útil para los parámetros, peligroso cuando el patrón atrapa páginas legítimas. - Un bloqueo heredado de preproducción. Durante el desarrollo, el sitio suele protegerse con un
Disallow: /global. Si esa línea pasa a producción sin retirarse, todo el sitio queda bloqueado. - Un CMS o plugin mal configurado. En WordPress, la opción «Pedir a los motores de búsqueda que no indexen este sitio» (Ajustes → Lectura) añade un bloqueo global. Algunos temas y extensiones generan también sus propias reglas.
- Una ruta de recursos errónea. Bloquear
/wp-content/o una carpeta de recursos puede impedir que Google cargue el CSS y el JavaScript necesarios para renderizar la página.
El hilo conductor: en algún punto de tu robots.txt, una línea dice «no rastrees esto» cuando querías lo contrario. Todo el trabajo consiste en encontrar cuál, y sobre qué URLs golpea.
Ahora que conoces las causas, identifica con precisión qué páginas están afectadas, antes de decidir qué desbloquear.
Identificar las páginas afectadas en la lista que analizas
Aquí es donde Search Console muestra su límite: su herramienta de inspección de URL trata una sola URL cada vez. Para saber, página por página, cuál está bloqueada y por qué regla, inspeccionas, lees, pasas a la siguiente. Viable con unas pocas páginas. Con cientos, comprobar que ninguna página estratégica está atrapada se vuelve impracticable.
Ese es el muro que IndexProbe derriba. IndexProbe es la versión en masa de la herramienta de inspección de URL de Google: consulta la API oficial de Search Console para inspeccionar, en un solo análisis, la lista de URLs que le proporcionas (importación CSV, sitemap, copiar y pegar). Para cada página muestra su estado de indexación, su estado robots.txt (permitida o bloqueada), el segmento de URL y los enlaces internos que recibe.
Lo que obtienes depende de la lista que aportes. IndexProbe no rastrea tu sitio para descubrir URLs: inspecciona las que le das, y solo esas.
- Una selección de páginas estratégicas (tus páginas clave, tu sitemap de páginas a indexar). Cualquier página importante que aparezca como «Bloqueada por robots.txt» es un caso B inmediato: una página que querías indexar, cerrada al rastreo por error. La detectas sin presuponer nada del resto del sitio.
- Una exportación completa de tus URLs (sitemap entero, exportación de rastreo…). El desglose por tipo de página muestra entonces dónde se concentra el bloqueo —un vistazo basta para ver que admin, carrito y filtros están muy bloqueados (sano), mientras que productos y blog casi nunca deberían estarlo.
Ese es exactamente el triaje que IndexProbe está diseñado para hacer posible: separar el bloqueo intencionado de la página útil atrapada, en todas tus URLs de un vistazo.
💡 ¿Quieres saber cuáles de tus URLs están bloqueadas por robots.txt, y si una página estratégica está atrapada? IndexProbe inspecciona tu lista de URLs y te da la respuesta en un análisis. Probar IndexProbe en acceso anticipado →
Corregir según el caso
Una vez triadas tus páginas, la corrección depende del caso. No los mezcles: la acción correcta para una página útil es lo opuesto a «no toques nada».
Hacer que se rastree una página útil (caso B)
El objetivo es retirar el bloqueo que impide a Google leer la página.
- Encuentra la regla exacta que bloquea la URL. En Search Console, la inspección de URL indica qué línea del
robots.txtse aplica. Identifica la directivaDisallowresponsable. - Afina o retira esa regla. Si es demasiado amplia (
Disallow: /blog), ajústala a lo que realmente querías bloquear, o añade una excepción (Allow:) para la página a liberar. Si es un resto de preproducción (Disallow: /), elimínala. - Comprueba que no quede ningún
noindexen la página: una vez desbloqueada, debe poder indexarse. - Solicita una reinspección en Search Console, y luego da tiempo a Google para volver a rastrear. El estado solo cambia en el siguiente paso de Googlebot.
Dejar o afinar un bloqueo intencionado (caso A)
Para las páginas que sí querías bloquear, no hay nada que corregir: el estado es el resultado esperado. Aprovecha simplemente para comprobar que tus reglas no son ni demasiado amplias (podrían atrapar una página útil) ni demasiado estrechas (dejarían pasar URLs que querías bloquear). Y recuerda: si una de esas páginas además debe desaparecer del índice porque se filtró en él, el robots.txt no basta —hace falta un noindex, es decir, desbloquear primero (ver «Indexada aunque bloqueada»).
Según tu CMS
- WordPress. Comprueba primero Ajustes → Lectura: la casilla «Pedir a los motores de búsqueda que no indexen este sitio» añade un bloqueo global, a desmarcar en producción. Para editar las reglas, usa el
robots.txtvirtual gestionado por Yoast SEO o Rank Math, o un archivo físico en la raíz. - Shopify. Las reglas por defecto bloquean
/cart,/checkout,/account(páginas que efectivamente no quieres indexar). Para ajustarlas, edita el archivorobots.txt.liquiddel tema —con prudencia, liberando solo lo que deba liberarse.
"Bloqueada" vs "Indexada aunque bloqueada" vs "Excluida por noindex"
Tres estados de Search Console se parecen y se resuelven de forma muy distinta. La guía rápida:
| Estado GSC | De dónde viene el bloqueo | ¿Indexada? | Acción |
|---|---|---|---|
| Bloqueada por robots.txt | robots.txt (rastreo prohibido) |
No | Nada si es intencionado; desbloquear si hay una página útil atrapada |
| Indexada aunque bloqueada por robots.txt | robots.txt, pero URL encontrada en otro sitio |
Sí | Desbloquear y luego noindex para desindexar |
| Excluida por la etiqueta 'noindex' | etiqueta noindex en la página |
No | Nada si es intencionado; retirar el noindex si es una página útil |
Cada uno tiene su lógica: el primero bloquea el rastreo, el segundo revela que el bloqueo no bastó para mantener la página fuera del índice, el tercero es una exclusión voluntaria a nivel de página. Confundirlos es aplicar la corrección equivocada. (El artículo «Excluida por la etiqueta noindex» está en camino.)
Comprobar que la corrección funcionó
Tras desbloquear tus páginas del caso B, confirma a escala que Google volvió a pasar. Reinspecciona tus URLs y compara dos análisis en el tiempo: las páginas que liberaste deben salir del estado «Bloqueada por robots.txt», rastrearse y luego pasar a indexadas.
Es el ciclo completo: entender que el bloqueo suele ser normal, triar A/B, desbloquear sin caer en la trampa del noindex, comprobar.
Preguntas frecuentes
«Bloqueada por robots.txt», ¿es grave? No en sí mismo. En la mayoría de los casos es un bloqueo intencionado que cumple su función: admin, carrito, filtros que no quieres en Google. Solo se convierte en problema si una página que querías indexar queda bloqueada por error.
¿Por qué una de mis páginas importantes está bloqueada?
Casi siempre por una regla Disallow demasiado amplia, un comodín mal configurado o un bloqueo heredado de preproducción. Inspecciona la URL en Search Console para ver qué línea del robots.txt se aplica, y luego afina o retira esa regla.
¿Cómo desbloquear una página bloqueada por robots.txt?
Encuentra la regla Disallow responsable en tu robots.txt, retírala o ajústala (con una directiva Allow si hace falta), comprueba que no quede ningún noindex en la página, y solicita una reinspección en Search Console.
¿robots.txt o noindex?
Depende del objetivo. El robots.txt impide el rastreo (útil para ahorrar presupuesto de rastreo en páginas sin valor). El noindex impide la indexación (útil para que una página no aparezca en los resultados). Para desindexar una página hace falta un noindex que Google pueda ver, es decir, una página no bloqueada al rastreo.
¿Qué diferencia hay con "Indexada aunque bloqueada por robots.txt"? «Bloqueada» significa que la página ni se rastrea ni se indexa: el bloqueo se sostiene. «Indexada aunque bloqueada» significa que Google indexó la URL pese a la regla, porque la encontró en otro sitio. El segundo pide acción; el primero, casi nunca.
¿Cómo comprobar este estado en un gran número de URLs?
La inspección de URL de Search Console trata una URL cada vez. Para triar a escala, una herramienta como IndexProbe inspecciona la lista de URLs que le proporcionas (CSV, sitemap) y muestra, para cada una, el estado de indexación, el estado robots.txt y los enlaces internos que recibe.
Deja de adivinar qué páginas están bloqueadas de verdad. IndexProbe se conecta a la API oficial de Search Console e inspecciona tu lista de URLs en un solo análisis: estado de indexación, estado robots.txt y estado noindex lado a lado. En minutos separas los bloqueos intencionados de las páginas útiles atrapadas, y verificas tus correcciones de un análisis al siguiente.