演算法更新記錄
每次更新的日期與站點反應
演算法更新紀錄像航海日誌對照氣象紀錄——船速掉了，先查那天有沒有風暴，才知道是船的問題還是天的問題。
03為什麼是現在學
流量波動的第一個排除項就是「Google 又更新了」。沒有對照紀錄，每次波動都從零開始猜；有紀錄，五分鐘完成初步歸因。
04白話理解（對客戶簡報可直接引用）
維護一張兩欄時間軸：Google 官方更新（核心更新、垃圾更新的起訖日）×自家大事（改版、大量發文、換模板）。流量異動時先對這張表：跟更新重疊→看受影響的是哪類頁面、對照官方說明方向；跟自家動作重疊→回滾或深查那次改動。
05工具箱
- ▸Google 搜尋狀態資訊主頁（官方更新時間表） — 唯一權威來源
- ▸自家變更日誌（部署/內容大事記） — 跟 log 文化同一件事
06怎麼做 · SOP 2 步（每步標產出物）
- 1建立雙軌時間軸並回填過去一年→ 更新對照表
- 2每次官方更新起訖都記錄自家曲線反應→ 更新反應紀錄
07場景應用（實戰經驗）
- ◆核心更新期間流量掉 15%——對照發現受災集中在「薄標籤頁」，方向明確：這是品質面的訊號，處方是內容淘汰（c22）而不是技術修補。
08⚠️ 常見誤區
- ✕更新期間急著大改——官方明講更新期間波動正常，改動反而汙染歸因；等更新結束再評估。
口訣
「先查天氣，再修船。」
10里程碑 · 完成標準（可驗證）
- ☐對照表持續維護
- ☐每次更新有反應紀錄
學習者勾自己的進度；顧問勾客戶專案的交付——同一份標準，兩種用法。
12檢核方式與依據出處
半自動：程式抓資料或客戶填表，再由系統／顧問判讀。
- 🟢 官方明文Google 搜尋狀態資訊主頁（更新清單） ↗
依據等級決定計分權重（🟢×3／🔵×2／⚠️×1）——權重量的是「依據有多硬」， 不是「我們覺得多重要」。查無權威文件的判準，誠實標「業界慣例」。