发布与验证
让 AI 统一静态站 URL：从四个入口查同一篇文章
让站内链接、规范地址和站点地图互相对齐。
资料核验2026.11.12 · 静态内容站 · RSS、索引与发布检查
文章从 /notes/demo 和 /notes/demo/ 都能打开。链接一半带尾斜杠、一半不带，读者复制出去的地址也开始分叉。静态托管本身可能已经有重定向，先检查线上响应再决定哪种写法。
交给编码助手的任务
让助手找出生成器中站内链接、canonical、RSS 与站点地图四个出口。用一篇同时可带或不带尾斜杠访问的文章核对实际托管规则，再统一到同一条公开路径。
从生成器统一地址
给文章生成一条首选路径。内部导航、RSS、站点地图和 canonical 都用它。托管支持时，把其他写法重定向到首选路径。若先上线规范标记，确认它使用真实正式域名。
从同一篇文章取这四个位置的地址，做逐项比较。再用普通浏览器打开变体，记录最终落到哪个 URL。
文章迁址时保留旧链接的重定向，已经被收藏的地址才有机会继续工作。
先准备一个对照样例
以 /notes/demo/ 为首选地址。把卡片链接、canonical、RSS link 和 sitemap loc 抄到一行对照表。再向托管地址请求不带尾斜杠的变体，记录实际重定向与最终响应，避免仅凭本地结果下结论。
用这些结果验收
- 四处使用相同正式地址。
- 旧网址保有可访问或可追踪的重定向。
- 构建阶段正式域名缺失时不会把测试地址当成正式值。
审查时容易漏掉什么
canonical 是用于指示首选 URL 的信号。验证要包含真实 HTTP 响应、渲染的页面头和生成文件，别只检查代码里有没有写 canonical 标签。
让助手检查分页 URL、文章 URL 和订阅入口是否有不同身份规则。规范地址应只表达当前页面的首选版本。部署边缘若将斜杠变体跳转，用实际请求链记录响应状态和目的地址，再与源站生成的链接对照。
