今天很忙，分享一個(gè)最近從實(shí)際案例中得到的數(shù)據(jù)。

我之前的文章中有介紹過，如何通過 Google Indexing API 提交鏈接收錄。具體的做法就是，先去谷歌云申請(qǐng)免費(fèi)的 Indexing API，將相關(guān)信息保存下來后，集成到 RankMath 這樣的 SEO 插件里。

那下次你有新建鏈接時(shí)，便可以直接用 RankMath 實(shí)現(xiàn)批量請(qǐng)求鏈接收錄。一般這種通過 API 方式，提交鏈接的上限可以達(dá)到 200 條，且整個(gè)提交的過程很快（1-2 分鐘左右）。

那使用這種 API 方式，就要比自己手動(dòng)在谷歌站長工具里提交鏈接要高效很多。畢竟 GSC 里面，絕大部分賬號(hào)每天只能提交 10 條鏈接，且整個(gè)手動(dòng)操作的過程費(fèi)時(shí)費(fèi)力。

但是這種方式，并不是特別完美。根據(jù)我這幾個(gè)月的實(shí)際體驗(yàn)，從數(shù)據(jù)結(jié)果中會(huì)發(fā)現(xiàn)通過將 API 集成到 RankMath 再請(qǐng)求收錄的這種方法，整體的收錄比率并不高（基本在 60% 左右）。

也就是說，100 條鏈接請(qǐng)求收錄后，基本收錄成功的數(shù)量在 60 條左右，剩下的基本都是顯示“已爬取但未收錄”。那剩下的 40 條鏈接，就需要自己手動(dòng)在 GSC 后臺(tái)里一條一條再請(qǐng)求一遍了。

期間我有質(zhì)疑過為什么會(huì)存在如此大數(shù)據(jù)偏差，搜索了很多文檔，但是并沒有發(fā)現(xiàn)什么特別有用的答案。于是上個(gè)月月中，干脆通過 AB 測(cè)試的方式去測(cè)試一下問題所在。

我的方法就是自己用 Python 寫一段腳本代碼，使用這段代碼去批量提交鏈接收錄請(qǐng)求，然后再將兩種請(qǐng)求收錄方式做相應(yīng)的數(shù)據(jù)對(duì)比（同一個(gè)網(wǎng)站的鏈接，進(jìn)行隨機(jī)分配）。

最后發(fā)現(xiàn)通過自己 Python 代碼請(qǐng)求收錄的鏈接，成功率基本都在 95% 以上，每批次僅有幾條鏈接不收錄（顯示“已抓取但未收錄”）。兩相對(duì)比，數(shù)據(jù)差異就非常大了。

今天也有朋友問我，這種數(shù)據(jù)差異的原因是什么。不好意思，我現(xiàn)在也不知道。但我能確定的是，肯定是在 RankMath 的某個(gè)環(huán)節(jié)出了問題，且這個(gè)問題還不是我們能控制的。

因?yàn)檎麄€(gè) AB 測(cè)試的流程，就只有請(qǐng)求收錄的環(huán)節(jié)不一樣。我現(xiàn)在也沒辦法看 RankMath 這款插件的源代碼，沒辦法得出結(jié)論。不過知道了“坑”在那里，后續(xù)繞著走就行了。