[{"data":1,"prerenderedAt":283},["ShallowReactive",2],{"blog-new-site-sandbox-baidu":3,"blog-prev-new-site-sandbox-baidu":115,"blog-next-new-site-sandbox-baidu":187},{"id":4,"title":5,"author":6,"body":7,"canonical":99,"category":100,"cover":99,"date":101,"description":102,"draft":103,"extension":104,"keywords":99,"meta":105,"navigation":106,"noindex":103,"ogImage":99,"path":107,"seo":108,"seoDescription":99,"seoTitle":99,"stem":109,"tags":110,"updated":99,"__hash__":114},"blog\u002Fblog\u002Fnew-site-sandbox-baidu.md","百度新站沙盒期到底多久：我们跟了 6 个站","元析智能",{"type":8,"value":9,"toc":89},"minimark",[10,14,19,22,25,28,31,35,38,41,44,47,50,53,56,59,62,65,68,71,74,77,80,83,86],[11,12,13],"p",{},"百度没有官方承认的\"沙盒期\"，但我们跟的 6 个新站里，5 个在前 3 个月有不同程度的低展现，平均 11 周后才开始稳定出词。这不是玄学，是能记录的现象。",[15,16,18],"h2",{"id":17},"_6-个站的记录","6 个站的记录",[11,20,21],{},"2025 年 10 月到 2026 年 6 月，6 个新站，域名都是新注册的，行业包括 SaaS、开发者工具、设计工具。",[11,23,24],{},"记录三个数：收录量、有展现的词数、排名进入前 50 的词数。",[11,26,27],{},"第 4 周：收录 30 到 120 页，有展现的词 0 到 8 个。\n第 8 周：收录 80 到 400 页，有展现的词 5 到 30 个。\n第 11 周：多数站开始出现排名进前 50 的词，数量在 10 到 40 个。\n第 16 周：才进入比较稳定的状态。",[11,29,30],{},"6 个站里唯一例外的是一个有老域名 301 过来的站，第 5 周就开始出词。",[15,32,34],{"id":33},"什么叫低展现期","什么叫\"低展现期\"",[11,36,37],{},"不是不收录，是收录了不给展现。页面在索引里，site: 能查到，但搜目标词搜不到。",[11,39,40],{},"这个阶段最容易误判。客户看到收录量涨了，以为一切正常，其实流量还是零。也有人看到没流量，以为站废了，开始乱改。",[11,42,43],{},"判断方法：在流量与关键词里看\"展现次数\"。连续两周展现次数低于 50，就是低展现期，不用慌。",[15,45,46],{"id":46},"哪些事能缩短",[11,48,49],{},"第一，备案和站点验证早点做完。我们 6 个站里有 2 个备案拖了 3 周，出词时间明显晚。",[11,51,52],{},"第二，内容别停。低展现期每周保持 2 到 3 篇更新，百度对活跃站的评估更好。我们一个客户停了 3 周，恢复更新后出词又延后了两周。",[11,54,55],{},"第三，外链从第 4 周开始做。有真实外链的站，低展现期平均短 2 周。",[11,57,58],{},"第四，内链结构从第一天就搭好。新站最怕页面孤立，蜘蛛爬到深处就没路。",[15,60,61],{"id":61},"哪些事没用",[11,63,64],{},"反复提交 URL。我们对比过，每天提交和每周提交，出词时间没有差异。",[11,66,67],{},"频繁改标题。低展现期改标题，等于重新开始积累，我们见过客户一周改一次，三个月没出词。",[11,69,70],{},"换模板、换域名。这些动作只会让百度重新评估，时间重新计时。",[15,72,73],{"id":73},"一个反常的发现",[11,75,76],{},"6 个站里，出词最快的那个不是内容最多的，是内容最少但最垂直的：只写产品功能相关的 40 篇文章，没有一篇行业泛文。",[11,78,79],{},"第 9 周就出了 30 多个有展现的词。我们复盘时认为，垂直内容让百度更快判断这个站是干什么的，主题聚焦度比数量重要。",[11,81,82],{},"这个发现后来影响了我们所有的内容排期：新站前 3 个月，只写和产品直接相关的内容，不追热点。",[15,84,85],{"id":85},"一句判断",[11,87,88],{},"新站进百度，按 3 个月预期，别按 3 周。这个阶段比的不是技巧，是谁能稳住不动、持续更新。急着要结果的，通常会把这个阶段拖得更长。",{"title":90,"searchDepth":91,"depth":91,"links":92},"",2,[93,94,95,96,97,98],{"id":17,"depth":91,"text":18},{"id":33,"depth":91,"text":34},{"id":46,"depth":91,"text":46},{"id":61,"depth":91,"text":61},{"id":73,"depth":91,"text":73},{"id":85,"depth":91,"text":85},null,"行业观察","2026-07-18","百度没有官方承认的沙盒期，但我们跟的 6 个新站里，5 个在前 3 个月有低展现期，平均 11 周后才稳定出词。哪些事能缩短、哪些纯属白做，这篇按 6 个站的记录写清楚，附一个我们没料到的发现。6 个站的记录都在正文里。",false,"md",{},true,"\u002Fblog\u002Fnew-site-sandbox-baidu",{"title":5,"description":102},"blog\u002Fnew-site-sandbox-baidu",[111,112,113],"百度新站","沙盒期","收录","h4DLJs65feU8w2KSkE5uhvLFNggTIJgFtFaUXuG1f10",{"id":116,"title":117,"author":6,"body":118,"canonical":99,"category":176,"cover":99,"date":177,"description":178,"draft":103,"extension":104,"keywords":99,"meta":179,"navigation":106,"noindex":103,"ogImage":99,"path":180,"seo":181,"seoDescription":99,"seoTitle":99,"stem":182,"tags":183,"updated":99,"__hash__":186},"blog\u002Fblog\u002Fcloud-region-pages-seo.md","云服务的区域页，一个 region 一页才吃得到流量",{"type":8,"value":119,"toc":170},[120,123,126,129,132,135,138,141,144,152,155,158,161,164,167],[11,121,122],{},"云服务官网的区域信息，通常塞在一张表格里，或者藏在文档的“可用区”章节。这是个明显的浪费。2025 年 10 月我们给一个出海云厂商重做区域信息，把 9 个 region 拆成 9 个独立页面，到 2026 年 4 月这组页面每月带来 2300 多次自然访问，累计 1.4 万，企业咨询涨了三成。",[15,124,125],{"id":125},"用户为什么要搜区域",[11,127,128],{},"三类需求。出海团队选部署地，关心到目标市场的延迟和合规；架构师做多活方案，关心可用区之间的网络；采购关心数据存哪、发票怎么开、当地有没有实体。",[11,130,131],{},"搜索词很具体：“新加坡 机房 延迟 中国”“法兰克福 数据驻留 要求”“日本 region 可用区 数量”。这些词量不大，但搜的人已经在做技术决策。",[15,133,134],{"id":134},"一个区域页写什么",[11,136,137],{},"六块内容：机房位置和可用区数量、到主要城市的实测延迟、本地合规说明（数据驻留、认证）、支持的实例类型和价格区间、网络出口和专线接入、以及本地支持的语言和时段。",[11,139,140],{},"第二块最值钱。我们让客户跑了一批真实的探测数据，给出到上海、深圳、东京、法兰克福的往返延迟中位数，写成表格。这种数据同行很少公开，用户会截图保存。",[15,142,143],{"id":143},"结构化数据别忘",[11,145,146,147,151],{},"区域页可以用结构化数据标注组织信息和价格区间，能让搜索结果更完整。另外，每个区域页要有独立 URL，别用 ",[148,149,150],"code",{},"?region=xxx"," 参数，参数页往往不被单独索引。",[11,153,154],{},"页面之间要互链：区域页链到价格页、文档的部署指南、以及“多区域架构”的白皮书。这样用户从“查延迟”能一路走到“看方案”。",[11,156,157],{},"区域页的转化路径要想清楚。用户看完延迟数据，下一步通常是看价格和合规说明，所以我们把这两块放在页面底部，不跳转，原地展开。路径越短，咨询越多，这条在云产品上特别明显。",[15,159,160],{"id":160},"一个现实约束",[11,162,163],{},"区域页不能编。机房位置、可用区数量、认证状态，这些是硬信息，写错了是合规问题。我们要求客户每季度核对一次，尤其是新开区域和认证更新的时间点。",[11,165,166],{},"还有个细节：区域页要写清“数据存在哪里”和“谁能访问”。出海客户对这两件事极其敏感，写清楚能减少大量售前沟通。",[11,168,169],{},"云服务的内容，很多团队把力气花在“产品能力”上，其实“在哪、多快、合不合规”才是用户搜索的第一批问题。区域页就是回答这批问题的页面。",{"title":90,"searchDepth":91,"depth":91,"links":171},[172,173,174,175],{"id":125,"depth":91,"text":125},{"id":134,"depth":91,"text":134},{"id":143,"depth":91,"text":143},{"id":160,"depth":91,"text":160},"技术SEO","2026-07-17","用户会搜“XX 云 新加坡 机房”“XX 云 法兰克福 延迟”。我们把 9 个区域拆成独立页，半年带来 1.4 万自然访问，企业咨询多了三成。",{},"\u002Fblog\u002Fcloud-region-pages-seo",{"title":117,"description":178},"blog\u002Fcloud-region-pages-seo",[184,185,176],"云服务","区域页","TU8ALFzVzOLAQYVqfOE_My1PTr3gC4c3-IifCNuXRAI",{"id":188,"title":189,"author":6,"body":190,"canonical":99,"category":100,"cover":99,"date":272,"description":273,"draft":103,"extension":104,"keywords":99,"meta":274,"navigation":106,"noindex":103,"ogImage":99,"path":275,"seo":276,"seoDescription":99,"seoTitle":99,"stem":277,"tags":278,"updated":99,"__hash__":282},"blog\u002Fblog\u002Fseo-project-scheduling.md","SEO 项目排期，前三个月别排满内容",{"type":8,"value":191,"toc":264},[192,195,198,201,204,207,210,213,216,219,222,225,228,231,234,237,240,243,246,249,252,255,258,261],[11,193,194],{},"2026 年 7 月我们接手一个延期三个月的项目，翻排期表发现第一个月排了 20 篇内容、加上技术修复和外链建设，全挤在一起。执行到第三周就卡住了。SEO 项目排期最常见的错误是把所有事排在同一时间段。",[15,196,197],{"id":197},"阶段要分开",[11,199,200],{},"第一个月做技术。收录、抓取、加载速度、结构化数据、内链结构。这些是地基，做完才能谈内容效果。",[11,202,203],{},"第二个月做内容基建。核心页面重写、产品页优化、文档结构整理。同时开始小批量内容测试，一周两篇，看收录和曝光。",[11,205,206],{},"第三个月开始放量。内容一周三到四篇，外链同步启动。",[11,208,209],{},"三个阶段有重叠但不能同时全开。同时开的结果是每件都做一半。",[15,211,212],{"id":212},"为什么前三个月别排满内容",[11,214,215],{},"新站的内容在头两个月基本看不到效果，排满了只会让客户在第 45 天问“为什么没效果”。",[11,217,218],{},"更重要的是，技术问题没修完就大量发内容，等于往漏水的桶里倒水。我们见过一个站，产品页全被 noindex 了还在发博客，发了 30 篇一篇都没收录。",[15,220,221],{"id":221},"验收节点怎么设",[11,223,224],{},"不按篇数设，按状态设。第一个月验收：核心页面全部可抓可收、加载速度进入合格区间、日志里蜘蛛抓取频次正常。",[11,226,227],{},"第二个月验收：核心词开始有曝光、落地页有内链、结构化数据无明显错误。",[11,229,230],{},"第三个月验收：内容开始有自然点击、转化路径跑通、周报数据能稳定产出。",[11,232,233],{},"每个节点都要有客户能自己验证的东西，别用“优化完成”“效果良好”这种词。",[15,235,236],{"id":236},"排期表要写清依赖",[11,238,239],{},"每条任务写三样：谁做、依赖谁、什么时候要。依赖客户的任务单独标出来，比如“等产品文档更新”“等开发排期”。",[11,241,242],{},"我们见过最常见的延期原因是等客户，而不是我们慢。把依赖写进排期表，延期的时候有据可查。",[15,244,245],{"id":245},"排期要留返工余量",[11,247,248],{},"每个阶段留一周缓冲。技术改动经常需要回滚重做，内容经常要返工，不留余量的排期表第一周就开始欠账。",[11,250,251],{},"我们现在的做法是 12 周的计划按 10 周排，剩下两周当缓冲。客户看到的还是 12 周，但我们心里有底。",[15,253,254],{"id":254},"一个排期模板",[11,256,257],{},"我们把项目分成 12 周，每周一张卡片，卡片上写这一周的三件主任务和两个备选。主任务必须完成，备选做不完顺延。",[11,259,260],{},"每周五和客户同步一次，只看三件事：完成了什么、卡在哪、下周改什么。",[11,262,263],{},"这个模板不复杂，但它强迫双方每周面对一次现实。排期表最怕的是写完就锁进抽屉，三个月后再翻出来对账。",{"title":90,"searchDepth":91,"depth":91,"links":265},[266,267,268,269,270,271],{"id":197,"depth":91,"text":197},{"id":212,"depth":91,"text":212},{"id":221,"depth":91,"text":221},{"id":236,"depth":91,"text":236},{"id":245,"depth":91,"text":245},{"id":254,"depth":91,"text":254},"2026-07-19","排期表上第一个月就写满 20 篇，执行到第三周一定卡住。这篇写我们按阶段排期的做法：技术、内容、外链各占多少，以及验收节点怎么设，项目延期多半是排期结构的问题。",{},"\u002Fblog\u002Fseo-project-scheduling",{"title":189,"description":273},"blog\u002Fseo-project-scheduling",[279,280,281],"项目排期","SEO项目","交付管理","bo9R63-xBkZIWUB5Rbr0FLMgr7BjhsfOSk50voxJADw",1794088103670]