Formalización de la especificación del Protocolo de Exclusión de Robots

Lunes, 1 de julio de 2019

Durante 25 años, el Protocolo de Exclusión de Robots (REP) ha sido uno de los componentes más básicos y críticos de la web. Permite a los propietarios de sitios web excluir a clientes automatizados, por ejemplo
rastreadores web, de
acceder a sus sitios, ya sea parcial o totalmente.

En 1994, Martijn Koster
(él mismo un webmaster) creó el estándar inicial después de que los rastreadores estuvieran abrumando su sitio. Con más aportes de otros webmasters, nació el REP, y fue adoptado por los motores de búsqueda para ayudar a los propietarios de sitios web a administrar sus recursos de servidores más fácilmente.

Sin embargo, el REP nunca se convirtió en un
estándar de Internet oficial, lo que significa
que los desarrolladores han interpretado el protocolo de manera algo diferente a lo largo de los años. Y desde su
creación, el REP no se ha actualizado para cubrir los casos extremos de hoy. Este es un
problema desafiante para los propietarios de sitios web porque el estándar de facto ambiguo dificultaba escribir
las reglas correctamente.

Queríamos ayudar a los propietarios de sitios web y desarrolladores a crear experiencias increíbles en Internet en lugar
de preocuparse por cómo controlar a los rastreadores. Junto con el autor original del protocolo,
webmasters y otros motores de búsqueda, hemos documentado cómo se usa el REP en la web moderna y
lo hemos enviado al IETF.

El borrador de REP propuesto refleja más de 20 años de experiencia en el mundo real confiando en las reglas de robots.txt, utilizadas tanto por Googlebot como por otros rastreadores importantes, así como por aproximadamente medio billón de sitios web que confían en el REP. Estos controles de grano fino dan al editor el poder de decidir qué les gustaría que se rastree en su sitio y posiblemente se muestre a los usuarios interesados. No cambia
las reglas creadas en 1994, sino que define esencialmente todos los escenarios indefinidos para el análisis y coincidencia de robots.txt, y lo extiende para la web moderna. En particular:

1. Cualquier
   protocolo de transferencia basado en URI
   puede usar robots.txt. Por ejemplo, ya no se limita a HTTP y se puede usar para FTP o
   CoAP
   también.
2. Los desarrolladores deben analizar al menos los primeros 500
   kibibytes de un robots.txt.
   Definir un tamaño máximo de archivo garantiza que las conexiones no estén abiertas por demasiado tiempo, aliviando
   la tensión innecesaria en los servidores.
3. Un nuevo tiempo máximo de caché de 24 horas o un valor de directiva de caché si está disponible, ofrece a los propietarios de sitios web la flexibilidad de actualizar su robots.txt cuando lo deseen, y los rastreadores no sobrecargan los sitios web con solicitudes de robots.txt. Por ejemplo, en el caso de HTTP, se podrían usar encabezados Cache-Control para determinar el tiempo de caché.
4. La especificación ahora establece que cuando un archivo robots.txt previamente accesible se vuelve inaccesible debido a fallas del servidor, las páginas no permitidas conocidas no se rastrean durante un período de tiempo razonablemente largo.

Además, hemos actualizado la
forma Backus-Naur aumentada
en el borrador de internet para definir mejor la sintaxis de robots.txt, lo cual es crítico para los desarrolladores para analizar las líneas.

RFC significa Request for Comments, y lo decimos en serio: subimos el borrador al IETF para obtener comentarios de los desarrolladores a quienes les importan los bloques de construcción básicos de internet. A medida que trabajamos para dar a los creadores web los controles que necesitan para decirnos cuánta información quieren poner a disposición de Googlebot y, por extensión, elegible para aparecer en la Búsqueda, tenemos que asegurarnos de hacerlo bien.

Si desea dejarnos un comentario, hacernos preguntas o simplemente saludar, puede encontrarnos en
Twitter y en nuestra
Comunidad de Webmasters, tanto fuera de línea como en línea.

Publicado por Henner Zeller,
Lizzi Sassman, y
Gary Illyes