2026 年 8 月 Google演算法更新（Spam Update）：被打的到底是什麼

2026 年 8 月 Google演算法更新（Spam Update）：被打的到底是什麼

太長不看版： 官方時程是 2026-08-18 16:27 UTC 開始、08-21 08:49 UTC 完成，全球全語言——不是社群普遍轉述的 8/17，這一天之差會改變你對自家流量圖的判讀。被打的不是「用了 AI」，是「大量產生沒有人在搜的頁」。我們把自有的 20 個 Search Console 資產在推出前後各拉一次：沒有一個站被清空，合計曝光 20,537 → 26,469（+28.9%），主站持平在 −0.0%；而窗口比看起來掉最慘的兩個站，逐日拉開來看是更新開跑前三到七天就開始掉。如果你真的踩到了，處理順序是 410 優先於 noindex，恢復期預估 2–4 個月。

官方到底公告了什麼

先把一手來源攤開。Google Search Status Dashboard 的事件紀錄（incidents.json，我們在 2026-09-09 直接拉的）寫的是：

人可讀的版本在 Google Search Status Dashboard 的 Ranking 歷史頁↗，政策本體在 Spam policies for Google web search↗，更新類型的說明頁是 Google Search spam updates↗。

這裡有一個值得停下來的細節：業界普遍寫成「8/17 起」，我們自己的內部情報筆記一開始也是這樣記的。但官方 JSON 的 begin 是 8/18 16:27 UTC，換算台北時間是 8 月 19 日凌晨 00:27。

一天的差別聽起來很小，實際上決定了你會不會誤判：如果你的站是 8 月 15 日開始掉的，那不是這次更新——推出的時候它已經在掉了。這種歸因錯誤的代價是你會去修錯的東西。

社群回報了什麼（以下全部是從業者說法，未經我們驗證）

以下四個案例來自 r/SEO 的 August 2026 Spam Update 討論串↗、GPWA 的同主題討論↗，以及 4,500 頁那一串↗。這幾個站台對自動化抓取回 403，我們是以瀏覽器讀取後轉述的，沒有辦法用第三方資料交叉驗證這些人的流量數字，所以請把它們當成「有人這樣說」而不是「事實如此」。

一、買競品過期域名做 301。 有人買下競品的過期域名，把它 301 到自己的產品頁，被判 expired domain abuse。這是 Google 垃圾內容政策裡明文列出的類型，不是灰色地帶。

二、10 萬頁的資訊站腰斬。 該站約 7 萬頁在索引，回報流量腰斬。無人工處置通知、無技術故障。

三、4,500 頁一天上線，歸零一個月。 一個營養資料庫，五種語言、4,500 頁，同一天全部上線。回報是：先爆量一週，接著歸零約一個月，而且連原本表現正常的舊頁一起死。這一點是整件事最值得記住的地方——罰的是站，不是那批頁。

四、反例：純資料庫站被重新評估後 20 倍。 一個 Leica 鏡頭的資料庫站，在這一波之後回報流量成長約 20 倍。同樣是「資料庫型」內容，一個死一個活。

第四個案例才是解題的鑰匙：如果被打的是「資料庫型內容」，那第四個站不該活。所以被打的一定是別的東西。

那把尺：「這一頁有人在搜嗎」

Google 的 John Mueller 在 Bluesky 上針對程式化 SEO 的說法（社群轉述串↗），大意是這類頁面「常導向 spam、邊緣 spam 或低品質」，而系統會因此對整站失去信心，要解決需要時間與大量努力去證明價值。

把這句話跟四個案例對起來，那把尺其實很簡單：這一頁有沒有人在搜。

• 「倫敦到巴黎機票」——有人搜，這頁該存在。
• 5,000 個城市兩兩配對產生 2,500 萬頁——其中絕大多數的組合一年沒有一個人搜，這些頁不該存在。

第三個案例的營養資料庫，資料是真的、完整度是夠的。但資料完整度不算分。Google 問的問題不是「你的資料齊不齊」，而是「為什麼是你這一頁，而不是另外 50 個抄同一份公開資料庫的站」。

這也解釋了第四個案例為什麼活下來：Leica 鏡頭的規格資料庫，每一支鏡頭都真的有人在搜，而且那個資料在別的地方不好找。同樣是資料庫，一個回答了「為什麼是你」，一個沒有。

延伸閱讀：Google 自己的 Creating helpful, reliable, people-first content↗ 就是這把尺的官方版本，值得把裡面的自問清單真的跑一遍。

這次不是 anti-AI，是 anti-empty

那一串討論裡最好的一句判讀是：這次不是 anti-AI，是 anti-empty。

Google 對 AI 生成內容的官方立場從 2023 年就沒變過，Using generative AI content↗ 講得很直白：怎麼產生的不是重點，內容有沒有用才是。這次更新的行為完全符合那份文件——它把權重重新分配給「有理由存在」的頁面。

一個頁面要「有理由存在」，最低限度是三樣東西裡至少有一樣：一個主張、一個來源、一個數字。三樣都沒有的頁面，不管是人寫的還是模型寫的，都是同一種東西。

我們自己的稿件驗收就是照這個標準做的：每一篇上線前跑一次自動 gate，其中最常卡住的一條就是「外部權威來源少於三個網域」。這不是形式主義——一篇沒有外部來源的文章，通常也就沒有主張。

我們自己的橫斷面：20 個站，推出前後各拉一次

上面全部是別人的數字。這一段是我們自己的。

方法：我們手上有 26 個 Search Console property，扣掉客戶資產（客戶的流量不是我們可以拿出來寫文章的東西）與一個重複 property，剩 20 個自有站。每個站拉三個窗口的曝光，都是週一到週日，避開工作日與週末的自然週期差：

• 推出前：2026-08-10 → 08-16
• 推出期間：2026-08-18 → 08-24
• 完成之後：2026-08-22 → 08-28

站名不公開（其中幾個是還在養的資產），但每個站的原始數字都存在我們的檔案裡。

先講一個資料陷阱

redclawey.com 在 Search Console 裡同時有 sc-domain 與 URL-prefix 兩個 property，而 sc-domain 那個的資料只從 2026-08-22 開始——那天才驗證。第一次跑的時候我們就是用它，拿到「0 → 4,362 曝光」這種漂亮但完全假的數字。

**同一個站有多個 property 時，先確認資料起始日再選。**不然你會寫出一篇建立在 API 空值上的分析。

結果

三件事：

1. 沒有一個站被清空。 合計曝光是往上的。
2. 主站完全持平：11,118 → 11,114。逐日看是在 1,159 到 1,907 之間震盪，就是平常的波幅。
3. 站 K 的 +4990% 不能當戰績——基期只有 30 曝光，那是雜訊放大。

逐日拉開之後，故事變了

這才是重點。我們把 07-27 到 09-05 的逐日曝光拉出來，兩個窗口的百分比講的故事跟逐日講的不一樣：

掉最多的兩個站，跌勢都早於 8/18：

• 站 J（−95.5%）：08-10 到 08-14 每天是 29 / 29 / 33 / 34 / 37，08-15 掉到 12、08-16 掉到 5。更新 8/18 才開始推。之後也沒回來，09-05 只剩 2。
• 站 I（−54.0%）：08-10 是 95，08-11 就掉到 49，一路走低。同樣早於 8/18。

如果我們只比兩個窗口，這兩個站會被寫成「本次更新的災情」。逐日一拉，它們跟這次更新沒有時間上的關係。（站 J 是我們印度線的資產，那條線的衰退從 7 月就開始了，那是另一個故事。）

在推出期間或完成隔天出現階梯式上升的有三個：

• 站 C：08-18 是 211，08-19 跳到 355 並維持——落在推出窗口內。
• 站 B：08-21 是 232，08-22 跳到 348，之後持續爬。完成隔天。
• 站 K：08-21 是 4，08-22 跳到 128，之後穩定在 130–300。同樣是完成隔天。

還有一個要自己戳破的：站 A 的窗口比是 +50.6%，看起來像受益者。但逐日看，它是 08-16 就從 166 跳到 690——比推出早兩天。我們不能把它算進這次更新的帳。

漲上來的曝光是從哪裡來的：既有頁，不是新頁

兩個出現階梯的站，我們再往下拉一層，把推出前與完成後兩個窗口的逐頁曝光對起來看。如果這次更新是在「獎勵新內容」，那漲幅應該來自新上榜的頁；如果是在「重新分配權重」，那漲幅會集中在本來就有曝光的頁上。

兩個站都是同一個形狀：**漲幅絕大部分來自本來就在排的頁面往上走，而不是新頁進榜。**站 B 有一篇既有的指南頁從 234 曝光變成 497，另一篇從 8 變成 237——那不是新內容被發現，那是同一批頁被重新評價。

這跟「重量重分配給有理由存在的頁」的判讀是一致的，也是為什麼我們不建議在被打之後急著大量發新頁：如果系統正在重新評價你既有的頁，你該做的是讓既有的頁值得被評價，不是再丟一批新的進去讓它評。

這份數據能證明什麼、不能證明什麼

不能證明因果。 這是曝光不是排名，我們沒有對照組，20 個站的內容型態與上線時間都不同。三個站在 08-19 和 08-22 出現階梯，時間吻合，就只能寫成「時間吻合」。

能說明的是形狀。 我們這 20 個站有大量 AI 輔助產出的內容，如果這次更新真的是在打「AI 寫的東西」，我們應該一片紅。實際上是往上的。這跟「anti-empty 而非 anti-AI」的判讀一致。

如果你真的踩到了：挖坑的順序

以下是社群那一串裡票數最高的處理建議，我們把它整理成執行順序。這一段我們沒有第一手經驗可以背書——我們沒有被打到，所以沒有恢復的實測數據。當作一份待驗證的清單來讀。

1. 先確認你掉的那天，跟 8/18–8/21 有沒有時間關係。 這就是本文第一段那個日期為什麼重要。掉在 8/15 的站，修 scaled content 是修錯東西。

2. 盤點：程式化頁 vs 有搜尋需求的頁。 把站上的頁分成兩堆。判準只有一個：這個 query 一年有沒有人搜。用 Search Console 的實際曝光資料判，不要用工具估值。

3. 多餘的頁用 410，不是 noindex。 noindex 需要 Google 重新爬過每一頁才讀得到標籤——4,500 頁就是 4,500 次重爬，而你正處在爬取預算被縮的狀態。410 Gone 是直接告訴它這頁沒了。兩者的差別在 Google 的 HTTP status codes 說明↗ 裡講得很清楚。

4. 301 只准同站同題。 把 A 主題的頁 301 到 B 主題的頁，本身就是被政策點名的操作。跨站的更不用說——第一個案例就是這麼死的。

5. 恢復期繼續發真內容。 社群的說法是要讓 Google 看到這個站還有脈搏。這一點無法驗證，但成本低。

6. 乾淨之後，每月放回 50 頁以內。 需求優先、帶自家角度。一次全放回去等於重演一次。

7. 預期 2–4 個月，而且通常要等下一次 core update。 Spam update 的恢復不會在下週發生。

電商變體頁怎麼辦

有一種站會很緊張：電商的變體頁（顏色、尺寸、規格組合），本質上就是程式化生成的大量相似頁。

判準沒有變，但答案不同：變體頁通常真的有人搜（「iPhone 16 Pro 沙漠色」是有量的），所以它不屬於「沒人搜的頁」。真正該處理的是組合爆炸的那一層——三個維度交叉出來的、沒有人會這樣搜的長尾組合。

處理方式是聚合頁 + canonical：把沒有搜尋量的組合 canonical 到有量的父頁，接受那一層長尾流失。這件事的細節可以看 Google 的 canonical 說明↗，我們也在 結構化資料指南 裡寫過商品頁的 schema 該怎麼配。

你現在該做的三件事

1. 開 Search Console，把你的站拉 2026-08-10 → 08-16 對 2026-08-22 → 08-28。然後一定要再拉一次逐日——窗口比會騙你。
2. 如果真的掉了，先確認起跌日跟 8/18 的關係，再決定要不要動內容。
3. 如果沒掉，把這次當成一次免費的體檢：站上有多少頁是「沒有人搜、只是因為能生成所以生成」的？那些頁在下一次更新之前處理掉，成本比事後低得多。

我們把整套稽核流程寫在 SEO 作業系統 裡；索引控制的部分在 robots.txt 與索引控制指南，sitemap 的部分在 sitemap 完整指南。如果你要的是有人直接幫你把這件事做完，那是我們的 iGaming SEO 建站與代營運服務。

常見問題

這次更新的官方時間到底是什麼時候？

2026-08-18 16:27 UTC 開始、2026-08-21 08:49 UTC 完成，全球所有語言。台北時間是 8 月 19 日凌晨到 8 月 21 日下午。業界普遍寫的「8/17」與官方紀錄不符。

我的站在 8 月中掉了，是這次更新嗎？

先看起跌日。8/18 之前就開始掉的，跟這次更新沒有時間關係——我們自己有兩個站就是這種情況，一個從 8/15、一個從 8/11 開始掉。歸因錯了會讓你去修錯的東西。

用 AI 寫文章會被這次更新打嗎？

單純用 AI 不會。Google 的官方立場是產生方式不是判準。被打的是「大量產生沒有人在搜的頁」，這件事人工也做得出來。我們自有的 20 個站有大量 AI 輔助內容，這次合計曝光是 +28.9%。

被打之後應該用 noindex 還是 410？

410。noindex 要 Google 重爬每一頁才讀得到，而你此時的爬取預算正在被縮。410 是直接告訴它這頁沒了。

多久會恢復？

社群的共識是 2–4 個月，而且通常要等到下一次 core update 才會重新評估。這一點我們沒有第一手數據可以背書，因為我們的站沒有被打到。

電商的商品變體頁會被判嗎？

會不會被判，看的是「有沒有人搜這一頁」。有搜尋量的變體頁不屬於這次的目標；沒有人會這樣搜的多維度交叉組合才是。把後者 canonical 到父頁，接受長尾流失。

---

了解我們的廣告策略與投放服務 →