- Uma especificação independente de plataforma que organiza os recursos técnicos que um bom site deve ter, cobrindo de
<title> até llms.txt
- Voltada tanto para pessoas quanto para agentes, com referência a padrões modernos da web como WHATWG, W3C, IETF RFCs, WCAG e MDN
- Independentemente da forma de implantação — WordPress, Next.js, apps em Django, HTML puro etc. — a especificação em si é a mesma, e também inclui dicas de implementação
- O conteúdo é dividido em 10 áreas como Foundations, SEO, Accessibility, Security e Performance, mapeadas para padrões amplamente aceitos
- Oferece um servidor MCP público, Agent Skill,
/llms.txt e respostas em Markdown para uso por agentes e operadores em fluxos de auditoria, aprendizado e melhoria
Uma especificação independente de plataforma para bons sites
- The Website Specification é uma especificação independente de plataforma que organiza os recursos técnicos que um bom site deve ter, cobrindo de
<title> até /.well-known/security.txt, conformidade com WCAG e llms.txt
- Voltada tanto para pessoas quanto para agentes, e cada tópico se conecta a fontes de padrões modernos da web como WHATWG, W3C, IETF RFCs, WCAG e MDN
- Seja com WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, apps em Django ou HTML puro, a especificação em si é a mesma em qualquer forma de implantação, e as dicas de implementação vêm depois
- Todas as páginas têm um link Edit on GitHub, aceitam PRs e exibem suas fontes
-
Áreas abordadas
- Os tópicos completos são divididos em 10 áreas mapeadas para padrões amplamente aceitos
- Foundations: 14 itens cobrindo HTML,
head e elementos básicos do documento
- SEO: 13 itens incluindo
robots.txt, sitemap, canonical, dados estruturados e outros elementos de visibilidade em buscas
- Accessibility: 20 itens com regras baseadas em WCAG para que usuários com todas as capacidades possam usar o site
- Security: 12 itens cobrindo cabeçalhos, transporte e políticas para proteger visitantes com segurança
- Well-Known URIs: 9 itens organizando caminhos padronizados definidos em
/.well-known/
- Agent Readiness: 18 itens cobrindo elementos que permitem que agentes de IA e crawlers leiam o site
- Performance: 19 itens abrangendo Core Web Vitals, cache, imagens, fontes e comportamento de rede
- Privacy: 6 itens sobre consentimento, sinais e respeito às escolhas do visitante
- Resilience: 5 itens sobre falhas elegantes, como páginas de erro, modo offline e redirecionamentos
- Internationalisation: 12 itens cobrindo idioma, localidade, direção e conteúdo traduzido
Como usar para agentes e operadores de sites
- A especificação completa é oferecida por meio de um servidor público MCP de somente leitura e sem autenticação
- Há um Agent Skill publicado, informando quando e como agentes compatíveis devem usar a especificação
- Cada URL da especificação fornece Markdown por página via
/llms.txt e Accept: text/markdown
- Um exemplo de configuração do servidor MCP é o seguinte
{
"mcpServers": {
"specification-website": {
"transport": "http",
"url": "https://mcp.specification.website/mcp";
}
}
}
-
Fluxo de uso
- Audit: percorra o checklist e verifique cada item com “o site faz isso — sim/não”
- Learn: em cada item, veja o que é, por que é importante e como implementar
- Improve: se encontrar algo faltando, informações desatualizadas ou tópicos ausentes, é possível abrir um PR com as fontes
1 comentários
Comentários do Hacker News
Agent Readiness tem cara de algo que vai dar vergonha com o tempo, tipo "Web 4.0 Blockchain Integration"
Não porque agentes vão se tornar irrelevantes, mas porque, mesmo que fiquem importantes, se o site tiver que criar tratamento especial para agentes isso já contraria o propósito original
No fim, isso provavelmente vai ser usado por agentes maliciosos para mostrar uma coisa para os agentes e outra para as pessoas, e por isso acho que vai acabar sendo deliberadamente ignorado
Hoje em dia, tudo em um site é componente. Até um dropdown simples com uma lista finita tem seu próprio loader e dispara 10 requisições
fetchsem motivo. Não é exagero; é só olhar a web do Instagram e do FacebookEsqueçam todas essas especificações e me deem o HTML original, sem ofuscação por coisas como React, que insistem que um novo framework JS vai mudar tudo
A web é, por natureza, um ambiente hostil, e considero que uma boa parte de quem opera sites é ela mesma um agente malicioso. Diferenciar o que pessoas e agentes veem é algo que os sites vão usar de propósito, como já faziam com mecanismos de busca
O motivo de "Agent Readiness" não durar muito é que os operadores de sites logo vão perceber que agentes são, na prática, automação de acesso. E isso é justamente contra o que eles vêm lutando, porque ameaça a capacidade de monetização deles
Ainda assim, duvido que isso aconteça na prática. O problema dos agentes maliciosos já era possível há muito tempo. Por exemplo, entregar para crawlers de mecanismos de busca um conteúdo diferente daquele que o usuário vê depois de clicar. Se não me falha a memória, houve uma época em que o Google penalizava sites assim
https://frontendchecklist.io/rules
Pessoas querem um site bonito, e dá para fazer isso até com HTML puro. Agentes não precisam nem disso; idealmente, bastaria ver o conteúdo da página só em Markdown
Por que não ter uma versão para agentes? Isso economiza tempo e dinheiro tanto para o agente cliente quanto para o host do site
Seria bom poder indicar, com um padrão como
llms.txt, que "agentes devem visitar este espelho, que é uma versão Markdown bruta do que os humanos veem"Parte da agent readiness deste site equivale a SEO para AI. E, no caso de sites que não querem crawling por AI, isso também serve no sentido oposto
Seria bom ter boas práticas para áreas como formulários de login. Por exemplo: usar nomes padronizados de campos de entrada que gerenciadores de senha reconheçam, desativar autocomplete e capitalização automática nos campos de login, usar o
input typecorreto do HTML5 se for e-mail, evitar formulários que fazem a pessoa digitar só o e-mail e clicar de novo para então poder inserir a senha, seguir o NIST SP 800-53 e evitar autenticação em dois fatores por SMS ou trocas periódicas arbitrárias de senha e regras de composição, entre outras coisasHá sites demais que nem sequer dão foco automático quando o formulário tem apenas um campo
https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
Depois disso ele publicou muitos textos novos, e talvez seja um dos melhores materiais de UX na web
Até receber o identificador do usuário, não dá para saber se aquele usuário usa senha ou outro método
https://frontendchecklist.io/rules/html/input-types
Quando começo a criar componentes de UI do zero, gosto muito deste site
https://component.gallery/
Ele liga você aos componentes de vários design systems, e muitos deles também incluem diretrizes profundas sobre acessibilidade, internacionalização e afins. Como exemplos de documentação especialmente boa, há o Lightning Design System da Salesforce e o Stacks do StackOverflow
https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
https://stackoverflow.design/system/forms/checkbox
Aí a maioria dos sites não trata isso como prioridade, ou nem sabe que isso é algo a considerar, e acabamos no estado atual
Sempre imaginei que os sites tivessem algum motivo para migrar para esse padrão. Talvez funcione melhor para defesa contra bots, por exemplo. Fico curioso se alguém sabe mais sobre isso
À primeira vista, quase tudo parece gerado por IA, então o jeito como isso é apresentado pode não funcionar muito bem. Ainda assim, se você ler vários itens, tirando a seção de Agent o resto transmite uma higiene web sólida de forma bem clara, então acho que daria para mandar isso para um desenvolvedor web em início de carreira
Ainda assim, é irônico que o próprio site não aplique nem as práticas que ele mesmo diz serem "obrigatórias"
https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
Não entendo qual é o objetivo deste site. Ele se anuncia como uma especificação, mas não entendo exatamente o que ele estaria especificando
Todos os itens usam outras "fontes da verdade" como referência
"Eu estava cansado de apontar para seis fontes diferentes para sustentar uma única recomendação. HTML era WHATWG, acessibilidade era WCAG, cabeçalhos eram IETF, dados estruturados eram schema.org, e o resto era MDN, web.dev e Google Search Central
Não existia uma especificação única, opinativa e neutra em relação à plataforma sobre o que um website moderno realmente deve fazer
Então eu escrevi uma"
[1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...
Fico curioso sobre o quão comum é o que está aqui. /.well-known/change-password seria bom de ter, mas olhando https://news.ycombinator.com/.well-known/change-password e google.com/.well-known/change-password, parece que isso não está implementado
Nunca ouvi falar de isso ser usado na prática
A URL do Google está em https://accounts.google.com/.well-known/change-password, e não no domínio principal
Isso parece ter saído de uma fábrica de resíduo. "SEO", "Agent-readiness". É exatamente o tipo de coisa que um bom website não deveria fazer
Como não poderia deixar de ser, foi feito por um especialista em "SEO" de Wordpress que usa Claude LLM e também é investidor-anjo. Alguém que enriqueceu destruindo a internet que amávamos com resíduo publicitário agora quer destruir o que resta com resíduo de LLM
Classificar "stable URLs" como "agent readiness" parece um sinal de que o autor se importa mais com IA do que com pessoas. Vou colocar esse domínio na lista de bloqueio. Já dá para ver que isso vai piorar a busca por informações de desenvolvimento web
"Não é um framework. Não é um guia. É uma especificação — o que é obrigatório, o que é recomendado e o que deve ser evitado."
É difícil dizer quanto do site é resíduo de LLM, mas parte do texto certamente parece ser
https://specification.website/llms-full.txt
Primeiro, os pequenos rótulos coloridos como required, optional, recommended
Segundo, a quantidade insana de conteúdo que ninguém vai ler
Terceiro, o desenvolvimento que empurra uma ideia fraca com um nível de detalhe doloroso
Eu estava pensando em fazer algo assim por conta própria, mas colei isso em um chat de agente qualquer e funcionou muito bem
Acabei de usar um modelo local (Qwen3.6 27B / pi) para gerar uma lista dos padrões obrigatórios que faltavam em um site antigo feito em Hugo, depois criar uma lista de tarefas e ir resolvendo uma por uma, deixando cada mudança para eu revisar
Ele até fez um favicon que faltava, recortando um símbolo a partir do logo, e o resultado ficou bem bom
pi. Gosto da sensação de zero atrito com prompts curtos de agente/sistema, mas se você simplesmente largar uma tarefa aleatória para ele, parece que vão surgir bastante espera e becos sem saídaAbri o site no MacBook e o uso de CPU passou de 50%
Considerando que é uma especificação sobre como websites deveriam ser, isso é bem irônico
Parte do conteúdo é bem boa, mas espero que padronizar isso como uma checklist de 128 itens não faça as pessoas terem medo de criar websites
Minha especificação favorita é a especificação alucinada. Acho que devo dizer parabéns
Já estou ansioso pela alternativa ISO conduzida por agentes ou pelo caça-níquel operado por LLM