The Website Specification es una especificación web agnóstica de plataforma que enumera las 128 características técnicas que todo sitio decente debería tener, desde la etiqueta <title> hasta /.well-known/security.txt. Su premisa es tan simple como poco común en la industria: no son opiniones, son estándares.
Lo verdaderamente novedoso es para quién está escrita. El proyecto declara que su público son «humanos y agentes», y expone toda la especificación como servidor MCP y como Markdown para que las IA la consulten igual que lo haría una persona frente a la documentación.
TL;DR
- The Website Specification reúne 128 temas técnicos en 10 categorías: Foundations, SEO, accesibilidad, seguridad, performance y más.
- Cada regla enlaza al estándar de origen: WHATWG, W3C, IETF (RFCs), WCAG y MDN. No son opiniones, son estándares consolidados.
- Es agnóstica de plataforma: aplica igual a WordPress, Drupal, Next.js, Astro, Hugo, Django o HTML plano.
- Incluye un servidor MCP de solo lectura y sin autenticación para que los agentes de IA consulten la spec en tiempo real.
- Publica un Agent Skill y expone cada página como Markdown vía /llms.txt y la cabecera Accept: text/markdown.
- Cubre rutas estándar bajo /.well-known/ como security.txt (RFC 9116) y el emergente llms.txt.
- Todo es open source: cada página tiene un enlace 'Edit on GitHub' y se aceptan PRs siempre que citen fuentes.
Qué propone The Website Specification
La pregunta que intenta responder el proyecto es engañosamente básica: ¿qué hace, técnicamente, un buen sitio web? Cualquiera que haya trabajado en desarrollo web conoce la sensación de tener una lista mental difusa —«hay que poner un <title> decente, configurar el robots.txt, no romper el contraste de color, acordarse del sitemap.xml»— sin un lugar único y autoritativo donde verificarla. The Website Specification convierte esa lista difusa en 128 ítems concretos, cada uno con un formato de auditoría binario: ¿el sitio hace esto, sí o no?
El catálogo abarca diez áreas mapeadas a estándares ampliamente aceptados. Cada ítem se puede leer en dos niveles: como casilla de verificación para un audit rápido, o como ficha extendida que explica qué es la regla, por qué importa y cómo implementarla. La filosofía está resumida en una de sus frases: «Standards, not opinions». Cuando una regla dice que un encabezado de seguridad debe estar presente, el enlace no apunta al blog de moda del momento, sino al RFC o a la recomendación del W3C que lo define.
Esa disciplina de citar la fuente primaria es lo que distingue al proyecto de las decenas de listas de «mejores prácticas» que circulan. Aquí el orden de prioridad es explícito: primero el estándar, después la pista de implementación. Si mañana cambia la recomendación oficial, la spec se actualiza apuntando a la nueva fuente, no a la preferencia de un autor.
De los estándares dispersos a una especificación web unificada
El problema que ataca no es nuevo. Los estándares que rigen la web están repartidos entre organismos distintos: WHATWG mantiene el HTML living standard, el W3C publica WCAG y un sinfín de recomendaciones, la IETF emite los RFCs que definen cosas como security.txt (RFC 9116) o las URIs bajo /.well-known/ (RFC 8615), y MDN documenta cómo todo eso se usa en la práctica. Un desarrollador que quiera «hacerlo bien» tiene que saltar entre cinco o seis sitios con tonos, formatos y niveles de profundidad muy diferentes.
The Website Specification funciona como una capa de índice sobre ese ecosistema. No reescribe los estándares ni los reemplaza: los organiza, los traduce a checklist accionable y los enlaza de vuelta a la fuente. El resultado es algo parecido a lo que un linter es para el código: una especificación web operativa que se puede recorrer ítem por ítem y aplicar sin tener que ser un experto en cada RFC.
La otra apuesta de diseño es la neutralidad de plataforma. El proyecto lo dice sin rodeos: da igual si publicás con WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, una app de Django o HTML plano. La especificación es la especificación; las pistas de implementación vienen después y se adaptan a cada stack. Para equipos en LATAM que conviven con realidades muy heterogéneas —un CMS heredado en PHP aquí, un frontend en Astro allá— esa independencia es práctica: la misma checklist sirve para auditar todo el portafolio.
Las diez áreas se mapean a estándares de WHATWG, W3C, IETF y WCAG.
Las 10 categorías y los 128 temas
El reparto de los 128 temas da una idea clara de las prioridades del proyecto. Performance y accesibilidad son las áreas más densas, lo que refleja dónde suelen estar los problemas reales de los sitios en producción:
-
Foundations (14) — lo básico del HTML, el
<head>y la estructura del documento que toda página necesita. -
SEO (13) — visibilidad en buscadores:
robots.txt, sitemaps, canonicals y datos estructurados. - Accesibilidad (20) — reglas alineadas con WCAG para que personas de todas las capacidades puedan usar el sitio.
- Seguridad (12) — cabeceras, transporte y políticas que protegen al visitante.
-
Well-Known URIs (9) — rutas acordadas bajo
/.well-known/. - Agent Readiness (18) — todo lo que hace al sitio legible para agentes de IA y crawlers.
- Performance (19) — Core Web Vitals, caching, imágenes, fuentes y comportamiento de red.
- Privacidad (6) — consentimiento, señales y respeto a la elección del visitante.
- Resiliencia (5) — fallar con elegancia: páginas de error, modo offline, redirecciones.
- Internacionalización (12) — idioma, locale, dirección de texto y contenido traducido.
Un ejemplo concreto de la categoría de seguridad es el archivo security.txt, que estandariza cómo un sitio publica su canal de contacto para reportes de vulnerabilidades. Así de simple es el artefacto que la spec pide colocar en /.well-known/security.txt:
Contact: mailto:security@tudominio.com
Expires: 2026-12-31T23:59:59z
Preferred-Languages: es, en
Canonical: https://tudominio.com/.well-known/security.txt
Policy: https://tudominio.com/seguridad
En la categoría de Agent Readiness aparece el emergente llms.txt, un archivo de texto en la raíz del sitio pensado para que los modelos de lenguaje encuentren rápido el contenido relevante, evitando tener que parsear HTML lleno de menús y banners:
# Mi Sitio
> Documentación y artículos sobre desarrollo web.
## Docs
- [Guía de inicio](https://tudominio.com/docs/inicio.md)
- [Referencia de API](https://tudominio.com/docs/api.md)
## Opcional
- [Changelog](https://tudominio.com/changelog.md)
Lista para agentes: MCP, llms.txt y Agent Skills
Aquí está el ángulo que hace de este proyecto una noticia y no solo otra lista de buenas prácticas. The Website Specification no se conforma con decir que un sitio debería ser legible para agentes: se aplica el principio a sí misma. Toda la especificación está disponible como un servidor MCP (Model Context Protocol) de solo lectura y sin autenticación, de modo que un agente compatible puede consultarla en vivo mientras audita o construye un sitio.
La configuración para conectar el servidor MCP a un cliente compatible es mínima:
{
"mcpServers": {
"specification-website": {
"transport": "http",
"url": "https://mcp.specification.website/mcp"
}
}
}
Además, cada página de la spec se puede obtener como Markdown puro, ya sea pidiendo su variante /llms.txt o enviando la cabecera Accept: text/markdown sobre cualquier URL del sitio. Es la misma página, servida en el formato que cada consumidor prefiera. La consulta funciona idéntico en los tres sistemas operativos, porque curl está disponible en todos:
# Linux / macOS
curl -H "Accept: text/markdown" https://specification.website/seo
# Windows (PowerShell)
curl.exe -H "Accept: text/markdown" https://specification.website/seo
💭 Clave: El proyecto trata «legible para humanos» y «legible para agentes» como requisitos que están convergiendo, no como mundos separados. La misma URL sirve HTML para un navegador y Markdown para un modelo.
El flujo completo se puede visualizar así: el desarrollador y el agente consumen la misma especificación, que a su vez apunta a los estándares de origen, y el sitio web final expone su contenido en el formato que cada cliente necesita.
graph LR
A["Agente de IA"] -->|"MCP / llms.txt"| B["The Website Specification"]
C["Desarrollador"] -->|"checklist / PR"| B
B --> D["Estandares de origen: WHATWG, W3C, IETF, WCAG"]
E["Sitio web"] -->|"Accept: text/markdown"| A
Para completar el círculo, el proyecto publica un Agent Skill: un módulo que le enseña a cualquier agente compatible cuándo y cómo usar la especificación. En la práctica, esto significa que un asistente de código puede recibir la instrucción «auditá este sitio contra la spec» y resolverla consultando una fuente estructurada en lugar de alucinar reglas.
La spec se recorre como un audit binario: cada ítem es un sí o un no.
Qué significa para desarrolladores en LATAM
Para equipos de la región, el valor más inmediato es tener un baseline común que no dependa de la antigüedad o la moda del stack. Una agencia que mantiene diez clientes en plataformas distintas puede correr la misma checklist sobre todos y producir un reporte comparable. Un freelancer puede usarla como argumento técnico ante un cliente: «tu sitio falla en 7 de los 12 ítems de seguridad y en 9 de los 20 de accesibilidad» es mucho más convincente que una recomendación vaga.
La categoría de internacionalización merece atención especial en contextos hispanohablantes. Configurar correctamente el atributo lang, las etiquetas hreflang para versiones por país y la dirección del texto son detalles que impactan tanto el SEO como la experiencia, y que suelen quedarse a medias en proyectos que arrancaron pensando solo en un mercado.
💡 Tip: Empezá el audit por las categorías de accesibilidad (20 ítems) y performance (19). Son las más densas de la spec justamente porque son donde más sitios fallan, y donde el retorno —usuarios y Core Web Vitals— es más medible.
Hay también una lectura estratégica de cara al tráfico de agentes. A medida que más usuarios delegan búsquedas y resúmenes a asistentes de IA, los sitios que exponen su contenido de forma legible para máquinas —vía llms.txt, Markdown o datos estructurados— tienen ventaja para ser citados correctamente. La categoría de Agent Readiness deja de ser un experimento de nicho y empieza a parecerse a lo que el SEO fue para los buscadores hace veinte años.
⚠️ Ojo: Que un sitio sea legible para agentes no implica abrirlo sin control. Exponer Markdown y un
llms.txtes distinto de servir endpoints sensibles; la categoría de seguridad de la spec sigue aplicando con la misma fuerza.
Qué sigue
El proyecto se construye en abierto: cada página incluye un enlace «Edit on GitHub» y acepta pull requests con la única condición de que aporten fuentes. Esa gobernanza es la que define su futuro. Si la comunidad lo adopta, podría convertirse en una referencia de facto —el equivalente a lo que MDN representa para la documentación— y crecer más allá de los 128 temas actuales conforme aparezcan nuevos estándares.
El riesgo, como en todo proyecto comunitario, es la deriva: mantener 128 fichas sincronizadas con estándares que evolucionan exige trabajo constante. La disciplina de «fuente requerida en cada PR» ayuda a contener la entropía, pero la prueba real será su capacidad de mantenerse actualizado durante años. Por ahora, ofrece algo escaso: un lugar único, citable y agnóstico para responder la pregunta de qué hace, técnicamente, un buen sitio web.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es The Website Specification?
Es una especificación web agnóstica de plataforma que enumera 128 características técnicas que todo sitio decente debería tener, organizadas en 10 categorías y enlazadas a estándares de WHATWG, W3C, IETF, WCAG y MDN. Funciona como una checklist auditable donde cada ítem es un «sí o no».
¿Para qué sirve el servidor MCP?
El servidor MCP de solo lectura permite que un agente de IA consulte la especificación en tiempo real, sin autenticación. Así un asistente de código puede auditar o construir un sitio apoyándose en una fuente estructurada en lugar de inventar reglas.
¿Qué es el archivo llms.txt?
Es un archivo de texto que se coloca en la raíz del sitio para que los modelos de lenguaje encuentren rápido el contenido relevante en formato Markdown, sin tener que parsear HTML lleno de navegación y banners. La spec lo incluye dentro de su categoría de Agent Readiness.
¿Funciona con WordPress o solo con frameworks modernos?
Funciona con cualquier plataforma. El proyecto es explícito: la especificación es la misma para WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, Django o HTML plano. Las pistas de implementación se adaptan a cada stack, pero las reglas no cambian.
¿Es gratis y de código abierto?
Sí. El proyecto se construye en abierto, cada página tiene un enlace «Edit on GitHub» y se aceptan pull requests siempre que citen fuentes. La checklist y el servidor MCP son de acceso libre.
¿En qué se diferencia de una lista de «mejores prácticas» cualquiera?
En que cada regla enlaza de vuelta a su estándar de origen en lugar de a la opinión de un autor. Su lema es «standards, not opinions»: si el estándar oficial cambia, la spec se actualiza apuntando a la nueva fuente.
Referencias
- The Website Specification — sitio oficial del proyecto con las 128 reglas, el servidor MCP y el Agent Skill.
- WCAG (W3C/WAI) — pautas de accesibilidad para el contenido web, base de la categoría de accesibilidad.
- RFC 9116 — estándar IETF que define el archivo security.txt bajo /.well-known/.
- RFC 8615 — especificación de los Well-Known URIs (/.well-known/).
- Model Context Protocol — protocolo abierto sobre el que se sirve la especificación a los agentes.
- MDN Web Docs — referencia de implementación citada por múltiples reglas de la spec.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)