ホームページリニューアル前のURL棚卸し｜残す・統合・転送を決める一覧表

ホームページをリニューアルするとき、デザインや新しいページ構成より先に確認したいのが、現在公開されているURLです。トップページやサービスページだけを見て「全部で20ページほど」と数えても、実際には過去のお知らせ、採用情報、PDF、キャンペーンページ、フォームの完了ページなどが残っていることがあります。

これらを把握しないまま新サイトを公開すると、検索や外部サイトから訪問されていたページが突然404になったり、本来は残すべき内容が削除されたりします。反対に、役割を終えたページを何となく移植すると、新サイトでも似た内容が増え、更新先が分からなくなります。

URL棚卸しの目的は、旧URLをただ並べることではありません。旧URLごとに、残す・更新する・統合する・削除する・保留するの判断を付け、新URLと公開時の処理まで一行で確認できる状態を作ることです。この記事では、現行URLの集め方、判断材料、一覧表の項目、公開前後の確認方法を順に整理します。

URL棚卸しの完成形は「旧URLごとの処理が決まった表」

サイトマップは、サイト内のページ構成を示す資料です。一方、リニューアル用のURL一覧表は、旧サイトから新サイトへ何を引き継ぐかを決める作業台帳です。同じURL一覧でも、役割が異なります。

完成した表では、少なくとも次の質問に答えられる必要があります。

• この旧URLは、どこから見つかったか
• 現在も必要なページか、役割を終えたページか
• 検索流入、外部リンク、問い合わせ導線などの判断材料があるか
• 残す、更新、統合、削除、保留のどれか
• 新サイトでは、どのURLを表示するか
• 旧URLへアクセスされたとき、200、301、404のどれを返すか
• 誰が内容を確認し、公開前後に誰がテストするか

一覧表は、次のような列から始めると扱いやすくなります。

列	記録する内容	記入例
旧URL	現在公開されている完全なURL	https://example.jp/old-service/
ページ名・役割	何を伝え、どこへつなぐページか	旧サービス紹介、問い合わせへの入口
収集元	URLを見つけた場所	クロール、XMLサイトマップ、CMS、GA4
判断材料	流入、検索表示、被リンク、社内利用など	検索流入あり、営業資料から案内中
判断	残す・更新・統合・削除・保留	統合
新URL	公開後の最終URL	https://example.jp/service/
公開時処理	200・301・404	301
確認者・結果	内容確認者と公開前後のテスト	営業責任者確認済み、転送正常

URLだけでは、ページの重要性を判断できません。例えば、アクセス数が少ない会社概要でも、取引前の確認や採用応募者の安心につながっていることがあります。反対に、アクセス数が多い古い記事でも、現在のサービスと内容が合わなければ更新や統合が必要です。数値と事業上の役割を同じ行で見られるようにすることが、棚卸し表の要点です。

現行URLは一つの方法では集まり切らない

URL収集で起きやすい失敗は、XMLサイトマップだけ、またはサイト内クロールだけで一覧を完成させることです。どちらも有力な収集元ですが、それぞれ拾えないURLがあります。

サイト内クロールは、現在のページからリンクでたどれるURLを集めるのに向いています。しかし、どこからもリンクされていない過去ページ、広告専用のランディングページ、古いPDFは見つからないことがあります。XMLサイトマップも、更新設定が止まっていたり、対象外の投稿タイプがあったりすれば、全URLを保証するものではありません。

そのため、次の収集元を重ねます。

1. サイト内クロール

トップページからリンクをたどり、URL、タイトル、ステータスコード、canonical、見出しなどを取得します。まず全体像をつかむ方法です。グローバルメニューにない記事や、ページネーション、カテゴリーページも確認できます。

クロール結果には、画像、CSS、パラメーター付きURLなどが混ざる場合があります。最初から大量に削除せず、HTMLページ、PDF、画像・動画、システム用URLのように種類を分けてから整理します。

2. XMLサイトマップ

現在のサイトが検索エンジンへ伝えようとしているURLを確認できます。投稿、固定ページ、事例、商品など、サイトマップが複数に分かれている場合は、すべて取得します。

サイトマップに載っているのにクロールで見つからないURLは、内部リンクが切れている可能性があります。逆に、クロールで見つかるのにサイトマップへ載っていないURLは、意図的な除外か設定漏れかを確認します。差分そのものが、リニューアル前の点検材料になります。

3. CMSや管理画面の登録データ

WordPressなどのCMSでは、公開済みの固定ページや投稿を一覧で確認できます。独自CMSの場合も、記事や商品をCSV出力できることがあります。CMSの一覧には、サイト内リンクがなくても公開状態のページが残っている場合があります。

ただし、下書き、非公開、ゴミ箱、プレビューURLまで混ぜないよう、公開状態を別列へ記録します。公開中かどうか分からないデータは、推測で削除せず保留にします。

4. Search Console、アクセス解析、サーバーログ

検索結果に表示されたページ、実際に訪問されたランディングページ、サーバーへアクセスされたURLを確認します。サイト内から見つからないURLでも、検索結果や外部リンクから訪問されていることがあります。

数値は「ある・ない」だけでなく、集計期間をそろえます。季節性がある事業では、直近28日だけを見ると必要なページを低く評価することがあります。可能であれば直近1年と直近3か月を並べ、最近の変化と年間の役割を分けて見ます。計測タグが途中で変わった場合や、同意設定などで欠測がある場合は、「アクセス0」ではなく「データ不足」と記録します。

5. サイト外で使われているURL

広告、メール署名、メールマガジン、SNSプロフィール、Googleビジネスプロフィール、QRコード、紙のパンフレット、営業資料、取引先ページから案内しているURLも確認します。これらは検索流入が少なくても、事業上は重要です。

PDFや画像ファイルへ直接リンクされている場合もあります。新サイトでファイル名や保存場所を変えるなら、HTMLページと同じように行き先を決めます。問い合わせフォーム、送信完了ページ、予約、採用応募、会員向けページなどは、公開範囲と動作確認を別途付けます。

集めたURLは、表記を整えてから重複を判断する

複数の収集元を結合すると、同じページに見えるURLが重複します。例えば、HTTPとHTTPS、wwwありとなし、末尾のスラッシュありとなし、計測用パラメーター付きURLです。

ここで注意したいのは、見た目が似ているからといって、機械的に一行へまとめないことです。実際のサーバーが別URLとして200を返している場合、検索エンジンや外部リンクから別々に参照されている可能性があります。まず実際の応答、canonical、内部リンクの向き先を確認し、そのうえで正規URLと派生URLを分けます。

作業手順は次の通りです。

1. すべての収集元を一つの表へ追加する
2. 収集元を残したまま、完全一致の重複だけを除く
3. HTTP・HTTPS、www、末尾スラッシュ、パラメーターの違いをグループ化する
4. 現在のステータスコードと最終到達URLを確認する
5. 正規URL、転送済みURL、エラーURL、要確認URLへ分ける
6. 棚卸し日を記録し、公開直前まで変更履歴を残す

「URLを短くしたい」「英語のスラッグへ変えたい」といった希望は、この段階では判断欄にメモします。収集と変更を同時に始めると、旧URLの記録が失われやすいためです。

判断材料は検索順位だけでは足りない

残すか削除するかを決めるとき、検索流入は重要な材料ですが、それだけで結論を出すと事業に必要なページを落とします。URLごとに、次の四つの視点を付けます。

事業上の役割

ページが、問い合わせ、購入、採用、信頼形成、既存顧客の案内、法令表示、社内外の説明のどこに使われているかを確認します。会社概要、プライバシーポリシー、特定商取引法に基づく表記などは、直接の流入が少なくても必要です。

サービスページでも、問い合わせを直接生むページと、営業担当が説明後に送る補足ページでは役割が異なります。「アクセスが少ない」という理由だけで削除せず、誰がどの場面で使うかを書きます。

検索・アクセス・リンクの実績

Search Consoleでは、クリック、表示回数、検索語句、ページ単位の動きを確認します。アクセス解析では、ランディング、閲覧後の移動、問い合わせや購入への関与を見ます。外部リンクがあるページは、リンク元と内容の関係も確認します。

数値は、ページの価値を自動判定する点数ではありません。例えば検索流入が少なくても、広告から利用されているページがあります。逆に流入があっても、内容が古く、現在のサービスへ誤解を招くならそのまま残せません。数値の横に、判断理由を短く書くことが重要です。

内容の正確さと更新責任

料金、対応地域、営業時間、スタッフ、製品仕様、制度、事例などが現在も正しいかを確認します。更新が必要な場合は、誰が事実確認できるかも記録します。

同じテーマの記事が複数あるときは、古い方を消す前に、それぞれにしかない情報、検索されている言葉、外部リンクを確認します。統合先へ必要な内容を移した後で、旧URLの処理を決めます。

技術上の状態

現在のステータスコード、canonical、noindex、robots.txt、内部リンク、モバイル表示、フォームやダウンロードの動作を見ます。現在エラーだから不要とは限りません。重要ページが設定ミスで表示されていない可能性もあります。

不明点は「保留」にし、理由、確認先、期限を付けます。保留は放置ではなく、判断に必要な情報がそろっていないことを示す正式な状態です。

残す・更新・統合・削除・保留の基準

棚卸し表の判断は、五つにそろえると関係者間で認識を合わせやすくなります。

残す

URLも内容も引き続き使えるページです。URLを変えない場合は、新サイトでも同じURLで200を返すことを基本にします。デザインやCMSが変わっても、URLまで変える必要があるとは限りません。

「残す」には、本文だけでなく、タイトル、画像、PDF、構造化データ、フォームなどの確認項目を付けます。移植後に情報が欠けていないかをテストします。

更新する

ページの役割とURLは残す一方、内容、導線、写真、表現を現在に合わせるページです。検索流入があるページほど、タイトルだけを残して本文を全面的に別内容へ変えるのではなく、訪問者が求めている情報を確認します。

公開前に、誰が事実確認し、どの時点の情報へ更新したかを記録します。更新待ちのまま公開する場合は、古い情報が残らないよう公開範囲を調整します。

統合する

似た役割や検索意図を持つ複数ページを、一つのページへまとめる判断です。統合先には、旧ページから残す情報を先に移します。その後、各旧URLから内容の近い新URLへ301転送します。

複数の旧URLを一つへまとめること自体が問題なのではありません。問題になるのは、内容の関係が薄いページまで一律にトップページへ送ることです。各旧URLに対して、訪問者が求めていた情報を受け取れる最終URLを一つ決めます。

削除する

現在も将来も役割がなく、内容を引き継ぐ適切なページもない場合です。サイト内リンク、サイトマップ、メニュー、広告、資料などから案内を外し、旧URLは404を返すようにします。

削除ページをすべてトップページへ301転送すると、訪問者は探していた情報を見つけられません。内容が近い後継ページがある場合だけ転送し、ない場合は削除として扱います。

保留する

契約、法務、事業方針、掲載許可、更新担当、計測データなどが確認できず、判断できないページです。保留欄には「確認できていない理由」「確認する人」「判断期限」を書きます。

期限のない保留は、公開直前に忘れられます。新サイトへ一時的に残すのか、非公開で確認するのか、公開日までに決めるのかを明確にします。

旧URLと新URLは「一つの旧URLに一つの結果」で対応させる

転送表を作るときは、一つの旧URLに対して結果を一つにします。結果は、同じURLで200、新URLへ301、後継なしで404のいずれかです。条件によって行き先が変わる場合は、条件を別列へ書き、テスト方法も決めます。

新URL欄には、「サービスページ」のような名称ではなく、公開後の完全なURLを入れます。公開前は仮URLでも構いませんが、確定後に一括置換し、最終URLを固定します。

特に確認したいのは次のURLです。

• 検索流入や問い合わせが多いページ
• 外部サイトや取引先からリンクされているページ
• 広告、SNS、QRコード、印刷物で使っているページ
• PDF、画像、動画などへ直接アクセスされるURL
• フォーム、送信完了、予約、購入など計測に関わるURL
• HTTP・HTTPS、wwwあり・なし、サブドメインの違い
• パラメーター付きURLや、旧CMS特有のURL

転送は、旧URLから最終URLへ直接つなぎます。旧URLから中間URL、その先でさらに新URLへ移る転送チェーンは避けます。公開後にURLを変更した履歴が複数ある場合も、古い転送設定を見直し、可能な範囲で最終到達先へ直接つなぎ直します。

一覧表を公開前のテスト仕様書へ変える

URL一覧表は、判断が終わった時点で完成ではありません。公開前は、そのままテスト仕様書として使います。各行に「期待する結果」と「実際の結果」を追加すると、漏れを見つけやすくなります。

公開前の確認項目は次の通りです。

1. 新URLが予定どおりの内容を200で表示する
2. 旧URLが一回の301で正しい新URLへ到達する
3. 削除URLが404を返し、関係のないページへ転送されない
4. 新サイトの内部リンクが旧URLではなく新URLを直接参照する
5. canonical、XMLサイトマップ、構造化データが新URLにそろっている
6. ステージング用のnoindexやクロール制限が公開後に残らない
7. PDF、画像、フォーム、完了ページ、予約、検索などが動作する
8. 計測タグが新URLでも記録できる

全URLを手作業で開くのではなく、一覧表を使って自動確認と目視確認を分けます。ステータスコード、転送先、転送回数はまとめて確認し、重要ページの内容、フォーム、ダウンロードは人が操作します。

「公開時処理」列とテスト結果が一致しない行は、公開前の未完了項目です。担当者名と再確認日を付け、修正後に結果を上書きせず履歴を残します。

公開後は旧URL一覧から再度アクセスする

新サイトのトップページやメニューが正しく見えても、移行が成功したとは限りません。公開後は、保存しておいた旧URL一覧を起点に再クロールし、想定した200、301、404になっているか照合します。

優先順位は、次の順にすると対応しやすくなります。

1. 問い合わせ、購入、応募など成果に直結するURL
2. 検索流入、被リンク、広告、外部資料からの利用が多いURL
3. 主要サービス、会社情報、法令表示、フォーム
4. 内部リンク、canonical、サイトマップの不一致
5. 低利用の過去ページや補助ファイル

Search Consoleでは、旧URLと新URLの検索表示やインデックス状況を確認します。アクセス解析では、新しいランディングページへ流入が移っているかを見ます。サーバーログやエラーログを確認できる場合は、想定外の404や古いURLへの継続アクセスを拾います。

公開直後に数値が動いても、一日の増減だけで結論を出しません。重要なのは、対応表どおりに転送・表示され、想定外のエラーが増えていないかを確認することです。問題を見つけたら、旧URL、新URL、期待結果、実際の結果を同じ行へ記録して修正します。

リダイレクト設定の記事とは工程を分けて使う

URL棚卸しとリダイレクト設定は連続する作業ですが、同じものではありません。

この記事で扱っているのは、実装前の準備です。現行URLを集め、役割とデータを確認し、残す・統合・削除を決め、旧URLと新URLの対応表を作ります。

サーバーやWordPressで301をどのように設定するか、転送が正しく動くかを技術的に確認する段階は、既存の「検索順位を保つリダイレクト設定完全マニュアル」へ分けて確認してください。先に棚卸し表ができていれば、実装担当者は「どこからどこへ転送するか」を推測せずに設定できます。

制作会社へ渡す最低限のURL一覧表

すべての数値や技術情報を自社だけで埋める必要はありません。制作会社へ相談する段階では、次の見出し行を用意し、分かる範囲と未確認を分ければ始められます。

旧URL｜ページ名・役割｜収集元｜現在の状態｜流入・検索表示｜外部リンク・社外利用｜判断｜新URL｜公開時処理｜内容確認者｜公開前結果｜公開後結果

表は一枚でも構いませんが、行数が多い場合は、次の三つのシートに分けると管理しやすくなります。

• 全URL台帳：収集したURLと判断材料を残す
• 転送表：旧URL、新URL、301・404の実装対象だけを抜き出す
• テスト結果：公開前後の期待結果、実測結果、修正履歴を残す

自社側は、ページの事業上の役割、内容の正しさ、確認できる担当者を判断します。制作会社は、URL収集、現在の応答、CMSやサイト構造、転送方法、公開後の確認を支援します。検索やアクセスのデータがある場合は、削除や統合の根拠として共有します。

一覧表を完全に埋めてから相談する必要はありません。「このURLは営業資料で使っている」「このページは担当者が分からない」「この二つは同じサービスに見えるが統合してよいか判断できない」といった未確認事項が書かれている方が、調査範囲を決めやすくなります。

まとめ：URL棚卸しは、消すページを探す作業ではない

ホームページリニューアル前のURL棚卸しは、古いページを減らすためだけの作業ではありません。これまで使われてきたURL、検索や外部リンクから訪問される入口、社内外で案内している資料、問い合わせや購入につながる導線を、新サイトへどう引き継ぐか決める作業です。

現行URLは、クロール、XMLサイトマップ、CMS、Search Console、アクセス解析、サーバーログ、社外で使っているURLを重ねて集めます。そのうえで、事業上の役割、検索・アクセス・リンクの実績、内容の正確さ、技術状態を確認し、残す・更新・統合・削除・保留へ分けます。

最後に、各旧URLへ新URLと200・301・404を割り当て、公開前後のテスト結果まで同じ表へ残します。一行ごとの行き先が決まっていれば、リニューアルでページ数や構成が変わっても、必要な入口を見失いにくくなります。