網站 Sitemap 入門指南：為什麼每個網站都需要一份網站地圖才能被 Google 找到
Sitemap（網站地圖）是一份把你網站所有可被收錄網址完整列出來的清單檔案，作用是主動告訴搜尋引擎「這裡有哪些頁面、什麼時候更新過」，讓爬蟲不必靠運氣自己摸路。它管的是「被發現」…
Sitemap 是什麼？一句話講清楚它的作用
Sitemap（網站地圖）是一份把你網站所有可被收錄網址完整列出來的清單檔案，作用是主動告訴搜尋引擎「這裡有哪些頁面、什麼時候更新過」，讓爬蟲不必靠運氣自己摸路。它管的是「被發現」這一步，對排名高低沒有直接作用。一份規範的 XML sitemap 單檔最多只能放 50,000 個網址、未壓縮不超過 50MB，超過就得拆成 sitemap index [來源：〈sitemaps XML 格式〉 https://www.sitemaps.org/protocol.html 2026-06-29]。這個上限直接決定大型網站要不要拆檔，後面會展開。
重點先看：Google 官方明說 sitemap 不是排名因素，它只幫爬蟲「發現」網址；單一檔案上限 50,000 網址 / 50MB 未壓縮 [來源：〈Manage your sitemaps〉 https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview 2026-06-29]。把它當排名開關，是用錯了力氣。
講白一點，sitemap 是一份給機器看的「名片清單」。你把名片遞出去，對方要不要收、什麼時候收，決定權不在你手裡。很多剛用 WordPress 架好網站的人，把 sitemap 當成「按下去就會收錄」的開關，提交完焦慮地每天刷 Google Search Console，看新頁面出來了沒。如果你連站都還沒架好，可以從 30 分鐘快速架好 WordPress開始。這個焦慮本身，其實就反映了對 sitemap 真實作用的誤解。
要判斷「要不要做 sitemap」，得先理解它的本質。下表把它跟幾個常被搞混的概念拆開。
| 項目 | 本質 | 主要對象 | 管的事 |
|---|---|---|---|
| XML sitemap | 結構化網址清單（.xml） | 搜尋引擎爬蟲 | 這裡有哪些頁面要被收錄 |
| HTML sitemap | 一般網頁導覽頁 | 真人訪客 | 幫人找到深層頁面 |
| robots.txt | 爬蟲指令檔 | 搜尋引擎爬蟲 | 可不可以爬 |
| canonical | HTML 標記 | 搜尋引擎 | 這頁的正本是誰 |
本質上，sitemap 記錄的是每個網址、最後更新時間（lastmod）、更新頾率（changefreq）、優先順序（priority）這幾個欄位。不過 Google 已多次表示，priority 跟 changefreq 它基本忽略，只有 lastmod 稍微會參考，而且你得誠實填、不能亂塞 [來源：〈Manage your sitemaps〉 https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview 2026-06-29]。把心力花在調 priority 數值上，產出接近零。
提交 sitemap 的性質屬於「建議」，命令權不在你手上。Google 收到之後還是會自己決定要不要收錄、什麼時候收。這個限制要先承認，後面所有討論才會成立。如果你的網站結構健康、內部連結完整，sitemap 只是錦上添花；想先打好底子，可以從 SEO 友善的網站架構怎麼規劃看起；如果結構一團亂，sitemap 也救不了你，它只會把那份亂更清楚地暴露出來。
XML sitemap 與 HTML sitemap 的差別
XML sitemap 是寫給搜尋引擎爬蟲讀的機器碼清單，目的是加速收錄；HTML sitemap 是寫給真人看的網頁導覽頁，目的是幫訪客找到深層頁面。兩者服務對象不同、格式不同、SEO 作用也不同，把它們混為一談是最常見的入門錯誤。
XML 版用.xml 副檔名，內容是純結構化資料，你提交到 WordPress 網站提交 Search Console 與 sitemap，或寫進 WordPress SEO 基礎設定裡的 robots.txt 讓搜尋引擎自己抓。對絕大多數網站，這一種就夠了。它的角色很單純：一份機器讀得懂的網址清單，搜尋引擎照單決定要不要收。想搞懂搜尋結果是怎麼運作的，可以先看 SERP 搜尋結果頁運作機制。
HTML 版則是一個普通的網頁，把站內重要頁面的名稱與連結整理出來，放在某個分類頁或頁尾。它的主要價值落在使用者體驗與內部連結這兩塊，對爬蟲的吸引力是附帶效果。對一個頁面動輒上百篇的部落格，HTML sitemap 能讓訪客快速找到舊文，同時也等於多了一層內部連結網絡。
| 比較項 | XML sitemap | HTML sitemap |
|---|---|---|
| 格式 | .xml 機器碼 | 普通 HTML 網頁 |
| 對象 | 搜尋引擎爬蟲 | 真人訪客 |
| 主要目的 | 加速頁面被發現與收錄 | 導覽、提升使用者體驗 |
| SEO 直接作用 | 間接（影響收錄） | 間接（內部連結＋停留） |
| 提交方式 | Search Console / robots.txt | 站內選單、頁尾連結 |
| 多數網站需要嗎 | 需要 | 視網站規模，非必要 |
這兩種可以同時存在，互不衝突。但有一件事絕對不要做：把 HTML 版那個導覽頁的網址，拿去當 XML sitemap 提交到 Search Console。Google 要的是機器碼清單，你給它一頁給人看的網頁，它只會回你一個「無法讀取格式」的錯誤。
還有一類針對特定內容類型的進階版本：圖片 sitemap、影片 sitemap、新聞 sitemap。這些不是每個網站都需要，只有當你有大量圖片想被收進圖片搜尋、或經營影音內容、或跑新聞站時才值得做。如果你只是個寫文章的部落格，硬上圖片 sitemap 的邊際收益接近零，不如把心力花在 圖片 SEO 的 alt 描述與壓縮上，順手把每篇的 標題標籤 Title Tag 寫好，回報還比較實在。
提交 sitemap 不會直接拉動排名，它只管被收錄
不會。Sitemap 影響的是「被收錄」而不是「排名高低」，它不是排名訊號。一個頁面能不能排上去，取決於內容品質、關鍵字佈局與外部連結，跟有沒有寫進 sitemap 無關。內容品質這一塊，Google 看的是 E-E-A-T 經驗、專業、權威、信任這幾個面向，sitemap 寫得多漂亮在這裡幾乎不計入。Google 官方文件講得很直白：sitemap 是幫助爬蟲「發現」網址的輔助管道，不是排名因素 [來源：〈Manage your sitemaps〉 https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview 2026-06-29]。
這句話值得多想一秒。市面上很多教學把 sitemap 包裝成「做了就會被 Google 收錄、SEO 變好」的萬靈丹，連某些外掛的銷售頁都這樣寫。但現實是，sitemap 從來不決定你排第幾名。真正影響排名的是頁面本身：內容是否切中搜尋意圖、E-E-A-T 夠不夠紮實、技術架構有沒有拖累、反向連結強不強。把「排名沒起色」怪罪到沒做 sitemap，是搞錯了方向。
那為什麼大家還是會把 sitemap 跟「SEO 變好」連在一起？因為它的價值是間接的。sitemap 確保你的好內容「先被收錄」，被收錄了才有資格參與排名競爭。這條鏈是：發現 → 收錄 → 排名。sitemap 只站在第一段，後面兩段它完全插不上手。想搞懂後面這段，可以對照Google 搜尋演算法核心規則，看排名訊號到底長什麼樣；想往上爬一階，提升 Google 排名的關鍵因素會比改 sitemap 更有用。
一個常見的誤判方向：商品頁 SEO 做得很紮實，標題、描述、結構化資料都到位，但流量就是上不來，第一反應往往是「是不是 sitemap 沒做好」，或懷疑該不該搭配 SEO 自然流量與廣告一起做。實際檢查卻常發現 sitemap 完全正常、頁面也都被索引，真正的問題出在商品頁跟分類頁在搶同一個關鍵字，發生關鍵字蠶食。sitemap 出問題的機率，遠低於內容與架構出問題的機率。
規模、孤立度與更新頻率，決定 sitemap 的價值高低
當網站規模大、頁面彼此連結稀疏、有大量深層內容或剛上線沒有外部連結時，sitemap 的價值才會明顯浮現。對一個結構清楚、內部連結完善的十頁形象網站，做不做其實差別很小。判斷要不要認真做 sitemap，可以從三個條件看：網站是否夠新、還沒累積任何反向連結，這時 sitemap 是主動跟搜尋引擎打招呼的唯一管道；規模是否大到深層頁面靠選單要點好幾層才到，讓爬蟲的爬取預算可能不夠用；以及更新頻率是否頻繁到必須讓搜尋引擎快速知道「又有新頁面了」，像新聞、部落格、電商新品都屬於這類。最後一個關鍵條件是孤立頁面密度，也就是那些沒有任何內部連結指向的頁面，這種頁面不靠 sitemap 幾乎一定被埋沒。
反向判斷也很重要。如果你的網站是個結構清楚、彼此都連得到的小型形象站或作品集，sitemap 屬於「做了安心、不做也不會怎樣」那一類。小站做了不會吃虧，但不值得為了它失眠。很多時候，小站的收錄問題出在 永久連結設定沒弄好、或是網域剛換 www 與 non-www 沒統一，又或者 SSL 憑證還沒掛上，這些都比 sitemap 影響更大。
這裡要承認一個不確定性：到底多大算「大到需要認真做 sitemap」？沒有一個硬門檻。實務上的常見分界是，頁面數破百、且有持續產出內容的網站，做完整 sitemap 的回報開始變得明顯；十頁以下的形象站，把心力放在內容與內部連結，CP 值高得多。會不會踩到那條線，主要看網站的孤立頁面密度與更新頻率，總頁數只是參考。這也牽涉到爬取預算怎麼分配，頁面越多、越深層，爬蟲能花在你站上的額度就越要算著用。
用兩個維度判斷要不要投入心力：規模與孤立度
把抽象的「要不要認真做」轉成可判讀的象限，用兩個維度來定位你的網站最清楚。第一個維度是「規模」：總頁面數少、還是已經破百上千。第二個維度是「孤立度」：多數頁面都能靠主選單或內部連結在三層以內點到，還是有大量要點好幾層、甚至完全沒有內部連結指向的深層頁。把這兩個維度交叉，會得到四個象限，每個象限對應不同的投入建議。
| 規模 / 孤立度 | 孤立度低（內部連結健全） | 孤立度高（有深層頁或孤立頁） |
|---|---|---|
| 小規模（十頁上下） | 象限一：基礎 sitemap 即可，重心放內容 | 象限二：先補內部連結，再做 sitemap 兜底 |
| 大規模（破百上千頁） | 象限三：標準多檔 sitemap，定期看落差 | 象限四：必須拆檔分類，sitemaps 配合連結工程一起修 |
象限一的小站，sitemap 屬於保險動作，WordPress 外掛預設產出就夠用，不必多花時間調校。象限二的網站，真正缺的是內部連結結構，sitemap 只能把已經存在的深層頁送進去，無法替它們建立可被點擊的路徑；這類網站先修網站架構，回報會比調 sitemap 高。象限三的中大型網站，要做的是標準動作：按內容類型拆檔、定期檢查落差、誠實更新 lastmod。象限四最棘手，常見於老電商或累積多年的內容站，sitemap 拆檔只能解決「發現」問題，真正卡收錄的往往是孤立頁太多、分類頁互相搶字、或篩選頁製造大量重複，這類問題的根在架構與內容策略，sitemap 只是其中一環。
把網站放進象限之後，還要再問一個動態問題：這個象限會移動嗎？一個剛起步的部落格今天在象限一，隨著文章累積到兩三百篇、分類越分越細，半年後會往象限三移動；一個電商站一波大促銷上架幾千個 SKU，可能瞬間從象限三跳到象限四。sitemap 策略要跟著這個移動調整，固定一套設定用到底，等網站長大之後就會跟現實脫節。
對電商網站，這件事更關鍵。商品頁動輒數千個，加上分類、篩選、變體，很容易產生大量爬蟲摸不到的深層頁。這時不只 sitemap 要做，還要分頁拆檔，並且好好處理商品變體與缺貨頁。如果這塊沒處理好，你可以參考電商商品頁 SEO 優化的做法，會比死磕 sitemap 格式更有感。商品頁體驗本身也要穩，Core Web Vitals 核心體驗指標沒顧好，再完美的 sitemap 也救不了跳出率。如果等不及自然流量發酵，也可以先了解 SEA 關鍵字廣告與 SEM 怎麼搭配，用付費流量先把數據跑出來。
大站拆檔的標準做法：分類、命名、與 index 檔
頁面數量逼近 50,000 上限，或是不同類型頁面有截然不同的更新節奏，就該拆檔。拆檔的核心原則是「按內容類型分」，讓每一份 sitemap 內部的頁面性質一致，這樣 lastmod 的更新頻率才會真實，也方便你在 Search Console 裡單獨觀察某一類頁面的收錄狀況。常見的拆法是文章一份、商品一份、分類一份、標籤一份，各自獨立成檔。
命名上建議讓人一眼看懂用途，例如 sitemap-posts.xml、sitemap-products.xml、sitemap-categories.xml，不要用流水號 sitemap1.xml 這種無意義命名。原因很實際：日後要在 Search Console 一張張報表裡找問題，看得懂檔名能省下大量時間。拆完之後，用一個 sitemap index 檔（通常命名 sitemap.xml）把所有子檔包起來，這個 index 檔列出每個子檔的網址，提交時只要提交 index 檔，搜尋引擎就會自動往下抓所有子檔。
- 每份子檔控制在遠低於 50,000 網址的數量，留成長空間，避免每次新增就要重拆。
- 同一份子檔內的頁面更新節奏盡量一致，商品檔每天可能動，文章檔可能每週動，混在一起會讓 lastmod 失真。
- index 檔最多可列 50,000 個子檔，對絕大多數網站綽綽有餘。
- 子檔移除或整併時，記得同步更新 index 檔，不要留下指向不存在檔案的死連結。
另一個大站常見的陷阱是「變體頁全部列進去」。一件衣服有紅藍黑三色、S 到 XL 五個尺寸，背後可能產生十幾個網址，但它們的 canonical 通常都指向同一個主商品頁。把這十幾個變體網址全塞進 sitemap，等於把同一份內容重複提交十幾次，既浪費爬取預算，也讓「已提交 vs 已索引」的落差看起來異常巨大，因為 Google 會把變體合併到 canonical，只收一個。正確做法是只列 canonical 指向的主版本，變體網址交給 canonical 處理，這跟canonical 解決重複內容的邏輯一致。
該放進 sitemap 的網址，與必須排除的網址
只放你希望被收錄、而且對外開放（沒有 noindex、沒有被封鎖）的網址。最常見的錯誤是把分頁、篩選頁、tag 頁、感謝頁、後台登入頁全部倒進去，結果提交一堆不該被收錄的垃圾網址，反而浪費爬蟲的注意力。
哪些東西該排除？把這份清單當成預設值。實務上看到「已提交 500、已索引 12」這種巨大落差，原因十之八九出在這裡。
- noindex 的頁面：你都叫搜尋引擎不要收錄了，卻把它寫進 sitemap，這是自相矛盾。
- robots.txt 封鎖的頁面：被擋的網址不該再列進 sitemap。
- 分頁與篩選重複頁：例如排序、顏色篩選產生的變體，多半是重複內容。
- 感謝頁、結帳流程頁：這些頁面被收錄對使用者毫無意義。
- 站內搜尋結果頁：等於把搜尋引擎的結果頁再丟給它收錄，毫無價值。
重點原則是：只列規範網址（canonical）。一個頁面如果有多個版本，例如 http 與 https、有無結尾斜線、或印列版，只把 canonical 指向的那個版本放進去，重複版本不要全部塞。這跟 canonical 網址解決重複內容的邏輯是同一件事。如果你之前做過 301 與 302 轉址，舊網址也不要再放進新 sitemap，免得訊號打架。網址命名本身也要先顧好，細節可參考 SEO 網址命名與 URL 優化。
唯一稍微有用的欄位是 lastmod，而且要誠實填，上次更新是什麼時候就寫什麼時候，不要為了顯得「很新鮮」而把沒動過的頁面標成昨天更新。Google 比對之後發現不實，這個欄位的可信度會被打折 [來源：〈Manage your sitemaps〉 https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview 2026-06-29]。與其糾結 priority 數值，把同樣的時間投到 關鍵字研究，回報會高得多。
回到檔案上限。一個 sitemap 檔案最多 50,000 個網址、未壓縮 50MB [來源：〈sitemaps XML 格式〉 https://www.sitemaps.org/protocol.html 2026-06-29]。超過就要拆成多個檔案，再用一個 sitemap index 檔把它們包起來。sitemap index 是什麼？簡單講就是「sitemap 的 sitemap」，一個清單的清單。一個網站可以有多個 sitemap，這是大型網站的標準做法，不是犯規。
| 欄位 | Google 看重程度 | 要不要花時間 |
|---|---|---|
| loc（網址） | 必要 | 必填、確保正確 |
| lastmod（最後更新） | 會參考 | 誠實填寫即可 |
| changefreq（更新頻率） | 基本忽略 | 不必調 |
| priority（優先順序） | 基本忽略 | 不必調 |
電商網站要特別處理商品變體頁與缺貨頁。變體頁如果是同一個 canonical，就不要重複列；缺貨頁如果是暫時缺貨，可以留著，但如果是永久下架，記得用 404 頁面或轉址處理，不要讓一堆死頁留在 sitemap 裡。提交大量薄內容頁，會讓 Google 對整站的內容品質打上問號，這在 低品質內容被降權的討論裡很常見；流量真的大幅下滑時，再對照 破解 SEO 保證第一頁的迷思校正預期。
提交 Sitemap 後的收錄時程，與那個落差數字
沒有保證時間。快則幾天、慢則數週，也可能提交了卻一直不被收錄索引。提交 sitemap 等於把網址送進待審佇列，不保證一定被挑中；真正能判斷結果的數字，是 Search Console 裡「已提交 vs 已索引」的落差。
新站通常幾天到兩週會開始有頁面被索引，但這只是經驗值，沒有官方保證時程。想長期追蹤到底收了幾頁、沒收幾頁，就靠 索引狀態報表那組數字。Google 從不承諾「提交後多久會收錄」，任何給你明確數字的人，要嘛是凭運氣、要嘛是在講特定案例。你能做的，是把變數控制好，然後等。
真正該盯的，是 Search Console 的「已提交的網址」與「已索引的網址」這兩張報表。還沒接觸過這套工具的，先看一篇Google Search Console 入門介紹會比較好上手。這份報表的功能 Google 官方有完整說明 [來源：〈Search Console 中的網頁索引報告〉 https://support.google.com/search-console 2026-06-29]。提交了 200 個網址、被索引 180 個，那很健康；如果已提交 200、已索引只剩 5，問題十之八九不在 sitemap，而在內容品質或網站架構。
把這個落差看清楚之後，還得認清第二層現實：就算頁面順利被收錄，也未必能換來流量。Ahrefs 分析其 Content Explorer 資料庫約 140 億個頁面發現，96.55% 的頁面從 Google 拿不到任何自然流量 [來源：Ahrefs〈96.55% of Content Gets No Traffic From Google〉 https://ahrefs.com/blog/search-traffic-study/ 2023-12-01]。這組數字再次印證：sitemap 只負責把頁面送進收錄池，能不能被點擊、能不能排上去，靠的是內容本身有沒有切中搜尋意圖，sitemap 的完整度在這一關幫不上忙。
一份 sitemap 最有價值的產出，不是那個.xml 檔，而是 Search Console 裡「已提交 vs 已索引」的落差數字。那個差距才是你網站真正的健康報告。
從這個角度看，sitemap 在這裡的角色其實是異常偵測工具。你提交之後，那個落差會直接告訴你收錄到底正不正常。落差小，你的內容跟架構大致沒問題；落差大，別急著改 sitemap 格式，先去查為什麼 Google 不願意收。常見原因包括內容太薄、被判定重複、子網域與子目錄配置混亂、或是被 演算法更新波及，這時候看 網站流量下滑的復原策略會比改 sitemap 實際。
提交後可以主動請求索引個別網址，Search Console 有「要求索引」的功能，背後對應的是 網址審查工具 URL Inspection，但每次有數量限制，而且不保證即時收錄，更多實戰技巧看 Search Console 提升成效的實戰技巧。這功能比較適合用在少數重要新頁，不是拿來批量狂刷的工具。影響收錄速度的關鍵，是網站權重、內容獨特性與爬取預算，不是 sitemap 的格式完美度。想確認某頁到底被收了沒，可以參考查詢網頁是否被 Google 收錄的方法。
落差太大時，依序排查這五個原因
當「已提交」與「已索引」之間出現明顯落差，多數人的直覺是去改 sitemap，但這幾乎從來不是答案。落差代表 Google 收到了網址、卻選擇不收，原因落在下面幾個方向，建議照順序檢查，由便宜到貴。
| 排查順序 | 可能原因 | 怎麼驗證 | 處理方向 |
|---|---|---|---|
| 1 | 頁面被 noindex 或 robots.txt 擋住 | 逐頁用 URL Inspection 看「覆蓋範圍」狀態 | 移除衝突指令，確認訊號一致 |
| 2 | 內容太薄或被判定重複 | 比對同主題頁面，看是否互相抄襲或空殼 | 補深內容、合併重複頁、設 canonical |
| 3 | canonical 指向混亂 | 檢查每頁 canonical 是否指向自己或正本 | 修正指向，只列規範版本進 sitemap |
| 4 | 頁面載入失敗或回傳錯誤碼 | 用瀏覽器無痕模式打開，看是否 5xx 或跳轉鏈過長 | 修伺服器與轉址，確保回傳 200 |
| 5 | 整站品質被演算法下修 | 對照流量下滑復原，看是否同步波及多頁 | 回到內容與 E-E-A-T 全面盤點 |
把這張表當成流水線：先排除訊號衝突這類一分鐘就能查的技術問題，再進入內容品質這種需要動手改的層面。很多人卡在第一步之外的原因，是因為前面四項都沒問題、卻還是不收，那多半是整站品質訊號出了狀況，單頁單頁修沒有用，要從站內 SEO 與E-E-A-T 的角度做整體盤點。記得一個原則：sitemap 把頁面送進待審佇列，它對「要不要收」沒有投票權，真正決定收錄的是頁面本身的品質與訊號一致性。
以這類累積型內容站或中小型電商為例，常見的狀況是這樣的：站長在 Search Console 看到一個讓人心慌的數字，已提交約 800 到 1,200 個網址、已索引卻只有約 200 到 350 個，落差落在六到八成。這個幅度在累積多年的部落格、或上架商品逐漸過百的電商站，並不罕見，通常不是 sitemap 格式壞掉，而是裡面混進了不該列的網址。依典型表現，這類落差往往集中在幾種來源：分頁與篩選產生的重複網址約佔三到五成、缺貨或下架但沒清理的死頁約佔一成多、標籤頁與搜尋結果頁這類薄內容頁約佔一成多，真正屬於「內容沒問題卻不被收」的比例，反而不高。實務上常見的處理順序是，先把分頁、篩選、感謝頁這類明顯該排除的網址從 sitemap 移除並補上 canonical，一輪調整後重新提交，約四到八週內，已索引數字通常會往約 500 到 650 個的方向回升，落差收斂到三成上下，這算是相對健康的收斂幅度。
這裡要誠實指出一個限制：就算落差收斂到三成，剩下的那一塊也很難歸零。「已檢索—未索引」這個狀態，Google 給的資訊有限，你會看到網址被讀取、卻收不下來，背後常是內容獨特性或品質訊號不足，這一塊無法靠改 sitemap 解決，要回到補深內容與整併重複頁的硬功夫。換句話說，sitemap 能幫你把「送錯的網址」清乾淨，讓落差數字誠實反映真正的收錄能力，但它救不了「內容本身不夠好」這件事。決策角度在這裡很明確：sitemap 是除錯工具，不是增長工具，把心力分配在「先讓落差誠實、再補強內容」，比反覆調格式更能把那塊收不下來的比例往下降。
Sitemap、robots.txt、canonical 三者的分工
三者各司其職：robots.txt 管的是「可不可以爬」、canonical 管的是「這頁的正本是誰」、sitemap 管的是「這裡有哪些頁面要被收錄」。把三者搞混或互相矛盾，是技術性 SEO 最常見的收錄災難來源。
robots.txt 可以擋爬蟲抓取整個目錄或某些網址。但你不能一邊在 robots.txt 封鎖某頁，一邊又把那頁寫進 sitemap，這等於一邊叫人別來、一邊寄邀請函。被擋的網址不該再寫進 sitemap，否則訊號自相矛盾，Google 會困惑到底要不要理你。
canonical 指向的規範網址，才是該進 sitemap 的版本。一個頁面如果同時存在多個網址版本，重複頁不要列，只列 canonical。這跟前面講「只放規範網址」是同一件事。把 canonical 跟 sitemap 想成兩個對外發言窗口，它們講的必須是同一套故事，不然聽眾會不知道該信誰。想弄懂 標準網址 canonical 怎麼設，可以把那篇文章當成設定手冊對照。
順帶一提，robots.txt 裡可以用 Sitemap: 指令宣告 sitemap 的位置，這是搜尋引擎自動發現 sitemap 的管道之一。你不用把 sitemap 網址到處貼，只要寫進 robots.txt，爬蟲下次來訪就會自己讀到。這也是為什麼 SEO 入門教學常把 robots.txt 跟 sitemap 綁在一起講。
| 工具 | 管的問題 | 矛盾時的後果 |
|---|---|---|
| robots.txt | 可不可以爬 | 封鎖頁卻寫進 sitemap → 訊號打架 |
| canonical | 正本是誰 | 列了非規範版本 → 重複收錄或被合併 |
| sitemap | 有哪些頁面要被收錄 | 放了 noindex 頁 → 自相矛盾 |
| noindex | 不要被收錄 | 同時出現在 sitemap → 訊號混淆 |
noindex 的頁面也不要放進 sitemap，邏輯跟 robots 封鎖一致：你都告訴搜尋引擎「這頁不要收」了，又把它塞進「請收這些頁」的清單，等於左手打右手。這兩個指令該怎麼分工、誰先誰後，可以對照robots.txt 與 noindex 的差別來看。三者不一致時，搜尋引擎會以更嚴格的訊號為準，這表示它傾向「不收」。也就是說，矛盾幾乎一定導致整批頁面不被收錄，吃虧的是你自己。
如果你網站有多語系版本，還要再加上 hreflang 多語系標記。hreflang 跟 sitemap 的搭配是另一個容易出錯的點，原則一樣：標記的網址、canonical、跟 sitemap 裡列的，三者要講同一套話。大型多語系站常見的收錄問題，有一半出在這三個訊號對不上。多語系情境還有一個專屬作法：把 hreflang 直接寫進 sitemap，用 sitemap 來宣告各語言版本的對應關係，這對頁面數龐大、無法逐一在 HTML 加標記的網站特別實用。除了 Google，你也可以用 Bing Webmaster 提交 sitemap 搶攻 Yahoo 流量擴大收錄管道；想評估 Bing 這邊的市場，先看看 Bing 關鍵字搜尋量怎麼查再決定要不要投入。
每個月十分鐘的 sitemap 健檢清單
把 sitemap 當成固定流程來跑，比偶爾想起來才看一次有效得多。這份十分鐘的清單每個月固定走一次，就能把多數收錄異常在變嚴重前攔下來。
- 開 Search Console 的「網頁索引」報表，記下「已提交」與「已索引」兩個數字，跟上個月比對，落差是否突然擴大。
- 點進「未索引」的原因分類，看集中在哪一類（例如「已檢索—未索引」通常指向內容品質問題，「已封鎖」指向指令衝突）。
- 抽三到五個沒被收的網址，用 URL Inspection 逐頁看原因，確認是不是 noindex、robots 或 canonical 出問題。
- 檢查 sitemap 檔本身能不能正常開啟、有沒有回傳錯誤碼，Search Console 的 sitemap 報表會直接標示「無法讀取」的狀態。
- 大站額外做一件事：按子檔分別看落差，鎖定哪一類頁面（例如某個商品分類）集體出問題。
這份清單的重點不在於「修好 sitemap」，而在於把那個落差數字養成固定的觀察指標。數字穩定，代表你的收錄管道順暢；數字突然跳動，等於網站對你舉手示意哪裡出狀況了。把十分鐘投在這裡，回報遠高於反覆調 priority 或重新產生 sitemap 檔。多數收錄災難很少是瞬間發生，多半是落差悄悄擴大好幾週才被發現，每月走一次清單，就是要把那個窗口壓到最短。
把這份清單跟一般的SEO 地雷排查分開看，兩者節奏不同：地雷排查是季度或半年的大盤點，sitemap 健檢是每個月的例行巡邏。例行巡邏成本低、能及早發現訊號衝突與死頁累積，大盤點則處理架構與內容策略層面的問題。兩者搭配，收錄這條鏈才會穩。
結論：把 Sitemap 當體檢報告，而不是排名法寶
到底要不要做 sitemap？要做，但心態要對：把它當成一份定期更新的「收錄健康度體檢報告」，它沒有衝排名的開關作用。每個月回 Search Console 看一次那個落差數字，比糾結格式完美更能救你的流量。
對任何超過十頁、有持續產出內容的網站，sitemap 都是低成本高保障的基礎動作。它的成本很低，WordPress 用 Rank Math 或 Yoast 一鍵就能自動產生，根本不必手寫；想比較這兩款的外掛生態，WordPress SEO 外掛完整評測整理得很清楚，產出工具的細節可以看 sitemap 產生與提交的實作步驟。它的保障則很實際：確保你花心力寫的好內容，不會因為爬蟲摸不到而被埋沒。寫好內容的方法，可以搭配 SEO 文章寫作技巧一起看。
而 WordPress 之所以是sitemap 自動化的首選方案，跟它的市占規模直接相關：根據 W3Techs 截至 2026 年 6 月的調查，WordPress 被用於 41.5% 的所有網站，在已知內容管理系統的網站中更高達 59.2% [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]。正因為佔了這麼大的市場份額，Rank Math、Yoast 這類外掛才會把 sitemap 產生、lastmod 更新、拆檔邏輯全部自動化處理掉，一般站長只要裝好、設定完，幾乎不用再碰 sitemap 的格式細節。
把「已提交 vs 已索引」落差列為固定的 SEO 健檢指標。每個月花十分鐘看一次，落差突然變大就深究原因。這個動作的回報，遠高於你跑去調 priority 數值或重新格式化 sitemap。想看更完整的健檢思路，可以對照 SEO 網站健檢工具評比跟 常見拖垮排名的 SEO 地雷；若是想知道自家品牌在網路上的能見度變化，Ahrefs Brand Radar 品牌雷達是另一個可追蹤的指標。
說到底，真正長期決定收錄與排名的，是內容品質與網站架構，sitemap 只是讓好內容別被埋沒的保險。它的份量會隨網站規模、頁面孤立程度與更新頻率而浮動：新站要靠它對外打招呼、大站要靠它處理爬取預算、電商要靠它管理成千上萬的商品頁。但對一個內部連結良好的十頁形象網站，它屬於做了安心、不做也不會怎樣那一類。想讓 AI 工具幫你把收錄與排名這類數據整理成可執行的建議，可以先用 Search Console 的 AI 報告把那個落差數字讀成白話結論，再試試 Ahrefs Agent A 這類 AI SEO 助理。
所以與其問「sitemap 要不要做」，不如問兩個更實在的問題：我的網站有沒有爬蟲摸不到的頁面？我的「已提交 vs 已索引」落差正不正常？這兩個答案，才會真正決定你該花多少心力在 sitemap 上。如果你想更系統性地把收錄這件事理清楚，技術性 SEO 與爬蟲溝通策略跟 站內 SEO 內容優化會是比 sitemap 本身更值得投資的下一步；真的分身乏術，再考慮找 SEO 委外服務協助。
常見問題
網站一定要有 sitemap 嗎？
不是絕對必要，但強烈建議有。規模小、內部連結完整的形象站，沒有 sitemap 通常也不影響收錄；一旦頁面變多、有深層頁或孤立頁，sitemap 就是確保它們被發現的基本保險。
sitemap 最多可以放幾個網址？
單一檔案上限是 50,000 個網址、未壓縮 50MB [來源：〈sitemaps XML 格式〉 https://www.sitemaps.org/protocol.html 2026-06-29]。超過就得拆成多個檔案，再用 sitemap index 包起來，一個網站可以同時擁有多個 sitemap。
WordPress 怎麼自動產生 sitemap？
WordPress 從 5.5 版起內建基本的 XML sitemap 功能；更完整的做法是裝 Rank Math 或 Yoast 這類 SEO 外掛，設定好就會自動產生並持續更新，不必手寫任何程式碼。
提交 sitemap 一定會被收錄嗎？
不一定。提交只是讓搜尋引擎知道這些網址存在，是否收錄仍由它自行決定。內容太薄、重複、或被其他訊號封鎖的頁面，提交了也可能一直不收。
sitemap 要放 noindex 的頁面嗎？
不要。noindex 表示你希望該頁不被收錄，把它寫進 sitemap 等於訊號互相矛盾。sitemap 只放確實要被收錄、對外開放的網址。
大型網站的 sitemap 要怎麼拆分？
依內容類型或區段拆成多個檔案，例如文章、商品、分類各一份，每份不超過 50,000 網址，再用一個 sitemap index 檔統整，提交時只要提交 index 檔即可。
sitemap 要多久更新一次？
由工具自動更新最好，每次有新頁面或舊頁修改就同步刷新 lastmod。手動維護的話，建議跟內容發布節奏一致，至少每月檢查一次是否有該移除的死頁。
「已提交」與「已索引」落差很大，是 sitemap 出問題嗎？
通常不是。落差大代表 Google 收到了網址、卻選擇不收，原因多半落在內容太薄、重複、被 noindex 或 robots 封鎖、canonical 指向混亂，或整站品質被演算法下修。先依序排查訊號衝突與內容品質，再去動 sitemap 格式。
行動優先索引下，sitemap 要特別做什麼嗎？
不需要為行動版單獨做一份 sitemap，但你要確保 sitemap 裡列的網址在行動版上能正常開啟、回傳 200、內容與桌機版一致。Google 已全面採行動優先索引，行動版打不開或內容縮水的頁面，就算寫進 sitemap 也難被正常收錄。