網站新鮮度訊號別只加一個日期：SITE_UPDATED vs LASTMOD 拆分為什麼重要
文 / Coolkid發布：2026-06-09 · 最後更新：2026-08-04閱讀約 8 分鐘
摘要
GEO(生成式引擎優化)盤點抓不到新鮮度，通常是 schema 缺了 dateModified。但全站只塞同一個 LASTMOD，會讓當時 19 篇沒改內文的文章在 schema 裡假裝「今天更新」，這是 Google 不鼓勵的假新鮮度。把站台部署日跟文章內容日拆成兩個常數之後，Perplexity 的引用力從 62 升到 85。
1. 起點:audit 抓不到新鮮度,我第一個直覺是錯的
跑 GEO 盤點，訊號項拿 5/6，一致性還掉兩分。
提示寫得很清楚，schema 裡沒有 dateModified，schema 的描述跟 meta 對不上。
我第一個直覺很單純，把全站共用的 LASTMOD 常數改成今天的日期，重新 build，問題解決。
實際上跑完一輪之後，我看了一眼 19 篇 SEO 跟 pitfall 文章的 HTML。
每一篇的 Article schema 裡，dateModified 都變成今天。
但我這天根本沒動那 19 篇的內容。我只是改了 build.py 的 head 樣板，加了新鮮度 meta。文章本身一個字都沒變。
那一刻我才意識到，我剛剛把整個站變成一個對 Google 撒謊的站。
照 Google Search Central 對 dateModified 的定義(官方文件)，這個欄位應該反映「文章內容有實質修訂」的時間。
不是部署時間，不是檔案的修改時間，也不是「我今天有 push 過」。
對沒改過的文章宣稱今天更新，本質上跟偷偷改一個日期字串騙 Google 來重爬一樣。
Google 官方只定義了 dateModified 該反映什麼，沒有公開「亂標日期會被怎麼處理」。
以下是我的推測，官方沒有這樣說：一個站如果日期一直在動、內容不動，那個日期對排序就沒有參考價值，久了標了等於沒標。你不必信這句。
SE Ranking 2025 年掃了 12.9 萬個網域、21.6 萬個頁面，看 ChatGPT 到底都引用什麼（原始報告，2026-08-04 查核）。
結論是 3 個月內更新過的內容平均被引用 6.0 次，沒更新的只有 3.6 次，多了將近七成。
新鮮度真的有用。但它的前提是真的更新過，不是日期字串在動。
2. 問題在於:站台跟文章是兩種不同的「東西」
我盯著 constants.py 那一行看了很久：
LASTMOD = "2026-05-29"這個變數被用在三個位置。
首頁 schema 的 dateModified、page_shell 注入的文章修改時間、footer 那行看得見的「最後更新」。
問題在於，這三個位置的「最後更新」根本不是同一個概念。
首頁跟 hub 是活的頁面，每次部署都會重新生成、列表更新、內鏈微調，它的「最後更新」就是「我最後一次 push 的時間」。
但一篇 5 月 9 日寫的 PageSpeed 文章，最後更新應該就是 5 月 9 日，不是今天。
我在 build log 寫了一句留給自己：LASTMOD 一個常數同時表達兩個語意，這是型別錯誤。
型別錯誤遲早會咬你一口。
3. 拆兩個常數,分別語意化
正解很單純，拆成兩個常數，分別表達兩個語意。
LASTMOD = "2026-05-28" # 內容基準日(文章 schema / article:modified_time)
SITE_UPDATED = "2026-05-29" # 站台部署日(首頁 / hub / footer)接著把使用的位置跟語意對齊。
首頁 schema 的 dateModified 改用 SITE_UPDATED，因為首頁是活的，這樣才誠實。
文章 meta 還是用 LASTMOD，先暫用一個內容基準日，逐篇的真實日期留給 #19。footer 的站台更新標籤用 SITE_UPDATED。
og:updated_time 全站都注入，用 SITE_UPDATED，因為它本來就是「這個頁面什麼時候被重新部署」。
footer 的文案我從「最後更新」改成「站台更新」。
原因是文章頁本身就有自己的「最後更新」。如果 footer 也叫最後更新、值卻不一樣，讀者會看到兩個名字相同、日子卻不同的日期，這對信任是負分。
改成「站台更新」就清楚多了。一個是文章本身的，一個是整個站台最後一次部署的。
4. 套完之後,audit 跟 AI 引擎怎麼反應
部署完重跑一次 GEO 盤點：
數字比我預期的明顯。
| 指標 | 改前 | 改後 |
|---|---|---|
| signals(freshness) | 5/6 False | 6/6 True |
| schema_desc_matches_meta | False | True |
| consistency 缺失 | 2 項 | 0 項 |
| brand_entity | 5/10 | 6/10 |
| Perplexity 引用力 | 62 | 85 |
| 總分 | 76 | 78 |
Perplexity 從 62 升到 85，多了 23 分，是這次最讓我意外的一塊。
其他平台變化都很小，ChatGPT 70 分沒動，Google AI 80 分也沒動。
但 Perplexity 對新鮮度顯然有特別重的權重。
這跟它的產品定位有關。它主打即時、引用最新來源，所以排序時對日期比其他引擎敏感。
Ahrefs 2025 年 7 月分析了約 1,700 萬筆 AI 引用（原始研究，2026-08-04 查核）：被引用的頁面平均 1,064 天，自然搜尋前 10 名平均 1,432 天，換算下來 AI 引用的內容新 25.7%。
這個數字蓋過所有平台的平均，但實際上是 Perplexity 跟 ChatGPT 把均值拉上來，Google AI Overviews 對舊內容相對寬容。
所以如果你寫的是長青主題、目標是被 Google 摘要引用，新鮮度沒那麼決定性。如果你的目標是 Perplexity 跟 ChatGPT，新鮮度訊號就是必修。
5. 還沒解的問題:文章 dateModified 還是統一的
這次重構解掉了「站台跟文章」的概念混淆，但沒解掉當時 19 篇文章共用同一個 LASTMOD 這件事。
pagespeed-67-to-93 這篇看得見的最後更新是 5 月 9 日，但它的 Article schema 抓的還是 5 月 28 日，schema 跟畫面上寫的不一致。
這個問題的乾淨解法，不是再把 LASTMOD 往前推一天，是把每一篇文章的真實日期當成一筆資料來管理。
下一篇 #19 會講我怎麼把這 41 篇文章拆出一份日期登錄檔。
再用單一注入點清掉寫死的舊日期，最後做四方一致性驗證，畫面、schema、meta、登錄檔四個都要對得起來。
▸ 常見問題
我可以只把 LASTMOD 改成 mtime 自動取嗎?
不能直接這樣做。mtime 反映檔案的最後修改時間,但 build pipeline 會在每次部署時動到所有 HTML 檔(即使你只改了 CSS),最終結果還是「每篇都今天」。要拿 mtime,至少要拿「source 端」的 mtime — 但即使這樣也有問題:你重構 build.py 的時候會動所有 builder 函式,文章內容沒變但 mtime 變了。最乾淨的還是手動 registry(下一篇 #19 完整講)。
拆兩個常數會不會讓我之後忘記哪個該動?
我用一句話約定:「我有沒有改某一篇文章的內文?沒有 → 只動 SITE_UPDATED。有 → 兩個都動,並且去 article_dates.py 把那一篇的 modified 也 bump。」這個約定可以寫進 build commit message template 提醒自己。比起記憶「今天該不該動 LASTMOD」,記憶「我改了什麼」更可靠。
Google 真的會懲罰假新鮮度嗎?
我不知道,而且我沒有證據說會。Google Search Central 的 Article 文件只定義了 dateModified 該反映「內容有實質修訂」,沒有公開「亂標日期會被怎麼處理」。以下是我的推測,官方沒有這樣說:一個站如果日期一直動、內容不動,這個日期對排序就沒有資訊量,久了標了等於沒標 — 與其說被懲罰,不如說訊號失效。這是推論不是機制,你不必信。反過來想,標實話本來就沒有成本。
Perplexity 為什麼對新鮮度反應這麼大?
Perplexity 的產品定位是「即時 answer engine」,實務上對新鮮度反應比另外兩家大。至於它內部 retrieval 怎麼運作、是不是真的用 dateModified 設門檻過濾,Perplexity 沒公開,我無法驗證 — 我能講的只有 audit 工具給它的分數對新鮮度跳得最明顯(+23),真實引用率怎麼變我看不到。
新鮮度訊號別只加一個日期。
站台跟文章是兩種不同的時間語意，一個常數同時表達兩個，是型別錯誤。拆成兩個之後，盤點的訊號項從 5/6 變 6/6，Perplexity 多了 23 分。
名詞解釋
- 部署（deploy）
- 把做好的網站或程式「推上線」讓所有人用得到的動作。
- GEO（生成式引擎優化）
- 讓 ChatGPT、Perplexity 這類 AI 在回答問題時引用你網站內容的優化方法，是 SEO 在 AI 時代的延伸戰場。
- 結構化資料（Schema / JSON-LD）
- 用機器看得懂的格式跟搜尋引擎說明「這頁是文章、作者是誰、何時更新」，有機會換到更豐富的搜尋結果外觀。
- 內部連結（internal link）
- 站內文章互相連的連結，幫讀者跟搜尋引擎理解「哪些內容相關、哪一頁重要」，是成本最低的 SEO 訊號。
- AI Overviews
- Google 搜尋結果頂部由 AI 生成的摘要區塊，會引用來源網站。被它引用是 GEO 的主要戰場之一。
- 自然流量（organic traffic）
- 從搜尋結果免費點進來的流量，相對於買廣告來的流量。
- ChatGPT
- OpenAI 的對話式 AI。本站常拿它跟 AI 代理對比：ChatGPT 給你答案、你自己動手；AI 代理直接幫你把事做完。
看完這篇之前先確認:
- 在意 GEO audit 分數、特別想被 Perplexity / ChatGPT 引用
- 站台架構是 living page + content article 混合(多數 blog / 紀錄站都是)
- 部署頻率比真正更新文章內容的頻率高
- 純 evergreen 內容站、幾乎不重新部署(你的 build mtime ≈ 內容變更時間,一個常數就夠)
- 用 CMS(WordPress / Ghost)每篇文章已經內建 published / updated 欄位,本來就分開
- 全站只有一頁(landing page)
- footer 跟文章 meta 都叫「最後更新」、值卻不一樣,讀者一看到立刻減分
- 改完 LASTMOD 沒同步改 SITE_UPDATED 的觸發時機(兩個常數要約定觸發時機)
- 把 dateModified 當「最後 mtime」用 — Google 在意的是內容語意變化,不是 file mtime
如果內容對你有用就太好了
隨喜斗內
相關閱讀
- #14 把 /about 改造成 AI 看得懂的 entity:ProfilePage + FAQPage schema 實戰
- #17 workflow 圖書館分類落地:8 篇串成知識結構 + Pillar C 自動化日常
這篇背後的真實開發過程記錄在 Build Log。
搜尋標籤：geo、freshness、schema、datemodified、perplexity、build-in-public。
本篇為個人實驗紀錄。2026-08-04 更正兩處。(1) 初版把 SE Ranking 那份研究的樣本規模寫大了一個量級,舊內容的引用次數也抄錯,兩個數字已對回原始報告更正並補上來源連結。(2) 初版把「Google 會逐漸調低這個站的新鮮度權重」寫成已知機制,官方沒有公開這件事,已改標為個人推測。GEO audit 分數來自第三方工具,不同工具評分標準不同,本文做法不保證在你的網站產生相同結果,請依自身狀況驗證。教育研究用途,不構成投資建議。