用途
The Website Specification 是一个与平台无关的规范，用于说明「一个好网站应该做什么」。它共有十个类别、140 多个页面，每个条目都带有状态标注。该规范以三种机器可读形式提供：逐页 Markdown、llms.txt / llms-full.txt，以及一个 MCP 服务器。
适用时机：
- 用户询问「我的网站应该有什么」「X 是必需的吗」「审计这个 URL」「规范对 Y 是怎么说的」或类似问题。
- 你在评审网站，希望引用一手标准而非厂商博客文章。
- 你需要一份平台无关的机器可读契约来做审计。
主要能力与使用方式
最快路径 —— MCP
如果可以使用 MCP，就用它。该服务器是无状态 Streamable HTTP，无需认证，CORS 完全开放。
- 端点：https://mcp.specification.website/mcp
- 服务器卡片：https://specification.website/.well-known/mcp/server-card.json
- 协议修订：2025-03-26
工具：
search(query, limit?)—— 对所有页面做全文搜索。list_topics({ category?, status?, limit? })—— 过滤后的索引：slug、标题、状态、摘要、URL。get_topic({ slug })—— 返回某个页面的完整规范 Markdown，包括其引用的来源。get_checklist({ category?, status? })—— 可勾选的 Markdown 清单。get_categories()—— 十个类别及其数量和摘要。get_changes({ since?, type?, limit? })—— 某日期之后的变更：新页面、状态提升、重写、删除，每项都解析到当前需要重新审计的主题。
提示词：audit_url(url, focus?) —— 针对目标 URL 生成一份对照规范的审计计划，可选限定到一个类别。
不使用 MCP —— 直接获取 Markdown
每个规范页面都有规范的 HTML URL 和 Markdown 变体。
- HTML：https://specification.website/spec/<category>/<slug>/
- Markdown（文件扩展名）：https://specification.website/spec/<category>/<slug>.md
- Markdown（内容协商）：在 HTML URL 上设置
Accept: text/markdown，中间件会重定向到 .md 变体。
站点级索引：
- https://specification.website/llms.txt —— 每个页面的「标题 — 摘要」行，加载成本低。
- https://specification.website/llms-full.txt —— 所有页面拼接为 Markdown，用于一次性加载上下文。
- https://specification.website/rss.xml —— 变更的 feed。
- https://specification.website/sitemap-index.xml —— 所有 URL。
- https://specification.website/.well-known/api-catalog —— 所有机器可读端点的 RFC 9727 链接集。
类别
类别 slug 是 URL 的一部分。当前 slug 包括：
- foundations —— HTML、head、文档基础。
- seo —— robots.txt、站点地图、canonical、结构化数据。
- accessibility —— 对齐 WCAG 的规则。
- security —— 头、传输、策略。
- well-known ——
/.well-known/下的标准路径。 - agent-readiness —— 让网站对 AI 智能体和爬虫可读（llms.txt、MCP、内容信号、链接头、markdown 源端点）。
- performance —— Core Web Vitals、缓存、图像、字体。
- privacy —— 同意、信号、尊重访客选择。
- resilience —— 错误页、离线、重定向。
- i18n —— 语言、区域、方向、翻译内容。
调用 get_categories() 获取带数量的实时列表。
状态 —— 契约
每个页面上的 status 字段就是门槛。
- required —— 没有它平台契约就会破坏。给出修复建议时优先列出这些。示例：
<title>、<meta charset>、HTTPS、图像 alt 文本、真正的 404。 - recommended —— 现代网站应该做到。示例：CSP、HSTS、结构化数据、Open Graph、llms.txt。
- optional —— 取决于上下文。
- avoid —— 过时或有害。若网站这样做，应标记出来。
required 的门槛是「平台会破坏」，而不是「我们强烈建议」。总结时，绝不要把 recommended 悄悄升级为 required。
常见工作流
- 「审计这个 URL。」调用
audit_url提示词获取计划，或获取get_checklist({ status: "required" })并引导用户逐项验证。更深入的审计，再拉取status: "recommended"。 - 「agent readiness 的必需项是什么？」调用
list_topics({ category: "agent-readiness", status: "required" })，然后对每一项调用get_topic。 - 「规范为什么这样说 X？」每个页面的 frontmatter 中有 2–4 个一手来源。引用那些来源，而不是规范页面本身。
- 「有 Y 对应的类别吗？」先调用
get_categories()；如果没有匹配的，用search(query)在语料中搜索。
与 MDN MCP 搭配
该规范回答一个好网站应该做什么以及它是否是必需的。它不记录每项 Web 特性如何工作或支持度如何。为此，请搭配 MDN MCP 服务器（https://mcp.mdn.mozilla.net/ —— 免费，无需认证），它提供 MDN 文档和 Baseline / 浏览器兼容性数据。
两者在审计或构建中可以干净地组合：
- 用该规范决定检查什么、何时是必需的 ——
get_checklist、list_topics或audit_url提示词。 - 对于出现的每项 Web 平台特性，调用 MDN MCP 获取如何实现以及是否可安全上线（Baseline 状态、浏览器支持）。
即：specification.website 告诉你 Content-Security-Policy 是 recommended 以及为什么；MDN MCP 告诉你哪些指令是 Baseline 以及如何编写它们。保持角色区分 —— 不要向该规范询问浏览器支持数据，也不要向 MDN 询问某约定对一个好网站是否必需。
保持最新 —— 只重新审计有变动的部分
该规范经常变化，尤其是 agent-readiness。不要每次从头重新审计网站，也不要信任规范的缓存副本 —— 检查增量：
- 审计后，存储规范的最新变更日期。使用 MCP 时，
get_changes()会将其作为latest返回；否则记录你运行的日期。 - 下次，调用
get_changes({ since: <that date> })。它只返回此后新增的页面、状态提升/降级、重写和删除，每项都已解析到当前主题（含当前状态和 URL）。 - 只重新审计那些主题 —— 对每个调用
get_topic，然后重新检查目标站点。
不使用 MCP 时，同样的类型化历史是 changelog RSS feed：https://specification.website/changelog/rss.xml（条目标记为 added / changed / status / removed，并带有受影响的 slug）。轮询它并对新条目采取行动。
合理的默认频率是每月一次，或在任何新审计开始时。状态提升（例如某主题变为 required）可能让之前通过的网站变为不通过，因此即使没有新增页面，也值得做一次增量检查。
来源与许可
- 代码 MIT。
- 内容 CC BY 4.0。
- 站点源码：https://github.com/jdevalk/specification.website。
引用时，使用页面的规范 URL，并以 updated frontmatter 字段作为 as-of 日期。