中小企的 XML 網站地圖應收錄哪些頁面？何時更新 lastmod？

先決定網站地圖代表甚麼

XML 網站地圖是網站擁有人維護的網址清單，用來表明希望搜尋引擎發現哪些頁面。Google 說提交的網址只是提示，包括較弱的標準網址訊號，並非要求收錄清單中每一頁的命令。對小型零售商而言，把所有參數網址、測試頁及過期活動頁加進去，不能創造需求或強迫排名。真正有用的問題是：哪些公開頁面提供獨立內容，訪客從搜尋結果進入亦合理？先訂這項頁面政策，再讓網站地圖反映它。

產生 XML 前，先為每頁選定偏好的網址。若一篇文章同時可從舊路徑、追蹤參數和現行乾淨網址進入，清單只放現行偏好網址一次。使用包含主機名稱和路徑的完整 HTTPS 網址，而非相對路徑，亦不要使用會再轉址的 HTTP 網址。網站地圖內容應盡量與頁面 canonical 標註及站內連結一致。提示互相矛盾，既增加維護難度，也會令 Google 即使看到網站主的偏好，仍須自行選擇重複頁的代表網址。

要把頁面發現與存取控制分開。私人帳戶、結帳確認、站內搜尋結果、草稿或測試站，即使有路由，也不應只因為網址存在便放進公開網站地圖。從清單移除網址，本身不會阻止檢索或移除已收錄頁面；存取控制和索引指令各有用途。反過來，有用的頁面即使不在網站地圖，也可能經連結被發現。應把收錄決定視為公開內容政策，並以技術檢查確保所選網址確實打開預期頁面。

從可靠的頁面來源產生清單

頁數極少的介紹網站，可以由人手維護短網站地圖，並在頁面改動時核對。但產品、指南及不同語言頁面如經常發佈，就應從建立公開路由的同一批已核准內容紀錄產生清單。不要抓取路由器的所有路徑，便假定全部應出現在搜尋結果。每頁須有明確發佈狀態、偏好網址和有意義的內容更新時間。這樣同事問為何某產品缺席、已封存活動仍在清單時，才有可解釋的依據。

把產生的檔案當成公開產物驗證。Google 要求完整絕對網址及 UTF-8 編碼，亦列明單一網站地圖上限為五萬個網址或未壓縮 50 MB。大部分中小企遠低於此限制，把很小的清單拆成多份只會增加管理環節。應從建置環境以外取得公開檔案、解析 XML，並抽查每種內容類型的網址。核對回應狀態、轉址終點、頁面語言及該頁是否預期公開。檔案產生指令成功，並不證明部署後網站提供相同內容。

網站地圖可透過 robots.txt 的 Sitemap 一行讓 Google 發現，亦可在 Google Search Console 提交；後者提供處理資訊，協助判斷 Google 是否取得並理解檔案。兩種途徑都不保證即時檢索或收錄。若提交報告顯示錯誤，應先比較公開檔案和受影響網址，再處理後重新提交；反覆提交沒有改動的檔案並非修復方法。Google 已停止舊有未驗證網站地圖 ping 端點，因此部署腳本即使仍呼叫它，也不能把該動作當成有效的發現訊號。

刪除項目亦需要獨立的決定紀錄。活動結束後，要判斷頁面作為檔案是否仍有用、應引導至相關替代頁，還是應從公開發現途徑移除。先讓站內連結和頁面回應配合選擇，再更改網站地圖。若 XML 刪了網址，頁面和顯眼連結卻仍宣傳它，便留下互相矛盾的訊號。同樣，替代頁若仍需經多個舊網址轉址才到達，直接把它列入清單也會增加含糊之處。記錄頁面負責人的決定，並用一般瀏覽器測試最終目的地，才算完成改動。

讓 lastmod 如實反映內容改動

可選填的 lastmod 指頁面最後一次重要改動的時間。Google 指出，當日期持續符合事實時，它可協助安排再次檢索。主要文字、結構化資料或有意義連結改動，可支持更新日期；頁尾或側欄的零碎修改則未必需要。不要把每個項目一律設成部署時間或今天日期，否則等於反覆聲稱所有頁面都改了。若系統無法為集合式首頁或分類頁提供有根據日期，省略 lastmod 比捏造日期更好。

要為每種內容訂出可重複執行的規則。文章可採用實質編輯修訂獲核准的日期；產品頁可在公開規格、供應描述或優惠詳情有重大改動時更新。共用導覽列改動，不一定代表每頁的日期都要重寫。內容系統應保留導致頁面改動的事件，讓編輯能解釋該數值。日期須符合網站地圖協定支援的格式。如包含時間與時區偏移，也須代表實際事件，不能因伺服器時區設定而意外移位。

有些產生器把 changefreq 和 priority 輸出得像排名控制鈕。Google 表明不使用這些元素。與其替每頁分配主觀優先級，員工時間更應用於核對標準網址和有依據的 lastmod。檔案可以保持簡單：每項包含必要的網址位置，以及有根據才加入的日期。簡單格式亦方便覆核，讓人清楚看到哪頁新增、移除或真正改動，而不用穿過不影響目標決定的裝飾欄位。

以小型網店測試政策

假設網店有一個乾淨的產品網址、同一產品的廣告追蹤網址、仍提供有用資料的售罄產品頁，以及結帳收據。若商戶仍希望訪客找到產品頁，就把乾淨網址列入清單。廣告版本內容相同，不應作第二個偏好網址。收據屬私人頁面，應排除。售罄頁則需要編輯判斷：若仍能協助比較或尋找替代品，保留可能合理；若產品永久下架，頁面亦沒有價值，就應調整頁面與連結政策，而非讓過時條目無限期留在清單。

假設產品標題及規格在星期二改動，全站頁尾在星期四改動。產品的 lastmod 可反映星期二的實質更新，不應只因全站重建便自動變成星期四。若內容系統無法保留星期二的事件，團隊應改善資料流程，或先省略日期，直至能可靠提供。這是示範流程，並非聲稱 Google 會在某天檢索或提升排名。目標是建立可信的訊號，下次發佈時仍有相同意思。

雙語網站要分別檢查英文與繁體中文公開網址。希望被找到的每個語言版本，都應打開其預期內容；網站地圖項目不應悄悄把所有訪客轉到單一預設語言頁。本文處理的是收錄及網址準確性，互相指向的語言標註另有設計需要。實用的抽查方法是在部署後，分別開啟兩種語言的一篇文章、一個產品和一個分類頁。這可在產生檔案變成數百個錯誤項目前，及早發現翻譯路由問題。

為檔案指定負責人及覆核流程

每次發佈時，把網站地圖新增及移除的網址與已核准頁面變動對照。若項目出現轉址、無法開啟、指向另一主機、暴露私人路由，或沒有內容事件卻宣稱新 lastmod，都要調查。部署後取得真正公開的網站地圖；如可使用 Search Console，亦查看其報告。記錄錯誤屬檔案存取、解析還是個別網址，因為修復方法不同。每月簡單覆核舊活動與產品項目，往往比不斷重新提交相同清單更有用。

驗收標準應屬營運層面，而非排名承諾。同事應能說明每種頁面為何列入、把每個網址追溯至仍運作的偏好公開頁，並解釋 lastmod 的來源。Google 仍可能選擇另一標準網址，或不收錄某頁。若搜尋能見度不理想，網站地圖只是診斷資料之一，還要結合頁面效用、站內連結、檢索可及性和真正的 Search Console 證據。清單保持誠實，日後調查才不用先清理自己製造的誤導資料。