El archivo robots.txt ha bloqueado la URL: cuándo es correcto y cuándo no

"El archivo robots.txt ha bloqueado la URL" significa que Google no rastreó la URL porque una regla de su archivo robots.txt lo prohíbe, y la URL no está en el índice. En la mayoría de los sitios, el estado es correcto: las áreas de administración, los carritos, la búsqueda interna y las URLs con parámetros se bloquean a propósito. Solo le cuesta algo cuando la regla atrapa una página que usted quiere en la búsqueda, y la tarea consiste en encontrar esas páginas entre las bloqueadas intencionadamente.

Hasta 2022, el Informe de cobertura de indexación de Search Console usaba 2 nombres para este caso: "El archivo robots.txt ha bloqueado la URL enviada", para las URLs incluidas en un sitemap enviado, y "Bloqueada por robots.txt", para el resto. Si usa Search Console en inglés, el estado actual se llama "URL blocked by robots.txt". En alemán, la documentación de ayuda de Google lo recoge ahora como "URL wird von der robots.txt-Datei blockiert"; el nombre anterior era "Durch robots.txt-Datei blockiert". Si su informe dice "Se ha indexado aunque un archivo robots.txt la tenía bloqueada", la URL está en el índice pese al bloqueo, y ese estado tiene su propia guía.

Qué significa este estado según Google

La documentación de Google sobre el informe "Indexación de páginas" (consultada en octubre de 2026) incluye "El archivo robots.txt ha bloqueado la URL" en el grupo "Sin indexar" y explica que el archivo robots.txt del sitio bloqueó la página. La misma documentación presenta todo el grupo "Sin indexar" diciendo que esas páginas no están indexadas, "pero no necesariamente por un error".

El bloqueo tiene 2 consecuencias para su decisión:

• El bloqueo impide el rastreo, no la indexación. La documentación de Google añade que un bloqueo no garantiza que la página se quede fuera del índice. Si Google encuentra información sobre la página sin cargarla, por ejemplo enlaces desde otras páginas, hay una pequeña probabilidad de que se indexe igualmente y pase a "Se ha indexado aunque un archivo robots.txt la tenía bloqueada".
• Google nunca ve la página. Ni título, ni contenido, ni los enlaces que contiene, ni etiqueta canónica, ni noindex. Lo que la página diga de sí misma es invisible mientras la regla siga vigente.

¿Es un problema? Separe los bloqueos intencionados de los accidentales

Empiece por el filtro de la parte superior del informe "Indexación de páginas". Cámbielo de "Todas las páginas conocidas" a "Todas las páginas enviadas". Las URLs bloqueadas que aparecen en "Todas las páginas enviadas" están incluidas en un sitemap que usted envió: le está pidiendo a Google que las indexe mientras robots.txt le prohíbe rastrearlas. Esa contradicción es casi siempre un error, sea cual sea la intención de la regla.

En 29 sitios web externos enviados para una auditoría de SEOReport cuyas páginas del sitemap descargamos entre mayo y octubre de 2026, 2 (7%) incluían en su sitemap URLs que su propio robots.txt bloquea. No es el problema de sitemap más frecuente, pero es el que bloquea páginas que el sitio ya ha declarado importantes.

Los patrones accidentales, con el antes y el después

Cada patrón siguiente es una regla que funcionó tal como estaba escrita y bloqueó más de lo previsto.

1. El archivo de staging que llegó a producción. Un sitio de desarrollo está bloqueado por completo, y el archivo viaja a producción con el resto de la compilación.

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. Un prefijo demasiado corto. Google compara una regla desde el principio de la ruta de la URL, así que Disallow: /search bloquea /search?q=shoes, y también /search-engine-basics/, un artículo real.

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. Un comodín que atrapa páginas de destino. * coincide con cualquier secuencia de caracteres, y la comparación de Google incluye la cadena de consulta. Disallow: /*? bloquea todas las URLs con parámetros, incluidas las páginas de categoría paginadas como /shoes/?page=2, que quizá quiera que se rastreen para que se encuentren los productos que contienen.

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

La misma trampa se aplica a las extensiones de archivo. En un sitio cuyas páginas terminan en .php, Disallow: /*.php bloquea todo el catálogo.

4. Un grupo de Googlebot olvidado. La especificación de robots.txt de Google indica que un rastreador solo sigue el grupo más específico que lo nombra, y que los grupos específicos y el grupo * no se combinan. Un grupo User-agent: Googlebot escrito para una migración hace años sigue aplicándose a Googlebot, mientras el equipo edita solo el grupo * y no se explica el bloqueo.

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

La solución es eliminar el grupo antiguo o copiar en él las reglas actuales. La misma regla explica un efecto secundario habitual de las políticas para rastreadores de IA: un sitio que añade grupos con nombre para bots concretos debe repetir en cada uno todas las reglas compartidas. Nuestra tabla de decisión sobre robots.txt y rastreadores de IA muestra patrones que mantienen separadas las reglas de búsqueda y las de IA.

5. Recursos de renderizado bloqueados. Disallow: /assets/ o Disallow: /static/ bloquea el CSS y el JavaScript que cargan sus páginas. La introducción de Google a robots.txt indica que puede bloquear recursos poco importantes, pero no aquellos cuya ausencia dificulte a Google entender la página. Estos archivos bloqueados rara vez aparecen como páginas en el informe "Indexación de páginas", así que búsquelos desde el lado de la página: ejecute una prueba en directo en Inspección de URLs y abra "Ver página probada" y, después, "Más información" para ver los recursos de la página que cargó Google. Revise también el host de los recursos: robots.txt se aplica por host, protocolo y puerto, así que los archivos servidos desde cdn.example.com siguen el robots.txt propio de ese host. Un script bloqueado que construye el contenido de la página importa sobre todo en los sitios que renderizan en el navegador, que trata nuestra guía de renderizado de JavaScript.

Cómo probar una regla de robots.txt con una URL

No necesita ninguna herramienta para predecir la decisión de Google. Con la especificación de Google, son 4 pasos.

flowchart TD
    A["URL que quiere probar"] --> B["Abra robots.txt en el mismo host y protocolo"]
    B --> C{"¿Hay un grupo para Googlebot?"}
    C -->|sí| D["Use solo ese grupo"]
    C -->|no| E["Use el grupo *"]
    D --> F["Enumere cada Allow y Disallow que coincide con la ruta"]
    E --> F
    F --> G{"¿Alguna coincidencia?"}
    G -->|no| H["Permitida"]
    G -->|sí| I["Gana la regla con la ruta más larga"]
    I --> J{"¿Allow y Disallow igual de largos?"}
    J -->|sí| H
    J -->|no| K["Aplique la regla más larga"]

1. Elija el archivo. Abra /robots.txt en el host y el protocolo exactos de la URL. https://www.example.com/robots.txt no rige https://shop.example.com/.
2. Elija el grupo. Use el grupo User-agent más específico que coincida con Googlebot. Los nombres de user agent no distinguen entre mayúsculas y minúsculas.
3. Encuentre las reglas que coinciden. Una regla coincide si su ruta coincide con el principio de la ruta y la consulta de la URL. * coincide con cualquier carácter, $ marca el final de la URL, y las rutas distinguen entre mayúsculas y minúsculas: /Shop/ no coincide con /shop/.
4. Elija la ganadora. Gana la regla con la ruta más larga. Si un Allow y un Disallow empatan, Google aplica la menos restrictiva, el Allow.

Este es el método aplicado al archivo "después" del patrón 3, más Disallow: /search:

Para comprobar la interpretación de Google y no la suya, ejecute Inspección de URLs sobre la URL. En los detalles del rastreo, "¿Se permite el rastreo?" muestra si una regla de robots.txt bloquea a Google, y una prueba en directo aplica el archivo que Google puede descargar en ese momento. Google también publica su analizador de robots.txt como biblioteca de código abierto, que los desarrolladores pueden ejecutar contra un borrador del archivo antes de publicarlo.

Corrija la regla y después valide

Cambie el archivo para que las páginas que quiere que se rastreen dejen de coincidir. Acote un Disallow demasiado amplio, añada un Allow más largo para la excepción o elimine un grupo que haya quedado de otra época. Después:

1. Descargue el archivo publicado para confirmar que el servidor sirve su cambio y no una copia en caché o generada en la compilación: curl -s https://www.example.com/robots.txt.
2. Solicite que se vuelva a rastrear robots.txt desde el informe de robots.txt de Search Console. Google suele almacenar el archivo en caché durante un máximo de 24 horas, y la ayuda del informe menciona el desbloqueo de URLs importantes como motivo para solicitar un nuevo rastreo. El informe muestra cuándo descargó Google el archivo por última vez y cualquier error o advertencia; una línea con un error se ignora.
3. Ejecute una prueba en directo en Inspección de URLs con 2 o 3 URLs afectadas. "¿Se permite el rastreo?" debería indicar ahora que sí. Use "Solicitar indexación" en las páginas que más importan; la ayuda de Google indica que la indexación puede tardar hasta una o dos semanas.
4. Haga clic en "Validar corrección" en el problema dentro del informe "Indexación de páginas" cuando haya corregido la regla. La documentación de Google indica que la validación suele tardar hasta unas 2 semanas y puede tardar mucho más.

La ayuda de Google sobre cómo solicitar un nuevo rastreo indica que el rastreo puede tardar desde unos días hasta unas semanas, así que cuente con que el recuento baje poco a poco. Las URLs que sigan en el informe después deberían ser las que usted quería bloquear.

Antes de desbloquear una página que ha estado oculta durante meses, mírela como lo hará un rastreador: su código de estado, su metaetiqueta robots y su etiqueta canónica. Una página que nadie podía rastrear puede llevar un noindex olvidado, que la llevaría directamente a «La URL se ha marcado como "noindex"». Nuestro análisis de conflictos de indexabilidad explica cómo interactúan estas señales.

Search Console le dice qué URLs están bloqueadas. Un diagnóstico completo de SEOReport contrasta las páginas que incluye su sitemap con sus reglas de robots.txt y nombra las que les pide a los buscadores que encuentren mientras les dice que no las rastreen. También señala un disallow para todo el sitio y la ausencia de robots.txt. Lee las reglas escritas para todos los rastreadores, así que un grupo exclusivo para Googlebot sigue siendo algo que conviene confirmar en Inspección de URLs.

Preguntas frecuentes

¿Perjudica a mi sitio tener muchas URLs bloqueadas?

No, por sí solo no. Miles de URLs de parámetros o de búsqueda bloqueadas indican que robots.txt está haciendo su trabajo. Cuente las URLs bloqueadas que incluye su sitemap y las páginas bloqueadas que quiere posicionar; son las únicas que le cuestan algo.

¿Qué ocurre si falta mi robots.txt o devuelve un error?

La especificación de Google trata un 404 u otra respuesta 4xx (salvo 429) como si no existiera robots.txt, así que no se bloquea nada. Un error 5xx es distinto: Google deja de rastrear el sitio durante las primeras 12 horas y después usa la última copia válida que tenga durante un máximo de 30 días. Google trata igual los tiempos de espera agotados y los errores de DNS del archivo, así que un robots.txt que no responde a tiempo puede pausar el rastreo de un sitio que no tiene ninguna regla de bloqueo.

¿Debo quitar del sitemap las URLs bloqueadas?

Sí. Un sitemap enumera las URLs que usted quiere indexar, así que no debería contener ninguna URL que robots.txt bloquee. Quite del sitemap las bloqueadas a propósito y desbloquee las accidentales. Nuestra guía de sitemaps XML explica qué más debe contener el archivo.

¿Puedo usar robots.txt para retirar una página de Google?

No. robots.txt controla el rastreo, y Google puede seguir indexando una URL bloqueada a la que enlazan otras páginas. Para mantener una página fuera de la búsqueda, deje que Google la rastree y añada noindex. La guía de robots.txt y acceso de rastreo explica qué herramienta sirve para cada cosa.

¿Afecta a mi sitio principal un robots.txt en un subdominio o en HTTP?

No. Cada combinación de host, protocolo y puerto tiene su propio archivo, y Google no lee los archivos robots.txt colocados en subdirectorios. Un archivo de bloqueo en staging.example.com no puede bloquear www.example.com, pero el robots.txt de su host de recursos o de su CDN sí decide si Google puede descargar los archivos que cargan sus páginas.