サーチコンソールでインデックスをリクエストしたBloggerページがのきなみリダイレクト要因で登録エラーとなっているではないか。
この記事はCloudfrontを導入して対策するロードマップです。
原因
Bloggerはモバイルユーザーエージェントに対してはGETクエリm=1をつけてモバイル最適ページにリダイレクトさせるようだ。
そしてインデックス登録したURLにスマートフォン用 Googlebotがやってきてリダイレクトエラーに引っかかっるようだ。
Google はほとんどのサイトについて、主としてコンテンツのモバイル バージョンをインデックスに登録します。そのため、Googlebot のクロール リクエストの大部分はモバイル クローラーを使用して行われ、一部がデスクトップ クローラーを使用して行われます。
Googlebot とは | Google 検索セントラル | ドキュメント | Google for Developers
対策
==結論==
Cloudfrontのマネージドポリシーで解決した。
m=1付きでインデックスをリクエストする作戦
だめパターン
インスタントな対策としてはm=1付きのurlでインデックスリクエストする手があるが、ページのカノニカルURLとしてはm=1がついていないので下記のループが待っているため今後も仕様変更によって踊らされる可能性が高く恒久対策にはならない。
- いつか
パソコン用 Googlebotがやってくる -
m=1無しでインデックスを更新する - いつか
スマートフォン用 Googlebotがやってくる - リダイレクトエラーでインデックス解除する
- わい)
m=1付きでリクエストする -
スマートフォン用 Googlebotがやってきてインデックス登録する → 1に戻る
CDNをかます作戦
ここから本題
CDNを中継してスマホと思しきユーザーエージェントの場合、はなからm=1クエリを付記してコンテンツサーバー(Blogger)にリクエストしてリダイレクトを抑止する。
CDNを選定する
Cloudflare
- 検索すると真っ先にこの手のソリューションとして引っかかってくる🔎 blogger m=1 cdn
- 無料プランの範囲でユーザエージェント判定と、urlのトランスフォームルールが組むことができる最有力なCDN
無料プランの限界
さっそくアカウントを作ってトライすると、
- CloudflareはディストリドメインのDNSホストゾーンを預ける必要がある
- いまのホストゾーン
Route53でレコードを組みまくっているので渡したくない - だったらブログホストのサブドメインを切り出してcloudflareのネームサーバーに委任しようとしたら、Freeプランはルートドメイン(ネイキッドドメイン)しか登録させてもらえなかった
ということで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を指定する
ロードマップ
- Cloudfrontディストリビューションを作成する
- 代替ドメインにBloggerのカスタムドメインを設定する
- ACMでバージニアリージョンのSSL証明書を発行してディストリビューションに紐づける
- オリジンにBloggerのカスタムドメイン用のホストを設定する
- キャッシュポリシーをノーキャッシュで設定
- オリジンリクエストポリシーにHostヘッダを指定する
- カスタムドメインの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ディストリビューションに設定したらサジェストに出てきた。
そりゃそうか良く出来ているなという感じ。