网站上线后 90 天维护检查清单

网站上线不是项目结束，而是网站开始面对真实用户、真实活动、真实编辑和真实数据的时间点。上线后的前 90 天，通常会暴露设计评审和 staging QA 中看不到的问题。

这份网站维护检查清单适合创始人、市场团队、B2B 团队、电商团队和内容编辑。你可以在网站改版、Shopify 主题更新、WordPress 主题开发、Headless Commerce 上线或多语言网站发布后使用它。

先在上线记忆还清楚的时候记录基线。保存 sitemap、重点 URL、页面模板、表单去向、追踪事件、analytics 视图、Search Console 资源、CMS 角色、插件或应用清单、主机方案和备份设置。

这个基线能减少后面的猜测。如果流量下降、表单不发送、某个模块坏掉，或插件更新影响布局，团队可以和明确的上线状态对比，而不是靠记忆判断。

• 保存上线 URL 清单和重定向表。
• 记录 analytics 事件、表单去向和转化目标。
• 导出当前插件、应用、主题和集成清单。
• 记录重点模板的 Core Web Vitals、页面速度、收录和抓取状态。

很多维护检查是一页一页看。这有用，但会漏掉路径级问题。访客体验网站时，不是孤立看模板，而是从搜索结果到落地页，从服务页到案例，从产品页到购物车，或从文章到咨询表单。

挑出真正有商业价值的路径，并在桌面和手机上测试。B2B 网站可以测试首页到服务页、证明内容再到联系表单。Shopify 可以测试集合页到产品页、购物车和结账。多语言网站要测试语言切换、本地化表单和翻译后的 metadata。

技术 SEO 维护应该在搜索引擎有时间重新抓取之后开始。检查重点 URL 是否收录，canonical 是否稳定，重定向是否工作，标题和描述是否按预期显示，结构化数据是否有效。

然后检查数据。一次上线即使视觉成功，如果 analytics 没有记录询盘、购买、活动流量或 consent 行为，业务上仍然会失真。重点看支持决策的事件，而不是只看 pageview。

• Search Console：收录、覆盖率、sitemap 处理、主要查询和异常 404。
• Analytics：表单提交、结账事件、CTA 点击、滚动事件、来源数据和转化路径。
• SEO 元数据：标题规则、描述、社交预览、图片 alt 和 canonical 输出。
• 重定向：旧的重点 URL 应该跳到预期的新位置。

上线后，编辑方式通常会变化。团队会创建新页面、复制旧布局、粘贴更长的标题、上传比例不一致的图片、加脚本，或安装应用来快速解决小问题。这些决定不一定错，但需要复查。

打开 CMS，检查上线后发生了什么变化。重点看未使用草稿、重复模块、破掉的图片裁切、缺失的 alt、不清楚的字段名、没有经过确认的布局 workaround，以及每次修改都要找开发的页面。

这对 WordPress 和 Shopify 尤其重要，因为很多小编辑会慢慢变成长线维护债务。目标不是阻止团队编辑，而是让编辑保持安全、可预期，并且有文档。

功能检查应该固定、重复、甚至有点无聊。提交每一个重要表单，确认通知、CRM 路由、邮件送达、预约链接、结账流程、订阅组件、评价组件、站内搜索、筛选器和追踪脚本都正常。

同时检查看不见的系统：备份、可用性监控、SSL、插件更新、应用账单、废弃集成、用户权限、防垃圾设置，以及前外包或前员工的访问权限。前端再精致，也不能弥补运营系统损坏。

• 表单：提交测试询盘，并确认正确团队收到。
• 备份：确认可以恢复，而不是只确认存在备份。
• 安全：检查管理员账号、角色、密码、插件、应用和 API key。
• 集成：确认 CRM、邮件、电商、analytics 和 consent 工具仍然能交换数据。

维护清单只有在发现被转成行动时才有用。建立一个小 backlog，记录严重程度、负责人、受影响页面或系统、建议修复方式和复查日期。把紧急 bug、质量改进和战略变化分开。

优先级可以很简单。先修坏掉的表单、结账问题、安全缺口、收录问题和追踪失败。再安排内容清理、CMS 改进、速度优化和设计细节。更大的结构问题，放进下一次改版或重建讨论。