Bloqueada por robots.txt: qué significa este estado de Search Console y cómo corregirlo

El estado bloqueada por robots.txt aparece en el informe de indexación de páginas de Google Search Console, entre los motivos por los que las páginas no se indexan. La documentación del informe de indexación de páginas lo describe en una línea: la página se ha bloqueado mediante el archivo robots.txt de su sitio. Detrás de esa línea hay dos situaciones muy distintas, un bloqueo sano y uno accidental, además de un pariente confuso: «Indexada, aunque un archivo robots.txt la ha bloqueado». Esta guía explica cómo distinguirlas y corregir cada una sin romper nada más. Si el archivo es nuevo para usted, empiece por nuestra definición de robots.txt.

¿Qué significa «Bloqueada por robots.txt» en Search Console?

Su archivo robots.txt está en la raíz del host (ejemplo.com/robots.txt) e indica a los rastreadores qué rutas pueden obtener. Cuando Googlebot encuentra una URL, por un enlace o un sitemap, consulta primero ese archivo. Si una regla Disallow coincide con la ruta para su user agent, no descarga la página. Search Console muestra entonces la URL en «Bloqueada por robots.txt».

De ahí salen dos consecuencias. Google no ve el contenido, el título, los enlaces internos ni ninguna metaetiqueta de la página. Y como nunca la lee, tampoco ve una etiqueta noindex. El estado figura como motivo de no indexación y, para la mayoría de los sitios, es informativo: Google mismo señala que las URL bloqueadas por robots.txt probablemente lo están a propósito.

El problema empieza cuando la lista contiene páginas que quiere ver en Google: fichas de producto, artículos, categorías o el sitio entero tras una migración. En ese caso el bloqueo es una causa directa de un sitio web que no aparece en Google, y uno de los problemas técnicos más rápidos de resolver.

«Bloqueada por robots.txt» frente a «Indexada, aunque bloqueada»

El segundo estado parece contradictorio, y es el que más preocupa a los propietarios de sitios. La introducción de Google a robots.txt lo explica: robots.txt no sirve para mantener una página fuera de Google. Si otras páginas enlazan a una URL prohibida, Google puede indexar la URL sin rastrearla. El resultado muestra entonces la dirección sin descripción, porque Google nunca leyó el texto.

La clave es decidir primero qué quiere para cada URL: indexada o no indexada. Robots.txt responde a otra pregunta (rastreada o no rastreada), y mezclar ambas es el origen de la mayoría de los errores.

¿Por qué sus páginas están bloqueadas por robots.txt?

La mayoría de los bloqueos accidentales vienen de unas pocas causas. Revíselas en este orden:

• Una regla de preproducción que llega a producción. Disallow: / protege un sitio de pruebas, se publica con el lanzamiento y lo bloquea todo.
• Un ajuste del CMS. WordPress tiene la opción «Disuadir a los motores de búsqueda de indexar este sitio»; otras plataformas tienen interruptores equivalentes que editan robots.txt o añaden cabeceras.
• Una regla más amplia de lo previsto. Disallow: /p bloquea /productos/ y /precios/ además de /p/. Las reglas de robots.txt afectan al inicio de la ruta.
• Comodines. * equivale a cualquier secuencia de caracteres y $ marca el final de una URL. Disallow: /*? bloquea todas las URL con parámetros, lo que puede incluir páginas paginadas o filtradas que quiere indexar.
• Recursos bloqueados. Bloquear /assets/ o /wp-includes/ oculta el CSS y el JavaScript que Google necesita para renderizar la página, y empeora su comprensión del contenido.
• Una migración. Las rutas cambian, el robots.txt antiguo se queda o el nuevo alojamiento sirve su propio archivo por defecto.
• El host equivocado. Cada subdominio y protocolo tiene su propio archivo: las reglas de www.ejemplo.com no se aplican a tienda.ejemplo.com.

Recuerde que Google sigue la regla más específica (la ruta coincidente más larga) y, cuando un Allow y un Disallow son igual de específicos, gana el menos restrictivo. Un Allow: /blog/ concreto puede, por tanto, reabrir una carpeta situada bajo un bloqueo más amplio.

Cómo corregir «Bloqueada por robots.txt» paso a paso

1. Exporte las URL afectadas

En Google Search Console, abra Indexación, luego Páginas, y haga clic en la fila «Bloqueada por robots.txt». Exporte la lista y ordénela por carpeta. Normalmente verá un patrón en un minuto: un directorio, un parámetro, un subdominio.

2. Separe los bloqueos intencionados de los errores

Marque cada patrón como «mantener bloqueado» o «debe estar en Google». Carritos, procesos de pago, cuentas de cliente, resultados de búsqueda interna y zonas de administración van al primer grupo. Todo lo que responde a una búsqueda, recibe enlaces o figura en su sitemap XML va al segundo. Una URL que está en el sitemap y bloqueada a la vez es una contradicción que hay que resolver.

3. Encuentre la regla que coincide

Abra la herramienta de inspección de URLs con una URL de ejemplo: indica si el rastreo está permitido. Después lea el archivo publicado o pegue la URL en nuestro comprobador de robots.txt gratuito para ver qué línea la bloquea y para qué user agent.

4. Edite el archivo

Elimine o acote la regla, o añada un Allow más específico. Haga un cambio mínimo y pruébelo tanto con una URL que quiere desbloquear como con una que debe seguir bloqueada. Si el archivo está desordenado, cree uno limpio con nuestro generador de robots.txt y compárelos antes de publicar.

5. Haga que Google lea el nuevo archivo

Google suele guardar robots.txt en caché hasta 24 horas, según su especificación de robots.txt. Para acelerar, abra Ajustes y luego el informe de robots.txt de Search Console (disponible para propiedades de dominio), y solicite un nuevo rastreo del archivo. Después, solicite la indexación de sus URL desbloqueadas más importantes en la inspección de URLs.

6. Valide y vigile

Haga clic en «Validar corrección» en la página del problema. La validación puede tardar de varios días a algunas semanas, y las URL nuevas se comprueban a medida que Google las vuelve a rastrear. Nuestra guía sobre la indexación en Google explica qué ocurre después del rastreo, cuando Google decide si una página merece quedarse.

Cómo corregir «Indexada, aunque un archivo robots.txt la ha bloqueado»

La corrección depende de lo que quiera para la página:

1. Quiere la página en Google. Quite el bloqueo. Google rastreará la página, leerá su contenido y mostrará un resultado normal con título y descripción.
2. No quiere la página en Google. Quite también el bloqueo y añada <meta name="robots" content="noindex"> en el head, o una cabecera HTTP X-Robots-Tag: noindex para PDF y otros archivos. Cuando Google haya rastreado de nuevo la página y la haya retirado, puede volver a bloquearla si el volumen de rastreo importa, algo que la mayoría de los sitios nunca necesita. Nuestra definición de noindex explica las opciones.
3. La página no debería ser pública. Protéjala con contraseña o elimínela (404 o 410). Ni robots.txt ni noindex son medidas de seguridad.

En una navegación por facetas con miles de URL de filtros, un bloqueo en robots.txt puede seguir siendo la herramienta adecuada para ahorrar presupuesto de rastreo. La advertencia «Indexada, aunque bloqueada» en algunas de esas URL es entonces aceptable, siempre que las versiones canónicas de sus categorías sean rastreables e indexadas.

Cómo comprobar que la corrección ha funcionado

Tres señales confirman una corrección correcta. La inspección de la URL publicada muestra «Rastreo permitido: Sí». El número de páginas bloqueadas en el informe de indexación de páginas baja en las semanas siguientes. Y las páginas desbloqueadas empiezan a sumar impresiones en el informe de rendimiento. Una pasada rápida con nuestro comprobador de indexabilidad detecta también los otros frenos que suelen acompañar a los errores de robots.txt: un noindex olvidado, una canónica errónea o una redirección.

Vigilar importa porque estos errores vuelven. Una actualización del tema, un plugin o un script de despliegue pueden reescribir robots.txt sin que nadie lo note. Seguir las páginas cuyos clics e impresiones caen de golpe es la alerta temprana más rápida.

El panel GEO y SEO de Sorank se conecta a Search Console y muestra esas páginas al alza y a la baja en una sola vista, de modo que un bloqueo introducido por un despliegue aparece como un grupo de URL en descenso y no como una pérdida lenta e inexplicable.

Robots.txt, rastreadores de IA y GEO

Robots.txt tiene ahora un segundo público: los rastreadores de los asistentes de IA. OpenAI, Anthropic, Perplexity y Google publican sus user agents (GPTBot y OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended), que respetan robots.txt. Una regla pensada para uno de ellos, o un bloqueo general User-agent: *, decide si ChatGPT, Claude o Perplexity pueden leer sus páginas cuando buscan en la web para construir una respuesta.

Se aplica el mismo razonamiento que con Google: decida bot por bot qué quiere. Bloquear los rastreadores de entrenamiento y permitir los de búsqueda es un compromiso habitual, y nuestra guía de robots.txt para rastreadores de IA enumera los user agents y las reglas de cada uno. La entrada del glosario sobre rastreadores de IA explica qué hace cada bot.

Para ver el efecto de estas decisiones, siga los prompts que importan para su negocio. El seguimiento de menciones en IA de Sorank muestra si ChatGPT, Gemini o Claude citan su sitio, y qué competidores citan en su lugar.

La regla que debe recordar

Robots.txt decide lo que los rastreadores pueden leer; noindex decide lo que los resultados pueden mostrar. Reserve los bloqueos para zonas sin valor de búsqueda, no bloquee nunca una página que quiere indexar o desindexar y revise el informe de indexación de páginas tras cada migración o despliegue. La mayoría de los problemas de «bloqueada por robots.txt» se resuelven en minutos en cuanto se encuentra la regla culpable, y el panel de Search Console de Sorank le ayuda a detectar el siguiente antes de que le cueste tráfico.