RankMath批量請求鏈接收錄有什么差異？
今天很忙，分享一個最近從實際案例中得到的數據。
我之前的文章中有介紹過，如何通過Google Indexing API提交鏈接收錄。具體的做法就是，先去谷歌云申請免費的Indexing API，將相關信息保存下來后，集成到RankMath這樣的SEO插件里。
那下次你有新建鏈接時，便可以直接用RankMath實現批量請求鏈接收錄。一般這種通過API方式，提交鏈接的上限可以達到200條，且整個提交的過程很快（1-2分鐘左右）。
那使用這種API方式，就要比自己手動在谷歌站長工具里提交鏈接要高效很多。畢竟GSC里面，絕大部分賬號每天只能提交10條鏈接，且整個手動操作的過程費時費力。
但是這種方式，并不是特別完美。根據我這幾個月的實際體驗，從數據結果中會發現通過將API集成到RankMath再請求收錄的這種方法，整體的收錄比率并不高（基本在60%左右）。
也就是說，100條鏈接請求收錄后，基本收錄成功的數量在60條左右，剩下的基本都是顯示“已爬取但未收錄”。那剩下的40條鏈接，就需要自己手動在GSC后臺里一條一條再請求一遍了。
期間我有質疑過為什么會存在如此大數據偏差，搜索了很多文檔，但是并沒有發現什么特別有用的答案。于是上個月月中，干脆通過AB測試的方式去測試一下問題所在。
我的方法就是自己用Python寫一段腳本代碼，使用這段代碼去批量提交鏈接收錄請求，然后再將兩種請求收錄方式做相應的數據對比（同一個網站的鏈接，進行隨機分配）。
最后發現通過自己Python代碼請求收錄的鏈接，成功率基本都在95%以上，每批次僅有幾條鏈接不收錄（顯示“已抓取但未收錄”）。兩相對比，數據差異就非常大了。
今天也有朋友問我，這種數據差異的原因是什么。不好意思，我現在也不知道。但我能確定的是，肯定是在RankMath的某個環節出了問題，且這個問題還不是我們能控制的。
因為整個AB測試的流程，就只有請求收錄的環節不一樣。我現在也沒辦法看RankMath這款插件的源代碼，沒辦法得出結論。不過知道了“坑”在那里，后續繞著走就行了。
