Sitemap 提交後沒被收錄？分層歸因找出卡點

先看一個示範情境（情境為建構，用來對準問題）：一間做五金零件外銷的 B2B 目錄站，兩千個產品頁上線三個月，自然搜尋帶來的詢問屈指可數。週會上老闆問了一句「Sitemap 不是早就送了嗎」，與會的人翻出後台紀錄，爭論就此打住：開站當月就送出了，狀態欄一路顯示成功。動作沒有做錯，期待卻從第一步就放錯了位置。

把網頁索引報表打開，兩千頁裡有一大批停在「已找到、尚未建立索引」，另一批被併進「重複，Google 已選擇其他標準網址」。一個頁面沒浮上結果頁，可能在三個環節掉出隊伍：它沒進過機器的待辦名單、進了名單卻一直沒被讀、讀完了卻沒被評選進索引。清單只在第一個環節使力，而「送出去就等著被收」這個期待，官方任何文件都沒有給過背書。

接下來先把結論攤開，再沿機器端的流水線逐層拆：哪些站需要這份清單、哪些網址有資格進去、欄位為何被差別待遇、檔案交給誰產生、走哪條管道送、送完怎麼讀差距、修正順序怎麼排。五金站會在沿途各站復現，充當判準的示範組；你可以停在任何一站，對照自己網站的報表往下查。

快速重點：Sitemap 換到的是被看見的機會，外加一個看得到處理狀態的介面；下載檔案、抓取網址、編入索引，官方一件都沒答應。沒被收錄先歸因到發現、讀取、評估三層，清單只對第一層有效；修正時可讀性在前、價值在後，順序錯了會白忙數週。

三種沒被收錄，只有一種跟這份清單有關

頁面要浮上搜尋結果，機器端走的是三站式流水線：先拿到網址（發現），接著下載並讀內容（讀取），然後判斷要不要收進索引（評估）。Sitemap 交出去的東西，本質是一批排進待辦佇列的網址線索，作用點只在第一站。這也是五金站把送出紀錄攤開後得到的答案：狀態成功只說明檔案被讀到，大批網址分別停在「已找到」與「重複」，病灶多在讀取與評估那兩站，把同一份清單重送十次，機器也不會有反應。

預期要在一開始就校準。官方給這份檔案的定位，是幫機器發現頁面、看懂網站結構，而且把話說在前頭：下載檔案、抓取網址、編入索引，三件事都不在保證範圍。把送出當成收錄手續，後面的判斷全會歪掉；先分層，才知道力氣該往技術還是內容撒，兩種誤判都省得下來。

歸因靠的是報表狀態，不必猜。打開 Search Console（介面還不熟的話，先看Search Console 報表的操作教學），把沒被收錄的網址對照下表定位：

↔ 左右捲動檢視完整表格

報表上的症狀	落在哪一站	清單使不上力的原因
網址在網頁索引報表裡完全找不到	發現	唯一使得上力的一站，該補的就是網址線索
停在「已找到、尚未建立索引」	讀取排程或評估	網址已在待辦裡，重送等於再排一次隊
顯示「重複，Google 已選擇其他標準網址」	評估後整併	版本合併的結果，該對齊的是 canonical 與標準網址

被索引是參與排名的先決條件，這點有外部資料可以對照。Backlinko 於 2025 年 4 月更新、涵蓋 1,180 萬筆搜尋結果的排名研究指向同一個前提：能進入排名的頁面，以被收進索引為先決條件。這是相關性的觀察，不是「被索引就會排名」的因果保證；但方向夠清楚，連索引都沒進的頁面，後面的努力都沒有上場機會。名詞還不熟的讀者，可以先讀XML Sitemap 的基礎說明與網站 Sitemap 的入門指南，再回到這條分流。

報表很少只給一種答案。同一個站裡，三種狀態常常並存：商品頁整批停在已找到，文章頁有一群被整併，還有少數網址根本沒出現過。歸因因此要分組做，不是對整站下一個結論；先看面積最大的那一群，因為同一個原因通常掛在一整批網址上，修一個結構問題，掉出隊伍的那一整群才有機會一起回來。五金站的報表就是這種長法，這也是它值得當示範組的原因。

連結健康的站不做清單，為什麼不吃虧？

機器認識網站有兩條路，成本結構不同。預設那條是被動的：沿著別人指向你的連結與你自己的導覽，一頁一頁走，靠的是結構；清單這條是主動的：把全貌一次攤開，直接遞到機器手上。兩條路進的是同一個待辦佇列，清單的優勢不在比較快，而在補上連結走不到的網址，外加一份可以對帳的全貌。官方的原始立場，用自己的話講就是：網頁之間的連結串得夠完整的網站，大多數頁面本來就會被找到，官方總覽文件把這件事當成基本前提，而不是例外狀況。

判斷的軸也常被拿錯。不該問「我有幾頁」，該問「有幾頁是連結走不到的」：一百頁全部掛在選單下兩層，機器走得到，清單可有可無；一萬頁裡有八千頁要點四次篩選才浮現，那八千頁要被看見，清單幾乎是唯一的管道。頁數本身不是訊號，頁數乘上深度才是。把官方提過的適用情境整理成五個是非題，答「是」的次數越多，這件事越值得往前排：

• 規模乘深度：網址多到自己都數不清，深度又把大批頁面埋在篩選器後面。量級大到檢索分配開始有感的站，把爬取預算的說明一併納入規劃。
• 全新且孤立：網站剛上線，外部連結趨近於零。等別人主動連向你，主導權不在自己手裡。
• 導覽外孤兒頁：有頁面只能從站內搜尋或篩選結果抵達。根治靠補連結，內部連結的布局方法比任何提交動作都優先，清單只是補位。
• 內容靠前端渲染：關鍵文字要等 JavaScript 執行後才出現，讀不到就等於不存在，這是JavaScript SEO 的專文要處理的範疇。
• 多型態內容：圖片或影片本身就是內容主角，延伸格式才有發揮空間。經營電商的讀者，可以把這題接上WooCommerce 產品頁的收錄處理，商品頁是收錄量的主力。

示範的五金站在這一節命中兩個訊號：兩千個產品頁要經過多層篩選才浮現，分類篩選又會生出參數網址（情境為建構）。這就是判準的用法：不是感覺網站很大，而是能指出哪幾題答「是」。五題都答「否」的站，把這件事往後放不是偷懶；同樣的力氣花在內容與連結上，回報通常更具體。

欄位的差別待遇：能被驗證的訊號才有份量

同一份檔案裡的欄位，機器端的待遇差很大，分界的機制只有一條：訊號能不能被交叉驗證。loc 對得上真實頁面、lastmod 對得上實質變化，機器拿得到旁證，所以有參考價值；priority 與 changefreq 是純自我報告，自稱重要、自稱天天更新，機器無從查證，sitemaps.org 的協定裡也只把它們定位為建議，久而久之下游自然不依賴。

↔ 左右捲動檢視完整表格

欄位	你以為的作用	機器端的實際待遇
loc（網址）	宣告網址存在，順便排個先後	清單的本體，對不上真實頁面就整筆失效
lastmod（更新時間）	標得越新，越常被造訪	對得上實質變化才有參考價值，供重新檢索的排程參考
priority（優先度）	自報重要度，換取青睞	協定定位為建議，Google 不使用
changefreq（更新頻率）	預約機器的造訪頻率	同為建議性質，多數時候被忽略

lastmod 的實質更新怎麼認定？標準很白話：一個曾經到訪的讀者再回來，看得出哪裡變了嗎？看得出，才算；只訂正一個錯字、換掉圖檔的檔名，這類讀者無感的調整不算。若每天都把時間戳改成當天、內容卻沒動，短期看不到代價，長期卻是在訓練機器不相信這個欄位；等到真正的大改版出現，它已經沒有信用可用了。各欄位的語法與標籤定義，協定全文寫得完整，照著組合不會出錯。

放進清單的每個網址，都在花你的檢索額度

清單不是放得越滿越保險，方向剛好相反。每個網址放進去，等於向機器遞出「這一頁值得被單獨評估」的白名單資格，而資格濃縮成四個問句：這一頁撐得起自己的內容嗎？機器讀得到也索引得動嗎？它是不是參數或篩選器生的變體？它是不是轉址或錯誤頁？四問全過才有位置，有一問答得心虛，就先不放。通不過檢查的網址大量混進去，等於請機器重複評估同一批內容，花掉的是你自己的檢索額度。

最大宗的污染源，是 faceted 導覽與排序參數生出的網址變體：同一批內容的過濾與排序版本全塞進檔案，機器要多花資源處理重複訊號，查詢參數網址的取捨有完整的處理原則。同一內容的多個版本，只放標準網址，canonical 的設定邏輯在這裡是一體兩面。確定不打算收錄的頁面，走noindex 的幾種施作方式處理；一邊在清單裡推薦、一邊在頁面上宣告不要，是最該先剔除的自相矛盾。

另一個安靜的污染源是空彙整頁：分類底下沒有商品的版本、只剩一兩項結果的極窄過濾頁，內容與其他頁面幾乎相同，對搜尋者沒有獨立價值。這類頁面常是篩選器自動生出來的，網站主人未必知道它們存在；對帳時清單數比發布數多出一截，往往就是它們的貢獻。處理方向與參數頁同一路：能收斂的就收斂成有內容的分類頁，收斂不了的不給清單位置。

風險也不是「放多了會被罰」這種處罰，而是訊噪比：雜訊多的清單，會把自己在報表裡的診斷價值稀釋掉，乾淨的清單才讀得出重點。送出前把三個數字並排，發布數從 CMS 後台的已發布頁數看，先排掉草稿與修訂版本；清單數不必逐筆手數，在檔案裡統計 url 項目的數量即可，送出之後 Search Console 的報表也會直接列出已提交的網址數；真分母是發布數減去刻意 noindex 的頁數，也就是預期會被收錄的量。落差的型態會直接指出該修哪個決定：

1. 清單多於發布：納入設定可能過寬，分頁、參數與空彙整被一起塞了進來。
2. 清單少於發布：排除設定可能過頭，或建置完成後根本沒有重產檔案。
3. 真分母異常偏低：清單裡混了 noindex、封鎖或轉址頁，noindex 的觀念解析把這條界線畫得清楚。

五金站在這一節翻出第一個意外：對帳才發現清單混進上百個篩選參數頁，真分母一算就現形（情境為建構）。對帳不必天天做，三個時機固定排就好：大改版前後、內容清倉之後、每季一次的例行健檢；每個落差都要能追溯到一個具體決定，找不到來源的落差，就是下一次要盯著看的風險。

誰產生這份檔案，決定它多久會過期

挑產生方式，不是挑工具，是兩個軸的交叉：誰手上永遠有你最新的網址全貌，以及新增頁面時，它會不會自己跟上。自動同步式（CMS 外掛、建置流程）內容一動、清單跟著動；一次性盤點式（爬蟲、線上產生器）掃完那一刻就開始過期，定位是救急與對帳，不是長期機制。四種來源放進同一張矩陣看：

↔ 左右捲動檢視完整表格

來源	清單壽命	維護成本與定位
CMS 外掛	跟著內容自動同步	低，設定一次，主流路線
建置流程	每次建置自動重產	低到中，要寫進部署習慣
爬蟲掃描	掃描當下有效	高，每次都要人跑，只當盤點
手寫最小檔	手動更新	頁面極少才划算

外掛路線是主流，市場結構說明了原因。W3Techs 2026 年 9 月的統計裡，WordPress 在 CMS 市場的占有率將近六成，這群站多半交給外掛處理：Rank Math 的 Sitemap 模組會為文章、頁面與自訂文章類型持續維護清單，納入與排除的範圍可以設定，網址量到上限時自動分檔。同類外掛的差異，併著WordPress SEO 外掛的橫評與Rank Math 的設定教學一起看；動手前先把永久連結的定型做完，網址結構日後大改，清單等於重來一次。

靜態站產生器與 Headless 架構屬於建置流程這條路：Astro、Next.js 這類框架靠建置時的外掛，每次建置就自動重產 sitemap index 與子檔，原始碼一推上去，清單就是新的。這條路有一個專屬陷阱：前端路由不等於後端 API endpoint，Headless 網站的內容 API 網址，與公開頁面網址是兩回事，清單該放的是使用者實際會開啟的最終頁面網址，不是機器讀資料用的那一組。頁面極少的站手寫最小清單也行，結構用文字說明就是：一份 urlset 包住多個 url，每個 url 裡用 loc 放網址、用 lastmod 放實質更新日，協定全文公開在 sitemaps.org，照著組不會錯。

沒有人說得清全貌的站，才動用爬蟲。接手來路的舊站、或頁數連自己都說不準的大站，先用Screaming Frog SEO Spider掃一遍，順帶做斷鏈與重複頁的健檢；免費的線上產生器xml-sitemaps.com也可以，免費版本設有頁數上限，以工具官方頁面為準。這兩條路都屬一次性盤點：產物拿來對帳、拿來救急可以，當成長期維護機制，就會一直追著過期跑。工具面的整體挑選，併進SEO 工具的評比一起看。

規模到了上限就得拆檔。協定定下的硬上限是單檔 50,000 個網址、或未壓縮 50MB，兩者先碰到誰就算誰；超過時用一份 sitemap index 把子檔包起來，送出只送 index 那份。拆檔依頁面類型分：商品一檔、文章一檔、分類一檔，日後哪一群收錄掉了，一眼定位問題群；大站的分割與管理，Google 的大型 Sitemap 專文有更細的建議。

主動提交與被動聲明，換到的確定性不一樣

送出前只有一個前提：先通過網站擁有權的驗證。HTML 標籤、上傳檔案、DNS 紀錄都行，官方驗證說明列出全部方法；還沒驗證的人，回Search Console 的驗證流程跑完再回來。接著在 Sitemaps 頁面填路徑送出，輸入時只需要路徑，不必連網域一起貼上；回報的狀態常見「成功」與「無法讀取」，夾帶錯誤時也會另外標明（狀態欄位的官方定義），而「成功」的意義僅止於檔案被讀到。

檔案送出去之後，節奏就不在你手上了。官方文件把界線畫得很清楚：提交這個動作，只是把檔案位置當成線索交出去，下載檔案、抓取網址、編入索引，三件事都不在保證之列。把界線記住，對報表的期待才會準；主動提交真正換到的確定收益，是看得到的狀態回報與錯誤訊息，收錄的保證本來就不在交易的內容裡。

狀態卡在「無法讀取」時，按三步依序查：先看路徑有沒有拼錯，多一個斜線、少一個副檔名都是常見犯；再把檔案網址貼進瀏覽器直接開開看，開不了就先修伺服器端；都沒問題，就對照協定查格式，標籤拼錯或編碼不符都會被判失敗。通常十分鐘內能定位原因，比反覆重送省事。

robots.txt 那條路，是在檔案裡加一行 Sitemap 宣告，支援協定的爬蟲來讀檔時自然會看到，性質是跨引擎的被動保險。robots.txt 的完整介紹值得整篇讀過，先記一個地雷：robots.txt 擋得住檢索，拿不掉已建立的索引，兩件事混在一起會出狀況。Bing 與 Yahoo 端，用Bing Webmaster Tools 的實務處理；兩家引擎背後的合作關係會隨時間變動，搜尋結果不要直接劃上等號。兩條管道的差別，用「有沒有回報可看」一句話就能說完：主動提交給你一個看得到的管理介面，聲明只是讓檔案的存在被知道，官方沒有承諾哪條比較快。

差距落在哪一環，動作就落在哪一環

讀報表時，把兩份串成一條鏈：Sitemap 報表的「已發現」是起點，網頁索引報表的「已索引」是終點，兩者之間的差距，就是還沒做完的工作。差距的長法不同，修的地方就不同：已發現的數字離清單數很遠，先查檔案與提交這一端，格式、路徑，或者機器讀檔的排程根本還沒輪到，隔一陣子再回來看，多半會自己收斂；已發現夠、已索引偏低，才進入真正的排查區，這時網頁索引報表的原因欄位就是地圖，按欄位分類，一類一類往回修。大範圍的確認看網頁索引報表的判讀，單頁狀態用網址檢查工具的操作最準。

「已找到」三個字常被高估：它只說明網址排進了待辦佇列，內容還沒被讀過。一批網址長期停在已找到、遲遲沒被讀取，常見的背景是整站檢索量不高，機器把資源投在別處；此時值得經營的是全站的爬取吸引力與連結，繼續對清單送件沒有幫助。官方文件也把已發現與已索引之間的落差視為常態，而不是需要報警的異常。

把索引比例當體溫計之前，先確認分母放對了：分母不是清單裡的網址總數，而是預期可索引網址，不打算送進索引的頁面，先從分母剔除再算。健康門檻也沒有一體適用的數字，七八成才健康、跌破六成要警戒這類一體適用的講法，站型一換就失準。比單一總比例更有診斷價值的做法是分組追蹤：商品頁一組、文章一組、分類頁一組，哪一群的已索引數在掉，問題就鎖定在哪一群。被判「重複，Google 已選擇其他標準網址」的頁面不算損失，canonical 整併的設計，本來就會讓重複版本退出索引。

Google Search Central 的 Search Console Training 系列影片，把這套流程整套演示過一次：提交的入口在哪裡、處理狀態去哪個頁面看、報表上每個數字的意義是什麼，片中並且特別提醒，提交成功不等於所有網址都會被索引。影片的說法與書面文件的措辭相互一致：清單影響的是發現，收不收錄，由評估端決定。

看報表的頻率，不用自己發明規格：新站與大改版後的頭幾週，一週看一次；數字進入穩態後，併入每月的例行健檢即可。報表面想練手感，Search Console 的實戰技巧可以當手冊翻；單一網址的確認，確認單一網址是否被收錄的做法講得最細，兩篇搭配著用。

先讓機器讀得到，再談值不值得收

修正的順序會決定成敗：第一層修可讀性，第二層才修價值。順序顛倒的代價很具體：把幾個星期燒在改文案上，而擋在門口的只是一行 noindex 或一條封鎖規則。

可讀性這一層的共同點，是機器根本沒讀到內容，或讀到時被明確擋下；要修的是設定，內容先放一邊：

• 頁面帶著 noindex 標記：移除標記，或承認這一頁本來就不該出現在清單裡。
• robots.txt 封鎖了檢索：解開允許，並記住封鎖與索引是兩件事。
• 回應 404 或伺服器錯誤：修網址或伺服器，重新提交沒有幫助。
• canonical 指向其他版本：確認指向是你要的，清單裡只放標準網址。

價值那一層有三種修法：內容薄弱就補、與其他頁面高度重複就整併、關鍵內容靠前端程式才渲染就修管線。工作量大，但躲不掉。修正之後的驗證，單頁可以用網址檢查工具的要求建立索引功能，但它設計給零星排查、有每日次數的節流，不適合拿來把整批網址灌一輪；批次的做法還是回到清單與結構，讓機器照自己的排程消化。

修正之後也別急著天天驗收。可讀性的修正，幾天內就能在網址檢查看得到變化；價值層的修正，要等機器重新檢索與評估，通常以週為單位回頭看才公平。把預計回查的日期直接寫在修正清單上，比憑記憶回訪可靠，也避免「改了卻以為沒效」的誤判。

該系統性處理還是逐頁處理，看原因欄位的分布：同一個原因掛在一大批頁面上，是結構問題，從分類架構、篩選器設計或渲染管線的根源修，逐頁補救沒有盡頭；零星分布才逐頁看。整站性的整備，屬於技術性 SEO 的系統性指南的範圍，建議當成獨立的工作階段排程，與內容產製分開管理。

搬站與改版，一致性比速度值錢

換網址與大改版的銜接，順序是固定的：先把新頁面全部確認可以正常開啟，接著讓每個舊網址一對一 301 轉到對應的新頁，然後把內部連結與 canonical 換成新網址，等各處訊號對齊之後，再送出只含新網址的清單。這套順序做齊，不保證一定被收錄；少做任何一件，過渡期就會被拉長。真正在作用的是一致性訊號：新頁可存取、轉址對應正確、清單與連結指向同一組網址，機器收到的指令不互相矛盾，過渡才走得完。

過渡期間，舊清單先留著，幫機器理解新舊網址的對應關係；這段時間 Search Console 同時列出兩份，屬正常狀態，不必急著刪掉舊的。收尾的判準看報表、不看日曆，三個訊號一起到位才算結束：新網址的已索引數量趨穩、舊網址不再以已索引狀態出現、沒有新增的轉址錯誤。這段時間通常以週為單位，依站而異。

五金站的改版續章（情境為建構）：團隊把篩選參數頁整併成路徑式分類頁，回穩時間比預估多出幾週。事後對帳找到兩個延遲源：一批 301 到新版上線才生效，選單深處還有一段連著舊路徑。根因在時序與一致性，不在內容；換網址的整段工程，網址優化與轉址設定拆得更細。

延伸清單開不開，看內容裡誰是主角

三種延伸格式，一句話各自定位。圖片清單回報的是沒寫進 HTML 的圖：JavaScript 執行後才掛上畫面的、被當成 CSS 背景套用的；圖是產品主角的站，開了才有意義。影片清單的服務對象，是那種頁面本身只當播放器殼的影片頁，讓機器知道裡面有可索引的影片；縮圖網址要提供，而且要能公開存取。新聞清單只裝最近兩天內的內容、需要持續翻新，門檻在內容要符合 Google News 的政策；這裡沒有申請或審核手續，符合政策的網站會被自動納入評估，內容不是新聞型態就用不上。

判準一句話：格式服務內容型態。五金站的零件規格圖，有機會藉圖片清單走進圖片搜尋的發現範圍（情境為建構）；一個純文字站開圖片格式，就只是多一份要維護的檔案。開了就要讓它跟著建置流程更新：新聞清單還留著三天前的項目，等於對外展示一份沒人在顧的檔案，開了又放著，傷害比不開更大；圖片端的細節，接圖片 SEO 優化。

什麼時候根本不必管它

走完整套機制，邊界反而變得清楚。三種情況可以放心不做：連結走得到每個頁面、收錄狀態正常、近期沒有改版或換網址的計畫。三個訊號出現時，才值得重跑一輪：大改版或大量換網址之後、自然搜尋流量無預警回落、每季一次的例行健檢。用觸發條件取代固定的時間表，因為這件事的價值在儀器，不在儀式。

一輪跑完留下來的東西，比「送出了」三個字多得多。五金站的帳面（情境為建構）：真分母建立了、參數頁從清單剔除、索引比例改依產品頁分組追蹤；下一次流量出現異動，有儀器可以量，不必從頭調查。第二次重跑只剩驗證的成分，調查的功夫，第一次就已經做完了。

這份清單真正買到的，是被看見的機會，加上一排看得到的數字；被看見之後的排名與流量，接手的單位是內容品質與搜尋意圖的契合度，兩段是接力，不是替代。往下一層的兩份材料：SEO 完整指南與搜尋意圖的分析。

對帳之後若發現問題屬於整站層級，或團隊沒有餘力做系統性健檢，Whoops 有收錄與索引鏈的技術健檢與顧問服務；所有診斷以可驗證的報表為依據，不對排名或流量結果做承諾。