站点改版要过渡、内容批量清理、卖掉的域名不想再被推、服务商绑定的自动提交想停掉……这些时候都会冒出一个念头：把百度的递交入口关掉。这个动作听起来很简单，但真正动手时，十个人里有七八个会先走错方向，有人上来就删代码，有人转头去改 robots.txt，结果要么没关干净，要么把不该关的东西一起关了。
问题的根源在于，"百度递交入口"从来不是一个开关，而是散在几个地方的几条通道。每条通道关法不同，关掉之后的影响也不同。哪个该关、去哪个后台关、关完会不会误伤，这三件事想清楚了，操作只要几分钟。
一句话定调：递交是"你把内容送过去"，收录是"百度决定要不要"；关掉前者，管不住后者。
一、先分清递交和收录，这是两套东西
百度生态里跟"内容进索引"相关的动作，粗分下来是两套：一套是递交，一套是收录控制。很多人把这两套混成一套，于是产生了两个最常见的误判，以为自己关了某个入口，实际什么都没发生，或者反过来，以为某个动作只是"停止提交"，实际却让整站从搜索结果里消失。
递交类动作（你主动送）
网页里的自动推送代码、搜索资源平台的 API 推送、sitemap 提交、手动提交 URL、建站系统或插件里的自动提交开关。特点是：你不动，它就不发生。
收录控制类动作（你设规则）
robots.txt 里的 Disallow、页面上的 noindex 标注、已收录页面的删除申请、死链提交。特点是：设好之后长期生效，影响范围往往比想象的大。
两套动作的目标完全不同。如果诉求是"我不想再主动推它了"，要动的是递交类通道；如果诉求是"我不希望这些页面出现在搜索结果里"，该用的是收录控制手段。用错工具，白忙一场还是小事，误伤整站流量才是麻烦。
还有一种情况要先说明白：递交类动作，全部是免费且方向单一的。递交本身不会让站点变差，百度也从来不因为"提交得多"而降权。所以关闭递交入口这件事，多半是出于站点状态变化后的管理需要，而不是什么"纠错"。想清楚这一点，就不会被某些"帮你关闭入口规避惩罚"的说法带偏。
二、网页代码里的推送脚本，怎么找怎么去
先理清一件事：网页代码里的那段自动推送脚本，指的是早年百度提供的 JS 代码，页面被打开时会自动上报当前地址。这个功能 *** 前些年就已经暂停使用，多年没有恢复。换句话说，留在模板里的那段代码，绝大多数时候处在一个"挂着但不干活"的状态，删与不删，对收录格局的影响都微乎其微。真正需要处理的，是它带来的另一类麻烦：清理站点时看着它在模板里碍眼，或者做安全审计时被当成不明脚本。
要把它找出来，直接全文搜两个特征词就行。第一段是带 hm.baidu.com 或 push.zhanzhang.baidu.com 地址的脚本、第二段是声明自动推送配置的变量。典型的长这样：
<script>(function(){var bp = document.createElement('script');var curProtocol = window.location.protocol.split(':')[0];if (curProtocol === 'https') {bp.src = 'https://zz.bdstatic.com/linksubmit/push.js';} else {bp.src = 'http://push.zhanzhang.baidu.com/push.js';}var s = document.getElementsByTagName("script")[0];s.parentNode.insertBefore(bp, s);})();</script>找到之后，通常出现在这几个位置：主题的公共头部模板、单独的页脚引入文件、建站系统里的"统计与代码"粘贴框。删的时候容易漏三种情况：同一段代码在移动版和桌面版模板里各有一份，只删了一边；站点上了 CDN 或开了静态缓存，源码改完缓存没刷，页面里还能看到；主站子站共用模板，删了主站忘了子站。改动之前先备份模板文件，改完用无痕模式打开页面查看源代码，搜一遍特征词确认干净。
删脚本之前顺手确认一件事：有的建站系统会把自动推送和其他统计脚本写在同一个引入文件里，删之前看清它是不是" *** "了别的功能，别一剪刀下去把数据统计也带走。
三、搜索资源平台里的几条接口，停用方式各不一样
打开搜索资源平台仔细看一圈会发现，这里压根没有一个叫"关闭递交"的按钮。原因不复杂：平台上的递交是几种并列的工具，用不用由站长的动作决定，而不是靠一个总开关控制。所以要"关"，关的是每条工具各自的运作方式。
每个站点后台里的普通收录，通常带着手动提交、API 提交、sitemap 三个入口。手动提交不必管，你不交它就静止；麻烦的是另外两条通道，因为它们往往是被程序自动调用的，人走了，程序还在按时跑。
| 递交通道 | 平时怎么运作 | 停用动作 | 停用后的影响 |
|---|---|---|---|
| 手动提交 | 人工在后台逐条粘贴 URL | 不操作即停止，无需任何设置 | 无，本来就没有自动动作 |
| API 推送 | 程序带着 token 定时调用接口，把新页面送出去 | 停掉调用程序；无法停程序时，在平台重置推送 token，旧对接立刻失效 | 新页面不再被主动送出，收录回到自然发现节奏 |
| sitemap 提交 | 平台定期来抓取站点地图，按图索骥发现新链接 | 平台上手动删除已提交的地图；站点端同步移除 sitemap 文件与 robots 里的声明 | 发现效率略有下降，已有收录不受影响 |
一个实操细节：很多人遇到的"推送停不掉"，是外包公司或建站服务商在替站点跑推送，你自己连调用程序在哪都不知道。这种情况别去平台里东翻西找，直接在平台重置 token 就行，对方手里那把"钥匙"当场作废。事后把新 token 只交给你信任的对接方。
还有一点值得说明：搜索资源平台不会因为你停用推送而撤掉站点权限，也不会记什么"态度分"。哪天需要重新启用，把程序或地图重新接上就行，通道本身没有开关锁死这一说。
四、建站系统和插件里的自动提交开关，最容易漏
前两类通道都在"外面"，这一类藏在站点自己的后台里。现在的建站系统、SEO 插件、发布工具，很多都自带"发布文章自动推送给搜索引擎"的功能，开箱即用，默认还常常是打开的。平时这是好事，一旦站点状态变了需要停止推送，它就成了最容易被漏掉的源头。站长把代码删了、把平台 token 重置了，插件还在那儿勤勤恳恳地推。
要关干净，按这几个位置逐个看过去，顺序不分先后，但一个都别少：
找"推送""收录""站长平台"一类的选项卡，把自动推送的勾去掉，顺便看一眼 token 输入框里有没有内容。
部分建站系统的站点设置里自带收录推送选项，名称通常叫"发布后自动提交"，位置可能在内容设置或 SEO 设置下。
有些推送是用定时脚本跑的，插件关了它还在。server 面板或系统的任务列表里找带 push、submit 字样的条目。
采集发布工具、多平台同步工具里如果填过推送接口，去它的对接设置里解绑，或者干脆在平台侧重置 token 一了百了。
站点一多，这四处的排查量会成倍放大。手里十几个站的时候，逐个进后台翻插件设置，一天下来也关不干净几个，还容易关了这个忘了那个。用 UC 建站系统这类带统一管理能力的环境会省很多事：推送开关、接口状态、各站索引情况汇总在一个看板里，关哪个站、留哪个站，一处操作，剩下的交给后台同步，不用再靠人肉记忆对账。
五、真想停收录，该动的是另外几处开关
绕不开一个场合：有人要关递交入口，其实心里想的是另一件事：不让某些页面再出现在搜索结果里。这两个目标之间隔着一段路，只关递交是走不到的。递交停了，页面早就在库里躺着，搜索照旧能搜到。要让内容从结果里退场，得用收录控制的手段。
- robots.txt 的 Disallow：告诉蜘蛛别抓某类路径，适合"还没被收录的整块区域"提前设防。已经收录的老页面不会因为加了这行字而自动消失，需要等下次抓取被拒后再慢慢淡出。
- 页面级 noindex 标注：针对单个页面，指令明确，适合目录页、标签页、测试页这类"不想出现在结果里但希望正常访问"的页面，是比 robots 更精准的工具。
- 已收录内容的移除申请：对已经进库的页面，通过平台的正规删除入口提交，按流程走审核，快照更新有周期，耐心等。
- 死链提交：页面已经删掉、地址变成 404 的，把死链清单整理出来提交，比一个页面一个页面申请更省事。
这里有一条必须强调的红线：
robots.txt 里一句写错的 Disallow，可能让整站从搜索结果里清空。这条文件的语法容错很低，写通配符、写路径前缀时尤其容易手滑，效果却是全站级的。
动 robots 之前只有一件事值得花时间：对着语法一条条核对，改完用平台提供的检测工具验证。宁可多检查十分钟，不要拿站点流量赌一次手滑。
回到主题上就清楚了：关递交入口，解决的是"不想再主动送"；上面这几样工具，解决的是"不想被搜到"。两件事分开处理，各自都不复杂，混在一起才会出现"都操作了，哪一个也没达到目的"的尴尬。
六、什么情况该关，什么情况放着别动
工具和方法都摆在桌面上了，还剩最后一个判断：自己的情况到底属于哪一类。这个判断做错，要么白折腾，要么把顺手的工具关得莫名其妙。按经验，真正需要动手的场景就那么几种，其余大多数时候，通道原样放着才是正解。
这些情况建议关
站点改版过渡期，避免旧结构页面大量被推；批量清理测试内容期间；域名准备出售或停用；发现某服务商拿着授权跑与你无关的推送；多站之间重复推送同一批地址造成浪费。
这些情况不用动
站点正常运营、内容持续更新，推送通道就该开着；页面已挂的那段旧 JS 代码，功能早停，删不删随你；只是听说"提交太多不好"这种说法，本身站不住，不值得专门去关。
这些情况先别急着关
刚上线不久、收录本来就慢的站点，关掉推送等于自断一条发现渠道；做站群正在起量阶段的，推送是效率工具，停掉只会让收录更慢。
补一个执行层面的建议：关闭动作尽量选在流量低谷的时点做，比如夜间或周末，出问题时排查窗口更充裕。别在活动上线的当天动这类设置。
七、动手之前记基线，动手之后看趋势
所有操作里，最容易被跳过、事后又最让人后悔的一步，是关闭之前留一份记录。原因很现实：递交通道关掉之后，收录节奏一定会变化，变多少、算不算正常，只有跟关闭前的数据对比才知道。没有基线，出了波动只能凭感觉猜，猜错了方向，要么白白折腾回来，要么放任问题扩大。
记录的内容不用复杂，关闭当天把这些数字抄下来就够了：站点当前收录量、有排名的词数量、近三十天的自然流量、几条主力页面的排名位置。这几项凑在一起，就是后面判断趋势的参照系。搜索资源平台后台、统计工具里都能查到，十分钟的事。
关闭动作本身只需要几分钟，真正决定这件事做得对不对的，是关闭前后的这两份数据。
关闭后的两三周里，重点看两样东西。收录量的走势：如果之前依赖推送比较重，停掉之后新增收录放缓属于预期内，页面更新频率高、外链基础好的站点受影响会小一些。已有排名的稳定性：老页面不该因为"新内容不再推送"而掉位，如果排名出现大面积波动，要回头检查是不是关闭动作顺带改动了别的设置，比如 sitemap 删得过头、robots 误加了一条。
把整件事从头到尾拎一遍：先分清递交和收录归属哪套体系，再去代码、平台、插件三个地方把对应的通道逐一停掉或停用，涉及收录控制的再单独处理，最后用前后两组数据验收。每一步都不难，难的只是别跳步。关掉递交入口管的是自己的节奏，管不了百度的判断，认清这条边界，操作就不会变形。
站点状态变了就调整通道，状态平稳就让工具照常运转，这件事没有一劳永逸的配置，只有跟得上节奏的管理。
（文中操作路径基于公开的平台功能说明整理，各渠道规则与界面会不定期调整，实际操作请以 *** 最新说明为准。）
