Google Search Console 日期快速設定器
Google Search Console Performance 報表的日期區間與比對區間，可以透過一組標準 URL 參數直接寫死在連結裡。把 resource_id、start…
Google Search Console Performance 報表的日期區間與比對區間，可以透過一組標準 URL 參數直接寫死在連結裡。把 resource_id、start_date、end_date、compare_start_date、compare_end_date 這五個參數組進 base URL（https://search.google.com/search-console/performance/search-analytics），就能跳過日期選擇器，一次打開帶比對區間的報表。截至 2026 年 6 月，根據 Google Search Central 對 Performance 報表的說明，這條 URL 參數組合仍是 GSC 支援的開啟行為。
重點先看：把五個日期參數寫進連結就能跳過日期選擇器，比對區間天數必須跟主區間相同，否則 Delta 會被天數差污染。GSC 預設的近 28 天 vs 前 28 天是最穩的長期比對視窗。
如果你是那種每個月都要在 Google Search Console 的 Performance 報表手動點日期、做本月跟上月比較的人，大概很熟悉一種疲勞：明明只是要看曝光有沒有成長，卻得先點開日曆、選新區間、再點比對、再選舊區間，點一點按鈕還跑版，選到隔壁那欄。這裡教你先把「對的日期區間」一次生好、可以分享、可以重現。這是後續任何 SEO 分析 的前提工程，省下來的是每個月重複累積的點選成本。想看更多這類操作眉角，可以參考Google Search Console 實戰技巧。
為什麼 GSC 的日期選擇器這麼讓人疲倦
GSC 的日期選擇器卡在三件事。第一，它在你每次切換資源、切換頁籤、甚至縮放視窗時都可能位移，特別是在行動版與部分瀏覽器，點下去的常常是隔壁欄位。第二，比對區間得再手動點一次，而 GSC 預設不會幫你把舊區間天數對齊新區間。第三，這整套動作每個月、每個週報都要重來一次，累積下來的重複成本遠比你想像的高。
真正危險的不是點錯欄位，而是無聲的誤差。比對區間的天數若跟主區間不同，曝光和點擊的 Delta 會同時混入天數差和真實趨勢，你看到「衰退 8%」，可能只是因為舊區間多算了三天。這類誤差不會跳出警告，會直接被你寫進 SEO KPI 月報裡，一路傳到決策層。更麻煩的是，當一個被污染的數字進了月報，下個月的比對基期又會建立在這個錯的數字上，誤差會在每個月的報表裡疊加，直到有人回頭重算才發現前幾個月的判斷基礎是錯的。
可分享的帶參數連結能一次解掉兩個問題：不用每次重點、不容易點錯。一份帶好日期的 GSC 連結貼進月報，同事打開就是同一份區間設定，不會各自解讀。如果你還沒把 GSC 裝起來，先看Google Search Console 安裝教學把資源建好，再對照Google Search Console 完整指南把報表從頭到尾跑過一遍。
GSC 報表日期其實能寫進連結裡：URL 參數原理
答案是可以，而且早就支援。GSC Performance 報表的 base URL 是 https://search.google.com/search-console/performance/search-analytics，後面接 query string 就能指定要開哪個資源、哪段區間、要不要帶比對。把這組參數組進網址，點開直接是你要的報表畫面。
五個關鍵參數的意義如下。resource_id 指定要開的資源，需 URL 編碼；start_date 和 end_date 是主區間；compare_start_date 和 compare_end_date 成對出現時就啟用比對模式。日期格式是 YYYYMMDD，注意這個格式緊貼八位數字、沒有連字號，跟 ISO 8601 的 YYYY-MM-DD 完全不同，混用就會解析失敗。
| 參數 | 作用 | 格式／範例 |
|---|---|---|
resource_id | 指定開啟的資源 | 需 URL 編碼，如 sc-domain%3Aexample.com |
start_date | 主區間開始日 | YYYYMMDD，如 20260601 |
end_date | 主區間結束日 | YYYYMMDD，不可超過今天 |
compare_start_date | 比對區間開始日 | YYYYMMDD |
compare_end_date | 比對區間結束日 | YYYYMMDD，成對出現即啟用比對 |
有幾個地雷要留意。resource_id 裡的冒號和斜線在 URL 裡都要編碼，手動組網址時漏掉 encodeURIComponent 就會解析失敗。結束日若設成未來日期，GSC 沒有未來資料，報表會空白或截至今日。這也是為什麼很多教你查 Google 關鍵字搜尋量 或 自然曝光 的工具，背後都會做未來日攔截。報表區間搞定後，想確認頁面到底有沒有進索引，可以順著Google 網頁收錄查詢的步驟查一遍，再搭配Sitemap 提交實作教學把提交流程補齊。
一條完整 URL 長什麼樣子：逐段拆解
把參數湊成一條網址，結構是 base URL 接問號，再依序串參數，參數之間用 & 分隔。假設資源是網域資源 sc-domain:example.com，主區間是 2026 年 5 月整月，要比對 2026 年 4 月整月，整條連結會長這樣：https://search.google.com/search-console/performance/search-analytics?resource_id=sc-domain%3Aexample.com&start_date=20260501&end_date=20260531&compare_start_date=20260401&compare_end_date=20260430。這條連結貼進任何瀏覽器、只要有資源權限，打開就是同一份帶比對的報表。
逐段拆開看，resource_id=sc-domain%3Aexample.com 把冒號編碼成 %3A；start_date 與 end_date 圍出 5 月 1 日到 5 月 31 日共 31 天；compare_start_date 與 compare_end_date 圍出 4 月 1 日到 4 月 30 日共 30 天。這裡藏著一個經典的天數不對齊：5 月 31 天對上 4 月 30 天，曝光 Delta 會多背一天的份量。要排除這個污染，主區間改用 5 月 1 日到 5 月 30 日（30 天），比對區間維持 4 月 1 日到 4 月 30 日（30 天），兩邊都是 30 天，Delta 才乾淨。這正是工具自動回推比對結束日的核心價值，幫你把這種手算容易出錯的天數對齊一次處理掉。
六個最常用的 GSC 比對區間：本月 vs 上月到近 28 天
做月報或週報時，大多數人翻來覆去就是那六組比對。前三組看月度與年度趨勢，後兩組看短期波動。把它們的日期推算邏輯搞清楚，之後存成範本就能批次產連結。
| 比對組合 | 用途 | 新區間邏輯（原始碼推算） |
|---|---|---|
| 本月 vs 上月 | 追蹤當月成長動能 | 1 號至今日 vs 上月整月 |
| 上月 vs 前月 | 看上月表現對比再前一個月 | 上月整月 vs 前月整月 |
| 本月 vs 去年同月 | 抓季節性與年度成長 | 本月 vs 去年同月整月 |
| 上月 vs 去年同月 | 排除當月未滿的干擾 | 上月整月 vs 去年同月整月 |
| 近 7 天 vs 前 7 天 | 抓即時波動、演算法更新 | 昨日起回推 7 天 vs 再前一個 7 天 |
| 近 28 天 vs 前 28 天 | GSC 預設長期比對視窗 | 昨日起回推 28 天 vs 再前一個 28 天 |
偏好上是這樣取的：月報同時用「本月 vs 上月」和「近 28 天 vs 前 28 天」雙視角。前者看日曆月動能，後者排除月份天數差的干擾。28 天是 GSC 預設的長期比對視窗，接近一個完整月循環又不被 30 或 31 天的月份差污染。年度回顧才用「本月 vs 去年同月」，抓季節性最準。
有一個常被忽略的陷阱：本月還沒過完時，「本月 vs 上月」的新區間會只截到今天，天數少於上月整月。這時候 Delta 同樣會被天數差污染，建議這種情況改用「近 28 天 vs 前 28 天」會比較乾淨。如果你對 季節型與長青型關鍵字 的分類有興趣，年度比對特別能看出季節起伏。
六組比對的具體日期推算範例
把推算邏輯套到一個具體時間點會清楚很多。假設今天是 2026 年 6 月 15 日，GSC 資料有兩到三天的延遲（後面會講這個延遲怎麼影響短期視窗），六組比對的日期會落在：
| 比對組合 | 主區間 | 比對區間 |
|---|---|---|
| 本月 vs 上月 | 2026/06/01 至 2026/06/15 | 2026/05/01 至 2026/05/31 |
| 上月 vs 前月 | 2026/05/01 至 2026/05/31 | 2026/04/01 至 2026/04/30 |
| 本月 vs 去年同月 | 2026/06/01 至 2026/06/15 | 2025/06/01 至 2025/06/30 |
| 上月 vs 去年同月 | 2026/05/01 至 2026/05/31 | 2025/05/01 至 2025/05/31 |
| 近 7 天 vs 前 7 天 | 2026/06/08 至 2026/06/14 | 2026/06/01 至 2026/06/07 |
| 近 28 天 vs 前 28 天 | 2026/05/18 至 2026/06/14 | 2026/04/20 至 2026/05/17 |
從這張表可以看出兩件事。第一，「本月 vs 上月」在月中看，主區間 15 天對上比對區間 31 天，Delta 一定偏衰退，因為主區間少了一半天數，這就是為什麼月中看月報會嚇到自己。第二，「上月 vs 前月」是 31 天對 30 天，差一天，汙染較小但仍存在，要追求乾淨就改用整月等長或近 28 天視窗。實務上，月中做報表優先用「近 28 天 vs 前 28 天」，等月底資料補齊再回頭用「本月 vs 上月」收尾，這個順序能避開大部分天數差陷阱。
resource_id 的兩種格式：URL prefix 與 Domain property
resource_id 到底要貼什麼，是這個工具最容易出錯的地方。GSC 資源分兩種，格式完全不同，貼錯連結就會打開空白。最穩的判斷方式是打開 GSC，看左上角資源選擇器顯示的那串字，整串複製下來就對了。換網域時 resource_id 也要同步更新，否則連結打開還是舊資料。
| 資源類型 | 格式 | 正確範例 |
|---|---|---|
| 網址資源（URL prefix） | 開頭 https://，結尾 / | https://www.example.com/ |
| 網域資源（Domain property） | 以 sc-domain: 開頭 | sc-domain:example.com |
常見的錯誤格式有幾種。www.example.com 缺了 https:// 和結尾 /；https://www.example.com 結尾少了斜線；example.com 看起來像網域卻沒加 sc-domain: 前綴。這幾種都會讓產生的連結解析失敗。如果你搞不清楚兩種資源的差別，可以對照網域與網址的區分和網址組成結構先建立觀念。背後其實牽涉到www 與 non-www 網址的差異，這個選擇會一路影響到資源怎麼設、怎麼比對。
還有一點：resource_id 進到 URL 之後要做 URL 編碼。冒號會變 %3A，斜線會變 %2F。所以 sc-domain:example.com 在連結裡會長成 sc-domain%3Aexample.com，https://www.example.com/ 會長成 https%3A%2F%2Fwww.example.com%2F。手動組網址時漏掉這層編碼，是連結打不開第二大常見原因。這跟處理網址查詢參數的通用規則一致。如果你連網域都還沒申請，可以先從網域申請購買全攻略挑一個，主機與設定的前置作業也算同一條線。
兩種資源在資料涵蓋範圍上的實質差別
選哪種資源會直接決定連結打開後能看到多少資料。URL prefix 資源只涵蓋你填的那個協定加路徑，例如填 https://www.example.com/，就只看得到 https 加 www 開頭的網址，http://example.com 或 https://m.example.com 都不在這個資源裡。Domain property 走 DNS 驗證，涵蓋整個註冊網域含所有子網域與所有協定，example.com 之下不管 www、m、blog、http、https 全部算進來。
這個差別在做比對時影響很大。如果你的站同時有桌面版與行動版子網域，用 URL prefix 分別建資源，會看到兩份獨立報表，比對時只能各自比；用 Domain property 建一個資源，會把兩邊合進同一份報表，比對的是合計後的總量。現在全球超過一半的網站流量來自行動裝置，2026 年第一季行動裝置（不含平板）占全球網站流量約 52.27% [來源：Statista〈Share of mobile web traffic worldwide quarterly 2015-2026〉https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026-04-28]。在行動流量占比這麼高的環境下，桌面版與行動版的成效常常明顯不同，用 Domain property 合併看會稀釋掉兩邊各自的趨勢，這時候分開建 URL prefix 資源、用 URL 參數分別產連結，反而更能對出行動版單獨的衰退或成長。兩種資源不是誰優誰劣，要看你想看的顆粒度。
天數對齊：讓比對 Delta 只反映真實趨勢
比對區間天數不一樣，是 GSC 比對最常見的無聲誤差來源。假設主區間是 31 天的整月，比對區間只取了 28 天，Delta 會假性呈現衰退，但你分不清這 3 天的差距到底來自天數還是真實表況下滑。
背後的數學很直接。曝光 Delta 等於「天數差乘上日均」加上「真實趨勢」。當兩邊天數不同，這兩項被綁在一起，無法分離。工具的處理方式是根據主區間天數自動回推比對區間結束日：compare_end_date = compare_start_date + (主區間天數)，確保兩邊涵蓋的天數完全相同。這就是為什麼比對區間只需填開始日，結束日會自動算出來。
把這個公式套進實際數字會更具體。主區間是 2026 年 5 月 1 日到 5 月 28 日，跨度 28 天（含頭尾算 28 天的話，end - start = 27 天，這裡以 GSC 慣用的「天數」為準）。比對區間開始日填 2026 年 4 月 1 日，工具會把比對結束日算成 4 月 1 日往後推 28 天，落在 4 月 28 日，兩邊都是 28 天，Delta 只剩下真實趨勢這一項。如果你手動把比對結束日填成 4 月 30 日（為了湊整個 4 月），比對區間變 30 天，多出來的 2 天份量會被算進 Delta，一個日均 1000 曝光的站，這 2 天就憑空多出 2000 曝光的基期墊高，把衰退幅度壓低或把成長幅度墊高。數字看起來合理，其實是錯的。
跨月比對時尤其要小心 2 月、30 天或 31 天的月份。年度內容更新或做年度回顧時，建議用整月 vs 整月，而不是任意截 N 天對 N 天，才能排除月份天數差。Delta 要有意義，前提就是兩邊天數一致，這是任何 排名與曝光比較研究 的基本動作。
| 比對類型 | 天數對齊風險 | 建議做法 |
|---|---|---|
| 跨月（30 vs 31 天月份） | 差 1 天，污染小但累積可見 | 用整月 vs 整月，或改 28 天視窗 |
| 跨年含 2 月 | 閏年差 1 天，容易遺漏 | 把閏年算進去，兩邊天數核對一致 |
| 任意 N 天 vs N 天 | 人為誤差最大 | 改用公式自動回推比對結束日 |
什麼情況下不該用比對模式
比對模式不是萬用解，有幾種情境硬上比對反而誤導。第一種是網站剛上線、還沒有完整的前一個區間資料，例如新站只有 10 天資料，你硬比 28 天 vs 前 28 天，比對區間會整段空白，Delta 會顯示無意義的暴增。這種情況關掉比對，只看單一區間的絕對值與每日走勢即可。
第二種是網站經歷過大規模結構變動，例如重新命名網址、合併資源、換網域。前後兩個區間的資料可能分屬不同的 URL 結構，曝光的歸屬基準已經變了，把這兩段拿來比 Delta，等於拿蘋果比橘子，數字會跑但沒有可比性。這種情況要等結構穩定後，從新的穩定基期開始累積比對。
第三種是遇到 Google 演算法重大更新的當下，短期波動會被放大，這時候比 7 天 vs 前 7 天會看到劇烈跳動，但這個跳動是演算法重排的暫態，用來判斷長期成長方向會誤判。演算法更新期間建議拉長到 28 天 vs 前 28 天，等重排沉澱再讀數字。
三步驟用 GSC 日期產生器產出可分享連結
實際操作只要三步。第一步抓資源，第二步定新區間，第三步定舊區間，工具就把完整 URL 組好給你。每一步的細節拆開講，跟著做一次，下個月就只剩換開始日。
- 第一步：複製資源名稱。打開 GSC，看左上角資源選擇器，把整串字（含
https://結尾斜線或sc-domain:前綴）複製下來，貼進 resource 欄位。格式錯會即時跳出修正提示。 - 第二步：選預設或自訂新區間。點一組預設（如上月 vs 前月），或自己填開始日與結束日。結束日可手填，也可由預設帶入。
- 第三步：定比對區間。只需填比對開始日，結束日會根據主區間天數自動算出，確保兩邊天數一致。
三步填完，下方會出現一條完整 URL。點「開啟 Search Console」直接跳轉報表，或點「複製連結」貼到月報、Notion、Slack。同事打開就是同一份區間設定，不會各自解讀。產出來的連結可重現、可分享，這正是省去每個月重複手動比對的關鍵動作。如果你之後想把資料拉進儀表板，可以接著看用 Looker Studio 整合 GSC 與 GA。
如果你是第一次接觸 GSC 的核心功能，建議先跑過一次網址檢查工具和網頁索引報表，熟悉介面再來玩日期參數會順很多。GSC 在外部連結與關鍵字資料上有缺口，可以搭配 Screaming Frog、Ahrefs、Ranking 等工具補足；站若是 WordPress 架的，直接用 Site Kit by Google 把 GSC 串進後台，比手動產連結更省事。
比對決策矩陣：依目的選對視窗
面對六組比對，到底什麼時候該用哪一組，可以用兩個維度來決定。第一個維度是「關心的時間尺度」，分短期（週、雙週）與長期（月、季、年）。第二個維度是「要回答的問題類型」，分成「成長動能」（現在比過去快或慢）與「季節性／基期」（今年比去年同期）。把這兩個維度交叉，就能對到最適合的比對組合。
| 時間尺度 ＼ 問題類型 | 成長動能 | 季節性／基期 |
|---|---|---|
| 短期（週、雙週） | 近 7 天 vs 前 7 天 | 近 28 天 vs 去年同期 28 天（自訂） |
| 長期（月） | 本月 vs 上月、近 28 天 vs 前 28 天 | 本月 vs 去年同月、上月 vs 去年同月 |
這張矩陣的用法是先問自己要回答什麼，再挑視窗。例如這個月的月報要向主管交代「SEO 有沒有在成長」，落在「長期＋成長動能」這格，主選近 28 天 vs 前 28 天（天數對齊最乾淨），再用本月 vs 上月當輔助（看日曆月動能）。如果是年底要做年度回顧，要回答「今年比去年好還是差」，落在「長期＋季節性」這格，選本月 vs 去年同月或上月 vs 去年同月，把季節因素納進來才公平。如果是週一到週五的日常監控，要抓演算法更新或突發流量下滑，落在「短期＋成長動能」，近 7 天 vs 前 7 天最即時，但要把資料延遲算進去（下一節會講）。
評分卡：判斷一組比對適不適合你的站
不是每個站都適合同一組比對。要決定一組比對視窗值不值得寫進例行月報，可以用下面五個指標打分，每項給 0 到 2 分，總分 8 分以上才算值得長期追蹤。
| 指標 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 天數對齊 | 兩邊天數不同 | 差 1 天 | 完全相同 |
| 資料完整度 | 有段落在資料延遲內 | 邊界值 | 兩邊都已補齊 |
| 基期穩定 | 基期含結構變動 | 部分受影響 | 基期結構與現在一致 |
| 可比性 | 跨網域或跨資源 | 同資源不同 URL 結構 | 同資源同結構 |
| 樣本量 | 日均曝光極低 | 中等 | 夠大、波動可控 |
舉幾個情境套這張評分卡。一個剛改版完兩個月的站，要用本月 vs 上月，天數對齊給 2 分，但基期穩定只有 0 到 1 分（前段含改版前的舊結構），總分可能只有 6 分，這時候這組比對的 Delta 參考價值有限，不如等結構穩定滿三個月再開始正式比。一個流量穩定、運作三年的老站，近 28 天 vs 前 28 天五項幾乎都拿滿分，這組就值得每月固定跑。評分卡的好處是把「這份比對到底能不能信」從直覺變成可重複檢查的清單，團隊裡每個人用同一套標準，才不會各自憑感覺判讀數字。
以一個月自然曝光約 8,000 到 15,000、點擊約 600 到 1,200 的中型內容站為例，這類站常見的狀況是月度曝光波動本身就會落在約正負 6% 到 12% 之間，這個幅度已經逼近甚至超過天數不對齊造成的人為偏差。依這類站的典型表現幅度，套用評分卡時可以這樣取捨：月底資料補齊後跑「本月 vs 上月」（天數對齊 2 分、資料完整度 2 分、基期穩定若站齡滿半年以上給 2 分，合計約 8 到 9 分），Delta 可信；但月中臨時要看趨勢時，同一組會因為主區間天數不足、尾巴又卡在資料延遲區，資料完整度只剩 0 分，總分掉到約 4 到 5 分，這時改用「近 28 天 vs 前 28 天」就能把資料完整度拉回 2 分。常見的失誤是直接拿月中、未補齊的「本月 vs 上月」Delta 去跟主管交代衰退或成長，結果次月初資料補齊後數字反轉，前面下的判斷得整個收回。務實的決策角度是：同一份月報固定用兩組視窗交叉看，28 天對齊視窗當主軸、整月視窗當輔助，兩組方向一致才動資源，方向打架就先掛著等資料補齊，不要急著用單一組被污染的數字驅動行動。
資料延遲：GSC 兩到三天的資料空窗怎麼處理
GSC 的 Performance 資料不是即時的，通常會有兩到三天的延遲，今天看報表，最新資料大概只到兩到三天前。這個延遲對短期比對的殺傷力遠大於長期比對。做近 7 天 vs 前 7 天時，最近那 7 天的尾巴可能還沒補齊，Delta 會被低報，看起來像衰退，其實只是資料還沒進來。
處理資料延遲有幾個原則。第一，把「昨日起回推」這個邏輯改成「最近完整日起回推」，避開還沒補齊的那幾天，例如今天 6 月 15 日，最近完整日是 6 月 12 日，近 7 天就用 6 月 6 日到 6 月 12 日。第二，做週報固定挑每週三或週四，讓週一的資料有兩到三天沉澱時間。第三，月報固定在次月 5 號之後做，前一個月的資料才會完整，月初做月報看到衰退通常是資料沒補齊，不要急著下結論。
資料延遲也會影響「本月 vs 上月」在月中的可信度。月中做這組比對，主區間只到今天、尾巴又卡在延遲區，等於同時背了天數不足和資料不完整兩個問題，Delta 幾乎沒有參考價值。這也是月報建議等到次月初資料補齊再做的核心理由。把延遲納入流程設計，是讓比對數字真正可信的隱形前提。
常見錯誤與排除：連結打開空白、日期跑未來、比對消失
產出來的連結打不開或日期怪怪的，九成是幾類問題。逐一排查很快就能定位。
| 症狀 | 原因 | 排除方式 |
|---|---|---|
| 連結打開空白 | resource_id 格式錯（缺結尾 / 或缺 sc-domain:） | 回 GSC 左上角整串複製，重貼 resource 欄位 |
| 日期警告「超過今天」 | 結束日設到未來，GSC 沒有未來資料 | 截至今日或更早，工具會提示自動修正 |
| 比對欄位消失 | 比對開關被關閉，只剩單一區間 | 把比對開關打開，Delta 欄位就會回來 |
| URL 解析失敗 | 手動組網址時冒號、斜線未 URL 編碼 | 用工具產生，或補上 encodeURIComponent |
| 被擋在登入頁 | 分享對象沒有該資源權限 | 請對方先用有權限的帳號登入 GSC |
| Delta 異常衰退 | 比對區間天數少於主區間，或資料延遲未補齊 | 對齊兩邊天數，並避開延遲區 |
| 跨資源連到舊站 | 換網域後 resource_id 沒同步更新 | 重新複製新資源的 resource_id |
跨帳號權限是最容易被忽略的一項。你產的連結綁的是你的資源，分享給沒有該資源權限的人，對方打開只會看到登入頁或無權限提示。這跟分享GA4報表的道理一樣，權限沒開就是看不到。如果你常用 GA4 專有名詞 跟 GSC 交叉看，記得兩邊權限要分開授權。想系統性搞懂分析工具，可以從Google Analytics 完整教學入門，先把帳戶與資源階層釐清，再看GA4 工作階段的定義就不會混淆。
把 GSC 日期比對做成例行流程：月報與週報的自動化思路
把這個產生器嵌進每月或每週流程，才是真正省時間的地方。做法是建立一份連結範本表，列固定，每月報表日當天只換開始日那一欄，就能批次產出當月的六組比對連結。三種報表節奏對應不同的視窗選擇：週報用近 7 天 vs 前 7 天抓即時波動，但要記得把起算日退到最近完整日，避開資料延遲區；月報同時跑本月 vs 上月與近 28 天 vs 前 28 天雙視窗，一個看日曆月動能、一個排除天數差，兩者方向一致才動資源；年度回顧才動用本月 vs 去年同月，把季節性納進基期。固定在次月 5 號之後做月報，前一個月的資料才會完整，這個時間錨點比挑哪一組視窗更影響數字可信度。
連結範本表的欄位設計
一份能批次產連結的範本表，核心欄位不用多。第一欄放比對組合名稱（本月 vs 上月、近 28 天 vs 前 28 天等），第二欄放主區間開始日，第三欄放主區間結束日，第四欄放比對區間開始日，第五欄用公式串成完整 URL。公式裡把 resource_id、四個日期變數套進 base URL 的範本，每個月只要改第二到第四欄的日期，第五欄的 URL 自動更新。六組比對就是六列，整份月報的連結一次產好。
進階一點可以在範本表加上結論欄，每次看完報表把當月 Delta 與一句話判斷寫進去，例如「近 28 天曝光 +12%，主要來自 A 關鍵字」。累積下來，這份表就是一份逐月的 SEO 成長日誌，年底做回顧時直接翻這份表，不必回頭重算每個月的數字。這也是把一次性工具變成長期資產的關鍵設計。
搭配 Looker Studio Dashboard 串接 GSC 資料來源，可以把這些比對的結論拉進可視化儀表板做長期追蹤，不用每次手動開連結。如果想再往前一步，把 UTM 參數、GTM 和 GA4 的資料一起整合，就能在同一個面板上對照自然流量與付費流量的趨勢。實作時建議照著UTM 追蹤碼完整教學把五大參數設清楚，代碼部署則交給GTM 代碼管理工具統一管理，避免散落各處難追蹤。
這整套做法的本質，是把每個月重複的比對動作收斂成一份連結範本，時間從每個月點選十幾次縮成換一個日期欄位。對於追蹤 SEO 流量成長 的人來說，這個前提工程做好，後面的分析才不會建立在錯的區間上。一旦報表上看到流量掉了，下一步就是照著網站流量下滑的找回方法逐項排查；要評估該靠自然搜尋還是付費廣告補洞，可以參考SEO 與 Google Ads 的選擇。
為什麼每個月比對曝光變化這件事值得標準化？因為能從 Google 拿到自然流量的頁面其實少得驚人。Ahrefs 分析其 Content Explorer 索引中約 140 億個頁面後發現，96.55% 的頁面從 Google 拿不到任何自然流量，只有 1.94% 的頁面每月能拿到 1 到 10 次造訪 [來源：Ahrefs〈96.55% of Content Gets No Traffic From Google. Here's How to Be in the Other 3.45% [New Research for 2023]〉 https://ahrefs.com/blog/search-traffic-study/ 2023-12-01]。在絕大多數頁面都拿不到流量的現實下，準確追蹤少數有曝光的頁面是成長還是衰退，就是每個月用 GSC 比對區間在做的事，而區間對齊做錯，等於把這份判斷建立在污染過的數字上。Ahrefs 同一份研究也指出，反向連結是 Google 前三大排名因素之一，連入該頁的網站數量與該頁流量之間存在明確的正相關 [來源：Ahrefs〈96.55% of Content Gets No Traffic From Google (Tim Soulo)〉 https://ahrefs.com/blog/search-traffic-study/ 2023-12-01]。這意味著每個月比對曝光變化時，也要把連結成長納進背景脈絡，否則只看 GSC 的曝光數字會錯過真正的驅動原因。
報表區間處理好之後，分析通常會往需求端與內容端延伸。需求端先分清楚長尾關鍵字與關鍵字搜尋量在策略上的位置，需要實際數字時再交叉比對多個來源；內容端 GSC 只看得到表面成效，真正的判斷要看資訊增益、E-E-A-T 與 Entity SEO 這類品質訊號，技術上搭配結構化資料與 Canonical 處理，避免同一份內容被自己分散掉權重。連結與技術端則是另一組基本功：站內的內部連結、站外的反向連結、底層的網址結構與爬取預算，都會回頭影響 GSC 報表裡看到的曝光與排名。把日期區間這層前提工程做對，這些下游分析才有可靠的數字基礎。
進階技巧：把日期參數與維度篩選疊起來用
只寫日期參數的連結，打開的是整個資源的全域報表。但實際排查問題時，往往要先縮到某一個維度才看得清楚。GSC 報表在日期之外，還能透過點擊查詢、網頁、國家、裝置、搜尋類型這些維度來過濾。把維度篩選的動作跟日期參數結合，就能產出「針對某個關鍵字、某段區間、帶比對」的專屬連結，這對排查單一關鍵字的衰退特別有用。
實務流程是這樣的：先用日期參數連結打開帶比對的全域報表，確認整體趨勢後，在報表內點進「查詢」維度，找出 Delta 最異常的那幾個關鍵字，再把游標停在那個關鍵字上，GSC 會把這個查詢設成篩選條件，整份報表瞬間縮成只剩這個關鍵字的曝光、點擊、排名。這時候你看到的是「這個關鍵字在這段區間、相對前一個區間」的純淨 Delta，排除了其他關鍵字的拉扯。把這個縮好篩選的報表網址複製下來，就成了一條可分享、可重現的單關鍵字比對連結。
這個技巧在兩種情境特別有用。第一是某一個主力關鍵字的排名掉了，你想隔離出來看它到底掉了多少、是點擊率跌還是曝光跌，篩選後的 Delta 會給出單一關鍵字的乾淨數字，全域報表的雜訊全部濾掉。第二是季節性關鍵字，例如年節相關的詞，平時曝光極低，混在全域報表裡看不到，篩選出來才能對出它的季節起伏。想長期追蹤這類關鍵字，把這條篩選過的連結存進前面講的範本表，每個月開同一條連結，就是同一個關鍵字的逐月比對。這也是把 GSC 從「看大盤」推進到「管單品」的關鍵操作。
常見問題
GSC 的 resource_id 要填什麼格式？
兩種：網址資源填 https://www.example.com/（含協定、含結尾斜線），網域資源填 sc-domain:example.com。最穩的做法是從 GSC 左上角資源選擇器整串複製。
GSC 比對區間的天數不一樣會影響結果嗎？
會。天數不同時曝光 Delta 會混入天數差，無法判斷增減是來自天數還是表現。工具會用主區間天數自動回推比對結束日，確保兩邊天數一致。
GSC 產生的分享連結別人打開會一樣嗎？
區間設定會一樣，但前提是對方擁有該資源的檢視權限。沒有權限的人打開會被擋在登入頁或看到無權限提示。
GSC 的日期參數連結可以帶維度篩選嗎？
可以。先用日期參數連結打開帶比對的報表，再在報表內點進查詢、網頁、國家或裝置維度，把某一個項目設成篩選條件，報表縮成只剩該項目後，複製網址就是一條帶日期又帶維度篩選的連結，適合長期追蹤單一關鍵字或單一頁面的逐月比對。
什麼時候不該用比對模式？
三種情況建議關掉比對。網站剛上線、還沒有完整的前一個區間資料時；網站剛經歷大規模結構變動、前後兩段資料的 URL 結構不同時；以及遇到 Google 演算法重大更新的當下，短期波動是暫態，應該拉長到 28 天視窗等重排沉澱再讀數字。