Sitemap 產生提交教學：3 步驟讓 Google 快速收錄

想像一下，你花了三個月寫了八十幾篇深度文章，每一篇都反覆打磨過標題、內文與內部連結，自認為內容品質在同主題裡排得上前段班。你滿懷期待地打開 Google Search Console（簡稱 GSC），等著看流量慢慢爬上來。結果發現：八十幾頁裡，Google 只收錄了三十幾頁，剩下那五十頁，就像從來沒被生下來一樣。

這個情況在實務上並不少見。Google 可能尚未發現網址，也可能已發現但尚未抓取或索引；原因還可能涉及內部連結、內容品質、重複網址或技術設定。sitemap.xml（網站地圖）是一份主動提供給搜尋引擎的網址清單，可附上可信的最後修改時間，協助搜尋引擎發現網站希望被檢索的頁面。

接下來會依序說明產生、提交、驗證三個步驟，並處理常見的收錄障礙。如果還不確定 sitemap 在 SEO 裡的位置，可以先看XML Sitemap 的概念說明與給新手的入門指南，再進入實作。

Sitemap 真正幫你解決的是什麼問題

很多人把 sitemap 想成「通知 Google 來收錄」的開關，好像送出之後排名就會往上衝。這個理解只對了一半。sitemap 本身不影響排名，它影響的是檢索（crawl）與索引（index）的效率。

Googlebot 的時間與資源有限，它不會無止境地在你網站上亂逛。當你的網站架構清楚、內部連結完整時，Google 靠著爬行就能發現大部分頁面。但現實是，很多網站的內部連結結構並不完美：新發布的文章埋在分類頁的第三頁、某些頁面只透過搜尋結果或篩選器才連得到、JavaScript 渲染的內容 Google 一時半刻讀不出來。這時候 sitemap 就是那條「不管你內部連結怎麼亂，都會明確告訴你有這些網址」的保險繩。

Backlinko 在 2025 年 4 月分析了 1,180 萬個 Google 搜尋結果，發現能進入排名的頁面絕大多數都是「被確實索引、而且結構與語意訊號清楚」的頁面。換句話說，連索引都進不去的頁面，連上桌比賽的資格都沒有。sitemap 解的就是這一關：先讓你的每一頁有機會被看見。

Google 官方在 Search Central 的 sitemap 文件裡講得很白：sitemap 主要價值在於協助搜尋引擎更有效率地發現與理解你的網站結構，特別是那些內部連結不容易觸及的頁面。

把 sitemap 放回整個搜尋流程裡看，它的位置在「檢索」這一關。搜尋引擎要讓一個頁面出現在結果裡，會經過幾個階段：先發現網址、接著檢索內容、然後分析判斷值不值得索引、最後才是排名與呈現。sitemap 作用在最前頭的「發現」與「引導檢索」階段。它不會替你決定排名，但它決定了你的頁面「有沒有機會被放進評估的池子裡」。這樣看來，可以把它定位成基礎建設，它屬於打底的工作，跟衝刺排名的戰術是兩個層次的事。

對電商網站來說，這個觀念尤其關鍵。一個 WooCommerce 商店可能有幾百上千個產品頁，每一頁都對應到一個潛在的長尾搜尋。如果 sitemap 沒做好，導致一半的產品頁根本沒被索引，那就等於你庫房裡有一半的商品永遠擺不到架上。電商站的 sitemap 處理還有一個特殊難點：篩選器與 faceted navigation 會產生海量參數網址，這些網址內容高度重疊，全部塞進 sitemap 只會拖累整體評估。關於產品頁本身的優化，可以參考WooCommerce 產品頁的 SEO。

一句話總結：sitemap 不是排名魔法，是「收錄效率的基礎建設」。沒做好，後面再多內容與連結優化都是漏水的桶子。

你的網站真的需要 sitemap 嗎：四種情境

在動手之前，先問一個誠實的問題：你的站到底需不需要這份名單？Google 官方的態度其實很務實：sitemap 對某些網站是「必要」，對另一些網站只是「錦上添花」。弄清楚自己落在哪一邊，你才知道該投入多少力氣。

實務上會遇到的情況大致可分成四種：

網站類型	sitemap 的重要性	原因
大型網站（數百頁以上）	必要	內部連結結構再好，也難保證每個深層頁面都能被爬到
全新網站、外部連結稀少	必要	沒有別人連向你，Google 不一定會主動發現你
頁面之間連結薄弱（如孤兒頁）	必要	有些頁面只透過站內搜尋或表單才連得到，爬蟲走不到
小網站、結構清楚、內部連結完整	建議做，但非生死交關	Google 靠爬行就能發現大部分頁面，sitemap 是加分

實務上的建議是：只要你的網站打算長期經營，就做一份。理由很單純，sitemap 的維護成本接近零（尤其是用外掛自動產生的情況），但它換來的是「Google 對你網站結構的一份明確認知」。這就像幫你的房子裝門牌，你不裝，郵差遲早也能找到你；但裝了，效率就是不一樣。

有一個常見的迷思要順手戳破：sitemap 講究的是「一份就好、而且結構清楚」。同一個網站，你只需要一份（或一組有層次的）sitemap，散落好幾份內容重複、版本混亂的清單只會製造麻煩。版本一旦失控，Google 拿到的訊號會互相打架，排查起來反而更累。

三步驟總覽：產生、提交、驗證

把整個流程拆成三個動作，後面的章節會逐一展開：

1. 產生 sitemap.xml：依你的網站類型（WordPress、靜態站、電商、大型站），選對產生方式，產出一份「乾淨」的網址清單。
2. 提交給搜尋引擎：透過 GSC 與 Bing Webmaster Tools 正式聲明，並在 robots.txt 放一行保險。
3. 驗證與監控：用 GSC 的 Sitemap 報表與網址檢查工具，確認提交的網址真的進到索引，而不是石沉大海。

三步缺一不可。很多人停在第二步就以為做完了，但其實「提交成功」不等於「收錄成功」，這是新手最容易踩的認知誤區。第三步才是分出高下的地方。

第一步｜產生 sitemap.xml：依網站類型選對方法

產生 sitemap 的方式沒有標準答案，取決於你的網站是怎麼架的。先把幾種主流情境列出來，你對號入座。

情境一：WordPress 站，用外掛自動產生

根據 W3Techs 的統計（2026 年 6 月），WordPress 在所有使用內容管理系統的網站裡佔有率超過六成，是目前的絕對主流。如果你是 WordPress 站長，恭喜，sitemap 幾乎不用自己生，主流 SEO 外掛都會幫你做好。

以 Rank Math 為例，它的 Sitemap 模組在啟用後會自動為你的文章、頁面、自訂文章類型與分類標籤產生對應的 sitemap，而且支援多層 sitemap index，網址數量一多會自動分檔。你可以在 Rank Math 的設定裡勾選要納入哪些文章類型、排除哪些分類，這個細節後面講「乾淨 sitemap」時還會再提到。如果你想更全面比較各外掛的差異，可以參考WordPress SEO 外掛的完整比較與Rank Math 的設定教學。

老實說，WordPress 站真正要小心的不是「有沒有 sitemap」，而是外掛預設把什麼東西都丟進去。這個問題在後面那節會專門講。在設定 Rank Math 或同類外掛時，有幾個欄位值得你親手確認：文章類型只勾「文章」與「頁面」這類有獨立內容的、分類法排除掉使用量極低的標籤、圖片與影片 sitemap 模組在需要時才開。很多人裝完外掛就放著不管，結果 sitemap 裡塞滿了沒有任何文章的空分類頁，這些都是稀釋訊號的噪音。WordPress 的永久連結結構也會直接影響 sitemap 裡的網址長相，建議在產生 sitemap 之前先確定永久連結的 SEO 設定是你要的結構，免得日後大改網址又要重來一遍。

情境二：靜態站、Headless 或手寫網站，自己生成

如果你用的是 Astro、Next.js、Eleventy、Hugo 這類靜態站產生器，sitemap 通常是一個 build-time 的外掛或函式。以 Astro 為例，官方的 @astrojs/sitemap 整合會在你每次 build 時自動產生 sitemap index 與子檔，把 site 設定裡的所有路由都納進來。Headless 架構（前端與後端分離）更要特別注意：你的前端路由跟後端 API 的網址是兩回事，sitemap 裡放的應該是「會被使用者看到的最終網址」，不是 API endpoint。

如果你是完全手寫的網站、或頁面數量很少（例如十幾頁的形象官網），你也可以直接手動寫一份 sitemap.xml。格式其實不複雜，sitemaps.org 的協定就是規範這件事的官方標準。一個最小的範例長這樣：

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-07-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/contact</loc>
    <lastmod>2026-06-20</lastmod>
  </url>
</urlset>

每個 <url> 區塊裡，<loc> 是必填的網址，<lastmod> 是最後更新時間。其他還有 <changefreq> 與 <priority> 兩個欄位，它們到底有沒有用，後面會專門戳破這個迷思。

情境三：用線上產生器或爬蟲工具掃一份出來

有些情境你沒辦法從系統端直接產生 sitemap，例如接手一個別人架的舊站、或不確定到底有多少頁面被發布出去。這時候線上產生器與爬蟲工具就是最快的盤點方式。

xml-sitemaps.com 是最常被用的免費線上產生器，貼上網址就能掃出一份 sitemap，缺點是免費版有頁數上限，五百頁以上的站要付費。實務上更推薦用 Screaming Frog SEO Spider 這類專業爬蟲工具，它模擬 Googlebot 的爬行邏輯，能同時幫你發現斷鏈、重複頁面、標題缺失等技術性問題，等於一次做完網站健檢。關於這類工具的整體挑選邏輯，可以搭配SEO 工具完整評比一起看。

網站類型	推薦產生方式	注意事項
WordPress	SEO 外掛自動產生（Rank Math、Yoast 等）	檢查預設納入的文章類型，別把沒意義的頁面也丟進去
靜態站（Astro、Hugo 等）	build-time 外掛自動產生	確認 site 網域設定正確，避免產出 localhost 網址
電商（WooCommerce、Shopify）	平台內建或外掛，產品頁獨立分檔	商品下架要即時移除，避免提交一堆 404
大型內容站	程式化產生 + sitemap index 分檔	遵守每檔 50,000 網址與 50MB 上限
手寫形象官網	手動撰寫 sitemap.xml	新增頁面後記得更新，別讓 sitemap 跟實際網站脫節

第二步｜提交給 Google Search Console 與 Bing

sitemap 產生好之後，接下來就是把它正式交到搜尋引擎手裡。有兩個主流管道：官方的站長工具，以及 robots.txt 裡的聲明。建議兩個都做，互為保險。

用 Google Search Console 提交

提交 sitemap 的前提是你已經在 GSC 完成網站的所有權驗證。如果你還沒做這一步，先回頭把GSC 的安裝與驗證跑完；完整的操作脈絡可以看GSC 完整教學。Google 官方對驗證流程有詳細說明，支援 HTML 標籤、HTML 檔案、Google Analytics、Google Tag Manager、DNS 紀錄等多種方式（見 Verify your site ownership，2026）。

驗證完成後，提交的動作非常簡單：在 GSC 左側選單點「Sitemaps」，在輸入框填入你 sitemap 的路徑（例如 sitemap_index.xml），按下提交。Google 會開始處理，狀態欄位會顯示「成功」或「無法讀取」（細節見 Search Console 的 sitemap 管理說明）。這裡要提醒一個細節：輸入框裡只要填「路徑」，不要重複貼整個網址的網域部分，GSC 會自動幫你接上。

在 robots.txt 聲明 sitemap 位置

除了透過 GSC 主動提交，你也可以在網站根目錄的 robots.txt 裡加一行 Sitemap: 聲明。這個做法的好處是，任何遵守標準的搜尋引擎爬蟲（不只 Google）來抓你的 robots.txt 時，都會順便讀到 sitemap 的位置。

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap_index.xml

這是一個被動但零成本的保險。robots.txt 跟 noindex 的關係常常被搞混，如果你對這塊還有疑問，可以參考robots.txt 的完整介紹。要特別注意一個地雷：robots.txt 可以「封鎖檢索」，但它不能「移除索引」，這兩件事混在一起會出大事，相關細節在noindex 的觀念解析裡有專門說明。

順手提交給 Bing（與 Yahoo）

Yahoo 與 Microsoft 的搜尋技術合作範圍可能隨市場與時間調整，不宜把所有 Yahoo 搜尋結果一律視為 Bing。若目前台灣 Yahoo 的官方產品說明確認由 Bing 提供技術，再把 sitemap 提交到 Bing Webmaster Tools，並持續檢查索引與抓取狀態。

順帶提一個容易被錯過的細節：主動透過站長工具提交的 sitemap，跟被動放在 robots.txt 等爬蟲自己讀的 sitemap，兩者在「被處理的速度」上有差異。主動提交等於你按了門鈴，搜尋引擎會在較短的時間內排程來處理；被動聲明則要等爬蟲下次造訪你的 robots.txt 時才會讀到。對新發布的網站或剛上線的新內容，主動提交能爭取到更快的首次檢索。不過兩者最終的收錄結果不會有本質差別，差別主要在「起步的速度」。

第三步｜驗證收錄：提交之後才是工作的開始

很多人以為按下「提交」那一刻工作就結束了。錯。提交成功只代表「Google 收到你的 sitemap」，不代表「Google 已經把裡面的網址都收錄了」。中間還有一段距離，而這段距離正是你要監控的地方。

看懂 GSC 的 Sitemap 報表

回到 GSC 的「Sitemaps」頁面，點進你提交的那份 sitemap，會看到「已發現的網址」這個數字。這個數字代表 Google 從這份 sitemap 裡讀到了多少個網址。如果這個數字跟你實際的頁面數差很多，那代表你的 sitemap 內容有問題，可能是格式錯誤、或某些網址被 Google 判定為無效。

但要特別注意，「已發現」不等於「已索引」。想看實際有多少頁面真的進到索引，要到「網頁索引」報表（Pages）去看，那裡會列出「已索引」、「未索引」以及未索引的原因（可對照 Google 的 sitemap 總覽文件）。關於索引報表的判讀，可以搭配Google 收錄查詢的完整教學一起看。

用網址檢查工具逐頁確認

如果你想確認某個特定網址到底有沒有被收錄，GSC 的「網址檢查工具」（URL Inspection）是最精準的方式。把完整網址貼進上方的搜尋框，GSC 會告訴你這個網址目前的狀態：是「已建立索引」、還是「未建立索引」、或是「重複網址，Google 已選擇其他網址作為標準」。如果是未索引，還會附上原因，讓你知道下一步該修什麼。詳細操作可以參考網址檢查工具的使用教學。

這裡順帶補一個觀念：如果你的頁面有重複內容問題（例如同一篇文章有 http 與 https 兩個版本、或是有列印用的參數網址），Google 會自己選一個「標準網址」來索引。sitemap 裡放的應該是你「希望被索引的那個標準網址」，這跟 canonical 設定是一體兩面的事，相關細節在Canonical URL 的完整指南裡有深入說明。

收錄率怎麼算、多少才算正常

一個實務上會追蹤的指標是「收錄率」：已索引頁面數 ÷ sitemap 裡宣告的網址數。健康的大型內容站，這個比例通常落在七八成以上。如果低於六成，那就要回頭檢查到底是哪些網址沒被收錄、原因是什麼。常見的原因不外乎品質被判斷為薄弱、被 canonical 合併、被 noindex 擋掉、或是根本回傳 404。

收錄率長期追蹤下去，還能發現一個很有價值的訊號：哪些類型的頁面 Google 特別「不愛收」。例如你發現標籤彙整頁的收錄率特別低，那可能就是 Google 認為這些頁面的內容太薄、或跟其他頁面重疊太高，這時候與其硬塞進 sitemap，不如考慮用 noindex 或內部連結策略來處理。這類判斷需要把幾個報表對著看，想更熟練操作 GSC 的各種報表，可以參考GSC 的五個實戰技巧。

關於監控的頻率，務實的建議是：新站或剛改版的網站，前兩個月每週看一次 Sitemap 與網頁索引報表，因為這段時間收錄狀況變動最快，問題也最容易浮現；網站穩定之後，每個月搭配例行 SEO 健檢看一次就夠了。不需要每天盯著報表焦慮，但也不能交差了事就再也不回頭。SEO 裡很多災難都是「設定一次就忘了」造成的，sitemap 也是其中之一。

還有一個進階的監控角度：把 sitemap 裡的網址數量、跟你的內容管理系統裡實際發布的頁面數量定期對帳。這兩個數字應該大致吻合。如果 sitemap 裡的網址數明顯多於你實際發布的內容，那八成是外掛把不該納入的頁面（分頁、參數網址、自動產生的彙整）也丟了進去；反過來說，如果 sitemap 裡的網址數少於你實際發布的，那可能是某些頁面被設定排除、或是 sitemap 沒有在內容更新後重新產生。這個「對帳」的習慣，是判斷 sitemap 是否健康的快速體檢。

一份「乾淨」的 sitemap 才有用：哪些網址該剔除

這一節是最關鍵、卻最多人忽略的重點。

以一個健康資訊站為例，sitemap 裡常見堆了上千條網址，一打開才發現大半是分頁、篩選參數與標籤彙整頁。真正有價值的原創文章反而被淹在一堆低品質網址裡，Google 每次來抓都要在這些噪音裡翻找，等於變相浪費了你的爬取預算。

sitemap 不是「放越多越好」。你丟給 Google 的每一個網址，都代表一次「請你來評估這個頁面」的請求。當這些請求裡夾雜大量低品質、重複、或根本沒有獨立價值的網址時，Google 會對你整個網站的「網址品質」打上一個問號。更實際的影響是，有限的爬取資源被分散到沒用的頁面上，真正重要的新文章反而排隊排更久。爬取預算的概念在爬取預算優化指南裡有完整說明，強烈建議搭配閱讀。

下面這張表，是實務上幫網站健檢時常用來逐項檢查「該不該放進 sitemap」的判斷清單：

網址類型	要不要放進 sitemap	理由
原創內容文章、產品頁	放	這些是你想被排名的主力頁面
分類與標籤彙整頁	視情況	若有獨立價值且不重疊可放，否則剔除
分頁（page/2、page/3）	不放	內容與第一頁重複度高，稀釋價值
篩選器參數網址（?sort=price 等）	不放	同一內容的變體，會造成重複內容
站內搜尋結果頁	不放	低品質、無獨立價值，易被視為內容農場化
noindex 頁面	不放	你都宣告不索引了，放進 sitemap 是自相矛盾
404 與轉址鏈頁面	不放	提交一個回傳錯誤的網址，只會拖累評估
臨時活動、已下架商品	動態管理	到期就移除，別長期留著

判斷的核心原則只有一句：放進 sitemap 的，都應該是你「願意拿排名去拼」的頁面。任何只是「存在但不值得被單獨評估」的網址，都不該出現在這份名單裡。

lastmod、priority、changefreq 的真相

很多教學文章會教你把 <priority> 設成 1.0、把 <changefreq> 設成 daily，好像設定越積極，Google 就越勤勞地來抓。老實說：這些欄位的實際影響，遠比你想像的小。

Google 自己多次說明過，priority 與 changefreq 這兩個欄位在很大程度上會被忽略，因為它們太容易被站長自己「灌水」，參考價值低。真正有實際作用的是 <lastmod>，它代表這個網址最後被更新的時間，而且 Google 會拿它來判斷要不要重新檢索這個頁面；sitemaps.org 的協定本身就明白標示 priority 與 changefreq 是「建議」性質，不保證被採用。

所以實務上的建議是：

• lastmod 一定要給，而且要給得準確。每次內容真的更新了才更新時間，不要為了「看起來很新鮮」而天天改。
• priority 與 changefreq 可以給，但別花時間在裡面微調。它們頂多是給其他比較會參考這些欄位的搜尋引擎看的。
• 把力氣放在「讓被更新的頁面真的有實質內容變化」上頭，這樣 lastmod 才有意義。空有更新時間戳、內容卻沒變的頁面，遲早會被看破手腳。

這個觀念跟整個白帽 SEO 的核心一致：讓訊號本身就反映真實，勝過任何刻意的操作。Google 在 Mobile-first indexing（2023 年 10 月全面到位）之後，對「內容是否真的與時俱進」的判斷只會越來越細。

大型網站怎麼拆 sitemap：sitemap index 與上限

當你的網站成長到一定程度，一份 sitemap 裝不下所有的網址。sitemaps.org 的協定有兩個硬上限：單一 sitemap 檔案最多 50,000 個網址、未壓縮前最大 50MB。超過這兩個限制，就必須拆成多份 sitemap，再用一份「sitemap index」把它們包起來。

sitemap index 的結構長這樣：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
    <lastmod>2026-07-10</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-07-09</lastmod>
  </sitemap>
</sitemapindex>

提交到 GSC 時，你只要提交那一份 sitemap index 就好，Google 會自己往下讀裡面的每一份子檔。

拆檔的時候，建議按頁面類型或主題分檔，別只按數量切。例如把文章一檔、產品頁一檔、分類彙整一檔。這樣的好處是，當你在 GSC 報表裡發現某一份子檔的收錄率特別低時，可以立刻定位是哪一類頁面出了問題。這對大型電商站尤其重要，因為產品頁的收錄狀況跟部落格文章通常天差地遠。Google 針對大型網站的 sitemap 管理有專門的文件，建議網址數量大的人都讀一遍。

如果你的網站規模真的很大（例如幾十萬、上百萬網址），還可以考慮把 sitemap 壓縮成 .gz 格式，能省下不少傳輸量。這在協定裡是允許的。

sitemap 不只是網址清單：圖片、影片、新聞延伸格式

很多人以為 sitemap 只是一串 <loc> 網址，到此為止。其實 sitemaps.org 的協定支援「延伸格式」（extensions），讓你可以在同一個網址底下，附帶回報這個頁面裡有哪些圖片、影片、或新聞內容。這幾個格式在多數教學裡被輕描淡寫帶過，但對特定類型的網站，它們是真正的收錄加速器。

圖片 sitemap（image sitemap）

圖片 sitemap 讓你在 <url> 裡用 <image:image> 標記，回報這個頁面包含的圖片網址、標題、授權資訊等。它的價值在於：有些圖片是透過 JavaScript 動態載入、或藏在 CSS 背景裡，Google 的圖片爬蟲不一定抓得到。把它們寫進 sitemap，等於主動遞上一份「這裡有這些圖」的名單。對攝影師作品集、電商產品圖、設計靈感庫這類圖片本身就是內容主角的網站，這個格式特別值得做。圖片曝光的細節，可以再搭配圖片 SEO 優化一起規劃。

影片 sitemap（video sitemap）

影片 sitemap 讓你回報影片的長度、縮圖網址、發布日期、甚至家庭友善標記。對於把影片嵌入頁面、卻沒有把影片放在獨立可被爬蟲讀取位置的網站（例如影片存在第三方平台、頁面只是個播放器殼），影片 sitemap 是讓 Google 知道「這個頁面有一支值得索引的影片」的最直接方式。一個實務提醒：縮圖網址一定要給、而且要是可公開存取的圖片網址，否則這筆紀錄等於白寫。

新聞 sitemap（news sitemap）

新聞 sitemap 是專門給 Google News 發布者用的格式，它的特性跟一般 sitemap 很不一樣：它只包含「最近兩天」發布的文章，而且要持續更新。對有申請通過 Google News 審核的媒體站來說，這是新文章能快速進入新聞索引的關鍵管道。如果你不是新聞發布者，這個格式對你沒用，別誤以為「裝了就有加分」。

延伸格式	適合誰	關鍵欄位
圖片 sitemap	圖片為主角的網站（攝影、設計、電商）	圖片網址、標題、授權
影片 sitemap	有嵌入式影片內容的頁面	影片位置、長度、縮圖網址
新聞 sitemap	通過 Google News 審核的媒體	發布時間、標題、近兩天內容

這些延伸格式不是每個網站都需要，但當你的內容型態剛好命中，它們往往就是「為什麼別人的圖片或影片老是比你早被收錄」的答案。多數 SEO 外掛會在啟用對應模組時自動幫你加上這些標記，所以你通常不用手寫，只要確認模組有開。

網站改版或換網址時，sitemap 要怎麼銜接

有一個情境特別值得拉出來講，因為它最容易被忽略、卻最容易釀成流量崩跌：網站改版或大量更改網址的時候。這時候 sitemap 的時機（timing）比你想像的重要。

當網站全面更換網址結構，例如從查詢參數式網址改為路徑式網址，或由 HTTP 遷移至 HTTPS，應先確認新網址可正常開啟，再設定舊網址到對應新網址的 301 轉址，更新內部連結與 canonical，最後提交只包含新網址的 sitemap。提交順序本身不是保證收錄的開關；真正重要的是新網址可存取、轉址一對一正確，且 sitemap、內鏈與 canonical 使用一致的網址。

另一個實務提醒是：改版後的過渡期，暫時保留舊 sitemap 不要急著刪。舊的 sitemap 可以幫助 Google 理解「這些舊網址已經轉向新網址」的對應，加快權重轉移的速度。等 GSC 的報表顯示新網址的索引狀況穩定下來（通常需要幾週），再把舊 sitemap 移除就好。如果你對轉址與網址變更的細節還不熟，建議先讀過SEO 網址優化與 301 轉址，把基礎觀念弄清楚再動手。

這個銜接做得好不好，直接決定改版後你的自然流量是「平順過渡」還是「先掉一半再慢慢爬回來」。許多改版悲劇的根因都不是內容變差，而是 sitemap 與轉址的時序沒對齊。

提交後沒被收錄的八個常見原因

把上面三步驟都做完，卻還是有一堆頁面沒被收錄？別急著怪 sitemap 沒用。多數時候，瓶頸出在 sitemap 之外的環節：頁面本身的設定、伺服器回應、或內容品質的判斷。下面是實務上最常見的八個兇手，逐一排查通常就能找到答案。排查時請記得一個原則：先排除「技術性阻擋」（noindex、robots.txt、404、canonical），再檢視「品質性判斷」（內容薄弱、重複），順序對了，效率才會高。

1. 頁面被 noindex 標記：你一邊在 sitemap 說「請收錄這個頁面」，一邊在頁面 head 裡寫 noindex，Google 當然聽頁面的指令。
2. robots.txt 封鎖：robots.txt 擋掉了檢索，Google 連內容都讀不到，自然無法評估與索引。
3. 被 canonical 合併：頁面指向了另一個標準網址，被合併進去，不會單獨出現在索引裡。
4. 回傳 404 或 5xx：提交了一個打不開的網址，Google 只能判定為無效。
5. 內容被判斷為薄弱或重複：頁面內容太少、或跟站內其他頁面高度重疊，Google 認為不值得單獨收錄。
6. JavaScript 渲染問題：關鍵內容靠 JS 動態產生，Google 一時讀不到。這在現代前端框架特別常見，可以參考JavaScript SEO的專門討論。
7. 新站、權重低、等待期：全新網站的爬取頻率本來就低，有時需要的只是耐心，持續產出與累積連結。
8. sitemap 與實際網站脫節：sitemaps 是某次 build 產出的快照，之後新增的頁面根本沒被更新進去。這在靜態站最常見。

排查的時候，把 GSC 的「網頁索引」報表跟你的 sitemap 對著看，效率最高。報表會直接告訴你每個未索引網址的具體原因，不用瞎猜。如果你發現某個原因反覆出現在很多頁面身上，那通常代表網站有一個系統性的結構問題，要從根源修起，逐頁補救只會沒完沒了。這些技術性問題其實都屬於技術性 SEO的範疇，如果你是系統性地處理一整個網站，建議把技術健檢當成一個獨立工作階段來做。

今天的行動清單

讀完不等於做完。以下是建議你今天就動手跑一遍的具體動作：

1. 確認你有沒有 sitemap：在瀏覽器打開 你的網址/sitemap.xml 或 /sitemap_index.xml，看看到底有沒有東西。很多站長以為自己有，其實從來沒產生過。
2. 檢查內容是不是乾淨：打開你的 sitemap，隨機抽看幾十條網址，看看裡面有沒有分頁、篩選參數、標籤彙整、搜尋結果頁這類該剔除的網址。
3. 確認 GSC 已驗證並提交：如果還沒驗證，先跑完 GSC 安裝；驗證完就把 sitemap 路徑提交進去。
4. 在 robots.txt 加一行 Sitemap 聲明：這是免費的保險，三十秒就能做完。
5. 七到十四天後回來看報表：進 GSC 的 Sitemaps 與網頁索引報表，看「已發現」與「已索引」的數字有沒有落差，落差大的話用上面的八個原因排查。
6. 建立定期更新機制：動態網站讓外掛或系統自動更新 sitemap；靜態站確認每次 build 都重新產生。別讓 sitemap 變成過期的快照。

sitemap 這件事不性感，它不會讓你明天就衝上第一名。但它是一個網站能不能被搜尋引擎「完整看見」的地基。地基沒打好，你後面投入再多內容產製、關鍵字研究、連結經營，都會有一部分是漏水的。把這份名單跑完，你至少可以確定：你寫的每一頁，都有公平的上桌機會。

最後留一個觀念給你：sitemap 解決的是「被看見」的問題，而「被看見」之後能不能排上前，靠的是內容本身的品質、搜尋意圖的契合度、以及長期累積的權威性。這幾件事是接力賽，sitemap 跑的是第一棒。第一棒跑穩了，後面的努力才不會白費。如果你想把接力賽的每一棒都弄清楚，可以從SEO 完整指南與搜尋意圖這兩個主題開始往下扎根。

如果你在跑這份清單的過程中，發現自己的網站技術基礎問題比想像中多，或者你需要有人幫你把整個收錄與索引的鏈條系統性地檢查一遍，Whoops SEO 提供這類技術健檢與顧問服務。地基的事，永遠值得在最一開始就做對。