Directivas de Robots.txt: Una Guía de Todas las Reglas Estándar y Ocultas

Resumen Ejecutivo

El archivo robots.txt (Protocolo de Exclusión de Robots, REP) es un mecanismo de larga data, basado en texto, para que los webmasters indiquen a los rastreadores automatizados qué partes de un sitio pueden o no ser accedidas. Fue propuesto por primera vez por Martijn Koster en julio de 1994 ^[1] y desde entonces se ha convertido en un estándar de facto. En 2022, fue estandarizado formalmente como RFC 9309 en la Pista de Estándares del IETF ^[2]. Robots.txt no es un mecanismo de control de acceso o seguridad; más bien, es una "solicitud" voluntaria a los rastreadores amigables (motores de búsqueda y otros bots) sobre las preferencias de rastreo ^[3]. Para 2021, aproximadamente el 81.9% de los sitios web indexados tenían un archivo robots.txt ^[4], lo que refleja su ubicuidad.

Este informe proporciona un examen en profundidad de todas las directivas y parámetros conocidos en robots.txt, incluyendo los oscuros y específicos de motores de búsqueda. Cubrimos el núcleo estándar (por ejemplo, User-agent, Disallow, Allow) y la sintaxis de patrones (comodines, $ fin de línea), así como extensiones como los enlaces Sitemap:. Luego detallamos directivas no estándar o menos conocidas – por ejemplo, Crawl-delay, Clean-param y Host de Yandex, Request-rate/Visit-time de Seznam, y reglas históricas de noindex – incluyendo qué rastreadores de búsqueda principales las soportan. A lo largo del informe, las afirmaciones están respaldadas por documentación oficial, análisis de expertos y estudios de casos del mundo real. Por ejemplo, la guía de Google Search Central confirma que las reglas de robots como "noindex" (en robots.txt) no son compatibles ^[5], y que las páginas bloqueadas por robots aún pueden ser indexadas si se enlazan desde otro lugar ^[6] (e incluso aparecer en los resultados de Google con fragmentos ^[6]). Yandex documenta sus características únicas como Clean-param (para ignorar parámetros de consulta) ^[7], mientras que los ingenieros de Bing han señalado que Bing nunca respetó una directiva noindex en robots.txt ^[8].

También analizamos las tendencias de uso (por ejemplo, tabla de soporte de directivas de motores de búsqueda) e incidentes reales. Por ejemplo, un estudio de caso de SEO informó cómo las reglas de robots configuradas por el host (añadidas sin el conocimiento del webmaster) desautorizaron inadvertidamente secciones clave del sitio con el tiempo – las páginas afectadas cayeron lentamente del índice de Google ^[9]. Desde el punto de vista de la seguridad, los investigadores advierten que incluir rutas sensibles (como /admin/, /backup/, /debug/) en robots.txt en realidad pone un objetivo para los atacantes ^{[10] [11]}. Basándose en datos (por ejemplo, del Almanaque SEO de HTTP Archive de 2021 ^[4]) y blogs de motores de búsqueda ^{[12] [13]}, el informe concluye con implicaciones para los webmasters (mejores prácticas, fiabilidad del rastreo) y direcciones futuras (el potencial de extender el REP con nuevas reglas de consenso).

Introducción y Antecedentes

El Protocolo de Exclusión de Robots (REP) es el estándar original de control de rastreadores de la web. Comenzó como un simple archivo /robots.txt en la raíz de un sitio, leído por bots de indexación, indicando qué URLs desautorizar o autorizar. Martijn Koster introdujo la idea por primera vez en la lista de correo www-talk del W3C en julio de 1994 ^[1]; famosamente, lo necesitó después de que su sitio fuera atacado por DOS por un rastreador agresivo. Durante las décadas siguientes, el REP siguió siendo un estándar de facto informal utilizado por prácticamente todos los principales motores de búsqueda. A pesar de su antigüedad, el REP persistió con pocos cambios: para 2025 "apenas había tenido que evolucionar" — Google señala que la única extensión universalmente compatible que obtuvo fue la directiva Allow ^[13].

En septiembre de 2022, el IETF formalizó estas prácticas como RFC 9309 (Source: blog.seznam.cz). Este documento codifica el lenguaje REP y las reglas de procesamiento en la Pista de Estándares de Internet ^[2]. La RFC reconoce la especificación original de 1994 de Koster ^[14] y aclara cómo los rastreadores deben analizar y almacenar en caché robots.txt, manejar redirecciones, errores y leer las reglas de User-agent, Allow, Disallow ^{[15] [16]}. Es importante destacar que la RFC establece explícitamente que las directivas de robots no son un esquema de autorización – si se lista una ruta en robots.txt, es abiertamente explorable para cualquier humano o bot adversario, por lo que la seguridad real debe usar un control de acceso adecuado (por ejemplo, autenticación HTTP) ^[17].

En la práctica, los archivos robots.txt utilizan una gramática sencilla. Consisten en uno o más "grupos" (bloques), cada uno comenzando con una o más líneas User-agent:, seguidas de reglas coincidentes. Por ejemplo:

User-agent: *
Disallow: /private/
Allow: /private/special/
Sitemap: https://example.com/sitemap.xml

Esto significa "para todos los rastreadores, desautorizar /private/ excepto autorizar /private/special/. Además, aquí está nuestro sitemap." En el Grupo 1, la ruta vacía después de Disallow: implica permitir todo. Cada regla es un par clave-valor separado por dos puntos. La clave puede ser Allow: o Disallow:, seguida de un patrón de ruta URL. La sintaxis REP (según RFC 9309) especifica que para un grupo coincidente, la regla más específica (la coincidencia de ruta más larga) tiene precedencia, y en caso de empate, un Allow supera a un Disallow ^[18]. Las reglas distinguen entre mayúsculas y minúsculas en la ruta URL – por ejemplo, Disallow: /Example/ no bloqueará /example/ ^[19]. Si ninguna regla coincide con un rastreador o URL dado, el rastreo está implícitamente permitido (el valor predeterminado es abierto) ^{[18] [20]}.

Desde los primeros días de Internet, el paradigma ha sido que los rastreadores amigables deben obedecer estas directivas. Google, Bing, Yandex y otros han construido sus bots para respetar las reglas estándar y muchas extensiones comunes. Sin embargo, esta naturaleza voluntaria significa que cada rastreador puede elegir qué directivas soportar. Como veremos, algunas directivas (como Crawl-delay o Clean-param) son respetadas por solo unos pocos motores, y otras (como una línea Noindex en robots) son ignoradas por los principales rastreadores ^{[5] [8]}. Las siguientes secciones detallan la sintaxis, el soporte oficial y muchos parámetros "ocultos" o menos conocidos utilizados en los archivos robots.txt actuales.

Sintaxis y Directivas Principales de robots.txt

Directivas Estándar: User-agent, Disallow, Allow

Las directivas fundamentales en un archivo robots.txt son User-agent (identificando el rastreador objetivo) y Disallow (bloqueando rutas). RFC 9309 formaliza esta sintaxis base: cada regla es Allow: o Disallow:, cada una seguida de un patrón de ruta ^[21]. Un grupo de reglas se aplica a las líneas User-agent precedentes ^[22]. Por ejemplo:

User-agent: Googlebot
Disallow: /admin/
Allow: /admin/help/

Esto le dice a Googlebot que no puede rastrear /admin/ excepto que puede rastrear /admin/help/. La palabra clave * se usa para coincidir con todos los rastreadores (por ejemplo, User-agent: *) ^[23]. Por convención, un Disallow: en blanco (sin ruta) significa permitir todo (sin restricciones). Si ninguna regla coincide, el contenido es rastreable por defecto ^[18].

Los rastreadores coinciden con la regla más larga: si múltiples directivas coinciden con una URL, la que tiene la cadena de ruta más larga gana. Si un Allow y un Disallow son exactamente iguales en longitud, Allow tiene precedencia ^[18]. Las mayúsculas y minúsculas importan: la coincidencia de rutas distingue entre mayúsculas y minúsculas ^[19]. (En la práctica, dado que los nombres de dominio pueden no distinguir entre mayúsculas y minúsculas, la RFC aconseja usar punycode o conversión UTF-8, pero esos detalles afectan principalmente a la localización ^[24]).

La mayoría de los motores de búsqueda soportan la directiva Allow hoy en día ^[25]. Por ejemplo, la documentación para webmasters de Yandex lista explícitamente Allow junto con Disallow como una directiva que permite el rastreo ^[26]. Google también usa reglas Allow: para crear excepciones en un árbol de Disallow ^{[25] [12]}. (Originalmente, Allow era una extensión no oficial de Google introducida en la década de 1990; ahora es ubicua).

Otra directiva común es Sitemap: que le dice al rastreador dónde encontrar el/los sitemap(s) XML del sitio. Aunque no forma parte del REP original, es "un estándar adicional" reconocido por Google, Bing, Yandex y otros ^[12]. En el ejemplo anterior, Sitemap: https://example.com/sitemap.xml dirige a los rastreadores a la URL del sitemap. Google, de hecho, fomenta la colocación de sitemaps en robots.txt (y lo ha hecho rastreable a través de esta regla) ^[27]. Todos los principales motores de búsqueda respetan la línea Sitemap: por conveniencia aunque esté fuera de la gramática formal de la RFC ^[28].

Patrones y Comodines

Los rastreadores modernos también soportan la coincidencia de patrones simples en las rutas. Los más utilizados son el comodín * (coincide con cualquier secuencia de caracteres) y el ancla $ (coincide con el final de la URL). Por ejemplo, Disallow: /*.pdf$ significa "desautorizar todas las URLs que terminan en .pdf". El representante de Google ha permitido durante mucho tiempo * y $ en los patrones de Disallow (su analizador de código abierto y su documentación soportan esta sintaxis) ^{[25] [12]}. Yandex también acepta estos comodines. Según la ayuda de Baidu, su Baiduspider soporta tanto "* como $" para la coincidencia de URLs ^[29]. En la práctica, muchos sitios explotan esta capacidad para bloquear tipos de archivos completos o parámetros de consulta de URL. (Por ejemplo, Disallow: /*?* bloqueará cualquier URL que contenga "?"). Se aplica un proceso de coincidencia detallado: una vez que un rastreador recopila todas las reglas Disallow y Allow para su user-agent, encuentra la regla con el prefijo coincidente más específico (más largo); si esa regla es Allow, la URL puede ser rastreada, y si es Disallow, la URL es bloqueada ^[18].

Sensibilidad a Mayúsculas y Minúsculas y Normalización

Las directivas coinciden con las rutas URL textualmente. Eso significa que las mayúsculas y minúsculas importan y la cadena exacta debe coincidir desde el primer carácter. Por ejemplo, una directiva Disallow: /Category/ bloqueará URLs como /Category/Item1 pero no /category/item1 – la falta de coincidencia entre mayúsculas y minúsculas significa que la segunda URL no es detectada ^[19]. De manera similar, el analizador de robots decodifica los caracteres codificados por porcentaje antes de la coincidencia ^[30]. Sin embargo, tenga en cuenta que aunque la coincidencia de rutas en las reglas distingue entre mayúsculas y minúsculas, la mayoría de los rastreadores tratan los nombres de User-agent: y de las directivas (User-agent, Allow, etc.) como palabras clave que no distinguen entre mayúsculas y minúsculas ^[31]. En resumen, las reglas de robots.txt siguen una coincidencia de cadena precisa en la parte de la ruta de las URLs, por lo que se debe tener en cuenta la normalización de URL y las mayúsculas y minúsculas al escribir las reglas.

Directivas Extendidas y Menos Conocidas

Más allá de la gramática básica, han aparecido una serie de directivas no estándar. Estas no forman parte del REP original de 1994, pero muchas son soportadas en la práctica por rastreadores particulares.

• Allow: Ya cubrimos Allow: como una extensión para anular las desautorizaciones. Su soporte ha crecido hasta convertirse efectivamente en un estándar en todos los principales motores ^[25]. El analizador de robots de Google asegura que las reglas Allow sean respetadas, y si una regla Allow y una Disallow coinciden con una URL, Google usa la ruta más larga (a menudo la Allow si es más larga) ^[18].

• Crawl-delay: Esta directiva fue inventada para regular la velocidad de rastreo (pocas páginas por segundo). No forma parte de la gramática oficial del REP【26†】, pero algunos motores la utilizan. Yandex soporta Crawl-delay en robots.txt, por ejemplo, Crawl-delay: 10 para esperar 10 segundos entre recuperaciones ^[32]. Bing también respeta Crawl-delay. Google no soporta una directiva crawl-delay en robots.txt: como explicó Matt Cutts de Google, muchos webmasters la configuran incorrectamente (por ejemplo, la establecen en 100,000) causando efectivamente ningún rastreo ^[33]. En su lugar, Google ofrece controles de velocidad de rastreo en Search Console (e internamente gobierna el rastreo con configuraciones de "carga del host") ^[34]. Por lo tanto, si escribe Crawl-delay en robots.txt, solo Yandex, Bing (y quizás algunos rastreadores personalizados) lo tendrán en cuenta, no Google.

• Host específico del motor de búsqueda: Originalmente, Yandex introdujo una directiva Host: para permitir a los webmasters declarar el dominio preferido del sitio entre los espejos. Por ejemplo, si un sitio es accesible tanto como example.com como example.net, Yandex tomaría la primera línea Host: como el host canónico ^[35]. En la práctica, solo Yandex reconocía Host:. Sin embargo, a partir de marzo de 2018, Yandex eliminó el soporte para Host:, aconsejando en su lugar usar redirecciones (Source: robotstxt.ru). (Cualquier línea Host: después de la primera es ignorada ^[35].) Otros motores de búsqueda ignoran esta directiva por completo.

• Clean-param de Yandex: Yandex soporta una directiva inusual Clean-param: p0[&p1&p2...] [path] para canonicizar URLs eliminando parámetros de consulta irrelevantes ^[7]. Por ejemplo, para colapsar parámetros de seguimiento, se podría escribir:

  User-agent: Yandex
  Clean-param: ref /some_dir/get_book.pl
  

  Esto le dice a Yandex que las URLs del tipo /some_dir/get_book.pl?ref=XYZ&book_id=123 deben ser tratadas como si solo book_id=123 fuera relevante, es decir, ignorar todos los valores de ref= ^[7]. Yandex entonces indexará solo una URL canónica (get_book.pl?book_id=123) en lugar de duplicados. Esta directiva es exclusiva de Yandex (Google, Bing, etc. no soportan Clean-param), y su sintaxis puede aceptar múltiples parámetros e incluso comodines de ruta ^[7].

• Noindex y Nofollow (en robots.txt): Al principio, algunos propietarios de sitios (e incluso algunas discusiones de Google) consideraron añadir Noindex: /somepage dentro de robots.txt para evitar la indexación. Sin embargo, Google se ha negado durante mucho tiempo a respetar Noindex en robots.txt. En un blog de 2019, Gary Illyes (Google) desaconsejó el uso de cualquier regla noindex, nofollow o crawl-delay en robots.txt, afirmando: "estamos retirando todo el código que maneja reglas no soportadas y no publicadas (como noindex)" ^[5]. De hecho, Google dice explícitamente que no garantiza que bloquear una URL en robots.txt la mantendrá fuera de los resultados de búsqueda ^{[5] [6]}. (Las páginas no permitidas por robots aún pueden clasificarse si están enlazadas en otros lugares; Google simplemente puede mostrar un fragmento de marcador de posición.) De manera similar, el equipo de Bing señaló que la "directiva noindex no documentada nunca funcionó para Bing" ^[8]. En resumen, ningún motor de búsqueda moderno importante soporta una regla <Noindex> en robots.txt. Para eliminar páginas de Google, se debe usar una <meta name="robots" content="noindex"> en la página o enviar una respuesta 404/410 ^{[5] [8]}. (El único “nofollow” relevante para robots.txt es Disallow, que impide que el rastreador siga los enlaces, pero esto tampoco detiene la indexación si otros sitios enlazan a ella.)

• Otras extensiones propuestas: A lo largo de los años, se han sugerido o adoptado varias otras directivas por rastreadores de nicho. Por ejemplo, el borrador de Conman.org (década de 2000) definía Request-rate: y Visit-time:. SeznamBot (un popular motor de búsqueda checo) implementa estas: por ejemplo, Request-rate: 10/1m limita el rastreo a 10 páginas por minuto, posiblemente con ventanas de tiempo adicionales (como 1500-0559) (Source: blog.seznam.cz). El Visit-time del borrador podría sugerir horas de rastreo preferidas. Estas no son reconocidas por Google, Bing, Yandex o la mayoría de los sitios fuera de Seznam. Mat Cutts bromeó que el equipo de IBM podría definir líneas unicorns: allowed si quisieran extender el protocolo ^[36]. El punto clave es que los rastreadores son libres de implementar directivas propietarias: el protocolo es extensible. Por ejemplo, el propio analizador de código abierto de Google fue demostrado con un manejador Sitemap: para validar el soporte de reglas personalizadas ^[36]. El blog de Google de 2025 "REP a prueba de futuro" reconoce explícitamente que tales reglas personalizadas (como clean-param, crawl-delay) están fuera del nuevo RFC pero aún son soportadas por algunos motores (aunque notablemente no por Google Search para esas específicas) ^[28].

La siguiente tabla resume las directivas de robots.txt comunes (superiores) y poco comunes, y qué motores de búsqueda principales las soportan actualmente:

Tabla: Directivas clave de robots.txt y soporte por los principales motores de búsqueda. “✓” indica soporte. Un espacio en blanco “–” significa que no hay soporte. Yandex históricamente aceptó Host: y Clean-param:; Google/Bing no lo hacen. Tanto Google como Bing ignoran cualquier Noindex: en robots.txt` ^{[5] [8]}. (Fuentes: Documentación oficial de Google, Yandex, conocimiento de la comunidad.)

Comportamientos Específicos de los Motores de Búsqueda

Diferentes rastreadores interpretan las reglas de robots de manera ligeramente distinta. Esta sección destaca los comportamientos de los principales motores de búsqueda (Google, Bing, Yandex, Baidu, etc.) y cómo tratan robots.txt.

• Google (y Googlebot): Googlebot sigue completamente la porción "estándar" del REP. Reconoce User-agent, Disallow, Allow, Sitemap y comodines. Google no implementa Crawl-delay o Request-rate; en su lugar, utiliza controles de rastreo centralizados. Google también ignora cualquier línea no soportada como Noindex: en robots.txt ^[5]. Es importante destacar que Google seguirá indexando (sin contenido) las URLs que están prohibidas. Como señala una guía de SEO, "Ninguna URL está completamente bloqueada de los motores de búsqueda si la prohíbes en robots.txt" ^[6]. La documentación de Google también dice que "no garantiza" que las páginas prohibidas no terminen indexadas. En la práctica, Google puede mostrar una entrada en los resultados para una URL prohibida (a menudo etiquetada como "No verificada" o sin fragmento) si encuentra enlaces a ella ^[6]. Las características más recientes de Google incluso permiten que las páginas prohibidas sean citadas en resúmenes de IA con fragmentos ^[37]. Después de 2019, Google deshabilitó formalmente el análisis de noindex en robots (y cualquier regla no publicada como nofollow) ^[5], alineándose con la postura de Bing ^[8]. En 2019, Google liberó el código de su analizador de robots.txt como código abierto y publicó un borrador de Internet (propuesta pre-RFC) mostrando cómo se podrían añadir nuevas reglas ^[36]. El blog oficial de Google ("REP a prueba de futuro") señala que en más de 25 años, el único cambio universalmente adoptado fue la adición de Allow ^[13]; otras extensiones (como sitemap:) se hicieron comunes fuera del RFC.

• Bing y Yahoo: Dado que Yahoo Search ahora utiliza el rastreador de Bing ("Bingbot"), su uso de robots es idéntico. Bing soporta User-agent, Disallow, Allow, Sitemap y (oficiosamente) Crawl-delay. Bing requiere que si especificas una sección con nombre para Bingbot:, debes repetir allí cualquier regla general. Como informó SearchLand, "Si creas una sección específicamente para Bingbot, todas las directivas predeterminadas serán ignoradas... Debes copiar y pegar las directivas que quieres que Bingbot siga bajo su propia sección" ^[38]. Frédéric Dubut, desarrollador senior de Bing, confirmó que nunca reconoció noindex en robots.txt, por lo que las páginas deben usar meta etiquetas o encabezados para eliminarlas del índice de Bing ^[8]. Por lo demás, el comportamiento de Bing es similar al de Google: las páginas no permitidas aún pueden indexarse si están enlazadas, y Bing reserva sus propios controles de caché en las Herramientas para webmasters.

• Yandex: Yandexbot respeta el REP estándar más sus extensiones propietarias. Su documentación enumera Allow, Disallow, Crawl-delay, además de Sitemap y Clean-param ^[26]. Yandex utiliza Clean-param: para optimizar el rastreo de URLs dinámicas (ver ejemplo anterior ^[7]). Su Crawl-delay se expresa en segundos (por ejemplo, Crawl-delay: 10) ^[32]. Hasta 2018, Yandex también leía una directiva Host: para el dominio canónico, pero ahora está descontinuada (Source: robotstxt.ru). Notablemente, Yandex trata las páginas no permitidas de manera similar a Google: aún pueden ser indexadas, pero Yandex no puede ver su contenido y, por lo tanto, no puede respetar ningún noindex HTML en ellas. (Por lo tanto, Yandex advierte a los webmasters que usen meta noindex en lugar de robots para ocultar contenido ^[39].) Al igual que Google, Yandex considera que las reglas de robots son sensibles a mayúsculas y minúsculas.

• Baidu (el principal motor de búsqueda de China): Los bots de Baidu (por ejemplo, "Baiduspider") soportan User-agent, Disallow, Allow y Sitemap. Baidu soporta explícitamente los patrones comodín * y de fin de línea $ ^[29] (su propia documentación afirma que "Baiduspider soporta los caracteres comodín * y $"). Baidu no tiene un argumento Crawl-delay público en robots.txt; en su lugar, los webmasters chinos ajustan la tasa de rastreo a través de las Herramientas para webmasters de Baidu. Baidu también señala que las páginas bloqueadas por robots aún pueden aparecer en los resultados de búsqueda a través de enlaces de otros sitios ^[40]; así que, de nuevo, Disallow es una directiva para controlar el rastreo, no un método infalible de no indexación. En la práctica, <User-agent: Baiduspider> aparece en aproximadamente el 1,9% de los sitios (según las Estadísticas de Rastreo ^[41]).

• Otros rastreadores: Existen innumerables bots menores (como mj12bot de Majestic, Ahrefs, etc.) que simplemente obedecen el REP como Google. El informe SEO de HTTP Archive de 2021 señaló que los user-agents específicos más comunes encontrados (después de Google, Bing, Baidu, Yandex) incluían Majestic (mj12bot, 3,3% de escritorio) y Ahrefs (ahrefsbot, 3,3% de escritorio) ^[42]. Ninguno de estos bots introduce nuevas directivas únicas más allá de lo que hacen los principales motores.

Tendencias y Estadísticas de Datos

Para entender el uso real de robots.txt, podemos basarnos en datos de rastreo web. Según el capítulo SEO del Archivo HTTP de 2021 ^[4], el 81.9% de los sitios web utilizan un archivo robots.txt en su dominio principal (un ligero aumento desde aproximadamente el 72% en 2019). Por el contrario, alrededor del 16.5% de los sitios no tienen robots.txt, en cuyo caso Google trata todas las páginas como rastreables ^[4]. El ~1.6% restante o bien devolvió errores o no fue accesible. Es importante destacar que si la obtención de un robots.txt falla con un HTTP 5xx (error del servidor), la política de Google (según RFC 9309) es tratar el sitio como "inaccesible" y suspender temporalmente el rastreo ^{[43] [44]}. Si falla con un 4xx o 403, Google puede tratar el archivo como "no disponible" y permitir el rastreo por defecto ^[43]. En la práctica, el Archivo encontró que aproximadamente el 0.3% de los sitios devolvieron 403/5xx para robots.txt, y el equipo de Google estimó que hasta el 5% tuvo errores 5xx transitorios y el 26% estuvo inaccesible en ocasiones ^[44]. Incluso los problemas temporales con robots.txt pueden detener un rastreador: en una encuesta, Google dijo que dejará de rastrear un sitio por un tiempo si su robots.txt devuelve errores, ya que "no está seguro de si una página determinada puede o no ser rastreada" ^[44].

En cuanto al tamaño del archivo, la mayoría de los robots.txt son bastante pequeños (<100 KiB). El análisis del Archivo HTTP muestra que solo ~3,000 dominios excedieron los 500 KiB, el máximo documentado por Google, lo que significa que en esos archivos extragrandes, cualquier regla más allá de los 500 KiB simplemente sería ignorada ^[45]. Además del tamaño, también hay consideraciones de codificación de archivos (RFC 9309 requiere UTF-8) y un límite de 500 KB para el analizador para evitar la sobrecarga ^{[24] [46]}. Los archivos muy grandes o mal formados, por lo tanto, corren el riesgo de no ser analizados completamente.

Otra estadística útil es con qué frecuencia se mencionan agentes de usuario específicos. La Figura 8.6 del Web Almanac muestra que "Googlebot" aparece en aproximadamente el 3.3-3.4% de las reglas de robots.txt, Bingbot en ~2.5–3.4%, Baiduspider ~1.9%, Yandexbot ~0.5% ^[41]. (Estos porcentajes corresponden a todos los archivos robots.txt rastreados). Esto indica que Google y Bing son objetivo explícito de un pequeño porcentaje de sitios, mientras que Majestic y Ahrefs también aparecen (aproximadamente un 3% cada uno). Esto refleja la práctica de las herramientas SEO de colocar sus propias instrucciones de rastreo.

Finalmente, el uso de directivas extendidas es relativamente raro en la web. Por ejemplo, contrastemos Clean-param de Yandex con su uso generalizado: prácticamente el 100% de las reglas de robots dirigidas a Yandex lo usan cuando está presente, pero aparece solo en un pequeño porcentaje de todos los sitios a nivel mundial (ya que solo los sitios indexados por Yandex lo usarían). De manera similar, muy pocos sitios listan Host: ahora (ya que Yandex lo eliminó) o Request-rate de Seznam. Este informe se ha centrado en la exhaustividad más que en la prevalencia, por lo que cubrimos completamente incluso estos casos más raros.

Estudios de Caso y Ejemplos del Mundo Real

Errores de SEO: Un ejemplo clásico del impacto de robots.txt es el estudio de caso de Glenn Gabe en Search Engine Land ^[9]. Un cliente se dio cuenta de que páginas clave de categorías estaban desapareciendo misteriosamente de Google. Tras la investigación, Gabe encontró dos culpables: (1) el proveedor del CMS había estado añadiendo programáticamente nuevas directivas robots.txt con el tiempo sin el conocimiento del propietario del sitio, y (2) algunas directivas de denegación usaban la capitalización incorrecta (por ejemplo, /CATEGORY/ en lugar de /Category/). Dado que la coincidencia de robots.txt distingue entre mayúsculas y minúsculas, esas directivas bloquearon páginas accidentalmente. El resultado fue una "fuga lenta" de URLs importantes del índice de Google ^[9]. El análisis de Gabe destaca el peligro de incluso pequeños cambios en robots. Subraya que los webmasters deben monitorear las ediciones de robots.txt (algunos usan alertas o control de versiones) y auditar rutinariamente qué URLs importantes podrían estar siendo bloqueadas (herramientas como Screaming Frog o el probador de robots de Search Console pueden ayudar) ^{[9] [47]}. Usar la Wayback Machine del Internet Archive para verificar versiones históricas de robots.txt también puede identificar cuándo se añadió una directiva dañina ^[47].

Riesgo de Seguridad/Honeypots: Más allá del SEO, los archivos robots.txt han atraído la atención de investigadores de seguridad e incluso hackers. Un probador de penetración en 2015 analizó cientos de miles de robots.txt en la web y encontró que a menudo exponen "mapas del tesoro" a los atacantes ^[10]. Si un archivo robots deniega directorios como /admin/, /staging/ o /backup/, esencialmente anuncia que estas áreas sensibles existen. Por ejemplo, Weksteen (un investigador de seguridad) informó haber encontrado muchos portales de administración e inicio de sesión simplemente extrayendo rutas denegadas en robots.txt ^[48]. Sus hallazgos incluyen casos reales: miles de sitios gubernamentales y académicos tenían entradas "/disallow" que apuntaban a archivos PDF confidenciales y datos de personal, a los que los atacantes accedieron posteriormente a través de la búsqueda. Como resume The Register, “la mención de un directorio en un archivo robots.txt grita que el propietario tiene algo que quiere ocultar” ^[48]. Incluso los sitios conocidos no son inmunes: cita casos en los que nombres de expedientes de víctimas de trata fueron expuestos inadvertidamente a través de descripciones de imágenes en listas de denegación.

De manera similar, los expertos en seguridad aconsejan ampliamente: no confíe en robots.txt para proteger contenido secreto. Las guías de hacking ético enfatizan que publicar nombres de archivos o directorios sensibles en robots.txt es contraproducente; crea una "superficie de ataque no intencional" ^[49]. De hecho, algunos administradores configuran honeypots listando rutas denegadas falsas y atractivas (por ejemplo, /admin/please_dont_hack/) y luego monitoreando cualquier acceso a esas rutas. La conclusión es que robots.txt es público: todo ser humano y bot malicioso puede leerlo. Una sección que restringe una ruta significa que esa ruta existe y es importante; los atacantes la sondearán en consecuencia ^{[49] [50]}.

Bloqueo vs Indexación: Otra preocupación práctica implica los diferentes comportamientos de "bloqueado" vs "indexado". Search Console introdujo nuevos mensajes de estado como "Indexada, aunque bloqueada por robots.txt", lo que confunde a muchos SEOs. Como explica un artículo de SearchEngineLand de febrero de 2025 ^[51], "Bloqueada por robots.txt" no significa "nunca aparecerá en los resultados de búsqueda". Google afirma explícitamente que una página denegada aún puede ser indexada (a menudo utilizando su URL y el texto de enlaces externos), aunque Googlebot no recuperará su contenido ^[6]. De hecho, las páginas pueden incluso aparecer en funciones especiales; Lily Ray observó una URL de Goodreads listada en los resúmenes de IA de Google a pesar de estar bloqueada por robots ^[37]. El consenso de la comunidad se resume: "Ninguna URL está completamente bloqueada de los motores de búsqueda si la deniegas en robots.txt" ^[6]. Corregir una denegación accidental generalmente implica eliminar la directiva y volver a solicitar la indexación a través de herramientas (o simplemente esperar un nuevo rastreo) ^[52].

Caso: Operaciones de Rastreo Grandes: Proyectos públicos como el Internet Archive confían en robots.txt para respetar las exclusiones de sitios. Los rastreadores del Archivo analizan robots.txt y obedecen Disallow (como lo hacen prácticamente todos los bots buenos). Sin embargo, diferentes organizaciones han optado por interpretar algunos códigos de estado de manera diferente. Por ejemplo, las notas de ingeniería del Internet Archive indican que, por defecto, un robots.txt faltante se trata como "permitir todo", mientras que un cierto patrón de redirecciones o 401/403 podría tratarse como "permiso total" (es decir, indexable) ^[17]. Google, por otro lado, trata los 401/403 de manera diferente (los considera analizables como "permitir todo") ^[17]. Tales matices implican que los resultados del rastreo pueden variar ligeramente entre instituciones.

Análisis y Discusión

Profundidad de las Extensiones vs. Uso Práctico. En los más de 25 años de existencia de robots, muy pocas reglas nuevas han logrado la adopción universal de las directivas principales. Los ingenieros de Google señalan que, aparte de Allow, la única otra "extensión" que casi todos los bots principales entienden es Sitemap: ^[13]. Todas las demás características siguen siendo específicas del motor o opcionales. Por ejemplo, tanto Google como Yandex ignoran silenciosamente cualquier directiva noindex o nofollow colocada en robots.txt ^{[5] [8]} – tales líneas simplemente no tienen efecto. De manera similar, mientras que Crawl-delay es ampliamente reconocido por Bing y Yandex, Google elige intencionalmente no soportarlo ^[33].

Algunas extensiones propuestas en el pasado aún persisten en usos de nicho. "Request-rate" y "Visit-time" de Seznam muestran que la planificación de horarios complejos para bots es posible si tanto el rastreador como el webmaster están de acuerdo. El equipo de robótica de Google fomenta la participación de la comunidad: el artículo "REP a prueba de futuro" invita explícitamente a los webmasters a proponer nuevas directivas (con consenso) a través de canales abiertos ^{[28] [53]}. Nos recuerda que la simplicidad y ubicuidad de robots.txt lo convierten en un candidato para nuevas reglas, pero solo si son ampliamente beneficiosas. La historia de la adopción de sitemap: como regla (una vez obtenida por colaboración de SEOs y motores de búsqueda) se presenta como un modelo ^[54]. Por el contrario, advierten que los cambios unilaterales no se convertirán en estándar; se necesita colaboración.

Implicaciones para Webmasters y SEO. Para los profesionales, los "secretos" de robots.txt se refieren principalmente a comprender cómo se comporta cada bot y a realizar pruebas adecuadas. Asuma siempre que Google (y Bing) ignorarán cualquier significado privado u oculto en su archivo robots. Nunca coloque contraseñas reales, claves o puntos finales altamente secretos en robots.txt. Úselo solo para cortar rutas de rastreo de bajo valor (páginas duplicadas, áreas de staging/prueba, etc.), no para ocultar contenido. Pruebe sus reglas en herramientas: el Probador de robots de Google Search Console (si está verificado) y validadores de terceros, para asegurarse de que la sintaxis sea correcta. Monitoree los cambios en el uso de su robots.txt (la wayback machine o alertas); como muestra el caso de Gabe, los cambios inesperados pueden arruinar silenciosamente el SEO. Mantenga el archivo ligero para evitar límites de tamaño; comprima múltiples denegaciones en una especificación de ruta cuando sea posible.

Perspectivas Futuras. Con el REP ahora oficialmente estandarizado, la mayoría de las "brechas del protocolo" son conocidas. Los rastreadores muestran interés en evolucionar robots.txt (por ejemplo, el borrador de la IETF, analizadores de código abierto), pero cualquier cambio será lento dada la necesidad de compatibilidad con versiones anteriores y un amplio soporte. La perspectiva de Google para 2025 es que robots.txt puede incluir nuevas preferencias de rastreo, pero solo a través de un cuidadoso consenso de la comunidad ^[53]. A medida que surgen la IA y nuevas modalidades de búsqueda, controlar lo que un bot puede ver sigue siendo crucial (robots.txt es la primera línea de comunicación). Sin embargo, irónicamente, las especificaciones enfatizan que el control sensible debe pasar a mecanismos más seguros (por ejemplo, metaetiquetas, configuraciones de servidor) ^[17]. El REP probablemente seguirá siendo una pieza importante, aunque limitada, del ecosistema de indexación. Las pistas del futuro incluyen un mejor análisis (Google de código abierto su analizador ^[36]) y directivas nuevas y potencialmente flexibles – pero por ahora, los webmasters deben dominar las existentes, sabiendo que no hay "otros secretos sobre robots.txt" más allá de estas reglas ^[55].

Tablas

Tabla: Soporte de características de los principales rastreadores de motores de búsqueda. Las marcas de verificación provienen de la documentación oficial y blogs mencionados anteriormente. Google y Bing no reconocen una directiva noindex en robots.txt ^{[5] [8]} (use metaetiquetas o encabezados HTTP en su lugar).

Tabla: Desglose de la frecuencia con la que se nombran bots específicos en robots.txt (el uso en escritorio vs. móvil es similar) ^[41]. Aparte de * (utilizado en todos los archivos), los bots de Google y Bing son referenciados explícitamente solo por un pequeño porcentaje de sitios. Cabe destacar que algunos bots de herramientas SEO (Majestic, Ahrefs) aparecen con tanta frecuencia como los de los grandes motores de búsqueda.

Conclusión

El archivo robots.txt puede parecer trivial, pero encierra muchas sutilezas. Nuestro estudio muestra que, además de las conocidas reglas User-agent/Disallow, existe un amplio panorama de directivas con diferente adopción. Algunos "secretos" de robots.txt tienen que ver con la ausencia: por ejemplo, saber que Google no respetará Crawl-delay o Noindex en este archivo ^{[33] [5]}. Otros matices implican la interacción y los casos extremos: las URL no permitidas aún pueden ser parcialmente indexadas ^[6], o los fallos en la obtención de robots.txt pueden congelar el rastreo hasta que se solucionen ^{[43] [44]}. También descubrimos herramientas menos conocidas como Clean-param de Yandex para la fusión de cadenas de consulta ^[7] y las reglas de límite de tasa de Seznam (Source: blog.seznam.cz). Cada una tiene su lugar en ecosistemas específicos.

La trayectoria histórica es que robots.txt ha demostrado ser notablemente duradero y extensible. Ha experimentado solo modificaciones menores en 30 años (por ejemplo, la adición de Allow y el soporte de comodines) ^[13]. La RFC de 2022 congeló oficialmente gran parte de su sintaxis, aunque permite nuevos registros a través de "otros registros" (como con Sitemap:) ^[56]. En adelante, los cambios serán muy lentos, si es que los hay. Google fomenta las ideas impulsadas por la comunidad (el ejemplo de una regla sitemap: existente muestra cómo el consenso puede impulsar la adopción ^[54]). Pero por ahora, los webmasters deben ser expertos en las reglas e interpretaciones actuales: el uso indebido puede dañar el SEO o la seguridad.

Recomendaciones: Los webmasters deben mantener robots.txt simple y bien probado. Solo deben listar lo que es verdaderamente no público o de baja prioridad (por ejemplo, páginas de inicio de sesión, rutas de búsqueda duplicadas). Siempre verifique la sintaxis (use herramientas o el probador de Search Console) y recuerde que el archivo en sí es público. Consulte la documentación oficial de cada motor de búsqueda en caso de duda: para Google, consulte Google Search Central; para Yandex, consulte las directrices de Yandex.Webmaster ^[26]; para Baidu o Bing, sus centros de ayuda. Al solucionar problemas de indexación, siempre verifique que no haya desautorizado accidentalmente URL necesarias (las herramientas comunes incluyen el informe de robots de Google Search Console ^[6] y el historial de versiones archivadas ^[47]).

En resumen, robots.txt sigue siendo una herramienta fundamental, aunque discreta, para el control del rastreo. Comprender todo su alcance —hasta los "secretos" de los parámetros ocultos o únicos— permite a los propietarios de sitios web gestionar mejor su presencia en línea. Todas las afirmaciones y recomendaciones anteriores están respaldadas por fuentes autorizadas y ejemplos del mundo real. Utilice este informe como una lista de verificación de referencia para asegurarse de que su robots.txt sea correcto y seguro, y para mantenerse al tanto de cualquier desarrollo futuro en el Protocolo de Exclusión de Robots ^{[28] [17]}.