¡Oh! El robots.txt, ese pequeño archivo, un simple bloc de notas que nos puede salvar el culo en más de una ocasión. ¿Qué tienes url que no quieres indexar? Tranquilo, un buen disallow puede ser suficiente… o no. Y es que las instrucciones que damos a los robots de indexación de los buscadores en este archivo no dejan de ser sugerencias, sugerencias contundentes, pero sugerencias.

Lo primero que hay que tener claro es que los robots, y sobre todo Google, hacen lo que les da la gana y que tú solo puedes darle recomendaciones de lo que debe y no debe hacer. El robots.txt, al igual que puede ser un sitemaps, nos sirve para guiar a Google y otros buscadores, pero eso no evitará que se suelten de tu mano y vayan dónde ellos quieran.

En este artículo, que no va a ser demasiado largo, me gustaría compartiros mi forma de especificar un robots.txt decente en un caso genérico. Si usáis CMS como WordPress, Prestashop o Magento seguramente sepáis que hay determinados directorios a los que no queremos que acceda el buscador, pero cuando nos enfrentamos a un desarrollo personalizado el asunto cambia un poco.

¿Qué es el robots.txt?

Según la Wikipedia, hablamos del “estándar de exclusión de robots, también conocido como el protocolo de la exclusión de robots o protocolo de robots.txt”, lo cual “es un método para evitar que ciertos bots que analizan los sitios Web u otros robots que investigan todo o una parte del acceso de un sitio Web, público o privado, agreguen información innecesaria a los resultados de búsqueda”. Y es que “los robots son de uso frecuente por los motores de búsqueda para categorizar archivos de los sitios Webs, o por los webmasters para corregir o filtrar el código fuente”.

¿Más claro? Al final, como ya he dicho, se trata de un archivo que nos permite especificar a los robots de los buscadores qué deben y qué no deben revisar. Podemos decir que se trata de establecer puertas, unas las cerraremos con llave y otras las abriremos de par en par, no sin correr el riesgo de que el robot fuerce o cierre la puerta si le apetece (aunque le costará más).

¿Cómo debe ser el archivo robots.txt?

Estamos hablando de un sencillo bloc de notas, con unas condiciones estándar. Esto quiere decir que en un sistema Windows podremos crearlo, darle el contenido y ya será válido, pero si queremos ser un poco más técnicos, hablaremos de que debe ser un archivo con formato UTF-8 y, a poder ser, sin BOM, ya que lo va a ignorar si lo hay.

¿Quién lee el robots.txt?

Quien tú quieras, así de sencillo. Es habitual especificar un uso genérico del robots.txt, diciéndole a los robots, independientemente de dónde vengan, unas instrucciones generales. Sin embargo, también podemos establecer diferentes fórmulas para diferentes robots.

Todo ello lo hacemos gracias a la instrucción User-agent:, que nos permite especificar a quién nos dirigimos. Podemos decirle a todos que hagan algo mediante User-agent: *, o bien especificar un robot concreto que queremos que actúe de otra manera, por ejemplo con User-agent: Googlebot, con lo que únicamente ese robot podrá hacer caso a las fórmulas que especifiquemos a continuación.

En resumen, especificamos a quién nos dirigimos con las instrucciones:

  • A cualquier robot: User-agent: *
  • A un robot específico: User-agent: nombrerobot

¿Qué instrucciones puedo dar?

Lo primero que debemos pensar es que vamos a hablarle a un robot o a muchos, por lo que la forma más sencilla es darle cuantas menos opciones posibles. En este caso, nos regimos por esto y únicamente podremos darle dos, algo así como “adelante, puedes pasar” y “quieto, aquí no entras”. Para ello nos haremos servir de las fórmulas Allow: y Disallow: respectivamente.

¿Y dónde le dejamos o no entrar al robot? Esta pregunta se responde justo después de permitirle o no pasar. Una instrucción perfectamente válida sería Allow: /empresa/, lo que permitiría al robot pasar al directorio /empresa/ y a todas las url que se generen a continuación del mismo. Pero, ¿y si solo queremos que acceda a ese directorio? Utilizaremos un stop, que se traduce en el símbolo $. Si añadimos Allow: /empresa/$ le estaremos diciendo al robot que no pase de la última barra.

También es posible que no queramos que pase a una carpeta concreta, como puede ser nuestro panel de administración. En este caso sería tan sencillo como decirle Disallow: /admin/, lo que le impediría entrar a esa carpeta y a todas las url generadas a continuación.

En resumen:

  • Quiero que leas/indexes: Allow: /directorio/
  • No quiero que leas/indexes: Disallow: /directorio/
  • No quiero que pases de donde te he indicado: usamos $ al final de la orden.

¿Tengo que indicar las url una por una?

¡Pues claro que no! Dónde vamos a parar. Para evitarnos un exceso de instrucciones utilizamos nuestro tan recurrido asterisco, que nos sirve como comodín. Si le decimos al robot una instrucción tipo Allow: */carpeta/*.js$, le estaremos indicando que tiene permiso para leer todos los archivos con extensión de Javascript ubicados en /carpeta/ independientemente de cuál sea su ruta anterior y el nombre del archivo. ¿Entiendes cómo usar el asterisco?

Vamos con otro ejemplo: Allow: /*.css$ hará que los robots lean todos los archivos de estilo que haya en nuestra estructura de archivos web independientemente de dónde se encuentre y de cómo se llame.

¿Cómo aplico todo esto a un robots.txt de verdad?

Bien, aquí lo importante. En primer lugar indicaremos a quién nos dirigimos, posteriormente cerraremos todas las puertas a los robots y después iremos abriendo las puertas una a una según nos interese. ¿Entiendes?

Un ejemplo claro:

Si queremos ser todavía más concienzudos, podemos indicarle a los robots la url de nuestro sitemaps para que, ya que se pasan por aquí, también lo hagan por allí. Esto lo haremos al final de todas las órdenes anteriores.

Además, cuando trabajamos con una web en producción, lo más común si no queremos que se indexe es que la especifiquemos de la siguiente manera:

¿Y ya está? ¿Me puedo olvidar del robots.txt?

¡NO! Insensato. Sobre todo durante las primeras semanas (y días) tras el lanzamiento de una web cuya estructura de directorios y navegación no tenemos interiorizada, y la subida del archivo de sitemap, es necesario echar un vistazo a la Google Search Console a menudo. Porque has creado la propiedad, ¿verdad?

En la Search Console existe un apartado llamado Recursos bloqueados que se encuentra dentro de la sección Índice de Google. Aquí podremos ver todos los recursos a los que, en este caso, Google no ha podido acceder y a las webs que afecta. Si es algo muy necesario para que el robot vea la web como la debe ver un usuario, deberemos añadir una excepción con un nuevo Allow en nuestro robots.txt.

Pero aquí no acaba el asunto. Si hemos subido nuestro sitemap, posiblemente también tendremos advertencias de lugares a los que Google no ha podido acceder por culpa de nuestro robots.txt. Aquí tendremos dos posibles soluciones: añadir una nueva excepción o quitar la url del sitemap, dependiendo de nuestro interés e intención.

Quiero testear mi robots.txt

Y si quieres, puedes. En la Search Console también encontrarás un apartado dedicado exclusivamente a este archivito. En la sección Rastreo encontrarás el Probador de robots.txt donde, además del contenido de este archivo que seguro te sonará, verás un área de texto a continuación de tu dominio para poner url relativas y directorios.

Según los vayamos poniendo veremos el texto PERMITIDO en verde junto a la url si es el caso, o un aviso rojo y la línea que la impide si no. ¡Es hasta divertido!

Uso de search console para probar robots.txt

Un ejemplo de robots.txt funcionando

Y esto es todo. ¿A que no es complicado? Como he dicho al principio, debemos tener en cuenta que el archivo robots.txt es tan solo una guía para los robots de los buscadores. Podemos cerrar y abrir puertas, pero los bots van a su bola. Eso sí, la guía siempre es bienvenida y, desde mi punto de vista, obligatoria para cualquier proyecto web.

¡Espero que os haya servido el artículo y nos leemos pronto!