Robots, sitemaps y rutas conocidas

La Web necesita que clientes que no conocen una aplicación de antemano puedan localizar determinados metadatos. Los crawlers buscan reglas y sitemaps. Los clientes de identidad necesitan descubrir endpoints y claves. Los procesos de divulgación buscan un contacto estable. Para evitar que cada producto invente otra ubicación, varios estándares asignan rutas predecibles en el origen.

Que la ruta sea predecible no hace equivalentes sus contenidos. robots.txt expresa preferencias de rastreo. Un sitemap declara URLs. /.well-known/ reserva ubicaciones para protocolos concretos cuya semántica vive en otra especificación. La tarea es interpretar cada documento según ese contrato y convertir sus relaciones en candidatos verificables.

Los ejemplos usan ORIGIN para el esquema y la autoridad, como https://www.example.com. No incluye una ruta de aplicación.

El Robots Exclusion Protocol busca /robots.txt en la raíz del servicio:

curl -sS ORIGIN/robots.txt

El archivo agrupa reglas por User-agent. Disallow excluye rutas del rastreo y Allow introduce una excepción más específica:

User-agent: *
Disallow: /private/
Allow: /private/public-guide.pdf
Sitemap: https://www.example.com/sitemap.xml

El crawler selecciona el grupo que corresponde a su product token. Para una URL, gana la regla que coincide con más octetos. Si Allow y Disallow tienen la misma longitud, prevalece Allow. Las rutas distinguen mayúsculas y minúsculas.

robots.txt no es control de acceso. Una ruta listada puede seguir siendo accesible y una ruta ausente puede requerir autenticación. Tampoco demuestra que el contenido sea sensible. Aporta nombres y preferencias que deben comprobarse como cualquier otra evidencia.

Crawl-delay aparece en implementaciones reales, pero no forma parte de las reglas normativas de RFC 9309. Su interpretación cambia entre crawlers. Registra el comportamiento de la herramienta en lugar de asumir una semántica común.

La directiva Sitemap puede apuntar a un sitemap XML o a un índice de varios sitemaps. También se prueba habitualmente /sitemap.xml:

curl -sS ORIGIN/sitemap.xml

Un conjunto mínimo contiene elementos <loc>:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/products/</loc>
  </url>
</urlset>

lastmod describe la fecha declarada de modificación. changefreq y priority son indicaciones para crawlers, no propiedades verificadas del recurso. Deduplica las URL y compara sus hostnames con el scope. Un sitemap antiguo puede contener rutas retiradas y un índice puede estar comprimido.

RFC 8615 reserva el prefijo /.well-known/ en la raíz de un origen. Cada sufijo debe estar registrado o definido por una especificación. La ruta base no tiene por qué mostrar un listado:

curl -sS ORIGIN/.well-known/security.txt
curl -sS ORIGIN/.well-known/openid-configuration

Cada especificación define cómo construir su URL. /app/.well-known/security.txt no es el recurso canónico de RFC 9116 para el origen. OpenID Connect es una excepción relevante: cuando el valor issuer contiene una ruta, concatena /.well-known/openid-configuration después de ella para admitir varios emisores en el mismo host.

security.txt publica cómo comunicar vulnerabilidades. Contact y Expires son campos obligatorios. También pueden aparecer Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy y Hiring:

Contact: mailto:security@example.com
Expires: 2026-12-31T23:59:59Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

El fichero se aplica al dominio o dirección desde el que se recupera. No declara por sí solo el alcance de todos los subdominios. Una fecha Expires pasada indica que la información necesita revisión.

openid-configuration publica metadatos de un OpenID Provider:

{
  "issuer": "https://id.example.com",
  "authorization_endpoint": "https://id.example.com/oauth2/authorize",
  "token_endpoint": "https://id.example.com/oauth2/token",
  "userinfo_endpoint": "https://id.example.com/oauth2/userinfo",
  "jwks_uri": "https://id.example.com/oauth2/jwks",
  "scopes_supported": ["openid", "profile", "email"],
  "response_types_supported": ["code"],
  "id_token_signing_alg_values_supported": ["RS256"]
}

La respuesta relaciona emisor, endpoints, scopes, tipos de respuesta y algoritmos publicados. jwks_uri apunta a claves públicas usadas para verificar firmas. No expone por ese hecho una clave privada. Comprueba que issuer coincida exactamente con el emisor esperado y registra qué endpoints pertenecen a otros hostnames.

La especificación de metadatos del servidor de autorización de OAuth 2.0 utiliza el sufijo oauth-authorization-server. Otras entradas relevantes dependen de la aplicación, como assetlinks.json para asociaciones con Android o apple-app-site-association para servicios de Apple. El registro de IANA permite comprobar el sufijo y localizar su especificación vigente.

Para cada ruta conserva:

Una ruta nueva se incorpora al crawling. Un emisor o hostname nuevo vuelve al inventario de dominios y hosts virtuales.

Si un documento anunciado no responde, conserva la relación y diagnostica por separado resolución, redirección, autenticación y vigencia. Un sitemap puede declarar una URL retirada. Un security.txt puede haber expirado. Un emisor OpenID Connect con metadatos incompletos puede seguir activo. La ausencia actual modifica la confianza de la relación, pero no borra la evidencia que la produjo.

• RFC 9309: Robots Exclusion Protocol
• Sitemaps Protocol
• RFC 8615: Well-Known Uniform Resource Identifiers
• IANA: Well-Known URIs
• RFC 9116: security.txt
• OpenID Connect Discovery 1.0