CloudfrontでBloggerのサーチコンソールインデックス登録エラーを対策する

on   in ,      0 件のコメント

サーチコンソールでインデックスをリクエストしたBloggerページがのきなみリダイレクト要因で登録エラーとなっているではないか。




この記事はCloudfrontを導入して対策するロードマップです。

原因


Bloggerはモバイルユーザーエージェントに対してはGETクエリm=1をつけてモバイル最適ページにリダイレクトさせるようだ。


そしてインデックス登録したURLにスマートフォン用 Googlebotがやってきてリダイレクトエラーに引っかかっるようだ。


Google はほとんどのサイトについて、主としてコンテンツのモバイル バージョンをインデックスに登録します。そのため、Googlebot のクロール リクエストの大部分はモバイル クローラーを使用して行われ、一部がデスクトップ クローラーを使用して行われます。

Googlebot とは | Google 検索セントラル  |  ドキュメント  |  Google for Developers


対策


結論


Cloudfrontのマネージドポリシーで解決した。



m=1付きでインデックスをリクエストする作戦

だめパターン


インスタントな対策としてはm=1付きのurlでインデックスリクエストする手があるが、ページのカノニカルURLとしてはm=1がついていないので下記のループが待っているため今後も仕様変更によって踊らされる可能性が高く恒久対策にはならない。


  1. いつかパソコン用 Googlebotがやってくる
  2. m=1無しでインデックスを更新する
  3. いつかスマートフォン用 Googlebotがやってくる
  4. リダイレクトエラーでインデックス解除する
  5. わい) m=1付きでリクエストする
  6. スマートフォン用 Googlebotがやってきてインデックス登録する → 1に戻る

CDNをかます作戦

本題


CDNを中継してスマホと思しきユーザーエージェントの場合、はなからm=1クエリを付記してコンテンツサーバー(Blogger)にリクエストしてリダイレクトを抑止する。


CDNを選定する


Cloudflare ※だめパターン

  • 検索すると真っ先にこの手のソリューションとして引っかかってくる🔎 blogger m=1 cdn
  • 無料プランの範囲でユーザエージェント判定と、urlのトランスフォームルールが組むことができる最有力なCDN

無料プランの限界


さっそくアカウントを作ってトライすると、


  • CloudflareはディストリドメインのDNSホストゾーンを預ける必要がある
  • いまのホストゾーンRoute53でレコードを組みまくっているし、突然知ったCloudflareを信用してないので渡せない、渡したくない
  • だったらブログホストのサブドメインを切り出してcloudflareのネームサーバーに委任しよう
    → Freeプランはルートドメイン(ネイキッドドメイン)しか登録させてもらえない

ということでCloudflareは却下。`Cloudflareをそもそも知っていたとしたら強力なソリューションであったので今後に活かしたい。


CloudFront

  • この手のソリューションとしてCloudfrontが検索で出て来ないが、lambda@EDGEでユーザーエージェントを判定してオリジンへのクエリコントロールを実装できる。
  • 常時無料利用枠が付帯する。

常時無料利用枠に含まれます

  • 1 か月あたり 1 TB のインターネットへのデータ転送
  • 1 か月あたり 10,000,000 件の HTTP または HTTPS リクエスト
  • 1 か月あたり 200 万件の CloudFront 関数呼び出し
  • 1 か月あたり 2,000,000 回の CloudFront KeyValueStore の読み取り
  • 無料の SSL 証明書
  • 制限なし、すべての機能が利用可能

料金 - Amazon CloudFront | AWS


ということで、CDNはCloudfrontで決定した。


Cloudfrontの設定


変更前


カスタムドメインのCNAMEをBloggerのカスタムドメイン用ホストghs.google.comに指定する


変更後


カスタムドメインのCNAMEをCloudfrontディストリビューションにして、オリジンにBloggerのカスタムドメイン用のホストghs.google.comを指定する


ロードマップ

  1. Cloudfrontディストリビューションを作成する
  2. 代替ドメインにBloggerのカスタムドメインを設定する
  3. ACMでバージニアリージョンのSSL証明書を発行してディストリビューションに紐づける
  4. オリジンにBloggerのカスタムドメイン用のホストを設定する
  5. キャッシュポリシーをノーキャッシュで設定
  6. オリジンリクエストポリシーにHostヘッダを指定する
  7. カスタムドメインのCNAMEをCloudfrontディストリビューションに変更する

以上でサーチコンソールのインデックス登録が成功した。



作業中の問題と対策

オリジンにBloggerのカスタムドメイン用のホストを指定する


カスタムドメインのCNAMEをCloudfrontディストリビューションに変更するため、ということはオリジンに何を指定するのか要領を得ず、デフォルトの {登録ホスト}.blogspot.comを指定したときに起こった問題。


まずカスタムドメイン設定した状態でデフォルトの{登録ホスト}.blogspot.comホストにリクエストするとhttps://{カスタムドメイン}に移動しました。的なページに誘導される。


ので、カスタムドメイン設定を解除してオリジンに {登録ホスト}.blogspot.comを指定すると直アクセスは繋がるが、ページに含まれるアセットやリンクのホストには{登録ホスト}.blogspot.com/~が適用されるため、リンクを踏むと{登録ホスト}.blogspot.comに移動しているという悲しい事態となった。


結論としては、Bloggerは元のカスタムドメインを設定したままで良くて、オリジンにはghs.google.comを指定する。


オリジンリクエストポリシーにHostヘッダを指定する


502 ERROR The request could not be satisfied.エラー画面で接続できない問題。


Cloudfrontはビューワーのリクエストヘッダをオリジンリクエストポリシーで明示的に指定しない限りオリジンに渡さない。


よって、オリジンリクエストポリシーが未設定だとHostヘッダを渡さないのでghs.google.comからカスタムドメインへの連携が出来ず
https://ghs.google.comでは証明書エラーだし、http://ghs.google.comは404だし、結果502 ERROR The request could not be satisfied.となる。


結論としては、オリジンリクエストポリシーにHostヘッダを設定することでBloggerサイトに疎通可能となる。


逆にUserAgentヘッダも指定しない限りは渡されないので、結果的にモバイルページリダイレクトは発生しなくなった。
そして、少なくとも私がBlogger使っているテーマで通常ページとモバイルページ(?m=1)をソース差分を確認した結果、何も差分がなかったのでlambda@EDGEの対応も不必要となった。


カスタムドメインのCNAMEをCloudfrontディストリビューションに変更する


Route53のAエイリアスレコードでCloudfrontのディストリビューシュンを指定しようとしたらサジェストに出てこない。


CNAMEレコードのFQDNに合致する代替ドメインをCloudfrontディストリビューションに設定したらサジェストに出てきた。
そりゃそうか良く出来ているなという感じ。

Share:

0 Comments:

コメントを投稿