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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/417736/4588a7e5-8249-d186-d446-5374de3efcf4.png)

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

## 原因

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

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

> Google はほとんどのサイトについて、主としてコンテンツの[モバイル バージョンをインデックスに登録](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing?hl=ja)します。そのため、Googlebot のクロール リクエストの大部分はモバイル クローラーを使用して行われ、一部がデスクトップ クローラーを使用して行われます。
[Googlebot とは | Google 検索セントラル  |  ドキュメント  |  Google for Developers](https://developers.google.com/search/docs/crawling-indexing/googlebot?hl=ja)

## 対策

==結論==

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

![image 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/417736/296c634e-95a4-dcfe-d911-a851156882db.png)

### `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](https://www.google.com/search?q=blogger+m%3D1+cdn&sca_esv=4c908fbc6c8bfb37&rlz=1C5CHFA_enJP995JP995&sxsrf=ACQVn086pEG2l0NuWwxHEWTV5mPwz3G2uw%3A1709945146863&ei=OrHrZaWNNNaa2roPoYy-kAw&ved=0ahUKEwilksGI-uWEAxVWjVYBHSGGD8IQ4dUDCBA&uact=5&oq=blogger+m%3D1+cdn&gs_lp=Egxnd3Mtd2l6LXNlcnAiD2Jsb2dnZXIgbT0xIGNkbjIIEAAYgAQYogQyCBAAGIAEGKIEMggQABiABBiiBEjUI1DUA1jMIXABeAGQAQCYAYMBoAHMA6oBAzAuNLgBA8gBAPgBAZgCBaAC3APCAgoQABhHGNYEGLADwgIEEAAYHsICBhAAGAgYHsICCBAAGIkFGKIEmAMAiAYBkAYBkgcDMS40oAe_BQ&sclient=gws-wiz-serp)
- 無料プランの範囲でユーザエージェント判定と、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](https://aws.amazon.com/jp/cloudfront/pricing/)

ということで、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ディストリビューションに設定したらサジェストに出てきた。
そりゃそうか良く出来ているなという感じ。