案例研究：餅乾怪獸如何吃掉我們 22% 的能見度

去年，Homeday 的團隊 — 領先的物業之一德國的科技公司 — 決定遷移到新的內容管理系統 (CMS)。 除其他外，遷移的目標是提高頁面速度並創建一個具有所有必要功能的最先進、面向未來的網站。 遷移的主要動機之一是使內容編輯器能夠在沒有開發人員幫助的情況下更自由地創建頁面。

在評估了幾個 CMS 選項後，我們決定使用 Contentful 的現代技術堆棧，為編輯和開發人員提供卓越的體驗。 從技術角度來看，Contentful 作為一個無頭 CMS，允許我們選擇我們想要使用的渲染策略。

我們目前正在分幾個階段或多次進行遷移，以降低產生大規模負面影響的問題的風險。 在第一波中，我們遇到了 cookie 同意問題，導致在五天內可見度損失近 22%。 在本文中，我將描述我們在第一次遷移浪潮中面臨的問題以及我們如何解決這些問題。

設置第一個測試-wave

對於第一個測試波，我們選擇了 10 個流量高但轉化率低的 SEO 頁面。 我們建立了一個基礎設施來報告和監控這 10 個頁面：

• 最相關關鍵字的排名跟踪

• SEO 儀表板(DataStudio、Moz Pro、SEMRush、Search Console、Google Analytics)

• 常規爬網

經過全面的規劃和測試階段，我們在 12 月將前 10 個 SEO 頁面遷移到新的 CMS 2021. 儘管在測試階段遇到了一些挑戰(加載時間增加、HTML 文檔對像模型更大等)，但我們決定上線，因為我們沒有看到大的障礙，我們想在聖誕節前遷移第一個測試波。

第一次績效考核

對實現目標感到非常興奮遷移的第一步，我們在第二天查看了遷移頁面的性能。

接下來看到的東西真的讓我們很不高興。

一夜之間，被遷移頁面的跟踪關鍵字的可見度從 62.35% 下降到 53.59% — 我們在一天內失去了 8.76% 的能見度！

由於排名急劇下降，我們進行了另一輪廣泛的測試。 除其他事項外，我們還測試了覆蓋/索引問題，如果包含所有元標記、結構化數據、內部鏈接、頁面速度和移動友好性。

第二次績效評估

所有文章在遷移後都有緩存日期，內容已完全索引並被谷歌閱讀。 此外，我們可以排除幾個遷移風險因素(URL、內容、元標記、佈局等)作為錯誤來源，因為沒有任何變化。

在接下來的幾天裡，我們跟踪的關鍵字的可見度再次下降至 40.60%，在五天內總共下降了近 22%。 與跟踪關鍵字的競爭(此處為“估計流量”)相比，這也清楚地顯示出來，但可見性看起來相似。



由於其他遷移風險因素以及 Google 更新已被排除在錯誤來源之外，因此肯定必須成為技術問題。 過多的 JavaScript、較低的 Core Web Vitals 分數或更大、更複雜的文檔對像模型 (DOM) 都可能是潛在原因。 DOM 將頁面表示為對象和節點，因此 JavaScript 等編程語言可以與頁面交互並更改樣式、結構和內容。

跟踪 cookie 碎屑

我們必須盡快發現問題并快速修復錯誤並儘量減少更多負面影響和流量下降。 當我們的一個工具向我們顯示具有高外部鏈接的頁面數量以及具有最大內容大小的頁面數量增加時，我們終於得到了第一個真正的提示，即可能是技術原因的原因。 重要的是頁面不要超過最大內容大小，因為具有大量正文內容的頁面可能不會被完全索引。 關於高外部鏈接，重要的是所有外部鏈接都是值得信賴的並且與用戶相關。 外鏈的數量就這樣上升了，令人懷疑。





與我們的頁面數量相比，這兩個指標都高得不成比例遷移。 但是為什麼？

在檢查了哪些外部鏈接已添加到遷移的頁面後，我們看到 Google 正在讀取和索引 所有已遷移頁面的 cookie 同意書 。 我們進行了站點搜索，檢查了 cookie 同意的內容，並看到我們的理論得到了證實：



這導致了幾個問題：

1. )

   由於索引 cookie 同意書，為每個頁面創建了大量重複的內容。

2. 內容遷移頁面的大小急劇增加。 這是一個問題，因為具有大量正文內容的頁面可能無法完全編入索引。

3. 號碼外部傳出鏈接急劇增加。

4. 我們的片段突然在 SERP 上顯示了一個日期。 這將建議博客或新聞文章，而 Homeday 上的大多數文章都是常青內容。 此外，由於出現日期，元描述被切斷。

但是為什麼會這樣呢？ 根據我們的服務提供商 Cookiebot 的說法，搜索引擎爬蟲訪問網站時會模擬完全同意。 因此，他們可以訪問所有內容，並且 cookie 同意橫幅的副本不會被爬蟲索引。

那麼為什麼遷移的頁面不是這樣呢？ 我們用不同的用戶代理爬取並渲染了頁面，但仍然無法在源代碼中找到 Cookiebot 的踪跡。

調查 Google DOM 並尋找解決方案

遷移的頁面使用來自 Contentful 和插件的動態數據呈現。 這些插件只包含 JavaScript 代碼，有時它們來自合作夥伴。 其中一個插件是 cookie 管理器合作夥伴，它從我們的代碼庫外部獲取 cookie 同意 HTML。 這就是為什麼我們一開始沒有在 HTML 源文件中找到 cookie 同意 HTML 代碼的踪跡。 我們確實看到了更大的 DOM，但可以追溯到 Nuxt 的默認、更複雜、更大的 DOM。 Nuxt 是我們使用的 JavaScript 框架。

為了驗證 Google 是否從 cookie 同意橫幅中讀取副本，我們使用了 Google 搜索的 URL 檢查工具安慰。 我們將遷移頁面的 DOM 與未遷移頁面的 DOM 進行了比較。 在一個遷移頁面的 DOM 中，我們終於找到了 cookie 同意內容：



其他引起我們注意的是舊頁面上加載的 JavaScript 文件與我們加載的文件遷移的頁面。 我們的網站有兩個用於 cookie 同意橫幅的腳本，由第 3 方提供：一個用於顯示橫幅並獲取同意 (uc)，另一個用於導入橫幅內容 (cd)。

• 我們舊頁面上加載的唯一腳本是uc.js，負責

  cookie 同意橫幅。 這是我們在每個頁面中都需要一個腳本來處理用戶同意。 它顯示 cookie 同意橫幅而不索引內容並保存用戶的決定(如果他們同意或不同意使用 cookie)。

  • 對於遷移的頁面，除了uc.js，還有一個cd.js 文件加載。 如果我們有一個頁面，我們想向用戶顯示有關我們的 cookie 的更多信息並索引 cookie 數據，那麼我們必須使用 cd.js。 我們認為這兩個文件相互依賴，這是不正確的。 uc.js 可以單獨運行。 cd.js 文件是 cookie 橫幅的內容被渲染和索引的原因。

  找了好久，因為我們認為第二個文件只是第一個文件的先決條件。 我們確定簡單地刪除加載的 cd.js 文件就是解決方案。

  實施解決方案後的性能評估

  我們刪除文件的那天，我們的關鍵字可見度為 41.70%，比遷移前還低 21%。

  但是，在刪除文件後的第二天，我們的可見度就提高到了 50.77%，第二天幾乎恢復正常，為 60.11%。 估計的流量表現類似。 終於解脫了！

  結論

  我可以想像很多 SEO 都處理過這樣的小問題。 這似乎微不足道，但導致遷移過程中的可見性和流量顯著下降。 這就是為什麼我建議分波遷移，並預留足夠的時間來調查遷移前後的技術錯誤。 此外，在遷移後的幾週內密切關注站點的性能至關重要。 這些絕對是我從這次遷移浪潮中的主要收穫。 我們剛剛在 2022 年 5 月初完成了第二次遷移浪潮，我可以說到目前為止沒有出現重大錯誤。 我們將再進行兩波，希望在 2022 年 6 月底前成功完成遷移。

  遷移頁面的性能現在幾乎恢復正常，我們將繼續下一波。

關於漢娜·阿道夫 —

是 Homeday 的 SEO 和內容營銷團隊負責人。