¿Están preparadas las webs .tokyo para los agentes de IA?

Lighthouse construye el árbol de accesibilidad que recorrería un agente y puntúa la página como aprobada o suspendida. El denominador son solo las páginas que la auditoría pudo evaluar: un notApplicable o un error se excluyen en vez de contarse como suspenso, y la fracción que se pudo evaluar se publica al lado como la cobertura.

n=1 · coverage 50.0% · margin ±53.00 pp.

La auditoría llms-txt aprobando: se sirve un fichero Y Lighthouse lo considera válido. El denominador es cada página de la muestra, así que esto es una fracción de toda la web y no de las webs que tienen fichero. Es la cifra que usa el índice, porque un fichero roto no guía a un agente.

n=2 · coverage 100.0% · margin ±37.48 pp.

Un recuento, no un porcentaje: cuántas webs de la muestra registran herramientas WebMCP que un agente puede llamar. Es la auditoría que define la dimensión Actuar; las otras dos auditorías de WebMCP miden lo buenas que son esas herramientas, no si existen.

n=1 · coverage 50.0% · margin ±53.00 pp.

Leído del robots.txt de las webs de la muestra: de los agentes de IA que seguimos, cuántos NO están prohibidos. Gradual y no un sí o un no: echar a un agente de diecisiete no es lo mismo que echarlos a todos. Una web sin robots.txt no bloquea a nadie, así que cuenta como completamente alcanzable: eso es una medición, no un hueco. Es la única cifra que MULTIPLICA el índice en vez de sumarse, porque es una condición previa: si un agente no puede descargar la página, nada más de la página importa. Una salvedad que preferimos decir antes que esconder: un Disallow general bajo User-agent: * no se cuenta, porque la medición sobre todo el corpus tampoco lo puede ver, y preferimos ser consistentes a ser listos.

n=2 · coverage 100.0% · margin ±37.48 pp.