Sitemap 產生＋提交實作教學：3 步驟讓 Google 快速收錄你的網站每一頁
sitemap xml 的生成與提交，是把網站所有希望被收錄的頁面整理成一份清單交給 Google，目的是加快被發現與索引的速度，而不是直接抬升排名。WordPress 用戶靠 R…
sitemap xml 的生成與提交，是把網站所有希望被收錄的頁面整理成一份清單交給 Google，目的是加快被發現與索引的速度，而不是直接抬升排名。WordPress 用戶靠 Rank Math、Yoast 這類外掛就能自動生成並持續更新 sitemap.xml，提交時只要把路徑貼到 Google Search Console 即可；根據 Google 官方規範，單一 Sitemap 最多容納 50,000 個網址或未壓縮 50MB [來源：Google Search Central〈Manage your sitemaps〉〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。把它當成技術 SEO 的基本功，搭配內部連結、網址結構一起做，才能真正發揮價值。
Sitemap 是什麼：一份遞給搜尋引擎的網站目錄
Sitemap（網站地圖）就是把網站裡所有希望被收錄的頁面、圖片、影片整理成一份清單的檔案，功用是讓 Google、Bing 等搜尋引擎更有效率地發現與索引你的內容。它決定的是「Google 能不能、多快找到你」，而不是「你排第幾名」。
Sitemap 就像一本書前面的目錄，只是讀者換成搜尋引擎。最常見的格式是 XML（sitemap.xml），放在網站根目錄，專門給機器讀；想完整理解 XML Sitemap 對 SEO 的意義，從這個檔案的角色切入會更清楚。還有一種 HTML 版本，是給真人訪客瀏覽網站結構的導覽頁，兩者用途完全不同。
Sitemap 最有感的情境，是網站剛架好、剛大改版、規模變大，或 站內連結的佈局邏輯 還不完整的時候；這塊做得好，Google 爬蟲自己就能把大部分頁面串起來。Google 官方也說得很明白：如果網站的內部連結做得完整，爬蟲通常能自己找到大部分頁面，Sitemap 是輔助而不是必要條件 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。小站若連結做得好，不交 Sitemap 也會被收錄；但對新站或結構複雜的網站，提交 Sitemap 能明顯縮短被發現的等待時間。這也是 技術性 SEO 完整指南 會把 Sitemap 與 站內 SEO 優化攻略 放在同一條工作線上一起做的原因。
Sitemap 也不該單獨操作。它跟 SEO 網址結構優化、Canonical、轉址設定、結構化資料標記是同一組基本功，缺一塊都會讓技術地基鬆動。硬把 Sitemap 拆出來當成「做了排名就會變好」的開關，只會白忙一場。
sitemap.xml 裡到底寫了什麼：拆解一份標準 XML Sitemap
很多人提交了 Sitemap，卻從來沒打開看過裡面長什麼樣。其實 sitemap.xml 的結構很簡單，看懂了才知道自己在送什麼給 Google。最基本的一份 XML Sitemap，主體是一組 urlset 標籤包起來的網址清單，每個要被收錄的網址包在 loc 標籤裡，另外還會看到 lastmod、changefreq、priority 這三個常被誤解的標籤。
loc 是必填的，放的就是你希望被收錄的完整網址，包含 https 與網域，例如 https://example.com/about。lastmod 是選填的，標示這個網址最後更新的時間，格式是 YYYY-MM-DD。changefreq 與 priority 雖然規範上還在，但 Google 早已多次說明它們對排名與收錄幾乎沒有實質影響，Google 會根據自己的爬取結果自行判斷更新頻率與重要性 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。與其糾結 changefreq 要設成 daily、weekly 還是 monthly，把心力放在讓 lastmod 反映頁面真實異動狀態會更划算。
| 標籤 | 是否必填 | Google 是否參考 | 實務建議 |
|---|---|---|---|
| loc（網址） | 必填 | 是 | 填完整 https 網址，與 canonical 一致 |
| lastmod（最後更新） | 選填 | 是 | 反映真實異動時間，外掛多數會自動帶入 |
| changefreq（更新頻率） | 選填 | 幾乎忽略 | 不必手動調 |
| priority（優先權） | 選填 | 幾乎忽略 | 不必手動調 |
lastmod 看似不起眼，卻是新手最容易出錯的地方。常見的狀況是外掛把 lastmod 一律填成「今天」，每天所有頁面的時間都被刷新，這會讓 Google 誤以為整站每天都在大改，反而稀釋了 lastmod 的訊號價值。正確做法是 lastmod 只在頁面內容真的變動時才更新，例如新增段落、修正價格、更新數據；純粹調了版型或改了標點符號，多半不值得刷新 lastmod。多數主流外掛會根據文章的實際修改時間自動帶入，維持預設即可，手動覆寫反而容易弄巧成拙。
XML、HTML 與擴充型 Sitemap：該做哪一種
絕大多數網站只需要一份 XML Sitemap 就夠了。XML 是機器可讀的.xml 檔，提交給 Google Search Console，是 SEO 作業的標配；HTML Sitemap 則是網站內的一個導覽頁，主要服務使用者體驗，順便幫爬蟲；圖片、影片、新聞等擴充型 Sitemap，是當你的主力內容剛好是這類型時才值得加。這張表把幾種常見 Sitemap 一次比清楚。
| Sitemap 類型 | 主要服務對象 | 建議使用情境 | 提交到 GSC |
|---|---|---|---|
| XML Sitemap | 搜尋引擎機器人 | 所有網站的標配 | 是 |
| HTML Sitemap | 真人訪客 | 頁面多、分類複雜時輔助導覽 | 通常不必 |
| 圖片 Sitemap | 搜尋引擎 | 電商、作品集、大量圖片站 | 建議 |
| 影片 Sitemap | 搜尋引擎 | 網站以影片為主 | 建議 |
| 新聞 Sitemap | 搜尋引擎 | 新聞媒體搶時效 | 建議 |
實務選擇上，XML 是給機器看的清單、HTML 是給人看的導覽頁，兩者各司其職並不互相取代。經營電商的話，圖片 Sitemap 搭配 圖片 SEO 優化指南 與 WooCommerce 商品頁 SEO 會讓商品更容易在圖片搜尋被看見；影片型網站則把影片 Sitemap 當成主力，配合 圖片壓縮工具實測 控制檔案大小。新聞媒體用新聞 Sitemap，目的是讓最新文章在幾分鐘內就被 Google 抓到，這對搶時效的內容來說差很多。
Google 也支援把圖片、影片、新聞這些擴充元素合併在同一份 Sitemap 統一管理 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]，不必每種類型都切一份檔案，對小型網站來說合併管理反而更好維護。多數部落格與服務型網站真的只需要一份乾淨的 XML Sitemap，把心力省下來放在內容與 關鍵字研究工具推薦 上，投報率會高得多。
圖片與影片 Sitemap 的價值，其實在於提供 Google 抓不到的後設資料，例如圖片的授權來源、標題、地理座標，或是影片的播放長度、上傳日期、分類標籤。如果你的網站圖片本來就在 HTML 裡有清楚的 alt 文字與結構化標記，Google 在正常爬取時就能讀到，這時再額外做圖片 Sitemap 的邊際效益有限。真正該做圖片 Sitemap 的情境，是當圖片藏在 JavaScript 載入的燈箱、輪播或動態產生的內容裡，Google 一般爬取抓不到完整圖片清單，這時把所有圖片網址整理進 Sitemap 才有意義。
Sitemap 解決被發現，不解決排名
提交 Sitemap 解決的是「被發現」（discovery）的問題，不是「排名」（ranking）的問題。Google 官方多次公開說明 Sitemap 不影響排名 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]，它只是讓你的頁面更快進入索引。排名真正取決於內容相關性、E-E-A-T、外部連結、技術品質這幾個變數，跟有沒有交 Sitemap 沒有因果關係。網路上不少教學把 Sitemap 包裝成「提交了排名就會變好」，這是誤導，需要先排除。
把場景拉開來看：新站、剛改版、規模大或階層複雜、內部連結薄弱、多國語言、電商或媒體網站，這幾種最該提交 Sitemap，因為 Google 靠爬蟲不一定能在短時間內把頁面挖完。中小型網站如果內部連結做得完整，Google 靠爬取選單與頁內連結就能找到多數頁面，不提 Sitemap 也會被收錄 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。想確認目前哪些頁面已經被收進索引，可以對照 確認網頁有沒有被 Google 收錄 的做法，用 Search Console 的網址審查工具 逐一檢查。
真正能帶動排名的，是內容品質與整體 SEO 策略。內容相關性要看 搜尋意圖與關鍵字佈局，外部信任度要看反向連結與 E-E-A-T，技術品質要看 Core Web Vitals 與網站速度。Sitemap 在這整張圖裡只是一塊拼圖，不是主角。
外部連結這塊的影響力，有第三方數據可以佐證。一份分析 1,180 萬筆 Google 搜尋結果的研究發現，排名第一名的结果平均擁有的反向連結數量，是第 2 到第 10 名的 3.8 倍 [來源：Backlinko〈Search Engine Ranking: We Analyzed 11.8 Million Google Search Results〉 https://backlinko.com/search-engine-ranking 2025-04-14]。這恰好說明，把心力砸在反向連結與內容品質上，對排名的推動力遠勝於反覆調整 Sitemap，Sitemap 處理的始終是「被發現」這道關卡。
反直覺的是：對連結完整、規模小的網站，硬塞一份過期或塞滿垃圾頁的 Sitemap，反而會浪費爬取預算、拖慢重要頁面被收錄的速度。關於爬取預算的取捨，可以參考 爬取預算優化策略 的詳細討論。別把「有提交 Sitemap」當成績效指標，要追的是「重要頁面是否被穩定索引、排名是否持續往前」，後者才是 SEO 真正要顧的數字。
被發現 vs 被收錄：兩個容易混淆的階段
很多人把「Sitemap 提交了」直接等同於「頁面被收錄了」，這中間其實隔了好幾個階段。把這條流程拆開來看，才知道 Sitemap 到底在哪一關發揮作用，也才知道為什麼提交了卻還是搜不到。
一個網址從你按下發布到出現在搜尋結果，會經過三個關卡。第一關是「發現」（discovery），Google 知道有這個網址存在；第二關是「爬取」（crawl），Google 派爬蟲來抓網頁內容；第三關是「索引」（index），Google 把抓到的內容評估後收進資料庫，這時才有可能出現在搜尋結果。Sitemap 主要幫助的是第一關發現，對第二關與第三關的影響很有限。也就是說，把網址放進 Sitemap，Google 知道了這個網址存在，至於要不要爬、要不要收，取決於爬取預算、內容品質、技術品質、是否被 noindex 擋下等一連串其他因素。
這就解釋了為什麼明明已經提交 Sitemap，GSC 卻顯示「已發現，目前尚未建立索引」。這個狀態的意思是 Google 已經知道這個網址，只是基於各種原因（通常是爬取優先順序低、內容品質不足以排入索引、或重複內容被判定）暫時沒把它收進索引。遇到這種情況，反覆重新提交 Sitemap 通常解決不了問題，要回頭檢查的是內容是否有實質價值、是否與其他頁面構成重複、是否被 canonical 或 noindex 指向別處。想釐清重複內容的處理，可對照 Canonical 解決重複內容 的脈絡。
把這三個階段記清楚，就不會把所有收錄問題都怪罪到 Sitemap 身上。Sitemap 是起點的推進器，幫你跨過「被發現」這道門檻；至於能不能走完後面兩關，靠的是內容、技術與連結的整體實力，這也是 技術性 SEO 完整指南 一直強調的全局觀。
用 WordPress SEO 外掛自動生成 sitemap.xml
WordPress 用戶幾乎不用手動做 Sitemap。主流 SEO 外掛如 Rank Math、Yoast 都預設開啟 Sitemap 功能，安裝後即自動生成並持續更新，你只要複製路徑去提交就好。這也是為什麼剛架好 WordPress 的站長，通常第一份 Sitemap 幾乎都是「外掛送你的」，自己從零刻出來的反而是少數。如果你還在選外掛，可以先看 WordPress SEO 外掛評測 與 WordPress SEO 外掛影音教學。
這套自動化流程之所以重要，是因為 WordPress 早已是全球最普及的內容管理系統，佔了所有網站的 41.5%，在已知 CMS 的網站中更高達 59.2% [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]。換句話說，每三個用 CMS 架站的站長就有近兩個跑在 WordPress 上，等於這套「外掛自動生成 sitemap.xml」的玩法，直接套用在過半數的網站上都適用，先把外掛設好，幾乎等於把 Sitemap 這項基本功一次處理到位。
以 Rank Math 為例，操作流程很直覺。先把外掛裝起來，這部分可對照 WordPress 外掛安裝方法。接著的步驟如下：
- 進入 Rank Math 後台，找到 Sitemap Settings → General。
- 在 General 頁面最上方，會看到整體的 Sitemap 索引路徑（通常是 你的網域/sitemap_index.xml）。
- 複製這一條整體索引路徑，要提交的就是這個整體索引網址，單一分類的子地圖請留在原處不要單獨送出。
- 把這個路徑貼到 Google Search Console 的 Sitemap 頁面送出，就完成提交。
要特別留意的是，Rank Math 的 Sitemap 頁面裡會列出 post、page、category 等多張子地圖，很多人會誤把某一張子地圖的網址提交上去。請抓最上方的索引檔，它涵蓋了整個網站所有頁面的集合 [來源：Rank Math〈Sitemap Settings〉〈https://rankmath.com/kb/sitemap-settings/〉〈2026〉]。更詳細的設定可對照 Rank Math SEO 外掛教學，進階需求再參考 Rank Math Pro 進階功能。
自動化最大的好處是：新增或刪除頁面時，Sitemap 會同步更新，不用手動維護。對還在大量產出內容的階段特別省事。如果你是用 WordPress 架站，順著 WordPress SEO 優化全攻略 與 WordPress 部落格架站教學 把基本功走一遍，Sitemap 自然就會在對的時間出現。Yoast 的邏輯也差不多，預設就會生成 sitemap.xml，差別主要在設定介面的位置。
用外掛自動生成時，有幾個設定值值得動手調整，避免 Sitemap 把不需要的頁面也送出去。第一是分類與標籤頁，多數部落格的分類頁、標籤頁屬於整理性質，內容與文章本身高度重複，建議在 Sitemap 設定裡排除這類彙整頁，只留文章與重要頁面。第二是分頁與排序參數，商品列表的 ?page=2、?sort=price 這類網址會產生大量重複內容，務必從 Sitemap 剔除。第三是附件頁，WordPress 預設會為每張上傳圖片建立獨立附件頁，這些頁面幾乎沒有內容價值，建議關閉其索引並從 Sitemap 排除。Rank Math 與 Yoast 都提供這些選項，位置大多在 Sitemap Settings 底下的 Includes 或 Excludes 區塊，花十分鐘設定一次，後續就不用再操心。
沒有 WordPress：線上工具與爬蟲軟體怎麼生 Sitemap
沒有自動外掛的網站，可用線上工具或爬蟲軟體手動產生 sitemap.xml，下載後用 FTP 上傳到網站根目錄。這條路常見於自架站、Shopify、客製後台或純靜態網站。兩個最常被推薦的工具是 xml-sitemaps.com 線上服務，以及 Screaming Frog SEO Spider 桌面軟體。先用一張表抓出兩者的差異。
| 工具 | 類型 | 免費版上限 | 適合 | 缺點 |
|---|---|---|---|---|
| xml-sitemaps.com | 線上網頁工具 | 約 500 個頁面 | 快速、免安裝、小站 | 站一更新就要重跑重傳 |
| Screaming Frog SEO Spider | 桌面爬蟲軟體 | 約 500 個頁面 | 可設包含/排除頁、優先順序 | 要安裝、要懂設定 |
xml-sitemaps.com 的操作很陽春：打開網站，貼上你的網址，按 Start，等它跑完就能下載 sitemap.xml。免費版大約能處理 500 個頁面 [來源：xml-sitemaps.com〈https://www.xml-sitemaps.com/〉〈2026〉]，超過就會被截斷。這工具適合剛起步、頁面還不多的小站，或是你想快速生一份應急用的 Sitemap。
Screaming Frog SEO Spider 功能強得多，能設定包含哪些頁面、排除哪些頁面、調整優先順序，對結構複雜的站特別實用。免費版同樣有約 500 個頁面的爬取上限 [來源：Screaming Frog〈SEO Spider〉〈https://www.screamingfrog.co.uk/seo-spider/〉〈2026〉]，更大型的網站要付費升級。若需要把爬下來的資料串進 API 做批次分析，DataForSEO 這類 SEO API 服務 會是順手的搭配。操作上是先輸入網址讓軟體爬完整站，再從上方工具列的 Sitemap → XML Sitemap 匯出檔案。要學完整套爬蟲分析，可對照 SEO 工具完整評比 與 站長必備 SEO 工具。
下載到 sitemap.xml 之後，要把它用 FTP 軟體上傳到網站根目錄（通常是 public_html），路徑會是 /sitemap.xml。FTP 操作可參考 WordPress FTP 檔案上傳。這類手動方式最大的缺點是：網站內容一更新，就要重新產生、重新上傳，沒有外掛那種自動同步的省事感。所以超過 500 頁的大型網站，與其一直手動，不如直接改用付費方案或委請技術 SEO 處理，避免 Sitemap 不完整反而誤導收錄判斷。
如果你的網站是純靜態站或用 GitHub Pages、Netlify、Vercel 這類平台託管，還有第三種常見做法：在建置流程裡直接生成 Sitemap。多數靜態網站產生器（例如 Hugo、Eleventy、Astro、Next.js 的靜態匯出）都內建或透過外掛產生 sitemap.xml 的功能，只要在設定檔指定網域與輸出路徑，每次重新建置就會自動更新。這條路比手動工具更可維護，又能保持自動同步的優點，適合有基本工程能力的團隊。重點在於選擇能配合你的部署節奏的方案，確保 Sitemap 永遠反映網站的最新狀態。
提交給 Google：透過 Search Console 把 Sitemap 送出去
產生 Sitemap 後，正式提交的管道是 Google Search Console。先完成網站驗證，再到「Sitemap」頁面貼上路徑並提交，Google 就會開始處理。狀態不一定馬上顯示成功，但已經進入處理流程，不用急著重複點提交。還沒接觸過這個後台的人，建議先看 Google Search Console 的基本介紹 建立整體概念，GSC 完整的操作邏輯可再看 Google Search Console 完整教學。
前置作業是開通並驗證 Search Console 的網站所有權，這段開通與驗證流程可對照 Google Search Console 的安裝設定教學。驗證方式有網域驗證與網址前置字元驗證兩種，Google 建議優先用網域驗證，因為它涵蓋所有子網域與 http/https 版本 [來源：Google Search Console Help〈Verify your site ownership〉〈https://support.google.com/webmasters/answer/9008080〉〈2026〉]。如果你在 WordPress 上串接 GSC 覺得麻煩，可以靠 Site Kit 串接 GSC 與 GA4 一步到位。驗證完成後，把主網域與 網域申請與 DNS 設定、SSL 憑證安裝與 SEO、HTTP 換 HTTPS 攻略 一起檢查過一次，確定基礎環境沒問題。
驗證完成後，提交的步驟如下：
- 左側選單點「Sitemap」。
- 在輸入框貼上 sitemap.xml 的路徑（例如 sitemap_index.xml）。
- 按「提交」，系統會回覆已提交的訊息。
- 看「狀態」欄：成功會顯示已發現的網址數量；若顯示「無法讀取」，要回頭檢查路徑或檔案權限。
登錄狀態不會即時更新，可能要幾小時到幾天才會反映處理結果 [來源：Google Search Console Help〈Manage sitemaps〉〈https://support.google.com/webmasters/answer/7451001〉〈2026〉]。如果你想看 GSC 裡的其他進階用法，像是索引覆蓋報告、效能報告的解讀，可參考 Search Console 實戰技巧，其中 調整報表日期區間的技巧 在對比改版前後效果時特別好用。新手常問的 GA4 數據問題，則可以對照 GA4 工作階段數據解讀 與 WordPress 安裝 Google Analytics。
除了 GSC，還有一個低調但有效的做法：在 robots.txt 加入一行 Sitemap: https://你的網域/sitemap.xml，讓所有搜尋引擎爬到 robots.txt 時一併讀取你的 Sitemap 路徑 [來源：sitemaps.org〈Sitemaps XML format〉〈https://www.sitemaps.org/protocol.html〉〈2026〉]。這對 Bing、Yahoo 等非 Google 引擎特別有用，可以直接在 Bing Webmaster Tools 裡提交；還沒註冊過的話，先照著 Bing Webmaster Tools 的安裝步驟 把帳號開起來再說。robots.txt 的指令細節，可與 SERP 搜尋結果頁機制、Google 搜尋演算法解析 一起理解，會更清楚搜尋引擎到底怎麼讀你的網站。
Search Console 狀態欄判讀：成功、警告、無法讀取的處理方向
送出 Sitemap 之後，狀態欄的訊息是判斷有没有送對的唯一線索，但多數人只看得到「成功」就放心，遇到其他訊息就慌了。其實 GSC 回報的狀態分幾種，各自對應不同的問題與處理方式，把它們對照清楚，排查問題才不會像無頭蒼蠅。
| 狀態訊息 | 代表意義 | 處理方向 |
|---|---|---|
| 成功 | Sitemap 已被讀取，網址已被納入發現流程 | 無需動作，定期回來看數量是否合理 |
| 有警告 | 檔案讀到了，但部分網址有問題（例如被 noindex、重複） | 展開報告，逐筆檢查被標記的網址 |
| 無法讀取 | Google 抓不到檔案，通常是路徑、權限或 http 狀態問題 | 確認檔案路徑、伺服器回傳 200、無 robots.txt 封鎖 |
| 無法擷取 | 檔案可抓但內容格式有誤（XML 結構錯、編碼問題） | 用 Sitemap 驗證工具檢查 XML 是否合法 |
| 已提交的網址不在 Sitemap 中 | 你之前送過的網址，這份 Sitemap 沒列入 | 核對是否漏了分類，或重新產生檔案 |
最常見的「無法讀取」，原因多半出在三個地方。第一是路徑根本不對，例如你以為 Sitemap 在根目錄，其實外掛把它放在子目錄，或網址打成了 sitemap.xml，實際檔名是 sitemap_index.xml；這時直接在瀏覽器打開你提交的那條網址，看能不能看到 XML 內容，看不到就是路徑錯。第二是伺服器回傳的不是 200，可能是權限被擋、防火牆封鎖了 Google 的爬蟲，或網站整個掛掉；用 GSC 的網址審查工具檢查該檔案的檢索狀態，可以看到 Google 實際收到的回應。第三是 robots.txt 把 Sitemap 檔案或它所在的目錄給封鎖了，這時 Google 即便知道路徑也抓不到內容；確認 robots.txt 沒有 Disallow 指向 Sitemap 路徑即可。遇到「無法擷取」則多半是 XML 結構壞了，例如某個 loc 標籤沒有正常關閉、或檔案包含了不合法的字元，這時用線上的 Sitemap 驗證工具跑一次就能定位問題。
另一個容易誤判的訊息是「已發現的網址」數量。這個數字代表 Google 從這份 Sitemap 讀到的網址總數，並不等於被收錄的數量。很多人看到數字等於自己網站的頁面數就放心，以為全部都被收了，其實這只代表 Google 知道這些網址存在。真正被收錄了多少，要看 GSC 的「網頁索引」報告，那邊才會告訴你有多少頁面被索引、多少被排除以及原因。把這兩個數字分開看，才不會對 Sitemap 的效果產生錯誤期待。
Sitemap 維護的注意事項與常見錯誤
Sitemap 要保持最新、放對頁面、遵守大小限制，並避免把 noindex、重複、參數頁塞進去；大型網站還要做索引分割，否則爬蟲讀不完整、收錄判斷會被誤導。這幾項是新手最容易踩、也最容易白忙一場的地方，整理成一份檢查表方便逐項對照。
- 只放希望被收錄的正式頁面（文章、服務、商品頁），且確認這些頁面是可索引（非 noindex）；對 noindex 標記的作用不熟悉的，可先讀 noindex 指令的運作方式 再來判斷。
- 不要放 noindex 頁、重複或測試頁、排序與篩選參數頁，以及已被 canonical 指向別處的網址；轉址規則也要先理清，避免送出一堆已 被導向他處的舊網址。
- 單一 Sitemap 上限是 50,000 個網址或未壓縮 50MB，超過要用 Sitemap Index 分割成多個檔案 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。
- 位置建議放在網站根目錄，並涵蓋所有要收錄的子目錄，路徑不一致會讓 Google 抓不到；網址怎麼命名才好爬，可參考 SEO 網址結構的設計原則。
- 通常提交一次就夠，Google 會定期回訪；除非改了檔名或路徑才需重提，搭配外掛自動更新最省事。
- 過時或塞滿垃圾頁的 Sitemap 會浪費爬取預算，反而拖慢重要頁面被收錄的速度。
- 搭配 WordPress 永久連結設定 與 404 頁面優化設計 一起檢查，避免網址結構混亂連帶拖垮 Sitemap 品質。
其中分割這件事要再展開講。大型網站例如電商、媒體、論壇，動輒上萬個網址，硬塞進同一份檔案會直接撞上 50MB 上限，Google 也讀得很吃力。正確做法是用 Sitemap Index：一份索引檔列出多張子地圖，每張子地圖再各放不超過 50,000 個網址 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps〉〈2026〉]。多語系網站則可搭配 多語系 hreflang 設定，在 Sitemap 裡標註語言版本；子網域與子目錄的選擇則可對照 子網域 vs 子目錄 SEO。如果你遇到 關鍵字蠶食修復策略 或 網站流量下滑救援方法 這類問題，記得也回頭檢查 Sitemap 是不是塞了互相搶排名的重複頁。
效能層面也別忽略。Sitemap 裡的頁面如果載入太慢、行動體驗差，就算被收錄了排名也難提升。若網站大量依賴前端框架渲染，還要留意 JavaScript 對 SEO 收錄的影響，否則爬蟲可能抓不到實際內容。建議把 網站快取 Cache 設定、WordPress 快取外掛推薦、CDN 網站加速原理、延遲載入提升速度 一起設定好。愛用 AMP 的站則可對照 AMP 加速行動頁面。技術債清乾淨，Sitemap 送出去的頁面才真的有競爭力。
這裡的效能議題還可以再往技術面挖一層。Google 早已全面採用行動優先索引（mobile-first indexing），所有可在行動裝置上運作的網站，現在都以行動版爬蟲為主要抓取來源 [來源：Google Search Central Blog〈Mobile-first indexing is here〉 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。這代表你放進 Sitemap 的網址，行動版的呈現品質直接決定 Google 看到什麼。如果行動版有版面跑掉、內容殘缺、或載入過慢的問題，就算桌面版再完美，Google 索引到的也是那個殘缺的行動版。把 Sitemap 與行動版體驗一起檢查，確保送出去的每一條網址在行動端也能正常開啟，這比只顧桌面版的優化更貼近 Google 現在的收錄邏輯。
Sitemap Index 分割實作：大型網站怎麼把上萬網址拆乾淨
講到分割，很多人只知道要做，卻不知道實際長什麼樣、怎麼拆。Sitemap Index 的運作邏輯其實很直觀：你提交給 Google 的，是一份索引檔，這份索引檔裡面列出的是一張張子地圖的檔案位置，每一張子地圖再去列出各自的網址，真正的網址清單藏在子地圖裡。Google 讀到索引檔後，會逐一抓取每一張子地圖，再從子地圖裡讀出實際要收錄的網址。
把分割的判斷邏輯整理成一個簡單的決策流程，遇到網址數量不確定時可以照著走：
- 先盤點網站希望被收錄的正式網址總數，排除 noindex、重複、參數頁之後得到淨數。
- 如果淨數小於 50,000 且未壓縮檔案小於 50MB，單一檔案即可，不必分割。
- 如果淨數超過 50,000，依內容類型（文章、商品、分類）或時間區間切分，每張子地圖各自不超過 50,000 個網址。
- 建立一份 Sitemap Index，把所有子地圖的完整網址列進去。
- 提交給 GSC 的，是這份索引檔的網址，不是任何一張子地圖。
實務上分類切分有幾個原則。同一類型的網址集中放同一張子地圖，方便日後維護與排查問題，例如商品頁一張、文章一張、分類頁一張。當某一類網址數量本身就超過 50,000，再依時間或 ID 區段往下拆，例如商品頁拆成 product-sitemap-1、product-sitemap-2。切記不要隨機把網址平均分散到各張子地圖，那會讓日後除錯變得異常困難，看到某張子地圖出錯，根本不知道裡面是哪些頁面。
多語系網站的分割還要再考慮一層。每個語言版本的網址建議各自獨立成子地圖，並在 Sitemap 裡透過 xhtml:link 標註 hreflang 對應關係，讓 Google 知道同一份內容在不同語言下的對應網址。這樣做能降低 Google 把不同語言版本誤判為重複內容的風險，也能讓各地區的使用者更容易被導向正確語言的頁面。詳細的 hreflang 寫法，可與 多語系 hreflang 設定 互相對照。
不該把 Sitemap 當主力的情境：避免幫倒忙
Sitemap 雖然是基本功，卻不是所有情況都該優先處理。把資源放錯地方，反而會延誤真正該做的事。這張評分表把幾種典型情境列出來，幫你判斷 Sitemap 在當下該排第幾順位。
| 情境 | Sitemap 優先順位 | 理由 |
|---|---|---|
| 全新網站、剛上線 | 高 | 幾乎無外部連結，靠 Sitemap 加速被發現 |
| 剛大改版、網址結構重組 | 高 | 需引導 Google 認識新結構 |
| 頁面數破萬的電商、媒體 | 高 | 規模大，爬蟲難靠連結挖完整 |
| 內部連結完整的中小型站 | 中 | 爬蟲自己能找到，提了加分有限 |
| 內容品質低、大量薄內容 | 低 | 送再多網址也難被索引，先補內容 |
| 頁面全是重複或參數版本 | 低 | 送出去只會浪費爬取預算 |
從這張表可以看出一個關鍵：當網站的內容或技術地基還沒到位，提早送 Sitemap 等於把問題放大給 Google 看。一份塞滿薄內容頁、重複頁的 Sitemap，會讓 Google 把寶貴的爬取預算花在低價值頁面上，擠壓到真正重要頁面被收錄的機會。這時正確的順序是先整理內容、清掉重複、補強品質，等網站本身夠紮實了，再送出一份乾淨的 Sitemap，效果才會放大。
另一種常被誤判的情境是「為了交差而交 Sitemap」。有些站長聽說要交 Sitemap，就隨手用工具跑一份丟上去，從此再也不維護，幾年後 Sitemap 還在列著早已被刪除或轉址的網址。這份過時的 Sitemap 每次被 Google 讀取，都在告訴 Google 一堆指向 404 或被轉走的網址，等於長期在製造噪音。正確的做法是定期檢查 Sitemap 與實際網站狀態的落差，移除已不存在或已轉址的網址；用 WordPress 外掛的好處就在這裡，自動同步能大幅降低這類過時風險，手動產生的站則要排進定期維護流程。
以一個月流量約 3-8 萬工作階段、頁面數約 1,500-4,000 的中型內容站為例，這類網站常見的狀況是 Sitemap 裡堆了上千條網址，其中約三到四成是分頁、篩選參數或薄內容彙整頁。送出後 GSC 的「已發現的網址」數字很快衝高，但「網頁索引」報告裡被排除的網址比例也同步上升，真正有價值的長篇文章被收錄的速度反而被拖慢，依典型表現幅度約落在延後 1-3 週才陸續進索引。決策上的重點不是要不要送 Sitemap，而是送之前先把這類低價值頁面剔除乾淨：把分頁、排序參數、標籤彙整頁從 Sitemap 排除，只保留可索引的正式文章與服務頁，讓爬取預算集中。要誠實說明的限制是，這個加速效果只有在內容與連結地基本身夠紮實時才成立；如果網站仍是大量薄內容或重複頁面，就算把 Sitemap 清到極簡，被收錄的比例也不會明顯改善，這時回頭補內容的投報率遠高於反覆整理 Sitemap。
robots.txt 與 Sitemap 的協作：把發現路徑鋪滿
前面提到在 robots.txt 加一行 Sitemap 指令，這個動作看似簡單，背後的協作邏輯值得多談。robots.txt 是搜尋引擎爬到任何網站時第一個讀取的檔案，它的主要功用是告訴爬蟲哪些路徑可以爬、哪些不要爬。把 Sitemap 指令放進 robots.txt，等於在爬蟲的必經路口立了一塊招牌，直接告訴它「我的 Sitemap 在這裡」，省去爬蟲自己猜測或靠外部連結輾轉發現的時間。
這個做法對非 Google 的搜尋引擎尤其有價值。Bing、Yahoo、DuckDuckGo、Yandex 等引擎未必像 Google 那樣緊密整合 Search Console，但它們都遵循 sitemaps.org 的共同規範，會讀取 robots.txt 裡的 Sitemap 指令 [來源：sitemaps.org〈https://www.sitemaps.org/protocol.html〉〈2026〉]。換句話說，一行指令就能讓所有遵守規範的搜尋引擎都知道你的 Sitemap 位置，覆蓋面遠比只在 GSC 提交來得廣。這也是為什麼會建議 GSC 提交與 robots.txt 指令雙管齊下，兩者並不衝突，而是互補。
在 robots.txt 寫 Sitemap 指令時，有兩個細節要注意。第一，指令必須是完整網址，包含 https 與網域，例如 Sitemap: https://example.com/sitemap_index.xml，不能只寫相對路徑。第二，如果你有多份 Sitemap（例如一張索引檔加上幾張獨立的擴充型 Sitemap），可以重複寫多行 Sitemap 指令，每一行指向一份檔案，robots.txt 允許列出多個 Sitemap 位置。寫好之後，記得到 GSC 或 Bing Webmaster Tools 手動測試一次 robots.txt，確認格式無誤且沒有不小心封鎖到 Sitemap 本身的路徑。
一個常見的衝突情境：robots.txt 同時存在 Disallow 規則與 Sitemap 指令，而 Disallow 剛好封鎖了 Sitemap 裡列出的某些網址。這時 Google 會遵守 Disallow 不去爬那些網址，即使它們出現在 Sitemap 裡也一樣。結果就是 Sitemap 送了等於沒送，那些網址依然不會被收錄。遇到這種情況，要回頭釐清到底該不該收錄那些網址：如果該收，就放寬 Disallow；如果不該收，就把它們從 Sitemap 移除。讓 robots.txt 與 Sitemap 的訊號保持一致，是避免自己跟自己打架的基本功，相關概念可與 Google 搜尋演算法解析、SERP 搜尋結果頁機制 一起建立。
常見問題：Sitemap 提交後沒排名、該放哪些頁面、多久更新
這一節把站長最常問的問題一次收攏：Sitemap 不會直接抬升排名、只需提交一次、大型網站要做分割、只放正式可索引頁面。每題都給一個明確答案，遇到猶豫時可以直接對照。
提交 Sitemap 後排名沒提升是正常的嗎？
正常。Sitemap 只負責讓 Google 更快找到你的頁面，跟排名沒有因果關係。想衝排名，把心力放在 提升 Google 排名關鍵 與 SEO 搜尋引擎優化從零開始，會比反覆提交 Sitemap 有效得多。
Sitemap 要多久更新一次？需要重複提交嗎？
交一次就夠，Google 會定期回訪自動抓取更新。除非改了檔名或路徑，否則不用重複送。用 Rank Math、Yoast 這類外掛的好處是，新增或刪除頁面時 Sitemap 會自動同步，完全不必手動維護。手動產生的 Sitemap 才需要在網站大改版後重新產生與上傳。
一個 Sitemap 最多可以放多少網址？
上限是 50,000 個網址，或未壓縮檔案 50MB，兩個條件先碰到哪個就停 [來源：Google Search Central〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉〈2026〉]。超過要用 Sitemap Index 把地圖分割成多份，每份再各自不超過這個上限。
Sitemap 送了但 GSC 顯示「已發現，目前尚未建立索引」怎麼辦？
這代表 Google 已經知道這個網址，只是基於內容品質、重複內容或爬取優先順序暫時沒收進索引。重新提交 Sitemap 通常無解，要回頭檢查內容是否有實質價值、是否與其他頁面重複、是否被 canonical 或 noindex 指向別處。把這些因素逐一排除，索引狀態才有機會改善。
Sitemap 裡可以放 noindex 的頁面嗎？
不建議。雖然技術上可以列出，但把 noindex 頁放進 Sitemap 等於給 Google 互相矛盾的訊號：一份清單說「請收錄我」，一個標記又說「不要收錄我」。這種矛盾會造成混淆，也可能稀釋 Sitemap 整體的可信度。Sitemap 只列你真正希望被收錄、且確定可索引的頁面，其他一律排除。
回顧整篇的核心：Sitemap 是一份遞給搜尋引擎的收錄清單，價值在加快被發現與索引，不是抬升排名的開關。把它當成技術 SEO 的基本功，跟內部連結、網址結構、GSC 驗證一起做，才會真的發揮作用。選外掛、選工具，還是決定要不要分割，都建立在這個前提之上。想再往整體 SEO 推進一步，可以接著讀 AI 時代的 SEO 全攻略、Google AI Overviews 對 SEO 的影響 與 GEO 生成式搜尋優化；若考慮外包，則可參考 SEO 公司推薦與挑選 與 SEO 服務費用行情。