[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-seo-deliverables-list":3,"blog-prev-seo-deliverables-list":119,"blog-next-seo-deliverables-list":216},{"id":4,"title":5,"author":6,"body":7,"canonical":103,"category":104,"cover":103,"date":105,"description":106,"draft":107,"extension":108,"keywords":103,"meta":109,"navigation":110,"noindex":107,"ogImage":103,"path":111,"seo":112,"seoDescription":103,"seoTitle":103,"stem":113,"tags":114,"updated":103,"__hash__":118},"blog\u002Fblog\u002Fseo-deliverables-list.md","SEO 项目的交付物清单，缺一项就会扯皮","元析智能",{"type":8,"value":9,"toc":93},"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,90],[11,12,13],"p",{},"2026 年 8 月我们复盘了两个结束的项目，客户满意度差别很大，原因不在效果，在交付物清不清楚。一个项目每周有固定的东西可看，另一个只有月末一份报告。交付物不是只有报告。",[15,16,17],"h2",{"id":17},"九项固定交付",[11,19,20],{},"诊断报告，一次，项目开始时交。技术修复清单，一次，带优先级。内容计划表，一次，季度更新。",[11,22,23],{},"每周数据简报，一条消息。每月完整报告，一份文档。内容稿件的审校记录，每篇一份。",[11,25,26],{},"技术改动记录，每次改动一行。关键词排名追踪表，每周更新。季度复盘，一次，带下一步计划。",[11,28,29],{},"这九项写进合同附件，每项标清频率和格式。",[15,31,32],{"id":32},"每项都要能验收",[11,34,35],{},"“每周简报”这四个字不够，要写清：每周一上午发出、包含四个数字、用固定模板。",[11,37,38],{},"“内容审校记录”要写清：记录谁审的、改了什么、修改前后对比。",[11,40,41],{},"验收标准写得越具体，月底吵架的概率越低。我们见过最模糊的合同写“定期提供优化建议”，结果双方对“定期”的理解差了十倍。",[15,43,44],{"id":44},"交付物的格式",[11,46,47],{},"数据简报用群消息，控制在手机一屏能读完。",[11,49,50],{},"月度报告用文档，5 页以内，附录放明细。",[11,52,53],{},"技术改动记录用表格，一行一次改动：日期、页面、改了什么、谁改的、为什么改。",[11,55,56],{},"内容稿件用共享文档，保留修改痕迹。",[11,58,59],{},"格式不重要，重要的是每次一样。客户知道去哪找什么，就不用每次问你。",[15,61,62],{"id":62},"一个容易忽略的交付物",[11,64,65],{},"技术改动的记录。很多项目做完，客户不知道自己站被改了什么，换了服务商之后发现一堆奇怪配置，说不清是谁弄的。",[11,67,68],{},"我们现在的规矩是每次改生产环境都记一行，包括改回滚。这个记录对客户有价值，对我们也是保护。",[15,70,71],{"id":71},"交付物要有存档",[11,73,74],{},"所有交付物存到一个共享目录，按项目、按月份分。客户换人、我们换人，都能直接找到。",[11,76,77],{},"我们吃过亏：一个项目做了一年，客户换了市场负责人，新来的人问你们都做了什么，我们翻了两天才把材料找齐。从那以后存档成了硬规矩。",[15,79,80],{"id":80},"交付物不是越多越好",[11,82,83],{},"九项是上限。有的项目只需要五项，硬凑到九项就是给自己找活。",[11,85,86],{},"判断标准是：这项交付物客户会不会看、看了会不会用。不会看的就别做，做了也是形式。",[11,88,89],{},"我们上个季度砍掉了两个交付物：一个是每周的竞品动态，客户从来不看；一个是每月的关键词新增清单，和排名表重复。",[11,91,92],{},"清单的目的是减少扯皮，不是增加工作量。这个度要自己把握。",{"title":94,"searchDepth":95,"depth":95,"links":96},"",2,[97,98,99,100,101,102],{"id":17,"depth":95,"text":17},{"id":32,"depth":95,"text":32},{"id":44,"depth":95,"text":44},{"id":62,"depth":95,"text":62},{"id":71,"depth":95,"text":71},{"id":80,"depth":95,"text":80},null,"行业观察","2026-07-29","交付物不是只有报告。这篇列出我们每个项目固定交付的九项内容，写清每项的格式、频率和验收方式，避免月底为做没做争论，附九项清单和验收写法。",false,"md",{},true,"\u002Fblog\u002Fseo-deliverables-list",{"title":5,"description":106},"blog\u002Fseo-deliverables-list",[115,116,117],"交付管理","验收","项目流程","WBRCsigDuXTWaAUqHk1R6epXYV-bOzduvpYIbtyhBQo",{"id":120,"title":121,"author":6,"body":122,"canonical":103,"category":204,"cover":103,"date":205,"description":206,"draft":107,"extension":108,"keywords":103,"meta":207,"navigation":110,"noindex":107,"ogImage":103,"path":208,"seo":209,"seoDescription":103,"seoTitle":103,"stem":210,"tags":211,"updated":103,"__hash__":215},"blog\u002Fblog\u002Fbaidu-crawl-diagnosis-errors.md","百度抓取诊断报 403 和 503，我们怎么查源站",{"type":8,"value":123,"toc":195},[124,127,130,133,136,139,143,146,149,152,156,159,162,165,168,171,174,177,180,183,186,189,192],[11,125,126],{},"抓取诊断报 403 或 503，九成不是百度的问题，是源站的防火墙、CDN 或 UA 拦截把蜘蛛挡了。2025 年到现在我们处理过 20 多次这类问题，原因就三种。",[15,128,129],{"id":129},"先确认是不是真的被挡",[11,131,132],{},"抓取诊断会给出状态码和抓取时间。403 是拒绝访问，503 是服务不可用。",[11,134,135],{},"两件事要确认：一是你自己用浏览器访问同一个 URL 是否正常；二是换个时间再诊断一次，排除偶发。",[11,137,138],{},"如果浏览器正常、诊断稳定报错，基本就是蜘蛛被针对性拦截了。",[15,140,142],{"id":141},"_403-的三种原因","403 的三种原因",[11,144,145],{},"第一，CDN 或 WAF 的安全策略。很多云厂商的默认规则会拦截\"非浏览器 UA\"，百度蜘蛛的 UA 里有 Baiduspider 字样，被当成爬虫挡掉。",[11,147,148],{},"第二，服务器的 UA 黑白名单。运维为了防采集，配了只允许常见浏览器 UA，把搜索引擎也挡了。",[11,150,151],{},"第三，IP 段被封。站点被恶意爬过之后，运维封了一批 IP，误伤了百度蜘蛛的出口 IP。",[15,153,155],{"id":154},"_503-的两种原因","503 的两种原因",[11,157,158],{},"第一，源站负载高。蜘蛛来的时候正好赶上资源紧张，返回 503。这类问题通常伴随偶发，抓取诊断多试几次能复现。",[11,160,161],{},"第二，限流配置。Nginx 或云防火墙的限流规则太严，蜘蛛的并发请求触发了限流。",[15,163,164],{"id":164},"怎么验证",[11,166,167],{},"我们一般做三步。第一步，用 curl 带上百度蜘蛛的 UA 请求页面，看返回码。第二步，反查请求来源 IP 是否属于百度，百度蜘蛛的 IP 可以通过 DNS 反查确认。第三步，看服务器访问日志里百度蜘蛛的请求量和状态码分布。",[11,169,170],{},"三步做完，问题基本定位。我们最近一次排查，日志里百度蜘蛛的 403 占 78%，原因就是 CDN 的 UA 规则。",[15,172,173],{"id":173},"修复",[11,175,176],{},"CDN 和 WAF 加白名单，放行百度蜘蛛的 UA 和 IP 段；服务器 UA 规则里加搜索引擎的 UA；限流规则给蜘蛛单独放宽。",[11,178,179],{},"改完在抓取诊断里重新抓一次，确认状态码 200。再观察一周抓取频次有没有恢复。",[15,181,182],{"id":182},"一个反复出现的坑",[11,184,185],{},"换 CDN 之后忘了同步白名单，是我们遇到最多的情况。今年 3 月一个客户迁移 CDN，迁移当晚百度蜘蛛就被挡了，抓取诊断全报 403，三天后才发现。",[11,187,188],{},"这类问题的特点是：站点访问正常、Google 也正常（Google 的爬虫 IP 段被新 CDN 默认放行），只有百度有问题。所以盯抓取诊断，比盯总流量更早发现问题。",[15,190,191],{"id":191},"一句判断",[11,193,194],{},"这类问题最冤的地方在于：站点本身没问题，内容也没问题，就是被自己的安全配置挡在门外。上线新站或者换 CDN 之后，第一件事应该是跑一次抓取诊断。",{"title":94,"searchDepth":95,"depth":95,"links":196},[197,198,199,200,201,202,203],{"id":129,"depth":95,"text":129},{"id":141,"depth":95,"text":142},{"id":154,"depth":95,"text":155},{"id":164,"depth":95,"text":164},{"id":173,"depth":95,"text":173},{"id":182,"depth":95,"text":182},{"id":191,"depth":95,"text":191},"技术SEO","2026-07-28","抓取诊断报 403 或 503，九成不是百度的问题，是源站的防火墙、CDN 或 UA 拦截把蜘蛛挡了。我们处理过 20 多次这类问题，我们处理过 20 多次这类问题，验证方法、三种常见原因和修复动作都在这篇，也写了一个反复出现的坑。",{},"\u002Fblog\u002Fbaidu-crawl-diagnosis-errors",{"title":121,"description":206},"blog\u002Fbaidu-crawl-diagnosis-errors",[212,213,214],"抓取诊断","百度蜘蛛","服务器配置","1pGDtS726_J6ZzmleXPsT2QRcXXBAVXBNK823jlftRg",{"id":217,"title":218,"author":6,"body":219,"canonical":103,"category":204,"cover":103,"date":275,"description":276,"draft":107,"extension":108,"keywords":103,"meta":277,"navigation":110,"noindex":107,"ogImage":103,"path":278,"seo":279,"seoDescription":103,"seoTitle":103,"stem":280,"tags":281,"updated":103,"__hash__":285},"blog\u002Fblog\u002Fcdn-waf-blocking-crawlers.md","CDN 和防火墙把蜘蛛拦了，日志里看不出来的坑",{"type":8,"value":220,"toc":267},[221,224,227,230,234,237,240,243,246,249,252,255,258,261,264],[11,222,223],{},"蜘蛛被拦分两种：一种能被日志看见，比如 403、429；另一种看不见，CDN 直接在边缘返回验证页或者在网络层丢弃，源站日志里一条记录都没有。第二种最要命，因为你在日志里找不到任何证据。",[15,225,226],{"id":226},"怎么发现",[11,228,229],{},"GSC 抓取统计里请求量突然归零，但站点本身访问正常，大概率是被拦了。百度搜索资源平台的抓取诊断会报\"抓取失败\"，或者返回的内容不是你的页面。日志里 Googlebot UA 的请求数变成 0，而其他 UA 正常。最直接的验证方法：找一台海外 VPS，用 curl 带蜘蛛 UA 请求首页，看返回什么。",[15,231,233],{"id":232},"_2025-年-11-月那次","2025 年 11 月那次",[11,235,236],{},"一个客户上线新的 WAF，默认规则把 UA 里含 \"bot\" 的请求全部拦截。Google 抓取量三天内从每天 4000 次掉到 200 次，他们一直以为是\"算法波动\"，第 6 周才找我们。恢复访问后两周抓取量回来，但掉下去的那批关键词排名过了两个月才补回来一部分。",[15,238,239],{"id":239},"白名单怎么配",[11,241,242],{},"Google 和 Bing 都提供官方 IP 段或者反向 DNS 验证方式，百度也有官方 IP 列表。别只按 UA 做白名单——UA 可以伪造，安全团队也不接受这种规则。用 IP 段加反向解析双重校验，既安全又不误伤。",[11,244,245],{},"Cloudflare 这类 CDN 有自己的\"已验证机器人\"机制，直接打开就行，别自己写规则。",[15,247,248],{"id":248},"一个排查清单",[11,250,251],{},"发现抓取量异常时，按这个顺序查：GSC 抓取统计是不是全站归零；百度抓取诊断能不能抓到；日志里蜘蛛 UA 的请求数；CDN 后台的拦截日志（很多厂商有这个报表）；安全产品的拦截规则里有没有 bot、crawler 这类关键词。五步走完，基本能定位到是哪一层拦的。",[11,253,254],{},"如果是 CDN 厂商的默认防护拦的，让他们把已验证机器人放行；如果是自己配的规则，加 IP 段白名单。改完立刻用 curl 验证，别等第二天看数据。",[15,256,257],{"id":257},"上线安全产品前必须做的一件事",[11,259,260],{},"跑一次蜘蛛访问测试：用 Googlebot、Bingbot、Baiduspider 的 UA 和官方 IP 各请求一次核心页面，确认返回 200 和正常 HTML。这次测试要写进变更流程，和\"上线后检查监控\"同等重要。",[15,262,263],{"id":263},"立场",[11,265,266],{},"安全团队和 SEO 团队的矛盾不会消失，但可以靠流程解决：任何影响入口流量的变更，上线前必须验证蜘蛛可达。这一条比事后排查六周便宜太多。",{"title":94,"searchDepth":95,"depth":95,"links":268},[269,270,271,272,273,274],{"id":226,"depth":95,"text":226},{"id":232,"depth":95,"text":233},{"id":239,"depth":95,"text":239},{"id":248,"depth":95,"text":248},{"id":257,"depth":95,"text":257},{"id":263,"depth":95,"text":263},"2026-07-30","蜘蛛被 WAF 拦掉时，日志里可能只剩空白或者 403，甚至完全没有记录。我们遇到 5 次这类事故，最久的一次被拦了 6 周。这篇讲怎么发现、怎么配白名单、怎么进变更流程。",{},"\u002Fblog\u002Fcdn-waf-blocking-crawlers",{"title":218,"description":276},"blog\u002Fcdn-waf-blocking-crawlers",[282,283,284],"抓取","CDN","日志分析","5bNahw7QT6DYXnyBi6VjmAhnmSjig7EZZMAM8C_29fk",1794088103367]