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