Web 开发领域长期面临一个隐性困境：尽管存在 W3C、WHATWG、IETF 等权威机构制定的底层标准，但在 "如何构建一个合格的网站" 这一实践层面，开发者往往依赖零散的经验帖、框架默认配置或团队内部约定。这种碎片化的知识传递方式导致同一组织内的不同项目可能采用迥异的实现策略，跨团队协作时更是难以对齐基础假设。
Website Specification 项目正是针对这一痛点提出的系统性解决方案。该项目由 Joost de Valk 发起，以 MIT 协议开源维护，旨在建立一套平台无关的技术规范 —— 无论你使用 WordPress、Next.js、Astro 还是原生 HTML，规范本身保持中立，仅定义 "好网站应当具备的技术特性"，而将具体实现细节留给开发者自行决策。
十大技术领域的全覆盖
该规范将网站技术要求划分为十个相互关联的类别，形成从基础结构到前沿能力的完整谱系：
基础层（Foundations） 涵盖每个页面必须具备的 HTML 头部元素，包括文档类型声明、字符编码、视口设置、标题元素等 14 项具体要求。其中对 <meta charset> 的位置约束（必须位于文档前 1024 字节内）和对 lang 属性的强制要求，直接对应着浏览器解析策略和辅助技术的依赖逻辑。
可访问性（Accessibility） 以 WCAG 指南为基准，定义了 20 项从颜色对比度、图像替代文本到键盘导航、焦点指示器的具体要求。值得注意的是，规范明确将 "避免使用无障碍覆盖层（Accessibility Overlays）" 列为建议项 —— 这类第三方 JavaScript 组件声称能在运行时自动修复网站的无障碍问题，但实践表明它们往往干扰屏幕阅读器的正常工作流。
Agent Readiness 是该规范最具前瞻性的类别，包含 18 个主题，专门应对 AI 代理和大型语言模型爬虫的新需求。从 /llms.txt 文件约定、MCP（Model Context Protocol）服务器暴露，到 Web Bot Auth 身份验证机制，这一类别正在快速迭代，部分条目仍处于草案阶段，但已反映出 Web 生态对机器可读性的重新重视。
其余类别分别覆盖 SEO（搜索可见性）、Security（安全头部与策略）、Well-Known URIs（标准路径约定）、Performance（Core Web Vitals 与资源优化）、Privacy（隐私信号与同意管理）、Resilience（错误处理与离线能力）、Internationalisation（多语言与本地化）。
三级约束的工程化价值
规范采用 "必需（Required）/ 推荐（Recommended）/ 避免（Avoid）" 的三级标注体系，这一设计本身即体现了工程化思维：
-
必需项 对应着技术债务的硬性底线。例如 " 每个
<img>元素必须具备alt属性 " 不仅是可访问性的基础要求，也直接影响搜索引擎对图像内容的理解能力。 -
推荐项 提供了渐进增强的路径。以
/llms.txt为例，规范将其定位为 "新兴约定而非正式标准"，鼓励网站维护者主动提供面向 LLM 的精选内容索引，但不强制要求。 -
避免项 则基于实践经验指明反模式。除了前述的无障碍覆盖层，规范还明确建议不要使用空链接 / 按钮（即仅包含图标而无文本标签的交互元素），这类设计对语音控制用户和屏幕阅读器用户构成实质性障碍。
这种分级体系使得团队可以根据项目阶段和资源约束制定差异化的合规策略 —— 初创产品可以优先满足必需项，成熟项目则逐步向推荐项对齐。
AI 时代的协议扩展
Agent Readiness 类别的设计思路尤其值得关注。传统 Web 标准主要面向人类用户和搜索引擎爬虫，而 AI 代理的兴起带来了新的交互范式：
内容发现机制 方面，规范推广 /llms.txt 作为站点根目录下的 Markdown 索引文件，供 LLM 快速获取网站核心内容概览；同时支持通过 Accept: text/markdown 请求头或 .md 后缀 URL 直接获取页面的原始 Markdown 源码，避免代理需要解析复杂的 HTML DOM。
机器可读接口 方面，项目自身即作为示范案例，提供了基于 MCP（Model Context Protocol）的只读查询端点。任何兼容 MCP 的客户端都可以通过标准 JSON-RPC 接口查询规范内容，这一设计将静态文档转化为可编程的知识库。
身份验证机制 方面，Web Bot Auth 提案基于 RFC 9421 HTTP Message Signatures，允许爬虫通过密钥签名证明自身身份，使网站能够基于可验证的凭证而非易伪造的 User-Agent 字符串来实施访问控制。
这些扩展并非要取代现有的 Web 标准，而是在其基础上增加面向智能代理的语义层，类似于 RSS/Atom 之于 HTML 的关系。
落地实践建议
对于希望采用该规范的团队，建议遵循以下路径：
首先，利用规范提供的在线检查清单对现有站点进行基线审计。检查清单将十个类别的要求转化为可逐项勾选的是 / 否问题，便于快速识别合规缺口。
其次，将必需项纳入代码审查的自动化检查流程。许多必需项（如 HTML doctype、lang 属性、图像 alt 文本）可以通过 ESLint、HTML-validate 等工具实现静态检测。
再次，对推荐项采用 "渐进合规" 策略。例如可以先在核心页面实现 /llms.txt，再逐步扩展到全站；可以先为 API 文档暴露 MCP 端点，再考虑为内容页面增加 Markdown 源码接口。
最后，保持对规范演进的关注。由于项目采用开放协作模式（每页均提供 "Edit on GitHub" 入口），新出现的 Web 技术（如 Popover API、:has() 选择器等）会被持续纳入规范更新。
资料来源
- Website Specification 官方网站：https://specification.website
- 项目 GitHub 仓库：https://github.com/jdevalk/specification.website
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。