ホームページリニューアルでURLを変える前の引継ぎチェックリストのアイキャッチ

NOTES

ホームページリニューアルでURLを変える前の引継ぎチェックリスト

ホームページのリニューアルで検索流入や問い合わせ導線を落とさないためには、変更不要なURLを維持し、変更する…

チップス

ホームページのリニューアルで検索流入や問い合わせ導線を落とさないためには、変更不要なURLを維持し、変更するURLだけを旧新URL対応表へまとめます。公開前に表を作り、301転送(恒久転送)、canonical(代表URLを示す設定)、内部リンク、サイトマップ、計測を同じ行で読み戻せる状態にしてください。

ドメイン変更、CMS変更、デザイン刷新を一度に重ねると、不具合が起きたときに原因を切り分けにくくなります。大きな変更は可能なら分け、公開前・公開直後・数週間後の確認担当まで決めることが、移行作業の出発点です。

この記事では、既存サイトのリニューアル相談を始めたものの、現在のURLをどう扱うべきか整理できていない中小事業者の担当者に向けて、制作会社へ渡せる表の項目と確認手順をまとめます。

URLを変える前に決めること

デザインや文章を変えるだけなら、ページのURLまで変えるとは限りません。現在のページと新しいページの役割が同じで、URLに運用上の問題がない場合は、既存URLを維持するほうが引継ぎ項目を減らせます。

URL変更を検討するのは、ページを統合する、情報設計を組み替える、ドメインを変更するなど、旧URLのままでは新しい構成を表しにくい場合です。見た目を新しくしたいという理由だけで、すべてのURLを書き換える必要はありません。

判断は、旧URLごとに「維持」「変更」「統合」「廃止」の四つへ分けます。維持は同じURLで公開、変更は対応する新URLへ恒久転送、統合は内容を引き継ぐページへ転送、廃止は代替ページの有無を確認する扱いです。

代替のない廃止ページを、関係の薄いトップページへまとめて転送する方法は避けます。Googleも、多数の旧URLを無関係な一つのURLへ転送すると、利用者を混乱させ、soft 404(実質的にページが見つからない状態)として扱われる可能性があると案内しています。[1]

同時に、今回のリニューアルで何を変えるかも線引きします。Googleは、ドメイン、CMS、レイアウトなどの変更を一度に重ねず、一つずつ進める考え方を案内しています。

事業上の都合で同時公開が避けられない場合でも、URL、CMS、計測の各担当と確認項目を分けておくと、公開後の原因調査がしやすくなります。[1]

旧URLと新URLの対応表を作る

旧URL一覧から維持・統合・廃止を分岐し、新URL、転送先、担当者を確定する流れを整理した図
維持・統合・廃止の判断順を理解するために、旧URL一覧から維持・統合・廃止を分岐し、新URL、転送先、担当者を確定する流れを整理しています。

対応表は、転送設定だけを依頼するための一覧ではありません。どのページを残し、どこへまとめ、誰が内容と動作を確かめるかを、事業者と制作会社が共有する台帳です。

旧URLは、現在のサイトマップ、アクセス解析、Google Search Console、CMSのページ一覧などから集めます。すべてを一度に洗い出しにくい場合は、検索流入があるページ、問い合わせにつながるページ、外部からリンクされているページ、主要サービスページから着手します。

画像やPDFが検索や外部リンクの入口になっている場合は、それらのURLも移行対象へ含めます。[1]

リニューアル用URL対応表の項目例
旧URL新URL・扱い担当確認結果
トップページの旧URL維持、または新URLを記入事業者・制作会社公開前/直後/数週間後
主要サービスページの旧URL維持・変更・統合から選択事業者・制作会社表示・転送・計測
問い合わせページの旧URL維持、または変更時の転送先を記入事業者・制作会社送信・完了・通知
検索流入がある記事の旧URL維持、または対応する記事へ統合制作会社転送・canonical
廃止候補ページの旧URL代替先、またはページなしの扱いを記入事業者404・410を含め確認

この表で決めるのは、URLの扱いだけではありません。内容の妥当性を事業者が確認し、転送やcanonicalなどの実装を制作会社が確認するといった役割分担まで、行単位で確定します。

一つの旧URLに対し、最終的な行き先は一つにします。複数段階の転送である転送チェーンを作らず、可能な限り旧URLから最終URLへ直接転送する設計にします。

統合する場合も、名称が似ているだけではなく、旧ページを訪れた人が目的を果たせるページかを確かめてください。Googleは、旧URLと新URLの対応付けを準備し、内部リンクやcanonical、サイトマップを新URLへ更新する流れを示しています。[1]

「確認結果」欄は、公開前に一度埋めて終わりにしません。「公開前OK」「公開直後OK」「数週間後確認済み」のように時点を分けます。同じ表を使い続ければ、公開後に問題が見つかった際も、対象URL、担当、前回の確認結果をすぐにたどれます。

301転送とcanonicalと内部リンクの役割を分ける

301転送、canonical、内部リンクは、どれか一つを設定すれば残りが不要になる仕組みではありません。利用者を新しいページへ送る処理、検索エンジンへ代表URLを示す情報、サイト内の移動先を整えるリンクとして、役割を分けて依頼します。

301転送は旧URLから新URLへ案内する

301転送は、ページが恒久的に移動したことをサーバーから伝え、旧URLへのアクセスを新URLへ送る方法です。Googleは、URLを恒久的に変更する場合、可能であればサーバー側の恒久転送を使うよう案内しています。[2]

設定後は、転送コードが301であることだけでなく、対応表で決めた最終URLへ到達するかを確認します。旧ページAから中間ページB、さらに新ページCへ進む形ではなく、AからCへ直接転送できるかを制作会社へ確認してください。

canonicalは代表として扱ってほしいURLを示す

canonicalは、同一またはよく似た内容へ複数のURLでアクセスできるときに、代表として扱ってほしいURLを示す情報です。新ページでは、そのページ自身の正式なURLを示す自己参照canonicalを設定し、旧ドメインやテスト環境のURLが残っていないかを確認します。

恒久転送とcanonicalはいずれも代表URLを判断するシグナルになりますが、canonicalは旧URLへアクセスした利用者を新URLへ移動させる処理ではありません。URLを廃止して移動させる場面では301転送を行い、新サイト内ではcanonical、内部リンク、サイトマップが同じ正式URLを指すようにそろえます。[3]

内部リンクとサイトマップは新URLへそろえる

メニュー、パンくず、本文リンク、ボタン、フッターなどの内部リンクは、旧URLを経由させず、新URLを直接指定します。301転送が動いていても、サイト内リンクを旧URLのまま残すと、利用者の移動と確認作業に余計な経路が増えます。

サイトマップへ記載するのは、公開後に検索結果へ出したい正式な新URLです。canonicalでは新URL、内部リンクでは旧URL、サイトマップでは別URLというように食い違わせず、対応表の一つの行から同じ行き先を読み戻せる状態にします。

Googleも、サイト内ではcanonicalと考えるURLへ一貫してリンクし、サイトマップへ正式URLを含めるよう案内しています。[3]

計測は検索エンジン向けの設定ではありませんが、問い合わせ導線を守るために同じ行で確認します。ページ表示だけでなく、フォーム送信、完了画面、電話やメールの導線など、現行サイトで確認している項目が新URLでも記録されるかを公開前に試します。

公開前に確認する項目

公開前の確認は、トップページだけを見て終わらせず、URL対応表に載せた主要URLごとに行います。制作会社が設定し、事業者が画面と問い合わせ導線を確認するなど、同じURLを異なる視点で読み戻すと漏れを見つけやすくなります。

  • 維持するURLで予定したページが表示され、主要な文章・画像・ボタンが欠けていない
  • 変更・統合する旧URLが、対応表で決めた新URLへ301転送され、ループや不要な中継がない
  • 新URLのcanonicalが、旧URLやテスト環境ではなく、公開する正式URLを指している
  • 公開対象ページに、開発中だけ使っていたnoindexやrobots.txtの遮断が残っていない
  • メニュー、パンくず、本文、CTA、フッターの内部リンクが新URLを直接指している
  • サイトマップへ正式な新URLが入り、旧URLやテスト用URLが混在していない
  • 廃止ページは代替先の有無に応じて扱いを決め、無関係なページへ一括転送していない
  • 問い合わせフォームの入力、確認、送信、完了表示、社内通知まで一連で動作する
  • 現行サイトで使っているアクセス解析と問い合わせ計測が、新しいページでも記録される
  • 各項目の確認日、確認者、不具合、再確認結果をURL対応表へ記録している

noindexは、ページを検索結果へ掲載しないよう指示する設定です。robots.txtは、検索エンジンによる巡回を制御するファイルです。テスト環境で使っていた指定が本番公開後も残らないようにします。

Googleの移転ガイドでも、開発中に設定したnoindexやrobots.txtの制限を公開時に見直し、canonicalと転送を検査するよう案内しています。[1]

チェック結果は「設定済み」ではなく、「旧URLを開くと、301を経て指定の新URLが表示された」のように、確認した動作を残します。問題があった行だけ再確認日を追加すれば、公開判定と修正履歴を一つの表で管理できます。

公開直後と数週間後に読む数字

公開前は設定と表示、公開直後は転送と計測、数週間後は検索流入と問い合わせ導線を見る時間軸を整理した図
時点ごとの確認項目を分けるために、公開前は設定と表示、公開直後は転送と計測、数週間後は検索流入と問い合わせ導線を見る時間軸を整理しています。

公開直後に見るのは、順位の上下よりも、設定と問い合わせ導線が実際の環境で動いているかです。数週間後には、検索流入が旧URLから新URLへ移っているか、問い合わせにつながる入口が保たれているかを確認します。

公開直後は技術不良を探す

公開後は、対応表から主要な旧URLを開き、最終URL、表示内容、canonical、フォーム動作を再確認します。あわせて、アクセス解析で新サイトの閲覧が記録されるか、問い合わせのテスト送信が計測と社内通知の両方へ反映されるかを確かめます。

エラーログや確認ツールで、404、500番台のエラー、転送ループ、想定外の転送先が増えていないかも見ます。旧URLが減り、新URLへのアクセスが増える動きは移行に伴うものです。

一方で、主要URLが404になる、全ページがトップへ飛ぶ、計測が一件も入らないといった状態は、通常の変動として待たずに修正対象へ戻します。

ドメインを変更した場合は、新旧サイトをSearch Consoleで確認し、転送開始後にアドレス変更ツールの対象と実行担当を確認します。HTTPからHTTPSへの変更だけの場合は、このツールを使わないとGoogleは案内しています。[4] [1]

数週間後は検索流入と問い合わせ導線を読む

数週間後は、Search Consoleで新URLの表示回数、クリック、検索クエリ、インデックス状況を確認します。アクセス解析では、自然検索から入ったページ、主要ページの閲覧、問い合わせ完了までの流れを見ます。

サイト全体の合計だけではなく、URL対応表の主要行ごとに旧URLと新URLを比較すると、問題のあるページを切り分けやすくなる方法です。

Googleは、URL変更を伴う移転では再クロールと再インデックスの間に検索順位が一時的に変動し、中小規模のサイトでも多くのページの移行に数週間かかる場合があると説明しています。ただし期間は固定ではなく、URL数やサーバーの処理速度などで変わります。[1]

一時的な変動と技術不良は、設定の検査結果と組み合わせて判断します。転送、canonical、noindex、内部リンク、サイトマップ、計測に異常がなく、新URLの認識が徐々に進んでいるなら推移を継続して見ます。

特定ページだけ流入が戻らず、旧新対応や検索意図がずれている場合は、その行の転送先と内容を再点検します。

制作会社へ渡す資料と質問

初回打ち合わせでは、「SEOに配慮してほしい」とだけ伝えるのではなく、URL対応表と確認条件を渡します。制作会社が実装範囲を見積もり、事業者が確認すべき内容を引き取れる形にしてください。

  • 現在の主要URL一覧に、維持・変更・統合・廃止の判断と新URL候補を記入したか
  • URL一覧をどの資料から取得し、画像・PDF・過去記事をどこまで対象にするか合意したか
  • 301転送をどの方法で設定し、旧URLから最終URLまでをどう検査するか確認したか
  • canonicalの生成ルールと、自己参照・旧URL・テスト環境URLの確認方法を聞いたか
  • メニューや本文を含む内部リンクの旧URL検査と修正範囲を決めたか
  • サイトマップへ載せるURLと、公開後に送信・確認する担当を決めたか
  • noindex、robots.txt、公開環境の表示制限を誰が解除し、誰が読み戻すか決めたか
  • 現行のアクセス解析と問い合わせ計測を何まで引き継ぎ、テスト結果をどう報告するか決めたか
  • 公開前、公開直後、数週間後の確認日と、事業者・制作会社それぞれの担当を決めたか
  • ドメイン変更がある場合、Search Consoleの新旧確認とアドレス変更ツールの実行条件を確認したか

制作会社から受け取る結果は、「301設定済み」「確認済み」という一言ではなく、旧URL、転送先、最終ステータス、canonical、内部リンク、計測結果、確認日が分かる形を求めます。対応表へ結果を追記してもらう方法なら、事業者側でも公開後の状態を読み戻せます。

担当は、技術作業ができる人だけを置けばよいわけではありません。サービス内容や問い合わせ先の正しさは事業者、転送やcanonicalの実装は制作会社、計測結果は両者で確認するなど、判断できる人を項目ごとに割り当てます。

公開日の立ち会いが難しい場合は、異常があったときの連絡先と、公開を戻す判断者も決めておきます。

まとめ

URLを変えるリニューアルでは、301転送だけを設定して完了にしません。変更不要なURLを維持し、変更するページは旧新URL対応表へまとめ、canonical、内部リンク、サイトマップ、計測まで同じ行から確認します。

公開前は設定と表示、公開直後は転送と問い合わせ計測、数週間後は検索流入と問い合わせ導線を読みます。ドメイン変更やCMS変更などを重ねる場合は、作業と担当を分け、どの変更に問題があるか追える状態にしてください。

現在の主要URLを一覧にし、維持・変更・統合・廃止の判断欄と担当者欄を付けて、制作会社との初回打ち合わせへ持参する。

参考資料

  1. 「サイトを移転する方法」Google Search Central、最終更新:2026年6月17日(UTC)。原文を見る
  2. 「リダイレクトと Google 検索」Google Search Central、最終更新:2026年4月14日(UTC)。原文を見る
  3. 「rel="canonical" などを使用して正規 URL を指定する方法」Google Search Central、最終更新:2026年7月10日(UTC)。原文を見る
  4. 「アドレス変更ツール」Search Console ヘルプ、確認日:2026年8月7日。原文を見る