網站地圖的 lastmod 天天都在變：分割與更新頻率的錯誤案例檢討
網站地圖每天把全部網址的 lastmod 改成今天，等於告訴搜尋引擎「每一頁都剛改過」。訊號失真之後，真正更新的頁面反而被淹沒。解法是依更新節奏拆檔，只在內容實質改變時才更新日期，並讓每個檔案各自有清楚的維護人。
這篇是一份錯誤案例檢討。案例是示範情境，由多個常見狀況拼成，不對應任何真實客戶。我們用它把「網站地圖該怎麼分割」與「更新頻率怎麼標」這兩件事拆開講清楚。
示範情境：一張每天都在「更新」的網站地圖
一家賣工具零件的中型電商，網站約有商品頁、分類頁、部落格、門市頁四種內容。網站地圖由外掛自動產生，全部放在同一個檔案。
外掛有一個預設行為：每次排程重建時，把所有網址的 lastmod 寫成重建當下的時間。排程設在每天凌晨。結果是一千多個網址，每天都顯示剛剛更新。
行銷人員發現兩個現象。第一，新上架的商品要很久才出現在搜尋結果。第二，部落格改過價格說明的舊文，搜尋結果裡的摘要遲遲沒變。兩件事都指向同一個問題：搜尋引擎不知道該先看哪一頁。
錯在哪裡？三個彼此相連的判斷失誤
失誤一：把 lastmod 當成心跳訊號
團隊以為日期越新，爬蟲來得越勤。實際上 lastmod 的價值在於「可信」。當每一頁每天都改日期，這個欄位就失去分辨能力。爬蟲無法從中挑出真正改過的頁面，只能自己決定節奏。
失誤二：依賴 changefreq 與 priority
外掛把首頁的 priority 設成最高，商品頁設成中等，changefreq 全部寫 daily。團隊以為這樣能指揮爬蟲。實務上，這兩個欄位很難左右主要搜尋引擎的檢索排程。花時間調它們，不如把 lastmod 寫對。
失誤三：一個檔案裝全部
所有網址放在同一個檔案，Search Console 的報表也只能看到一個總數。哪一類頁面被收錄得差，完全看不出來。問題被平均掉了。
重整後的分割方式
我們把單一檔案拆成一個索引檔加上數個子檔。拆分依據不是網址數量，而是「更新節奏」與「負責人」。同一個子檔裡的頁面，應該用相近的頻率更新，並由同一個人維護。
| 子檔 | 內容 | 實質更新的觸發條件 | 維護人 |
|---|---|---|---|
| sitemap-products-new | 近九十天上架商品 | 上架、規格或價格調整 | 商品組 |
| sitemap-products-core | 九十天以上的常態商品 | 規格、價格、庫存狀態改變 | 商品組 |
| sitemap-categories | 分類與篩選後保留索引的頁 | 分類說明或排序邏輯改寫 | 網站管理 |
| sitemap-articles | 部落格與知識文章 | 內文段落、數據或結論修改 | 內容組 |
| sitemap-stores | 門市與服務據點頁 | 地址、營業時間、電話異動 | 營運組 |
新品單獨成檔有一個好處：上架後可以在報表裡直接觀察這一檔的收錄比例，不會被幾百個老商品稀釋。商品過了九十天，再移到常態商品檔。
拆分之前，也要先清掉不該在地圖裡的網址：已轉址、已設 noindex、標準網址指向別頁的頁面，都不應出現。網站地圖應該只列你希望被索引的標準網址。索引數量本身若已經膨脹，可以先參考索引膨脹的清理順序再回來拆檔。
lastmod 什麼時候該改，什麼時候不該改
這是整次檢討最重要的規則。我們寫成一張判斷清單，貼在內容組與商品組的作業文件裡。
- 該改：商品價格、規格、庫存狀態改變
- 該改：文章主要段落改寫、數據更新、結論調整
- 該改：門市地址、電話、營業時間異動
- 不該改：頁尾年份、側欄推薦文章、相關商品輪播換了
- 不該改：只修一個錯字或調整排版間距
- 不該改：外掛或主題更新，頁面內文沒有變
- 不該改：網站地圖排程重建本身
規則背後的邏輯很單純。lastmod 要回答的是「讀者看到的主要內容有沒有變」。只要答案是否，日期就不動。這也呼應 Google 對有用內容的說法：不要為了顯得新而改日期，Google 建立有用內容的說明裡把「為了看起來新鮮而改日期」列為需要自問的情況。
技術上，最穩的做法是讓 lastmod 讀取資料庫裡「主要內容欄位」的最後修改時間，而不是頁面輸出時間。如果系統做不到，就先改成手動維護，寧可慢，也不要錯。
更新頻率怎麼排：三種節奏
網站地圖檔本身也需要決定多久重建一次。重建頻率和 lastmod 是兩件事。重建只是把最新狀態寫出來，日期是否改變，仍然由內容決定。
| 網站類型 | 建議重建節奏 | 原因 |
|---|---|---|
| 每天上架商品的電商 | 每天一次，或上架後即時 | 新品需要盡快被發現 |
| 每週發文的企業官網 | 發文或改文後即時 | 頁數少，事件驅動就夠 |
| 很少變動的形象網站 | 每月檢查一次 | 重點是確認沒有失效網址 |
即時重建需要外掛或系統支援。做不到的話，排程重建也可以，只要日期是從內容欄位讀出來，就不會再出現全部同一天的狀況。
重整後怎麼驗收
驗收不看排名，因為排名受太多因素影響。我們只看三件和網站地圖直接相關的事。
- Search Console 的網站地圖報表裡，每個子檔都能成功讀取，沒有錯誤
- 各子檔「已提交」與「已建立索引」的比例分開觀察，找出最弱的一檔
- 抽查十個最近真正改過的網址，確認 lastmod 是改動當天，而不是重建當天
在示範情境裡，最弱的是常態商品檔。追下去發現許多停售商品還留在地圖中。這不是拆檔造成的，而是拆檔之後才看得見。這正是分割的價值。
網站地圖只是讓搜尋引擎找到頁面的管道之一。站內連結結構仍然是基礎，Google 的 SEO 入門指南也把兩者並列說明。更完整的拆分原則可以對照網站地圖拆分與優先順序的做法。
檢討會上被追問的四件事
檢討會議裡，老闆與工程師各自提了問題。這些問題在其他網站也常出現，我們把回答整理在這裡。
子檔要不要依網址數量平均分配？
不必。單一網站地圖檔有網址數與檔案大小上限，超過時一定要拆。但在上限之內，拆分依據應該是管理需要。一個子檔只有五十個網址也沒關係，只要它代表一種清楚的頁面類型。
停售商品要從地圖移除嗎？
要看頁面如何處理。如果停售頁轉址到替代商品，就移除。如果保留頁面並標示停售，提供替代建議，它仍是有用的頁面，可以留在常態商品檔，lastmod 改成標示停售的那一天。
改了 lastmod 之後要不要每次都重新提交？
不需要每次手動提交。網站地圖網址固定，在 Search Console 提交一次，並在 robots.txt 寫明位置即可。之後搜尋引擎會自行回來讀取。手動重新提交適合用在大規模改版之後。
文章只改了標題，日期要改嗎？
如果標題改動反映內文重點改變，就改。如果只是換個說法吸引點擊，內文不動，就不改。判斷標準永遠回到同一題：讀者讀到的主要內容有沒有變。
適用與不適用的情況
適用：頁數超過數百頁、內容類型多、有多人維護的網站。這類網站最容易出現日期失真，也最需要分檔看報表。
不適用：二三十頁的形象官網。這類網站一個檔案就夠，重點是確保網址正確、沒有轉址頁混入。拆檔反而增加維護成本。
限制：網站地圖無法保證收錄。頁面品質、重複程度、站內連結深度都會影響結果。如果拆檔後某一類頁面收錄仍然很低，問題多半在內容本身，需要另外處理。想請我們協助盤點網站結構，可以從冠誠的網站技術健檢服務了解流程，常見疑問則整理在常見問題頁。