不重新提交，Google 也會回來讀 sitemap：Search Console 的兩個時間戳

我的部署筆記裡有一條規則：Google 不會因為 sitemap 內容變了就回來重抓，每次部署完都要用 Search Console API 重新提交一次。寫下這條的依據是 2026 年 8 月 23 日的一次觀察：一個站的線上 sitemap 有 129 個網址，Search Console 記錄的還是 95 個。

但把我有權限的 23 支 sitemap 的狀態一次拉出來看，「不重新提交就不會再下載」這半句站不住：很多支幾個月沒重新提交，Google 上週還是下載過。這篇要談的是 Search Console API 裡兩個時間戳能說明什麼、不能說明什麼。依序回答五件事：兩個時間戳是什麼、沒提交的會不會被下載、提交之後發生了什麼、下載之後還有什麼看不到，以及 ping 與 IndexNow 在這裡的位置。

兩個時間戳

Search Console API 的 sitemaps.list（GET /webmasters/v3/sites/{siteUrl}/sitemaps，siteUrl 要百分比編碼）每支 sitemap 回幾個欄位，這篇用到的是：

lastSubmitted：最後一次提交的時間
lastDownloaded：最後一次下載的時間
isPending：文件的說法是「為 true 表示這支 sitemap 還沒處理」
contents[].submitted：該內容類型的網址數，這篇看的都是 web

這個站自己的那一列（2026-10-12 16:37 UTC 拉的，整理成一欄一行）：

sc-domain:baobaolin.com  https://baobaolin.com/sitemap.xml
  lastSubmitted  2026-07-31T17:13:18Z
  lastDownloaded 2026-10-06T16:39:08Z
  isPending      false
  contents       web submitted=50

baobaolin.com 不在我那支重新提交的腳本裡，API 記錄的最後提交時間仍是 7 月 31 日，但 Google 在 10 月 6 日下載過它。它記到的 50 個網址，和我同一天用 curl 抓線上 sitemap 數到的 <loc> 數一樣（這個站最新一輪文章還沒部署）。

沒重新提交，也會被下載

23 支裡有 13 支，最後一次提交距離快照超過 14 天（約 15.8 到 192.3 天，另有一支約 555.5 天）。它們的 lastDownloaded：

距上次提交	距上次下載	支數
約 15.8–192.3 天	2.3–9.0 天	12
約 555.5 天	約 550.2 天	1

12 支都在快照前 9 天內被下載過。例外的那一支，我同一天用 curl 打它的網址，10 秒內沒有回應。Search Console 的說明寫，sitemap 抓取一直失敗時，Google 會重試幾天，之後就停止；這和那一支的狀況相符，但我沒有它當時的錯誤紀錄，只能算推論。這 13 支裡有 3 支是 feed（Google 接受 RSS 與 Atom 當 sitemap 提交）。

所以 Google 會自己回來讀 sitemap，不需要每次重新提交。Search Console 的說明（Sitemaps report）也這樣寫：成功抓過的 sitemap 會定期重抓，節奏和網站本身的抓取無關，但沒有承諾間隔；sitemap 有大幅變動時，可以考慮重新提交。這是一張快照，只看得到「最後一次下載離現在多久」，看不到兩次下載之間隔多久，所以我沒辦法從這裡算出頻率。8 月那次 95 對 129 的落差，一種可能是 Google 當時還沒重新下載新版，但那次我沒有留下 lastDownloaded，無法判定。

重新提交之後發生了什麼

重新提交是對同一支 sitemap 發一次不帶 body 的 PUT（我的腳本紀錄成功時回 204）：

PUT https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Abaobaolin.com/sitemaps/https%3A%2F%2Fbaobaolin.com%2Fsitemap.xml
Authorization: Bearer <access_token>

OAuth scope 要 https://www.googleapis.com/auth/webmasters，唯讀的 scope 不能提交。10 月 11 日 15:49 UTC 那一輪對 5 個網站、9 支 sitemap 提交。快照時的狀態：

結果	支數
最後下載時間落在提交後 27 分 27 秒到 32 分 27 秒之間	7
提交後約 24 小時 49 分仍是 `isPending: true`	2

7 支在同一個 5 分鐘的區間裡被下載，我認為是這次提交觸發的；但這是推論，我沒有「不提交」的對照組，不能說它們不提交就會晚多久。那 2 支的 lastDownloaded 是同一天的 15:30:46，比 15:49 那次提交還早；API 只留最後一次的時間，看不出中間經過。另有一支新網站的 sitemap，10 月 10 日提交，約 47.5 小時後 API 仍沒有下載時間。

Google 的〈Build and submit a sitemap〉寫得很直接：提交 sitemap 只是一個提示，不保證 Google 會下載它，也不保證會用它來抓網址。這一輪的結果和這句話一致：9 支裡 7 支大約半小時後有新的下載紀錄，2 支沒有，等多久沒有保證。

下載之後，API 看不到的事

有下載紀錄，不代表那些網址已經被抓、被收錄。API 回的 contents[].indexed 看起來像是收錄數，但有網址數的 21 支全部是 "0"（另外 2 支在我的輸出裡是空清單）。文件對這個欄位只有一句：「Deprecated; do not use.」單一網址有沒有收錄，用程式查是 URL Inspection API，一次一個網址；手動就用 Search Console 的網址檢查工具。

Google 在 2023 年 6 月 26 日的部落格文章裡說會把 lastmod 當成排程重抓的訊號，前提是它長期和頁面實際的重大修改一致。這個站的 sitemap 是 build 時產生的，文章頁的 lastmod 優先取頁面宣告的修改日，沒有就取發布日；首頁跟著最新一篇文章。日期準不準，最後還是看我改文章時有沒有更新宣告的修改日。

ping 已經沒有了，IndexNow 不含 Google

同一篇 2023 年的文章宣布停用 sitemap ping，說端點六個月後停止運作，之後的請求會回 404。我寫這篇時打了一次（第一行是指令，第二行是輸出）：

curl -s -o /dev/null -w '%{http_code}\n' 'https://www.google.com/ping?sitemap=https://baobaolin.com/sitemap.xml'
404

IndexNow 是另一條路，提交到任一個參與的端點，會分享給其他參與的服務。截至寫這篇時，它官網的 searchengines.json 列了 Bing、Yandex、Seznam、Naver、Yep、Internet Archive、Amazonbot，沒有 Google。所以我其他站的部署尾巴是兩件獨立的事：IndexNow 給 Bing 那一群，Search Console 的 PUT 給 Google，互相取代不了。（這個站的部署腳本目前兩件都沒做。）

我打算加的檢查：部署完 PUT，過一段時間用 GET 看 lastDownloaded 有沒有晚於 lastSubmitted、contents[].submitted 和線上 sitemap 的網址數是否相同。兩個都對上，是 Google 下載過新版的線索，但不是證明：網址數相同的不同版本、還沒處理完，都可能讓它對上。新文章有沒有被抓，還是要用網址檢查一篇一篇看。暫時 pending 可以再等；如果報表出現抓取錯誤，修正後再提交。

如果只記得一件事

不重新提交，Google 也會回來讀 sitemap，只是不照你的時程。開頭那條規則的前半句要改掉。後半句我還是照做，部署完重新提交一次，成本只是一個 PUT；這一輪 7 支在半小時左右就有下載紀錄，但它能不能讓新文章更早被抓或被收錄，這份資料回答不了。判斷有沒有下載過，看 lastDownloaded，不要看 indexed。