[{"data":1,"prerenderedAt":255},["ShallowReactive",2],{"blog-baidu-api-index-submission":3,"blog-prev-baidu-api-index-submission":109,"blog-next-baidu-api-index-submission":177},{"id":4,"title":5,"author":6,"body":7,"canonical":93,"category":94,"cover":93,"date":95,"description":96,"draft":97,"extension":98,"keywords":93,"meta":99,"navigation":100,"noindex":97,"ogImage":93,"path":101,"seo":102,"seoDescription":93,"seoTitle":93,"stem":103,"tags":104,"updated":93,"__hash__":108},"blog\u002Fblog\u002Fbaidu-api-index-submission.md","百度普通收录 API：从手动提交到脚本自动跑","元析智能",{"type":8,"value":9,"toc":84},"minimark",[10,14,18,21,32,35,38,41,44,48,51,54,57,60,63,66,69,72,75,78,81],[11,12,13],"p",{},"手动提交 URL 费时还容易漏。我们把百度普通收录 API 接进发布流程，每天自动推 30 条，半年省下约 40 小时。接口本身很简单，难在提交策略。",[15,16,17],"h2",{"id":17},"接口长什么样",[11,19,20],{},"百度普通收录 API 是一个 HTTP 请求，site 和 token 在搜索资源平台后台拿：",[22,23,28],"pre",{"className":24,"code":26,"language":27},[25],"language-text","curl -H 'Content-Type:text\u002Fplain' \\\n  --data-binary @urls.txt \\\n  'http:\u002F\u002Fdata.zz.baidu.com\u002Furls?site=https:\u002F\u002Fwww.example.com&token=xxx'\n","text",[29,30,26],"code",{"__ignoreMap":31},"",[11,33,34],{},"urls.txt 一行一条 URL，返回 JSON，里面有本次成功条数和剩余配额。就这么点东西，20 行脚本能跑通。",[15,36,37],{"id":37},"我们的脚本怎么跑",[11,39,40],{},"发布流程里加一步：新内容上线后，脚本从数据库取当天新增的 URL，过滤掉重复提交过的，拼成 urls.txt，调接口，把返回结果记日志。",[11,42,43],{},"两个细节。一是去重表，同一个 URL 只推一次，重复推不增加收录，还浪费配额。二是失败重试，接口偶尔超时，脚本第二天自动补推，不人工介入。",[15,45,47],{"id":46},"提交策略只推这四类-url","提交策略：只推这四类 URL",[11,49,50],{},"配额有限，什么 URL 都推等于没推。我们只推四类：新发布的文章、新上线的产品页、有搜索需求但还没收录的页面、更新过核心内容的老页面。",[11,52,53],{},"不推的：分类页、标签页、分页、搜索结果页、参数页。这些页面推了也大概率不收，收了也是低质页面。",[15,55,56],{"id":56},"快速收录和普通收录别搞混",[11,58,59],{},"搜索资源平台里有两个接口：普通收录和快速收录。快速收录不是所有站都有，需要站点有相应权益，别照着旧教程硬调，调不通先看后台有没有这个入口。",[11,61,62],{},"普通收录是保底的。我们所有站都接普通收录，快速收录只给有权益的站配，两者不冲突。",[15,64,65],{"id":65},"常见错误码",[11,67,68],{},"返回 401 是 token 不对；403 是配额用完或者站点没验证；400 常见于 URL 格式错误，比如带空格、没写协议头。",[11,70,71],{},"还有一个坑：同一批里有一条 URL 格式不对，整批可能失败。我们的脚本会先做格式校验，再提交。",[15,73,74],{"id":74},"效果和一个提醒",[11,76,77],{},"2025 年 8 月接入，到今年 1 月正好半年。一个 800 页的站，接 API 之前手动提交，一周推 60 条左右，收录周期 5 到 9 天。接完之后每天推 30 条，收录周期缩到 3 到 6 天，人工投入几乎为零。",[11,79,80],{},"提醒一句：提交只是告知，不是保证收录。我们见过客户每天推满配额，收录率还是不到 30%，问题在页面质量，不在接口。先把页面做好，再用 API 提效，顺序别反。",[11,82,83],{},"半年复盘：这个站的人工提交时间从每周 70 分钟降到 5 分钟，收录周期稳定在 3 到 6 天。今天这篇就是脚本自动推的，推完 4 天收录。对一个日更的站，这个时间差会放大，人工根本盯不过来。",{"title":31,"searchDepth":85,"depth":85,"links":86},2,[87,88,89,90,91,92],{"id":17,"depth":85,"text":17},{"id":37,"depth":85,"text":37},{"id":46,"depth":85,"text":47},{"id":56,"depth":85,"text":56},{"id":65,"depth":85,"text":65},{"id":74,"depth":85,"text":74},null,"技术SEO","2025-12-29","手动提交 URL 费时还容易漏。我们把百度普通收录 API 接进发布流程，每天自动推 30 条，半年省下约 40 小时。接口用法、提交策略、常见错误码和踩过的坑，这篇一次讲完，最后一节是我们半年后的复盘，照着做能省出每周一小时。",false,"md",{},true,"\u002Fblog\u002Fbaidu-api-index-submission",{"title":5,"description":96},"blog\u002Fbaidu-api-index-submission",[105,106,107],"百度收录","API","自动化","ryB5loOd061VIlJKAxV1Q26u0OTCmcRbqDzd7DNpNLk",{"id":110,"title":111,"author":6,"body":112,"canonical":93,"category":94,"cover":93,"date":166,"description":167,"draft":97,"extension":98,"keywords":93,"meta":168,"navigation":100,"noindex":97,"ogImage":93,"path":169,"seo":170,"seoDescription":93,"seoTitle":93,"stem":171,"tags":172,"updated":93,"__hash__":176},"blog\u002Fblog\u002Fsoc2-compliance-page-seo.md","合规页怎么做才能带来 B2B 搜索流量",{"type":8,"value":113,"toc":160},[114,117,120,123,126,129,132,135,138,141,144,148,151,154,157],[11,115,116],{},"合规页是 B2B 软件站里搜索意图最靠后的页面之一，也是最容易被做成一个 PDF 的页面。2025 年 10 月我们给一个做数据同步的 SaaS 重做合规区，把 6 页 PDF 拆成 14 个可索引的页面，到 2026 年 1 月这组页面带来 32 条企业线索，占同期官网线索的 19%。",[15,118,119],{"id":119},"谁在搜这些词",[11,121,122],{},"三类人：采购方的安全负责人、法务、以及填供应商问卷的实施人员。他们搜的是很具体的问题：“XX 是否支持 SOC 2 Type II”“数据存储在哪”“子处理商有哪些”“渗透测试多久做一次”。",[11,124,125],{},"这些问题每一个都值得一个页面。你把答案放进 PDF，搜索引擎读不到，AI 回答引擎也读不到，采购方只能去问你的销售，链路长了三倍。",[15,127,128],{"id":128},"页面结构怎么定",[11,130,131],{},"一个合规页要回答四层：认证是什么、覆盖哪些范围、有效期到什么时候、怎么拿到报告。最后一层是关键，用户要的是“怎么验证”，不是“我们有认证”。",[11,133,134],{},"我们的写法是在每个页面顶部放一张状态卡：认证名、状态（已获得\u002F进行中）、覆盖的产品线、报告申请入口。下面再展开说明。这个卡片用结构化数据标一下，Google 有时会在结果里直接展示。",[15,136,137],{"id":137},"常见的搜索词清单",[11,139,140],{},"按我们的经验，值得单独做页面的有：SOC 2、ISO 27001、ISO 27701、GDPR 数据处理、数据驻留区域、子处理商列表、漏洞披露政策、渗透测试说明、业务连续性、备份与恢复。",[11,142,143],{},"子处理商列表这页特别值得做，很多采购流程里必查，但很少有公司公开。我们做了之后，有个客户反馈说销售周期平均缩短了 5 天，因为不用来回发邮件确认。",[15,145,147],{"id":146},"别写空话写边界","别写空话，写边界",[11,149,150],{},"合规内容最怕写“我们高度重视安全”。改成写边界：“日志保留 90 天，企业版可延长到 12 个月”“数据默认存新加坡，可选法兰克福”。写清边界的页面转化率高，因为它帮采购方快速判断能不能用。",[11,152,153],{},"还有一个细节：合规页的 URL 要稳定。有客户把合规页放在帮助中心里，改版时路径变了，外链全断。这类页面被采购方收藏的概率高，URL 别乱动。",[11,155,156],{},"再补一个操作细节：合规页之间要互链。用户从 SOC 2 页会想点开子处理商、数据驻留、备份策略，这几个问题经常连着问。互链之后，单次访问的页面数从 1.3 到 2.8。",[11,158,159],{},"合规页的流量不大，一个词每月几十次搜索就算不错。但它的转化率是博客的十倍以上。做这块别用流量思维算账。",{"title":31,"searchDepth":85,"depth":85,"links":161},[162,163,164,165],{"id":119,"depth":85,"text":119},{"id":128,"depth":85,"text":128},{"id":137,"depth":85,"text":137},{"id":146,"depth":85,"text":147},"2025-12-28","SOC 2、ISO 27001 这类合规页，多数公司只放一个 PDF 下载。我们把它做成搜索落地页，一个客户的合规页半年带来 30 多个企业线索。",{},"\u002Fblog\u002Fsoc2-compliance-page-seo",{"title":111,"description":167},"blog\u002Fsoc2-compliance-page-seo",[173,174,175],"合规页","B2B SEO","安全软件","1xEFGW1ztWG9RGwV6TUgIZ52kl3b18IfdmtVmSOVKxs",{"id":178,"title":179,"author":6,"body":180,"canonical":93,"category":243,"cover":93,"date":244,"description":245,"draft":97,"extension":98,"keywords":93,"meta":246,"navigation":100,"noindex":97,"ogImage":93,"path":247,"seo":248,"seoDescription":93,"seoTitle":93,"stem":249,"tags":250,"updated":93,"__hash__":254},"blog\u002Fblog\u002Fcustom-crawler-dead-links.md","几千个页面的死链，我们为什么自己写脚本查",{"type":8,"value":181,"toc":236},[182,185,188,191,194,197,200,203,206,209,212,215,218,221,224,227,230,233],[11,183,184],{},"2025 年 12 月我们查一个一万两千页的文档站，历史死链积了两千多条，运维照着工具列表改了一周也没改完。站一旦上万页，查死链这件事工具就不够用了。免费版爬虫有 500 个 URL 的上限，付费版能爬完，但只告诉你哪些链接返回 404，不告诉你先修哪个。我们后来写了个八十行的脚本，解决的是排序问题。",[15,186,187],{"id":187},"现成工具卡在哪",[11,189,190],{},"爬取能力不是问题，判断规则是。工具把死链列成一张表，几千行，按发现顺序排。运维看一眼就头大，最后挑前十条改，剩下的放着。",[11,192,193],{},"另一件事是死链的价值不一样。从导航链过去的 404 和内页深处一个没人点的 404，处理优先级差很远。工具不做这个区分，因为它不知道你的业务。",[15,195,196],{"id":196},"脚本做什么",[11,198,199],{},"先读站点地图拿到全量 URL，再爬每个页面的出链，拼成一张内链图。然后并发发 HEAD 请求，记录状态码、跳转链、响应时间。",[11,201,202],{},"拿到结果后排序：来源页是不是首页或导航可达、这个 404 被蜘蛛抓过多少次、来源页本身有多少条内链。这几个数据日志里都有，拼起来就是优先级。",[11,204,205],{},"输出一张 CSV，前二十行直接进工单。我们处理完一批，脚本再跑一次，看哪些新冒出来。",[15,207,208],{"id":208},"三个坑",[11,210,211],{},"第一，HEAD 请求会被部分防火墙拦，返回 403，看着像坏链其实没错。改用 GET，只读前几 KB 就断开。",[11,213,214],{},"第二，不带 UA 的请求会被当成攻击。把 UA 改成带标识的，并且把并发压到 10 以下。",[11,216,217],{},"第三，301 可能是一串。从 A 跳到 B 再到 C，脚本要跟到底，只报最终状态。我们见过三跳的跳转链，第一跳修了，第二跳还在。",[15,219,220],{"id":220},"脚本的价值在排序",[11,222,223],{},"发现死链这件事，工具一秒能给你一万条。修哪一千条、按什么顺序修，才需要判断。",[15,225,226],{"id":226},"和现成监控服务的区别",[11,228,229],{},"市面上的死链监控服务是持续跑的，发现新 404 就告警。它解决的是别断，不解决先修哪个。我们两边都用：监控盯线上，脚本每月跑一次做排序。",[11,231,232],{},"监控服务还有个副作用，老站本来就有几百条历史死链，一接上就天天告警，最后没人看。先清一轮历史再接监控，告警才有人理。",[11,234,235],{},"我们现在的流程是每个月跑一次，按优先级修前 100 条，剩下的记录在案，等下次重建导航时一起处理。用了半年，站内 404 从 2400 多条降到 300 条以内，被抓取浪费掉的频次也明显少了。",{"title":31,"searchDepth":85,"depth":85,"links":237},[238,239,240,241,242],{"id":187,"depth":85,"text":187},{"id":196,"depth":85,"text":196},{"id":208,"depth":85,"text":208},{"id":220,"depth":85,"text":220},{"id":226,"depth":85,"text":226},"工具评测","2025-12-30","免费版爬虫有 500 URL 上限，付费版能爬但只报状态码。站上一万页、要按流量和权重排优先级时，八十行脚本更管用，这篇写脚本做什么和三个坑。",{},"\u002Fblog\u002Fcustom-crawler-dead-links",{"title":179,"description":245},"blog\u002Fcustom-crawler-dead-links",[251,252,253],"死链检测","自动化脚本","内链","-FaJsdcVmaQFc6e6A0s_n6Lw1yx6rkhcN6zYlA4rjE4",1794088109645]