¿Qué es el robots.txt exactamente?

Robots.txt es un archivo destinado a indicar a los buscadores qué URLs tiene derecho a visitar y de cuáles debería abstenerse. El funcionamiento es simple: antes de visitar una URL del site un robot debería mirar en este archivo para determinar si tiene que ir ahí a recoger información, o bien, si por el contrario, el dueño del site prefiere que no entre. En definitiva son solo indicaciones que cualquier robot puede saltarse si quiere, pero a las que el robot de Google hace bastante caso (que tampoco al 100%).

El archivo robots.txt es uno de esos temas técnicos del que todo SEO debe saber lo suficiente como para manipularlo con éxito. Por ello, el mismo Google en su soporte nos indica cómo podemos crear el nuestro:

🔗 Información sobre los archivos Robots.txt.

Se nos da información muy directa y fácil de asimilar. La redacción de estos archivos es muy sencilla aunque cualquier fallo, por mínimo que sea, podría provocar que las arañas no entrasen en las páginas que nosotros deseamos. En el mejor de los casos, eso provocará que sigan visitando URLs en las que no querríamos que perdiesen el tiempo. En el peor, será todo lo contrario: no indexará contenidos que en realidad sí que queremos que aparezcan en el buscador.

El formato general del robots.txt

Primero:

Empezamos declarando en una línea el user-agent (nombre del sistema que está navegando o rastreando el site) al que queremos afectar y tras ésta línea indicaremos los accesos permitidos y prohibidos.

Muchas veces declararemos un acceso a todos (user-agent:*) y en ocasiones nos referiremos a algún robot o crawler en particular (user-agent: googlebot).

user-agent: *
---- Reglas para todos los robots ----

user-agent: googlebot
---- Reglas que solo aplican a Google----

user-agent: bingbot
---- Reglas que solo aplican Bing----

Segundo:

Usamos directivas «Allow: {expresion}» y «Disallow: {expresion}» para indicar si damos acceso o lo eliminamos. Por defecto podríamos decir que un robot tiene acceso a todas las URLs del site («Allow:*») pero aunque esto ya es así desde el principio, muchos deciden dejarlo declarado de forma explicita y continuar prohibiendo a partir de ahí. Por eso, aun siendo innecesario, no debe parecernos raro ver un robots que empieza por «Allow: *».

Por último:

Podemos indicar nuestro sitemap.xml si lo deseamos (sitemap: sitemap.xml). Esto para Google carece de importancia si gestionamos adecuadamente Google Search Console; no obstante, puede ayudar a otros robots a leerlo, así que declararlo no va a hacernos mal.

sitemap: /miarchivositemap.xml

Una cosa curiosa de este archivo sitemap es que puede estar alojado incluso en otros dominios distintos al nuestro. Esto puede ser útil si, por ejemplo, necesitamos hacer subidas con cambios del archivo cada cierto tiempo y, en la web que trabajamos, no nos permiten ir actualizándolo de forma tan ágil.

Un ejemplo que cubra todo lo que acabamos de mencionar sería el siguiente:

user-agent: *
allow: *

user-agent: googlebot
disallow: /no-rastrear-esto/
allow: /no-rastrear-esto/pero-esto-si/
disallow: /*/no-rastrear-esto/

sitemap: /sitemap.xml  

Como ves el archivo robots.txt es un aspecto fundamental del SEO que, lamentablemente, a menudo no recibe la atención adecuada. El problema radica en que, aunque la documentación de Google proporciona información valiosa, no abarca todas las particularidades sobre cómo se interpretará este archivo. Si nos limitamos únicamente a esa información, corremos el riesgo de cometer errores que podrían tener consecuencias negativas en el futuro.

Así pues, os dejo 10+1 conceptos sobre estos archivos que hay que tener en cuenta y asimilar. Desde lo más básico, hasta consejos que sólo en webs complejas o con mucho detalle de optimización del Crawl Budget podremos aplicar.

¿Qué conceptos debemos conocer de robots.txt?

1. Donde colocas tu archivo es más importante de lo que crees.

Sigue existiendo confusión con este punto. El archivo robots.txt siempre se buscaba en la ruta «/robots.txt» del dominio. El robots.txt afecta al host donde está alojado pero sólo a este host exacto. Esto supone que un subdominio no hará caso al robots.txt de su host superior y que http y https usan archivos distintos.

¿Por qué entonces vemos sitios donde una configuración bloquea a otra? Lo veremos más adelante pero es sobre todo por temas de hosts redirigidos totalmente con un 301. Es decir, cuando vemos que el robots.txt de www.midominio.com afecta también a midominio.com normalmente es porque existe una redirección de «midominio.com/robots.txt» a «www.dominio.com/robots.txt» y, por lo tanto, se lee el mismo archivo para ambos hosts. Lo mismo pasa con http y https, si uno esta redirigido al otro se aplica el mismo archivo a ambos.

Pero en definitiva vendría a ser esto:

• midominio.com/robots.txt >> NO afecta a www.midominio.com y a blog.midominio.com
• dev.midominio/robots.txt >> Afecta a dev.midominio.com pero no a blog.dev.midominio.com
• www.midominio/robots.txt >> Afecta a www.midominio.com pero no a blog.www.midominio.com y solo afectará a midominio.com si hay un redirect de midominio.com/robots.txt a www.midominio.com/robots.txt

Además, hay que eliminar la creencia de que el robots.txt actúa como muchos piensan sobre carpetas concretas del site. Esto no es cierto: Google sólo lo lee si está en la raíz del documento:

«midominio.com/blog/robots.txt» no sirve para nada. Google no va a intentar leerlo ni tiene por qué hacerle caso. Algunos CMS se empeñan en añadirlo pero esto no forma parte de la definición oficial del archivo robots.txt.

2. El tipo y tamaño de archivo puede afectar a que no se lea tu archivo robots.txt

Lo ideal es que un robots.txt esté codificado en UTF-8 para no tener problemas de lectura. Pero lo cierto es que los archivos de texto pueden tener varias codificaciones. Por ejemplo, si creas el archivo desde tu bloc de notas de Windows es probable que su formato sea otro. Es recomendable usar editores de texto plano más profesionales (una opción sencilla y potente es notepad++) donde, entre otras cosas, se os deje escoger la codificación del archivo.

Aún así, Google nos dice que puede leer otras codificaciones. Pero lo que pasa en estos casos no es tanto que él pueda o no, sino que al generarlo se escriba en una codificación y el servidor lo devuelva en otra. Eso puede provocar los típicos caracteres extraños, que terminan en que el archivo no funcione o no se lea de forma adecuada.

Aún dentro de los archivos UTF-8 hay una cosa en estos archivos que se llama BOM (marca de orden de bytes del archivo, que ocupa la primera línea) . Lo ideal es que los ficheros simples no tengan BOM, pero Google es capaz de leer el robots.txt con un BOM inicial (si bien sólo uno y sólo al principio), así que si vuestro archivo tiene BOM no pasa nada.

Otra limitación la tenemos en el tamaño. Google nos limita a 500MB y si lo pasamos no leerá el archivo. Así que tenemos que economizar estos archivos, ya no sólo por no acercarnos a los 500MB, sino porque son archivos muy consultados por los robots y a mayor tamaño, más desgaste de proceso y red en el servidor.

3. Un disallow sólo prohíbe leer el contenido no indexar (y de primeras no está focalizado a desindexar).

⚠️ Un aviso: no es lo mismo un <meta name=»robots» content=»noindex» /> que un disallow en el robots. Significan cosas totalmente distintas.

• Disallow prohíbe a las arañas leer el HTML de la página. Pero puede leer la URL, por lo que ésta puede aparecer en búsquedas con información a partir de otras páginas y links de Internet. Además, con un disallow no eliminamos lo que ya sabía Google de esas páginas y no es extraño que tras añadir una URL como disallow veamos como el resultado se mantiene un tiempo en el buscador. Definitivamente no es una forma rápida de desindexar, sino que va más encaminado a temas de rastreo y a acciones a medio o largo plazo.
• Por el contrario un noindex en el meta-robots sí deja a la araña rastrear el HTML pero prohíbe que su resultado salga en Google. Es el efecto contrario: las arañas siguen perdiendo el tiempo con esa página pero los resultados desaparecen antes del buscador.

Todo esto por supuesto con matices… A la larga un Disallow provocará la desindexación si no hay links externos hacia esa página y por el contrario un meta-robots a noindex terminará provocando menor rastreo de esa URL que total Google no puede trabajar.

4. Si el contenido no se lee, como es lógico, las directivas del HTML se ignoran.

No tiene sentido un disallow+noindex o un disallow+canonical o disallow+rel-next/prev o un disallow+loquesea-en-el-html. Google no va a contemplar este HTML porque le hemos prohibido acceder a él, así que ahórrate su etiquetado.

Lo mismo pasa (aunque en menor medida) con las redirecciones. Si yo creo una redirección 301 de una URL vieja a una nueva y al mismo tiempo bloqueo la vieja por robots.txt, Google no debería enterarse de que he creado un 301 (porque no debería acceder a la URL con 301), así que el traspaso de autoridad no se realizará de forma eficiente. En la práctica, a veces sí se da cuenta de la redirección, pero por lo general se pierde mucha autoridad al hacer estas cosas.

Otro caso que merece atención es el uso de la directiva meta-robots=noindex en combinación con otras directivas. En teoría, nada impide la posibilidad de utilizar, por ejemplo, tanto un noindex como un canonical al mismo tiempo. Sin embargo, la interpretación de esta combinación es sumamente ambigua. Ante situaciones ambiguas como esta, Google tiende a ignorar todas las señales del HTML por precaución, ya que no puede confiar plenamente en ellas. Por lo tanto, aunque en teoría estas combinaciones sean posibles, no recomendaría su uso, excepto en el caso de «noindex,follow». Incluso esta combinación debe utilizarse con cautela, ya que el noindex limita la indexación de la página, lo que hace que el uso de «follow» pueda resultar contradictorio en ciertos contextos.

5. La redacción de las URLs es simple y muy concreta, pero sus reglas de lectura no son tan intuitivas como podría parecer.

La vamos a repasar porque llegados al detalle tiene miga y la gente comete muchos fallos. Cada línea debe empezar con una orden (allow/disallow) y cada orden hay que escribirla con mucho cuidado.

• Si las URLs no comienzan con un slash «/», Google lo añadirá. Es decir:
  • «disallow: blog» Google lo entenderá como «disallow: /blog» y
  • «disallow: -producto» como «disallow: /-producto».
• La regla que aplica Google no es un «contiene», nuestra declaración debe empezar por el principio de la URL. Normas tipo «disallow: .doc» no funcionan porque falta el principio de la URL. De hecho, entenderá que la URL a prohibir es aquella URL que empiece por «/.doc». Esto tiene varias implicaciones:
  • La solución cuando lo que queremos es definir partes del final o fragmentos de las URLs es redactarlas como sigue: «/*-producto» o «/*.doc» indicando que empieza por cualquier cosa y luego sí contiene ese rastro que queremos detectar.
  • Si pensamos en declarar carpetas de la web, todo se vuelve más fácil pues Google entenderá que se hace referencia a esa dirección y a todos los archivos internos que contengan esas carpetas. Es decir, al indicar «/mi-carpeta» como disallow, también prohíbo el acceso a «/mi-carpeta/mi-archivo».
• Las directrices allow/disallow no son sensibles a mayúsculas y minúsculas, pero las URLs que se definen en ellas sí lo son. Es decir, yo puedo escribir «disallow:» o «Disallow:» o «DISALLOW:» y es lo mismo, pero «/mi-pagina» y «/MI-PAGINA» no son la misma URL.
• Se nos permite usar los comodines * y $ para completar las URLs:
  • «*» es para cualquier conjunto de caracteres (el equivalente en expresiones regulares a «.*»).
    • «disallow: /blog*» bloqueará la carpeta /blog/ pero también cualquier archivo o carpeta cuya URL empiece por «/blog», por ejemplo «/blogueria.html».
    • «disallow: /*.doc» sí que funciona pues contemplamos cualquier carácter al principio y esperamos que acabe por .doc
  • «$» nos permite forzar que ese sea el final de la URL, sin permitir nada tras ella:
    • «disallow: /categoria/$» sólo bloqueará el acceso a la página de categoría «/categoria/» pero no a archivos internos como «/categorias/post».
    • «disallow: /blog$» solo bloqueará el archivo «/blog» pero no la carpeta «/blog/».
  • Se nos permite sobrescribir reglas, por ejemplo, para permitir el rastreo de una parte de una regla ya prohibida o prohibirlo luego de nuevo para una regla que lo permitía.

    disallow: /blog/
    allow: /blog/$
    allow: /blog/categoria-1

• • Por último, las reglas no se aplican por orden de lectura sino por lo específicas que son.
    La norma es que las reglas más largas pesan más que las más cortas.
    Así:

    disallow: /blog-corporativo/
    allow: /*.html
    

    No conseguirá que se rastreen los archivos «.html» dentro de /blog-corporativo/ dado que es más larga la expresión de blog-corporativo y por lo tanto pesa más.

    Pero esta otra composición si lo hará:

    disallow: /blog-corporativo/
    allow: /blog-corporativo/*.html
    

    Porque ahora «/blog-corporativo/*.html» es más largo que «/blog-corporativo/» … así de simple, pero también así de ilógico.

6. Las alternativas para evitar rastreo/indexación a robots.txt o meta-robots no son igual de potentes.

Y esto es así… No hay nada más potente y duradero que una sentencia de robots.txt…

• En Google Search Console puedes usar la herramienta de borrar contenido y estas URLs se borrarán. Pero Google aproximadamente a los 90 días olvidará que le habías pedido borrar la URL y, si por lo que sea, vuelve a encontrarla, la volverá a indexar. Por lo que sirve para eliminar errores puntuales, pero no para eliminar URLs que van a seguir ahí.
  • En Google Search Console puedes usar la herramienta de parámetros de URL para indicar si un contenido aporta cambios en la URL o no, pero esto no es mandatario. Es sólo una ayuda como puede ser el sitemaps y si Google cree que los parámetros indicados son interesantes (cambian el contenido del HTML), la usará igual. Básicamente sólo es útil para indicar que no indexe URLs de campañas y ayudar un poco con los listados. Lo que seguro que no evitará esta función es que los robots entren en dicha URL.

7. Todas las directivas no contempladas en la definición del robots se ignoran.

Por ejemplo, el famoso «Crawl-delay» se ignora. En teoría debería indicar tiempo entre peticiones de robots pero no le hace caso así que podemos olvidarnos de esta sentencia al menos para Google (otros rastreadores sí que le hacen caso).

Todas las directivas inventadas por terceros también se pasan por alto.

Y por último, las líneas que empiezan por «#» también se ignoran al entenderse como comentarios. Sin embargo, sí que cuentan en el tamaño de archivo máximo, así que es mejor no pasarse con su uso. Una recomendación para comentarios: cuando trabajamos con varios proyectos o muchos sites es mejor incluir notas de la versión subida como comentario:

#robots.txt for www.midominio.com DD-MM-YYYY

user-agent: ...

8. ¿Qué pasa cuando Google no puede acceder o encuentra cosas raras al acceder a tu archivo robots?

Ya hemos dicho que el archivo robots.txt siempre se busca en la ruta «/robots.txt» de tu dominio. Y que si no lo encuentra, podrá ir a buscarlo a un nivel superior de dominio (si existe). Por ejemplo, si no lo encuentra en www.dominio.com/robots.txt irá a buscarlo a dominio.com/robots.txt

Pero veamos ahora qué pasa cuando lo solicita. Un servidor lo que hará cuando reciba la petición del archivo robots.txt es devolver un código de respuesta, diciéndole a las arañas si lo está encontrando o no.

• Código «200». Significa que el archivo sí existe. Entonces lo leerá y aplicará sus normas. Si está vacío o googlebot no tiene directrices «disallow» entenderá que tiene acceso a todo y entrará hasta la cocina de la web.
• Códigos «4xx» (404, 401, 403, etc.). Significa que el archivo no existe o no está abierto al público. En ese caso Google lo entenderá como un archivo vacío y dará acceso a todo como si no contuviese disallows.
• Código «301». Significa «contenido movido permanentemente» y viene acompañado de una URL donde está el nuevo contenido. Google interpreta a todos los efectos que el contenido de esta URL a la que redirige robots.txt es el propio robots.txt, incluso si existe un cambio de carpeta, la URL está en otro dominio o si la URL no tiene el nombre «robots.txt».Conocer este detalle puede ser útil para gestionar robots.txt programados en algunos sistemas. Podemos tratar la URL de /robots.txt sólo como una redirección a donde realmente gestionamos nuestro archivo robots.txt.

  Sin embargo, también puede suponer un problema en migraciones mal realizadas de un dominio a otro o de http a https. En estos casos podemos encontrarnos con que al migrar un site devolvemos un 301 hacia el nuevo site con el robots.txt, con lo que estaríamos aplicando el robots.txt nuevo al viejo dominio dejando de bloquear las URLs viejas y pudiendo provocar una cascada de detección de errores y pérdida de tiempos de rastreo. Generalmente, la recomendación debería ser que todos los sites tengan su propio /robots.txt y que nunca se redirija pero esto en la mayor parte de los casos no se hace así.

• Otros códigos (sobre todo 503). Si hay un error al servir el archivo, Google entiende que el dominio está caído y para no molestar para el rastreo del site, sólo consultará el archivo 503 hasta que su error cambie. Parar el rastreo no supone desindexar, salvo que mantengamos así el servidor tanto tiempo que empiecen a perder fuerza los enlaces y contenidos de la página, por lo general mejor no hacerlo más de unas horas. El cómo actúa Google si este error persiste en el tiempo no lo sabemos exactamente, pero por el motivo que sea suele llevar a pérdidas de autoridad y a que se intente reindexar la web. Por este motivo, cuando hay errores técnicos en una web, y se están solucionando en ese mismo día, es preferible obligar al archivo robots.txt a que devuelva error 503 y así parar la indexación completa del site hasta que se arregle el problema. Esto es mucho mejor que bloquear el rastreo, ya que lo segundo tiene implicaciones más severas y un simple 503 es totalmente temporal.
• Sin respuesta. Otra posibilidad es que el servidor no devuelva nada o tarde demasiado tiempo en hacerlo (por problemas de configuración o porque la máquina esté demasiado saturada). En esos casos Google tira de la caché que tiene de este archivo durante un tiempo. Es decir, interpreta el último archivo robots.txt al que pudo acceder y trabaja como si fuese éste el que está subido.

9. El bloqueo de archivos JS y CSS puede ocasionar problemas e incluso está mal visto por el buscador.

Google recomienda no bloquear archivos CSS y JS. Antiguamente eran archivos que se solían bloquear porque no le servían a las arañas para nada. Pero ahora los robots de Google son capaces de interpretar el HTML y así situar los contenidos en su contexto: saben si un texto es grande o pequeño; el color de fondo; qué sitio ocupan en el diseño; o lo visibles que son los contenidos para los usuarios… Así que Google nos pide que le dejemos acceder a esto y así valorar la web al completo.

Si no les damos acceso a estos archivos es cuando empieza a enviarnos notificaciones y en la práctica la autoridad/calidad que percibe de nuestra web disminuye.

Esto no significa que no podamos nunca bloquearle un archivo JS (todos sabemos para qué 😈) pero sí que hay que evitar este bloqueo a nivel general.

10. Google entra en contenidos 400 pero no si se le bloquea.

Los contenidos 400 (páginas 404 – no encontradas, o 401 que suelen estar bajo login, etc…) si que son accedidos por las arañas. Google lo intenta y se encuentra al visitar las páginas con que estas no responden y por lo tanto no indexan.

Al final con esta situación lo que provocamos es perder tiempo de rastreo en URLs que nunca se van a indexar así que suele ser preferible bloquearles el acceso directamente. Pensemos en cualquier URL, incluso las de destino de los formularios de Google y una vez las tengamos presentes:

1. Evitemos que el HTML muestre links hacia ellas.
2. Independientemente de si este acceso existe o no, marquémoslas con disallow en el robots.

BONUS. Es posible enviar un noindex desde tu servidor creando una especie de robots.txt pero para noindex y nofollow.

No cuento este punto entre los 10 conceptos pues en realidad habla más de directivas de indexación que de robots.txt y es más una posibilidad que no es fácil de implementar para todos (y en su versión más sencilla no está recomendado y no sabemos realmente si funciona).

Hablamos de encontrar alguna forma no para prohibir el rastreo, sino para prohibir la indexación: el equivalente a la meta-etiqueta de robots marcada a «noindex» que comentábamos antes. Sobre este tema podréis leer de todo, lo más común es que os encontréis artículos que os hablen de la directiva «noindex:» dentro del archivo robots.txt

Esta regla viene a decirnos que nosotros podemos crear sentencias noindex en el archivo robots con la misma nomenclatura.

Por ejemplo:

Allow: /categoria-1/
Noindex: /categoria-1/*-pag-*$

Vendría a decirle al robot que puede navegar por la categoría-1 y rastrearla pero que los contenidos de las paginaciones de esta categoría no deben aparecer en el índice de búsqueda.

Sería genial que nos dejasen hacer esto, ya que como comentaba antes bloquear una URL no implica desindexarla, y así tendríamos un control total sobre todo. Sin embargo, y a pesar de que podréis ver como muchos SEOs lo mencionan e incluso Deepcrawl lo llegó a medir, Google no dijo en su día que no recomienda usarla y mientras lo sigan diciendo, yo creo que carece de sentido hacerlo. Así que no disfrutamos de esta posibilidad…

En su lugar, tenemos otra forma más complicada pero efectiva a nivel de servidor que podemos usar. Google tiene documentado el uso de directivas robots (index/noindex,follow/nofollow) con el uso de «x-robots-tag» en las cabeceras. Según esta definición tan sólo tenemos que enviar una cabecera del tipo «x-robots-tag» con el mismo valor que pondríamos a la meta-etiqueta robots para para pasarlo desde servidor y no desde HTML.

A parte del propio sistema, esto nos abre la puerta a crear un archivo que gestione estas cabeceras en nuestro servidor. Podemos hacer esto con el lenguaje de programación de nuestro CMS (PHP, Java, .Net, etc.) o directamente en la configuración del servidor. En ella, gracias a los archivos .htaccess y .htconfig, podemos declarar el envió de cabeceras en un único archivo que defina qué puede y qué no puede indexar el robot.

Ejemplo para marcar un «noindex,follow» en paginaciones de tu web a través del archivo .htconfig:

  <locationmatch "="" page-[0-9]+$"="">
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

Marcar no indexar incluir caché o descripción de los archivos PDF en el .htaccess…

<filesmatch "\.pdf$"="">
Header set X-Robots-Tag "index, noarchive, nosnippet"

O no indexar paginaciones a través del módulo de modRewrite con el que gestionamos nuestras URLs amigables y redirecciones:

RewriteCond %{THE_REQUEST} "^(GET|POST) .*page/[0-9]+ HTTP"
RewriteRule .* - [ENV=NOINDEXFOLLOW:true]
Header set X-Robots-Tag "noindex,follow" env=NOINDEXFOLLOW

Pero no quiero extenderme demasiado con este sistema, si quieres leer más sobre cómo ponerlo en práctica te invito a que visites otro post donde detallo otras 10 cosas que deberías saber sobre meta-robots. En la última de ellas se explica al detalle este sistema.

Conclusión

No se si os habrá pasado como a mí, a medida que he ido descubriendo con los años todo lo que os he expuesto en este post, pero la verdad es que como todo en el SEO, te das cuenta de que nunca sabes lo suficiente de todo. Me pareció interesante recopilar todo esto porque sigo viendo con el tiempo que los problemas que existen en muchos sites debido a no entender bien los archivos robots.txt siguen ahí año tras año y nadie habla de ellos demasiado.

Así que espero haber ayudado a algunos y a otros haberles descubierto algún detalle que desconociesen.