XML Sitemap 怎麼規劃？只提交真正想被搜尋的網址

先說結論：Sitemap 是想被發現的網址清單，不是網站備份

XML Sitemap 應該只列出你希望搜尋引擎在搜尋結果中呈現的完整、公開、可索引、canonical 網址。草稿、登入頁、站內搜尋結果、noindex 頁、轉址來源、錯誤頁、追蹤參數版與其他重複版本，不應因為「網站上有這條路徑」就一起塞進清單。

規劃時依序做三件事：

1. 先決定哪些頁面值得被搜尋，再從這些頁面產生 Sitemap。
2. 超過單檔限制時一定要分檔；未超過時，也可以按內容類型分檔，讓後續診斷更清楚。
3. 提交後分開驗證檔案、網址與索引結果：讀取成功只表示搜尋引擎能解析清單，不代表每個網址已被爬取或索引。

Google 說明，Sitemap 能協助搜尋引擎發現重要頁面與專門媒體，但不保證所有項目都會被爬取或索引。若小型網站的每個重要頁面都能從首頁沿著連結抵達，Sitemap 甚至不是發現內容的必要條件；它仍可作為網址清冊與監測入口，卻不能取代清楚的內部連結架構。

哪些網址該放進 Sitemap？用五道門檻判斷

每個候選 URL 都應同時通過以下門檻。只要其中一項不成立，就先處理頁面狀態，不要用提交清單掩蓋衝突。

門檻	應該看到什麼	不應列入的常見例子
有搜尋價值	頁面回答獨立問題，內容完整且預計長期保留	空標籤頁、站內搜尋結果、測試頁
公開可取得	不需登入，正式伺服器能穩定回傳內容	會員訂單、編輯預覽、暫存環境
成功回應	最終網址直接回傳 200	301／308 轉址來源、404、410、持續 5xx
允許索引	沒有 noindex，也沒有其他明確排除條件	刻意排除的活動完成頁、內部工具
是代表版本	網址是 self-canonical，站內連結也指向它	追蹤參數、列印版、排序版、重複主機名

Google 建議 Sitemap 使用完整絕對 URL，而且只列希望出現在搜尋結果的 canonical 版本。這項訊號比永久轉址或 rel="canonical" 弱；如果 Sitemap 列參數版、頁面宣告乾淨版、導覽又連舊路徑，搜尋引擎仍要自行判斷哪一個才是代表。

所以，Sitemap 應由「已發布且可索引的內容資料」產生，而不是對伺服器路由做不加判斷的全量匯出。若網站有重複版本，先完成canonical 與轉址的選擇；若問題是頁面不該出現在搜尋結果，則先釐清 robots.txt 與 noindex 的控制層。

XML 檔案至少要正確到什麼程度？

最精簡的 XML Sitemap 只需要網址集合、協定命名空間，以及每個項目的 <loc>：

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/coffee-grinder/</loc>
    <lastmod>2026-07-29</lastmod>
  </url>
</urlset>

檔案應使用 UTF-8，網址要是完整且可直接取得的正式版本。XML 中的特殊字元必須正確跳脫；例如參數網址裡的 & 要寫成 &，否則可能造成解析錯誤。

<lastmod> 是選填欄位，代表頁面主要內容最後一次有意義修改的日期，不是 Sitemap 每次重新建置的時間。Google 表示，可信的 lastmod 可作為安排重新爬取的訊號；若每天把全站日期改成今天，久而久之可能不再被信任。正文、結構化資料或重要連結實質更新時可以更新日期，只有頁尾年份或微小樣板變化則不必。

<changefreq> 與 <priority> 也是協定中的選填欄位，但 Google 明確表示不使用它們。與其替每篇文章猜「每週」或填滿最高優先度，不如維護正確 URL 與可信的 lastmod。

何時需要分檔？限制與診斷是兩個理由

Google 與 Sitemap Protocol 的單檔上限是 50,000 個 URL 或未壓縮 50 MB；任一上限先到，就必須拆成多個 Sitemap。需要管理多檔時，可建立 Sitemap index，讓它列出各個子檔，而不是把另一層 Sitemap index 塞進 index。

未達上限不代表一定要維持單檔。若網站有清楚的內容類型、語言、地區或更新流程，分檔能讓監測更有判斷力，例如：

• /sitemaps/articles.xml：正式文章。
• /sitemaps/topics.xml：有獨立內容的主題樞紐。
• /sitemaps/products-01.xml：商品分批檔案。
• /sitemaps/videos.xml：需要影片擴充資訊的觀看頁。

合理的分檔邊界應該對應「可以獨立修正的一群網址」。若某檔大量出現錯誤，就能直接定位到內容模板、商品匯入或特定語系。反過來，把每 100 個 URL 隨機切一檔，通常只增加維護成本，不會提升排名。

完整案例：540 條路徑，最後只提交 438 個網址

以下是虛構教學案例，用來示範網址盤點、分檔與驗證，不是 MKT Notes 或任何企業的搜尋資料。

一個食譜學習站的路由匯出共有 540 條：

類型	數量	決策
已發布食譜文章	420	公開、200、可索引、self-canonical，列入
有獨立介紹與導覽的主題頁	18	具搜尋與閱讀價值，列入
自動產生的薄弱標籤頁	30	暫不作搜尋入口，noindex，不列入
登入後編輯預覽	24	存取受限，不列入
已永久搬遷的舊網址	18	301 到新網址，只列最終目標
活動追蹤參數版本	20	canonical 指向乾淨版，不列入
站內搜尋結果	10	noindex，不列入

團隊把 438 個網址分成 articles.xml 的 420 篇文章，以及 topics.xml 的 18 個主題頁，再由一個 Sitemap index 統一列出。這個站遠低於強制分檔上限；分成兩檔的理由，是兩種頁面由不同模板與編輯流程產生，發生異常時可以分開看。

處理一段時間後，團隊在 Page indexing report 依 Sitemap 篩選，得到以下假設觀察值：

分檔	提交網址	已索引	其他狀態	下一步
文章	420	398	12 已爬取未索引、6 另選 canonical、4 取得錯誤	先查 4 個錯誤，再分別抽查內容與代表版本
主題頁	18	16	2 已爬取未索引	檢查頁面是否真的有獨立價值，而非重複文章清單

這些數字不能推論「提交後有 414 頁因 Sitemap 而收錄」。合理結論只有：搜尋引擎已能按兩群網址提供處理狀態，而問題集中在哪一類較容易判斷。文章索引率若用 398 ÷ 420 計算約為 94.8%，主題頁則是 16 ÷ 18 約為 88.9%；分母是各檔提交網址，不應和全站所有可開啟路徑混在一起。

提交後怎麼驗證？分成三層，不要只看 Success

第一層：檔案能否被取得與解析

先在未登入狀態開啟正式 Sitemap URL，確認回傳成功、內容是最新版本、沒有被登入或 robots.txt 阻擋。Google Search Console 的 Sitemaps report 會顯示是否可讀、最後處理時間、發現的 URL 數與解析錯誤；Bing Webmaster Tools 也會列出處理狀態、發現數量與個別警告。

Success 只回答「清單可被取得與處理」。如果顯示 Couldn’t fetch、格式錯誤、不同主機或過多轉址，先修檔案與伺服器，不要急著檢討文章內容。

第二層：清單內容是否符合站方決策

把 Sitemap URL 與內容資料庫或路由清冊比對，抽查：

• 是否混入轉址、404、noindex、登入頁或非 canonical 版本。
• 是否漏掉已發布且應被搜尋的重要頁。
• 網址的協定、主機名、大小寫與結尾斜線是否一致。
• lastmod 是否真的對應主要內容變更。
• 分檔數量與 Sitemap index 是否一致。

刪除 Search Console 中的一筆 Sitemap 提交紀錄，不會讓 Google 忘記已知 URL；同樣地，把 URL 從檔案移除，也不是刪除索引指令。頁面若要退出搜尋結果，仍需用符合目標的 noindex、404／410、存取控制或轉址處理。

第三層：網址後續處理與索引結果

在 Page indexing report 依「All submitted pages」或特定 Sitemap 篩選，分開看已索引、重複版本、已發現未索引、已爬取未索引、伺服器錯誤與其他原因。對重要樣本再使用 URL Inspection，比較現在正式頁面與 Google 已掌握版本。

不要追求每個已知 URL 都索引。真正的成功條件是：希望被搜尋的 canonical 頁面保持可取得、可索引，排除項目符合預期，而且異常能被定位與修正。 若讀者仍分不清「已提交、已爬取、已索引與有排名」，可回到搜尋可見度的三道關卡逐層診斷。

八步工作流：從內容清冊到持續監測

1. 定義搜尋入口：先寫出哪些頁面服務獨立讀者問題，哪些只是功能、狀態或重複路徑。
2. 從正式內容來源產生候選：使用已發布狀態、權限與頁面類型，不直接把所有路由全收。
3. 逐項套用納入門檻：檢查 200、公開、可索引、canonical 與預計長期保留。
4. 決定分檔邊界：超過限制就拆檔；未超過時，只為可維護、可診斷的內容群組分檔。
5. 輸出並驗證 XML：使用完整 URL、正確命名空間與可信 lastmod，檢查特殊字元和實際回應。
6. 發布並提交入口：把 Sitemap 或 Sitemap index 放在穩定 URL，可在 Search Console、Bing Webmaster Tools 與 robots.txt 提供位置。
7. 分層檢查結果：先看檔案能否讀取，再比對清單內容，最後才看各類網址的索引原因。
8. 記錄差異與修正日期：保存新增、移除、錯誤類型、代表樣本與修改原因，不用每天重送掩蓋未修問題。

七個常見誤判與限制

把全站所有可開啟 URL 都放進去

路由存在不等於值得搜尋。參數版、轉址頁與 noindex 頁混入清單，會讓站方同時送出互相矛盾的訊號，也讓報表難以區分預期排除與真正錯誤。

Sitemap 沒有某頁，就以為搜尋引擎不會找到

搜尋引擎仍可從站內連結、外部連結與過去紀錄發現 URL。Sitemap 是發現與監測線索，不是允許清單，也不是安全或存取控制。

提交成功就等於完成收錄

成功只表示檔案可讀。每個 URL 仍要經過排程、爬取、內容處理、canonical 選擇與索引判斷；索引後也不保證對特定查詢有排名。

每天更新全站 lastmod

沒有實質修改卻改日期，會讓欄位失去可信度。只在主要內容、重要連結或結構化資料有意義變更時更新；無法可靠判斷時可以省略。

用 priority 與 changefreq 控制 Googlebot

Google 表示不使用這兩個欄位。網站不會因為每頁都填最高 priority 就獲得優先收錄；應把維護時間放在內容、回應與連結一致性。

小站為了「更專業」切成大量小檔

分檔本身沒有排名加成。若檔案邊界無法對應內容類型、責任或故障範圍，只會增加提交、監測與失效風險。

只看 Sitemap report，不抽查正式頁面

清單可解析，不代表其中頁面回傳 200、允許索引或宣告一致。每次重大發布都應抽查代表 URL，並在 Page indexing report 觀察後續狀態。

最後帶走：把 Sitemap 當成可驗證的編輯清冊

• 只列入希望出現在搜尋結果的公開、200、可索引、canonical URL。
• 不列草稿、登入頁、站內搜尋、noindex、轉址來源、錯誤與重複版本。
• 單檔不得超過 50,000 個 URL 或未壓縮 50 MB；需要時使用 Sitemap index。
• 未達上限也可按可診斷的內容類型分檔，但不要任意切碎。
• lastmod 只反映有意義的頁面修改；Google 不使用 changefreq 與 priority。
• 提交成功不等於爬取、索引或排名成功。
• 依序驗證檔案、清單與 Page indexing 狀態，對重要樣本再做 URL Inspection。
• Sitemap 補充內部連結，不能取代網站資訊架構、內容品質與正確索引控制。

一份好的 Sitemap 不在於網址最多，而在於它能準確表達網站的編輯決策：哪些頁面是正式、穩定、值得搜尋的代表版本。當內容狀態、canonical、站內連結與 Sitemap 說同一件事，搜尋引擎比較容易發現正確網址，團隊也能用一致分母追蹤真正需要處理的異常。