El archivo robots.txt y las instrucciones que contiene es la implementación del conocido como Estándar de Exclusión de Robots, también llamado estándar o protocolo robots.txt. Durante mucho tiempo he visto como se ha utilizado este estándar con fines SEO bajo la convicción de que bloquear el rastreo de ciertos archivos y directorios podía mejorar el posicionamiento en buscadores.

Por ejemplo, una de las recomendaciones que más se han hecho en foros y portales de Internet ha sido que se deshabilitara el rastreo de archivos CSS, JavaScript, y a veces incluso imágenes, argumentando que su indexación afectaba negativamente al ranking de la web. ¿Te lo puedes creer?

Puede que fuera verdad, yo nunca le hice caso a esas recomendaciones así que no puedo decirte si tenían efecto o no, pero de lo que estoy seguro es de que actualmente están muy lejos de la realidad.

Hoy en día los principales buscadores de Internet (léase Google si quieres) necesitan interpretar todos los recursos que contiene una página web, incluyendo el CSS y JavaScript. Lo necesita por ejemplo en el test de usabilidad móvil.

Imagina que bloqueas el acceso al archivo .css que contiene las reglas de diseño adaptativo; como consecuencia el test de usabilidad móvil puede fallar y tu web será penalizada en los resultados de búsqueda desde dispositivos móviles.

Y no sólo se queda ahí la cosa, también se tienen en cuenta diversas métricas de rendimiento de la web, como puede ser el número y localización de los scripts, que pueden fallar si no se permite su rastreo.

En definitiva, la experiencia de usuario es un indicador con un peso importante en el SEO y su interpretación necesita que los rastreadores puedan acceder a todos los recursos de una página web, no sólo su HTML. Atrás quedaron los días en los que las webs eran rastreadas por los buscadores en modo texto.

Para que te hagas una idea de lo importante que es lo que quiero decir, Google Search Console tiene un panel dedicado en exclusiva a avisarte de las páginas en las que encuentra recursos bloqueados para que les prestes la debida atención:

Recursos bloqueados en Google Search Console
Registro de recursos bloqueados en Google Search Console

Fíjate en el texto que hay sobre el gráfico de la imagen anterior, dice así:

El procesamiento sin determinados recursos puede afectar la indexación de tus páginas web.

Y si todavía tienes dudas y no me crees, repasa las directrices técnicas de Google para webmasters.

Implementando robots.txt en WordPress

Por todo lo expuesto anteriormente, tal y como escribía hace unos días en WPSE, olvídate de las recomendaciones que puedas encontrar diciendo que bloquees los directorios de WordPress wp-content/themes, wp-content/plugins, wp-content/cache o cualquier otro directorio que contenga archivos .css y .js que utilices en el front-end de tu web.

Tampoco bloquees el directorio wp-includes, por mucho que leas esa recomendación en Internet. Este directorio contiene numerosas bibliotecas JavaScript, muchas veces acompañadas de CSS, que pueden ser utilizadas en el frontend por cualquier plugin, tema o el propio WordPress. Por ejemplo, video.js, la biblioteca JS y CSS utilizada para la reproducción de vídeo y audio, o el mismísimo jQuery, están alojados en wp-includes.

Concluyendo, se puede decir que, en general, el mejor archivo robots.txt para WordPress es el que genera automáticamente y cuyo contenido predeterminado es (desde WP 4.4):

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Has de tener en cuenta que WordPress crea el archivo robots.txt al vuelo, no existe físicamente. Salvo que sepas muy bien lo que haces y sus consecuencias, no es recomendable crear un archivo robots.txt real en WordPress; si lo haces se perderá la capacidad de creación al vuelo y cualquier plugin que lo utilice perderá su funcionalidad. En su lugar, si necesitas personalizar el robots.txt de WordPress utiliza el filtro robots_txt.

Por ejemplo, imagina que quieres bloquear el rastreo del directorio cgi-bin, del directorio de un determinado plugin y añadir la referencia al sitemap:

add_filter( 'robots_txt', function( $output ) {

    $output .= "Disallow: /cgi-bin/\n";
    $output .= "Disallow: /wp-content/plugins/carpeta-plugin-que-quiero-bloquear/\n";
    $output .= "\nSitemap: " . site_url( 'sitemap.xml' ) . "\n";

    return $output;

});

Esto dará como resultado el siguiente robots.txt:

User-agent: *
Disallow: /wp-admin/
Disallow: /cgi-bin/
Disallow: /wp-content/plugins/carpeta-plugin-que-quiero-bloquear/
Sitemap: http://misitio.com/sitemap.xml

Y si quieres seguir desactivando el rastreo de un directorio pero permitir el acceso a archivos css y js dentro de ese directorio podrías hacer algo así:

User-agent: *
Disallow: /wp-content/plugins/carpeta-plugin-que-quiero-bloquear/
Allow: /wp-content/plugins/carpeta-plugin-que-quiero-bloquear/*.css$
Allow: /wp-content/plugins/carpeta-plugin-que-quiero-bloquear/*.js$

Y recuerda: las indicaciones del Estándar de Exclusión de Robots son sólo eso, indicaciones, y como tales cualquier robot puede hacer caso omiso. Aunque haya estado utilizando la palabra “bloqueo”, el robots.txt en realidad no bloquea nada. Es como poner un cartel de “no pasar” en una casa con la puerta abierta. Habrá quien lo respete y habrá quien no. Si quieres bloquear el acceso de verdad tendrás que recurrir a otros métodos server-side.

Nota: las especificaciones del Estándar de Exclusión de Robots requiere que robots.txt sea accesible desde el directorio raíz, por ejemplo en miweb.com/robots.txt o tienda.miweb.com/robots.txt. Por este motivo, WordPress sólo puede controlar robots.txt si, igualmente, es accesible desde el directorio raíz.

Referencias