1. Google AI Overviews 引用品牌 listicle，卻有 69% 反而推薦競爭對手
新聞概述
Lily Ray 針對 80 組 B2B「best [category] software」查詢進行分析，發現 AI Overviews 共引用品牌自吹 listicle 323 次，其中 224 次（69%）引用了該品牌頁面後，實際推薦的卻是競爭對手產品，Forbes、Reddit、YouTube 為被推薦最多的來源。
資訊來源
- Search Engine Land：Google AI Overviews cite self-serving listicles but recommend competitors，Search Engine Land，2026 年 6 月 18 日
資訊可信度
中高。Lily Ray 為業界公認的 SEO 研究者，方法論（80 組查詢、人工計數引用次數）可供檢查，但樣本侷限於 B2B SaaS 類別，尚未在其他垂直市場驗證，結論不宜直接推論至所有產業。
事實重點
- 分析範圍：80 組 B2B「best [category] software」查詢，資料收集日為 2026 年 6 月。
- 品牌自吹 listicle 被 AI Overviews 引用共 323 次。
- 323 次中有 224 次（69%）引用了品牌頁面，但最終推薦的是競爭對手。
- AI Overviews 推薦最多的外部來源依序為 Forbes、Reddit、YouTube。
資訊判讀
這揭示了 GEO 的核心矛盾：AI Overviews 的合成邏輯並非「誰被引用就推薦誰」，而是從多方來源交叉比對後輸出結論，品牌自製的「自家最好」listicle 雖有助於被爬取，卻可能成為 AI 引用自家頁面、卻推薦他人的踏板。對 B2B 行銷人員而言，靠內部 listicle 主導 AI 引用的策略風險已被量化，中立第三方媒體的影響力遠高於品牌自媒體。
建議行動
- 針對核心 B2B 查詢（例如「best [你的類別] software」），實際執行一次 AI Overviews 測試，確認最終推薦的是自家還是競品，建立基準資料後每月追蹤。
- 將 GEO 資源轉向協助 Forbes、G2、Reddit 相關版位產出客觀且有利於自家品牌的評測內容，而非擴充品牌自推 listicle。
- 自有 listicle 確保 Organization、Product、Review schema 完整標記，即便短期無法改變推薦結果，仍可維持被引用的機會與頁面權威度。
2. Fractl 調查：AI 搜尋「有幫助」比率一年從 82% 跌至 54%，使用量卻同步上升 70%
新聞概述
Fractl Q2 2026 調查訪問 1,008 名美國消費者，認為 AI 搜尋比傳統搜尋「更有幫助」的比率從 2025 年的 82% 降至 54%，持懷疑態度者從 3% 升至 17%，但實際使用量同期卻上升約 70%，研究者將主因歸於幻覺（hallucination）不斷侵蝕使用者信任。
資訊來源
- Search Engine Land：AI search adoption rises, consumer trust declines，Search Engine Land，2026 年 6 月 17 日
資訊可信度
中。Fractl 為行銷研究公司，樣本規模（n=1,008）屬正規市調水準，但問卷原文與完整方法論未完整公開，「更有幫助」的比較基準定義仍有詮釋空間，數字需保留一定彈性。
事實重點
- 調查對象：1,008 名美國消費者，調查時間為 Q2 2026。
- 認為 AI 搜尋「更有幫助」的比率：82%（2025 年）→ 54%（2026 年 Q2），下降 28 個百分點。
- 認為 AI 搜尋幫助較少的「懷疑論者」比率：3% → 17%，增幅約 5 倍。
- AI 搜尋實際使用量同期上升約 70%。
- 信任下滑主因被研究者歸因於幻覺負面體驗的累積。
資訊判讀
「使用量升、信任降」並存，反映 AI 搜尋已從嘗鮮期進入習慣但不完全信賴的成熟期。這對 GEO 策略的意義是：內容在 AI 引用後仍需能通過使用者的主動查核，準確性與可驗證性比關鍵字密度更重要；品牌若長期被 AI 以幻覺方式錯誤描述，信任流失的速度可能超過曝光帶來的收益，且難以量化。
建議行動
- 定期用 ChatGPT、Perplexity、Bing Copilot 搜尋自家品牌名稱及核心產品，檢查 AI 回答是否出現幻覺性錯誤描述（如錯誤定價、功能描述失真），並向各平台提交回饋或修正公開來源。
- 在官網建立或強化「品牌事實清單」頁面（About、產品規格、FAQ），搭配 Organization schema 與 FAQPage schema，提供 AI 爬取時有明確、可驗證答案可引用的結構化事實。
3. Google 遷站指南更新：Change of Address 工具須對所有子網域變體個別提交與驗證
新聞概述
Google 於 2026 年 6 月 17 日更新 Search Central 網站搬家文件，正式明定進行網域遷移時，須針對舊網域的每一個子網域及 www / non-www 變體，分別在 Search Console 完成驗證並各自提交 Change of Address 請求，漏提交的子網域將導致搬家訊號不完整。
資訊來源
- Google Search Central：Site move with URL changes，Google，2026 年 6 月 17 日文件更新
- Search Engine Land：For site moves, specify all domain variants with Google’s Change of Address tool，Search Engine Land，2026 年 6 月 18 日
資訊可信度
高。來源為 Google Search Central 官方文件直接更新，可在該頁版本歷史（changelog）確認修訂內容。
事實重點
- Google Search Central 網站搬家指南於 2026 年 6 月 17 日正式更新。
- 遷移時須涵蓋舊網域的所有子網域（如 blog.example.com、shop.example.com）及 www / non-www 兩種變體。
- 每個子網域變體都必須先在 Google Search Console 完成驗證，才能成功提交各自的 Change of Address 請求。
- 若部分子網域遺漏提交，Google 收到的搬家訊號可能不完整，影響新網域的索引速度與排名轉移效率。
資訊判讀
此更新補強了過去文件未明確要求的技術細節，實務上許多網域遷移僅對主網域提交 Change of Address，子網域（如 blog.、shop.、m.）被遺漏的情況相當常見。在此更新之後，漏提交子網域將更難以被視為「可接受的省略」，對有多個子網域的大型電商或媒體網站影響尤為顯著，遷移前期規劃需要完整盤點所有已索引的子網域。
建議行動
- 若有近期或計劃中的網域遷移，使用 Search Console 的涵蓋範圍報告或 site:舊網域 搜尋算子，確認舊網域下有哪些子網域已被 Google 索引，逐一列出清單。
- 遷移前，在 Search Console 將所有子網域（含 www / non-www 各變體）加入並完成 HTML 標籤或 DNS 驗證；遷移後，每個子網域各自進入「設定 → Change of Address」提交請求。
- 若過去已完成遷移但只提交了主網域，可補提交遺漏子網域的 Change of Address 請求，有助於加速殘留舊 URL 的轉移與舊索引的清退。
