URLを変えないサーバー移転で順位を落とさない手順

サーバーを移したあと、検索からの流入が減った。URLは一つも変えていないのに、です。

このとき疑う先は、移転という行為そのものではありません。新しいサーバーをテストしていたときに掛けた蓋が、切り替え後もそのまま残っていないか。そして、Googleの巡回プログラム（Googlebot）が新しい入口に入れているか。まずこの2つです。

どちらも、切り替えの前に外す・確かめるだけで済みます。逆に言えば、切り替えたあとに気づくと、しばらく気づけません。新しいサーバーは人間のブラウザには普通に見えているからです。

公式ガイドが対象にしている「移転」の範囲

Google 検索セントラルには、ホスティングの変更を扱ったガイドがあります。そこで言う「ホスティング インフラストラクチャの変更」とは、ホスティング プロバイダの切り替えや、コンテンツ配信ネットワーク（CDN。世界中の拠点からページを配信するしくみ）への移行のことだと書かれています。そしてこのガイドは、ユーザーに表示される URL には影響を与えない移転のみを対象としています。

URLを変える場合は、同じ検索セントラルの別ガイドの範囲です。そちらには、現在のURLから新しい形式への対応表を用意する、元のURLから新しいURLへリダイレクトするようサーバーを設定する、といった手順が並びます。今回の話にそれらは出てきません。扱っている対象が違うからです。

手順の骨格も、公式の概要はかなり短いものです。

1. 新しいホスティング インフラストラクチャを準備する（コンテンツを新しいサーバーにアップロードする、またはCDNのサーバーと元のサーバーを設定してテストする）
2. ドメイン名のDNS設定（ドメインとサーバーの紐づけ設定）を変更して、新しいインフラを参照するようにする

公式は、この2番目の手順をもって「サイトが実際に移転されたことになり、トラフィックを新しいインフラストラクチャに送信するプロセスが開始される」と書いています。つまり移転当日にやることは、ほぼDNSの書き換えだけ。事故の芽は、その前の準備段階にまとめて仕込まれます。

落ちるとしたら、原因は準備段階に埋まっている

公式ガイドには、準備の説明のなかにこんな一文があります。テスト用のコピーでは、ヘッダーを使用してコンテンツのインデックス登録をブロックしたりすることがある、と。そして続けて、移転開始の準備ができたら、サイトの新しいコピーではそのようなブロックをすべて解除するようにと書かれています。

わざわざ書かれている、ということです。

テスト中のサイトを検索結果に出さないための処置は、正しい作業です。問題は、その処置が「テスト用の一時的なもの」だという記憶が、切り替え当日には薄れていること。DNSを切り替えた瞬間、そのテスト用の設定が本番の設定になります。

もう一つが入口です。公式は、Googlebot が新しいインフラストラクチャにアクセスできることを確認するよう求めています。そのうえで注意書きがあります。ファイアウォールの設定やサービス拒否攻撃（DoS）対策によって、Googlebot によるDNSやホスティング プロバイダのサーバーへのアクセスがブロックされていないことを確認してください、と。あわせて「Googlebot かどうかを確かめる方法」への案内も置かれています。同ページの英語の要約では、Googlebot のアクセスは Search Console を使って確認するとされています。

新しいサーバーを立てると、セキュリティ設定は初期状態か、移行元とは別の製品になっていることがあります。人間のアクセスは通り、巡回プログラムだけ弾かれる。これは画面を見ているだけでは絶対に気づけません。

切り替え前に外す蓋を棚卸しする6ステップ

やることは「新しいサーバーの上で、検索向けの制限が本番用の状態になっているか」を1か所ずつ確かめることです。順番に意味があります。上から順に、気づきにくい順ではなく、直すのに時間がかかる順に並べています。

1. 新旧の設定ファイルを並べて差分を取る。移行元と移行先で、検索まわりの記述がどう変わったかを先に見ます。ここで差が出ないなら、あとの5つは確認だけで済みます。
2. 新しいサーバーの応答ヘッダーを、本番ドメイン名で確認する。テスト用のURLで見ても意味がありません。切り替え後に返る値を見たいので、手元のパソコンから接続先を新サーバーに固定した状態で、本番のドメイン名を使って確かめます。
3. クロールとインデックス登録に関する制限を、置き場所ごとに数える。ヘッダー、HTMLの中、サーバーの設定ファイル、CMSの管理画面。同じ意味の制限が複数の層に散っていることがあり、1か所だけ外しても効きません。
4. ファイアウォールとDoS対策の許可設定を見る。ここが最も時間がかかります。ホスティング側の管理画面で設定するもの、CDN側で設定するもの、サーバー内で動いているものが別々にあるためです。
5. CDNを挟む場合は、CDNと元のサーバーの両方をテストする。公式が準備の手順に「CDNサーバーと元のサーバーを設定してテストする」と書いているのは、経路が2本になるからです。CDN側が通っても元のサーバー側で弾いていれば、経路によって結果が変わります。
6. 外したあと、もう一度2に戻る。設定を変えたら、変えた結果を同じ方法で読み直します。管理画面の表示と実際に返る値がずれることがあります。

6つのうち、切り替え当日に間に合わせられるのは2と6だけです。だから前もってやります。

置き場所ごとの判定表

蓋は一種類ではありません。どこに置かれているかで、症状も外し方も変わります。

表の3行目が、6ステップの3で「置き場所ごとに数える」と書いた理由です。クロールを止めたままインデックス登録のブロックだけ外しても、外したこと自体が読まれるとは限りません。順番があります。

そして5行目だけは、性質が違います。これは唯一、切り替えた瞬間に誰かが気づく蓋です。裏を返せば、残りの4つは誰も気づかないまま日数だけが過ぎます。

ワークスルー：共有サーバーからCDN併用へ移す

架空の自社サイト example.com で、実際に通してみます。共有サーバーで運用していたコーポレートサイトを、別のホスティングへ移し、あわせてCDNを挟む構成に変える。URLは1本も変えません。

移転の前。新しいホスティングにコンテンツを上げ、テスト用のURLで動作確認をします。この時点で、検索結果に出ないようテスト環境にはインデックス登録のブロックを掛けています。ここまでは正しい作業です。

準備の仕上げ。6ステップを回します。差分を取ると、移行元にはなかったインデックス登録ブロックのヘッダーが、新サーバーの全ページに付いていました。テスト用に入れたものです。これを外す。次にファイアウォールを見ると、初期設定で自動アクセスをまとめて遮断する設定が有効になっていました。ここも見直します。CDN側の設定も同様に確認し、経路を2本とも通します。

DNSのTTLを下げる。TTLは、DNSの設定情報がキャッシュとして保持される有効期限です。公式は、サイトのDNSレコードのTTL値を小さくすると、サイトの移転がより迅速に進むことがある、と書いています。理由も添えられています。DNS設定は通常、指定されたTTL設定に基づいてISPのキャッシュに保存されているため、値を小さくすると新しい設定がISPにすばやく適用されるようになる、と。下げるタイミングと戻すタイミングは、契約しているDNSの提供元の反映のしかたによって変わるので、提供元の案内に合わせます。

切り替え。DNSレコードを更新して、新しいホスティング プロバイダを参照するようにします。公式は、設定の更新方法についてはDNSプロバイダに問い合わせるよう案内しています。ここは提供元ごとに画面が違うためです。

切り替えたあと。ここからが次の節です。

見るのはログ。止める合図は「ゼロ」

切り替え後の監視について、公式ははっきりした基準を1つ置いています。

まず、元のサーバーと新しいサーバーの両方のサーバーログに注意します。DNS設定が全体に適用されてサイトのトラフィックが移行するにつれ、元のサーバーのトラフィックが減り、それに対応して新しいサーバーのトラフィックが増えていく。この形になっていれば、切り替えは進んでいます。同ページの英語の要約では、サーバーログに加えて、公開されているDNS確認ツールを使うことにも触れられています。

そして、旧サーバーを止めてよいタイミングです。公式はこう書いています。元のプロバイダのサーバーログを確認し、元のプロバイダへのトラフィックがゼロになったら、元のホスティング インフラストラクチャをシャットダウンできる、と。これでホスティングの変更が完了することになる、とも。

基準は日数ではありません。ログの数字です。

これは実務上、けっこう効きます。「1週間並行稼働させたから、そろそろ止めてよいだろう」という判断は、根拠がカレンダーにあります。TTLの反映は経路によって速さが違うので、カレンダーは実態を保証しません。見る場所を「旧サーバーのログ」に変えるだけで、判断が観測に変わります。

止める前に、旧サーバー側のログで確認したい点は3つです。

1. トラフィックが減り続けているのではなく、ゼロになっているか
2. 残っているアクセスがある場合、それがどこから来ているか（社内の監視や、古いDNSキャッシュを持つ経路の可能性があります）
3. 新サーバー側のログで、対応する増加が起きているか

3番目を見落とすと、単に旧サーバーへの到達が減っただけの状態と区別がつきません。減った分がどこへ行ったのかを、増えた側で確かめます。

クロール頻度が変わっても、下落の前兆とは限りません

移転後にクロールの様子が変わることは、公式ガイドが変動として扱っています。そのうえで理由が説明されています。サイトのクロール頻度は多くのシグナルに基づいて決定されており、ホスティングを変更するとこれらのシグナルが変わるため、変動が起こる、と。

さらに続きがあります。Googlebot は、新しい配信インフラストラクチャにアクセスした際、深刻な問題や遅延が発生しなければ、必要な範囲内でできる限り高速にサイトをクロールしようとする、と書かれています。

読み方が変わるはずです。移転後にクロールの数字が動いたとき、確かめるべきは「順位が下がる前兆かどうか」ではありません。「深刻な問題や遅延が起きていないか」です。前者は待つしかありませんが、後者は今すぐ見に行けます。応答が遅くなっていないか。エラーを返している経路がないか。

数字の変動そのものではなく、その裏で新サーバーが健康かどうかを見る。順番はこちらです。

公開前チェックリスト

切り替えのボタンを押す前に、この6つが埋まっているか確かめます。

• 新旧の設定差分を取り、検索まわりの記述の違いを把握した
• 本番ドメイン名で新サーバーの応答を読み、テスト用のブロックが残っていないことを確認した
• クロールとインデックス登録の制限を、置き場所ごとに数えて外した
• ファイアウォールとDoS対策で Googlebot のアクセスが遮られていないことを確認した
• CDNを挟む場合、CDN側と元のサーバー側の両方をテストした
• DNSのTTLを下げ、切り替え手順をDNSの提供元の案内に合わせて確認した

そして切り替え後に、旧サーバーのログのトラフィックがゼロになるまでは、旧サーバーを止めません。

URLも一緒に変える予定があるなら、必要な作業はここまでの内容とは別に増えます。対応表の作成やリダイレクトの設定が入るためで、その進め方はサイトリニューアルでURLを変えるときのリダイレクト設計にまとめています。移転後に見つかった404の扱いに迷ったときは、Search Consoleの404は放置してよいのかもあわせて参考にしてください。