Studio向けのAレコードやCNAMEを外す手順は？
Studio向けのAレコードは、移管先の公開準備が終わってから、移管先が指定する値へ書き換えます。先に消してしまうと、書き換えるまでの間はサイトが表示されません。ちなみに見出しには CNAME もありますが、StudioはCNAMEレコードに非対応です。wwwをCNAMEで向けたつもりでも、実際に効いているのはAレコードのほうでしょう。
作業の順番は次のとおりです。
- 移管の少なくとも1週間前に、DNSのTTL（設定を覚えておく時間）を数時間ほどへ下げる
- 移管先の仮のURLで、ページ・画像・フォーム・PDFなどのダウンロードを確認する
- Aレコードを、移管先が指定するレコード種別と値へ書き換える
- 旧環境へのアクセスが無くなってから、Studioの公開パネルでドメイン左側の［×］を押して接続を解除する
TTLを下げる時期は、URLを変えない移転の案内で示されている目安です。Studio側の必須条件ではなく、下げたからといってすぐに切り替わるわけでもありません。
また、仮のURLで確認する間は、そのサイトを noindex にして検索結果に出ないようにしておきます。DNS設定を変更した後は、Googlebotを含むアクセスが新しいサーバーへ正常に届いているかを観察します。Studioでの接続解除はドメインを切り離す操作で、DNSの書き換えとは別です。
Studio利用時に削除したAAAAレコードは移管先で戻す必要がありますか？
Studioへの移行時に削除したAAAAレコードを、移管先で必ず復元しなければいけないのか迷うところです。以前使っていた設定値を機械的に戻す必要はなく、移行先となるサーバーのIPv6対応方針に合わせて設定を判断します。
StudioではAAAAレコードは不要とされ、残っているとTLS証明書の発行に失敗する原因になっていました。つまり、移管先へ移る際も、以前の古い設定値をそのまま登録し直せばよいわけではありません。
移行先でAAAAレコードが必要になるかは、新しいインフラ側の案内で決まります。たとえばGitHub Pagesを利用する場合は指定のIPv6アドレスを登録するよう求められますし、Cloudflareのプロキシ環境を利用する場合はIPv6 compatibility機能によって必要な応答が自動生成されます。ただし、ホスティング提携経由の設定や partial setup の頂点ドメインは、この自動生成の対象外です。
気をつけたいのは、昔のAAAA値をメモから復元してしまうことです。IPv4とは別のサーバーを指すAAAAレコードが残ると、IPv6経由のドメイン確認が通らず、証明書の発行が止まることがあります。移管先の設定画面やヘルプにIPv6アドレスが載っていればその値を入れ、載っていなければ空のままにしておくのが手堅いですね。
wwwあり・なしの転送は移管先でどう設定し直せばいいですか？
Studioの画面内で行っていた転送設定と、一般的なWebサーバーでの設定とでは、ホスト名を統一する仕組みが異なります。Studioでは管理画面の設定で正規URLをどちらか一方に揃えられましたが、移管先ではサーバーの転送ルールやDNS側のサービスを使って自前で整える必要があります。
有料プランの独自ドメイン接続プロジェクトを対象に提供されているStudioのwwwリダイレクト機能では、正規URLをwww付き・なしのどちらかに固定したまま、もう一方のアクセスを自動で正規側へ転送していました。この転送はStudioのホスティング環境が担っていたため、DNSを移管先へ向けるとStudio側の転送機能は動かなくなります。移管先では、この転送をHTTPのリダイレクト（301）として設定します。DNSのレコードを書き換えるだけでは、wwwありからwwwなしへ人を送ることはできません。Cloudflareのリダイレクトルールなら、Request URL をwww付きのアドレス全体に当てはまるワイルドカード、Target URL をそのワイルドカード部分を引き継いだwwwなしのアドレスにし、ステータスを301、クエリ文字列の保持を有効にする設定例があります。パスやクエリも引き継がれますが、この例は https 側だけが対象なので、http で来たアクセスは別のルールで受けましょう。
移行先がApacheを採用したレンタルサーバーであれば、設定ファイルや.htaccessを使って301リダイレクトを実装します。サーバーの設定権限があれば専用のVirtualHost内でRedirectディレクティブを使う手法が適しており、.htaccessのみ編集可能な環境であればmod_rewriteを用いて正規のホスト名へ誘導する記述を置きます。
ところで、同じドメインのなかでwwwありとなしを入れ替えるだけなら、Search Console のアドレス変更ツールは使いません。正規化タグとリダイレクトで対応します。移管先でもHTTPとHTTPSの両方で漏れなく正規のURLへ301転送が作動するかをテストして設定を仕上げます。
移行後にサイトマップはいつ送信し、旧サイトマップはどうすればいいですか？
新しいサイトマップはどのタイミングで送信し、Studioで使っていた古いサイトマップはどのように扱えばよいのでしょうか。新しいサイトマップは、リダイレクトの設定と動作テストが終わり、移管先でサイトが表示されるようになってから送信します。送信前に、サイトマップのURLをブラウザで直接開いてXMLが表示されることと、Googleから取得できることを確かめておきます。
Studioではサイトマップのパスが「/sitemap.xml」に固定されていましたが、移管先のCMSでも同じパスで生成されているか、記載されているURL一覧が新しい形式に揃っているかを点検しておきましょう。移管先のサービスでは別のパスになることがあるので、Search Console に登録するURLもそれに合わせて変えます。
旧サイトマップの扱いは、URLが変わるかで分かれます。URLが変わる移行なら、新しいサイトマップを送信した時点で旧サイトマップは削除してかまいません。一方で、旧URLの登録減少と新URLの登録増加を追跡するために、あえて新旧両方のサイトマップを登録したまま推移を比較する方法もありますね。
URLが変わらない移行では、同じURLのサイトマップをGoogleが定期的に取り直します。それでも、移管で中身を大きく変えたなら、待たずに再送信したほうが反映を早められます。
もうひとつ、Search Consoleのサイトマップのレポートから旧サイトマップを消しても、Googleが把握しているサイトマップや、そこに載っていたURLまで消えるわけではありません。レポートの整理と、サーバー上のファイルを消す作業は別物です。取得エラーが出たときは、ファイルを直してから送り直します。
印刷物のQRコードのURLが変わる場合はどうすればいいですか？
店頭のチラシや名刺のQRコードが旧サイトの /news/123 を指していて、移管後の記事が /blog/123 に変わるとしましょう。印刷物は刷り直せないので、旧URLから新URLへ301リダイレクトを設定し、読み取った人を新しいページへ届けます。
設定したら、パソコンで旧URLを打ち込むだけでなく、実際の印刷物をスマホで読み取って転送先を確かめます。QRコードには、パラメータ付きのURLや、思っていたのと違うURLが入っていることもあるからです。
QRコードの旧URLがドメインごと変わる場合は、旧ドメインから新ドメインへの転送をリダイレクトページだけでは設定できません。旧ドメイン用のプロジェクトを残すか、外部のサーバーで転送しましょう。
転送をいつまで残すかについて、Googleは通常少なくとも1年、できるだけ長く維持するよう勧めています。利用者のことを考えると、無期限に残すことも検討してよいとしています。チラシや名刺は何年も配られ続けることがあるので、配布中の印刷物があるうちは外さないほうがよいでしょうね。
これから刷る分については、QR Code Generator の動的QRコードを使えば、印刷したあとでもリンク先を差し替えられます。