網站 sitemap 要放哪些網址？用頁面狀態清出提交清單

從正式網址、回應狀態、索引設定與 canonical 逐筆判斷 sitemap 成員，並記錄提交、排除或待修正的日期與原因。

「網站 sitemap 要放哪些網址？」不能靠把網站裡找得到的網址全部塞進去決定；名單應呈現網站希望搜尋引擎理解的正式頁面。實際盤點時，把網址用途、回應結果、索引設定和 canonical 一起看，才能分清應提交、應排除、待修正。本文聚焦 sitemap 成員與頁面狀態，不檢查文章素材或發布流程；表格中的網址與結果均為假設示例，請以自己的網站讀值為準。

列出可提交頁面

先把候選網址從現有 sitemap、主要導覽連結、CMS 網址匯出與人工指定的重要頁面匯在同一份表，先保留重複和原始形式，避免還沒比對就失去線索。對每筆逐一確認三件事：它是否是訪客可使用的正式內容頁；網站是否希望這個頁面有機會出現在搜尋結果；是否有一個穩定、可直接讀取的正式網址。三項皆符合，才標為「提交候選」。常見候選包括首頁、主要服務或產品說明、具內容價值的分類頁、獨立的資訊頁，以及每種語言各自完整且對應正確的頁面。頁面深度、流量大小或是否列在主選單，都不能單獨決定去留；重點是頁面用途與索引意圖一致。正式網址應使用完整絕對網址，並與頁面宣告的 canonical 對照；Google 也建議只列希望出現在搜尋結果的網址。Google Search Central：建立及提交 Sitemap

若清單含篩選或分頁網址，不把不同 URL 都算獨立頁；比較代表頁的主標題、主要內容和 canonical，確認是否值得分別出現在搜尋。大量網址先按頁型抽樣，遇到例外就另立類別，不能因多數合格而批次放行。另設「頁型」「來源」「負責人」欄，方便回查和交接。

下表以假設頁面說明初篩，通過初篩仍要繼續查狀態，不能直接當成已提交完成。表內的「待修正」表示先記下問題、找出負責位置，再回到同一列更新判斷，避免清單只有結論、沒有可追溯依據。

排除非正式網址

排除的核心不是網址長得複雜，而是該網址不是希望被搜尋引擎當作正式頁面理解的版本。先找出同頁多種寫法：HTTP/HTTPS、www 與非 www、大小寫、尾斜線、追蹤參數、篩選排序參數及列印版。若內容相同且頁面指定另一個正式網址，就把正式版本留在 sitemap，將替代版本標示為排除並記錄 canonical 或重新導向的線索。查詢參數並非一律要刪；若參數會呈現不同且需要搜尋曝光的內容，先由網站負責人確認其用途與 canonical 再決定，不能只憑問號判定。

測試／預覽站、開發環境、暫存網址、登入後才能看的帳戶頁、購物車、內部搜尋結果、站內篩選組合、已停用的活動頁，通常不屬於公開正式頁面；仍需核實它們是否真是當前站點用途，避免把「看起來像系統頁」的實際內容頁誤排除。也要查網址是否落在正式主機與語系路徑，不能把測試網域、舊網域或錯誤語系複製到公開清單。

同一頁若可由品牌網域與子網域開啟，先確認正式主機，再比對導向與 canonical；訊號矛盾時標待修正。搬遷中的舊網址，除非仍是希望搜尋呈現的正式頁，否則不要與新網址並列。排除表保留來源，如自動產生、第三方追蹤或人工補入，日後改規則才知道要回查哪些入口。每類規則挑一正一反例，核對是否誤排有獨立內容的頁面。

每種排除都寫明類別與判斷依據，例如「追蹤參數，canonical 指向不含參數版」或「預覽網址，非正式網域」。若頁面應從搜尋排除，sitemap 移除與頁面索引設定是兩項需分別檢查的工作；robots.txt 封鎖爬取也不等同 noindex。保留原始網址和檢查日期，日後有人問為何少了一筆，就能從記錄看出是確認後排除，還是待人處理。

檢查回應與索引設定

檢查 sitemap 中每條網址是否可從公開網路直接載入，並記錄 HTTP 狀態、最後到達網址、robots 是否允許抓取、meta robots 或 X-Robots-Tag 的 noindex，以及 canonical 等必要欄位。一般可提交候選需回傳成功頁面，且不被登入、爬取限制或 noindex 設定排除；「伺服器有回應」不等於「可索引」。Google 列出的技術條件包含可存取、回應 200、具可索引內容，但符合條件仍不保證收錄。Google Search Central：技術規定

遇到轉址不要留原始跳轉網址，先查看目的網址是否是對應的正式頁，再用目的網址作候選；若目的網址跑到首頁或不相干頁面，要標待修正而非自動替換。404 與 410 代表原址已不存在，確認是否有有效替代頁，沒有就移出候選並記下原因；5xx、逾時或間歇錯誤則先留在待修正，因為單次讀取不能說明長期狀態。200 但呈現空殼、錯誤訊息或「找不到內容」也可能是軟性 404，需檢視實際頁面，不以狀態碼自動放行。

實作可用爬取工具或瀏覽器查看 response headers 與 HTML head，將讀值寫入紀錄，不只留截圖。人工抽查同時抄原址與最終網址；批次掃描須確認讀值來自公開正式網域，而非登入狀態或測試主機。不同工具都可用，但紀錄要能辨識量測對象與結果。robots.txt 封鎖爬取不等同網址已離開索引；若要 noindex，須讓爬蟲可存取頁面並讀到指令，再依索引策略處理，避免設定互相衝突而無法判讀。

把「站內預期的 canonical」與 sitemap 網址對照，兩者不同時先調查模板、協定、主機名稱或重複內容。hreflang 是語系頁的相互提示，不能代替每個語系頁自己的可用狀態與正確 canonical。最後把結果標成可提交、排除、待修正，記錄檢查日期及錯誤訊息摘要；修好後回頭重新量測並更新原列，避免新清單只清掉問題，卻失去處理前後的證據。

比對 sitemap 與網站

先建立兩份可比的名單：一份從 sitemap XML 讀出 <loc>，若有 sitemap index，逐個收齊子 sitemap；另一份從正式網站網址來源取得，可用網站可爬取的內部連結清單、CMS 已公開網址匯出或網址清冊。對照前先統一主機、協定、尾斜線及參數規則，但另存原始值，否則正規化可能掩蓋真正的重複或錯誤。CMS 匯出只是一個來源，不等於所有列出頁面都該提交；爬取清單也可能漏掉沒有內部連結、但仍可直接開啟的正式頁面。

比對時把語言與頁型放在欄位裡，避免把繁中頁和英文頁當成重複，也不把同一模板生成的每個變體誤認為必要頁。若來源是 crawler，先確認它從首頁可到達的範圍；若來源是 CMS，確認匯出是否含預覽或已下架記錄。試算表比對時保留原始列號或來源檔名，讓每個差異都能回到來源重新核對；跨網域項目則依正式站點分表，不混成本站漏列。

把比對結果拆成三組：網站清冊有、sitemap 沒有；sitemap 有、網站清冊沒有；兩邊都有但網址版本、回應或 canonical 不一致。第一組逐頁判斷搜尋意圖與狀態後補入或註明排除，第二組檢查是否過期、孤立但有效，或來源漏抓；第三組先查差異原因再修正。不要將「兩份清單不相同」直接當成錯誤數，因為來源的涵蓋範圍可能不同。

例如假設清冊有 120 筆、sitemap 有 110 筆，比對後 100 筆完全相同，10 筆只在清冊、10 筆只在 sitemap。這不是直接新增 10、刪除 10 的結論，而是 20 筆待判斷：清冊獨有的可能是登入或參數頁，也可能是真正漏列；sitemap 獨有的可能是改版後仍有效的頁，也可能是已移除的網址。逐筆記錄最後決定及理由，完成後再以相同規則重跑差異；這組數字只示範假設算術，不代表網站實際表現。

記錄新增移除原因

每次新增、移除或改判，都保留一列變更紀錄，不要只覆寫現行 sitemap 名單。至少記錄網址、舊判斷、新判斷、檢查日期、原因、依據、處理人或下一位負責者、再次檢查條件；依據可寫成實際讀到的狀態碼、canonical 目標、noindex 標記或網站負責人確認，不需要複製秘密參數或使用者資料。若屬於短暫故障，記清楚下次檢查時間；若是永久替代，記下新正式網址以及舊址是否轉址。

例如可寫：「https://example.test/old → 排除；檢查日期 YYYY-MM-DD；回應 404；負責人確認頁面已撤下，沒有替代頁。」或「https://example.test/new → 提交候選；檢查日期 YYYY-MM-DD；200、canonical 指向自身；內容負責人確認為正式說明頁。」這些網址與判斷均為假設示例，作用是示範怎麼把觀察和決定放在同一筆，不表示任何真實網站狀況。

採用只新增、不覆寫的變更記錄，較容易看出反覆問題：同一網址若第二次被加入又移除，能查出是哪條規則改變、在哪次量測後改判。欄位可依團隊縮減，但須保留足以重做決定的資訊；「待修正」要有負責者或下次檢查條件，否則會變成無期限堆放。若匯出方式或正規化規則更新，另記版本，以免把工具改變誤判成網站改變。人工判斷也要寫確認依據，不把推測寫成站點事實。

原因要描述觀察和判斷，不寫「SEO 好」或「看起來沒用」等不可重現的結論。若是清單規則調整，也留修改前後和生效日期，如追蹤參數的統一處理方式，才能用同一規則重算歷史差異。把待修正與已完成分開：未確認的 5xx、canonical 衝突或語系不一致不要假裝已排除；有修正證據後，才將狀態更新為可提交或排除。再次提交 sitemap 不等同網址已收錄；Google 把 sitemap 視為提示，且不保證讀取或爬取。Google Search Central：建立及提交 Sitemap。

定期抽查清單差異

選定固定抽查節奏和觸發條件：例如依網站更新節奏每月抽查一次，另在網站改版、換網域、調整語系路徑、更新模板或搜尋索引規則後，立即檢視受影響清單。抽樣不要只挑首頁；至少涵蓋不同頁型、語系、含參數與不含參數的版本、近期新增或被移除的網址，以及上次列為待修正的項目。若 sitemap 分成多個子檔，讓每份都被抽到，避免只驗證 sitemap index 可讀，卻沒檢查子檔中實際頁面的狀態。

以同一份規則重新讀取 sitemap 與網站名單，先比對新增、消失、重複、主機或路徑變更，再抽查回應、索引指令及 canonical。每個差異都回到三種決策：新增而合格則補記候選；消失但仍合格則調查漏列；已轉址、錯誤或被排除設定影響則待修正或排除。保留本次抽查範圍、清單版本或檔案日期、差異數與每筆處理狀態；這些是內部清單紀錄，不要與公開 sitemap 混成一份。

抽查依變更風險分層：先看近期修改頁面、共用模板代表頁，再抽少量未改動頁作對照。同類連續出現問題，就擴大該頁型抽查並修正產生規則；若只有單頁異常，保留此筆記錄，不把局部問題套用到全站。

設定逾期追蹤方式，例如讓待修正項在負責者確認後再次抽查，沒有明確負責者時先標記未結案，而不是自動關閉。若抽查沒有差異，也記「抽查範圍、日期、無差異」，下一輪才知道檢過哪些頁；若發現多筆差異，先按頁型或共同模板找規則性原因，再逐筆確認，不要批次刪除。完成這次成員與狀態清查後，可到 ZhenheAI 官網 了解網站／數位體驗目前列出的企業網站、內容架構與 SEO 基礎方向，並帶上保留檢查日期和原因的清單，作為下一步需求討論的起點。