Specification.website 做了一件看起来很朴素、但对网站团队很有用的事：把“一个合格网站该具备什么”整理成 10 张清单。
这里面有很基础的东西，比如 <title>、robots.txt、站点地图、颜色对比度。也有更近两年才变得敏感的东西，比如 /.well-known/security.txt、/llms.txt，以及 AI Agent 能不能稳定读懂一个网站。
我更在意的不是它“发布了什么新标准”。它并不是 WHATWG、W3C 或 IETF 这类标准组织，也不能替这些组织制定 Web 标准。
真正的变化是：网站建设正在从“凭经验说最佳实践”，转向“拿一张可审计清单逐项对”。尺子摆出来，团队讨论会少很多玄学。
它把网站基础能力拆成 10 类，不绑定技术栈
Specification.website 目前列出 10 个分类。每个条目都尽量链接到公开来源，包括 WHATWG、W3C、IETF RFC、WCAG、MDN 等。
这使它更像一张“标准索引地图”，而不是某个团队自己的经验手册。
| 分类 | 条目数 | 主要覆盖 |
|---|---|---|
| Foundations | 14 | HTML、head、文档基础 |
| SEO | 13 | robots.txt、站点地图、canonical、结构化数据 |
| Accessibility | 20 | 对齐 WCAG 的无障碍规则 |
| Security | 12 | HTTPS、响应头、安全策略 |
| Well-Known URIs | 9 | /.well-known/ 下的标准路径 |
| Agent Readiness | 18 | 让 AI Agent 和爬虫更容易读取网站 |
| Performance | 19 | Core Web Vitals、缓存、图片、字体、网络行为 |
| Privacy | 6 | 同意机制、隐私信号、访客选择 |
| Resilience | 5 | 错误页、离线、重定向、降级能力 |
| Internationalisation | 12 | 语言、地区、方向、翻译内容 |
它强调平台无关。WordPress、Next.js、Django、Astro、Hugo、Drupal、TYPO3，甚至静态 HTML，都可以按同一套问题检查。
这点很关键。很多网站问题不是因为团队不知道“要优化”，而是因为不同角色的最低线不一致。
SEO 关心 canonical 和 sitemap。前端关心图片、字体和 Core Web Vitals。安全同事盯着 HTTPS、CSP、security.txt。无障碍审计看对比度、键盘访问和语义结构。
如果这些要求散在不同文档里，改版验收时就很容易变成补丁式协作。谁想起来谁提，谁漏了谁背锅。
有一张统一清单后，开发团队至少可以先做三件事：
- 上线前按分类逐项 audit，判断“有、没有、待确认”；
- 遇到不懂的条目，回到来源文档 learn，确认为什么要做；
- 发现清单遗漏或来源过时，在 GitHub 上提交 PR improve，并附上公开依据。
它不能替团队做完这些事，但能把讨论起点往前推。
Agent Readiness 和 MCP 是新变量，但别当成通行证
这套清单最有辨识度的部分，是 Agent Readiness。
过去网站主要面对两类读者：人和搜索引擎。现在多了一类读者：AI Agent。它们会抓取网页、读取文档、生成摘要，也可能在工具链里执行任务。
这带来一个新问题：网站不是“能打开”就够了，还要能被机器稳定理解。
Specification.website 为此提供了几个入口：开放 MCP server，地址是 https://mcp.specification.website/mcp，只读、无需认证；发布 Agent Skill；支持通过 /llms.txt 和 Accept: text/markdown 获取每页 Markdown。
这些设计的意义是降低查询成本。兼容 MCP 的工具或 Agent，可以直接读取规范内容，而不是让开发者在网页和文档之间来回翻。
但我不太买账把它讲成“AI 时代网站新门槛”的说法。证据还不够。
MCP 仍是新兴接口。Agent Skill 也不是网站上线的必要条件。/llms.txt 目前更像面向 AI 读取的补充说明，而不是所有网站都必须立刻部署的行业强制项。
更稳妥的用法，是把它放进内部流程，而不是拿来做营销标签。
| 对象 | 更现实的动作 | 不该误读成什么 |
|---|---|---|
| 网站开发者和技术负责人 | 把清单接入改版验收、PR review、CI 检查项；先补基础项，再评估 Agent Readiness | 不是自动修复工具，也不是新的官方 Web 标准 |
| SEO、无障碍、安全、性能审计团队 | 用同一张表对齐审计范围，减少重复检查和口径冲突 | 不是替代 Lighthouse、axe、Security Headers 等专项工具 |
这里可以和 Lighthouse、PageSpeed Insights、axe、Security Headers 做个对照。
这些工具通常擅长某个方向：性能、无障碍、安全或质量评分。Specification.website 的位置不同。它更像审计前的共识底稿，告诉团队“哪些问题应该被纳入检查”。
检测仍要靠具体工具。修复仍要靠工程实现。清单本身不负责把问题改好。
它适合做验收底稿，不适合被神化成万能标准
对开发者和技术负责人，最直接的影响是流程变化。
以后做网站改版、迁移框架、换 CMS、重做官网时，可以先拿这张清单做边界确认：哪些是必须项，哪些是暂缓项，哪些要交给安全或法务再判断。
这会改变一个常见决策：不是等上线前才问“SEO 检查了吗”，而是在需求阶段就把 canonical、结构化数据、图片尺寸、字体加载、CSP、错误页、语言标记、security.txt 放进验收范围。
对负责 SEO、无障碍、安全和性能审计的团队，价值更直接。
它给了一个共同底稿。审计团队可以少花时间解释“为什么这个也要查”，多花时间判断“这个网站有没有做到、做到什么程度、是否有业务例外”。
但边界也要说清楚。
这套清单不能替代业务判断。也不能覆盖所有行业合规要求。金融、医疗、儿童产品、跨境数据处理这类场景，仍要看当地法规、专业审计和企业自己的风险策略。
接下来最该看的，不是它会不会“一统 Web 标准”。这个说法太大，也不符合它目前的位置。
更实际的观察点只有两个。
一是来源维护能不能跟上。Web 规则会变，浏览器行为会变，安全建议也会变。清单如果不持续校准，很快就会从“尺子”变成“旧尺”。
二是它能不能进入真实工程流。比如进入 CI、PR review、上线验收和审计模板。只有进了这些环节，它才不只是一个好看的目录，而是能减少返工的工具。
网站建设最怕各凭经验。经验不是没用，但经验不成表，就很难审计；不进流程，就很难复用。