サイトリニューアルでSEOを落とさない移行チェックリスト｜制作会社が実案件で確認している項目

サイトリニューアルの後に「検索順位が落ちた」「Googleの検索結果の表示がおかしい」という相談は、決して珍しくありません。そして原因を調べると、ほとんどの場合は次の3つのどれかに行き着きます。

• 旧URLから新URLへの引き継ぎ（301リダイレクト）の漏れ
• title・description・canonicalなどメタ情報の欠落や誤り
• 公開後の検証不足（見た目だけ確認して中身を見ていない）

逆に言えば、この3つを移行の前・最中・後の各段階で計画的に潰しておけば、リニューアルでSEOが大きく落ちることはまずありません。この記事では、弊社がドメイン変更を伴うコーポレートサイト移行や店舗サイトのリニューアルで実際に使っているチェックリストを、確認の手順ごとに公開します。

先に全体像:移行チェックリスト

まず結論として、確認すべき項目の一覧です。詳細は後述しますが、この順番で潰していけば大きな抜けは出ません。

• 移行前:旧サイトの全URLを棚卸しする
• 移行前:新旧URLの対応表を作り、リダイレクトを1対1で設計する
• 移行前:title・description・canonical・OGP・構造化データの現状を確認する
• 移行時:301リダイレクトをパス・クエリごと引き継ぐ形で設定する
• 移行時:SSL証明書とwwwあり・なしの統一を確認する
• 移行時:HTML・JS内に残る旧ドメイン・旧表記を洗い出す
• 公開後:ブラウザではなくcurlなどで実測検証する
• 公開後:HTTP 200を信用せず、本文の中身まで確認する
• 公開後:Search Consoleでサイトマップ送信とインデックス状況を確認する
• 運用:旧ドメインの301リダイレクトを最低数ヶ月維持する
• 運用:旧ディレクトリは削除せず、まずリネームして寝かせる

移行前:URLとメタ情報の棚卸し

旧サイトのURL一覧を作る

移行作業の起点は、旧サイトにどんなURLが存在するかの棚卸しです。トップページと主要ページだけ見て進めると、検索流入を稼いでいた下層ページやブログ記事の引き継ぎが漏れます。サイトマップ、Search Consoleのインデックス済みページ、アクセス解析の流入URLを突き合わせて、一覧を作ってから設計に入ります。

リダイレクトは1対1で、チェーンは短く

URL構造を変える場合は、旧URLと新URLの対応表を作り、原則1対1の301リダイレクトを設計します。「全部トップページに飛ばす」という手抜きは、Googleからページ単位の評価引き継ぎが行われず、ユーザーにとっても目的のページに着けないため、順位下落の典型的な原因になります。

ドメイン自体を変更した案件では、リダイレクトが多段になることがあります。弊社が担当した美容関連企業のコーポレートサイトでは、経緯上「旧々ドメイン、旧ドメイン、新ドメイン」という3段のリダイレクトチェーンが発生しました。この場合も、各段が301でパスとクエリをそのまま引き継ぐ設定にしておけば、全経路が最終的に正しいページへ200で到達します。実際に全経路を実測し、パス付きURL・クエリ付きURLの引き継ぎまで確認してから公開しました。チェーンはゼロにできるならそれが最善ですが、やむを得ず残る場合は「全段301・引き継ぎあり・最終200」を実測で担保します。

メタ情報の現状確認。「元サイトにそもそも無い」ことがある

リニューアルでは「旧サイトにあったものを漏らさず引き継ぐ」ことに意識が向きますが、実務では逆のケースにもよく出会います。旧サイトにcanonicalもOGPも設置されていなかった、というケースです。

先ほどのコーポレートサイト移行でも、元のサイトにはcanonicalタグ・OGP・twitterカードのいずれも未設置でした。この場合、引き継ぎではなく移行と同時の新設になります。リニューアルは、こうした欠けていたSEOの土台を整える機会でもあるので、移行前の棚卸しの段階で「何があるか」だけでなく「何が無いか」も記録しておくと、公開時の作業リストが正確になります。

移行時:リダイレクト設定と旧URL残存チェック

HTML・JSの中に残る旧ドメイン・旧表記を洗う

リダイレクトを設定しても、新サイトのHTMLやJavaScriptの中に旧ドメインへのリンクや旧名称の表記が残っていると、無駄なリダイレクトを踏み続けたり、検索結果やSNSシェアで古い情報が表示されたりします。

ここはブラウザで目視するのではなく、ファイル全体をgrep（文字列検索）で機械的に洗うのが確実です。実際の移行案件では、目視確認を終えたあとにgrepをかけ直したところ、ヘッダーロゴ・フッターの社名表記など表示系の旧表記が4箇所残っているのが見つかりました。ビルドされたJSファイルの中に埋まっていた表記で、ページを普通に眺めているだけでは気づきにくい場所です。検索対象は小文字・大文字の両方、ロゴ画像のalt、構造化データの中まで含めます。

なお、ビルドパスや外部CDNの画像ファイル名など、画面に表示されない内部文字列に旧名称が残っていても実害はありません。すべてを書き換えようとしてビルド済みファイルの内部を壊すほうがリスクが高いので、「画面と検索結果に出るものだけ直し、出ないものは残す」という線引きで判断します。

SSLとwwwの統一

新ドメインでの移行なら、SSL証明書が新ドメインで正しく発行されているか、wwwあり・なしの両方でアクセスして正規URLに統一されるかを確認します。地味な項目ですが、httpとhttps、wwwありとなしで別URLとして評価が分散するのは、もったいない失点です。

公開後の検証:ブラウザで見るだけでは不十分

公開後の検証こそ、SEOを落とさないための本丸です。ここで「ブラウザで開いて表示されたからOK」としてしまうと、問題を見逃します。実案件で遭遇した3つの罠を紹介します。

罠1:ブラウザキャッシュが「移行失敗」に見える

ドメイン変更の公開直後、サイトのオーナーから「リダイレクトされない」「タイトルが旧表記のまま」という報告を受けたことがあります。しかしcurl（キャッシュを介さずサーバーの生の応答を確認できるコマンド）で実測すると、301リダイレクトもタイトルもサーバー側は完全に正常でした。原因はすべて報告者のブラウザキャッシュだったのです。

公開直後の「おかしい」という見た目の報告は、まずサーバーの実応答と切り分けます。検証する側も、ブラウザの再読み込みやシークレットウィンドウではなく、curlなどキャッシュの影響を受けない手段で確認する習慣をつけると、切り分けが一度で終わります。

罠2:HTTP 200が返っても中身が壊れていることがある

ステータスコード200は「ページが正常」を意味しません。実例が2つあります。

1つ目はサイトマップです。SPA（シングルページアプリケーション）構成のサイトでは、存在しないパスへのアクセスをindex.htmlに振り向ける設定が入っていることが多く、sitemap.xmlの実ファイルが無いのにアクセスすると200が返ります。実際、多店舗展開している店舗サイトの検証で、サイトマップが「200なのに中身はトップページのHTML」という状態を発見しました。Googleには有効なサイトマップを提示できていなかったわけです。

2つ目はサーバー側のエラーです。PHPのWarningなどは、HTTP 200を返しながらHTML本文の中にエラーメッセージが出力されることがあります。ステータスコードの確認だけでは検出できません。

対策はどちらも同じで、ステータスコードではなく本文を確認することです。サイトマップならXMLとして正しい中身が返っているか、通常ページなら本文にエラー文字列が含まれていないかを、grepで機械的にチェックします。

罠3:検索結果に「別のページの説明文」が出る

テンプレートを流用して複数サイト・複数店舗を展開する場合、ページ固有のメタ情報の設定漏れがあると、テンプレート元の情報がそのまま公開されます。怖いのは、サイトを普通に閲覧しているだけでは気づけないことです。titleやdescription、canonical、構造化データはソースを見ない限り目に入りません。

実際に、多店舗展開の店舗サイトで、ある店舗のページだけ専用のメタ情報が用意されておらず、title・description・canonical・構造化データがすべて別店舗のまま公開されていたケースがあります。Google検索でそのURLを調べると、検索結果に別店舗の説明文が表示されていました。ユーザーが別の店の営業時間や地名を見て来店判断をしかねない状態です。

リニューアルや店舗追加の公開後は、主要ページのソースを開いてメタ情報がそのページ固有のものになっているかを確認し、数日後にGoogleで実際の検索結果の表示も見る。この2段構えをチェックリストに入れておくべきです。

公開後の運用:旧環境をすぐに消さない

旧ドメインの301は最低数ヶ月維持する

ドメイン変更の場合、旧ドメインの契約を早々に解約したくなりますが、解約するとリダイレクトごと消えます。検索エンジンの評価引き継ぎ、外部サイトからの被リンク、ユーザーのブックマークは一晩では切り替わりません。旧ドメインの301リダイレクトは最低でも数ヶ月、可能なら1年程度は維持し、解約前にSearch Consoleで旧URLへの流入がほぼ消えたことを確認してから判断します。

旧ディレクトリは削除ではなく、まずリネームで寝かせる

リニューアル公開後、旧サイトのファイルや仮公開ディレクトリを整理する場面では、いきなり削除しないことを強くすすめます。正しい手順は次の通りです。

• 削除前に、サーバーのルート構成とindex.php・.htaccessの中身を必ず確認する（そのディレクトリを参照・読み込みしている記述がないか）
• 削除ではなく、まずリネームして数日寝かせる。問題が出たら即座に戻せる
• リネーム後は本番URLのステータスコードだけでなく、本文にエラーが出ていないかまで確認する

なぜここまで慎重にするかというと、本番ページが旧ディレクトリのファイルを内部で読み込むラッパー構造になっているケースが実際にあるからです。ルートのindex.phpが仮公開ディレクトリのHTMLを読み込んで表示する、といった構成は外から見ても分かりません。この状態で仮公開ディレクトリを削除すると、本番トップページが表示エラーで見られなくなります。「本番にアップ済みだからファイルの実体が別にあるはず」という思い込みは通用しない、というのが実務の教訓です。

Search Consoleでの仕上げ

公開後はSearch Consoleでの作業を忘れずに行います。新しいサイトマップの送信、インデックス状況の確認、ドメイン変更の場合はアドレス変更ツールの利用。この作業はサイト所有者の認証が必要なため、制作会社任せにせず、オーナー側でもアクセスできる状態にしておくことをおすすめします。

まとめ:検証を「見た目」から「実測」に変える

サイトリニューアルでSEOを落とさないためのポイントを整理します。

• URL構造は変えないのが最善。変えるなら旧URLの棚卸しと1対1の301設計をセットで
• メタ情報は「引き継ぐ」だけでなく「そもそも無いものを新設する」視点でも棚卸しする
• 旧ドメイン・旧表記の残存は目視でなくgrepで洗う
• 公開後の検証はブラウザでなくcurlで。ステータスコードでなく本文まで見る
• 旧ドメインの301は数ヶ月維持。旧ディレクトリは削除でなくリネームで寝かせる

共通しているのは、確認を「見た目」に頼らず「実測」に置き換えることです。ブラウザの表示、HTTP 200、公開済みという言葉。このどれもが、実際の状態を保証してくれません。リニューアルは公開した瞬間が終わりではなく、実測での検証と数ヶ月の経過観察までを含めて1つのプロジェクトとして設計する。それがSEOを落とさない移行の実務です。

graciautoでは、ドメイン変更を伴う移行やサイトリニューアルの際、この記事のチェックリストをそのまま案件に適用しています。リニューアルを検討していて検索流入を落としたくない方は、移行設計の段階からご相談ください。