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

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

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

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

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

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

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

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

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

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

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