Formalizamos 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 fundamentales de la Web. Permite que los propietarios de sitios web excluyan a los clientes automáticos, por ejemplo, a los rastreadores web, para que no puedan acceder a sus sitios de manera parcial o total.

En 1994, Martijn Koster (un webmaster) creó el estándar inicial después de notar que los rastreadores saturaban su sitio. Con más aportes de otros webmasters, nació el REP, y los motores de búsqueda lo adoptaron para ayudar a los propietarios de sitios web a administrar sus recursos de servidor con mayor facilidad.

Sin embargo, el REP nunca se convirtió en un estándar de Internet oficial, lo que significa que los desarrolladores interpretaron el protocolo de manera diferente a lo largo de los años. Además, desde su inicio, el REP no se actualizó para cubrir los casos excepcionales de hoy. Este es un problema desafiante para los propietarios de sitios web, ya que el estándar ambiguo de facto dificultaba la escritura correcta de las reglas.

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

El borrador de REP propuesto es un reflejo de más de 20 años de experiencia real en el uso de las reglas de robots.txt, que utilizan Googlebot y otros rastreadores importantes, así como cerca de 500 millones de sitios web que dependen del REP. Estos controles detallados permiten que el editor decida lo que desea rastrear en su sitio y posiblemente mostrárselo a los usuarios interesados. No cambia las reglas creadas en 1994, sino que define básicamente todas las situaciones indefinidas para el análisis y las coincidencias de robots.txt, y la extiende a 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 también se puede usar para FTP o CoAP.
  2. Los desarrolladores deben analizar al menos los primeros 500 kibibytes de un archivo robots.txt. Definir un tamaño de archivo máximo garantiza que las conexiones no se abran durante demasiado tiempo, lo que reduce la sobrecarga innecesaria de los servidores.
  3. El nuevo tiempo de almacenamiento máximo en caché de 24 horas o el valor de la directiva de caché (si está disponible) les brinda a los propietarios de sitios web la flexibilidad de actualizar su archivo 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 de control de caché para determinar el tiempo de almacenamiento en caché.
  4. La especificación ahora determina que, cuando un archivo robots.txt al que antes se podía acceder se vuelve inaccesible debido a fallas del servidor, las páginas no permitidas conocidas no se rastrean durante un período razonablemente largo.

Además, actualizamos el formulario Backus-Naur aumentado del borrador de Internet para definir mejor la sintaxis de robots.txt, que es fundamental para que los desarrolladores analicen las líneas.

RFC significa "solicitud de comentarios", y nos lo tomamos en serio: subimos el borrador a IETF para obtener comentarios de los desarrolladores que se preocupan por los componentes básicos de Internet. Mientras trabajamos para brindarles a los creadores web los controles que necesitan a fin de indicar cuánta información quieren poner a disposición de Googlebot y, por ende, calificar para aparecer en la Búsqueda, debemos asegurarnos de hacerlo bien.

Si quieres dejarnos un comentario, hacernos preguntas o simplemente pasar a saludar, puedes encontrarnos en Twitter y en nuestra Comunidad de webmasters, física y en línea.