Perplexity 引用你，往往不是因為你的文章寫得最好，而是因為在使用者送出問題的那一刻，你這一頁是它手上「最新、而且能被即時確認沒過期」的來源。內容新鮮度在 Perplexity 不是排名的加分項，是能不能進入候選來源清單的門檻。你可以有一篇兩年前寫得極好的分析，但只要它看起來像沒人維護的舊頁，模型在回答時效性問題時就會略過它，轉向一篇資訊較新、伺服器回應更明確的次等內容。
Perplexity 在哪裡讀你的「新鮮度」
先分清楚兩件事。Perplexity 同時維護自己的索引，以及在使用者提問時即時抓取網頁的能力——它的抓取器 PerplexityBot 負責建立索引，另一個 Perplexity-User 代理則在回答當下去確認頁面內容。這代表新鮮度訊號會在兩個時間點被讀到：建索引時，以及回答問題時。你要讓這兩個時間點看到的「這頁最後更新於何時」是一致而且可信的。時效性強的問題（價格、版本、法規、年度數字）尤其吃這一套，模型會傾向挑最近有動過、而且動得有憑有據的頁面。
- HTTP 回應標頭：Last-Modified 與 ETag，抓取器用它做條件式請求，判斷「上次抓過後有沒有變」。
- sitemap.xml 的 lastmod：告訴抓取器哪些網址值得優先回訪。
- 頁面內的結構化資料：Article／BlogPosting 的 dateModified 與 datePublished，讓模型知道內容宣稱的更新時間。
- 頁面上肉眼可見的日期：文章開頭或結尾標示的「最後更新」，人和模型都會讀。
- 內容本身的時效訊號：文中提到的年份、版本號、最新數字，是否和宣稱的更新日期對得起來。
先把伺服器層的新鮮度訊號修對
多數團隊把力氣全放在改內文，卻讓伺服器回傳錯誤或缺失的 Last-Modified，這是最常見、也最容易修的漏洞。正確做法：每次頁面實際內容變動，就更新 Last-Modified 標頭到當下時間；內容沒變就維持原值。搭配 ETag 這個內容指紋雜湊，讓抓取器可以用 If-Modified-Since 或 If-None-Match 發出條件式請求。頁面沒變，你的伺服器回 304 Not Modified、不傳整份 HTML；有變就回 200 帶新內容。很多用前端框架或 CDN 的站，預設把每次請求都回成 200、Last-Modified 還指向部署時間，導致每頁看起來都「剛改過又好像沒改過」，訊號自相矛盾。
條件式請求為什麼影響你被抓的頻率
抓取器對每個網站都有隱性的抓取預算，它不會無限次來爬你。當你的伺服器能用 304 快速回覆「沒變」，抓取器就能把省下來的資源花在回訪真正更新過的頁面上，回訪週期因此縮短。反過來，如果每次抓取都被迫下載整份頁面、又找不到清楚的更新時間，抓取器學到的經驗是「這站訊號不可靠」，回訪頻率會降。我們替客戶做 GEO 審計時，最常見的其中一項，就是修好這一層之後，關鍵頁被重新抓取的間隔明顯縮短。
sitemap 的 lastmod 必須誠實
sitemap 的 lastmod 是抓取器排優先序的重要依據，但它只在「準確」時才有用。常見錯誤是每次全站部署就把所有網址的 lastmod 一起刷成今天，等於告訴抓取器「我全站每天都變」。抓取器很快會發現內容其實沒動，於是整份 sitemap 的可信度一起下降，連真正更新的頁都被連累。正確做法是讓 lastmod 反映該網址內容的實際變動時間，逐頁計算，而不是用建置時間一鍵套用。只放真正值得回訪的網址，別把分頁、標籤頁、參數頁全塞進去稀釋訊號。
dateModified 與頁面可見日期要一致
結構化資料裡的 dateModified、HTTP 的 Last-Modified、sitemap 的 lastmod，以及頁面上肉眼看得到的「最後更新於」，這四個數字應該指向同一件事。當它們互相矛盾——schema 說今天更新、頁面卻寫著去年、伺服器標頭又是另一個時間，模型拿到的是雜訊，只能保守地不信任你宣稱的新鮮度。實作上把更新時間集中成單一資料來源，例如內容管理系統裡的實際修改時間戳記，四個出口都從它渲染，就能避免各說各話。datePublished 保留原始發布日、dateModified 反映最近一次實質修改，兩者都要有。
更新頻率：把力氣花在會過期的頁
不是每一頁都需要頻繁更新，硬要全站定期翻新只會稀釋你的維護資源。先把內容分成兩類：一類是會過期的，像定價、產品比較、整合清單、年度趨勢、法規與版本；另一類是相對恆常的，像名詞定義、原理說明。會過期的頁，排定固定的複查週期，資訊一變就更新、並讓四個時間訊號同步跟上；恆常的頁，只在有實質補充時才動。判斷「該不該更新」的標準是內容有沒有實質變化，不是行事曆到了。一次只改一個字卻刷新更新日的做法，模型看得出來，也不會因此更信任你。
新鮮度不是「多常改」，而是「改得有沒有理由，而且四個地方說法一致」。抓取器信任的是可預測的維護節奏，不是頻繁但空洞的變動。— Tenten GEO
再抓取：你不能命令 Perplexity，但能提高機率
- 確認 robots.txt 沒有擋掉 PerplexityBot 與 Perplexity-User，兩者都要放行，否則後面所有努力都白費。
- 更新關鍵頁後，同步刷新該網址的 Last-Modified、sitemap lastmod 與 schema dateModified，三方一致。
- 壓低伺服器回應時間，並用 304 正確回覆沒變的頁，把抓取預算讓給更新過的頁。
- 從高流量、常被回訪的頁面內部連到剛更新的頁，借它的回訪頻率帶動新頁被更快發現。
- 更新後在其他管道（自有電子報、社群、被外部引用的頁）製造一次新的抓取觸發，增加被即時抓到的機會。
把這套做完，你不是在討好某個演算法，而是讓每一次真實的更新都能被 Perplexity 快速、正確地讀到。多數網站的問題不在內容不夠好，而在新鮮度訊號自相矛盾，讓好內容被當成舊頁略過。如果你想知道自己的站在 Last-Modified、sitemap、schema 與可見日期這四個環節上哪裡在互相打架，可以預約一次 30 分鐘 GEO 診斷（/contact），我們會直接指出讓 Perplexity 略過你的那幾個訊號缺口。
