sitemap 完全指南：產生、送出，以及讓當天文章消失的時區 bug
一句話結論：sitemap 的價值不在「有沒有」，而在「裡面的 URL 是不是你真的想被收錄的那些」。我們自家站在 2026 年踩過一個很難發現的問題：sitemap 用 UTC 判斷「未來日期」，內容用台北時間標日期，結果台北時間早上 8 點前發的文章會被自己的 sitemap 判成未來文而整批跳過，頁面線上看得到、sitemap 裡卻沒有。這篇把產生、驗證、送出、複驗四段拆開講，每一段都附可以直接跑的指令。
大部分教學把 sitemap 講成一個檔案格式問題。實際上它是一份「我希望你優先看這些」的名單，名單錯了比沒有名單更糟。
sitemap 到底做什麼
sitemap 是發現機制，不是排名機制。放進去不代表會被收錄，沒放進去也不代表不會被爬到。它解決的是「爬蟲怎麼知道這個 URL 存在」，特別是站內沒有連結指過去的頁面。
這也帶出第一個常見誤解：sitemap 收錄 ≠ 內部連結。一個頁面只出現在 sitemap、站內沒有任何一條連結指過去，它就是孤兒頁。我們自家站 2026 年 8 月的盤點裡，371 個頁面有 94 個從來沒拿過任何一次曝光，佔 25.3%，其中很大一部分正是這種「只在 sitemap 裡」的頁。
sitemaps.org 的協定文件↗定義了格式，Google 的 sitemap 說明↗講的是它怎麼用這份名單。兩份都值得讀一次，因為它們都沒有承諾「放進去就會收錄」。
那個時區 bug
我們的 sitemap 產生器會過濾掉日期在未來的文章，避免排程稿提前曝光。判斷用的是伺服器的 UTC 當天。但內容的 frontmatter 寫的是台北時間。台北比 UTC 快 8 小時，所以在台北時間凌晨到早上 8 點之間，「今天」在 UTC 還是昨天，一篇標記為今天的文章就會被判成未來文，整批被跳過。頁面本身線上打得開、blog 索引頁也看得到，只有 sitemap 少了它。這種錯誤不會噴任何錯誤訊息。
修法有兩種，選一種就好，不要兩種都做：
| 做法 | 改哪裡 | 適合誰 |
|---|---|---|
| 日期一律帶時區 offset | frontmatter 寫 2026-08-25T09:00:00+08:00 | 內容團隊在同一個時區 |
| 產生器用台北當天判斷 | sitemap 產生邏輯改用 Asia/Taipei 取當天 | 內容跨時區、不想動既有檔案 |
我們自己選第一種，因為它把時區資訊放在資料本身，而不是藏在產生器的邏輯裡。第二種要記得所有讀日期的地方都要一起改，只改 sitemap 會出現「sitemap 有、索引頁沒有」的反向不一致。
產生完必須驗的四件事
我們的部署腳本裡有四個檢查，任何一個沒過就不算部署完成。這四個不是理論，是我們各自踩過一次之後才加進去的。
- URL 數量對得上。拿 sitemap 的 URL 數對比內容目錄的檔案數，差太多就是有東西被過濾掉了。我們 2026 年 8 月做完內容剪枝之後是 1,062 個 URL，數字對不上就回頭查。
- 抽驗 5 筆真的回 200。用 curl 打，不要用瀏覽器看。
- 尾斜線形式一致。站台 canonical 有尾斜線，sitemap 裡就不能少，否則每一筆都吃一次 308 轉址。
- 今天發的文章在裡面。這一條就是上面那個 bug 的守門員。
curl -s https://example.com/sitemap.xml | grep -c "<loc>"
送出與複驗
送出有兩條路，兩條都做：Google Search Console 的 sitemap 送出，以及 IndexNow↗ 這種即時通知協定。前者是給 Google 的，後者 Bing 與 Yandex 會吃。
送出之後不要就當作完成。到 Search Console↗ 看兩個數字：sitemap 讀到的 URL 數，以及實際被收錄的數量。這兩個數字差很多是正常的，差得離譜就要查。我們的經驗是，新站前 4 週落差 50% 以上都還算合理，超過 3 個月還是這樣就代表內容或技術面有問題。
什麼不該放進 sitemap
名單放太多東西是最常見的浪費。標了 noindex 的頁、被 canonical 指向別頁的重複頁、參數化 URL、分頁的第 2 頁之後、以及登入後才看得到的頁，這些放進去只是在稀釋名單的訊號。我們的判準很簡單：這個 URL 你希望它出現在搜尋結果裡嗎。不希望就不要放，不確定就不要放。
反過來，被 robots.txt 擋掉的頁更不該放。爬蟲讀不到那個頁，就讀不到頁面上的 noindex，結果它會用一個更差的狀態留在索引裡。這一條的完整排查在 robots.txt 與收錄問題排查。
常見問題
sitemap 一定要有嗎？ 小站站內連結完整的話，沒有也會被爬完。站大、有孤兒頁、或是新站沒什麼外部連結時，它的價值才明顯。
多久更新一次？ 有內容變動就更新。靜態產生的站在 build 時重新產出就好，不需要另外排程。
lastmod 要填嗎？ 要，而且要填真的。填假的（例如每次 build 都寫成今天）會讓這個欄位失去意義，Google 也會學會忽略它。
sitemap 裡的 URL 數量有上限嗎？ 單檔 50,000 筆或 50MB 未壓縮，超過就要拆成多個檔案並用 sitemap index 串起來，這是協定文件↗明訂的。
送出之後多久會收錄？ 沒有保證的時間。我們自家站的觀察是新頁 3 天到 3 週都有，差異主要來自站台權重而不是 sitemap 本身。
參考來源
- sitemaps.org 協定文件↗：格式、大小上限與 sitemap index 的規範。
- Google Search Central：sitemap 總覽↗：Google 怎麼使用這份名單，以及它明確不承諾什麼。
- IndexNow↗：即時通知協定，Bing 與 Yandex 支援。
- Google Search Console 說明中心↗：sitemap 讀取狀態與收錄數的查看位置。
本文的時區 bug、1,062 個 URL 與 25.3% 零曝光頁這幾個數字，出自我們自家站 2026 年 8 月的實測與內容剪枝紀錄，不在上述任何一份來源裡。
想把整套流程交給別人跑，可以看我們的服務內容，或直接聯絡我們。
相關文章
robots.txt 與收錄問題排查：Disallow 會讓 noindex 完全失效
同一天加 Disallow 和 noindex 是最常見的自我抵銷。這篇拆解四種回 200 卻其實壞掉的收錄問題，以及正確的排查順序。
SEO 優化作業系統：我們每週實際在跑的那一套
把 SEO 從一堆零散技巧變成一套會重複執行的流程。這篇拆解我們自家與客戶站正在跑的五階段作業系統，含每一步會擋人的驗收門檻、實測通過率與分語系點閱率數字。
AI Overviews 優化：先去看你 Search Console 裡的機器人問句
生成式引擎優化不用先買工具。把查詢報表篩出超過十二個字的完整問句讀一遍，那是模型在幫使用者找答案，而它跟點擊是兩種 KPI。附我們自家的分語系實測數字。