robots.txt para WordPress: Cómo crear el mejor para tu sitio Web

¡CON UN 20% DE DESCUENTO!

El archivo robots.txt en WordPress: comprendiendo primero cómo funciona

Antes de entrar en las “tripas” del archivo robots.txt y cómo escribirlo para que no perjudique nuestro posicionamiento orgánico, quisiera aclarar algunos conceptos que, según he podido constatar en muchos de los posts que he leído, crean bastante confusión y conducen a muchas configuraciones de robots.txt que no son necesariamente erróneas (que también) pero que no ofrecen lo que el propietario del sitio web espera de ellas.

Una de estas malinterpretaciones, por ejemplo, consiste en creer que un archivo robots.txt puede impedir el acceso a determinadas carpetas o ficheros del sitio web que queramos proteger, cuando, y ya lo adelanto, de ninguna forma tiene esa capacidad de bloqueo.

Así que veamos para qué sirve y, sobre todo, para qué NO sirve este archivo.

❓ ¿Cómo influye el archivo robots.txt en la indexación y posicionamiento #SEO de un sitio web? ❓ Clic para tuitear

Para qué sirve el archivo robots.txt en WordPress

La función y alcance del archivo robots.txt puede comprenderse mucho mejor si primero sabemos y entendemos cómo los buscadores indexan las páginas de los sitios web, puesto que este archivo interviene e influye activamente en parte de este proceso.

En realidad, los buscadores realizan su cometido mediante dos pasos bien diferenciados:

• • 1. Rastreo de los sitios web, en el que software especializado de los buscadores (denominados crawlers, bots, spiders o, preferiblemente en español, rastreadores o arañas) recorren los sitios web a través de los enlaces de sus páginas web, recolectando éstas.
    2. Indexación de las páginas web, en el que los algoritmos de búsqueda parsean y analizan el contenido de las páginas recolectadas por los rastreadores, con el fin de indexarlos y posicionarlos en los resultados de búsquedas con palabras relacionadas con dicho contenido.

El archivo robots.txt afecta, sola y exclusivamente, al primero de estos dos pasos. Es decir, a la recolección de páginas, indicando a los rastreadores qué secciones, páginas o recursos (entendiendo como tales cualquier tipo de fichero: imágenes, documentos, vídeos, etc.) de un sitio web pueden (o deberían) rastrear y qué no pueden (o no deberían) rastrear.

Sin embargo, aunque el archivo robots.txt no interviene directamente en la indexación y posicionamiento de las páginas web, sí que puede impedir (ya os adelanté que esto no es completamente cierto, profundizaremos en ello más adelante) que el contenido de una página o recurso sea analizado e indexado por los algoritmos de búsqueda.

Poniendo un símil, podemos imaginar un sitio web como un libro y al rastreador como una persona (un “censurador”, por ponerle emoción) que hojea ese libro siguiendo las normas (el equivalente al robots.txt) que establece qué tipos de páginas se pueden leer, cuáles deben ignorarse, o incluso qué capítulos o grupos de páginas pueden leerse o deben ignorarse.

El único cometido de esta persona, como rastreador/censurador, sería marcar las páginas que, según esas normas, pueden ser leídas por el público, mientras que apartaría el resto. Entonces el público (los algoritmos de búsqueda) sólo podría leer (analizar) las páginas permitidas por el censurador/rastreador.

 

Para qué no sirve el archivo robots.txt en WordPress

Llegados a este punto debemos evitar caer en el error, bastante generalizado, de que el archivo robots.txt puede restringir e impedir el acceso a determinados recursos de un sitio web, como si estuvieran protegidos contra accesos maliciosos.

Este es el matiz que remarcaba en el apartado anterior: en realidad, el archivo robots.txt no “impide” nada ni “impone” una suerte de código de conducta ineludible a los rastreadores, sino una serie de sugerencias que el rastreador decide si hacer caso o no. En líneas generales, los rastreadores de los buscadores son bastante educados y siguen fielmente sus instrucciones.

Sin embargo, os puedo asegurar que los rastreadores maliciosos las ignorarán (por ejemplo, los que buscan agujeros de seguridad para atacar un sitio web). Sería como poner un cartelito en la puerta de nuestra casa con el texto “No pasar” :/ Las personas honradas no entrarían pero ¿protegerías así tu casa contra los ladrones?

Pero tampoco tiene que ser necesariamente un rastreador malicioso, sino cualquier rastreador que, por el motivo que sea, ignore el fichero robots.txt. Para que os hagáis una idea, vosotros mismos podéis construir un rastreador sencillo a partir de este código Java, que sí respeta el robots.txt, en el que resulta increíblemente fácil eliminar las clases e instrucciones encargadas de obedecer sus instrucciones

Por tanto, si queremos limitar el acceso a determinados recursos privados de nuestro sitio web, no podemos hacerlo a través del fichero robots.txt, sino mediante mecanismos que no dependan de la interpretación de rastreador. Esta restricción solo se puede hacer desde el servidor que aloja el sitio web, impidiendo de forma efectiva el acceso a esos recursos independientemente de la buena o mala voluntad del visitante o rastreador (por ejemplo, mediante el fichero .htaccess).

Tened en cuenta también que el archivo robots.txt es de acceso libro y público: puesto que los rastreadores deben (deberían) leerlo, no puede tener ninguna restricción de acceso. Esto significa que cualquiera puede leer toda la información que incluyáis en ese fichero. Mirad, por ejemplo, el robots.txt del banco BBVA (que todos estaremos de acuerdo que estarán muy sensibilizados con la seguridad de su web).

 

El archivo robots.txt ante los enlaces entrantes externos

Observar un pequeño detalle en el símil del censurador de libros y pensad un poco en la siguiente pregunta: ¿qué pasaría si, en otro libro, hubiera referencias a páginas censuradas del primero desde páginas que no están censuradas? ¿Qué haría el censurador de este segundo libro?

Con las normas en la mano, no podría censurar las páginas del libro, pero entonces sus lectores tendrían una referencia a una página censurada en otro libro, aunque no podrían leerla (pues está censurada y el primer censurador “hace bien” su trabajo de acatar las normas).

Algo parecido sucede con los rastreadores y los ficheros robots.txt: un rastreador no llegaría a los recursos “prohibidos” por el robots.txt cuando rastreara a través de nuestro sitio web (supuesto que no pongamos nosotros mismos enlaces directos a ellas desde otras páginas, claro).

Sin embargo, si desde otro sitio web hubiera un enlace a uno de estos recursos, entonces desde esa página web externa habría una referencia a nuestro recurso que SÍ podría aparecer en los resultados de búsqueda, dado que esa página externa puede haber sido rastreada e indexado normalmente por los buscadores.

En este caso, el enlace al recurso “prohibido” aparecería en los resultados de búsqueda del buscador, aunque sin información adicional debido a que el rastreador (educado él) no la ha leído, acorde a las restricciones de nuestro archivo robots.txt:

Corolario: NO protejas tus recursos sensibles y privados con el archivo robots.txt; no está hecho para eso.

Los tres niveles del control de rastreo de un sitio web

El archivo robots.txt no es el único mecanismo que tenemos para controlar cómo los rastreadores (honestos) recorrerán nuestro sitio web, sino que disponemos de varios que operan a distintos niveles dentro del sitio web:

• • 1. A nivel del sitio web, que afecta a todos los recursos del sitio web. En este nivel trabajan el fichero robots.txt, el fichero sitemaps y la etiqueta de cabecera X-Robots-Tag.
    2. A nivel de página web, que afecta sólo a la página web que en ese momento está leyendo el rastreador, que correspondería a las meta-etiquetas robots incluidas en esa página.
    3. A nivel de enlace, que sólo afecta al enlace en que se defina dicha restricción, en el que se encuadra el atributo “rel” de las etiquetas HTML para los enlaces (“<a>”).

Dos consideraciones debemos tener en cuenta en cuanto al funcionamiento de estos mecanismos de control en cada uno de los niveles:

• • • Por defecto, todos los mecanismos permiten total libertad de rastreo e indexación de todos los recursos del sitio web. Es decir, los rastreadores seguirán todos los enlaces que encuentre, recolectará todos los recursos que rastree y los algoritmos de búsqueda indexarán todos estos recursos. La única condición para que un recurso sea indexado es que tenga un enlace hasta él o esté expresamente incluido en el fichero sitemaps.
    • En caso de conflicto (esto es, cuando un mecanismo aplica una restricción opuesta a otro mecanismo), siempre tiene preferencia la restricción del nivel superior y, en el mismo nivel, siempre tiene prioridad la restricción (por ejemplo, cuando el fichero sitemaps incluye un enlace a un recurso restringido por el fichero robots.txt).

El segundo punto puede inducir a confusión algunas veces. Para evitarlo, debemos ponernos en la piel del rastreador: ¿qué es lo primero que se encuentra cuando visita un sitio web? El archivo robots.txt. Si este archivo le indica que no rastree determinada página, entonces no podrá leer las restricciones a nivel de página web o nivel de enlace, por lo que ninguna de éstas llegaría a aplicarse.

En otras palabras, el rastreador dispone de total libertad de movimiento mientras no encuentre alguna directiva que le pare los pies.

Por último, observad que el fichero sitemaps realmente no impone ninguna restricción de rastreo, sino que simplemente informa al rastreador de las páginas disponibles para su rastreo. Esto no impedirá que rastree otros recursos enlazados desde estas páginas, pero normalmente dará preferencia a las páginas que sí aparecen en el sitemaps y las rastreará primero.

❓ ¿Cuáles son los tres nivel de control que tenemos sobre el rastreo (crawling) de un sitio web? ❓ #SEO #PosicionamientoWeb Clic para tuitear

¿Cuándo utilizar las restricciones de rastreo de uno u otro nivel?

No hay una regla fija que dé respuesta a esta pregunta, pero sí una serie de recomendaciones que debemos valorar individualmente para cada sitio web y, cuando proceda, para cada recurso o tipo de recurso:

• • 1. Utilizar el fichero sitemaps para indicar al rastreador nuestras preferencias de rastreo de las páginas y recursos de nuestro sitio web. Recordad que el sitemaps no puede incluir restricciones.
    2. Utilizar la restricción a nivel de enlace cuando ese enlace hace referencia a una página o recurso que no queremos que sea rastreada o indexada.
    3. Utilizar la restricción a nivel de página cuando queramos imponer alguna restricción de rastreo o indexación al contenido o los enlaces de una determinada página web.
    4. Utilizar la restricción a nivel de servidor cuando la restricción afecte a una sección completa del sitio web (que normalmente corresponderá a un directorio del servidor), a un tipo concreto de recursos (por ejemplo, los ficheros de imágenes) o, en general, a un grupo de varios recursos cuyo nombres de fichero reúnan algún requisito (por ejemplo, ficheros que incluyan el texto “instrucciones”) y que sea tedioso o imposible de realizar a nivel de página web o de enlace.

Las restricciones a nivel de enlace o a nivel de página web tienen un alcance limitado (al enlace o página en el que se encuentran), por lo que si cometemos un error con ellas, el efecto también será bastante limitado. No es una situación ideal, claro, pero es soportable.

En cambio, las restricciones a nivel de sitio web (esto es, las incluidas en el robots.txt) tienen un alcance global: absolutamente todos los recursos pueden resultadas afectadas por ellas. Por tanto, debemos ser especialmente cuidadosos cuando incluyamos alguna restricción y, cuando lo hagamos, asegurarnos que tengan el efecto deseado y no estemos restringiendo recursos que sí queremos que sean rastreados.

¡CON UN 20% DE DESCUENTO!

Creando y configurando el archivo robots.txt en WordPress

El fichero robots.txt es un fichero de texto, que podemos editar con cualquier editor, y que debe colocarse en la carpeta raíz del sitio web (http://www.mi-dominio.com/robots.txt), de forma que los rastreadores puedan localizarlo y leerlo fácilmente.

Dado que, por defecto, los rastreadores tienen acceso libre a todo el sitio web, recorriendo sus páginas a través de los enlaces entre ellas, en principio sólo necesitamos crear el robots.txt cuando queramos incluir alguna restricción. De hecho, John Mueller, de Google, recomienda expresamente borrarlo si no vamos a utilizarlo.

Posiblemente leáis que puede haber rastreadores que provoquen errores 404 si no encuentran el robots.txt pero, ¿qué queréis que os diga?, yo no me preocuparía lo más mínimo por un rastreador que no sabe que el fichero robots.txt no es obligatorio y, la verdad, casi preferiría que no se paseara por mi sitio web (y, ¿quién sabe?, quizás ese error 404 hasta le pare los pies en su confusión 😉 ).

? Guía para crear y configurar el archivo robots.txt para tu sitio web ? #SEO #PosicionamientoWeb Clic para tuitear

Estructura del archivo robots.txt

Cuando configuramos el archivo robots.txt podemos incluir las siguientes instrucciones o directivas:

• • • user-agent, que identifica el rastreador que debe cumplir las directivas que se indiquen en las líneas siguientes del fichero. Cada rastreador tiene su propio nombre.
    • disallow, que deniega el acceso a un recurso, sea un fichero o grupo de ficheros, o un directorio o grupo de directorios.
    • allow, que permite al acceso a un recurso. En principio, puesto que por defecto está permitido el acceso a todos los recursos, sólo tiene utilidad para deshacer parcialmente la restricción realizada por una directiva disallow (por ejemplo, permitir el acceso a una página dentro de una carpeta restringida por disallow).
    • sitemap, para indicar la dirección URL completa del fichero sitemaps del sitio web.

Algunos rastreadores reconocen directivas adicionales en el robots.txt, pero éstas son las más frecuentes con diferencia. A decir verdad, las únicas directivas del robots.txt recogidas por el protocolo de exclusión de robots son user-agent y disallow. Aunque allow y sitemap no están estandarizadas, son gestionadas de forma similar por la mayoría de los buscadores.

La estructura y orden de las instrucciones del robots.txt tiene relevancia, debiendo siempre indicar primero el rastreador (user-agent), seguido de las directivas allow y disallow (en este orden) que ese rastreador debe acatar, y terminando ese bloque con una línea en blanco antes de comenzar otro bloque con esta misma estructura:

# Bloque de restricciones para el rastreador de Google
user-agent: googlebot
allow: /documentos/curriculum.pdf
disallow: /documentos/

# Una línea en blanco antes de empezar un nuevo bloque
# Bloque de restricciones para el rastreador de Bing
user-agent: bingbot
allow: /documentos/curriculum.pdf
disallow: /documentos/

En este fragmento, dado que las restricciones son las mismas para los dos rastreadores indicados, podríamos sustituirlo por lo siguiente:

user-agent: bingbot
user-agent: googlebot
allow: /documentos/curriculum.pdf
disallow: /documentos/

Este fragmento, como habréis supuesto, instruye a los rastreadores de Google y Bing para que no rastreen la carpeta “/documentos/” (y todo el contenido que cuelga de ella), excepto el fichero “/documentos/curriculum.pdf”, que sí podrán rastrear e indexar.

Según el protocolo de exclusión de robots, la directiva allow debe aparecer antes de la directiva disallow cuyo efecto contrarresta, pero Google y Bing aplican a cada recurso la directiva que tenga mayor número de caracteres coincidentes en su patrón, independientemente del orden. Es decir, cuando un recurso coincida con el patrón de varias directivas, se le aplicará la directiva con el patrón más largo y, en caso de empate, la directiva allow prevalece.

Por último, si utilizamos la directiva sitemap, debemos incluirla al final del robots.txt:

sitemap: http://www.mi-dominio.com/sitemaps.xml

Si hubiera más de un sitemap, añadiríamos una línea por cada uno de ellos, todas encabezadas con la directiva sitemap:

sitemap: http://www.mi-dominio.com/sitemaps-pages.xml
sitemap: http://www.mi-dominio.com/sitemaps-posts.xml
sitemap: http://www.mi-dominio.com/sitemaps-index.xml

Aunque el archivo robots.txt puede incluir comentarios (la línea encabezada con el símbolo “#” en el fragmento anterior), no os recomiendo hacerlo: recordad que cualquiera puede acceder y leer el robots.txt, ¿realmente estáis dispuestos a explicarle a un desconocido, quizás malicioso, por qué estáis restringiendo o permitiendo el acceso a algún recurso?

 

Identificando los rastreadores

En general, cada bloque de directivas tiene el siguiente formato:

user-agent: <nombre-del-rastreador>
allow: <patrón-del-recurso>
disallow: <patrón-del-recurso>

Donde el <nombre-del-rastreador> es una cadena de texto que identifica al rastreador que debe acatar las subsiguientes directivas allow/disallow hasta encontrarse una línea en blanco.

Cada buscador tiene sus propios rastreadores (sí, varios), todos ellos con su nombre específico. Como hay cientos de rastreadores, salvo que tengamos un interés especial por alguno en concreto, siempre indicaremos que las directivas son aplicables a todos los rastreadores, poniendo un asterisco en lugar de un nombre:

user-agent: *

Hasta ahora, nunca me he sentido en la necesidad de identificar expresamente el user-agent de un rastreador y siempre he utilizado el asterisco. Y, la verdad, tampoco imagino ningún escenario en el que proporcione alguna ventaja la configuración de diferentes restricciones de acceso a un recurso para uno u otro rastreador (especialmente cuando se trata de los dos buscadores principales, Google y Bing).

De todas formas, si necesitáis el user-agent de algún rastreador de un buscador, lo mejor que podéis es consultarlo directamente en sus páginas. Por ejemplo, aquí tenéis los rastreadores de Google y de Bing.

 

Identificado los recursos

Con respecto al <patrón-del-recurso>, es una secuencia de caracteres con la que debe coincidir, total o parcialmente, el nombre completo (es decir, carpetas incluidas) de los ficheros o carpetas de los recursos para que la directiva tenga efecto en ellos. Esta comparación diferencia minúsculas de mayúsculas; es decir, “/documentos” es distinto de “/Documentos”.

Remarco lo de “nombre completo” porque los recursos no quedan identificados solamente por el nombre de su fichero o carpeta, sino también por la ruta de todas las carpetas para llegar hasta ellos, incluida la barra inclinada (“/”) inicial. Por tanto, el <patrón-del-recurso> también deberá incluir la ruta cuando sea necesario.

Cuidado: el patrón y el nombre completo del recurso se comparan a partir del primer carácter; es decir, un patrón no se comparará con la parte media del nombre de un recurso, por ejemplo:

• • • El patrón “/documentos” sería válido para la carpeta “/documentos/pdfs/”, puesto que comienzan igual.
    • El patrón “/documentos” NO sería válido para la carpeta “/datos/documentos/”, puesto que no comienzan igual.
    • El patrón “documentos” NO sería válido para ningún recurso, puesto que no comienza con la barra inclinada (“/”).

El patrón no se limita a compararse con ficheros, sino que puede coincidir con el nombre completo de un fichero o de una carpeta. En el caso de que sea un fichero, la directiva se aplicaría solamente a ese fichero, mientras que si fuese una carpeta, se aplicaría a todos los ficheros y subcarpetas de esa carpeta:

• • • disallow: /documentos/curriculum.doc, restringe el acceso al fichero “curriculum.doc” en la carpeta “/documentos/”.
    • disallow: /documentos/, restringe el acceso a todos los ficheros de la carpeta “/documentos/” y todas las subcarpetas (y sus ficheros) de ésta.

 

Usando comodines en los nombres de los recursos

Podemos formar patrones más complejos y genéricos utilizando dos caracteres especiales:

• • • “*” (asterisco), para indicar cualquier número de caracteres.
    • “$” (dólar), para indicar que no debe haber más caracteres a continuación.

Siguiendo con el ejemplo anterior:

• • • El patrón “/documentos$” NO sería válido para la carpeta “/documentos/pdfs/”, pero sí para “/documentos”.
    • El patrón “*/documentos” sería válido para el carpeta “/datos/documentos” y también para el fichero “/datos/documentos/curriculum.doc”.

Hay que tener mucho cuidado con la utilización del asterisco, puesto que podríamos incluir sin darnos cuenta recursos a los que no queremos aplicar esa directiva. Por ejemplo, la línea:

disallow: /*/documentos

restringiría el acceso a todos los recursos siguientes:

/servicios/documentos/
/proyectos/documentos/
/documentos/
/descargas/ficheros/documentos/
/ficheros/documentos.doc
/imágenes/escaner/documentos_antiguos.doc

Como podéis imaginar por estos ejemplos, utilizar el asterisco supone mucho riesgo, porque podría afectar a recursos que creásemos en el futuro y que, casualmente, coincidieran con el patrón indicado. Por este motivo, recomiendo evitar el uso del asterisco.

Por su parte, la utilización del dólar (“$”) se mucho más segura y, de hecho, lo recomiendo siempre que necesitemos referenciar a un único fichero:

# No rastrea curriculum.htm, pero sí curriculum.html
disallow: /documentos/curriculum.htm$

O a varios ficheros por su extensión:

# No rastrea todos los ficheros con extensión “.htm”, pero sí con “.html”
disallow: /*.htm$

Como veis, la utilización de los caracteres especiales puede tener efectos colaterales impredecibles (nunca sabremos qué ficheros o carpetas tendremos dentro de un año) por lo que, salvo casos muy concretos y muy cerrados, deberíamos evitar utilizar estos caracteres especiales en los patrones de las directivas (y si aún pensáis en utilizarlos, leed en este artículo lo que os puede pasar).

 

Recomendaciones generales para el archivo robots.txt en WordPress

Como ya estaréis suponiendo, la configuración del robots.txt puede ser muy crítica para el adecuado rastreo, indexación y posicionamiento orgánico de un sitio web. Por tanto, debemos extremar las precauciones cuando lo editemos, evitando que nuestra configuración pueda limitar el campo de trabajo de los rastreadores.

Aunque en los apartados anteriores ya he ido adelantando algunas recomendaciones a la hora de editar el robots.txt, dado el enorme impacto que puede tener en nuestra estrategia de posicionamiento, vuelvo a enumerarlos a continuación, junto con otras también importantes:

• • • El archivo robots.txt no es obligatorio. Los rastreadores “buenos” lo saben, así que no te preocupes por “errores 404” inexistentes y, si no lo necesitas, no lo crees.
    • No tiene sentido restringir en el robots.txt el acceso a rastreadores maliciosos o voraces (que rastrean excesiva y continuamente un sitio web), puesto que no están obligados a cumplirlo. Utilizar el fichero .htaccess, o equivalente, en su lugar (de hecho, ya hay proveedores de alojamiento que lo hacen automáticamente en todos sus servidores para algunos rastreadores).
    • No tiene sentido restringir en el robots.txt el acceso a recursos privados o confidenciales, puesto que el rastreador que quiera siempre podrá acceder. Es más, al ponerlo en el robots.txt estamos dando pistas a los rastreadores maliciosos para rastrear nuestro sitio web. En su lugar, utilizar el fichero .htaccess y evitar enlaces a esos recursos, tanto desde páginas web como en el fichero sitemaps.
    • No bloquear el acceso a las carpetas de los plugins. El rastreador de Google necesita utilizar los ficheros JS y CSS para renderizar las páginas donde se utilizan. Si los bloqueamos, no podrá acceder a ellos para evaluar el experiencia de usuario.
    • El archivo robots.txt es de acceso público y siempre está localizado en el mismo sitio: en la carpeta raíz del dominio. En consecuencia, no incluir comentarios que puedan dar pistas a intrusos maliciosos sobre el cometido o función de los recursos.
    • El archivo robots.txt no impide que un recurso pueda aparecer en los resultados de búsqueda de los principales buscadores; basta con que tenga enlaces entrantes externos para que aparezca. Para impedir la indexación de un recurso, utilizar metaetiquetas robots o etiquetas de cabecera X-Robot-Tab.
    • Salvo que haya un interés especial por elaborar una estrategia específica para algún buscador en concreto, utilizar siempre el comodín asterisco para el user-agent.
    • Utilizar sólo las directivas disallow, allow y sitemap. Aunque hay unas cuantas directivas más, no están estandarizadas y tienen diferencias de funcionamiento entre los rastreadores de buscadores. Incluso la directiva allow no es estándar, pero Google y Bing aplican el mismo criterio en su aplicación (la longitud del patrón del recurso).
    • El estándar de exclusión de robots define que la directiva allow debe preceder a la disallow que contrarresta. Aunque no es necesario para Google y Bing, otros muchos rastreadores sí que siguen el estándar, así que mejor seguir el estándar para asegurar la mayor compatibilidad.
    • La comparación entre el nombre completo de los recursos y el patrón de las directivas distingue entre minúsculas y mayúsculas. Mucho cuidado con esto, porque suele ser origen de bastantes problemas.
    • Tanto el nombre de los recursos como el patrón deben incluir la ruta completa, comenzando por la barra inclinada “/”.
    • El robots.txt no diferencia entre nombres de fichero y nombres de carpeta. Por ese motivo, todos los patrones de recursos en las directivas deben incluir la barra inclinada “/” al final, para no ser confundidos y comparados con nombres de fichero que comiencen con el mismo texto.
    • No utilizar nunca los caracteres especiales “$” y “*” (sí, lo sé, “nunca” es demasiado tiempo): es muy fácil que puedan tener efectos secundarios sobre otros recursos que no hayamos anticipado o previsto.
    • En caso de duda, mejor no incluir una directiva disallow que pueda tener un efecto secundario impredecible.

 

Plan para elaborar el archivo robots.txt

Llegados a este punto, ¿cómo deberíamos actuar para construir el robots.txt de un sitio web? Os propongo el siguiente plan:

• • 1. Partir de la base de que todos los recursos, tanto ficheros como carpetas, son de acceso libre para todos los rastreadores.
    2. Identificar individualmente todos los ficheros y carpetas que, por el motivo que sea, no queremos que sean rastreados por los buscadores.
    3. Si alguno de estos ficheros y carpetas identificados tienen información confidencial o privada, marcarlo aparte para restringir el acceso con otros mecanismos apropiados para ellos (por ejemplo, .htaccess).
    4. Del resto de ficheros y carpetas, escribir la correspondiente directiva disallow cuyo patrón sea el nombre completo para cada uno (comenzando con la barra inclinada “/”).
    5. Finalizar los patrones de nombres de fichero con el símbolo “$”, para evitar coincidencias con otros ficheros con nombre y extensión similares.
    6. Finalizar los patrones de nombres de carpeta con el símbolo “/$”, para indicar que es una carpeta y evitar coincidencias con otros recursos con nombre similar. En caso que también se quiere restringir a todas las subcarpetas, finalizarlo solo con el símbolo “/”.
    7. Una vez escritas todas las directivas disallow, incluir directivas allow para contemplar las excepciones, tomando las mismas precauciones que en los puntos 5 y 6.
    8. Si procede, agrupar las directivas disallow que tengan patrones similares, utilizando el símbolo especial “*”.
    9. Revisar el fichero robots.txt cada vez que haya algún cambio estructural en el sitio web (nuevas secciones, nuevos tipos de recursos, etc.).

Por lo general, si nuestro sitio web está bien estructurado (y, con la proliferación de gestores de contenidos, casi seguro que lo está), lo habitual es que solo necesitemos incluir directivas disallow para algunas carpetas y su contenido.

 

¿Debemos rastrear los ficheros de scripts y CSS?

Cuestión peliaguda y controvertida…  Si buscáis por Internet, encontraréis que muchos artículos recomiendan restringir el acceso a este tipo de ficheros, junto a las hojas de estilos, puesto que no son contenidos y no aportan nada para posicionar.

Hace años, la respuesta a esta pregunta habría sido negativa sin dudarlo: en aquella época, los rastreadores sólo “entendían” contenidos textuales, mientras que ignoraban  los ficheros ejecutables o interpretables, entre ellos los scripts Javascript y las hojas de estilos CSS.

Por tanto, tenía sentido restringir en el archivo robots.es el acceso a las carpetas que contenían exclusivamente este tipo de ficheros. Después de todo, el rastreador no los entendería y, al rastrearlo, estarían consumiendo recursos de nuestro servidor (no os asustéis, los rastreadores suelen ser educados e intentan “molestar” lo menos posible), así que podíamos dejarlos fuera sin peligro.

Sin embargo, esta perspectiva ha cambiado en los últimos años: los rastreadores actuales de los buscadores ya son capaces de interpretar y entender tanto los scripts como las hojas de estilo. Es más, incluso puede influir en el posicionamiento orgánico.

Actualmente, los ficheros Javascript y los estilos CSS tienen un papel fundamental en la generación de una página web, puesto que participan activamente en cuál será la apariencia final del sitio web, especialmente importante en el test de usabilidad móvil de PageSpeed Insights.

Recordemos que, hoy en día, la experiencia de usuario se ha convertido en uno de los factores de posicionamientos más importantes. Si impedimos que los rastreadores accedan a estos ficheros, no renderizarán adecuadamente una página web y, en consecuencia, no podrán analizar su apariencia ni evaluarla.

Y si mis palabras no os parecen suficientes (eso está bien: hay que ser críticos 😉 ), la propia Google actualizó sus directrices técnicas para webmasters en 2014 para recomendar que se permitiera el rastreo de estos ficheros:

“Si desactivas el rastreo de los archivos JavaScript o CSS en el archivo robots.txt de tu sitio, el procesamiento y la indexación de contenido que realizan nuestros algoritmos se verán afectados directamente y se podría producir una clasificación inferior al nivel óptimo.”

Mejor no llevarles la contraria 😀

✅ La pregunta del millón: ¿cómo quedaría el mejor archivo robots.txt para WordPress? ? #SEO #PosicionamientoWeb Clic para tuitear

¿Cómo sería el mejor archivo robots.txt para WordPress?

Si habéis leído todo lo anterior hasta aquí, seguramente os estaréis quedando con la impresión que el mejor fichero robots.txt para WordPress sería… ¡el fichero vacío!

Pues, por fuerte que pueda parecer, así es: casi mejor dejarlo vacío que incluir directivas que puedan afectar, directa o indirectamente, al óptimo rastreo del sitio web y, en consecuencia, perjudicar a su posicionamiento orgánico.

En realidad, un sitio web realizado en WordPress sin robots.txt… sí que tiene un archivo robots.txt, generado automáticamente por WordPress (desde la versión 4.4), con el siguiente contenido:

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

Estas líneas restringen el acceso a la carpeta “/wp-admin/” de WordPress, lo cual tiene sentido porque corresponde al entorno de administración de WordPress y no aporta nada al rastreo e indexación de nuestro sitio web. Aunque sí permite el acceso al fichero “/wp-admin/admin-ajax.php/”, decisivo para que theme y plugins se integren bien en WordPress.

Ahora bien, en el momento en que nosotros creemos expresamente un fichero robots.txt, WordPress dejará de generarlo y deberemos incluir las líneas anteriores nosotros mismos para que los rastreadores (honestos) no entren en la carpeta “/wp-admin/”.

Si, además, incluimos el sitemap, robots.txt quedaría así:

user-agent: *
disallow: /wp-admin/
allow: /wp-admin/admin-ajax.php

sitemap: www.mi-dominio.com/sitemaps.xml

Aunque no obligatorio, es una buena práctica incluir el fichero sitemaps. A través de la consola de búsqueda de Google podemos (y deberíamos) referenciarlo pero, al incluirlo en el robots.txt, nos aseguramos que los rastreadores de todos los buscadores lo localizarán, sin necesidad de entrar en sus respectivas consolas de búsqueda (o cómo las llamen cada buscador).

Sólo hay tres casos en los que añadiría restricciones a este fichero:

• • 1. Para restringir el acceso a carpetas que, con seguridad, tendrán contenido duplicado de las páginas del sitio web. Aún así, habría que valorar la utilización URL’s canónicas para estos casos, que sería lo más correcto, aunque para sitios webs muy grandes y bien estructurados puede ser más eficaz a través del robots.txt.
    2. Para restringir el acceso a carpetas caché que, por definición, tienen copias del contenido principal del sitio web. Sin embargo, debemos vigilar estas restricciones, pues algunos plugins pueden generar scripts o estilos CSS en la caché para optimizar el rendimiento de WordPress, pero los rastreadores no podrían parsearlos, lo que repercutiría en la evaluación de la experiencia de usuario.
    3. Para restringir el acceso a carpetas o ficheros cuyo contenido no queremos posicionar. Podría ser, por ejemplo, carpetas para descargas de documentos, vídeos, imágenes u otros recursos que no aportarían nada al posicionamiento orgánico de nuestro contenido principal, o que incluso podría interferir en este posicionamiento.

 

¿Qué no deberíamos incluir (nunca) en el robots.txt?

En este apartado voy a hacer un poco de abogado del diablo y desmontar los “mejores archivos robots.txt para WordPress” que se pueden encontrar a lo largo y ancho de Internet. No pongo ninguna referencia porque son muy parecidos (como cabía esperar) y tampoco quiero señalar a nadie.

Hay que reconocerles que, en efecto, hace unos años sí que eran los mejores archivos robots.txt pero que, ahora, con los nuevos avances tecnológicos en rastreo e indexación, han dejado de serlo.

He aquí una copia del código que puede encontrarse fácil y rápidamente en Google:

user-agent: *
disallow: /wp-login
disallow: /wp-admin
disallow: //wp-includes/
disallow: /*/trackback/
disallow: /*/attachment/
disallow: /author/
disallow: /*/page/
disallow: /*/feed/
disallow: /tag/*/page/
disallow: /tag/*/feed/
disallow: /page/
disallow: /comments/
disallow: /xmlrpc.php
disallow: /*?s=
disallow: /*/*/*/feed.xml
disallow: /?attachment_id*

Éstas son las líneas que ya no harían falta actualmente y el porqué:

disallow: /wp-login
# Ya hemos visto que esto no sirve para proteger este (sensible) recurso. En su lugar, deberíamos utilizar .htaccess.

disallow: //wp-includes/
# Puede afectar a la renderización de las páginas.

disallow: /*/trackback/
# Desde mi punto de vista, no tiene nada de malo incluir los enlaces backtrack.

disallow: /*/attachment/
# Tampoco veo nada malo en rastrear los attachments de los posts.

disallow: /author/, disallow: /*/page/, disallow: /*/feed/, disallow: /tag/*/page/, disallow: /tag/*/feed/, disallow: /page/
# Todas estas directivas son para no rastrear contenidos duplicados. Por ahí, bien, pero una mejor solución la proporciona el plugin Yoast SEO for WordPress, que añade metaetiquetas en las páginas correspondientes.

disallow: /comments/
# ¿Por qué es malo rastrear los comentarios? Pueden aportar contenido de calidad para nuestro posicionamiento orgánico.

disallow: /*/*/*/feed.xml
# No veo nada malo en rastrear y parsear este fichero, no veo posible que se confunda con contenido duplicado.

disallow: /?attachment_id*
# Puede ser necesario en algunos casos pero, a efectos prácticos, un WordPress bien configurado no tendría enlaces de este tipo.

Y éste sería el código que yo dejaría o añadiría (con algunos comentarios para explicar lo nuevo):

user-agent: *
# No aporta nada al posicionamiento orgánico:
disallow: /xmlrpc.php
disallow: /wp-admin
# Por si algún rastreador hiciera búsquedas (pueden producir contenido duplicado):
disallow: /*?s=
disallow: /wp-content/cache/
allow: /wp-admin/admin-ajax.php
# Las dos líneas siguientes sólo serían necesarias si decidieras bloquear la carpeta de algún plugin y asegurar que los rastreadores puedan seguir renderizando tus páginas:
allow: /*.css$
allow: /*.js$

sitemap: www.mi-dominio.com/sitemaps.xml

¡OJO! No estoy diciendo que éste sería el “mejor robots.txt” para WordPress, sino que sería la base mínima para empezar a configurar el mejor fichero robots.txt, añadiendo a partir de aquí lo necesario para adaptarlo a las características y necesidades específicas de ese sitio web en particular.

Y, para esta ampliación, sólo puede remitiros a las recomendaciones y plan de creación del fichero robots.txt que mencioné anteriormente.

Estoy convencido que muchos no estaréis de acuerdo con algunas de mis propuestas y recomendaciones. Os invito a comentarlo y, entre todos, conseguir la mejor solución 😉

¿Cómo sabemos si nuestro archivo robots.txt en WordPress es válido?

Afortunadamente, tenemos un recurso fácil y rápido para pasarle la “prueba del algodón” a nuestro archivo robots.txt: el informe de recursos bloqueados y el probador de robots.txt de la Search Console de Google. Otros buscadores tienen sus propios informes y “probadores” (¡qué raro suena esto! 😉 ), pero lo que veamos aquí se puede aplicar a ellos.

 

El informe de recursos bloqueados de Search Console

Este informe muestra las páginas que el rastreador de Google no ha sido capaz de renderizar debido a que algunos de los recursos (sean JavaScript, CSS o imágenes) utilizados en esa página están bloqueados por archivo robots.txt.

Como apunté en mi post sobre planificación de las tareas de seguimiento de Search Console, este informe deberíamos revisarlo quincenalmente, aunque si hacemos cambios en el robots.txt, podríamos consultarlo pasados unos pocos días (una semana debería ser suficiente) para asegurarnos que no hayamos bloqueado ningún recurso importante.

Como podéis ver en el siguiente informe, de mi propio sitio web, hace unos meses tuve algunos recursos bloqueados (estaba haciendo pruebas con robots.txt) y los fui eliminando:

Además del número de páginas con recursos bloqueados, el informe también incluye un listado con sus direcciones, sobre las que podemos pinchar para obtener más información con la que analizar y resolver la fuente del problema.

Y aquí es donde pasaríamos a utilizar el probador de robots.txt para comprobar las correcciones realizadas y asegurarnos que efectivamente resuelven el problema.

 

El probador de robots.txt de Search Console

Esta herramienta permite introducir la dirección de una página de nuestro sitio web y probarlo con los diversos rastreadores de Google; en general, salvo usos especializados, casi siempre utilizaremos el rastreador “Googlebot”:

Como podéis ver, el rastreador también nos muestra la versión del fichero robots.txt que tiene Google. Si lo acabáis de modificar, lo más probable es que sea diferente y tengáis que informar a Google que el fichero ha cambiado, pulsando en el botón “Enviar” de esta pantalla y entonces pulsar otra vez en el botón “Enviar” en la ventana que se abre (Google puede necesitar un tiempo para actualizar el archivo robots.txt en Search Console):

Pero no tenemos que esperar a que Google actualice su copia del robots.txt, podemos copiar directamente el código actualizado en el código de esta pantalla, pero tened en cuenta que el robots.txt en vuestro servidor seguirá siendo el que tuviera. Todo lo que cambiemos en el código de esta pantalla es temporal y solo tendrá validez a efectos de verificación.

Así, después de copiar nuestro código en el cuadro, pulsamos el botón “Probar” y entonces el probador nos informa si el rastreador tiene permitido o bloqueado el acceso a algún recurso de esa página. Por ejemplo, en la siguiente imagen podéis ver que he añadido una línea al robots.txt, bloqueándome una página (no hay riesgo, mi robots.txt no cambia) e indicándome que línea la está bloqueando:

Por tanto, con el informe de recursos bloqueados en la mano y utilizando el probador de robots.txt podemos refinar nuestra configuración hasta eliminar todos los recursos bloqueados y, entonces, podremos copiar el código resultante en el robots.txt de nuestro servidor e informar a Google que lo hemos actualizado (aunque Google lo renueva automáticamente al menos una vez al día).

Conclusiones

En torno al archivo robots.txt gira mucha confusión. No porque sea técnicamente complicado (no creo que haya una herramienta más sencilla en lo relacionado con el SEO), sino porque, por un lado, sus efectos no son inmediatos ni siempre fáciles de identificar; y, por otro, porque la evolución en la tecnología de rastreadores y algoritmos de búsqueda ha ido reduciendo la necesidad de utilizarlo.

Hasta tal punto ha evolucionado la tecnología de los buscadores que, para sitios webs pequeños y medianos, la mayoría de las veces no hace falta un archivo robots.txt, excepto el que el propio gestor de contenidos (sea WordPress, Drupal o cualquier otro) pueda generar por necesidades de su propia configuración.

Sin embargo, hay casos en que debemos analizar en profundidad nuestro sitio web, para asegurarnos que no estamos incurriendo en alguna penalización que pueda afectar al posicionamiento orgánico de nuestras páginas.

Por ejemplo, contenidos duplicados, caché de las páginas, contenidos generados por plugins, documentos o recursos que no aportan valor a nuestro sitio web… y un largo etcétera que dependerá tanto de nuestra estrategia de posicionamiento como de la propia estructura del sitio web.

Por este motivo, copiar un archivo robots.txt como “el mejor robots.txt para WordPress” puede ser una temeridad, porque puede ser perfecto para un sitio web pero desastroso para otro, aunque siendo parecidos visualmente.

En su lugar, debemos seguir una estrategia para configurar el archivo robots.txt: partir de un fichero básico de robots.txt, añadirle las restricciones y permisos que vayamos necesitando o detectando, y siempre tener el ojo puesto en las herramientas que Seach Console nos proporciona para detectar y subsanar cualquier bloqueo sobre recursos de nuestro sitio web.

? ¿Cuáles son los pasos y recomendaciones para crear y editar el archivo robots.txt en #WordPress? ? Clic para tuitear

Aunque la mayor eficacia e inteligencia de los algoritmos de búsqueda limitan la utilidad de los archivos robots.txt, aún podemos utilizarlos para guiar a los rastreadores a través de nuestro sitio web. ¿Tú qué opinas? ¿Qué debería y qué no debería tener el archivo robots.txt? ¿O deberíamos olvidarnos de él y dejarlo todo en manos de los rastreadores?

Imágenes: freepik, freeimages, elaboración propia.