Search Console 的 Sitemap 報表打開，狀態欄一片「成功」，已探索的網址數字也對得上；過幾個星期回頭查「網頁索引」報表，卻發現一堆重要的產品頁、文章頁卡在「已找到，目前尚未建立索引」，幾個你根本不想被看到的測試頁反而先一步被收錄了。
問題通常不在有沒有交這份清單，而在清單裡混進了不該出現的網址。XML sitemap（網站地圖）是一份用 XML 格式寫成的網址清單，作用是主動告訴 Google 哪些頁面值得優先查看，本質上是一張推薦名單，不是網站的完整備份，多數人卻把能列的都列進去，這份名單也就失去了引導的意義。
Google 官方說得很明確，提交 sitemap 只是一種提示，不是命令，收不收錄終究由演算法決定；而 Google 願意花在每個網站上的檢索時間本來就有限，業界慣稱它爬取預算。把該拿掉、該補上的網址一一釐清，遠比死守 priority、changefreq 這些早就沒人看的欄位有用。先從 sitemap 在 Google 眼中扮演什麼角色講起。
Sitemap 是什麼？為什麼不是每個網站都非做不可？
先講一個常被搞混的地方，爬取（crawling）跟收錄（indexing）是兩件事，sitemap 影響的只是前者。Google 的爬蟲會順著網站內部的連結，一頁一頁把網站爬出來，如果內部連結結構健康，每個頁面都有路徑走得到，就算沒有 sitemap，Google 多半也能把網站摸清楚；收不收錄則是另一套演算法在判斷內容值不值得放進索引，兩件事不能混為一談。
那什麼時候該認真做 sitemap？Google 官方的說法是，網站規模不大、內部連結又健康的話，有沒有交這份清單差別不大，規模的參考門檻大約是五百個頁面以內。但只要符合下面任一種情況，就有必要花心力設定：網站頁面數量龐大、剛上線還沒什麼外部連結、內容經常更新或有大量影片圖片、或是有多語系版本。這幾種站的共通點是，Google 自己爬未必爬得完整，需要一份清單主動補位。
順帶一提，XML sitemap 是寫給搜尋引擎看的網址清單，跟放在網站上給真人瀏覽的 HTML 網站地圖是兩回事，兩者目的不同，別搞混。
哪些網址一放進 Sitemap，就是在給 Google 傳矛盾訊號
弄清楚 sitemap 只是提示、不是命令之後，接下來要處理的是清單裡放了什麼。一份乾淨的 sitemap 有一條鐵律，清單裡每個網址都該回傳 200 狀態、沒有 noindex，而且是你希望出現在搜尋結果裡的標準版本。反過來說，下面幾類網址只要混進去，就是同時對 Google 喊出兩種矛盾指令。
已經掛 noindex 的頁面
在某個頁面掛上 noindex，等於明確告訴 Google 這頁不要收錄，同一時間又把它列進 sitemap，等於在說這頁請你收錄。這種自相矛盾的訊號，不會讓 Google 兩邊都聽，只會讓它開始懷疑整份清單的可信度。標籤彙整頁、站內搜尋結果頁、感謝頁、後台登入頁，這幾類本來就該掛 noindex 的頁面，檢查一輪特別容易抓到漏網之魚。
會被導向別處的網址
如果某個網址 A 會被 301 或 302 導向到 B，sitemap 裡就該直接放最終目的地 B，不要放會跳轉的 A。讓 Google 多走一次轉址等於白白浪費檢索資源，這份資源對頁面量大的網站來說本來就有限，能省則省。
重複或非標準版本的網址
這是最容易被忽略的一類。同一篇內容如果因為網址參數、有無結尾斜線、分頁、http 與 https、有無 www 的差異，出現好幾個打得開的版本，只該把那個標準網址放進 sitemap，其他版本一律不放，並在重複頁面掛上 canonical 標籤指回標準版；分頁產生的網址（像是 /page/2/ 這種）通常也不值得單獨放進 sitemap，除非有明確理由要它被個別索引，多數情況把 canonical 指回第一頁或整合頁就好。把一堆重複網址全塞進去，不只讓檔案變大，還會讓 Google 分不清真正想收的是哪一個。
回傳錯誤狀態碼的網址
404 找不到、410 已經刪除、或是 5xx 這類伺服器錯誤的網址，當然也不該留在清單裡；還有一種更隱形的變體叫 soft 404，網頁明明沒有內容卻回傳 200 狀態，Google 官方也提醒這種頁面會讓爬蟲繼續白跑，一樣算在錯誤網址裡。這類網址常常是搬家、改版後留下的殘骸，定期清掉，sitemap 才會一直保持乾淨。
這幾類網址背後其實只有一個共通問題，敢不敢讓它原封不動出現在 Google 搜尋結果裡。敢，才放進去，其餘的全部請出去。
lastmod 才該認真填，priority 和 changefreq 早就不值得你花時間
把該踢除的網址清乾淨之後，剩下網址該怎麼標注，又是另一回事。很多 sitemap 產生器會自動幫你填三個欄位，lastmod（最後修改時間）、changefreq（更新頻率）、priority（優先程度），於是不少人以為把 priority 全設成 1.0、changefreq 全設成 daily，就能催 Google 多來抓幾次。這個觀念早就過時了。Google 在官方文件裡寫得很直接，它會忽略 priority 和 changefreq 這兩個值。原因不難理解，這兩個欄位被濫用得太嚴重，幾乎每個網站都把所有頁面的優先程度設到最高、更新頻率設成每天，資料一旦全部一樣就沒有資訊量，Google 乾脆不看，改用自己觀察到的頁面重要性與實際行為，去決定要不要抓、多久抓一次。
真正值得認真對待的是 lastmod。Google 確實會參考這個值，前提是它必須準確，而且可以被驗證，也就是 Google 會拿寫的時間去跟頁面實際的修改情況對照。這裡藏著一個很多人踩到的雷，有些產生器每次重新產生 sitemap，就把所有頁面的 lastmod 一律改成當下時間，明明內容根本沒動，時間卻天天在變；Google 對照幾次發現對不上，就會開始不信任這個訊號，最後乾脆整份都不看。
正確的做法是，lastmod 只反映頁面實質內容的最後變更日期。所謂實質變更，指的是主要內文、結構化資料、或頁面上的連結有了有意義的更新，把頁尾的版權年份從去年改成今年這種小動作，不算實質更新，不該去動 lastmod。舉例來說：
<url>
<loc>https://www.example.com/blog/xml-sitemap-optimization/</loc>
<lastmod>2026-06-18</lastmod>
</url>Code language: HTML, XML (xml)這裡的 lastmod 只有在這篇文章的內文真的被改過一次的情況下才會更新，不是每次重新產生 sitemap 就跳成當天日期。把這個欄位填準，等於給 Google 一個可信的訊號，告訴它哪些頁面最近真的有變、值得回來重新抓一次。
塞爆的 Sitemap，會吃掉多少爬取預算？
priority、changefreq 調得再漂亮都沒用，真正該在乎的是 Google 願意花在網站上的檢索時間夠不夠。這件事業界稱為爬取預算，由兩個部分組成，檢索容量上限與檢索需求。容量上限跟伺服器健康度有關，回應速度快、沒有頻繁出錯，Google 才敢放心多派一點檢索連線過來；需求則跟網站規模、更新頻率、內容品質與熱門程度有關，跟同類型的其他網站相比，內容值不值得常常回來看，決定了 Google 願意分配多少時間。
Google 官方也誠實交代，這套精算主要是給規模夠大的網站看的，像是擁有超過一百萬個不重複頁面、內容變動頻率大概每週一次的大型網站，或是超過一萬個頁面、幾乎每天都在變動的中大型網站；如果網站沒有大量頻繁變動的頁面，或是新頁面通常在發布當天就被檢索到，其實不太需要花心力鑽研這一段，把 sitemap 維持在最新狀態、定期檢查索引涵蓋範圍就夠了。
不過即使是中小型網站，也有一個判準值得對照，Search Console 裡如果有大量網址被歸在「已找到，目前尚未建立索引」，就是爬取預算吃緊的訊號之一。Google 官方點名，網址庫的管理是網站主最能主動控制的因素，如果 Google 花太多時間檢索那些其實不重要、或是根本重複的網址，很可能就此判定網站其他部分不值得花時間查看，也不會提高預算來檢索網站。這正是為什麼 sitemap 裡塞進大量 noindex、重複、錯誤網址會反過來傷害真正重要的頁面，它們在跟一堆雜訊搶同一份有限的檢索時間。
大型網站的 Sitemap，怎麼拆才真正管用？
檢索預算有限，不代表把 sitemap 拆小就能無限換取更多時間，拆分真正要解決的是規模問題。Google 官方文件寫明，不論哪種格式，單一 sitemap 檔案在未壓縮的狀態下，大小不能超過 50 MB，網址數量不能超過 50,000 個。一旦超過，就得把它拆成好幾份，這時候登場的是 sitemap index（sitemap 索引檔）。
sitemap index 本身不直接列網頁網址，而是列出好幾份子 sitemap 的位置，像一份 sitemap 的目錄；把這份索引檔提交給 Google，它就會順著清單一份一份去讀子 sitemap。索引檔本身一樣有上限，Google 官方規定最多列 50,000 份子 sitemap，不過絕大多數網站離這個天花板還很遠。
實務上，拆分不只是為了不撞上限，更是為了管理和除錯方便。比較常見的拆法有三種：按內容類型分（文章一份、產品頁一份、分類頁一份），這樣哪一類頁面出問題，一眼就能定位；按重要性分，把首頁、核心分類頁放進同一份，次要或不常更新的頁面另外放一份；按更新頻率分，新聞或高頻更新的內容放一份、變動很少的靜態頁另外放一份，方便針對不同頁面設定不同的更新節奏。如果用 WordPress 搭配主流 SEO 外掛，通常會自動生成一個 sitemap index，再依文章、頁面、分類等類型切成多份子 sitemap，這套結構直接沿用就很合理。
如果 sitemap 裡還標記了圖片或影片，Google 官方也各自訂了數量規定。用標記方式把圖片加進現有 sitemap 時，每個網頁最多只能標記 1,000 張圖片；如果經營的是新聞型網站、要用新聞 sitemap，那份檔案最多只放 1,000 則新聞網址，而且只該包含近兩天內發布的內容，超過兩天就該從裡面移除。這些數字平常用不到，但一旦站點開始大量產出媒體內容，沒留意就會踩線。
送出前，這幾個 XML 格式錯誤最容易讓 Sitemap 直接解析失敗
前面談的都是網址該不該放，還有一層更基礎的問題是，檔案本身能不能被正確解析。sitemap 是一份 XML 檔案，網址裡如果出現 & 這種特殊符號卻沒有做實體逸出，寫成 & 而不是 &，整份 XML 就可能直接解析失敗，Google 讀不到，等於白做。除了 & 之外，網址裡任何非 ASCII 字元或空白，也建議先做好百分比編碼，避免格式跑掉。
另一個常見疏漏是相對路徑，sitemap 裡的每個網址都要寫成完整的絕對網址，像 https://www.example.com/about，不能只寫 /about 這種省略網域的寫法，Google 會照著列出的網址原封不動去檢索，寫錯就等於帶錯路。檔案編碼也有硬規定，sitemap 必須用 UTF-8 編碼，這點多數 CMS 或外掛會自動處理好，手動維護的網站則要特別檢查。
還有一種更容易被忽略的狀況，sitemap 檔案本身回傳 403、404 或 500，或是被自己的 robots.txt 擋住，爬蟲根本連讀取這份清單的機會都沒有；這種設定錯誤在網站開發階段用 Disallow: / 封鎖過全站、上線後卻忘記解除時特別常見。確認方式很簡單，用瀏覽器登出後直接打開 sitemap 網址，看看是不是真的能正常顯示。
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://www.example.com/sitemap.xmlCode language: plaintext (plaintext)上面這種寫法，robots.txt 封鎖後台路徑，但沒有連 sitemap 本身一起擋掉，是比較安全的配置；sitemap 的網址宣告放在檔案裡任何位置都可以，不受 User-agent 區塊限制。
交出去之後，Search Console 的哪些數字才是真正該看的？
格式跟位置都確認沒問題之後，真正要盯的是提交之後 Google 怎麼反應。狀態欄顯示成功，只代表 Google 成功讀到了這份 XML 檔案本身，不代表裡面列的每個網址都會被收錄；會不會收、什麼時候收，還是那句老話，由 Google 自己的演算法決定。真正該回頭確認的，是 Sitemap 報表裡「已探索」的網址數量，跟實際提交的網址數量對不對得起來，如果落差很大，通常代表清單裡有不少網址在讀取階段就被排除掉了。
再往下一層，把「網頁索引」報表用 sitemap 篩選，比對「已提交」跟「有效」的數量，這個缺口才是判斷 sitemap 有沒有真的發揮作用的關鍵。如果一堆網址卡在「已找到，目前尚未建立索引」，通常是前面幾節提到的問題疊在一起，清單裡混了太多不值得收錄的網址，拖累了 Google 對整個網站的檢索意願，也可能是頁面本身內容單薄，Google 判斷不划算收進索引。
至於多久會被抓取、被收錄，這題沒有標準答案。提交之後 Google 通常會在幾天內讀取 sitemap，但讀到不等於立刻收錄裡面每一頁，新頁面從被發現到真正進索引，可能幾天，也可能更久，取決於網站的權重、內容品質、以及這個頁面本身的重要性。sitemap 一旦被成功讀取，Google 會自己定期回來檢索，不必每天盯著重新送；重複提交同一份沒有變動的 sitemap，並不會加快收錄。
Sitemap 對 Google 以外的 AI 爬蟲來說，是不是同一張地圖？
前面談的每一條，焦點都放在 Googlebot 身上，但現在會讀這份清單的不只它一個。除了 Googlebot，現在檢索網站的還有一整批具名的 AI 爬蟲，像是 OpenAI 的 GPTBot、Anthropic 的 ClaudeBot、Perplexity 的 PerplexityBot，以及 Google 自己另外用來訓練 AI 的 Google-Extended。這些爬蟲各家都有公開文件說明自己的身分與行為，而 robots.txt 裡宣告 Sitemap 位置這件事，本來就是所有遵循這套公開協定的爬蟲共通讀得到的入口，不是 Google 專屬。
換句話說，為了 Googlebot 整理乾淨的那份 sitemap，某種程度上也是在為其他爬蟲鋪路。內容結構清楚、標題與段落有明確主張、資訊容易被抽取，才是決定會不會被 AI 生成的回答引用的關鍵，sitemap 只負責解決這個頁面爬得到、爬得對版本這個更基礎的前提，它不會讓內容變得更容易被引用，但如果連讓爬蟲找到都做不到，後面談引用就是空談。
至於要不要放行這些 AI 爬蟲，是另一個層次的決定，跟訓練資料授權、內容授權有關，不在這篇的討論範圍。但如果目標是讓內容有機會出現在 AI 搜尋的引用來源裡，至少要確保 robots.txt 沒有把它們一併擋掉，而 sitemap 依然是那份「這些頁面值得優先查看」的推薦名單，不管讀它的是哪一種爬蟲，乾淨、準確、只放真正想被看到的頁面，都是同一套邏輯。
Sitemap 做得再乾淨，也只是打通了被發現這一關，不會直接把排名往上推，更不會保證每個列進去的網址都被收錄。它真正做到的，是讓 Google 跟其他爬蟲把時間花在對的地方，不必在孤兒頁與雜訊裡瞎繞。把這份推薦名單維護好，是最基本、也最容易被忽略的技術門檻，之後要拚的內容深度、使用者體驗與內部連結，才是決定一個頁面最終能不能被優先收錄、進而排到前面的關鍵。