批量改标题和描述，脚本能做和不能做的事

2026 年 3 月我们给一个站批量改了 400 个产品文档页的标题和描述，用的是脚本。改完四周看数据，有 60 个页面的点击率反而降了，最后回滚了其中 40 个。批量改动这件事，脚本能做的比想象中少。

脚本能做的三件事

批量读。从站点地图或者 CMS 数据库把全部标题、描述、URL 拉出来，存成表。这一步人工做要一整天，脚本五分钟。

批量写。通过 CMS 的接口或者直接改数据库，把新标题写回去。写完立刻读一遍确认，不能写完就跑。

批量校验。标题长度、重复标题、描述长度、有没有漏填，这些规则让脚本查，比人眼靠谱。我们用的规则很简单：标题超过 30 个汉字截断，描述控制在 60 到 120 字，同站重复标题直接报错。

脚本做不了的事

判断哪个标题更好。这是内容判断，脚本没有数学依据。点击率受位置、搜索意图、竞品、季节影响，标题只是其中一个变量。

判断用户意图。产品页的标题是给已经知道产品的人看的，博客标题是给还在找答案的人看的，两种写法完全不一样，脚本分不出来。

判断品牌调性。有的公司要求标题里必须带产品名，有的要求口语化。这些约束得写进规则表，由人定。

我们的流程

先人工写 50 个标题，作为样本。这 50 个要覆盖不同类型页面，产品页、文档页、博客、案例。写完让团队投票选出最好的 10 个，总结出规律。

脚本按规律套模板生成剩下的 350 个，但每条都要人工扫一遍。我们抽了 10% 做详细复核，发现 7 条有语病。

上线后四周看数据，按页面类型分组对比点击率，下降超过 15% 的回滚。

那次失败的原因

我们把 400 个文档页的标题从“某功能官方文档”改成“某功能怎么用，完整步骤”。听起来更吸引人，但搜“某功能文档”的人是在找参考手册，加一句“怎么用”反而模糊。

导航型查询的页面，标题别乱改。它本来就不靠点击率吃饭，用户是直奔这个页面来的。

回滚机制

改之前把原值存一份带日期的表，按批次分组。一周内能一键回滚，超过两周就不好判断是不是标题造成的影响了。

还有一个规矩：别直接改生产库。先改测试环境，抽几个页面看渲染结果，确认没问题再上生产。我们见过脚本把 HTML 标签写进标题字段的事故，修复花了两天。