你照著教學裝好外掛、按下產生 sitemap、貼進 Search Console 提交，狀態欄顯示「成功」，於是你以為大功告成。可是幾週後打開索引涵蓋範圍報告，發現一堆網址卡在「已找到，目前尚未建立索引」，有些重要的產品頁、文章頁遲遲進不了搜尋結果，反而是一些你根本不想被收錄的測試頁、感謝頁悄悄被翻了出來。
問題往往不在你「有沒有提交」，而在你提交的那份清單裡，混進了不該出現的網址。XML Sitemap（網站地圖）是一份用 XML 格式寫成的網址清單，作用是主動告訴 Google「這些是我希望你來看、來收錄的頁面」。它本質上是一張優先順序的推薦名單，可是大多數人把它當成「全站網址的備份」，把能列的都列進去，結果這份名單就失去了引導的意義。
一份乾淨、只放標準頁面的 sitemap，會讓 Google 把抓取資源花在真正重要的頁面上；一份塞滿 noindex、重定向、重複網址的 sitemap，反而會稀釋訊號，甚至讓 Google 開始懷疑你這份清單的可信度。這篇會帶你把設定的每一個實作細節做對，先弄懂 sitemap 在幫 Google 做的是什麼事，再一條一條排除那些該被踢出去的網址，最後給你一份送出前可以逐項打勾的自查清單。
XML Sitemap 是什麼，為什麼設定對了能讓重要頁優先被收錄
先講結論，sitemap 不是排名因素，它影響的是「爬取」這一關，而爬取是排名的前提。Google 的爬蟲透過網站內部的連結，一頁一頁爬出你的網站結構。如果你的內部連結很健康，每個頁面都有路徑可以走到，那麼即使沒有 sitemap，Google 多半也能把網站摸清楚。
那為什麼還要設定 sitemap？因為現實中的網站常常沒那麼完美。新上線的站、剛改版的站、外部連結還很少的站，Google 不容易發現你；網頁數量一多、層級一深，那些藏在五六層底下、或是沒有任何內部連結指過去的孤兒頁面，爬蟲很可能就漏掉了。這時候 sitemap 就像你主動遞給對方的一份名單，告訴它「除了你自己爬到的，這些頁面也請你看一下」。
不過要提醒你一件常被誤解的事，提交 sitemap 只是一個提示，不是命令。Google 官方說得很白，就算你在 sitemap 裡放了一堆網址，也不代表它會把每一個都收錄。它會不會收、什麼時候收，仍然由 Google 自己的演算法決定。所以 sitemap 真正能幫上忙的地方，是讓 Google「發現」頁面更有效率，而不是逼它「收錄」。也正因為如此，這份清單放什麼、不放什麼，才會直接影響到你想被優先看見的頁面有沒有出現在對的位置。
那到底要不要做 sitemap？如果你的網站規模不大、內部連結又健康，老實說有沒有提交差別不大。但只要符合下面任一種情況，就強烈建議認真設定：網站超過 500 個頁面、網站剛上線還沒什麼反向連結、網站經常更新或有大量影片圖片內容、或網站有多語系版本。而既然要做，就值得把細節做對，不然提交了一份髒清單，效果可能比不提交還差。
哪些 URL 絕對不該放進 sitemap
這是整件事最容易出錯、也最少人講清楚的地方。一份好的 sitemap 有一條鐵律，裡面每一個網址都應該回傳 200 狀態、沒有 noindex、而且是你希望出現在搜尋結果裡的標準版本。反過來說，下面這幾類網址只要混進去，就是在發出互相矛盾的訊號。
第一類，帶 noindex 的頁面。 你在某個頁面掛上 noindex，等於明確跟 Google 說「這頁不要收錄」；可是你又把它列進 sitemap，等於同一時間說「這頁請你收錄」。這種自打嘴巴的指令，會讓 Google 覺得你的 sitemap 不太可靠。常見的 noindex 頁面包括標籤彙整頁、站內搜尋結果頁、感謝頁、後台登入頁，這些本來就不該出現在清單裡。
第二類，會發生重定向的網址。 如果某個網址 A 會 301 或 302 跳轉到 B，那 sitemap 裡就該直接放最終目的地 B，不要放會跳轉的 A。讓 Google 多走一次跳轉是浪費它的抓取資源，而抓取資源（爬取預算）對大型網站來說是有限的，能省則省。
第三類，重複內容或非標準版本的網址。 這是最隱形的坑。同一篇內容如果因為網址參數、Session ID、分頁、或 http 與 https、有無 www 的差異，產生好幾個能打開的網址，你只該把那個「標準網址」放進 sitemap，其他重複版本一律不放，並在那些重複頁掛上 canonical 標籤指回標準版。把一堆重複網址全塞進去，不只灌大檔案、增加雜訊，還可能讓 Google 分不清你真正想收的是哪一個。
第四類，回傳錯誤狀態的網址。 404 找不到、410 已刪除、或 5xx 伺服器錯誤的網址，當然也不該留在清單裡。這類網址常常是搬家、改版後留下來的殘骸，定期清掉它們，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 只反映頁面「實質內容」的最後變更日期。所謂實質變更，指的是主要內文、結構化資料、或頁面上的連結有了有意義的更新；至於把頁尾的版權年份從去年改成今年這種小動作，不算實質更新，不該去動 lastmod。把這個欄位填準，等於給了 Google 一個可信的訊號，告訴它哪些頁面最近真的有變、值得回來重新抓一次，這比你硬把 priority 全部拉到 1.0 有用得多。
大型網站怎麼用 Sitemap Index 把 sitemap 切開
當你的網站越長越大，單一一份 sitemap 會撞到硬限制。不論是哪種格式，單一 sitemap 檔案在未壓縮的狀態下，大小不能超過 50 MB，網址數量不能超過 50,000 個。一旦超過，你就必須把它拆成好幾份，這時候登場的就是 Sitemap Index（sitemap 索引檔）。
Sitemap Index 的概念很單純，它本身不直接列網頁網址，而是列出好幾份子 sitemap 的位置，像一份「sitemap 的目錄」。你把這份索引檔提交給 Google，它就會順著裡面的清單，一份一份去讀子 sitemap。要注意索引檔本身一樣有上限，最多列 50,000 份 sitemap、總大小不超過 50 MB，不過絕大多數網站離這個天花板還很遠。
實務上，拆分不只是為了不撞上限，更是為了管理和除錯方便。比較聰明的拆法是「按內容類型分群」，例如文章一份、產品頁一份、分類頁一份、圖片一份。這樣做的好處是，當 Search Console 報告某一份 sitemap 出現抓取錯誤時，你一眼就能定位是哪一類頁面出了問題，而不是在五萬個網址裡大海撈針。如果你用 WordPress 搭配主流 SEO 外掛，它通常會自動幫你生成一個 sitemap 索引檔，再依文章、頁面、分類等類型切成多份子 sitemap，這套結構直接沿用就很合理。
如果你的 sitemap 裡還標記了圖片或影片，也有各自的數量規定要記得。用標記方式把圖片加進現有 sitemap 時，每一個網頁最多只能標記 1,000 張圖片；如果你經營的是新聞型網站、要用新聞 sitemap，那份檔案最多只放 1,000 則新聞網址，而且只該包含兩天內發布的內容，超過兩天的就要從裡面移除。這些數字平常用不到，但一旦你的站開始大量產出媒體內容，沒留意就會踩線。
sitemap 該放哪裡、怎麼提交、多久才會被抓取
檔案做好了，接下來是放對位置、用對方法送出去。先講位置，建議把 sitemap 放在網站根目錄底下，也就是像 你的網域/sitemap.xml 這樣的路徑。原因是除非你透過 Search Console 提交，否則一份 sitemap 只會影響它所在目錄的下層；放在根目錄，才能涵蓋整個網站的所有檔案。還有兩個容易忽略的硬規定，sitemap 檔案必須用 UTF-8 編碼，而且裡面所有網址都要用完整的絕對網址，不能寫成省略網域的相對路徑。
提交方式主要有兩種。最推薦的是透過 Google Search Console 的 sitemap 報告，把 sitemap 的網址貼上去送出。這個方法的好處不只是提交，而是你能持續看到 Googlebot 上次存取 sitemap 的時間、有沒有讀取成功、以及處理時遇到了哪些錯誤，等於多了一個監控儀表板。另一種方式是在網站根目錄的 robots.txt 檔案裡，加上一行 Sitemap: 後面接 sitemap 的完整網址，Google 下次來讀 robots.txt 時就會順手發現它，但這種方式比較被動，也看不到後續的處理狀態。兩種可以同時用，但 Search Console 那條一定要做。
至於多久會被抓取、被收錄，這題沒有標準答案。提交之後 Google 通常會在幾天內來讀取你的 sitemap，但「讀到」不等於「立刻收錄裡面每一頁」。Googlebot 每天要處理的網站和內容量極大，新頁面從被發現到真正進索引，可能幾天、也可能更久，取決於你網站的權重、內容品質、以及這個頁面本身的重要性。所以提交完不必每天盯著重新送，sitemap 一旦被成功存取，Google 會自己定期回來檢索，你只要隔一段時間進 Search Console 確認狀態正常就好。重複提交同一份沒有變動的 sitemap，並不會加快收錄。
順帶釐清一個常被搞混的東西，XML sitemap 和 HTML sitemap 是兩回事。XML sitemap 是寫給搜尋引擎看的網址清單；HTML sitemap 則是放在網站上、給真人瀏覽的導覽頁，幫訪客快速找到各區內容。兩者目的不同，但都對體驗和爬取有幫助，不要把它們混為一談。
送出 sitemap 前，先把這 10 項逐一打勾
設定的細節談完了，最後給你一份送出前的自查清單。每次重大改版、或定期維護時，照著從頭到尾走一遍，能擋掉絕大多數常見的 sitemap 問題。
- 清單裡每個網址都回傳 200 狀態，沒有 404、410 或 5xx。
- 沒有任何帶 noindex 的頁面混在裡面。
- 沒有會 301 或 302 跳轉的網址，列的都是最終目的地。
- 每篇內容只放標準網址，重複版本與帶參數的網址都已排除。
- 所有網址都用完整的絕對網址，而且屬於同一個網域。
- 檔案用 UTF-8 編碼，特殊字元都已正確做實體逸出。
- 單一檔案沒有超過 50,000 個網址或 50 MB，超過的已用 Sitemap Index 切開。
- lastmod 反映的是內容實質變更的真實日期，不是每次產生就刷新的假時間。
- sitemap 放在網站根目錄，並已在 robots.txt 裡標明位置。
- 已透過 Search Console 提交，並確認狀態為成功讀取、沒有錯誤回報。
這份清單看起來瑣碎，但每一條背後都對應一個會實際拖慢收錄的問題。把 sitemap 維護乾淨，並不會直接幫你衝上排名，它做的是把「被發現」這一關打通，讓你辛苦寫好的頁面有機會被 Google 看見、進而參與排名。真正決勝的內容、體驗和內部連結，才有舞台可以發揮。先把這張推薦名單整理乾淨，再回頭去打磨那些更難、但更關鍵的優化，才是讓重要頁面持續被優先收錄的長久之計。