好，今天我們來聊一下這個 XML sitemap。嗯…很多人，真的很多人都覺得 sitemap 就是做好，然後丟到 Google Search Console 上面就沒事了。你知道嗎？我以前也差不多是這樣想的，但後來踩了幾個坑之後才發現，哇，裡面細節還真不少，特別是當你的網站開始變大、內容變多的時候，這個「地圖」怎麼畫，會直接影響到 Google 怎麼看你的網站。
先說結論：你的 Sitemap 不是給了就好，而是要給得「聰明」
簡單講，Sitemap 的核心目的，就是引導搜尋引擎的爬蟲（crawler）去有效率地抓取你網站上的重要頁面。 它像是一本書的目錄，你總不希望目錄裡面有缺頁、有錯誤頁碼，或是一堆跟內容無關的廢話吧？ 所以，優化 sitemap 的關鍵，不是把所有網址都塞進去，而是要策略性地告訴 Google：「嘿！這些頁面最重要，請優先來看！」這對於大型網站、新聞網站，或是剛上線沒什麼外部連結的新站來說，尤其重要。
多數教學沒講清楚的細節：不只是「有」，更是「好」
我看了很多文章，大部分都在教你怎麼「產生」一個 sitemap，例如用什麼工具啊、怎麼提交啊之類的。 這些都對，是基礎。但很少有人深入去談，當你的網站有幾萬、幾十萬頁的時候，那個 sitemap 檔案本身就會變成一個災難。你想想看，一個塞了五萬個網址的 sitemap，Google 爬蟲真的會每一次都從頭到尾乖乖爬完嗎？
再來就是 `lastmod` 這個標籤，也就是最後更新日期。我看到太多網站，為了想「騙」Google 說我的網站很活躍，就用腳本每天把所有頁面的 `lastmod` 都更新成當天日期。這在以前可能還有點用，但現在 Google 聰明多了。Google 的文件其實有提到，他們會比對頁面內容，如果發現 `lastmod` 的日期一直變，但內容根本沒動，久而久之，Google 就會開始不信任你給的這個訊號。 甚至有日本的 SEO 專家實測發現，濫用 `lastmod` 反而可能對 SEO 產生負面影響，因為這會損害你 sitemap 的信用。 所以，只有在頁面有「重要」更新時，像是修改了主要內容或結構化資料，才去更新 `lastmod`，改個錯字、換個標點符號那種就免了。
怎麼做？從網站結構開始思考你的 Sitemap 策略
好，那到底該怎麼做比較好？我自己是覺得，不要把 sitemap 當成一個獨立的檔案，而是要把它跟你的網站結構綁在一起思考。簡單來說，就是「分而治之」。
Google 其實早就考慮到大型網站的需求，所以 sitemap 有個限制，單一檔案不能超過 50,000 個網址，或是檔案大小不能超過 50MB。 這不是在為難你，這是在提醒你：「該分檔了！」你可以建立一個 `sitemap_index.xml` 的索引檔，然後由這個索引檔去指向多個子 sitemap 檔案。
這要怎麼分呢？這就是學問了。你可以：
- 按內容類型分：例如 `products.xml`、`articles.xml`、`categories.xml`。這樣做的好處是，當你只是更新了幾篇文章時，你只需要更新 `articles.xml` 的 `lastmod`，而不用動到龐大的商品 sitemap。
- 按重要性分：把核心頁面（首頁、主要分類頁）放在一個檔，把次要的、比較不常更新的頁面放另一個檔。
- 按更新頻率分：新聞網站就很適合這樣做，把每天更新的新聞頁放一個 sitemap，其他靜態頁面放另一個。
這樣拆分之後，管理起來會變得非常輕鬆。你可以針對不同類型的內容，設定不同的更新頻率，這對爬取效率（Crawl Budget）的優化非常有幫助。 說到爬取預算，這點跟台灣這種電商密集的環境特別有關。很多電商網站商品數動輒上萬，如果全部塞在一個 sitemap，Google 爬蟲可能花了很多時間在爬那些萬年不動的舊商品頁，反而忽略了你剛上架的熱門新品。
反過來看，Google 官方文件雖然提供了基本規範，但像日本 SEO 圈的一些討論就更深入，他們會去驗證不實的 `lastmod` 是否會導致 Google 降低對整個 sitemap 的信任度。 這告訴我們，誠實地告訴 Google 頁面的狀態，遠比試圖用小聰明去「催促」它來得更重要。
Sitemap 策略比較：到底哪種適合我？
說了這麼多，你可能還是有點亂。沒關係，我把它整理成一個表格，讓你比較清楚不同策略的優缺點。
| Sitemap 策略 | 適合對象 | 優點 | 缺點 |
|---|---|---|---|
| 單一靜態 XML 檔 | 頁面少於 500 頁的小型網站、個人部落格。 | 超簡單！很多線上工具都能一鍵生成。 | 網站一變大就完了，管理不易，而且只要一更新就要重傳整個檔案。 |
| Sitemap 索引檔 + 分割檔案 | 中大型網站，特別是電商、內容平台。 | 管理彈性高，可以針對不同區塊設定不同更新頻率，對爬取預算很友善。 | 設定起來比較複雜，需要後端工程師的幫忙，或是使用比較進階的 SEO 工具。 |
| 動態即時生成 | 新聞媒體、大型論壇、內容變動極快的網站。 | 可以最快速度通知 Google 有新內容，幾乎零時差。 RSS/Atom feed 其實也是一種動態 sitemap 的形式。 | 開發成本最高，對伺服器資源也是一種考驗，沒寫好可能會出錯。 |
常見的錯誤與迷思：別再這樣做了！
最後，我想提幾個我真的看到快爛掉的錯誤觀念，拜託，如果你還在這樣做，趕快停下來。
- 把所有網址都丟進去：拜託不要！Sitemap 是用來放你「希望」被索引的「重要」頁面。 那些 `noindex` 的頁面、404 錯誤頁、內部測試頁、或是內容重複的頁面，都不應該出現在 sitemap 裡。 你等於是給了爬蟲一張充滿斷頭路和鬼打牆的垃圾地圖。
- 設定了就不管了：Sitemap 不是一次性的工作。你應該定期，例如透過 Google Search Console 的報告，檢查 sitemap 的狀態，看看有沒有錯誤，或是哪些提交的網址一直沒被索引。 這些都是優化你網站內容和結構的重要線索。
- 以為 `priority` 和 `changefreq` 是聖旨：前面提過 `lastmod`，而 `priority`（優先權）和 `changefreq`（更新頻率）這兩個標籤，Google 也說了，它們更像是「提示」而不是「命令」。 你可以給建議，但 Google 還是會自己判斷。所以，與其花時間在這些標籤上斤斤計較，不如把精力放在提供真正有價值的內容和維持 sitemap 的乾淨、準確。
總結來說，把 sitemap 當成你跟 Google 溝通的一個重要管道，而不是一個交差了事的作業。一個乾淨、結構化、且誠實反映網站狀態的 sitemap，才能真正幫助你提升爬取效率，讓你的好內容更快被世界看見。
好啦，今天大概就聊到這裡。不知道你對自己的 sitemap 策略有沒有新的想法？你是用哪種方式在管理你的 sitemap 呢？可以在下面留言分享一下，大家一起交流交流。
