ホームページリニューアルのSEO対策｜URL対応表と公開前後の確認

アイキャッチは記事の内容をイメージしたAI生成画像です。

リニューアルでは、残せるURLを維持し、変えるURLには対応する新ページへの恒久転送を設定します。旧ページの説明・資料・相談導線も引き継ぎ、公開前後に動作を確認することが基本です。この記事では、URL対応表の記入例と、制作会社に確認する項目を具体的にまとめます。

リニューアルのSEO対策は、URLと必要な情報の引き継ぎから

ホームページをリニューアルするときは、残せるURLを維持し、変更するURLには適切な移転先を決めて恒久転送を設定します。それと並行して、旧ページが答えていた疑問、画像・資料、関連ページへのリンクを新サイトへ引き継ぎます。最初に制作会社へ確認するのは、「旧URLごとの扱いと、公開後に確かめる担当が決まっているか」です。

リニューアルは、実施しただけで検索順位が上がる施策ではありません。GoogleはURL変更を伴う移転で一時的な順位変動が起こり得ると説明しています。引き継ぎの確認は移行時の不備を防ぐための作業であり、現在の順位や訪問数を保証するものではありません。

出典：サイト・ホームページ移行について | Google 検索セントラル  |  Documentation  |  Google for Developers

ドメインとは、URLの中でサイトの所在を示す部分です。同じドメインのままでも、末尾の「company.html」を「company/」へ変えれば、ページのURLは変わります。「会社のドメインを残すのでSEOの引き継ぎは不要」とまとめず、ページ単位で変更の有無を確認してください。

URLを変えないサーバー移行でも、確認は必要です。Googleのホスティング変更ガイドは、新しい環境でページ・画像・フォーム・ダウンロードなどをテストし、所有権確認を保つことを案内しています。見た目が同じでも、保存先や設定の違いで機能が変わる場合があります。

出典：ウェブ ホスティングの変更と SEO | Google 検索セントラル  |  Documentation  |  Google for Developers

本記事は、企業サイトの担当者が移行の内容を整理し、制作会社や運用担当と確認するための手順です。費用の見積もりや制作全体の工程は関連記事へ分け、ここでは「何を残すか」「どこへ移すか」「何を確認したら公開できるか」を具体化します。サーバー設定の書き換えは、実環境を把握した担当者に依頼しましょう。

公開前に、旧ページと残す内容を一覧にする

新しいサイトの画面ができてから旧ページを探し始めると、移したい情報が抜けやすくなります。現行サイトを参照できる間に、ページとファイルの一覧、原稿・画像、設定の控えを残します。バックアップは保存した事実だけで終わらせず、復元方法と対応する担当も確認してください。

一覧を作るときは、CMSの公開ページ、サイトマップ、Search Console、アクセス解析、利用可能なサーバーログなどを照合する方法があります。一つの資料に載っていないことだけで「使われていないページ」と判断しないでください。古いメールや配布資料のQRコードから開かれる案内、PDFなども社内で確認すると、画面上のメニューだけでは見つからない入口を補えます。

流入数と、ページが果たす役割を一緒に見る

検索から訪問されているページは重点確認の対象です。ただし、アクセスが少ないという理由だけで削除は決めません。サポート情報、仕様の説明、取引先へ案内している資料など、特定の人に必要なページもあります。計測されていない期間やURLは未取得と記録し、実測ゼロと区別します。

旧タイトルをすべて機械的にコピーする必要はありませんが、何の疑問に答えていたページかは確認します。たとえば「見積もりに必要な原稿形式」を検索して来た人に、会社の理念だけを載せた新ページでは答えられません。見た目を整理するときも、必要な説明をどの新ページで読めるようにするかを先に決めます。

公開前の比較用に、検索の表示・クリック・平均掲載順位と、解析で取得できる訪問や相談に関する記録も保存します。期間、ホスト、対象URL、フィルタを一緒に残すと、移行後に条件をそろえられます。確認アクセスは集客として数えず、問い合わせボタンのクリックと実際に受け付けた相談も分けておきましょう。

URL対応表の作り方：維持・移動・統合・削除を決める

URL対応表は、旧ページを開いた人が新サイトでどこへ進むかを決める一覧です。旧URLと新URLに加えて、対応理由と確認結果を残します。下の例は同じドメインにある架空の印刷サービスの教材です。実際のサイトの設定や、VELGRITの移行実績を示すものではありません。

Googleは、恒久的なURL変更にはサーバー側の301または308リダイレクトを推奨しています。リダイレクトは、古いURLへのアクセスを新しいURLへ転送する仕組みです。301・308は恒久的な移動、302・307は一時的な移動に使われる応答コードです。実装方法はサーバーやCMSに合わせて決めます。

出典：リダイレクトと Google 検索 | Google 検索セントラル  |  Documentation  |  Google for Developers

統合する場合は、旧ページの内容を引き継いだ関連ページを選びます。無関係なページをまとめてトップページへ転送する方法は避けます。代わりの内容がない削除ページには404または410を返す扱いがあり、すべての旧URLに転送先が必要なわけではありません。

出典：サイト・ホームページ移行について | Google 検索セントラル  |  Documentation  |  Google for Developers

表の「設定済み」を「確認済み」に変える

対応表には、予定した転送先だけでなく、実際に到着したURL、応答コード、内容の確認結果、確認日を追記します。ブラウザで画面が開いたことと、301などの応答が返ったことは別の確認です。担当者には、旧URLから最終ページまでの応答を確認できる記録を依頼しましょう。

たとえば、「新しいサービスページが開いた」は途中の確認です。そのページに旧案内の説明があり、見積もりの入口へ進めるかも確かめます。転送先がさらに古いページへ戻る、別のURLを何度も経由する、最後にエラーになる、といった不備があれば修正対象として残します。社内担当は内容の対応を、実装担当はURLと応答を確認すると役割が明確になります。

転送を用意した後も、サイト内のリンクは新しい行き先へ更新します。canonicalは、同じ内容のURLが複数ある際に正規として扱ってほしいURLを伝える指定です。新しいページが旧URLやテスト環境を指したままにならないよう、本文リンク・正規URL・サイトマップの設定を移行先にそろえます。

出典：サイト・ホームページ移行について | Google 検索セントラル  |  Documentation  |  Google for Developers

公開してよい状態かを、3つの確認で判断する

確認は「制作会社がチェックする」という一行で済ませず、対象・担当・結果の置き場を決めます。たとえば、内容は社内担当、転送と検索設定は実装担当、見積もりまでの操作は双方で確認する分担です。すべてを一人で抱える必要はありませんが、未確認項目を引き継ぐ相手が分からない状態は避けましょう。

検索に出したい本番ページの制限を確認する

テスト中のnoindexやアクセス制限を、本番へ残さないようにします。noindexは検索登録を除外する指示で、HTMLのメタタグだけでなくHTTPヘッダーにも設定できます。robots.txtのクロール制限とは役割が違い、クロールを止めるとGoogleがnoindexの変更を読めない場合があります。制作担当には両方を別項目で確認してもらいます。

出典：noindex を使用してコンテンツをインデックスから除外する | Google 検索セントラル  |  Documentation  |  Google for Developers

この確認は、検索に公開するページに対して行います。テスト環境、管理画面、非公開の資料まで一律に制限を外す作業ではありません。公開対象のURL一覧を先に共有し、必要な保護は残します。「全部解除した」とするより、公開するページの取得結果を記録したほうが確認範囲を判断できます。

ドメイン変更がある場合だけ、追加の手続きを確認する

Search Consoleのアドレス変更ツールは、ドメイン・サブドメイン間の移転で使う手段です。同じサイト内のパス変更、HTTPからHTTPSへの変更、同一ドメインのwww有無の変更、URL不変のホスティング変更には使用しません。対象となる移転では、必要な転送を実装した後に利用条件を確認します。

出典：アドレス変更ツール – Search Console ヘルプ

フォームの動作確認が必要な場合は、試験環境やテスト識別子、通知先を事前に決めて実施します。一般の問い合わせや売上に混ざらないようにし、何度も通知を送る確認にはしません。この記事を読むだけで本番へ送信する必要はありません。実施担当と条件を合意し、既存の有効な試験記録があればその内容を確認します。

重要な転送ができない、公開ページが取得できない、相談フォームへ進めない場合は、公開時刻に合わせることより修正を優先する判断が必要です。復旧するときにフォームの新しい受付記録を失わないかも含め、戻す対象と手順を決めます。「バックアップがあるから大丈夫」とだけ考えず、どの状態へ戻すかを共有してください。

実践例：古いサービス案内から見積もりへ進めるか確認する

架空の印刷サービスが、古い一枚の案内を「サービス紹介」と「入稿の説明」に分ける例で考えます。読者は、印刷を頼めるかを確認し、原稿を用意して見積もりへ進みたい状態です。旧URLを新サービス紹介へ転送できても、原稿の条件がどこにも書かれていなければ、判断に必要な情報が欠けています。

まず旧案内にあった「対応する印刷物」「入稿時に確認する項目」「見積もり時に伝える内容」を一覧にします。そのうち、サービス紹介には対象と概要を、入稿の説明には具体的な準備を残す方針にします。サービス紹介から入稿の説明へ案内し、両方から見積もりの入口へ進めるかを確かめる構成です。これは編集部の設計例で、成果が出た事例ではありません。

新しい説明の中身は、実際の提供条件を把握している担当者が確認します。ファイル形式、納期、料金などを、旧ページの空欄や他社サイトから推測で埋めてはいけません。決まっていない条件は確認担当へ戻し、一般説明と個別見積もりが必要な部分を分けます。

この検査では、見た目の好みとは別に「必要な説明へ着けるか」を見ます。PCでは分かりやすくても、スマホでは表が切れる、ボタンが画面外に隠れる、資料の文字が読めないことがあります。検索から入ったページを起点に、途中の説明と最後の入口まで一続きに確認しましょう。

公開後は、取得エラー・検索クリック・相談を順に確認する

公開したら、新しいトップページだけでなく、対応表の旧URLから確認します。まず予定したURLと内容へ到着するか、重要なファイルやフォームを利用できるかを点検します。その後、検索への反映と流入を追います。Googleの移行処理を待つ話と、いま利用者がページを開けない不具合は分けて対応してください。

Googleは、移転用のリダイレクトをできるだけ長く、一般には少なくとも一年維持するよう案内しています。検索表示が切り替わったら直ちに消す計画にはせず、旧ドメインや転送設定を維持する担当・契約も確認します。これは検索順位の回復期限を意味しません。

出典：サイト・ホームページ移行について | Google 検索セントラル  |  Documentation  |  Google for Developers

検索データを比べるときは新旧URLを対応させる

URLが変わった場合、旧ページだけのクリック減少を見て失敗と判断せず、対応する新ページも確認します。ドメイン変更なら新旧それぞれのプロパティを対象にします。期間の長さ・曜日・検索種類などの条件をそろえ、公開日とその後の修正日も記録して比較しましょう。データの遅延がある期間は暫定として扱います。

検索表示はあるがクリックが少ないページは、検索語と掲載位置を見て、タイトルが答える内容と本文が合っているかを確認します。一方、訪問後に相談が少ない場合は、対象者、提供範囲、相談時の準備物、フォームまでの経路を点検します。どちらも、少数の数字だけで原因や効果を決めず、確認した事実から次の修正を一つ選びます。

計測のタグが外れたり、別のホストを集計していたりすると、訪問数の変化を正しく読めません。検索データ、サイトへの訪問、受付記録がそろわない場合は、まず計測条件を調べます。問い合わせクリックを実際の問い合わせと置き換えず、テストも識別しておけば、制作の検査完了と事業の成果を分けて判断できます。

担当者間の引き継ぎでは、URL対応表、公開時の検査結果、残っている課題、次の確認日を同じ場所へまとめます。「SEO対応済み」という一言より、対象の旧URLと結果が残っているほうが、変更後の不具合を追いやすくなります。まずは、次に公開する範囲について、残す情報と確認担当を決めるところから始めてください。

よくあるご質問