Google Search Console 日期切換：書籤做法

想像一個畫面。星期一早上，你打開 Google Search Console（簡稱 GSC）的成效報表，看到那條曝光曲線正穩穩往上爬。你鬆了一口氣，心想這陣子的優化終於發酵了，於是放心地關掉分頁，回去做別的事。

問題是，那條線之所以往上爬，很可能是因為你正看著一個「涵蓋了去年淡季、又接到今年旺季」的 3 個月視窗。你拿去年最低點和這個月最高點比，結論當然是「在成長」。你不是被數字騙了，你是被日期範圍騙了。

三分鐘重點。Google Search Console 的「日期快速設定器」，換句話說，就是任何能讓你用一次點擊、跳到某個預設日期區間的方法。簡單的做法是先在 GSC 選好範圍，把目前網址存成書籤，再重新開啟確認日期仍符合預期。GSC 沒有承諾網址格式永久不變，書籤失效時仍要重建。接下來會從日期判讀講到六個常用的切換場景，再給你一份可直接執行的行動清單。

如果你還沒把 GSC 裝起來，建議先回頭看過完整的 Google Search Console 教學手冊和5 個讓 SEO 效果翻倍的技巧，這篇談的是更窄、但被嚴重低估的一個環節：日期。

你是不是也被「過去 3 個月」這個預設值綁架了？

GSC 的數字永遠綁著一個時間戳，它是「某段時間內的真相」，拿掉那個範圍，數字就失去意義。同一個網站、同一組查詢，換一個日期範圍，結論可以完全相反。這不是 GSC 的 bug，這是所有時間序列資料的本質。我把幾個一定得先知道的前提列清楚，這些是看懂日期設定之前的基本功：

• 資料僅保留約 16 個月。GSC 的搜尋成效資料最遠僅能回溯到約 16 個月前，超過的部分會永久消失。這代表你做不了真正的「今年 vs 兩年前」年比，僅能做滾動式的近 16 個月比較。想把去年此時的表現留底，就得靠自己定期匯出。
• 預設視窗是過去 3 個月。這個預設值會把季節性、演算法更新、內容發布的影響全部糊成一團，是誤判的最大來源。多數人沒有意識到自己一直被這個預設值牽著走，每次開報表就直接讀那條線。
• 最新資料可能仍是初步值。GSC 已提供「24 小時」檢視，可查看最近的每小時初步資料；標示為初步的數字仍可能調整。做正式月報時，應使用已完整結束的日期區間，並留意介面上的資料更新時間。
• 單日數字會被進位。GSC 在聚合曝光與點擊時會做一些四捨五入，單日數字有小誤差，把區間拉長才會準。

換句話說，你看到的任何一個 GSC 數字，都綁著一個日期範圍。範圍錯了，數字再漂亮也可能誤導判斷。一項研究指出，多數受測網頁沒有取得可觀的 Google 自然搜尋流量（Ahrefs 的搜尋流量研究，2023 年 12 月）。這項研究不能用來判定單一頁面的價值，但能提醒我們：比較成長與衰退時，日期視窗必須和問題相符，避免長期平均掩蓋近期變化。

關鍵觀念：GSC 網址可能帶有目前的報表狀態

在 GSC 報表裡選好日期與部分篩選條件後，網址通常會跟著改變。因此，「日期快速設定器」可以從重複利用目前網址開始，不必先安裝外部工具。不過這是介面行為，不是 Google 對外承諾的穩定 API；重要流程仍要實際重開驗證。

在成效報表設好範圍後，可以觀察瀏覽器網址列。網址會包含 resource_id 這類資源識別資訊，也可能帶有日期或篩選狀態。把網址貼給有該資源權限的同事前，先用新分頁測試；接收者的權限、GSC 改版或部分未寫入網址的介面狀態，都可能讓畫面和原本不完全相同。

這個觀念其實和另一件 SEO 圈的事是同一回事。曾有人發現若在 Google 搜尋結果網址後面加上 num=100，就能讓一頁顯示一百筆結果，後來 Google 把這個參數拿掉，引發一陣討論。背後的道理完全一樣：查詢參數就是一份給機器看的設定清單，看懂了就能重複利用。如果你想從頭搞懂網址是怎麼組成的，可以看我寫的網址查詢參數和網址組成解析；那個 num=100 事件的來龍去脈，我也整理在num=100 參數停用的完整分析裡。

記住這個觀念，下面所有做法都僅是它的不同包裝而已。一旦你看懂「網址就是設定檔」，所謂的快速設定器就不再是黑魔法，而是一個你完全可以自己掌控的東西。

三種做法，選一個適合你的

知道網址帶著設定之後，要把它變成「一次點擊就到位」的工具，主要有三條路。三種做法的優缺點並排如下，你照自己的使用強度挑就好，不需要三個都做：

做法	原理	上手難度	適合誰	最大風險
書籤法	把設定好日期的 GSC 網址直接存成瀏覽器書籤	極低	管一個站、每天看一兩次的人	GSC 改版時舊網址格式可能短暫失效
書籤小工具（bookmarklet）	一段 JavaScript，點一下就在目前 GSC 分頁把日期改成你要的範圍	中	同時盯多個站、每天得切換好幾組區間的人	GSC 改版時腳本要跟著更新
瀏覽器擴充功能 / 第三方腳本	安裝現成套件，批次切換或跨站比對	中高	重度使用者、需要匯出與自動化的人	權限與資安，第三方可能讀到你的站內資料

如果是一個人管理單一網站，可以先試書籤法，設定成本低，也不必授權第三方擴充功能。需要跨多個資源頻繁切換時，再考慮書籤小工具。擴充功能適合確實需要批次匯出或跨站比對的使用者，安裝前務必檢查它要求的權限與資料處理方式。

5 分鐘做出你自己的日期書籤

這是我最推薦的起點，因為它透明、可複製、不依賴任何外部服務。整個流程像這樣，每一步都不要跳過：

1. 打開 GSC 成效報表，把日期選成你要的範圍，例如「過去 28 天」。
2. 等頁面完全載入，確認報表數字已經跟著更新。太早複製網址，可能會抓到還沒套用新範圍的舊狀態。
3. 把瀏覽器網址列裡那整串網址複製下來。
4. 在書籤列「新增書籤」，名稱寫「GSC 28天」或你自己看得懂的名字，網址貼上那串。
5. 為每一個你常用的區間，各重複一次，存成一整套書籤。

下面幾個區間可作為書籤起點。每個書籤存好後都要重新開啟，確認它代表的是滾動區間還是固定起訖日；若變成固定日期，日後就不會自動往前推移。

書籤名稱	日期範圍	用途
GSC 7天	過去 7 天	追蹤剛發布內容的即時反應
GSC 28天	過去 28 天	月度例行檢查的標準單位
GSC 3個月	過去 3 個月	與預設視窗對照，方便跟同事溝通
GSC 6個月	過去 6 個月	看中期趨勢，過濾掉短期雜訊
GSC 16個月	過去 16 個月	最長可用回溯，做年度季節性比對
GSC 比較	過去 28 天 vs 前 28 天	固定比較錨點，看環比變化

做完整套大約 5 到 10 分鐘。這 10 分鐘的投資，會在接下來每一個月替你省下幾十次手動點選的時間。老實說，這套書籤最脆弱的地方僅有一個：GSC 偶爾改版時，舊網址的格式可能失效。遇到這種情況，回報表重選一次、重新存書籤就好，前後不用 5 分鐘。比起依賴一個會偷偷讀你資料的擴充功能，我寧願靠這個笨但透明的做法。

書籤小工具的原理，以及為什麼它會壞掉

進階一點的人會想用書籤小工具（bookmarklet）。它的原理不複雜：你在書籤裡放的是一段以 javascript: 開頭的程式碼，跟一般書籤存網址的做法不同。點下書籤時，瀏覽器會在「你目前停留的那個 GSC 分頁」上執行這段程式碼，把日期參數改成你要的值，再讓頁面重新載入。換句話說，它的作用是就地修改你正在看的這個報表的設定，直接在你目前的位置換日期。

聽起來比書籤法強，但它依賴 GSC 前端的內部結構。Google 沒有保證日期參數格式會維持不變，今天能跑的 bookmarklet 在改版後可能失效。一般書籤也可能受網址格式或日期表示方式改動影響，僅是重建方式較簡單：回到報表重選範圍，再存一次並測試。

可以先用書籤法處理少量常用檢視；需要跨多個資源頻繁切換時，再評估 bookmarklet 或其他自動化。工具複雜度應和使用頻率、維護能力及權限風險匹配。

真的會讓我回頭打開 bookmarklet 的情境僅有一個：同時管理好幾個網域資源，而且要在它們之間快速套用同一組日期。書籤法在這裡會卡住，因為每個資源的網址開頭不同，你得為每個站各存一整套書籤，數量一多就會亂掉、還會記錯哪個書籤對哪個站。bookmarklet 不綁特定資源，它改的是「現在這個分頁」的日期參數，所以同一個按鈕可以套用在任何一個站上。如果你還沒走到這個情境，就別為它提早投資，先把書籤法吃透。

「日期範圍」會悄悄改變你看到的查詢清單

這是一個很多人沒注意、但會直接影響判斷的細節。GSC 成效報表的查詢清單不是無上限的。它在網頁介面上最多僅給你看一定數量的資料列（常被提到的上限是一千筆左右），而且這份清單的排序，會跟著你選的日期範圍變。

意思是：同一個網站，你用「過去 7 天」看到的「前 20 大查詢」，跟你用「過去 16 個月」看到的「前 20 大查詢」，很可能完全不一樣。短視窗會放大近期的爆發性查詢，長視窗會把長年穩定但單日量不大的查詢推上來。這沒有誰對誰錯，它們回答的是不同的問題：短視窗問「現在什麼正在發燒」，長視窗問「什麼是這個站長期的命脈」。

前述研究顯示，多數受測頁面沒有取得可觀的 Google 自然搜尋流量（Ahrefs 的搜尋流量研究，2023 年 12 月發布）。但這不表示低流量頁面都該刪除。日期視窗的用途，是把近期變化、長期趨勢與季節性分開看：僅看 3 個月，可能漏掉季節型查詢；僅看 7 天，也可能把短暫高峰誤判成長期主力。

如果需要的列數超過網頁介面的上限，就得改用 GSC 的匯出功能或 API，API 單次能拉回的資料量遠大於網頁。不過對大多數站長來說，網頁介面加上幾個常用視窗，已經足夠把最有價值的查詢抓出來。

平均排名這個數字，對日期範圍特別敏感

講一個容易被略過的陷阱：平均排名（average position）這個指標，會被日期範圍嚴重扭曲。GSC 的平均排名是「整個區間內所有曝光的加權平均」，所以它混合了高曝光日和低曝光日、第一名和第五十名。同樣是「平均排名 12」，可能是「每天都在第 12 名附近」，也可能是「一半時間排第 3、一半時間排第 30」。

這代表兩件事。第一，不要拿兩個長度不同的區間比平均排名，那是在比兩個不同分布的平均，沒有意義。第二，當你用比較模式看排名變化時，記得同時點開那個查詢的逐日資料看分布，別僅盯著平均數字往哪邊移動。一個「平均排名從 15 進步到 12」的結論，背後可能是少數幾天暴衝到第 1 名拉起來的，平常其實還是排得很後面。

日期範圍在這裡扮演的角色，就是決定這個「平均」涵蓋了哪些天。範圍越短，平均越能反映近期真實狀態；範圍越長，平均越平滑、也越容易藏住細節。這沒有標準答案，重點是你要知道自己現在用的是哪一種，並且在結論裡說清楚。

成效日期跟檢索日期，是兩件不同的事

一個非常常見的混淆，值得在這裡一次講清楚。GSC 成效報表裡的日期，指的是「使用者在 Google 搜尋時看到、並可能點擊你網站的那一天」；而你在網址檢查工具、網頁索引報表裡看到的「上次檢索時間」，指的是 Googlebot 上一次來抓這個頁面的時間。這兩個日期常常差好幾天甚至好幾週，而且它們之間沒有必然的先後關係。

這為什麼和日期設定有關？因為很多人會拿「上次檢索時間」去解釋成效數字的變化，例如「這個頁面三天前被重新檢索，所以昨天曝光暴增」。這個推論常常是錯的。檢索是 Google 讀取頁面內容的動作，曝光是搜尋結果被看見的動作，中間還隔著索引、排名計算、快取更新一連串步驟。一個頁面可能被檢索了但排名沒變，也可能完全沒被重新檢索，卻因為查詢量的季節變化而曝光大增。

所以當你在排查成效變化時，把這兩條線分開看。成效的問題用成效報表的日期視窗查，檢索與索引的問題用網址檢查工具和網頁索引報表查。把兩個不同性質的日期混在一起，是你越查越混亂的主要原因之一。記住：你在成效報表裡切換的那個日期，從來就不是「Google 上次來拜訪的日期」，而是「真實人類在搜尋結果上跟你相遇的日期」。

16 個月這道懸崖：你的歷史資料正在倒數消失

前面提過 GSC 僅保留約 16 個月的成效資料，這件事值得單獨拉出來講，因為它是一個會在你不知不覺中咬你一口的限制。今年的你，看不到前年的資料；明年的你，也看不到今年的資料，除非你現在就把它存下來。

這對季節型網站特別致命。想像你經營一個跟考試季、報稅季、節慶採購高度相關的站。你想回答「去年此時我的表現如何」，結果打開 GSC 才發現，去年那個月的資料已經被 16 個月的保留期吃掉了。你再也無法做精確的年比，僅能憑記憶猜。

解法很樸素，就是養成匯出留底的習慣。可以每月固定一天，把關鍵區間的查詢與頁面報表匯出成試算表，用日期當檔名存起來。資料量或自動化需求較高時，也可評估 Search Console 大量資料匯出到 BigQuery。這些留存資料，才能支援超過 GSC 介面保留期的比較。

留底要留得有用，關鍵在於檔名和結構一致。可用「資源名稱、報表類型、區間起訖」命名，例如「example.com、查詢、2026-05-01至2026-05-28」。要注意，介面匯出仍受資料列與匿名查詢等限制，不能稱為完整歷史全集；需要較完整且持續的資料時，應評估 API 或大量資料匯出。

比較模式，才是 GSC 最被低估的殺手級功能

很多人把日期設定器當成「切換視窗」的工具，卻沒發現 GSC 內建了一個更強的東西：比較兩個日期區間。它的重點是讓你同時看兩段時間的差異，比單純切換視窗更進一步，還會直接給你曝光、點擊的增減百分比，並把變化最大的查詢和頁面排到最前面。

固定歷史區間與滾動視窗回答的是不同問題。滾動視窗適合監測近期走勢；固定事件前後區間適合觀察改版或更新前後的差異。但單靠日期比較不能證明因果，也不能自動排除季節性，仍要對照去年同期、查詢需求與同期網站變更。

比較模式也可搭配裝置維度。全球網頁流量有相當比例來自行動裝置（Statista 的統計，截至 2026 年 4 月），但個別網站仍要看自己的資料。分開桌機與行動裝置，有助於發現總數持平時的內部分布變化。

國家與搜尋外觀（search appearance）也是一樣的道理。同一個比較區間，切到國家維度，你可能會發現整體持平的背後，是「台灣在掉、某個海外市場在長」。這類「維度乘以時間」的交叉分析，正是排名與曝光解讀的核心。想進一步理解曝光與排名的連動關係，可以參考我寫的搜尋曝光的真相。

交叉比對 GSC 與 GA4 時，日期要對齊

很多人會把 GSC 和 Google Analytics 併著看：GSC 告訴你「這個查詢在搜尋結果帶來多少曝光和點擊」，GA4 告訴你「這些人進站之後做了什麼、待了多久、有沒有轉換」。兩個工具合在一起，才能回答「流量進來之後到底有沒有用」這個問題。但這裡有一個超級常見的失誤：兩邊的日期視窗沒有對齊。

GSC 與 GA4 的預設視窗、時區與指標定義不同；GSC 最新的每小時資料還可能標示為初步值。如果一邊看過去 28 天、一邊看過去 30 天，日期差異就足以讓「搜尋點擊」和「進站工作階段」更難核對。即使日期完全一致，兩者仍不會因為口徑不同而一對一相等。

交叉比對前，先把兩邊手動設成同一個已完整結束的日期區間，例如「5 月 1 日到 5 月 28 日」，再記錄各自的時區與指標定義。GA4 的工作階段怎麼算、為什麼跟 GSC 的點擊對不起來，可以延伸閱讀Google Analytics 完整教學和GA4 工作階段解析。原則是對齊範圍與口徑，不是固定少看兩三天。

一張日期決策表：什麼時候用哪個視窗

講了這麼多，你可能還是會在打開報表的當下愣住：我這次到底該選哪個範圍？我把自己的判斷邏輯整理成一張決策表，照著走就好，不用每次重新想：

你想回答的問題	該用的視窗	為什麼
我新發的內容有沒有開始拿曝光？	過去 7 天，加頁面篩選	短視窗才看得到剛起步的微弱訊號
這個月的整體健康度如何？	過去 28 天	28 天是一個完整的週期單位，也避開週間波動
最近一次演算法更新對我有什麼影響？	比較模式：更新前後各一段等長區間	要看的是變化方向，不是絕對值
哪些查詢是這個站的長期命脈？	過去 16 個月	長視窗才會把穩定的長青查詢浮上來
某個頁面為什麼突然流量掉了？	比較模式：過去 28 天 vs 前 28 天，再切頁面	先定位是少數頁面還是全面性的問題
這是不是季節性衰退？	16 個月長視窗 + 去年同期匯出檔	必須有歷史留底才能判斷季節性

這張表的價值在於它逼你在動手看數字之前先想清楚自己到底要問什麼，完整與否倒是次要。多數錯誤的分析，不是出在數字算錯，而是出在「用錯視窗回答了另一個問題」。你可以把這張表印出來貼在螢幕旁邊，前幾次照表操課，等它內化成直覺之後再丟掉。重點在於養成「先定義問題、再選視窗」的習慣，記住配對反倒是次要。一旦這個習慣成型，日期快速設定器對你來說就不僅是一組書籤，而是一整套思考流程的入口。

六個常用的日期切換場景

工具做出來了、決策表也有了，接下來把常見場景寫出來。日期切換的目的，是回答一個具體問題：

1. 發布後 7 天追蹤。新文章上線之後，我會用「過去 7 天」加頁面篩選，看它有沒有開始拿到曝光。如果一周內完全沒有數字，通常代表收錄或索引出了狀況，這時候我會轉到網址檢查工具主動提交，或到網頁索引報表看是不是被擋掉了。
2. 演算法更新前後比對。每次 Google 推出核心更新，我會用比較模式，把「更新前一個月」和「更新後一個月」擺在一起看。重點放在哪些頁面被放大、哪些被壓縮，總曝光有沒有掉反倒是次要。一個站總曝光沒變、但前十名頁面換了一半，這比總數掉了 5% 更值得緊張。
3. 年同期比較。對季節型查詢，可比較今年與去年同期；若需要兩年以上資料，必須事先匯出或使用大量資料匯出留存。年比仍要留意活動日期、演算法與網站變更。
4. 季節性確認。用 16 個月長視窗把整個年度攤開來看，找出去年哪幾個月是高峰。知道高峰何時來，你就能提早兩三個月開始佈局內容，避免等高峰過了才後悔為什麼沒提早寫。
5. 流量下滑的第一時間排查。發現流量掉的當下，我會立刻切到「過去 28 天 vs 前 28 天」，先確認是全面性下滑、還是僅有少數頁面。如果是少數頁面，問題通常出在那幾個頁面本身；如果是全面性的，才需要往演算法或技術層面去找。完整的復原流程我整理在流量下滑怎麼辦那篇。
6. 內容去留的複查。用長視窗找出長期低曝光頁面，僅能建立複查名單。去留還要看導覽、客服、合規、轉換與外部連結用途，不能因零曝光直接刪除。規劃方式可參考年度內容更新。

這六個場景每一個都對應一個特定的書籤。這就是書籤法真正的價值：你不是在「操作工具」，而是在「回答問題」，每個書籤都是一個預先包好的問題，點一下就展開答案。

把固定區間餵進 Looker Studio，就不用再手動切

如果每天都在切同一組日期，還要把數字整理給團隊，可以考慮使用儀表板。把 GSC 接到 Looker Studio 後，日期範圍可做成下拉或預設控制項，讓團隊使用同一份報表。

把日期控制固定在儀表板層，可以統一比較基準，也方便分享同一個檢視。但 Looker Studio 本身不會替 GSC 封存超過保留期的歷史資料；要長期留存，仍須定期匯出，或使用 Search Console 大量資料匯出到 BigQuery。儀表板的設定方式可參考Looker Studio 儀表板實戰。

書籤適合個人快速開啟常用檢視，儀表板適合多人共用一致的報表定義。兩者都不是歷史資料庫；是否需要 BigQuery 或其他儲存方式，要看保留年限、資料量與維護能力。

四個最常見的日期設定錯誤

工具會用了、場景也清楚了，這一節整理四個常見錯誤：

錯誤	發生原因	正確做法
拿不同長度的區間互比	直覺上拿「過去 3 個月」和「過去 28 天」比	兩段區間長度要一致，比才公平
把初步資料當成定稿	忽略 GSC 的資料狀態與更新時間	正式比較使用已完整結束的日期；若看 24 小時檢視，要標明資料仍可能調整
僅看增幅、沒看基數	「曝光成長 200%」其實是從 10 變 30	同時看絕對值，小基數的漲幅別太當真
用 16 個月長視窗看「最近」變化	以為拉越長越準	近期變化用短視窗，季節性才用長視窗

這四個錯有一個共同的根：把日期範圍當成無關緊要的設定，沒有把它當成分析的前提來對待。一旦你開始把「我現在用哪個視窗」當成每次開口結論前要先交代的事，就像寫報告一定會寫「資料區間」一樣，這些錯就會自然消失大半。養成這個習慣，比記住任何一個技巧都重要。

今天就上手的日期工作流

觀念講完了，給你一份可以立刻執行的行動清單。不用一次做完，挑你現在最有感的開始就好，每一項都是十幾分鐘以內能完成的小動作：

1. 盤點你常用的日期區間。回想過去一個月你最常在 GSC 看哪些範圍，把那幾個寫下來。通常不會超過五個，這就是你書籤清單的初稿。
2. 把每個區間做成書籤。照上面的 5 分鐘流程，一個一個存。名稱寫清楚，未來的你會感謝現在的你。
3. 設一個固定的比較錨點。挑一個對你有意義的歷史區間（某次更新前、某次改版前），存成「比較」書籤，當作未來所有判斷的基準。
4. 建立月度檢查節奏。每月固定一天，用「過去 28 天 vs 前 28 天」走一遍主要頁面，把異常記下來。節奏比單次深度更重要。
5. 重要的區間匯出留底。若需要超過介面保留期的比較，可定期匯出試算表，或設定 Search Console 大量資料匯出到 BigQuery。

SEO 不是花錢，是存錢。你對自己網站過去表現的記憶越完整，未來做的每一個判斷就越準。日期設定看似是個小到不行的功能，但它決定了你看見的是真相還是錯覺。把這個小環節弄對，你接下來所有的 SEO 決策，都會站在更穩的地基上，不必再仰賴某一條被預設視窗扭曲過的曲線；而 GSC 在整個 SEO 工具堆疊裡的位置，可以進一步參考我整理的SEO 工具完整評比。

如果你看完發現，自己的網站連基本的 GSC 都還沒接好、或想被人帶著把整個日期與成效追蹤系統一次搭起來，Whoops SEO 有提供一對一的 SEO 顧問服務。無論你選擇自己動手還是找人陪跑，把日期這件事弄對，永遠是值得的第一步。