CMS移行で検索ビジビリティが22%低下、原因はcookieの同意フォームだった!?
この記事では、新しいコンテンツ管理システム(CMS)への移行後、検索トラフィック獲得が大幅に低下してしまった企業の事例を紹介する。
結果としてクッキー同意バナーのコンテンツが全ページでインデックスされていたことが原因だったのだが、なぜそのような事態に陥ったのか、そしてどのようにトラブルシュートして解決していったのかを解説しよう。
※Web担編注 タイトルを見て単純に「クッキー同意バナーがインデックスされるとSEOで問題がある」とは解釈しないでほしい。記事を最後まで読むとわかるが、この事例での問題の根源は少し特殊なクッキー同意バナーだ。
CMS乗り換えで検索トラフィック獲得が約22%失われた!
ドイツ有数の不動産テック企業である私たちHomedayのチームは2021年、新しいCMS(コンテンツ管理システム)への移行を決定した。移行の目的は、次のようなものだ:
- ページの読み込み速度を改善する
- 必要な機能を完備した最先端で、将来にわたって使い続けられるウェブサイトを作る
- コンテンツ編集者が開発者の助けを借りることなく、もっと自由にページを作成できるようにする
いくつかのCMSを評価した後、私たちは編集者と開発者の双方にとって優れた体験が得られる最新のテクノロジースタックを備えた「Contentful」を導入することにした。技術的な観点から言えば、Contentfulの特長は次の2点だ:
- ヘッドレスCMSである
- 採用したいフロントエンドの最新テクノロジーを使える
大きな負の影響を及ぼす問題のリスクを軽減するために、いくつかの段階に分けて移行を進めたのだが、結果として一気に移行してしまわなくて良かった。
というのも、最初の段階で、5日も経たないうちに検索トラフィック獲得の約22%が失われてしまった。
移行テスト段階
最初の移行テストで、トラフィックは多いがコンバージョン率が低いSEOページを10ページ選んだ。この10ページのレポーティングとモニタリングを行うために、次のインフラを構築した:
- 特に関連性の高いキーワードの検索順位の追跡
- SEOダッシュボード:
- DataStudio
- Moz Pro
- SEMRush
- Google Search Console
- Googleアナリティクス
- DeepCrawlを使った定期的なクロール
包括的な計画とテストの段階を経て、2021年12月にSEOの最初の10ページを新しいCMSに移行した。
テスト期間中にいくつか課題もあったが、大きな障害はなかったし、クリスマスの前に最初のテスト段階の移行を済ませたかったこともあって、移行プロセスをさらに進めていった。
最初のパフォーマンスレビュー
移行の第1段階を達成したことに大きな興奮を覚えつつ、翌日、移行したページのSEOパフォーマンスを確認した。その結果は、あまり喜ばしいものではなかった。
移行したページの追跡用キーワードの検索ビジビリティ※が、一晩で62.35%から53.59%に低下したからだ。1日で検索ビジビリティが8.76%も低下したことになる。
※Web担編注 この記事でいう「検索ビジビリティ」は「検索トラフィック獲得率」という意味でとらえてほしい。
Mozのツールが表示するSearch Visibilityを指しているようで、この指標は「そのツールに登録している追跡キーワードでの検索のうち、どれぐらいを自分のサイトが獲得しているか」を0%~100%で示すもの。主に順位をもとにした想定CTRから算出しているため、順位の影響が強く、検索ボリュームの多寡は関係ない。
つまり「検索ビジビリティが8.76%下がった」は「検索順位が下がったことで検索トラフィックが8.76%下がった」を意味する。
このように検索順位が大きく下がったことを受けて、次のような大規模テストを再度実施した:
- カバレッジやインデックス作成の問題かどうか
- すべてのmetaタグが含まれているかどうか
また次の項目もテストした:
- 構造化データ
- 内部リンク
- ページの読み込み速度
- モバイルでの使いやすさ
2回目のパフォーマンスレビュー
問題を特定するにはまず切り分けだ。
CMS移行後、私たちのサイトはGoogle検索に正しくインデックスされており、そのデータはCMS移行後の内容で間違いなかった。つまり、クロールとインデックスには問題ない。
移行のリスク要因である次のものは移行前後で変えていないため、検索ビジビリティ低下の原因から除外できた:
- URL
- コンテンツ
- メタタグ
- レイアウト など
追跡していたキーワードの検索ビジビリティは、その後の数日間でさらに40.60%にまで低下し、5日も経たないうちに合わせて22%近く低下した。これは追跡対象キーワードの競合相手との比較でも明確に示された。次に示すのは推定トラフィックのグラフだが、検索ビジビリティも同様の変化をしているように見えた。
移行に伴うリスク要因だけでなく、グーグルのアップデートもエラーの原因とは考えられなかったため、技術的な問題であることははっきりしていた。原因としては次のようなものが関係する可能性もあった:
- JavaScriptの多用
- Core Web Vitalsのスコアの低さ
- DOM※(Document Object Model)の肥大化や複雑化 など
※「DOM」は、ブラウザがHTMLを解釈しJavaScriptなどを実行したうえで構築した、ページの構造・内容・状態を表すブラウザ内部データのこと。
より詳細なトラブルシューティング
私たちは、できるだけ早く問題を特定して、すぐにバグを修正し、悪影響の拡大やトラフィックの減少を最小限に抑える必要があった。あるツールを使って調査したところ、CMS移行後に次のようなページが増えていたことがわかった:
- 外部向けリンクが多いページ
- コンテンツの分量が多いページ
技術的な原因と考えられるものについて、初めて有効な手がかりが得られた。
外部向けリンクが多い点については、いずれの外部向けリンクも信頼でき、ユーザーにとって関連性が高いものであることが重要だ。しかし、外部向けリンクの数が次の図のように急激に増えたのは何か問題がありそうだ(コンテンツは何も変えていないのだから)。
![](https://webtan.impress.co.jp/sites/default/files/images/blank.gif)
メインコンテンツの分量に関しても同様だ。コンテンツは何も変えずにCMS移行しただけなのに、なぜこういうことが起きるのだろうか。
![](https://webtan.impress.co.jp/sites/default/files/images/blank.gif)
どちらの指標も、移行したページ数から考えると異常に多くなった。これはなぜだろう?
クッキー同意バナーがインデックスされている!
次に、コンテンツを変えていないのに「外部向けリンクが多い」となったページで、どのような外部向けリンクがあるのかを確認した。すると、クッキー同意フォームからのリンクだと思われるURLばかりだった。
もしかして、移行したすべてのページについて、クッキー同意フォームをグーグルが読み取ってインデックス化しているのではないか!
グーグル検索で調べてみたところ、次に示すように、この見方が裏付けられた。
![](https://webtan.impress.co.jp/sites/default/files/images/blank.gif)
私たちが利用していたクッキー同意フォームは高度なもので、どんな情報をどう使うか詳細に記載しているものであり、同意フォーム内のテキストだけで30Kバイト以上あった(実物を見てもらうのがわかりやすい)。それにより、次のようなことが発生していたようだ:
- クッキー同意フォームがインデックス化されたことで、重複コンテンツが大量に生じた。
- ページのコンテンツサイズが大幅に増えた。メインコンテンツが膨大すぎるページは完全にインデックス化されない可能性がある。
- 外部を参照するリンクが大幅に増加した。
- SERPで突然、スニペットに日付が表示された。これはブログやニュース記事を示唆するものだが、Homedayのほとんどの記事はエバーグリーン(時間が経過しても役に立つ)コンテンツだ。また、日付が表示されたことで、meta descriptionが削除された。
しかし、なぜこのようなことが起こったのだろう? 当社のサービスプロバイダーCookiebotによると、検索エンジンのクローラーがウェブサイトにアクセスしてきたときは、完全な同意を得た状態だとみなす動作をするという。したがって、すべてのコンテンツにアクセスできるため、クッキー同意バナーに書かれている文章はインデックス化されないはずだ。
では、なぜ移行したページではそうならなかったのだろうか? 異なるユーザーエージェントでページをクロールしてレンダリングしてみても、ソースコードにCookiebotの痕跡を見つけることはできなかった。
グーグルのDOMを調査して、解決策を探す
移行したページは、「Contentful」と「プラグインの動的データ」でレンダリングされている。プラグインに含まれているのはJavaScriptのコードだけで、パートナーから提供されることもある。
こうしたプラグインの1つがクッキーを管理しているパートナーのもので、クッキー同意に関するHTMLをコードベースの外部から取得している。そもそもHTMLのソースファイルにクッキー同意に関するHTMLコードの痕跡が見つからなかったのは、これが理由だ。これより大きなDOMはあったが、元をたどるとJavaScriptフレームワークであるNuxtのデフォルトで、もっと複雑かつ大規模なDOMだった。
グーグルがクッキー同意バナーから文章を読み取っていることを検証するために、Google Search ConsoleのURL検査ツールを使用して、移行したページのDOMと移行していないページのDOMを比較した。その結果、移行したページのDOMの中にクッキー同意コンテンツが見つかった。
![](https://webtan.impress.co.jp/sites/default/files/images/blank.gif)
これ以外に目を引いたのが、次の違いだ:
- 古いページで読み込まれたJavaScriptファイル
- 移行したページで読み込まれたファイル
移行前のページで読み込んでいたクッキー同意バナー用のJavaScriptは1ファイルだけだった。しかし、移行後のページでは、それに加えて2つ目のクッキー同意バナー用JavaScriptを読み込んでいた。
調べてみると、移行後のページで追加で読み込んでいたJavaScriptは次のような状況で利用する特別なものだったらしい:
- クッキーに関する詳細情報をユーザーに表示したいページ
- クッキーのデータをインデックス化したいページ
2つ目のファイルは最初のファイルに必要な情報を含んでいるのだと勘違いしていたのだが、実際には1つ目のJavaScriptだけで良かったのだ。クッキー同意バナーの内容がレンダリングされてインデックス化されたのは、誤って読み込むように指定していたもう1つのJavaScriptファイルが原因だった。
そこでに、2つ目のJavaScriptを読み込まないようにするだけで解決すると判断した。
解決策を実行した後のパフォーマンスレビュー
2つ目のJavaScriptファイルを削除した日のキーワードの検索ビジビリティは41.70%で、移行前よりまだ21%低かった。
しかし、ファイルを削除した翌日には検索ビジビリティが50.77%に上昇し、その翌日には60.11%と、ほぼ元の状態に戻った。推定トラフィックも同じように変化した。よかった!
まとめ
多くのSEO担当者がこうした小さな問題に対処してきたことは想像がつく。
些細なことのようにも思えるが、移行中は検索ビジビリティとトラフィックが大幅に落ち込んだ。そのため移行作業は段階的に進め、移行の前後に技術的なエラーを調査するための時間を十分に確保することを推奨したい。
さらに、移行後の数週間はサイトのパフォーマンスを継続的によく観察することが重要だ。言うまでもなく、これらは今回の移行で私が得た重要な教訓である。
![用語集](/sites/all/modules/bancho/bancho_glossary/css/glossary-icon.gif)
ソーシャルもやってます!