Ahrefsのドメインレーティングは23から6に落ちました。その数字は無視できませんでした。とはいえ、それは説明ではありません。

この違いが調査の方針を決めました。第三者のスコアは、モデルのどこかが変わったことを示せます。しかし、どの技術的判断がその変化を引き起こしたのか、あるいは同様の動きが検索パフォーマンスにも現れているのかまでは分かりません。だから私たちは、下落を「サイトを点検するための合図」として扱い、判決として受け止めませんでした。

点検の結果、ルートURLの根本に実際の問題が見つかりました。既存の言語選好がない訪問者に対して、同じURLが、リクエストの発地点に応じて異なるロケールパスへ一時的にリダイレクトされてしまっていたのです。この挙動は、検索エンジンに理解させたかった恒久的なロケール構造と整合していませんでした。

私たちはこれを修正しました。ただし、それでも「このリダイレクトのせいでドメインレーティングが落ちた」と、正直に断言はできません。

スコアが実際に教えてくれること

Ahrefsはドメインレーティングを、0〜100のスケールで示すWebサイトの被リンクプロファイルに関する相対指標として定義しています。算出は、ドメインにリンクしているサイトや、Ahrefsのより広いインデックスに依存します。そのため、まったく同じ割合で被リンクを失っていなくても、スコアが動くことがあります。

Ahrefsはまた、ドメインレーティングはGoogleのランキング要因ではないと述べています。被リンクプロファイルを比較したり変化に気づいたりするのには役立ちますが、「Googleがページをどう評価して順位付けしているか」を直接測るものではありません。

そこで私たちが把握できた事実は、次の2つだけでした。

  1. スコアが23から6へ落ちた。
  2. ルートのリダイレクト挙動は修正される必要があった。

これらの事実は同時に存在していました。どちらがもう一方を引き起こしたかは、そのタイミングだけでは証明できません。

One root request reaches different locale destinations

ルートURLは何をしていたのか

旧ミドルウェアは、ロケール選好がすでにリクエストに入っていない場合、リクエスト国からロケールを選択していました。そして、非ローカライズされたパス(たとえばルートURL)を、そのロケールへ302レスポンスでリダイレクトしていました。

簡略化すると、関連する挙動は次のような形でした。

const country = request.cf?.country
  || request.headers.get('CF-IPCountry')
  || 'US'

const targetLocale = LOCALE_MAP[country] || 'en'

return new Response(null, {
  status: 302,
  headers: { Location: `/${targetLocale}/` },
})

コードは「親切」のつもりでした。ドイツの訪問者はドイツのロケールへ、アメリカの訪問者は英語へ送る、という考えです。

しかし問題はクロ―ラ側の前提条件でした。あるソースURLに対して、安定した行き先が1つに定まりませんでした。レスポンスはロケーションに依存し、リダイレクトは「移動は一時的」と伝えていました。

これは重要です。Googleは、恒久と一時のリダイレクトを異なる形で扱います。Googleのリダイレクトガイダンスでは、301や308のような恒久的リダイレクトは「ターゲットがカノニカルになるべき」という強いシグナルだとしています。一方で、302や307のような一時的リダイレクトでは、一般にソースが検索結果上のカノニカルURLのままになります。

一時的リダイレクトは、本当に一時的な変更である場合に有効です。サイトに恒久的なロケール階層があるのに、デフォルトで一時リダイレクトを使うのは不適切です。決定的なカノニカルとなる入口が必要なのです。

ロケーション依存のルーティングがリスクだった理由

同じルートURLを、異なるロケーションから2つのクローラがリクエストしている状況を想像してください。片方は/en/へのリダイレクトを受け取ります。もう片方は/de/へのリダイレクトを受け取ります。いずれもレスポンスは一時的です。

どちらのレスポンスにも、サイトが望むルート先の「安定した物語」は書かれていません。その挙動は、外部ツールがどこからいつクロールするかによって、異なるチェーンとして記録されてしまうこともあります。

ただし、これが直ちに権威を壊すわけではありません。302はペナルティではありません。検索エンジンは、ステータスコードだけでなくリダイレクトを解釈できます。問題は、私たちの実装が1つのレスポンスに3つの関心事を混ぜてしまっていた点です。

  • サイトの恒久的な構造
  • 訪問者の見込み言語
  • 訪問者が保存している選好

これらは別々に扱うべきです。カノニカルのルートは安定しているべきです。パーソナライズは、明示的な選好があるとき、または安定したページが読み込まれた後にのみ行うべきです。

決定的な修正

修正したミドルウェアは、新規リクエストと、保存されたロケール選択を持つ戻り訪問者を分けて扱います。

Cookieなしのリクエストが非ローカライズされたパスに来た場合、サーバーは英語パスへ恒久的な301リダイレクトを返すようにしました。行き先は国に関係なく同じです。

https://zenovay.com/  ->  https://zenovay.com/en/

一方で、すでにロケール選好Cookieを持つ訪問者に対しては、ミドルウェアは一時的なリダイレクトでその個人の選択を引き続き尊重できます。これは「サイトのカノニカル構造に関する主張」ではなく、ユーザー固有のレスポンスです。

Several uncertain paths resolve into one canonical route

これは小さなコード変更ですが、有用な性質があります。クローラとクリーンなブラウザの両方が、予測可能な最初のホップを見えるようになりました。私たちは通常のリクエスト、Googlebotのリクエスト、異なる言語ヘッダーでライブのルートレスポンスを検証しました。それぞれが同じ英語URLへの301を返していました。

この修正は、ローカライズされたページを削除する必要を生みません。すべてのロケールにはそれぞれ独自のURLがあります。言語セレクターや保存された選好も、引き続き訪問者へ提供されます。変更したのは、デフォルトの入口パスを決定的にしただけです。

結論できること、できないこと

旧ルートリダイレクトが技術的な欠陥だったことは結論できます。恒久的なサイト構造なのに、一時ステータスを使っており、さらにリクエストのロケーションによって行き先が変わってしまうものでした。現在の挙動は、クローラ、外部の監査ツール、人間にとって理解しやすくなっています。

ただし、その欠陥がAhrefsのスコア変化すべての原因だったとまでは結論できません。リダイレクトを、Ahrefsのインデックス変化、被リンクグラフ、参照ドメイン、その他のサイト要因から切り離して評価するための管理された実験がありません。

また、データが裏づける前に「回復した」と主張することもできません。修正の公開は観察の始まりであって、物語の終わりではありません。

責任あるアプローチは、変更日を記録し、複数のシグナルを分けて見守ることです。

  • それに紐づくドメインレーティングと、その背後の参照ドメイン
  • 新規に発見された被リンクと失われた被リンク
  • 第一者の検索データに基づく検索の表示回数とクリック
  • ルートおよびロケールページのインデックス状況とカノニカル選択
  • クリーンなリクエストから時間経過とともに見えるリダイレクトレスポンス

これらのシグナルが、修正後に一緒に改善していくなら、証拠はより興味深いものになります。それでも、解釈には慎重さが必要です。

実践的なリダイレクト監査

この種の問題を見つけるのに、大規模なSEOプラットフォームは必須ではありません。まずはHTTPレスポンスそのものから始めてください。

  1. CookieなしでルートURLをリクエストし、ステータスとLocationヘッダーを記録する。
  2. 別の言語ヘッダーを使って再度リクエストし、可能なら別地域からも実行する。
  3. 恒久的な公開ルートが、1つの決定的な行き先を持っていることを確認する。
  4. チェーンをたどり、余計なホップやループがない状態で終わることを確認する。
  5. 最終ページのカノニカルと代替言語リンクを確認する。
  6. 明示的なロケール選好を持つ「戻り訪問者」を別途テストする。
  7. 結果とデプロイ日を保存し、後の指標変化に文脈を与える。

Four checkpoints along a redirect audit path

コマンドラインでの有用な確認は、あえて退屈なやり方がいいです。

curl -I https://example.com/

その後は、入力を1つだけずつ変えてください。Accept-Languageヘッダーを追加します。クリーンなCookie jarを使います。そしてリクエストを別の地域から実行します。公開URLが単一のカノニカル行き先を持つべきだとしたら、最初のホップが地理ガチャになるべきではありません。

より広い教訓

指標の下落は、すぐにストーリーを作りたくなる圧力を生みます。早いストーリーは、しばしば「技術的観察」が裏づけのない因果主張に変わる場所です。

より良い順序は、遅くても価値のあるものになります。

  1. その指標が何を測っているかを確認する。
  2. システムの具体的な欠陥を点検する。
  3. 欠陥だから修正する。
  4. 影響に関する仮説から、検証済みの挙動を切り分ける。
  5. 変更後に一次指標と第三者指標の両方を観察する。

今回のドメインレーティングの下落が、実在するリダイレクト問題へ私たちを導きました。その問題を正しく直したことで、サイトは安定したカノニカルの入口パスを持てるようになりました。これがスコアの動きを説明できるかどうかは、いまも未解決の問いです。その問いを「確実だ」と作り話で埋めるより、未解決のままにしておくほうが私たちはよいと考えています。

私たちが信頼するのは、こういうデバッグ記録です。コードについては正確で、因果関係については慎重で、次に測るべきことが明確です。

Sources