定时发出去的文章，页面缓存要不要再刷一遍

设了定时发布的文章到点发出后，静态页面缓存要不要手动重建，取决于站点有没有把生成动作挂在发布事件上。稳妥的做法是按三处分别核对：正文页是否已生成、列表与首页缓存是否更新、站点地图是否收录了新地址。定时发布解决的是「什么时候进入正式状态」，静态生成解决的是「访客实际读到的是哪一份文件」，两步在系统里是分开的，所以到点之后要做的是核对而不是等待。

到点后先核对正文页

第一个核对动作很简单：直接打开这篇文章的地址，看返回的是新内容还是旧的占位结果。若正文页已正确，说明发布事件带动了该页面的静态生成；若仍是旧的，先确认文章状态是否真的从待发布转到了正式文档。

文档状态分为正式文档、草稿、待发布与回收站，定时发布走的是待发布到正式这一段。草稿可以用带 preview 标记的链接预览，但预览只证明内容本身没问题，不证明静态文件已经生成——这两个结论要分开取。

列表与首页的缓存最容易滞后

详情页只影响一个文件，列表页和首页聚合的是多篇文章的排序结果，它们的缓存重建往往比详情页慢一拍。最常见的现象是：文章能直连访问，但分类列表和首页上找不到入口。

这种情况要按顺序确认三件事：列表页的缓存是否已重建；该文章的分类归属是否正确；排序规则是否把它排到了首屏之外。第三点尤其容易被误判成缓存问题——如果列表按时间倒序，定时发布的文章时间在预期之内，它就应在首屏。

站点地图与推送要不要跟上

要。新地址进入站点地图是收录的前提，而定型后的站点地图通常按周期生成，定时发布的新文章可能落在下一个生成周期里。核对方式是打开站点地图文件确认该地址已出现。

如果这一批定时发布是时效内容，就不要只等站点地图：配合链接推送与主动推送，把新地址直接交给搜索引擎，让发现速度与发布时间对齐。这一点对有时效的栏目尤其重要，定时发布的价值本来就是踩时间点，收录慢了价值就打折。

批量定时发布的检查顺序

批量操作时，逐篇核对不现实，可以按固定顺序抽样：先确认发布批次的时间设置，再在到点后统一看一次列表页与首页，然后核对站点地图里本批地址的出现比例，最后抽查若干文章在分类页里的位置。

另一条经验是把备份放在批量动作之前。备份与恢复覆盖数据与静态文件，批量定时发布前先做一次备份，一旦时间设置错误或排序异常，可以整段回退而不是逐篇手工修。多站点运营时这一点更重要：同一套操作会作用在多个站点上，回退能力决定了试错成本。

常见问题

定时发布和手动点发布有区别吗

发布动作相同，触发方式不同。定时发布是时间因子机制，到点由系统把内容转为正式状态；手动发布由人决定时刻。两者的后续核对项一致。

每次定时发布都要重建全站缓存吗

不必。先确认发布事件是否自动带动相关页面生成；只有在列表页确实滞后时才需要针对性重建，全站重建留给批量改动和模板调整之后。

到点后文章没有出现在列表里怎么办

按三层排查：文章状态是否已是正式文档、分类归属是否正确、列表页缓存是否重建。多数情况落在第三层。

站点地图里没有刚发出的文章正常吗

取决于站点地图的生成周期。如果在周期内未出现属正常，但可以手动触发一次生成，或用链接推送把地址先提交出去。