[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-seo-scripts-maintenance":3,"blog-prev-seo-scripts-maintenance":116,"blog-next-seo-scripts-maintenance":196},{"id":4,"title":5,"author":6,"body":7,"canonical":100,"category":101,"cover":100,"date":102,"description":103,"draft":104,"extension":105,"keywords":100,"meta":106,"navigation":107,"noindex":104,"ogImage":100,"path":108,"seo":109,"seoDescription":100,"seoTitle":100,"stem":110,"tags":111,"updated":100,"__hash__":115},"blog\u002Fblog\u002Fseo-scripts-maintenance.md","SEO 脚本没人维护，三个月后一定会崩","元析智能",{"type":8,"value":9,"toc":90},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87],[11,12,13],"p",{},"2026 年 4 月我们从 git 里翻出 11 个自建脚本，4 个已经跑不通了。没人删，也没人修，就那么挂着定时任务，每天往日志里写报错。自建脚本的成本大头不在写，在养。",[15,16,17],"h2",{"id":17},"崩的五种原因",[11,19,20],{},"站点改版。选择器、API 路径、字段名一变，脚本立刻失效，这是最常见的。",[11,22,23],{},"第三方接口变更。GSC API 的字段调整、CMS 升级、webhook 格式变化，都会让脚本读不到数据。",[11,25,26],{},"磁盘和权限。日志写满、token 过期、服务账号被移出权限组，这些运维层面的问题最容易被忽略。",[11,28,29],{},"写脚本的人走了。没文档、没注释，接手的人看不懂也不敢改。",[11,31,32],{},"需求变了。当初要的报表没人看了，脚本还在跑。",[15,34,35],{"id":35},"三种崩法",[11,37,38],{},"静默出错最危险。脚本正常退出，但结果是空的或者错的，报表照发，数字全是零。",[11,40,41],{},"部分出错次之，比如只抓到一半页面，报表看着正常但少了一块。",[11,43,44],{},"彻底不跑反而安全，因为很快会有人发现数据没了。",[11,46,47],{},"我们现在的做法是每天校验输出行数，低于阈值直接报错退出，不生成报表。",[15,49,50],{"id":50},"三条维护规矩",[11,52,53],{},"每个脚本一个说明文件，写清用途、输入、输出、依赖、负责人。五分钟能写完，省后面的十次沟通。",[11,55,56],{},"依赖版本锁定。Python 包不锁版本，半年后换个环境跑不起来。",[11,58,59],{},"每季度跑一次全量验证，对着已知结果比一遍。这条最容易被跳过，但只有它能发现静默错误。",[15,61,62],{"id":62},"交接怎么做",[11,64,65],{},"录一段五分钟的屏，把脚本跑一遍，讲清每一步在做什么。视频比文档有效，因为能看到报错长什么样。",[11,67,68],{},"注释只写“为什么”，不写“是什么”。代码本身能看出是什么，看不出的是当初为什么这么写。",[11,70,71],{},"别留只有一个人能跑的脚本。这个人休假，任务就停。",[15,73,74],{"id":74},"哪些活别自己写",[11,76,77],{},"能买就买。日志分析、排名监控、死链检测都有成熟工具，自己写等于浪费三个月。",[15,79,80],{"id":80},"一个反面例子",[11,82,83],{},"2025 年我们写过一个自动提交站点地图的脚本，六行，跑了一年没坏。后来站点从 800 个 URL 涨到 3 万，站点地图超过 5 万条的上限被截断，脚本不知道，一直提交半份地图，导致新页面收录拖了一个月。",[11,85,86],{},"修起来十分钟，发现花了半个月。原因是没人校验过输出的条数。",[11,88,89],{},"只在两种情况下自建：市面上的工具满足不了具体规则，或者用量大到工具费用不合理。我们自建的脚本都落在“排序”和“拼数据”这两类事上，现成工具确实做不到。",{"title":91,"searchDepth":92,"depth":92,"links":93},"",2,[94,95,96,97,98,99],{"id":17,"depth":92,"text":17},{"id":35,"depth":92,"text":35},{"id":50,"depth":92,"text":50},{"id":62,"depth":92,"text":62},{"id":74,"depth":92,"text":74},{"id":80,"depth":92,"text":80},null,"SEO","2026-03-27","我们盘过 11 个自建脚本，4 个已经跑不动。崩的方式有静默出错、部分出错和彻底不跑三种。这篇写维护规矩、交接办法，以及哪些活干脆别自己写。",false,"md",{},true,"\u002Fblog\u002Fseo-scripts-maintenance",{"title":5,"description":103},"blog\u002Fseo-scripts-maintenance",[112,113,114],"自动化脚本","维护","工作流","yJYKpIH-VUaGrRXtE65UDEuAoLVpu4vsR7jLk7DHgIE",{"id":117,"title":118,"author":6,"body":119,"canonical":100,"category":101,"cover":100,"date":185,"description":186,"draft":104,"extension":105,"keywords":100,"meta":187,"navigation":107,"noindex":104,"ogImage":100,"path":188,"seo":189,"seoDescription":100,"seoTitle":100,"stem":190,"tags":191,"updated":100,"__hash__":195},"blog\u002Fblog\u002Fpost-update-first-three-things.md","算法更新后别急着改站，先做这三件事",{"type":8,"value":120,"toc":178},[121,124,128,131,134,137,141,144,147,150,154,157,160,163,166,169,172,175],[11,122,123],{},"算法更新后第一件事不是改站，是确认三件事：是不是真的更新、掉的是哪类页面、竞品有没有同样掉。这三件事没做完就动手，大概率改错方向。我们踩过这个坑，现在有固定顺序，也把判断标准写成了表。顺序错了，改得越多错得越多。",[15,125,127],{"id":126},"第一步确认是不是算法","第一步：确认是不是算法",[11,129,130],{},"看两个东西。一是同期其他站有没有波动，我们监测的同类站如果 80% 都在掉，基本可以确认是算法；只有一个站在掉，先怀疑自己。",[11,132,133],{},"二是看时间分布。算法更新通常在一两天内影响一批站，曲线是断崖式的；技术问题或改版是缓慢扩散的。",[11,135,136],{},"去年 11 月一次波动，客户坚持说是算法，我们查了 6 个同类站，只有他一个掉。最后查出来是 CDN 节点故障，服务器返回了 3 天 503。",[15,138,140],{"id":139},"第二步看掉的是哪类页面","第二步：看掉的是哪类页面",[11,142,143],{},"把掉量最大的 20 个页面拉出来，看它们的共同点：是同一个栏目？同一种内容类型？还是同一批发布时间？",[11,145,146],{},"这个分类决定后面怎么改。如果掉的是信息型文章，可能是内容质量或站点评级问题；如果掉的是产品页，可能是转化率或页面结构问题；如果掉的是新页面，可能是抓取或收录问题。",[11,148,149],{},"我们的做法是建一张表：URL、原排名、现排名、页面类型、发布时间、上次修改时间。这张表一拉，规律通常很明显。",[15,151,153],{"id":152},"第三步看竞品有没有同样掉","第三步：看竞品有没有同样掉",[11,155,156],{},"如果竞品也掉，说明是整个品类的需求或算法调整，你的站没问题，别乱改。如果竞品没掉甚至涨了，去看他们涨的是哪些页面，和你的差在哪。",[11,158,159],{},"这一步最容易被跳过，但它能省掉很多无用功。我们见过客户在竞品也掉的情况下大改站点，改完排名没回来，还把原来稳定的页面搞乱了。",[15,161,162],{"id":162},"三件事之后才动手",[11,164,165],{},"三件事做完，通常能得出一个方向：改内容、改结构、或者什么都不改只等恢复。",[11,167,168],{},"如果是内容问题，改最掉的那批页面，一次改 20%，观察两周。如果是结构问题，先修技术项，别碰内容。如果判断不了，什么都别改，观察一个月再说。",[15,170,171],{"id":171},"一个反例",[11,173,174],{},"2025 年 3 月核心更新后，一个客户第二天就把所有页面标题重写了。两周后流量又掉了 12%，因为新标题丢掉了原有的关键词。等我们介入时，已经改不回去了，只能重新做关键词映射。",[11,176,177],{},"算法更新不是考试，没有标准答案。先诊断，再动手，是我们用两年时间换来的顺序。",{"title":91,"searchDepth":92,"depth":92,"links":179},[180,181,182,183,184],{"id":126,"depth":92,"text":127},{"id":139,"depth":92,"text":140},{"id":152,"depth":92,"text":153},{"id":162,"depth":92,"text":162},{"id":171,"depth":92,"text":171},"2026-03-26","算法更新后第一件事不是改站，是确认三件事：是不是真的更新、掉的是哪类页面、竞品有没有同样掉。这三件事没做完就动手，大概率改错方向。我们踩过这个坑，写了份排查顺序，现在团队按这套顺序走，返工少了很多。",{},"\u002Fblog\u002Fpost-update-first-three-things",{"title":118,"description":186},"blog\u002Fpost-update-first-three-things",[192,193,194],"算法更新","排查流程","流量恢复","gGL-ueD8pi23VkaUlyRozGQuuvt9zdYNzI8VW3zJTMc",{"id":197,"title":198,"author":6,"body":199,"canonical":100,"category":274,"cover":100,"date":275,"description":276,"draft":104,"extension":105,"keywords":100,"meta":277,"navigation":107,"noindex":104,"ogImage":100,"path":278,"seo":279,"seoDescription":100,"seoTitle":100,"stem":280,"tags":281,"updated":100,"__hash__":285},"blog\u002Fblog\u002Fdirectory-url-change-301-map.md","改目录结构不掉排名：301 映射表怎么做",{"type":8,"value":200,"toc":266},[201,204,207,210,213,216,235,239,242,245,248,251,254,257,260,263],[11,202,203],{},"改 URL 结构本身不会掉排名，掉排名的是漏映射、错映射和上线顺序乱。这三次改版下来，我们最值钱的产出是一张映射表，不是技术方案。",[15,205,206],{"id":206},"映射表就五列",[11,208,209],{},"旧 URL、新 URL、类型、近 90 天点击、负责人。类型分三种：1:1 内容迁移、多对一合并、一对多拆分。",[11,211,212],{},"1:1 最好办，直接 301。合并类要确认内容真的合并了，不是把两个页都跳到首页。拆分类最麻烦——一个旧页拆成两个新页，301 只能给一个，另一个得靠内链和新 sitemap 去发现。",[15,214,215],{"id":215},"上线顺序",[217,218,219,223,226,229,232],"ol",{},[220,221,222],"li",{},"爬全站导出所有 URL，包括 sitemap 里的、内链里的、日志里被请求过的，三份合并去重。",[220,224,225],{},"按目录规则批量生成新 URL，人工抽检 10%。",[220,227,228],{},"写 301 规则，优先在 nginx 或 CDN 层做，应用层只留少数动态路由。",[220,230,231],{},"上线当天换 sitemap、替换站内链接、在两个平台提交改版。",[220,233,234],{},"旧 URL 的 301 至少保留一年，别三个月后就撤。",[15,236,238],{"id":237},"_2026-年-2-月那次改版","2026 年 2 月那次改版",[11,240,241],{},"一个 API 工具站把 \u002Fp\u002F{id} 改成语义路径，3200 个 URL。映射表里 3100 条 1:1，100 条合并。上线第 4 天新 URL 开始被抓，两周收录 2400 个，第 6 周流量回到改版前的 98%，第 10 周超过 12%。",[11,243,244],{},"过程中踩了两个坑：CDN 缓存了旧跳转结果，导致部分 URL 一直跳到 404；应用路由的正则写宽了，新 URL 也被自己的规则重定向了一次，形成循环。两个都是上线当天发现的，说明必须在上线前用三种 UA 各测一遍。",[15,246,247],{"id":247},"怎么判断映射对不对",[11,249,250],{},"上线前写脚本做一遍全量校验：对每条旧 URL 发请求，看最终落点是不是映射表里的新 URL、状态码是不是 200、跳转次数是不是 1。3200 条 URL 跑一遍几分钟，比事后查两周划算。",[15,252,253],{"id":253},"一个简化办法",[11,255,256],{},"如果新目录能按规则一一对应，别逐条写规则。比如 \u002Fp\u002F{id} 改成 \u002Fproducts\u002F{slug}，只要数据库里存了 id 和 slug 的对应关系，用一条带查表的 nginx 规则或者应用层中间件就能全量处理，比在配置里堆 3200 行靠谱得多。",[11,258,259],{},"没有一一对应关系的，才需要映射表。我们一般把映射表交给后端导入一张表，路由查表跳转，这样运营也能自己维护。",[15,261,262],{"id":262},"立场",[11,264,265],{},"别在流量高峰期改结构。选月末或者季度初，留两周观察期，这期间不做别的大改。改版期间最大的风险不是技术，是有人顺手\"优化\"了别的栏目。",{"title":91,"searchDepth":92,"depth":92,"links":267},[268,269,270,271,272,273],{"id":206,"depth":92,"text":206},{"id":215,"depth":92,"text":215},{"id":237,"depth":92,"text":238},{"id":247,"depth":92,"text":247},{"id":253,"depth":92,"text":253},{"id":262,"depth":92,"text":262},"技术SEO","2026-03-28","从 \u002Fp\u002F12345 改成 \u002Fproducts\u002Fdata-sync，几千个 URL 要映射。我们做过 3 次这类改版，关键是映射表的结构和上线顺序。这篇给可直接套用的模板和检查项。",{},"\u002Fblog\u002Fdirectory-url-change-301-map",{"title":198,"description":276},"blog\u002Fdirectory-url-change-301-map",[282,283,284],"网站迁移",301,"URL设计","Bky_vq9I0luy9BRU6q6vSYP2FB0ezPk_sbW550JInmE",1794088107271]