泛目录MIP提交；多数人顺序做反了

顺序反了，越推越废。

泛目录mip提交这词最近问的人不少，十个里有八个第一句是接口一天上限多少条。我一般反问一句：你那批目录页，随便抽二十个打开，返回的是正常页面还是空壳？多半就没人吭声了。推送接口不是收录开关，它顶多算个通知，通知过去的地址本身站不住，通知得再勤也白搭。先建再推，这个顺序一乱，后面全是无用功。

泛目录mip提交的先后顺序，我一般这么排

第一步不是拿 token，是抽检。从目录里随机抓一批 URL，用 curl 一条条看状态码和响应体大小，`curl -o /dev/null -s -w ‘%{http_code} %{size_download}\n’ https://你的域名/xxx/`，状态 200 但 size_download 只有一两百字节的，八成是空壳页或者模板占位页，这种页面推上去纯属给自己找麻烦。响应长度参差不齐、正文差异肉眼能看出来的，那才算有点底子。

第二步才轮到规则。

URL 规则不定下来，推出去的地址你自己都认不全

泛目录最容易被忽略的就是地址长得乱七八糟——带 `?id=123` 的、末尾多一个斜杠的、大小写混着来的、`/a//b/` 双斜杠的，在你眼里是同一个页面，在抓取端眼里是四五个不同地址。我接过一个站，目录看着不少，去重之后能推的地址少了一大截，剩下的全是重复。推之前把规则钉死：统一小写、去掉多余斜杠、参数页 canonical 到主地址、该 301 的别用 302 兜圈子，这些做完再谈提交。

robots.txt 先把不该抓的路径挡掉，sitemap.xml 只放你真想被看到的那些，把该挡的挡掉就好，别一股脑全塞进去凑数量吧。

抓取日志比推送回执诚实得多

接口返回一句 success，不少人就当成了。我一般不这么看。

先翻 nginx 的 access.log，grep 一下蜘蛛的 UA，看它这几天来没来、抓了哪些路径、状态码分布什么样。你会发现日志里能认抓取源的 IP 段，哪些是真蜘蛛、哪些是拿着假 UA 来扫目录的，顺手分一分，服务器上也少挨些莫名其妙的请求。真蜘蛛来的频次、抓的深度、在哪一层退出，比接口那行 JSON 靠谱多了。

日志里全是 404 和 5xx，接口给你返回 success 也没意义啊。

软 404 最坑。

状态码 200、正文写着暂无内容的那种页面，抓取端会当成正常页收下，但它跟空页面没区别，这种页收得多了，整站那点底子也跟着被拉下去。

小批量先推，看回执再放量

一次推几千条这种事我干过，后来不干了。先挑几十上百条，把回执拉下来逐条看：哪些 success、哪些报错、报错是参数格式不对还是地址压根访问不了。错误率低再翻倍放，错了就回头改规则。每天配额有上限，具体多少以服务商或官方页面说明为准，我不瞎猜。浪费配额的方式有无数种，最冤的是把明显是空壳的页面推上去。

同一台机器几十个目录，IP 是会说话的

泛目录一般就跑在一台机器上，几十个目录共用一个公网IP。抓取请求全集中打在这个地址，日志里的节奏，一看就明白。一个IP底下堆太多站？我不太建议。被限速了，连累的是一整批。真要做呢，给蜘蛛单独放行、把抓取频率压下来就好，比事后追着客服问强。服务器IP地址这东西看着只是个数，说白了是你所有目录的门牌。门牌上挤的人多了，敲门声自然就杂。

提交救不了模板化

泛目录的命门是模板太狠，几千个页面共用一套壳，只换标题和几个词，抓取端见得多了自然不待见。差异化得在生成端做——每页正文块顺序换一换、拼一段别的数据源的内容、加几个真有信息量的字段，这些动作要在提交之前完成。菜都上桌才想起放盐，何必呢。

也别指望推上去就等于被收录。提交只是把地址递过去，收不收、什么时候收，看对面。这个认知错位害过不少人，包括当年的我。

根子不在推送。

推的频率，没那么多讲究

有人问一天推几次合适呢？我的做法：有新地址就推，没新增就不推。别为了显得勤快，天天把老地址重推一遍——那纯粹是给配额找事做。标题改过、正文有实质变动，可以再推一次；只动了个标点也推，那就是自己跟自己过不去。说白了，接口那边怎么判重、多久生效，各家不一样，以官方页面说明为准。

要把顺序捋一遍的话，我是这么排的：抽检状态码和响应体大小，定死 URL 规则、canonical、robots、sitemap，翻日志确认真蜘蛛的行为，小批量试推看回执，放量，回头继续磨内容差异化。推是第五步，不是第一步。

顺序对了，配额才花得值，不然就是买了个已提交的心理安慰，页面该什么样还什么样。