robots.txt en WordPress

El archivo robots.txt y las instrucciones que contiene son la implementación del conocido como Protocolo de Exclusión de Robots (Robots Exclusion Protocol).

Durante mucho tiempo he visto como se ha utilizado el archivo robots.txt con fines SEO bajo la convicción de que bloquear el rastreo de ciertos archivos y directorios podía mejorar el posicionamiento en buscadores, o incluso que con robots.txt se podía bloquear robots maliciosos.

Beneficios SEO, algunos, pero en casos concretos. Y de bloquear robots, robots.txt no bloquea nada.

robots.txt de WordPress

Tal y como escribía hace unos días en WPSE, se puede decir que el mejor robots.txt para WordPress de forma general es precisamente el robots.txt que genera WordPress. Su contenido predeterminado es, desde WordPress 4.4 y por ahora (5.2.2):

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

En la mayoría de casos no tienes que prestar la menor atención a este archivo. El robots.txt predeterminado ya es bueno:

• No bloquea ningún recurso del frontend
• Bloquea todos los recursos del backend con excepción de admin-ajax.php, pues el AJAX API también puede ser utilizado en el frontend y hay que cumplir el punto anterior.

Recomendaciones comunes pero delicadas

1. Bloquear wp-content, wp-includes, css, js, imágenes y otros recursos

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.

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.

Sin embargo, todavía es fácil encontrar tutoriales en Internet en los que se recomienda bloquear el rastreo de ciertos tipos de recursos para mejorar el SEO.

Por ejemplo, en WordPress es común ver recomendaciones para bloquear los directorios wp-includes y wp-content, pero son precisamente esos directorios los que contienen los recursos utilizados en la parte pública de la web.

Salvo que sepas bien lo que estás haciendo y tengas un objetivo claro y fundamentado, esos directorios no se deben bloquear.

2. Robots.txt no bloquea ningún robot

A pesar de su nombre, el protocolo de exclusión de robots no bloquea nada. Si tu puedes acceder a un recurso bloqueado en robots.txt, puede hacerlo cualquier robot.

Si quieres bloquear de verdad el acceso a un recurso vas a tener que trabajar con otras herramientas.

robots.txt contiene indicaciones, algunos robots las siguen, otros robots no. Por ejemplo, los crawlers de Google, Bing y otros buscadores hacen caso a estas directrices y no rastrean ni indexan aquello que no les permita robots.txt.

Pero ten claro que robots.txt no bloquea nada en sentido estricto, es cuestión de que el software del robot quiera hacer caso o no, tan sencillo como eso. Bloquear robots spammers, peligrosos o maliciosos con robots.txt no tiene mucho sentido para mí. Y sin embargo, esta también es una recomendación muy fácil de encontrar en Internet.

3. Bloquear el rastreo no siempre es la mejor opción SEO

Como se ha mencionado, los crawlers de los principales buscadores respetan las indicaciones dadas en el archivo robots.txt. Si le decimos que no rastree algo, no lo rastrea y, por tanto, tampoco lo indexa.

Pero la mayoría de las veces, desde un punto de vista SEO, lo que de verdad queremos es que SI rastree pero que NO indexe. Piensa en ello un poco.

Vamos un poner un ejemplo que yo veo muy claro con otra de las recomendaciones más habituales sobre SEO, WordPress y robots.txt : bloquear el rastreo de feeds, tags, attachments, etc. Sin embargo, es mucho mejor dejar que los buscadores rastreen esas páginas, que lean esos documentos y que sigan los links que puedan contener hacia otras partes de la web.

Con robots.txt impides el rastreo y la indexación. Para permitir el rastreo pero no la indexación, que es lo interesante, mucho mejor utilizar las cabeceras follow,noindex, ya sea con cabeceras HTTP X-Robots-Tag o con etiquetas meta:

add_action( 'template_redirect', function() {
    if( is_feed() ) {
        header("X-Robots-Tag: follow,noindex");
    }
});

Al usar estas cabeceras, los bots pueden leer esos documentos aunque no los indexen, y al leerlos pueden seguir los enlaces que contengan aumentando así la posibilidad de que descubran todo el contenido de tu web y la tasa de contenido rastreado.

Este método se puede utilizar para cualquier recurso que utilicemos en el frontend pero cuya indexación no sea muy oportuna.

Por ejemplo, se utiliza en las URLs de WP REST API y en las URLs del AJAX API (wp-admin/admin-ajax.php). Ambas son URLs utilizadas en el frontend y por tanto debe permitirse su rastreo, no se deben bloquear en robots.txt, aunque su indexación no es nada oportuna y así se les hace saber a los buscadores a través de las cabeceras HTTP o de las etiquetas meta.

El caso concreto de la URL de admin-ajax.php es muy buen ejemplo. Fíjate que estaba específicamente permitida en el robots.txt predeterminado de WordPress como excepción al directorio wp-admin, pero si la pruebas y analizas las cabeceras HTTP te encontrarás con la cabecera X-Robots-Tag: noindex.

El directorio wp-admin se estuvo bloqueando en robots.txt al completo hasta que en el a versión 4.4 de WordPress, Joost de Valk (Yoast.com) sugirió poner como excepción el archivo admin-ajax.php, ya que era frecuentemente utilizado en el frontend por muchos plugins y al estar bloqueado en robots.txt generaba errores en Google Search Console. Por tanto, se debía permitir su rastreo, aunque no su indexación.

Modificar robots.txt en WordPress

A pesar de todo lo anterior, todavía puede haber muchas situaciones en las que esté plenamente justificado modificar el robots.txt de WordPress, aunque no sea estrictamente por motivos SEO ni mucho menos por seguridad.

WordPress crea el archivo robots.txt al vuelo, el archivo robots.txt no existe de verdad físicamente, y para modificar el robots.txt hay que hacer desde PHP con el filtro robots_txt.

Por ejemplo, imagina que quieres bloquear el rastreo del directorio cgi-bin, el 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/plugin-que-quiero-bloquear/\n";
    $output .= "Sitemap: " . site_url( 'sitemap.xml' ) . "\n";

    return $output;

});

Esto dará como resultado el siguiente robots.txt (contenido predeterminado más el añadido en el código):

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cgi-bin/
Disallow: /wp-content/plugins/plugin-que-quiero-bloquear/
Sitemap: ...ejemplo.com/sitemap.xml

También se podría bloquear toda la carpeta de plugins pero permitir los archivos .css y .js añadiendo estas líneas:

User-agent: *
Disallow: /wp-content/plugins/plugin-a-bloquear/
Allow: /wp-content/plugins/plugin-a-bloquear/*.css
Allow: /wp-content/plugins/plugin-a-bloquear/*.js

Estos cambios en el robots.txt también se pueden hacer creando el archivo robots.txt y subirlo al servidor, y no a través del filtro robots_txt, pero al crear el archivo bloquearás el manejo de robots.txt por WordPress y de cualquier plugin que lo utilice.

Por ejemplo, la mayoría de plugins que crean sitemaps añaden una o varias entradas al robots.txt utilizando el API de WordPress. Si el archivo robots.txt existe de verdad, no podrían hacerlo.

Así que recuerda, en WordPress no se debe crear un archivo robots.txt en el servidor directamente, se debe trabajar a través del API de WordPress.

Referencias

• The robots.txt file. HTML 4.01 specification, Appendix B.4.1. W3C. (última especificación publicada. Actualmente el Estándar de Exclusión de Robots no está en desarrollo activo).
• Información sobre los archivos robots.txt. Ayuda de Herramientas para webmasters de Google.
• Directrices para webmasters. Ayuda de Google Search Console.