把 sitemap.xml 當成上線前隨手產出的附件，產完就沒人再看，是我們在技術稽核時最常撞見的錯誤。它不是作文，不需要華麗，驗收時第一眼要問的也不是內容寫得好不好，而是這份地圖還活著嗎：能不能被打開、裡面的網址對不對、更新時間誠不誠實。這三件事決定了搜尋引擎會不會照著它去爬，比任何內容調整都先發生。
sitemap 是網站主動遞給搜尋引擎的地圖。地圖本身若是壞的，後面再漂亮的內容，爬蟲都可能繞不進去。以下我們把驗收拆成幾個層次，從最基礎的「它能不能被存取」開始，一路談到多語系的進階標註，照著這個順序查，幾乎不會漏掉致命的問題。
1. sitemap 的價值，是縮短「頁面存在」到「搜尋引擎知道」的距離
搜尋引擎的抓取資源是有限的。一個網站每天能被分配到的抓取次數（業界常稱抓取預算），不會因為頁面多就無限增加。sitemap 的作用，是讓爬蟲不必完全依賴一層一層點連結去發現頁面，而是直接拿到一份「這些網址請你優先看」的清單。
1.1 哪些網站最吃 sitemap 的紅利
對新站、深層頁面多的電商、或內部連結稀疏的網站，這份清單的價值特別高。根據我們的服務經驗，對一個內容更新頻繁、但內部連結鬆散的網站，補上一份正確的 sitemap 後，新頁面被索引的速度通常會明顯改善。sitemap 不保證頁面一定被收錄，但它會縮短「頁面存在」到「搜尋引擎知道頁面存在」之間的距離，這一段距離對成長中的網站往往就是關鍵。
1.2 一份合格 sitemap 的六個驗收條件
在細談之前，我們先把驗收標準攤開來，方便對照。這六點是我們每次交付前會逐條打勾的：
| 驗收項目 | 合格標準 | 驗收方式 |
|---|---|---|
| HTTP 狀態碼 | 直接存取 sitemap 網址回傳 200 | 用工具查看回應標頭而非只看畫面 |
| lastmod 標籤 | 存在且反映該頁真實最後更新時間 | 抽查數筆網址比對頁面實際更新日 |
| 網址數量 | 與網站實際可索引頁數相符 | 用爬蟲全站抓取後比對筆數 |
| 最終連結 | 每筆 loc 都連到真實頁面，非中繼檔 | 抽查是否為文章或頁面而非空節點 |
| GSC 提交 | 已提交且顯示成功、無法讀取的錯誤 | Search Console 的 Sitemap 報表 |
| 多語系標註 | 含 hreflang 的 xhtml:link 對應 | 檢查 loc 內的 alternate 標註 |
2. 狀態碼 200 與可存取性：別讓地圖自己就先迷路
這是最容易被忽略、卻最致命的一關。我們遇過不只一次，團隊在文件裡寫著 sitemap 網址，但實際點進去回傳的是 404 或 500，甚至被重導到首頁。搜尋引擎抓不到這份檔案，等於整份地圖不存在，後面所有標註都白談。
2.1 為什麼一定要 200，而不是 301 或 302
sitemap 的網址應該直接、乾淨地回傳 200。如果它是透過 301 或 302 重導才到最終位置，部分爬蟲會處理，但這中間多了一層不確定性，也容易和你在 robots.txt 或 GSC 裡宣告的網址不一致。我們的建議是，GSC 提交、robots.txt 裡的 Sitemap 指令、以及實際可存取的網址，三者要指向同一個回傳 200 的位置，不要繞路。順帶提醒一個常被忽略的細節：sitemap 檔案本身不應該被 robots.txt 擋掉，它所指向的頁面若被 noindex 就是另一個問題，後面會談。
2.2 用最低成本確認狀態碼
我們通常不會只用瀏覽器打開看到內容就算過關，因為瀏覽器可能顯示的是重導後的結果。比較可靠的做法是直接看回應標頭。用命令列一行就能確認：
curl -I https://example.com/sitemap.xml看回傳的第一行是不是 HTTP/2 200，同時留意 Content-Type 是否為 application/xml 或 text/xml。如果狀態碼正確但內容類型是 text/html，通常代表你其實被導到了一個錯誤頁，只是那個錯誤頁本身回 200。這種假性成功最難抓，一定要看內容類型交叉驗證。
2.3 三種常被忽略的可存取性問題
除了狀態碼，我們還會檢查三種容易被放過的狀況。第一種是 sitemap 被放在需要登入或帶特定參數才看得到的位置，開發環境測試時是好的，上了正式站卻因為權限設定而對爬蟲回傳 403。第二種是伺服器對同一個網址，給瀏覽器回 200、給爬蟲的 User-agent 回別的狀態，這種差別待遇會讓你在瀏覽器上怎麼看都正常，問題卻真實存在。第三種是 sitemap 檔案過大或產生超時，爬蟲抓到一半就斷，只讀到前面一部分網址。我們的習慣是用模擬爬蟲的工具實際抓一次，而不是只相信瀏覽器畫面。
3. lastmod 要誠實，它反映的是信任而不是新鮮感
lastmod 標籤標示每一個網址的最後修改時間。這個欄位我們特別在意，因為它是網站對搜尋引擎的一種承諾，而承諾一旦被發現造假，代價是信任被折損。
3.1 最常見的 lastmod 錯誤：全站同一個時間
很多自動產生的 sitemap 會把所有網址的 lastmod 都寫成「今天」，每次重新產出就整批更新。這在搜尋引擎眼中是一種雜訊。當它發現你宣稱昨天全站三千頁都更新了，實際抓下來卻幾乎沒變，它會逐漸不再把你的 lastmod 當一回事。真正該做的是，lastmod 對應到該頁「內容本身」的最後實質變動時間，而不是程式重新產檔的時間。
3.2 lastmod 的正確格式與取捨
格式建議採用 W3C Datetime，也就是含時區的 ISO 8601。單純日期是可接受的，但若能帶上時間與時區會更精確：
<url>
<loc>https://example.com/blog/seo-structure-guide/</loc>
<lastmod>2026-08-10T09:30:00+08:00</lastmod>
</url>我們不建議在 sitemap 裡塞 priority 與 changefreq，主流搜尋引擎早已幾乎忽略這兩個欄位，寫了也是徒增維護負擔，把力氣放在 lastmod 的準確度上更實際。我們稽核時會抽查幾筆：sitemap 裡標示某頁 lastmod 是三個月前，再去看那頁實際上次改動的紀錄，兩者若對得上，這份 lastmod 就是可信的；若整份檔案的 lastmod 全部一致，幾乎可以斷定它沒有反映真實更新。
3.3 什麼樣的改動才該更新 lastmod
一個常被問到的問題是：改了一個錯字、調了一下排版，算不算更新。我們的判斷原則是看「這次改動有沒有影響到使用者看到的實質內容」。補了一段新的說明、更新了數據、改寫了文末的判斷，這些該更新 lastmod；只動了 CSS、換了一張不影響語意的裝飾圖、或修了一個標點，就不必。把每一次微調都當成更新，會讓 lastmod 失去鑑別度，搜尋引擎分不出哪些是真正值得重新評估的頁面。反過來，真的大幅改寫了內容卻沒更新 lastmod，又會讓它錯過重新抓取的時機。這個分寸，是讓 lastmod 保持可信的關鍵。
4. 網址數量對不對得上，是我們判斷索引健康的體溫計
sitemap 裡的網址數量，應該和網站實際「希望被索引」的頁數相符。這個「相符」不是要求數字一模一樣，而是要求兩邊差距是可以解釋的。
4.1 sitemap 數量與實際頁數的三種落差
我們會把落差分成三類來處理，每一類的意義不同：
| 落差情況 | 可能原因 | 處理方向 |
|---|---|---|
| sitemap 頁數遠多於實際 | 含已刪除頁、參數頁、noindex 頁 | 清掉不該被索引的網址 |
| sitemap 頁數遠少於實際 | 產檔邏輯漏掉某些模板或分類 | 補上缺漏的頁面類型 |
| 數量接近但內容對不上 | 網址大小寫、結尾斜線不一致 | 統一 canonical 網址規則 |
其中最該優先處理的是第一類。sitemap 裡若混入了 noindex 頁面，會送出自相矛盾的訊號：你一邊在地圖上說「請索引這頁」，一邊在頁面標頭說「請不要索引」。搜尋引擎收到矛盾指令時，結果往往不如預期，而且會浪費本來就有限的抓取資源。
4.2 我們實際比對數量的流程
我們的做法是用爬蟲工具把網站爬一遍，得到所有回傳 200、且未被 noindex 的頁面清單，再把這份清單和 sitemap 的網址做交集比對。三個問題會浮現：哪些頁面在網站上但不在 sitemap、哪些在 sitemap 但網站上已不存在、哪些兩邊都有但 canonical 指向不同版本。把這三個名單處理乾淨，sitemap 的數量準確度就到位了。我們診斷過的案例中，有個內容量很大的網站，GSC 一直回報大量「已檢索但未收錄」，一比對才發現 sitemap 是舊系統產的，裡面有近四成是早就下架的活動頁；清掉之後，搜尋引擎的抓取才重新集中到真正有價值的頁面上。
4.3 數量對上了，還要看網址版本一不一致
數量比對到位只是第一步，我們還會看每一筆網址的「長相」是否就是你真正希望被索引的那個版本。同一頁很容易因為帶不帶結尾斜線、帶不帶 www、協定是 http 還是 https，而存在好幾個版本。如果 sitemap 列的是不帶斜線的版本，頁面的 canonical 卻指向帶斜線的版本，搜尋引擎等於收到兩個不一樣的網址，抓取與權重判斷都會被分散。我們會要求 sitemap 裡的每一筆 loc，都和該頁 canonical 標籤寫的是同一個字串，一字不差。這個細節在網站做過網址調整、或同時存在多種網址寫法的站上，特別容易出問題。
5. 多層多檔案 sitemap：分層可以，但最後一定要落在真實頁面
當網站頁數很多，單一 sitemap 檔案會受到限制，單檔上限是五萬筆網址或未壓縮 50MB。這時要改用 sitemap index，也就是一份索引檔指向多份子 sitemap。這種結構完全合規，但我們驗收時會特別盯一件事：每一條路徑走到最後，都必須連到真實的文章或頁面，而不是又指向另一個中繼檔卻斷在半空。
5.1 sitemap index 的正確樣貌
索引檔用的是 <sitemapindex> 根節點，底下每個 <sitemap> 指向一份子檔：
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts-1.xml</loc>
<lastmod>2026-08-15T10:00:00+08:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-08-18T14:20:00+08:00</lastmod>
</sitemap>
</sitemapindex>而每一份子檔內，才是真正列出頁面網址的 <urlset>。驗收的重點是：點開 sitemap-posts-1.xml，裡面的 loc 必須是像 https://example.com/blog/xxx/ 這種會渲染出內容的頁面，而不是又一個 .xml。索引檔只能有一層，不該出現索引檔再指向索引檔的多重巢狀。
5.2 分層的合理切法與兩個陷阱
我們通常會建議依內容類型切子檔，例如文章一份、產品一份、分類頁一份，這樣哪個區塊出問題一眼就能定位。要避免的陷阱有兩個：一是子檔之間網址重複，同一頁出現在多份子 sitemap 裡；二是索引檔列了子檔，但某份子檔實際回傳 404。搜尋引擎讀索引檔時若發現子檔抓不到，那整批頁面就一起被漏掉了。分層帶來彈性，但也把單點故障的風險放大，驗收時要逐份子檔確認狀態碼。
6. 多語系網站的 sitemap：hreflang 要寫進去而不是只放在 head
經營多語系網站時，很多人只在頁面的 <head> 裡放 hreflang 的 <link>，忘了 sitemap 本身也可以、也建議帶上語系對應。把 hreflang 標註進 sitemap 有個好處：搜尋引擎不必先抓每一頁才知道語系關係，在讀地圖的階段就能理解各語言版本之間的對應。
6.1 在 sitemap 裡標註 hreflang 的正確寫法
做法是在 <urlset> 加上 xhtml 命名空間，然後每一筆 <url> 內用 <xhtml:link> 列出所有語言版本，包含自己。以繁體中文與美式英文兩個版本為例：
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/zh-tw/</loc>
<xhtml:link rel="alternate" hreflang="zh-TW" href="https://example.com/zh-tw/"/>
<xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/"/>
</url>
</urlset>這裡有幾個我們會逐一檢查的重點：每個語言版本都必須列出完整的對應關係，而且要包含指向自己的那一條；各版本之間必須互相指認，不能只有 zh-TW 指向 en-US 而 en-US 沒指回來；x-default 通常指向語言選擇頁或預設語系首頁。這種對應關係只要有一邊漏掉或指錯，整組 hreflang 就可能被搜尋引擎判定無效。
6.2 sitemap 的 hreflang 與頁面 head 的關係
常有人問，既然 sitemap 裡標了 hreflang，頁面 <head> 裡還需要嗎。我們的立場是，兩者擇一實作即可，不必重複，但無論選哪一種，標註的內容一定要一致。實務上我們偏好放在 sitemap，因為多語系網站頁數多，集中在一份檔案裡維護，比散落在每一頁的 head 更好管理，也更不容易出現某幾頁忘了更新的情況。真正要避免的是最糟的那種做法：所有語系共用一個網址，只靠 JavaScript 切換文字，這樣搜尋引擎只會看到一份 HTML，其他語系內容形同不存在，hreflang 寫得再漂亮也救不回來。
7. 提交 GSC 之後，驗收才真正開始
把 sitemap 提交到 Google Search Console，對很多人來說是終點，對我們來說是起點。因為 GSC 會回饋搜尋引擎實際讀取這份檔案時發生了什麼，那才是驗收最有價值的部分。
7.1 提交後要盯的三個訊號
提交後在 Sitemap 報表裡，我們會確認狀態顯示為成功而非「無法擷取」，再看已探索的網址數量是否接近你 sitemap 的實際筆數。如果提交了三千筆但只探索到幾十筆，通常代表檔案格式有問題或大量網址無法存取。接著轉到「網頁索引」報表，交叉看是否有大量「已檢索但未收錄」或「找到但目前未編入索引」，這些狀態往往能反推回 sitemap 或頁面品質的問題。我們診斷過的案例中，有網站提交 sitemap 後一直看不到探索數字上升，追下去才發現是 sitemap 回傳的編碼有誤，XML 檔頭宣告 UTF-8 卻夾雜了其他編碼的字元，GSC 直接判定無法解析。這種問題在 Sitemap 報表的狀態欄會明白寫出來，只是很多人提交完就不再回頭看。
7.2 把 sitemap 位置也寫進 robots.txt
除了在 GSC 提交，我們一定會在 robots.txt 裡加上一行，讓沒有透過 GSC 提交的其他搜尋引擎也能發現它：
Sitemap: https://example.com/sitemap.xml這一行放在 robots.txt 的任何位置都可以，它是獨立指令，不受 User-agent 區塊影響。我們把它視為 sitemap 驗收的最後一哩，確保這份地圖不只 Google 看得到，其他爬蟲也找得到入口。
8. 常見問題
8.1 sitemap.xml 一定要放在網站根目錄嗎
放在根目錄（如 https://example.com/sitemap.xml）是最單純、也最不會出錯的做法，因為 sitemap 只能宣告與它自己同一路徑層級或更深層的網址。如果你把 sitemap 放在子目錄，它就只能涵蓋該子目錄底下的頁面。若確實需要放在別處，記得透過 GSC 提交完整網址，並在 robots.txt 用 Sitemap 指令指明位置，搜尋引擎就能正確讀取。
8.2 sitemap 裡可以放被 noindex 的頁面嗎
不建議。sitemap 的語意是「我希望這些頁被索引」，放進 noindex 頁會送出互相矛盾的訊號，也會稀釋抓取資源。正確做法是 sitemap 只收錄希望被索引、且 canonical 指向自己的頁面。登入頁、購物車、後台這類本來就不該被收錄的頁面，直接排除在 sitemap 之外。
8.3 更新一篇文章後，多久 sitemap 才會反映
這取決於你的 sitemap 是如何產生的。如果是動態產出，理想狀況是頁面一更新，對應的 lastmod 就即時變動；如果是排程產檔，就會有時間差。我們的建議是讓 sitemap 的產出綁在內容發布或更新的動作上，而不是固定每天重產一次，這樣 lastmod 才會準確反映真實變動，搜尋引擎也更願意信任它。
8.4 提交 sitemap 就能保證頁面被收錄嗎
不能。sitemap 的作用是幫助搜尋引擎「發現」頁面，收不收錄是另一回事，取決於頁面本身的內容品質、是否重複、是否有足夠的內部連結與價值。我們看過很多人以為提交 sitemap 就萬事俱備，結果頁面遲遲不被收錄，問題往往出在內容太薄或與其他頁面高度重複，而不是 sitemap 有錯。sitemap 負責把門打開，能不能進得去要看內容。換個角度說，當頁面遲遲不被收錄時，與其反覆重新提交 sitemap，不如回頭檢查那一頁是不是和站內其他頁面講了幾乎一樣的事，或者內容是否單薄到搜尋引擎覺得沒有收錄的必要。把力氣花在內容上，通常比在 sitemap 上調整更能解決收錄問題。
8.5 我該把圖片和影片也放進 sitemap 嗎
如果圖片或影片是頁面重要的內容資產，而且你希望它們出現在圖片或影片搜尋結果，是可以用專屬的 image 或 video sitemap 擴充標註的。但對多數以文字內容為主的網站，我們會先把基本的網頁 sitemap 做到正確、乾淨、與實際頁數相符，再視需求評估要不要加上媒體標註。基礎沒做好之前，先加進階標註只是把複雜度往上疊。
8.6 sitemap 多久會被搜尋引擎重新讀取一次
沒有固定頻率。搜尋引擎會依你過去更新的規律，自行決定多久回來讀一次，更新越頻繁、lastmod 越可信的網站，通常回訪越勤。這也是我們強調 lastmod 要誠實的原因之一：當它學會信任你的 lastmod，就會在你真的更新時更快回來抓。如果你剛上架一批重要內容、希望搜尋引擎盡快看到，可以在 GSC 重新提交一次 sitemap 當作主動通知，但平時不必為了催抓取而反覆重新提交，效果有限。
8.7 sitemap 需要壓縮成 .gz 嗎
當單一 sitemap 檔案很大時，壓縮成 gzip 格式（sitemap.xml.gz）可以縮短傳輸時間，主流搜尋引擎都支援讀取壓縮版。但壓縮不是必要的，對中小型網站來說，未壓縮的檔案反而方便你隨時打開檢查內容。我們的判斷標準是：檔案大到影響抓取效率再壓縮，否則保持可讀性優先，驗收時也比較省事。需要注意的是，即使壓縮，單檔仍受五萬筆網址與未壓縮 50MB 的上限約束，壓縮只省傳輸，不放寬數量限制，超過就還是要改用 sitemap index 分檔。