Te habrá pasado o lo habrás escuchado de algún colega:

«Google entra en páginas que tenía bloqueadas en el archivo robots.txt de mi web. ¿Es eso cierto? ¿Puede a veces ignorar este archivo?»

En el ámbito del SEO y la optimización web, este es un tema recurrente que genera mucha confusión. Si estás buscando una respuesta rápida a esta pregunta puedo decirte simplemente que «No». No es cierto que Google pueda omitir lo que le dice el archivo robots.txt y visitar contenidos que están ahí definidos como «bloqueados». Debemos tener claro que el robots.txt es más que una directriz para Google, es dogma. Desde que ve que le prohíbes entrar en una URL deja de entrar en ella. No es que lo haga más o menos, deja de entrar de forma absoluta y desde el segundo siguiente al que lee la prohibición.

En este artículo, exploraremos en detalle si Google siempre hace caso al robots.txt y analizaremos todos esos casos en los que parece ignorarlo. A lo largo del texto, te proporcionaremos ejemplos prácticos y consejos útiles para que entiendas cómo funciona realmente este archivo y cómo puedes utilizarlo a tu favor y conseguir que Google siempre te obedezca.

¿Qué es y cómo funciona el robots.txt?

El robots.txt es un archivo de texto simple que se ubica en la raíz de tu sitio web y sirve para dar instrucciones a los rastreadores o «bots» de los motores de búsqueda sobre qué partes de tu sitio pueden o no pueden rastrear. Utiliza directivas como User-agent para especificar a qué bot se dirige la instrucción y Disallow o Allow para indicar las rutas permitidas o prohibidas.

Por ejemplo, para bloquear el acceso de todos los bots a una carpeta específica:

User-agent: *
Disallow: /carpeta-privada/

Es importante entender que el robots.txt no es un mecanismo de seguridad. Aunque impide que los bots respetuosos rastreen ciertas áreas, no evita que otros bots menos estrictos o los usuarios accedan a esas páginas. Por lo tanto, no debes confiar en él para proteger información sensible.

Además, el archivo robots.txt es público. Cualquiera puede acceder a él añadiendo «/robots.txt» al final de tu dominio. Esto implica que podría revelar estructuras internas de tu sitio que prefieres mantener privadas. Por ello, debes ser cauteloso al especificar rutas sensibles en este archivo.

Algunos conceptos previos: ¿Conoces nuestro post sobre las 10 + 1 cosas que deberías saber del robots.txt?

Si deseas profundizar en el tema, te recomendamos leer nuestro post detallado sobre 10 + 1 cosas que deberías saber del robots.txt. En él, exploramos aspectos avanzados y curiosidades que te ayudarán a dominar el uso de este archivo. Algunos de los puntos que abordamos son:

• La importancia de saber ubicar el archivo.
• Los detalles sobre cómo se interpreta y lee el archivo
• Detalles sobre qué pasa cuando bloqueas una URL y a qué otros aspectos del seo afectas al hacerlo.
• Directivas que funcionan y no funcionan.

Herramientas para analizar tus robots.txt

El informe de Robots.txt

Es recomendable utilizar herramientas especializadas para verificar tu robots.txt. Una de las más útiles es el Informe de robots.txt  de Google Search Console. Esta herramienta no solo te permite ver como es tu archivo actualmente , sino que también puedes forzar la lectura del archivo por parte de Googlebot, lo que puede ser crucial cuando realizas cambios importantes.

Además, el probador actúa como un control de versiones, permitiéndote ver historiales de cambios y entender cómo afectan al rastreo e indexación de tu sitio.

Por qué el análisis de logs resulta tan interesante

Aunque menos común y sencillo que la cómoda herramienta que nos da GSC, el análisis de los logs de tu servidor pueder ayudarte a  entender cómo los bots interactúan con tu sitio web. A nivel técnico, los logs registran cada solicitud que se hace al servidor, incluyendo las de Googlebot y otros rastreadores. Esto te permite identificar si están accediendo a áreas que deberían estar bloqueadas por el robots.txt (o más bien validar que no lo hacen).

Al revisar estos logs, también puedes detectar patrones de comportamiento, frecuencia de rastreo y posibles errores que estén ocurriendo, pero ya solo mirando las peticiones que Googlebot hace del robots.txt te aportará la seguridad de saber lo que está viendo Google y cuando lo está revisando (y por tanto con qué contenido).

Revisar los cambios en tu robots.txt cada día: una buena idea para anticiparte a los problemas.

Otra opción es consultar y guardar una copia de tu robots.txt cada día. Esto puede parecer excesivo, pero te ayudará a detectar cambios no autorizados o errores accidentales que puedan ocurrir en tu web. Automatizar este proceso puede ser tan sencillo como configurar un script que guarde el archivo diariamente. Revisar el contenido guardado para ver si difiere de el del día anterior ya es un poco más complicado (pero solo un poco).

Nosotros en IKAUE optamos muchas veces por guardar cada día todas las líneas del Robots.txt, pero es cierto que el verdadero valor está en detectar solo si ha cambiado o no (porque el contenido histórico del propio archivo lo podrás revisar en Google Search Console).

Ya preparados, conociendo cómo funciona este archivo y las herramientas con las que solemos revisarlo, vamos a ver…

Los 4 motivos por los que se dice que Google no obedece al robots.txt siempre

Caso 1. Google entra porque el robots.txt está mal hecho

En la mayoría de los casos, cuando Google entra en URLs que deberían estar bloqueadas, es porque puede hacerlo. Es decir, tu crees que le has prohibido el acceso, pero no es así. No se trata por tanto de un error en su lectura del archivo, sino un error del site a la hora de redactarlo. Esto suele deberse casi siempre a una lista de errores fáciles de controlar en la configuración del robots.txt. Estos serían:

• No comprender que Google siempre lee desde el principio del path: Si defines fragmentos intermedios sin usar comodines, no bloquearás las rutas deseadas. Por ejemplo:

Disallow: /carpeta/privada/

Esta directiva bloqueará /carpeta/privada/ pero no /otro/carpeta/privada/. Si quieres bloquear todas las rutas que contengan «privado», debes usar comodines:

Disallow: /*/carpeta/privada/

• No comenzar las declaraciones por «/»: Sobre esto la norma antiguamente era que Google siempre entiende que la definición del path empieza por «/» y si no lo haces la añade. Pero no confíes en esa regla. Te dejo un post de Mj Cachón con un experimento que viene a decir que las declaraciones que no empiezan por «/» se ignoran. (Leer el post del experimento de Mj Cachón).
• No comprender el orden de priorización de las reglas: No es por orden de lectura sino por la longitud de la definición (número de caracteres). Esto significa que una regla más específica anulará a una más general, sin importar el orden en que aparezcan. Por ejemplo:

User-agent: *
Disallow: /carpeta/
Disallow: /carpeta/especial/archivo.html
Allow: /carpeta/especial/

En este caso, Googlebot podrá acceder a /carpeta/especial/ a pesar de la regla general que bloquea /carpeta/. Sin emargo no podrá acceder al archivo.hml pues está denegado.  Esto se debe a que la ruta permitida es más específica. Es decir, que los paths más largos (más carácteres) pesan más y el orden de escritura nada tienen que ver con la lectura del robots.txt.

• No entender que los grupos de User-agent son únicos y no se mezclan sus definiciones: Si tienes un grupo para User-agent: Googlebot y otro para User-agent: *, las reglas no se combinan. Por lo tanto, si no replicas las directivas necesarias en cada grupo, podrías abrir o cerrar el acceso involuntariamente.

User-agent: *
Disallow: /carpeta1/
Disallow: /carpeta2/

User-agent: Googlebot
Disallow: /archivo-extra.html

• Mucha gente con este ejemplo pensaría que Google no tuede entrar en la /carpeta1/ pero si que puede. Esto es porque los User-agents no se suman, se aplica solo el más específico al bot. Así pues, Googlebot solo tiene prohibido entrar a archivo-extra.html mientras el resto de bots tienen prohibidas esas dos carpetas pero Google no. Este es un error muy repetido y que muchos SEOs desconocen.

La solución a todos estos problemas es siempre la misma: utiliza el probador de robots.txt. Por desgracia Google no nos ofrece el suyo directamente pero hay varios gratuitos. No todos aplican todas las normas correctamente, pero la mayoría si. Otra opción es usar un crawler reconocido en el mercado que aplique bien el robots.txt y ver como actúa (por ejemplo Screaming Frog permite indicarle tu propio archivo robots.txt y ver cómo se realiza el crawl con él).

Caso 2. La indexación no está condicionada al rastreo. No es que Google entre, es que indexa sin entrar.

Es decir, Google, en la mayoría de los casos sigue el mismo proceso: rastrea las páginas de tu negocio y cuando tiene su contenido las indexa. Pero existen otras dos vías por las que Google puede conocer una URL de tu web e indexarla, incluso si no le dejas acceder a ella mediante el robots.txt:

a) La URL estaba previamente indexada

Si una URL ya fue indexada y rastreada en el pasado, Google ya tiene tus datos y sabe cómo tratarla. Cuando bloqueas la URL en el robots.txt, Google deja de rastrearla, pero eso no borra lo que ya sabe de ella. Puede tardar bastante tiempo (a veces más de un mes) en eliminarla de sus resultados, por lo que sigue ofreciéndola incluso estando bloqueada.

En Google Search Console verás estas URLs como «normales» y pasarán a estar «bloqueadas» cuando corresponda. Lo único que puedes hacer es validar en algún probador de robots.txt que estás haciendo el bloqueo correctamente (por ejemplo, comprobando que la URL en cuestión está efectivamente bloqueada).

Si deseas que la URL se desindexe, tienes dos opciones, y ninguna es del todo perfecta:

• Dejarla sin bloquear en el robots.txt y ponerle una metaetiqueta noindex: Esto evitará la indexación pero no el rastreo. Aunque muchas veces si la desindexas y luego (cuando ya esté desindexada) la bloqueas, ya no te dará más problemas.
• Realizar una desindexación manual en Google Search Console: Esto solo soluciona el problema temporalmente (90 días), y luego podría volver a indexarse. Pero al menos te saca la URL de encima rápidamente.

Personalmente, prefiero no hacer nada, si actuaas sobre el robots.txt es por temas de rastreo no de indexación y salvo que la URL sea problemática y no queramos que nadie la vea, no importará tanto si se indexa o no. En caso contrario, si necesitas que desaparezca del índice cuanto antes, optaría por desindexarla manualmente y luego monitorizar su estado en 90 días.

b) La URL tiene enlaces externos, y Google los ha visto

Muchas veces se cae en la trampa de pensar que Google necesita si o si leer el HTML de una URL para indexarla. Esto no es así.. Cuando Google detecta varios enlaces hacia una web que está bloqueada por robots.txt, se produce un efecto curioso: no puede rastrearla pero sí puede indexarla sin contenido. Está claro que sin título, H1, contenido, etc., esa URL nunca posicionará demasiado bien, pero eso no evita que para búsquedas muy concretas o de marca Google pueda ofrecerla como resultado.

Cuando esto sucede, tienes pistas para detectarlo:

• En Google Search Console, aparecerán en el informe de páginas como advertencia: «bloqueada pero indexada».
• Al realizar búsquedas sobre esta URL leerás en la descripción del snippet de Google que no se muestra descripción debido al bloqueo del Robots.txt.

En estos casos, muchas veces se trata solo de esperar y Google terminará eliminándo destas URLs del índice por no verles ningún valor. En los menos, sobretodo cuando sean URLs muy importantes tipo marca o página principal; será casi imposible hacerlas desaparecer sin un noindex.

Caso 3. La ceguera temporal de Googlebot sobre el robots.txt

En IKAUE llamamos «ceguera de Googlebot» al tiempo que puede pasar Google sin saber que hemos hecho cambios en nuestra web. Es decir, al tiempo que transcurre desde que hacemos un cambio hasta que Googlebot pasa por la URL que ha cambiado y puede leerlo. Este tiempo es distinto para cada URL y en URLs muy lejanas puede ser enorme, pero en el archivo robots.txt se acorta mucho.

Google, cuando pide una URL de nuestra web, siempre necesita saber si tiene permiso para visitarla, pero no siempre pide el robots.txt para saberlo. En su lugar, «cachea» (se guarda en memoria) el contenido del robot.txt durante 24 horas para no tener que pedírselo a tu web una y otra vez.

Es decir, si hace 10 horas que Googlebot leyó tu robots.txt, aunque tú lo cambies ahora mismo, hasta al cabo de 14 horas no volverá a pedirlo, no será consciente de que ha cambiado y en consencuencia, no le hará caso. Ese es «el tiempo de ceguera del robots.txt».

Esto significa que podrías bloquear ciertas URLs en tu robots.txt y que Google siguiese visitándolas unas horas mientras no sabe que ese cambio se realizó. Cuando eso pasa, no es que Google no haga caso al robots.txt, sino que no lo ha leído aún. Sin embargo, en momentos de grandes cambios de una web, como puede ser una migración o nueva versión, esto puede hacer mucho daño dejando a Google entrar durante 24 horas a URLs que no quieres que lea. Este es el origen de la mayoría de «expedientes X» de SEOs que aseguran que Google entró en URLs que tenía prohibidas y debes vigilarlo de cerca.

Para solucionar esto, debemos volver una vez más a la herramienta de informe del robots.txt de GSC, donde podemos pedirle cuando queramos que vuelva a leer el robots.txt. Al hacer esto, le estaremos obligando a leerlo y darse cuenta de que ha cambiado. Así que un buen protocolo SEO a seguir es lanzar esta funcionalidad sí o sí ante cualquier cambio de la web y de este archivo.

Puedes consultar nuestro video en YouTube sobre la ceguera del robots.txt y Googlebot para obtener más detalles.

Caso 4. Que el servidor falle cuando Google le pida el robots.txt

Esto es algo que no controlamos pero que puede destrozar nuestras estrategias de indexación. ¿Qué pasa cuando Googlebot pide el robots.txt y el servidor falla? Pues nada bueno.

• Cuando da un código 200: Se obedece al contenido del robots.txt siempre.
  
  
• Cuando da un código 30x: Se visita la URL de destino y se interpreta como si fuese la propia. Esto puede ser bueno o malo, dependiendo de si el contenido es el adecuado.
  
  
• Cuando da un código 40x: Se interpreta como que el robots.txt estaba vacío y que Google puede entrar donde quiera. Este es un error peligroso, pues si te sucede todo lo que tenías prohibido en tu robots.txt quedará invalidado y Google empezará a entrar en todas tus URLs.
  
  
• Cuando da un código 429, 500 o 503: Googlebot entiende que puede estar añadiendo más carga a tu web, la cual ya está saturada, y para de rastrear para hacer más daño a tu servidor. A partir de entonces, verás que Googlebot solo accede al robots.txt y a ninguna otra URL tuya hasta que este deje de dar error. Así que dar estos errores te permite parar a Google, pero esto es por un tiempo limitado; pasado ese tiempo (24 horas o lo que estime oportuno), sigue rastreando como si fuese un 404 (vía libre, que decíamos que era lo más peligroso que podía pasar).

• Documentación de Google Sobre cómo se interpretan estos estados.

Como ves, que tu servidor dé errores descontrolados sobre el robots.txt es muy peligroso. Por eso es buena idea hacer un control periódico del Crawl Stats de Google Search Console o de los logs del servidor. Sobre todo si ves entradas en URLs en las que Google no debería entrar, porque es probable que aquí encuentres la explicación a lo que sucede. 

En IKAUE hemos tenido varios casos de este tipo:

• Migraciones en las que al hacer un 301 sobre el site migrado hacia el nuevo empezamos a ver como Google accede a URLs que nunca habia visitado en el antiguo (pues se le aplica el robots.txt del nuevo)
  
  
• Servidores que por un fallo de programación dan 404 algunas veces sobre el robots.txt y vemos como Google algunos días entra por muchísimas URLs bloqueadas.
  
  
• Sistemas de seguridad que entienden que Googlebot es un bot con malas intenciones y empiezan a darle 410 en algunas URLs. Cuando esto pasa por desgracia a veces le dan 410 en el robots.txt y empieza a entrar por todos lados.
  
  
• Servidores que sistemáticamente se caen, dando a Google errores 500 o 503. Estos dan problemas ya de por si, pero además vemos como de golpe pueden provocar perdidas de crawlbudget muy importantes. Además de, en casos prolongados, también permitir el acceso a muchas de las URLs bloqueadas. 
  
  

Quédate con esto: Siempre que Google entra donde no debería es porque ha encontrado una situación que le permite hacerlo. Que esta situación sea más o menos rebuscada, es otro tema.

Conclusión

En definitiva, Google siempre obedece al robots.txt, siempre y sin excepción. Los casos en los que parece no hacerlo se pueden explicar con algunos de los escenarios que hemos descrito. Muchas veces, estas «desobediencias» son producto del desconocimiento del SEO que asegura que Google no le hizo caso. Puede ser que no sepa bien como funciona Google, que le falten datos o que alguien le haya asegurado que nada había cambiado cuando esto no es verdad.

Es recomendable que revises tu archivo robots.txt, utilices herramientas como el Informe de Robots.txt de Google y realices análisis de logs para asegurarte de que todo está funcionando como debería. Un aspecto fundamental es entender cómo funciona el robots.txt y cómo los bots interactúan con él. Así, podrás evitar sorpresas y garantizar que tu estrategia SEO se ejecuta correctamente.

Ten en cuenta que la comunicación y la monitorización constante son clave. Nosotros destinamos siempre muchos recursos a asegurarnos de que tenemos los sites de nuestros clientes bajo control.