先看现象。新闻站 2026 年 10 月仍在输出 AMP 版，正文在后台改完后源站十分钟内就是新内容，从搜索结果点进去看到的还是三天前的旧稿，缓存地址 /c/s/www.example.com/amp/… 的时间戳一直没动。试过在 Search Console 点重新抓取，也改过源站的 Cache-Control，缓存副本都没换。
原因不止一个，得分开看。AMP 页响应头里没有 s-maxage，缓存服务按默认的十几分钟到一天自己决定。还有一种是更新通知只在首次发布时推过一次，站内编辑修改正文不会重新推。
不容易想到的是，AMP 地址带 utm 参数，缓存键认成另一个版本，刷新的是没人访问的那份。
还有一种情况，页头 amphtml 的 link 指向旧地址，抓取器顺着它读到的是上一版。
上来先看缓存副本与源站的时间戳差异
curl -s 'https://www.example.com/amp/post-123' | grep -i -E 'etag|last-modified'给 AMP 页补上可缓存的响应头
add_header Cache-Control "public, max-age=60, s-maxage=60" always;调用更新通知接口推一次
curl -X POST -H 'Content-Type: application/json' -d '{"url":"https://www.example.com/amp/post-123"}' https://www.example.com/amp/update-ping回源抽正文首段和缓存版本比对
curl -s 'https://www.example.com/amp/post-123' | grep -o '<h1[^>]*>[^<]*'怎么算真的好了，看的是同一批现象。通知接口返回 200 后十分钟，缓存副本里的标题和首段与源站一致，日志里出现来自缓存更新服务的抓取记录，搜索点进来的落地页是新稿。
AMP 的缓存不是自己清得掉的，能控的只有响应头过期时间和更新通知，改这两处比反复点重新抓取有效。这类问题最好一次改到位，反复小改反而容易把原因搅混。