- Una especificación independiente de la plataforma que organiza las funciones técnicas que debe tener un buen sitio web, abarcando desde
<title> hasta llms.txt
- Está dirigida tanto a personas como a agentes y toma como referencia estándares web modernos como WHATWG, W3C, IETF RFCs, WCAG y MDN
- Ya sea que se despliegue con WordPress, Next.js, una app de Django o HTML puro, la especificación en sí es la misma e incluye pistas de implementación
- El tema completo se divide en 10 áreas como Foundations, SEO, Accessibility, Security y Performance, y está mapeado a estándares ampliamente aceptados
- Ofrece un servidor MCP público, Agent Skill,
/llms.txt y respuestas en Markdown para que agentes y operadores puedan usarlo en flujos de auditoría, aprendizaje y mejora
Una especificación independiente de la plataforma para buenos sitios web
- The Website Specification es una especificación independiente de la plataforma que organiza las funciones técnicas que debe tener un buen sitio web, cubriendo desde
<title> hasta /.well-known/security.txt, conformidad con WCAG y llms.txt
- Está dirigida tanto a personas como a agentes, y cada tema está vinculado a fuentes de estándares web modernos como WHATWG, W3C, IETF RFCs, WCAG y MDN
- Sin importar si se publica con WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, una app de Django o HTML puro, la especificación en sí es la misma, y después se añaden pistas de implementación
- Todas las páginas incluyen un enlace de Edit on GitHub, se aceptan PR y cada página muestra sus fuentes
-
Áreas que cubre
- El tema completo se divide en 10 áreas mapeadas a estándares ampliamente aceptados
- Foundations: 14 elementos que cubren HTML,
head y los elementos básicos del documento
- SEO: 13 elementos que incluyen factores de visibilidad en buscadores como
robots.txt, sitemap, canonical y datos estructurados
- Accessibility: 20 elementos que presentan reglas basadas en WCAG para que usuarios con todo tipo de capacidades puedan usar el sitio
- Security: 12 elementos que cubren encabezados, transporte y políticas para proteger de forma segura a los visitantes
- Well-Known URIs: 9 elementos que organizan rutas estándar acordadas bajo
/.well-known/
- Agent Readiness: 18 elementos que cubren lo necesario para que agentes de IA y rastreadores puedan leer el sitio
- Performance: 19 elementos que abarcan Core Web Vitals, caché, imágenes, fuentes y comportamiento de red
- Privacy: 6 elementos sobre consentimiento, señales y respeto a las decisiones de los visitantes
- Resilience: 5 elementos sobre fallas elegantes como páginas de error, modo offline y redirecciones
- Internationalisation: 12 elementos que cubren idioma, configuración regional, dirección y contenido traducido
Cómo lo usan agentes y operadores de sitios
- La especificación completa se ofrece mediante un servidor público de MCP de solo lectura y sin autenticación
- Se publica un Agent Skill que indica a los agentes compatibles cuándo y cómo usar la especificación
- Cada URL de la especificación ofrece Markdown por página mediante
/llms.txt y Accept: text/markdown
- Un ejemplo de configuración del servidor MCP es el siguiente
{
"mcpServers": {
"specification-website": {
"transport": "http",
"url": "https://mcp.specification.website/mcp";
}
}
}
-
Flujo de uso
- Audit: revisar la checklist y confirmar cada punto con “¿el sitio hace esto? — sí/no”
- Learn: revisar en cada punto qué es, por qué importa y cómo se implementa
- Improve: si encuentras algo faltante, desactualizado o un tema omitido, puedes abrir un PR adjuntando fuentes
1 comentarios
Comentarios en Hacker News
Es muy probable que Agent Readiness termine dando vergüenza ajena con el tiempo, como “Web 4.0 Blockchain Integration”
No porque los agentes vayan a volverse irrelevantes, sino porque, incluso si llegan a ser importantes, si un sitio tiene que hacer manejo especial para agentes, eso traiciona la intención original
Al final se usará para que actores maliciosos muestren algo distinto a los agentes y a las personas, así que probablemente se ignore a propósito
Hoy en día, en los sitios web todo es un componente. Hasta un dropdown simple con una lista finita trae su propio loader y lanza 10 requests
fetchsin motivo. No es exageración: basta con ver la web de Instagram y FacebookQue se dejen de todas estas especificaciones y mejor nos den HTML original, sin ofuscar por cosas como React que insisten en que un nuevo framework de JS va a cambiarlo todo
La web es, por naturaleza, un entorno hostil, y considero que una buena parte de quienes operan sitios web son por sí mismos actores maliciosos. Los sitios usarán deliberadamente mostrar algo distinto a los agentes y a las personas, tal como hicieron con los motores de búsqueda
La razón por la que “Agent Readiness” no va a durar es que los operadores de sitios pronto recordarán que los agentes son, en la práctica, automatización de acceso. Y eso es justo contra lo que llevan años peleando, porque amenaza su capacidad de monetización
Aun así, dudo que de verdad pase. El problema de los actores maliciosos existe desde hace mucho. Por ejemplo, darle a un crawler de buscador contenido distinto al que ve el usuario después de hacer clic. Si mal no recuerdo, hubo una época en la que Google penalizaba este tipo de sitios
https://frontendchecklist.io/rules
Las personas quieren un sitio agradable de ver, y eso puede lograrse incluso solo con HTML puro. Los agentes ni siquiera necesitan eso; idealmente, les bastaría con ver el contenido de la página solo en Markdown
¿Por qué no tener una versión para agentes? Les ahorra tiempo y dinero tanto a los agentes cliente como al host del sitio web
Estaría bien un estándar como
llms.txtpara indicar: “los agentes deben visitar en su lugar este mirror, que es una versión Markdown en bruto de lo que ven las personas”Parte del agent readiness de este sitio equivale a SEO para AI. A la inversa, si un sitio no quiere crawling de AI, también sirve para lo contrario
Estaría bien tener mejores prácticas para áreas como los formularios de inicio de sesión. Por ejemplo: usar nombres estándar de campos de input que reconozcan los administradores de contraseñas, desactivar autocomplete y autocapitalización en los campos de login, usar el
input typecorrecto de HTML5 si es un correo, evitar formularios que te hacen ingresar solo el correo y luego volver a hacer clic para poder meter la contraseña, seguir NIST SP 800-53 evitando 2FA por SMS o cambios periódicos arbitrarios de contraseña y reglas de composición, etc.Hay demasiados sitios que ni siquiera ponen foco automático en formularios con un solo campo
https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
Desde entonces ha publicado muchos textos nuevos y probablemente sea uno de los mejores recursos de UX en la web
Hasta que no recibes el usuario, no sabes si esa persona usa contraseña o algún otro método
https://frontendchecklist.io/rules/html/input-types
Cuando hago componentes de UI desde cero, de verdad me gusta este sitio
https://component.gallery/
Te enlaza a componentes de varios sistemas de diseño, y muchos de ellos incluyen también lineamientos profundos sobre accesibilidad, internacionalización y temas similares. Como ejemplos especialmente bien documentados están Lightning Design System de Salesforce y Stacks de StackOverflow
https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
https://stackoverflow.design/system/forms/checkbox
Entonces la mayoría de los sitios no lo consideran prioridad o ni siquiera saben que es algo que deberían contemplar, y por eso terminamos como estamos ahora
Siempre he pensado que debe haber una razón para que los sitios cambien a ese patrón. Por ejemplo, que sirva mejor contra bots. Me pregunto si alguien sabe más al respecto
A simple vista, casi todo parece contenido generado por IA, así que puede que la forma de transmitirlo no funcione muy bien. Aun así, si lees varios apartados, salvo la sección de Agent, el resto comunica una higiene web bastante sólida y con bastante claridad, así que creo que no estaría mal pasárselo a un desarrollador web que recién va creciendo.
Dicho eso, es irónico que el propio sitio ni siquiera aplique las prácticas que ellos mismos llaman "esenciales".
https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
No entiendo cuál es el objetivo de este sitio web. Se publicita como una especificación, pero no sé exactamente qué es lo que estaría especificando.
Todos los puntos toman como fuente alguna otra "fuente de verdad".
"Me cansé de tener que apuntar a seis fuentes distintas para respaldar una sola recomendación. HTML era WHATWG, accesibilidad era WCAG, headers era IETF, datos estructurados era schema.org, y el resto era MDN, web.dev y Google Search Central.
No existía una especificación única, con opiniones claras y neutral respecto a plataformas, sobre lo que un sitio web moderno realmente debe hacer.
Así que escribí una"
[1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...
Me pregunto qué tan comunes son las cosas que hay aquí. /.well-known/change-password estaría bien tenerlo, pero viendo https://news.ycombinator.com/.well-known/change-password y google.com/.well-known/change-password, parece que no está implementado.
Nunca había oído que se usara en la práctica.
La URL de Google está en https://accounts.google.com/.well-known/change-password y no en el dominio principal.
Esto parece salido de una fábrica de basura. "SEO", "Agent-readiness". Justo el tipo de cosas que un buen sitio web no debería hacer.
Cómo no, lo hizo un experto en "SEO" de Wordpress que usa Claude LLM y además es inversionista individual. Alguien que hizo dinero arruinando el internet que amábamos con basura publicitaria, y ahora quiere arruinar lo que queda con basura de LLM.
Que haya clasificado "stable URLs" bajo "agent readiness" me parece una señal de que al autor le importan más las IA que las personas. Voy a poner este dominio en mi lista de bloqueo. Ya veo que va a empeorar todavía más la búsqueda de información sobre desarrollo web.
"No es un framework. No es una guía. Es una especificación — qué es esencial, qué es recomendado y qué se debe evitar."
Es difícil decir qué parte del sitio es basura de LLM, pero algunas frases sin duda lo parecen.
https://specification.website/llms-full.txt
Primero, las pequeñas etiquetas de color como required, optional, recommended.
Segundo, una cantidad absurda de contenido que nadie va a leer.
Tercero, una forma de desarrollar ideas débiles con un nivel de detalle dolorosamente excesivo.
Yo mismo había pensado en hacer algo así, pero al pegar esto en cualquier chat de agente funciona sorprendentemente bien.
Justo ahora hice que un modelo local (Qwen3.6 27B / pi) generara una lista de estándares esenciales que le faltaban a un viejo sitio en Hugo, luego armó una lista de tareas y fue resolviéndolas una por una, dejándome revisar cada cambio.
Incluso creó el favicon que faltaba recortando un símbolo del logo, y quedó bastante bien.
pi. Me gusta esa sensación de cero fricción con prompts cortos de agente/sistema, pero si le dejas cualquier tarea al azar, siento que puede haber bastante espera y varios callejones sin salida.Abrí el sitio en mi MacBook y el uso de CPU se fue por encima del 50%.
Es bastante irónico si pensamos que supuestamente es una especificación sobre cómo debería ser un sitio web.
Algunas partes están bastante bien, pero ojalá que estandarizarlo como una checklist de 128 puntos no termine haciendo que la gente tenga miedo de crear sitios web.
Mi especificación favorita es la especificación alucinada. No sé, ¿habría que felicitarlo?
Ya espero con ansias la alternativa ISO impulsada por agentes o las tragamonedas operadas por LLM.