[{"data":1,"prerenderedAt":277},["ShallowReactive",2],{"blog-seo-cron-jobs":3,"blog-prev-seo-cron-jobs":104,"blog-next-seo-cron-jobs":187},{"id":4,"title":5,"author":6,"body":7,"canonical":88,"category":89,"cover":88,"date":90,"description":91,"draft":92,"extension":93,"keywords":88,"meta":94,"navigation":95,"noindex":92,"ogImage":88,"path":96,"seo":97,"seoDescription":88,"seoTitle":88,"stem":98,"tags":99,"updated":88,"__hash__":103},"blog\u002Fblog\u002Fseo-cron-jobs.md","跑 SEO 杂活的六个定时任务，怎么排才不出错","元析智能",{"type":8,"value":9,"toc":78},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75],[11,12,13],"p",{},"2026 年 3 月盘了一下我们跑的定时任务，六个，每周大概省下六小时机械劳动。定时任务的风险不在写，在没人管。一个静默失败的任务，比没有这个任务更危险，因为你会以为数据是对的。",[15,16,17],"h2",{"id":17},"六个任务",[11,19,20],{},"GSC 数据拉取，每周一凌晨；站点地图提交检查，每周一上午；死链扫描，每周二；排名快照，每周三；日志简报，每天 9 点；收录抽查，每周五。",[11,22,23],{},"这六个覆盖了我们日常要看的全部数据。再往上加就是过度自动化，比如自动改 titles、自动发文章，这类我们不做，改错了没人拦。",[15,25,26],{"id":26},"排期原则",[11,28,29],{},"别都放周一。周一凌晨是好时间，但六个任务一起跑，一个失败会影响后面的。我们按数据依赖排：先拉 GSC 数据，再跑排名快照，最后生成报告。",[11,31,32],{},"每个任务要能单独重跑，不依赖前面的中间文件。这条听着简单，实际写的时候很容易把状态存在临时文件里，一失败就得从头来。",[15,34,35],{"id":35},"失败处理",[11,37,38],{},"最危险的是静默失败。脚本报错退出，但没人看到，第二天报表是空的，大家以为这个站没数据。",[11,40,41],{},"我们的做法是心跳：每个任务跑完写一行记录到表里，包括时间和状态。另有一个检查任务，早上 8 点看所有任务最近一次成功时间，超过 26 小时没成功就在群里 @ 人。",[11,43,44],{},"26 小时这个阈值是因为日任务和月任务混在一起。日任务超过 26 小时没跑肯定有问题，周任务则由它自己的下一次运行覆盖。",[15,46,47],{"id":47},"谁维护",[11,49,50],{},"指定一个人负责，不是“大家一起看”。没有明确负责人，出问题就是互相等。",[11,52,53],{},"每季度 review 一次，把过去三个月没被任何人看过的任务删掉。我们上个季度删了一个排名监控任务，因为客户根本不看那份数据，白跑半年。",[15,55,56],{"id":56},"上线前先手动跑三次",[11,58,59],{},"定时任务最坑的是“看起来在跑”。第一次跑就写错字段的情况太常见，凌晨出错，三天后才被发现。",[11,61,62],{},"我们现在的规矩是手动跑三次，三次输出一致再挂 crontab。多花十分钟，省掉一次事故。",[15,64,65],{"id":65},"我们的排期表长什么样",[11,67,68],{},"任务用 crontab 跑，配置文件进 git，改动要提交合并请求。听着像小题大做，但你不会想体验“谁上周改了这个脚本”这种排查。",[11,70,71],{},"每个任务旁边写一行注释：它解决什么问题、失败会怎样、谁负责。三个月后自己都忘了当初为什么加。",[11,73,74],{},"日志统一写到固定目录，按任务名命名，保留 30 天。出问题先看最后 50 行，八成错误都在那里。",[11,76,77],{},"自动化不是越多越好。六个够用，第七个开始就是给自己找活干。",{"title":79,"searchDepth":80,"depth":80,"links":81},"",2,[82,83,84,85,86,87],{"id":17,"depth":80,"text":17},{"id":26,"depth":80,"text":26},{"id":35,"depth":80,"text":35},{"id":47,"depth":80,"text":47},{"id":56,"depth":80,"text":56},{"id":65,"depth":80,"text":65},null,"SEO","2026-03-11","六个定时任务每周省下六小时，但静默失败比不做更危险。这篇写任务清单、排期原则、心跳告警，以及我们每季度砍任务的规矩，看完能照着搭。",false,"md",{},true,"\u002Fblog\u002Fseo-cron-jobs",{"title":5,"description":91},"blog\u002Fseo-cron-jobs",[100,101,102],"自动化","定时任务","工作流","ut1Rob-FJ1zVcaOU9G0N9yxELWMCWWLwj02kRpti8Qo",{"id":105,"title":106,"author":6,"body":107,"canonical":88,"category":89,"cover":88,"date":176,"description":177,"draft":92,"extension":93,"keywords":88,"meta":178,"navigation":95,"noindex":92,"ogImage":88,"path":179,"seo":180,"seoDescription":88,"seoTitle":88,"stem":181,"tags":182,"updated":88,"__hash__":186},"blog\u002Fblog\u002Fbacklinks-still-work.md","外链权重在降，但这三种链接还在起作用",{"type":8,"value":108,"toc":169},[109,112,116,119,122,125,129,132,135,138,142,145,148,151,154,157,160,163,166],[11,110,111],{},"外链权重在降，但不是所有外链都没用了。还有三种在起作用：行业媒体的真实报道、开源项目和文档站的引用、客户和合作伙伴的官网互链。买的那种，2025 年以后基本清零。",[15,113,115],{"id":114},"第一种行业媒体的真实报道","第一种：行业媒体的真实报道",[11,117,118],{},"不是发稿，是报道。区别在于有没有编辑的判断和第三方信源。",[11,120,121],{},"从 2025 年 1 月起，我们给一个数据库工具客户做外链，14 个月拿到 11 篇行业媒体报道，都是因为产品有真实更新、有数据、有客户案例，记者主动写的。这批链接带来的推荐流量不多，但三个核心词的排名在两个月内各升了 4 到 7 名。",[11,123,124],{},"判断标准：这篇文章如果去掉你的产品名，还成立吗？成立，才是报道；不成立，就是软文。",[15,126,128],{"id":127},"第二种开源项目和文档站的引用","第二种：开源项目和文档站的引用",[11,130,131],{},"开发者工具类公司最该重视这类。GitHub 上的 README、awesome list、技术文档里的推荐，权重比普通外链高。",[11,133,134],{},"我们一个客户的开源 SDK，被 20 多个项目在 README 里引用，官网的文档页在 Google 上的排名比花钱做外链时还稳。这类链接的特点是自然增长，不用维护。",[11,136,137],{},"做法：把文档写好、把 SDK 维护好，然后在相关社区里真实回答问题，需要时带上链接。别群发，别拉群互赞。",[15,139,141],{"id":140},"第三种客户和合作伙伴的官网互链","第三种：客户和合作伙伴的官网互链",[11,143,144],{},"这条对 To B 软件公司特别有效。客户官网的\"技术栈\"或\"合作伙伴\"页面，链到你的产品页；你和集成伙伴互链。",[11,146,147],{},"这类链接的相关性高，来源页稳定，而且很难被判定为买卖。我们一个做客服系统的客户，拿到 30 多个客户官网的链接，都是真实使用关系，两年没掉。",[11,149,150],{},"做法：客户成功团队在交付时提一句，能不能在官网列一下。成功率大概三成，成本几乎为零。",[15,152,153],{"id":153},"怎么判断一条外链值不值",[11,155,156],{},"三个问题：来源页和你的主题相关吗？这条链接是编辑放的还是花钱买的？来源页自己有流量吗？",[11,158,159],{},"三个都过，值得争取；只过一两个，价值有限；一个都不过，别浪费时间。",[15,161,162],{"id":162},"我们不做的",[11,164,165],{},"不买链接，不做站群，不批量换友情链接，不在论坛签名里塞链接。这四件事在 2025 年之后的算法下，收益接近零，风险不小。",[11,167,168],{},"外链这件事，2026 年的正确姿势是\"少而真\"。这 14 个月我们拿到的真实外链一共不到 60 条，比不上同行一个月买的量，但没有一条被判定为垃圾。一年拿到 10 条高质量链接，比一个月买 100 条有用。",{"title":79,"searchDepth":80,"depth":80,"links":170},[171,172,173,174,175],{"id":114,"depth":80,"text":115},{"id":127,"depth":80,"text":128},{"id":140,"depth":80,"text":141},{"id":153,"depth":80,"text":153},{"id":162,"depth":80,"text":162},"2026-03-10","买的外链基本清零，但有三类链接还在起作用：行业媒体的真实报道、开源项目和文档站的引用、客户和合作伙伴的官网互链。我们按这三类做了 14 个月，附判断一条外链值不值的标准，以及我们不碰的四件事。",{},"\u002Fblog\u002Fbacklinks-still-work",{"title":106,"description":177},"blog\u002Fbacklinks-still-work",[183,184,185],"外链","链接建设","百度与Google","wH_lE_ASDX63AQTlbuRJz0v0VowWGq-bjd9aO_vlr3M",{"id":188,"title":189,"author":6,"body":190,"canonical":88,"category":265,"cover":88,"date":266,"description":267,"draft":92,"extension":93,"keywords":88,"meta":268,"navigation":95,"noindex":92,"ogImage":88,"path":269,"seo":270,"seoDescription":88,"seoTitle":88,"stem":271,"tags":272,"updated":88,"__hash__":276},"blog\u002Fblog\u002Fhreflang-canonical-conflict.md","hreflang 和 canonical 打架，多语言站最常见的错",{"type":8,"value":191,"toc":257},[192,195,198,205,211,217,221,224,227,230,233,236,239,242,245,248,251,254],[11,193,194],{},"canonical 管的是\"哪个地址是主版本\"，hreflang 管的是\"这组页面是同一内容的不同语言版本\"。两件事分工明确，但配在一起时特别容易互相拆台。最常见的错是跨语言 canonical：中文页指向英文页，理由是\"英文站是主站\"。这一指，中文页就永远不单独排名了。",[15,196,197],{"id":197},"三种冲突形态",[11,199,200,204],{},[201,202,203],"strong",{},"跨语言 canonical","：中文页 canonical 到英文对应页。看起来是\"集中权重\"，实际是告诉搜索引擎\"中文页不用单独存在\"。",[11,206,207,210],{},[201,208,209],{},"语言组里的地址不是主版本","：hreflang 指向的 URL 自己又被 canonical 到别处，整组关系混乱。",[11,212,213,216],{},[201,214,215],{},"x-default 指向一个被 canonical 掉的页面","：兜底版本不存在，等于没兜底。",[15,218,220],{"id":219},"_2026-年-1-月那个出海-saas","2026 年 1 月那个出海 SaaS",[11,222,223],{},"英文站是主域，中文站是子域。技术团队按\"主站优先\"的思路，把中文页 canonical 到英文对应页，同时两边又互相写了 hreflang。结果中文关键词的搜索结果全部展示英文页，中文站的自然点击只有英文站的 4%，客服天天收到\"你们官网为什么是英文\"的反馈。",[11,225,226],{},"改成同语言自指 canonical、完整 hreflang 组（含自引用和 x-default）之后，第 7 周中文站的自然点击涨了 5.6 倍。改动本身只有一行模板，前后差了一个季度。",[15,228,229],{"id":229},"验证方法",[11,231,232],{},"Screaming Frog 跑全站，导出 canonical 和 hreflang 两列交叉比对：canonical 指向的域名是否和本页语言一致、hreflang 组里的每个地址是否都 200 且 canonical 自指。抽 10 个页面手工看源码确认，工具报告偶尔会因为 JS 渲染漏读。",[11,234,235],{},"GSC 的\"网页\"报告可以按目录看展示份额，哪个语言版本的展示量明显低于它的页面占比，就去查那一组的配置。",[15,237,238],{"id":238},"我们的检查清单",[11,240,241],{},"每次接多语言站，我们照这四条过一遍：每个页面的 canonical 是否指向同语言自己；hreflang 组是否包含自引用；x-default 是否指向一个可访问的主版本；组里每个 URL 是否都返回 200 且没被 robots 屏蔽。四条全过，配置层面就算干净了。",[11,243,244],{},"再用 GSC 的展示数据交叉验证：中文目录的页面数占全站 40%，展示量却只有 5%，那这个语言版本的配置大概率有问题。数据永远比源码先说话。",[15,246,247],{"id":247},"正确的配置长什么样",[11,249,250],{},"中文页：canonical 指向自己，hreflang 列出自己、英文页、其他语言页，x-default 指向英文版。英文页同理。没有哪个语言版本\"更主\"。",[15,252,253],{"id":253},"立场",[11,255,256],{},"多语言站先立一个前提：每个语言版本都是独立站点，服务不同的用户群。语言之间不是主从关系。想清楚这一点，canonical 就不会乱指了。",{"title":79,"searchDepth":80,"depth":80,"links":258},[259,260,261,262,263,264],{"id":197,"depth":80,"text":197},{"id":219,"depth":80,"text":220},{"id":229,"depth":80,"text":229},{"id":238,"depth":80,"text":238},{"id":247,"depth":80,"text":247},{"id":253,"depth":80,"text":253},"技术SEO","2026-03-12","英文页 canonical 指向中文页、中文页 hreflang 指向英文页，这种配置会让两个版本互相抵消。我们用一个 2026 年 1 月的客户站讲清正确关系、三种冲突形态和验证方法。",{},"\u002Fblog\u002Fhreflang-canonical-conflict",{"title":189,"description":267},"blog\u002Fhreflang-canonical-conflict",[273,274,275],"hreflang","canonical","多语言","DZzGyUZlJ7S65t1gwaJvbdythbuAcUY6tKBGfOpnPQo",1794088107706]