这份清单怎么用
本站每个页面都是静态 HTML，发布前都要过一遍校验。下面这些就是站点自带的回归测试跑的检查，我们同时写清了每一项存在的原因，而不是丢一串链接了事。凡是没法自动化的，都把人工步骤写出来。
顺序是有意义的。先看爬虫可访问性与结构化数据，因为一个没人能收录的漂亮页面价值为零；再看内容体量和可访问性，因为那才是审核或第一次到访的人真正感受到的东西；性能放最后，因为它最好量化，也最容易被过度投入。
搜索与收录
- Google Search Console：本站以「网域资源」验证，所以覆盖数据是按
redskill.org整体统计的。每次发布后重新提交/sitemap.xml，并对改动的页面用网址检查。 - Bing Webmaster Tools：通过站点根目录下的
BingSiteAuth.xml文件验证。对我们来说这一步值得做，因为本站相当一部分搜索流量来自 Bing 及其合作渠道权重更高的市场。
结构化数据与富媒体结果
- Google Rich Results Test：校验每个页面输出的 JSON-LD 图。所有页面都带
Organization与WebSite节点；指南页额外带Article，分类页带CollectionPage与BreadcrumbList，入口页带ItemList，首页则带描述公开数据集的Dataset节点。 - Schema Markup Validator：用来抓那些不影响富媒体资格、但依然说明有问题的结构缺陷，比如一条
ItemList里所有条目指向同一个网址。
爬虫可访问性
有两个文件决定广告和搜索爬虫能不能读到本站，两者都会在部署前自动校验：
/robots.txt对全部用户代理放行，并且绝不能屏蔽信任页面。屏蔽一个同时带noindex的页面，会连带把这条指令也藏起来，结果该页面仍可能以裸网址形式被收录——比单独做任何一种选择都更糟。/ads.txt用于声明本域名的 AdSense 卖方授权。它只有一行，一旦与site.config.json里的发布商 ID 不一致，构建就会失败。
性能与可访问性
- PageSpeed Insights：检查移动端 Core Web Vitals。这里最常见的退化是加了图片或字重却没有体积预算，所以我们看的是实测数据而不只是实验室分数。
- WCAG 2.2：我们是针对具体条款测，而不是凭整体印象。绕过区块（2.4.1）靠每个页面的跳转链接满足；焦点可见（2.4.7）靠链接与控件的焦点描边；对比度最低要求（1.4.3）靠一层 token 级对比检查，任一对低于 4.5:1 就直接让构建失败；目标尺寸（2.5.8）要求交互控件不小于 24×24 CSS 像素，只在移动端出现的控件则做到 44；颜色的使用（1.4.1）要求每个风险标签都配文字值，而不是只靠颜色。
本地回归检查
发布前在仓库根目录跑这三条即可，它们刻意做得很快，而且完全离线。
python3 scripts/build-content.py --check校验生成页面与 sitemap 是否为最新，这样对手工改动生成页面的行为不会悄悄通过。python3 scripts/verify-seo.py校验元数据字数、canonical、hreflang 配对、JSON-LD 必需字段、静态资源缓存串、robots 与 ads.txt 内容、CSS 颜色 token 用法、对比度配对，以及每个可索引页面的最小正文体量。python3 -m unittest discover -s scripts -p "test_*.py"跑契约测试，防止共享页头页脚、页面骨架与校验边界彼此漂移。
我们不声称的东西
这些检查全部通过，只说明页面结构完整、彼此一致。它不代表内容正确，也不代表这里提到的任何第三方技能是安全的、还在维护的、或者仍然可用。那些是自动化检查回答不了的问题，也是本站把每一条数据集记录都呈现成「待核实的线索」而不是「已核实的事实」的原因。