この記事の要点
- リダイレクト設定は公開日当日ではなく、旧URLの全件棚卸しと新旧URL対応表(リダイレクトマップ)の作成から始めるのが正解です。
- 301リダイレクトを正しく設定することで、旧URLに蓄積された検索エンジンの評価を新URLへ引き継げます。設定漏れや誤設定は検索順位の長期低下につながります。
- 制作会社に依頼する場合も、リダイレクト対応範囲を事前に書面で確認することが、トラブル防止の最重要ポイントです。
ホームページのリニューアルで最も見落とされがちな作業が、URL移行時のリダイレクト設定です。デザインや機能の改善に注力するあまり、公開直後に検索順位が大幅に下落するケースは少なくありません。
本記事では、リニューアル前の準備からサーバ別の設定手順、公開後の確認作業まで、URL移行を失敗なく進めるための一連の手順を解説します。技術的な実装は制作会社に依頼する場合でも、発注前に仕組みと確認ポイントを把握しておくことで、設定漏れや認識齟齬を防げます。
まず何をすべきか?リニューアル前に着手する3つの準備
リダイレクト設定は公開日当日ではなく、旧URLの棚卸しと新URL対応表の作成から始めるのが正解です。この準備を怠ると、設定漏れや誤った転送先が生じ、公開後に検索順位が回復するまでの期間が長引く原因になります。
リニューアル前に済ませるべき準備は次の3点です。
- 旧URLの全件洗い出し(クロール)
- 新旧URL対応表(リダイレクトマップ)の作成
- 廃止ページの扱いの確定
各手順を順に確認します。
旧URLを全件書き出すURLクロールの方法
旧サイトに存在するURLを漏れなく把握することが、リダイレクト設定の精度を左右します。
担当者が準備すべきもの
制作会社に依頼する場合でも、以下の2点を事前に用意しておくと作業がスムーズに進みます。
| 用意するもの | 具体的な内容 | 備考 |
|---|---|---|
| 現行サイトのXMLサイトマップ | /sitemap.xml のURL |
なければ制作会社に確認 |
| Google Search Consoleのカバレッジレポート | 「有効」ステータスのURL一覧をCSVエクスポート | 権限があれば担当者でも取得可能 |
制作会社に依頼する場合の確認ポイント
クロール作業は一般的にScreaming FrogやSitebulbといったツールを使います。担当者が自分で操作する必要はありませんが、以下の点を制作会社に書面で確認してください。
- クロール対象のURLは何件か(リスト化して共有してもらえるか)
- noindex・パスワード保護ページも含めて洗い出すか
- クロール完了後にURL一覧をCSV形式で納品してもらえるか
つまずきやすい点: ページネーション(
?page=2など)や絞り込みURLが大量に存在するサイトでは、URLの件数が想定より大幅に増えることがあります。事前に制作会社と「管理対象とするURLの定義」を合意しておくと、対応表の作成コストを抑えられます。
新旧URL対応表(リダイレクトマップ)の作り方
リダイレクトマップとは、旧URLと新URLを1対1で対応させた表のことです。この表が完成して初めて、サーバやCMSへの設定作業に進めます。
基本フォーマット
| 旧URL | 新URL | ステータス | 優先度 |
|---|---|---|---|
/service/a.html |
/services/a/ |
301(移行) | 高 |
/blog/2020/01/post.html |
/blog/post-slug/ |
301(移行) | 中 |
/old-campaign/ |
/(トップページ) |
301(廃止→代替) | 低 |
/temp-page/ |
設定なし | 410(廃止・削除) | 低 |
「ステータス」欄の使い分け
- 301: 旧URLから新URLへ恒久的に転送する場合に使います。SEO評価を引き継ぐ標準的な選択です。
- 410: 転送先となる代替ページが存在せず、コンテンツを完全に廃止する場合に使います。404ではなく410を返すことで、検索エンジンにそのURLが意図的に削除されたことを明示できます。
301と302の違いやSEO評価への影響については、次のセクションで詳しく説明します。
作成時の3ステップ
- 旧URLの全件リストをCSVで準備します(前項のクロール結果を使います)。所要時間の目安は、URLが100件以下であれば半日程度です。
- 各旧URLに対して、新サイトの最も関連性が高いページを新URLとして割り当てます。担当者がコンテンツの内容を把握している場合は、制作会社とともに対応を確認すると精度が上がります。
- 廃止ページで代替先が存在しないものは「410」と明記し、設定対象から除外します。
つまずきやすい点: 旧URLのすべてに新URLを対応させようとすると、関連性の薄いページへ無理やり転送するケースが生じます。関連性の低い転送先を設定しても検索エンジンの評価引き継ぎ効果は限定的です。代替先がなければ410にする判断を迷わず行うことが重要です。
3つ目の準備: 廃止ページの扱いを確定する
廃止ページとは、新サイトには掲載しないと決まったページのことです。リダイレクトマップを作る段階で、ページごとに次の3択から扱いを決めます。
| 扱い | 設定 | 使う場面 |
|---|---|---|
| 新URLへ転送 | 301リダイレクト | 同等の内容が新サイトに存在する |
| 完全廃止 | 410 Gone | 内容が古く代替コンテンツもない |
| 暫定的にトップへ転送 | 301(トップページ宛て) | 代替ページが後日公開予定の場合のみ |
トップページへの一律転送は「廃止ページの一時措置」として機能しますが、関連性が低いためSEO評価の引き継ぎは期待できません。恒久的な対応としては使わないことを制作会社と合意しておいてください。
301リダイレクトとは?302との違いとSEOへの影響
301リダイレクトとは、旧URLへのアクセスを新URLへ恒久的に転送し、検索エンジンの評価を新URLに引き継がせる設定のことです。リニューアルでURLを変更する際にこの設定が抜けると、旧URLへの被リンクや検索評価が新URLに引き継がれず、順位が一時的に大きく下落するリスクがあります。
301と302の使い分け早見表
リダイレクトには複数の種類があり、目的によって使い分けが必要です。最もよく混同されるのが301と302です。
| ステータスコード | 意味 | SEO評価の引き継ぎ | 主な用途 |
|---|---|---|---|
| 301 | 恒久的な転送 | 引き継がれる | URLリニューアル、ドメイン移行 |
| 302 | 一時的な転送 | 原則引き継がれない | メンテナンス中の一時退避、A/Bテスト |
| 308 | 恒久的な転送(POSTメソッド保持) | 引き継がれる | APIやフォームを含む恒久転送 |
| 307 | 一時的な転送(POSTメソッド保持) | 原則引き継がれない | フォームを含む一時転送 |
ホームページリニューアルでURLを変更する場合は、原則として301を使います。302を誤って使うと、検索エンジンは「旧URLが正規のページ」と判断し続け、新URLにSEO評価が移らない状態が続きます。
302が適切な場面は、「キャンペーン期間中だけ特定ページに転送する」「システムメンテナンス中に一時的に別URLへ誘導する」といった、元のURLに戻ることが前提の一時的な転送に限定されます。
リダイレクトを設定しないとSEO評価はどうなるか
301リダイレクトを設定せずにURLを変更した場合、検索エンジンには旧URLと新URLが「別々のページ」として認識されます。その結果、次の3つの問題が連鎖的に起きます。
1. 旧URLが404エラーとして扱われる
リダイレクト設定がなければ、旧URLへのアクセスはページが存在しない状態(404エラー)になります。検索エンジンのクローラは404を検出すると、一定期間経過後にそのURLをインデックスから除外します。
2. 被リンクの評価が失われる
他サイトから旧URLへ向けられていた被リンク(被リンクはSEOで「外部からの評価票」として機能する要素です)は、リダイレクト先がなければ新URLには引き継がれません。長年かけて積み上げた被リンクの効果がゼロになるリスクがあります。
3. 検索順位の回復に時間がかかる
新URLは公開直後には検索エンジンにとって「評価の積み上げがない新規ページ」として扱われます。301リダイレクトで評価を引き継いだ場合と比較して、元の順位水準に戻るまでの期間が長くなる傾向があります。具体的な回復期間はサイトの規模や被リンク状況によって異なるため、「必ず◯ヶ月以内に戻る」と断言できる数値はありません。
なお、301リダイレクト設定後も検索順位がしばらく変動することは珍しくありません。Googleが新URLを認識・再評価するには一定のクロール期間が必要なためです。公開後の変動を「失敗」と誤認しないよう、Search Consoleで新URLのインデックス状況を継続的に確認することが重要です。確認方法は「公開後に必ず行う動作確認と検索エンジンへの通知手順」のセクションで詳述します。
サーバ別・CMS別の301リダイレクト設定手順
設定方法はサーバの種類とCMSによって異なるため、自社環境を確認してから着手することが重要です。以下では代表的な3つの環境ごとに、発注者として押さえておくべき確認ポイントと設定の概要を整理します。
Apacheサーバ(.htaccess)での設定
Apacheは国内のレンタルサーバの多くが採用しており、.htaccessというファイルに記述することでリダイレクトを制御します。
制作会社に依頼する場合、以下の点を書面で確認してください。
| 確認項目 | 確認の目的 |
|---|---|
.htaccessの編集権限が与えられているか |
サーバ環境によっては制限されている場合があります |
| リダイレクトマップをそのままコードに反映できるか | URLの件数が多い場合、自動生成ツールを使うかどうかで工数が変わります |
| 設定後のステータスコード検証を誰が行うか | 全件が301を返すかどうかの確認作業を含めて依頼範囲に含めてください |
技術担当者向けの補足として、個別URLのリダイレクトは Redirect 301 ディレクティブで記述し、URLパターンをまとめて処理する場合は RewriteRule を使います。設定ファイルは上から順に評価されるため、記述の順序が意図しない動作を引き起こすことがあります。制作会社に依頼する際は「設定後に全URLのステータスコードを一覧で報告してほしい」と明示することをおすすめします。
Nginxサーバでの設定
Nginxはクラウドサーバ(AWS、Google Cloud等)や高トラフィックのサイトで採用されることが多い構成です。.htaccessは使わず、サーバの設定ファイル(nginx.confまたは仮想ホスト設定ファイル)に直接記述します。
発注者として把握しておくべき点は、Nginxの設定変更はサーバの再起動またはリロードが必要という点です。レンタルサーバではなくVPS・クラウド環境の場合、設定変更のたびに操作が必要になるため、公開当日の作業フローを事前に制作会社と確認してください。
| 確認項目 | 確認の目的 |
|---|---|
| サーバの管理権限が制作会社にあるか | 権限がない場合は別途インフラ担当者との連携が必要です |
| 設定変更後のリロード作業は誰が行うか | 公開タイミングの調整に関わります |
| 設定ファイルのバックアップ手順は確立されているか | 誤記述でサイト全体が停止するリスクがあります |
WordPressプラグインを使う場合の注意点
WordPressサイトのリニューアルでは、「Redirection」などのプラグインを使ってリダイレクトを設定するケースがあります。管理画面から操作できるため、技術的なハードルが低い反面、いくつかの制約があります。
プラグインによるリダイレクトの主な制約:
- リダイレクト処理のタイミングが遅い。サーバレベルではなくWordPressのPHP処理内で実行されるため、
.htaccessやnginx.confに直接書く場合と比べて処理が一段階増えます。URLの件数が多いサイトでは表示速度への影響を検討する必要があります。 - WordPressが起動しないと動作しない。サーバエラーやWP本体の障害が発生した場合、リダイレクトも機能しなくなります。
- プラグイン削除時にリダイレクト設定が失われる。設定のエクスポートと保管を必ず制作会社に依頼してください。
これらの特性から、恒久的なURL移行には.htaccessまたはNginx設定ファイルへの直接記述が技術的に望ましい選択です。プラグインは「一時的な転送」や「少数のURLの例外処理」に用途を限定するとリスクを抑えられます。
発注者向けの確認ポイント: 「リダイレクト設定にプラグインを使いますか?サーバ設定ファイルへの直接記述とどちらを推奨しますか?その理由を教えてください」と制作会社に質問することで、対応方針の適切さを判断できます。
環境別の特性をまとめると次のとおりです。
| 環境 | 設定場所 | 発注者が確認すべき主なポイント |
|---|---|---|
| Apacheサーバ | .htaccess |
編集権限の有無、全件検証の実施 |
| Nginxサーバ | nginx.conf等 |
管理権限の所在、リロード作業の担当 |
| WordPress(プラグイン) | 管理画面 | 設定のエクスポート保管、速度への影響 |
具体的な設定ミスのパターンや、リダイレクトループ・チェーンリダイレクトの見分け方については後述します。
ドメイン移行を伴うリニューアルで追加すべき対応
ドメインごと変更する場合は、URL単位のリダイレクトに加えて、Google Search Consoleでの変更通知とサイトマップ再送信が必須です。URL単位の設定だけでは、検索エンジンへの「ドメインそのものが移転した」という通知が届かないため、評価の引き継ぎに余分な時間がかかります。
Google Search ConsoleのURL変更ツールの使い方
URL変更ツールとは、旧ドメインから新ドメインへの移転をGoogleに正式に申告するSearch Console上の機能です。サーバ側のリダイレクト設定を補完する役割を持ちます。
前提条件として確認すること
URL変更ツールを利用するには、以下の3点がすべて満たされていることが必要です。
| 条件 | 内容 |
|---|---|
| 旧ドメインのプロパティ | Search Consoleに所有権確認済み |
| 新ドメインのプロパティ | Search Consoleに所有権確認済み |
| リダイレクト設定 | 旧ドメイン全体から新ドメインへの301リダイレクトが実装済み |
申請手順
- Search Consoleで旧ドメインのプロパティを開きます。
- 左メニューの「設定」→「アドレス変更」を選択します。
- 移転先の新ドメインのプロパティを選択します。
- 「確認してページを更新」ボタンを押し、301リダイレクトの実装をGoogleが自動検証するのを待ちます。
- 検証が通過したら「サイトの移動」ボタンで申請を完了します。
発注者として確認すべき点: URL変更ツールの操作はSearch Consoleの所有権を持つアカウントでしか実施できません。制作会社が代行する場合、御社のSearch Consoleアカウントへのアクセス権限付与が必要になります。事前に権限付与の手続きを確認しておくことを推奨します。
なお、Google公式ヘルプによると、URL変更ツールによる移転シグナルはGoogleが処理を完了するまでに数週間かかる場合があります(出典: Google Search Central「サイトの移動について」)。申請後も検索順位が即日変わるわけではないため、数週間単位での観察が必要です。
申請後に行うサイトマップ再送信
URL変更ツールの申請と合わせて、新ドメインのSearch Consoleから新しいサイトマップを送信します。手順は以下のとおりです。
- 新ドメインのSearch Consoleプロパティを開きます。
- 「サイトマップ」メニューから新サイトマップのURLを入力して送信します。
- ステータスが「成功しました」になったことを確認します。
旧ドメインのサイトマップは削除する必要はありませんが、旧URL宛のサイトマップが残っていると混乱を招く場合があるため、制作会社に確認することを推奨します。
旧ドメインのDNS・サーバはいつまで維持すべきか
旧ドメインのサーバとDNS設定は、新ドメインへの移行後も一定期間維持する必要があります。理由は2つあります。1点目は、古いURLを記録しているブックマークや外部リンクから来るアクセスをリダイレクトで受け止めるためです。2点目は、検索エンジンが旧URLのインデックスを整理し終えるまで、クロールのリクエストが旧サーバに届き続けるためです。
維持期間の目安と根拠
維持期間については、案件の規模やサイトの被リンク数によって変わるため、一律の数字を断言することは適切ではありません。一般的に、リダイレクト設定を維持する期間は「Search Consoleの旧プロパティへのクリック数がほぼゼロになるまで」を目安にします。Search Consoleのパフォーマンスレポートで旧ドメイン宛のクリックとインプレッションをモニタリングし、数値が安定して低下した時点でサーバ縮小を検討することが現実的です。
コスト面での注意
旧ドメインのサーバ維持には費用がかかります。発注時の見積もりに旧サーバの維持費用が含まれているかどうかを確認してください。含まれていない場合、公開後に追加費用が発生することがあります。
DNS設定を変更するタイミング
DNSのTTL(Time to Live)とは、DNSレコードがキャッシュされる時間のことです。ドメイン移行前にTTLを短く設定しておくと、新しいDNS設定が世界中のサーバに伝播するまでの時間を短縮できます。この作業は制作会社またはドメイン管理事業者が担当することが多いため、「移行前にTTLを変更するか」を確認項目に加えてください。
このセクションで制作会社に確認すべき項目まとめ
| 確認項目 | 理由 |
|---|---|
| Search Consoleへのアクセス権限付与の手続き | URL変更ツール申請に必要 |
| サイトマップ再送信の対応範囲に含まれているか | 公開後の評価引き継ぎに直結する |
| 旧ドメインのサーバ維持期間と費用の取り決め | 公開後の追加費用発生を防ぐ |
| DNS TTLの事前変更対応 | 移行時の伝播遅延を最小化する |
リニューアル全体の発注フローや一般的なチェックリストは、失敗しないホームページリニューアルの進め方で詳しく解説しています。本記事ではリダイレクト・URL移行に固有の確認事項に絞って説明しています。
実装者が見てきた設定ミス上位5パターン
リダイレクト設定のミスは公開後しばらく気づかれないことが多く、発見が遅れるほど検索順位の回復に時間がかかります。ここでは、リニューアル案件で繰り返し発生しやすいミスのパターンを整理します。
発注者側でこれらのパターンを事前に把握しておくことで、制作会社への確認や検収時のチェックに役立てられます。
よくある設定ミス上位5パターン
| # | ミスのパターン | 発生しやすい状況 | 検収時の確認ポイント |
|---|---|---|---|
| 1 | リダイレクトループ | 同一URL間で転送が循環している | ブラウザでアクセスしてもページが表示されない |
| 2 | チェーンリダイレクト(多段転送) | 過去の移行設定が残ったまま重なっている | 旧URL→中間URL→新URLと2段階以上の転送になっている |
| 3 | 設定漏れ(一部URLが404) | URL数が多く対応表から抜け落ちた | 旧URLにアクセスして404が返る |
| 4 | canonicalタグとの競合 | リダイレクト先のURLが別URLをcanonicalに指定している | Search Consoleのカバレッジレポートに警告が出る |
| 5 | httpとhttpsの混在 | httpsへの切り替えと同時リニューアルで設定が分散した | http://旧URLへのアクセスが正しくhttps://新URLに届かない |
リダイレクトループとチェーンリダイレクトの見分け方
リダイレクトループとは、AがBへ、BがAへ転送するように設定が循環している状態です。ブラウザは「このページはリダイレクトが多すぎます」というエラーを表示し、ユーザもクローラも到達できなくなります。
チェーンリダイレクトとは、AがBへ、BがCへと2段階以上の転送が連なっている状態です。1回の転送で目的地に届かないため、クローラの処理効率が落ちます。Google公式ドキュメント(Googleの推奨するリダイレクトの実装)では、リダイレクトチェーンは可能な限り1段階に収めることを推奨しています。
発注者として確認すべき点は1点です。「すべての旧URLが1回の転送で新URLに届いているか」を制作会社に書面で確認し、公開前にステータスコードの一覧レポートを提出してもらいましょう。詳しい確認ツールの使い方はセクション6で解説します。
canonicalタグとの競合が起きるケース
canonicalタグとは、同じ内容のページが複数URLで存在するとき、検索エンジンに「こちらが正規のURLです」と伝えるタグです。
リダイレクトとcanonicalが同時に設定されると、次のような競合が起きることがあります。
- 旧URLから新URLへ301リダイレクトを設定した
- 新URLのHTMLには、さらに別のURL(例: wwwあり版やhttps版)をcanonicalに指定している
- 結果として、検索エンジンがどのURLを正規として扱えばよいか判断しにくくなる
この状態は、Search Consoleのカバレッジレポートに「canonicalで指定されたページが選択されていません」などの警告として現れることがあります。
リダイレクト先のURLとcanonicalタグが指すURLは一致させることが基本です。制作会社に依頼する際は「リダイレクト先のURLとcanonicalの一致確認を実施しているか」を確認事項の1つに加えてください。
httpとhttpsの混在(同時移行時のリスク)
httpsへの切り替えとURLリニューアルを同時に行う場合、次の4つのパターンすべてで転送が正しく動作するかを確認する必要があります。
http://旧URL→https://新URLhttps://旧URL→https://新URLhttp://新URL→https://新URLhttps://新URL(最終到達先)
このうち1つでも設定が抜けると、古いURLを踏んだユーザやリンクからのアクセスが404になります。制作会社に納品物として「4パターンの転送確認結果」を求めるとよいでしょう。
公開後に必ず行う動作確認と検索エンジンへの通知手順
公開直後にリダイレクトの全件確認とSearch Consoleへのサイトマップ送信を完了させることで、評価の引き継ぎを最短化できます。公開後に「なんとなく確認した」で済ませると、設定漏れが数週間後に順位低下として表れるケースがあります。
ステータスコードの一括確認と制作会社への依頼事項
リダイレクトの動作確認は、旧URLが「1回の転送で」新URLに到達しているかどうかを全件チェックするのが基本です。制作会社に依頼している場合は、以下の確認レポートの提出を検収条件として明示してください。
制作会社に提出を求める確認レポートの内容
| 確認項目 | 期待する結果 | 注意点 |
|---|---|---|
| 旧URLのHTTPステータスコード | 301 | 302や200になっていないか |
| リダイレクト先URL | 対応表どおりの新URL | 別ページに飛んでいないか |
| リダイレクト回数(ホップ数) | 1回 | 2回以上はチェーンリダイレクト疑い |
| 最終的なステータスコード | 200 | 404や503になっていないか |
| httpとhttpsの混在 | httpsで統一 | 混在はセキュリティ警告の原因になる |
自社内で確認する場合、ブラウザの開発者ツール(F12キー→ネットワークタブ)で個別URLのステータスコードを目視確認できます。対象URLが数十件以上ある場合は、制作会社がScreaming FrogやGSC APIなど一括チェックツールで出力したCSVレポートを受け取り、対応表と照合する方法が現実的です。
リダイレクトループとチェーンリダイレクトの詳細な見分け方はセクション5(実装者が見てきた設定ミス上位5パターン)で解説しています。
発注者として確認すべきポイント(つまずきやすい点)
制作会社に確認する際、「リダイレクト設定は完了していますか」と聞くだけでは不十分です。「全旧URLのステータスコード一覧をCSVで提出してください」と具体的に依頼することで、設定漏れの見落としを防げます。
インデックス再登録リクエストのタイミングと優先順位
リダイレクト設定の動作確認が完了したら、次にSearch Consoleでの通知作業を行います。手順と優先順位は以下のとおりです。
公開後の通知作業(実施順)
新URLのサイトマップを送信する(公開当日) Google Search Console の「サイトマップ」メニューから新しいサイトマップURLを送信します。既存のサイトマップURLが変わっていない場合も、再送信して更新を知らせてください。 つまずきやすい点:旧サイトマップのURLをそのまま残しておくと、削除済みURLがGoogleに伝わりにくくなります。旧サイトマップは削除するか、新URLのみを含む内容に差し替えてください。
優先度の高いURLをURL検査ツールでリクエストする(公開当日〜翌日) トップページ、サービスページ、流入数の多いブログ記事など、事業への影響が大きいページを優先してインデックス登録リクエストを送ります。Search ConsoleのURL検査ツールでURLを入力し、「インデックス登録をリクエスト」を選択してください。 つまずきやすい点:全URLにリクエストを送ろうとすると作業が膨大になります。サイトマップ送信でGoogleに一括通知したうえで、重要ページのみ個別リクエストするのが現実的な優先順位です。
ドメイン移行を伴う場合はURL変更ツールを使用する(公開当日) ドメインごと変更した場合の手順はセクション4(ドメイン移行を伴うリニューアルで追加すべき対応)で詳しく解説しています。
Search Consoleのカバレッジレポートを1〜2週間後に確認する 新URLが「インデックス済み」に移行しているか、旧URLが「リダイレクトされたページ」として処理されているかを確認します。「クロール済み・インデックス未登録」が多い場合はコンテンツ品質の問題が疑われるため、別途対応が必要です。
確認スケジュールの目安
| タイミング | 確認内容 |
|---|---|
| 公開当日 | リダイレクト全件のステータスコード、サイトマップ送信、重要URL個別リクエスト |
| 公開1週間後 | Search Consoleカバレッジレポートでエラーがないか |
| 公開1か月後 | 主要キーワードの検索順位の変動確認 |
| 公開3か月後 | 旧URLがGoogleのインデックスから消えているか |
検索順位が戻るまでの期間はサイト規模や被リンクの質によって異なるため、一定の期間を見込んだうえで定点観測を続けることが重要です。ドメイン移行後の順位回復についてはFAQセクションで補足しています。
リダイレクト設定の確認作業を制作会社任せにしてしまい、検収時に見落としが発覚するケースは少なくありません。当社(株式会社ノーティックラボ)では、累計20社以上のWeb制作・AI導入支援の経験をもとに、リニューアルプロジェクトでURL移行を扱う際の確認体制を次のセクションで詳しく説明します。
制作会社へ依頼する場合の確認事項と発注チェックリスト
リダイレクト設定は制作会社の作業範囲に明示されていないことがあるため、見積もり前に対応範囲を書面で確認することが不可欠です。
一般的なリニューアルの発注プロセスや費用相場については「失敗しないホームページリニューアルの進め方」で詳しく解説しています。このセクションではURL移行・リダイレクト設定に固有の確認事項に絞ります。
発注前に質問すべき5項目
制作会社への発注前に、以下の5点をメールや仕様書で書面確認してください。口頭での確認は後のトラブル原因になります。
| # | 確認項目 | 確認が必要な理由 |
|---|---|---|
| 1 | 旧URLの全件クロールと新旧対応表の作成は作業に含まれるか | 含まれない場合、設定漏れが発生してもベンダー起因の瑕疵として扱われない |
| 2 | リダイレクト設定はサーバ設定ファイルへの直接記述か、WordPressプラグインか | プラグインのみの対応は恒久的移行として不十分なことがあります(詳細はセクション3を参照) |
| 3 | 公開後に全URLのステータスコードをCSVレポートで提出してもらえるか | 301で転送されているか、ホップ数が1回かを数値で確認するためです |
| 4 | 旧ドメインのサーバ維持期間と費用はどのように扱うか | ドメイン移行を伴う場合、旧サーバの維持費が追加発生します(目安は「旧サイトのSearch Consoleクリック数がゼロになるまで」) |
| 5 | Google Search ConsoleのURLアドレス変更通知とサイトマップ再送信は作業範囲に含まれるか | 含まれない場合は御社側で対応が必要です |
つまずきやすい点: 「SEO対策込み」とうたっている制作会社でも、リダイレクト設定の検収レポートを標準提供しているケースは多くありません。「301設定はします」と言われても、全件確認の証跡が出てくるかどうかは別問題です。事前に「CSVレポートの提出」を要件として明記してください。
Nortiq LabsがリニューアルでURL移行をどう扱うか
当社のWebリニューアル(300,000円から)では、URL移行・リダイレクト設定を以下のプロセスで標準対応しています。
公開前の工程
- Screaming Frogを使った旧URLの全件クロール(対象ページ数に上限なし)
- 新旧URL対応表の作成とクライアント確認
- サーバ設定ファイルへの直接記述(Apache:
.htaccess、Nginx:serverブロック) - ステージング環境での全件ステータスコード検証
公開後の工程
- 本番環境での全URLステータスコード確認
- CSVレポートの提出(URL・ステータスコード・リダイレクト先・ホップ数を列記)
- Google Search ConsoleへのURLアドレス変更通知とサイトマップ送信
ドメイン移行を伴う案件では、旧ドメインのサーバ維持期間についても事前に合意書面を取り交わしています。
代表はUC Berkeley Data Science在学中のAIエンジニアで、サーバ設定やクロール解析を自ら実装します。コンサルティングファームやWebディレクタへの再委託はなく、技術的な判断と実装を同一人物が担当するため、現場の確認齟齬が発生しません。
御社のサイトがリニューアルを検討中であれば、現状のURL構造とSEO評価の引き継ぎ可否を無料で診断しています。公開前の段階からご相談いただくことで、設定漏れのリスクを事前に潰すことができます。
よくあるご質問
301リダイレクトを設定しないと検索順位はどうなりますか?
旧URLが404エラーになり、そのURLに蓄積されていた被リンク評価と検索エンジンの評価が新URLに引き継がれません。結果として、リニューアル後に検索順位が大幅に低下するリスクがあります。301リダイレクトを設定することで、評価の引き継ぎを最大化できます。
ドメイン移行後、検索順位が戻るまでどのくらいかかりますか?
設定が正しく完了している場合、Googleが新旧URLの関係を認識してインデックスを更新するまでの期間は案件ごとに異なります。サイト規模が大きいほど、または旧サイトのクロール頻度が低いほど時間がかかる傾向があります。Google Search Consoleのカバレッジレポートと検索パフォーマンスレポートで週単位のモニタリングを継続することが重要です。
WordPressのリニューアルで301リダイレクトはプラグインで対応できますか?
「Redirection」などのプラグインで設定自体は可能です。ただし、WordPress本体に障害が起きるとリダイレクトも機能しなくなるリスクがあります。恒久的な移行では、.htaccessなどサーバ設定ファイルへの直接記述を推奨します。詳しくはセクション3の「WordPressプラグインを使う場合の注意点」を参照してください。
リダイレクト設定は制作会社に任せてよいですか?自社でやる必要はありますか?
サーバ設定ファイルの編集は制作会社に依頼することが現実的です。ただし、「依頼したから終わり」ではなく、CSVレポートを受け取り全URLが正しく転送されているかを発注者側で確認することが重要です。確認の観点は本記事のセクション6(公開後の動作確認)を参照してください。
httpsへの切り替えとURLリニューアルを同時に行う場合、注意点はありますか?
httpからhttpsへの切り替えと、URLパス構造の変更を同時に行うと、リダイレクトの組み合わせが複雑になります。「http → https」と「旧パス → 新パス」を1回の301で処理できるよう設定することが重要です。2回に分けると不要なリダイレクトチェーンが発生し、表示速度とクロール効率に悪影響が出ます。詳しくはセクション5の「リダイレクトチェーンの見分け方」を参照してください。
リダイレクト設定の費用はどのくらいかかりますか?
単独でのリダイレクト設定のみを依頼する場合の費用は、対象URL数や環境によって異なります。Nortiq Labsではリニューアル全体のプロジェクト(300,000円から)の中にURL移行対応を含めて提供しています。現在お使いのサーバ環境や対象URL数をお知らせいただければ、無料診断の中でお見積もりの目安をご案内できます。



