公司規劃網站 SEO 費用時，常把「每月更新舊文章」列成固定工作，卻沒有定義什麼叫更新。有人改一個標點就把日期換成今天，有人重寫半篇仍只顯示最初發布日，也有人讓畫面日期、結構化資料與 sitemap 各自不同。報表看起來持續有產出，讀者卻無法判斷內容是否真的重新查證。

文章維護應先建立內容版本與變更判準，再決定何時顯示更新日、何時調整機器可讀資料。日期不是讓頁面看起來新鮮的裝飾，而是內容責任的一部分。若 SEO 合約只計算改過幾篇，沒有留下改了什麼與如何驗證，就難以驗收品質。

分開保存首次發布與最後重大更新

首次發布日應在文章第一次公開時固定保存；最後更新日則只在內容有實質變化時調整。校正錯字、修復失效的版面或更換不影響主張的圖片，可以留在修訂紀錄，但不一定構成對讀者有意義的重大更新。新增官方資料、修正已過時流程、重寫主要結論或補充新的適用限制，才比較接近應顯示更新日的情境。

每個組織仍需自行定義門檻。可在編輯流程加入「變更類型」「修改摘要」「查證來源」「審核人」與「是否更新公開日期」，避免由系統看到儲存動作就自動改日期。文章若只有排版調整，sitemap 與結構化資料也不應因此每天變動。

Google 的 Influence your byline dates in Google Search說明，Google 會綜合多個因素估算頁面發布或重大更新時間，不依賴單一日期訊號。官方建議在頁面醒目顯示並清楚標示發布或最後更新日期，也可在文章結構化資料提供 datePublished 與 dateModified；可見日期與結構化資料應保持一致，且日期必須描述頁面發布或更新，而不是正文提到的事件日期。

因此，一篇談年度活動的文章不能把活動日期誤當文章發布日；文章更新日也不能只存在於程式碼、畫面卻顯示另一個值。驗收時要同時查頁面文字、結構化資料與內容後台，並以同一個已核准版本為來源。

用變更紀錄回答「到底更新了什麼」

對法規、產品規格、操作教學或價格敏感內容，可在內部設定較短的複核週期，但週期到期不等於資料自動失效，也不代表一定要改公開日期。負責人應重新開啟原始來源，確認主張仍成立；若沒有內容變動，只記錄本次複核結果即可。

重大更新至少留下舊版本、變更摘要、來源與核准時間。這能在錯誤發布時回復，也能讓下一位編輯知道某段文字為何存在。刪除過時段落時，同樣要檢查標題、摘要、內部連結與結論是否還能成立，不能只移除正文而留下承諾式標題。

SEO 服務的月報可列出「新發布」「重大更新」「例行複核」「技術修正」四種工作，不把它們混成相同篇數。每篇附上變更摘要與驗證來源，比單純截圖日期更能證明交付。若來源無法重新開啟，應標成待查證並避免繼續沿用精確數字或結論。

Sitemap 的 lastmod 只反映重大頁面變更

Google 的 Build and submit a sitemap指出，sitemap 應列出希望出現在搜尋結果的完整 canonical URL；其中 lastmod 若能持續且可驗證地保持準確，Google才會使用。官方將主內容、結構化資料或頁面連結的更新列為可能的重大變更，單純更新版權年份則不是。

這提供明確的開發驗收條件：lastmod 應由內容最後重大更新時間產生，不是網站每次建置時間，也不是伺服器複製檔案的時間。若每天部署都把全站 URL 改成今日日期，搜尋系統與團隊都無法分辨哪些內容真的有變化。

sitemap 也不是保證收錄或立即重新抓取的命令。上述官方文件明確說明，提交 sitemap 只是提示，不能承諾每篇文章會被下載、檢索或取得排名。SEO 提案應把可控制的交付寫成 sitemap 正確產生、可公開讀取、URL 與 canonical 一致、Search Console 沒有處理錯誤；不能把搜尋引擎的最終決定包裝成保證成果。

用多頁技術官網建立內容維護盤點

晶脈封測 ChipWeave 展示案例有 43 頁內容，技術服務依製程分類並透過大型導覽組織。這是半導體官網展示作品，不是實際企業的 SEO 成效案例；它適合示範多頁網站如何建立內容庫存與責任分工。

可以先把每個技術服務頁列入盤點表，記錄內容負責人、首次發布日、最後重大更新、複核期限、引用資料與頁面狀態。當某項製程說明重寫時，只更新受影響頁面的公開更新日與 sitemap lastmod；若只是全站頁尾年份改變，所有技術頁日期都應保持不動。

再選一篇技術文章做驗收：在後台新增經確認的主要段落與內部連結，發布後檢查可見更新日期、結構化資料、sitemap 與 canonical。接著只修正一個標點重新部署，確認重大更新時間不會跟著改。最後回復前一版本，確定日期與內容版本仍能對應，而不是留下未發生的未來時間。

把內容治理納入 SEO 報價與交接

網站 SEO 費用若包含文章維護，交付範圍應寫清楚盤點篇數、複核頻率、每次可處理的變更類型、來源查證、審稿角色、結構化資料與 sitemap 測試。外包結束時，企業要拿到內容清單、版本紀錄、日期規則與產生 sitemap 的方式，而不只是幾張流量報表。

最後用三種情境驗收：首次發布新文章、實質重寫舊文章、只做非實質修正。新文章應有正確發布日；重寫文章保留原發布日並新增一致的更新日；小修則不冒充重大更新。三者都應使用正式 canonical URL，sitemap 只在適當時反映變更。

公司部落格能累積搜尋內容，前提是讀者與維護者都能信任它。把日期、版本、來源與 sitemap 串成同一套內容流程，SEO 工作才從「讓文章看起來是新的」轉成可追溯、可驗收的長期維護。