Webサイトリニューアルで引き継ぐもの｜URL・SEO・計測・問い合わせ導線の移行チェック

Webサイトをリニューアルするときは、デザインや文章だけでなく、旧サイトが持っていたURL、SEO設定、アクセス解析、問い合わせフォームなども新サイトへ引き継ぐ必要があります。

新しいサイトが問題なく表示されていても、旧URLから適切なページへ移動できない、アクセスを計測できない、問い合わせ通知が届かないといった状態では、業務上の移行が完了したとはいえません。

Webサイトリニューアルは、新しい画面を公開する作業ではなく、旧サイトが持つ検索・計測・問い合わせ・管理の仕組みを新サイトへ移す作業です。

最初に行うことは、旧サイトから何を残し、何を変更し、誰が確認するのかを一覧にすることです。

Web制作の現場では、公開画面の確認を優先するあまり、管理画面の権限、計測タグ、通知メール、旧URLからの転送など、表から見えにくい項目が後回しになることがあります。そのため、画面・検索・計測・問い合わせ・管理を分けて確認することが重要です。

この記事では、リニューアル時に引き継ぐものを整理し、公開前・公開当日・公開後に何を確認すればよいかを解説します。

Webサイトリニューアル全体の判断や進め方から確認したい場合は、Webサイトリニューアルの進め方もあわせてご覧ください。

Webサイトリニューアルで引き継ぐものは7つ

主な引き継ぎ対象は、次の7つです。

この分類は、特定のCMSや制作方法だけを前提にしたものではありません。WordPressなどのCMSを継続する場合でも、別のCMSへ移行する場合でも、確認対象を業務上の役割で分ける考え方は共通して使えます。

見た目が完成しても移行完了とは限らない

リニューアル作業では、画面の表示確認が先に目に入ります。しかし、利用者から見えない設定や管理情報も重要です。

たとえば、問い合わせフォームが表示されていても、担当者への通知が旧メールアドレスへ送られていれば、問い合わせを確認できません。

GA4のタグがページに入っていても、新しいURLでイベントが発生していなければ、リニューアル後の効果を正しく確認できません。

旧URLへアクセスしたときに404となる場合も、新しいサイト自体は表示できるため、公開直後には気づかないことがあります。

引き継ぎ対象を設定名ではなく、業務上の役割で分けると、非IT担当者でも確認しやすくなります。

専門用語をすべて覚える必要はありません。各設定が、利用者の移動、検索流入、問い合わせ、社内運用のどこに影響するかを理解し、担当者へ確認できる状態を目指します。

URLを変更しない場合でも確認は必要

URLを変更しないリニューアルは、URL移行の負担を抑えやすい方法です。

ただし、URLが同じでも次の項目が変わる可能性があります。

• titleやmeta description
• canonical
• noindex
• 内部リンク
• 構造化データ
• GA4やGTM
• 問い合わせフォーム
• CMSの管理権限

CMSやテーマを変更したことで、旧サイトでは出力されていた構造化データやOGPが消える場合もあります。デザインだけの変更に見えても、テンプレートや計測方法が変わる場合は、技術的な確認が必要です。

URLを維持する場合でも、変更箇所を一覧にして確認します。

最初に旧サイトと新サイトの変更範囲を整理する

引き継ぎ項目を決める前に、今回のリニューアルで何を変更するのかを整理します。

変更範囲が曖昧なまま制作を進めると、公開直前になってから、ドメイン、メール、計測、フォームなどの担当者が分からないことがあります。

変更する項目を一覧にする

主な確認項目は次のとおりです。

• URL
• ドメイン
• サーバー
• CMS
• ページ構成
• デザイン
• 問い合わせフォーム
• GA4やGTM
• メール環境
• 外部サービス

各項目について、変更するか、維持するか、確認が必要かを分けておくと、制作会社と発注側の認識を合わせやすくなります。

リニューアルの目的や更新体制がまだ整理できていない場合は、Webサイトリニューアル前に整理することから確認すると、移行対象を決めやすくなります。

同時に変更するものが多いほど確認範囲が広がる

URL、ドメイン、CMS、サーバーを同時に変更すること自体が問題なのではありません。

問題が起きたときに、どの変更が原因なのか分からない状態を避けることが重要です。

たとえば、公開後に問い合わせ通知が届かない場合、フォーム実装、送信先設定、DNS、メール認証、迷惑メール判定など、複数の原因が考えられます。

何を変更し、誰が確認し、問題が起きた場合にどこへ戻すかを事前に決めておくことが大切です。

変更が多い場合は、バックアップ、切り戻し方法、公開当日の連絡先もあわせて決めておきます。

残すページ・統合するページ・削除するページを決める

旧サイトのページは、次の3つに分けて整理します。

• 新サイトでも残すページ
• 他のページへ統合するページ
• 新サイトでは削除するページ

検索流入があるページ、問い合わせにつながっているページ、外部サイトからリンクされているページを、確認せず削除しないようにします。

アクセス数だけでなく、問い合わせ前に読まれているページ、営業時に案内しているページ、既存顧客が参照しているページも確認対象です。

ページを削除するか迷う場合は、公開後の用途と、代わりに案内できる新ページがあるかを基準に判断します。

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

URLを変更する場合は、旧URLごとに新しい移転先を決めます。

次の表は、URL対応表に入れる項目の記入例です。

URL対応表は、制作会社だけが使う技術資料ではありません。残すページや統合先を発注側が確認するための業務資料でもあります。

URLを変更する場合は301リダイレクトを確認する

301リダイレクトは、旧URLを訪れた利用者や検索エンジンを、対応する新URLへ案内する設定です。

重要なのは、設定方法より先に、旧ページの役割と移転先を決めることです。

301リダイレクトは、旧URLをどこへ送るか決まってから設定するものです。

検索エンジンに旧URLと新URLの関係を伝える重要な対応ですが、設定すれば検索順位を必ず維持できるものではありません。

ページ内容やサイト構造も変わるため、公開後の検索流入やインデックス状況を継続して確認します。

すべてをトップページへ転送しない

旧ページをすべて新サイトのトップページへ転送すると、利用者が探していた情報へたどり着けなくなる可能性があります。

対応する新ページがある場合は、意味が近いページへ転送します。

移転先がない場合は、無理にトップページへ転送せず、削除ページとして扱う方法も検討します。

統合するページの場合は、統合後のページに旧ページの内容が適切に含まれているかも確認します。

内部リンクも新URLへ更新する

リダイレクトが設定されていても、新サイト内のリンクを旧URLのまま残す理由はありません。

新サイト内の内部リンク、メニュー、CTA、画像リンクなどは、新URLへ更新します。

リダイレクトを何度も経由する状態や、旧URLと新URLが混在する状態を避けることで、利用者にも管理者にも分かりやすい構造になります。

SEO情報を新サイトへ引き継ぐ

URL以外にも、検索結果や検索エンジンの認識に関係する情報を確認します。

SEO情報は、一つの設定だけを確認するのではなく、URL、ページ内容、内部リンク、サイトマップなどが同じ方向を示しているかを見ることが重要です。

title・meta description・見出しを確認する

旧サイトの内容をそのまま移す場合でも、次を確認します。

• ページ内容とtitleが合っているか
• meta descriptionが旧サービスや旧情報のままではないか
• H1がページ内に適切に設定されているか
• H2やH3の順序が不自然ではないか
• 同じtitleが複数ページへ設定されていないか

リニューアルでサービス内容やページの役割が変わる場合は、旧サイトのtitleやdescriptionをそのまま移すだけでは、新しい内容と合わなくなることがあります。

制作段階から検索しやすい構造を整える考え方は、Web制作段階でのSEO設計で詳しく解説しています。

canonical・noindex・robotsを確認する

特に注意したいのは次の状態です。

• canonicalが旧URLを示している
• canonicalがテスト環境のURLを示している
• 開発中に設定したnoindexが残っている
• robots.txtで必要なページをブロックしている

canonical、内部リンク、サイトマップなどが別々のURLを示していると、新サイトの状態を判断しにくくなります。

robots.txtとnoindexは役割が異なります。どちらか一方だけを見て判断せず、公開対象ページがクロール・インデックス可能な状態か確認します。

XMLサイトマップと内部リンクを更新する

新サイトの公開URLをXMLサイトマップへ反映し、Search Consoleから確認できる状態にします。

サイトマップだけでなく、サイト内リンクも新URLへ統一します。

サイトマップは検索エンジンへURLを伝える補助となりますが、登録すれば必ずインデックスされるものではありません。

公開後は、送信状況だけでなく、実際のインデックス状態も確認します。

構造化データ・OGP・favicon・altも確認する

CMSやテーマを変更すると、次の情報が抜ける場合があります。

• 構造化データ
• OGP
• favicon
• 画像のalt
• パンくずリスト

今回の記事では具体的な設定方法までは扱いませんが、公開前後の確認対象に含めます。

実装方法や必要なschemaは、ページの種類やCMSによって異なります。旧サイトの設定をそのまま複製するのではなく、新サイトの内容と一致しているか確認します。

GA4・GTM・Search Consoleを新サイトで確認する

GA4はアクセスやイベントを計測する仕組み、GTMは計測タグを管理する仕組み、Search Consoleは検索エンジンから見たサイトの状態を確認する仕組みです。

アカウントやタグが存在しているだけでは、引き継ぎ完了とは判断できません。

管理画面にデータが表示されていても、旧サイトのアクセスだけを見ている場合や、新サイトで同じイベントを二重に送信している場合があります。

GA4は実際のアクセスとイベントで確認する

GA4では、次の項目を確認します。

• 新サイトのページビュー
• フォーム開始
• フォーム送信
• CTAクリック
• 電話リンク
• key event
• 二重計測
• 未計測

RealtimeやDebugViewなどを使い、新サイト上の操作が実際に計測されるか確認します。

確認時には、自分が行った操作とGA4上のイベントが対応しているかを見ます。

フォーム送信数やCTAクリック数だけでなく、旧サイトと同じ条件で比較できるかも重要です。

GTMは設定と公開状態を分けて確認する

GTMでは、次のような問題が起きることがあります。

• トリガー条件が旧URLのまま
• プレビューでは動くが公開されていない
• 同じタグが複数回発火している
• Cookie同意によって必要なタグが動かない

設定の有無だけでなく、プレビューと公開後の動作を確認します。

カスタムタグや複雑なイベントを使用している場合は、どのページ、どの操作、どの条件で発火するかを仕様として残しておくと、担当者変更後も確認しやすくなります。

Search Consoleの所有権とサイトマップを確認する

Search Consoleでは次を確認します。

• 対象プロパティ
• 所有者
• XMLサイトマップ
• インデックス状況
• 404
• 構造化データ
• Core Web Vitals

ドメイン変更を伴う場合は、同一ドメイン内のURL変更とは別の確認が必要です。

Search Consoleのプロパティ種別や移転手続きは、変更内容によって扱いが異なります。ドメイン変更、同一ドメイン内のパス変更、HTTPS化、サーバー変更を同じ操作として扱わないようにします。

問い合わせフォームは送信後まで確認する

問い合わせフォームは、表示だけでなく、問い合わせ対応へつながる一連の流れを確認します。

問い合わせフォームはWeb上の機能であると同時に、営業や顧客対応業務の入口でもあります。

フォームが表示されるだけでは確認完了ではない

確認する流れは次のとおりです。

1. フォームが表示される
2. 各項目へ入力できる
3. 必須項目やエラー表示が動く
4. 送信できる
5. 担当者へ通知が届く
6. 利用者へ自動返信が届く
7. 完了ページが表示される
8. 送信完了を計測できる

フォームの確認で重要なのは、送信ボタンが押せることではなく、担当者が受信し、必要な対応へ進めることです。

実際の問い合わせ対応と同じ流れでテストすることで、画面上では分からない問題を見つけやすくなります。

通知先と自動返信の内容を確認する

次の情報が旧サイトのまま残っていないか確認します。

• 通知先メールアドレス
• 送信元
• 件名
• 自動返信本文
• 会社名
• 住所
• 電話番号
• 旧URL
• 個人情報保護方針へのリンク

担当者の退職や部署変更によって、旧メールアドレスが残っていることもあります。

通知先だけでなく、誰が受信後に対応するかも決めておきます。

CTA・電話リンク・完了ページも確認する

フォームだけでなく、問い合わせにつながる次の導線も確認します。

• CTAボタン
• 電話リンク
• メールリンク
• 資料請求
• 予約
• 完了ページ

CTAのリンク先が旧URLのままになっていないか、スマートフォンで電話リンクが機能するか、完了ページで計測イベントが発生するかを確認します。

フォームが正常でも問い合わせにつながらない場合は、公開後に問い合わせが増えない原因を確認するチェックリストで、導線や計測状況を見直せます。

ドメイン・DNS・SSL・サーバー・メールを整理する

ドメイン、サーバー、メールは、同じ会社が管理しているとは限りません。

Web制作会社がサイトを制作していても、ドメインは発注側、メールは別の事業者、サーバーは保守会社が管理している場合があります。

ドメインとサーバーは別の管理対象

次の情報を整理します。

• ドメイン契約者
• ドメイン管理会社
• DNS変更権限
• サーバー契約者
• サーバー管理者
• SSL更新担当
• 更新期限
• 請求先

管理画面へ入れるかだけでなく、契約更新や設定変更ができる権限を誰が持っているか確認します。

DNS変更はメールへ影響することがある

Webサイトとメールが同じドメインを使う場合、DNS変更の内容によってメールへ影響する可能性があります。

必要に応じて、次の設定をメール管理者へ確認します。

• MX
• SPF
• DKIM
• DMARC

これらは、メールの配送先や送信元認証に関係する設定です。

詳しい設定方法は、利用しているサーバーやメールサービスによって異なります。

DNSを変更する場合は、Web担当だけで完結させず、メールやインフラの管理者にも影響範囲を確認します。

SSLとHTTPSを確認する

確認する項目は次のとおりです。

• 証明書エラーがない
• HTTPからHTTPSへ移動できる
• 主要ページがHTTPSで表示される
• サブドメインが必要な範囲で対応している
• HTTPの画像やファイルが混在していない
• 更新担当者が分かる

SSL証明書が設定されていても、一部のサブドメインや外部ファイルで警告が出る場合があります。

PCだけでなく、スマートフォンや主要ブラウザでも確認します。

旧サーバーをすぐ停止しない

新サイト公開後に問題が見つかった場合へ備え、旧環境の停止時期を事前に決めます。

残す期間は、サイト規模、契約、移行内容、切り戻し方法によって異なります。

旧環境を残す場合も、利用者や検索エンジンから新旧両方へアクセスできる状態を長期間続けるのではなく、目的と停止条件を決めます。

バックアップとして残すのか、切り戻し用として稼働させるのかも明確にします。

CMS・管理権限・契約情報を引き継ぐ

サイトを運用するためには、ログイン情報だけでなく、所有者や契約者も確認する必要があります。

管理情報が特定の担当者や旧制作会社に集中していると、公開後の更新や障害対応が難しくなります。

ログインできることと管理権限を持つことは違う

確認する項目は次のとおりです。

• 所有者
• 管理者
• 編集者
• 契約者
• 請求先
• 更新担当者
• 障害時の連絡先

管理画面へログインできても、契約更新や権限追加ができなければ、継続して管理できる状態とは限りません。

CMSでは、記事を編集できる権限と、ユーザー追加や設定変更ができる権限が分かれている場合があります。

GA4、GTM、Search Consoleなども、閲覧者と管理者ではできることが異なります。

外部サービスも一覧化する

次のサービスを使っている場合は、所有者や契約者を確認します。

• GA4
• GTM
• Search Console
• フォームサービス
• Webフォント
• 地図
• 動画
• API
• 有料プラグイン
• CDN
• Cookie同意管理
• 画像素材

外部サービスは、サイト上から見ただけでは契約状況が分からないことがあります。

無料期間、更新日、請求先、解約時の影響も確認しておくと、公開後の停止を防ぎやすくなります。

制作会社変更後も運用できる状態にする

旧制作会社や特定担当者しか管理できない状態を避けます。

制作会社へ管理を委託する場合でも、自社側で契約内容と連絡先を把握しておくことが重要です。

すべての権限を自社担当者だけで管理する必要はありませんが、誰に連絡すれば更新や復旧ができるか分かる状態にします。

公開前・公開当日・公開後に分けて確認する

公開前は設定とテスト、公開当日は切り替え後の主要動作、公開後は検索・計測・問い合わせの継続状況を確認します。

確認項目だけでなく、担当者、確認方法、完了条件も一緒に決めます。

公開前に確認すること

• URL対応表
• 301リダイレクト
• title
• canonical
• noindex
• XMLサイトマップ
• GA4
• GTM
• 問い合わせフォーム
• スマートフォン表示
• SSL
• バックアップ
• 公開担当者
• 障害時の連絡先

テスト環境で確認できるものは、公開前にできる限り確認します。

ただし、DNS、実際の公開URL、検索エンジンの認識など、公開後でなければ確認できない項目もあります。

公開当日に確認すること

• 主要ページ
• HTTP status
• 旧URLから新URLへの移動
• フォーム送信
• 通知メール
• GA4
• GTM
• DNS
• SSL
• エラー表示
• 切り戻し判断

すべてのページを同じ優先度で確認するのではなく、トップページ、主要サービスページ、問い合わせページ、アクセスの多い記事などを優先します。

問題が見つかった場合の連絡先と、公開を継続するか切り戻すかの判断者も決めます。

公開後に確認すること

• Search Console
• インデックス
• 404
• 検索流入
• GA4
• コンバージョン
• 問い合わせ
• 表示速度
• 利用者からの不具合報告
• 旧環境を停止できる状態か

公開日は切り替え日であって、確認の終了日ではありません。

当日は表示と問い合わせを中心に確認し、その後は検索流入、インデックス、404、コンバージョンなどを継続して見ます。

移行完了は、新サイトが表示されることだけでなく、主要な旧URLが適切に案内され、問い合わせと計測が動き、管理権限と公開後の確認担当が揃っている状態を基準に判断します。

公開直後の検索順位やアクセス数だけで成功・失敗を判断せず、変更範囲と過去データを踏まえて確認します。

発注側と制作会社の役割を決める

担当範囲は契約や保守体制によって異なります。次の表は一般的な分担例です。

発注側が確認・提供するもの

• 残すページ
• 削除するページ
• 問い合わせ先
• 契約情報
• アカウント所有者
• 公開日時
• 業務上止められない機能
• 運用担当者

発注側がすべての技術設定を理解する必要はありません。

一方で、どの情報を残すか、問い合わせを誰が受けるか、どの機能を止められないかは、事業側でなければ判断できません。

制作会社が設定・検証するもの

• URL移行
• リダイレクト
• SEO設定
• 計測タグ
• フォーム
• SSL
• 公開作業
• 技術エラー
• バックアップ

技術的な対応範囲は制作会社によって異なります。

サーバー、DNS、メール、広告タグなどが契約範囲外の場合もあるため、事前に確認します。

共同で確認するもの

• 公開可否
• 主要ページ
• フォーム送信
• 計測
• リダイレクト
• 管理権限
• 公開後監視
• 障害時対応

制作会社へ技術作業を任せることと、発注側が判断しなくてよいことは同じではありません。

誰が作業するかだけでなく、誰が確認し、誰が完了を判断するかを決めます。

リニューアル時に起きやすい引き継ぎ漏れ

代表的な引き継ぎ漏れは次のとおりです。

旧URLを把握していない

アクセスや検索流入があるページを確認せず、削除する可能性があります。

サイトマップだけでなく、アクセス解析、Search Console、既存の案内資料なども参考にします。

301リダイレクトが不足している

旧URLを訪れた利用者が404ページへ移動してしまいます。

特に、過去の広告、メール、SNS、外部サイトからリンクされているURLは確認が必要です。

noindexやテスト環境のURLが残っている

新サイトが検索対象にならない、またはcanonicalがテストURLを示す可能性があります。

公開前のテスト環境と本番環境で設定が異なる場合は、公開後の実URLでも確認します。

GA4が未計測または二重計測になっている

リニューアル後の実績を正しく比較できなくなります。

旧タグと新タグが両方動いていないか、重要なイベントが抜けていないかを確認します。

GTMの変更が公開されていない

プレビューでは動いていても、本番サイトへ反映されていない場合があります。

変更履歴と公開済みバージョンも確認します。

フォーム通知や自動返信が届かない

問い合わせが送信されても、担当者が確認できない可能性があります。

複数のメール環境や端末でテストすると、迷惑メール判定や表示崩れも確認しやすくなります。

DNS変更でメールへ影響が出る

Webサイトは表示できても、メール送受信へ影響する場合があります。

Web公開担当とメール管理担当が別の場合は、切り替え日時を共有します。

管理権限や契約者が分からない

公開後の修正、更新、請求、契約更新が難しくなります。

特定担当者の個人アカウントだけで管理していないかも確認します。

旧環境を早く停止してしまう

問題が見つかったときに、切り戻しやデータ確認ができなくなる可能性があります。

旧環境を残す目的と停止条件を明確にします。

公開後の確認担当が決まっていない

問題が発生していても、誰も確認していない状態になります。

確認項目ごとに担当と報告方法を決めます。

自社だけで判断しにくい場合は移行項目の整理から相談する

リニューアル時に必要な確認項目は、現在のサイト構成と変更範囲によって異なります。

特に次のケースでは、外部への相談を検討しやすくなります。

• URL変更が多い
• ドメインを変更する
• CMSやサーバーも変更する
• 旧サイトの管理情報が分からない
• GA4やGTMの所有者が不明
• 問い合わせフォームを止められない
• メールへの影響が分からない
• 制作会社の移行内容が十分か確認したい
• 公開後の監視まで依頼したい

相談前には、次の情報を分かる範囲で整理します。

• 現在のサイトURL
• ドメイン管理会社
• サーバー
• CMS
• 問い合わせフォーム
• GA4
• GTM
• Search Console
• 残したいページ
• 公開希望時期

すべての情報が揃っていなくても、現在分かっている内容から確認を始められます。

リニューアルでは、すべてのサイトへ同じ作業を当てはめるのではなく、現在の構成と変更範囲から必要な対応を整理することが重要です。

Web制作とSEO、アクセス解析、問い合わせ運用を分けずに確認することで、公開後も使い続けられる状態を目指しやすくなります。

よくある質問

Webサイトリニューアルで引き継ぐものは何ですか

URLとページ、SEO情報、アクセス解析、問い合わせフォーム、ドメインやサーバー、管理権限、公開後の確認体制を引き継ぎます。変更しない項目も、新サイトで正常に動くか確認が必要です。

URLを変更しない場合も301リダイレクトは必要ですか

URLが完全に同じであれば、そのページに対する301リダイレクトは通常必要ありません。ただし、一部でも削除・統合・URL変更するページがあれば、ページごとに移転先を確認します。

旧URLをすべてトップページへ転送しても問題ありませんか

原則として、内容が対応する新ページへ転送します。すべてをトップページへ転送すると、利用者が探していた情報へたどり着けず、検索エンジンから適切な移転と判断されない可能性があります。

GA4は新しいサイトでも同じものを使えますか

リニューアル前後の比較を重視する場合は、既存の計測環境を継続する方法があります。ただし、事業や計測目的を分けたい場合は、新しい構成が適することもあります。

問い合わせフォームは何をテストすればよいですか

表示、入力、エラー、送信、担当者通知、自動返信、完了ページ、迷惑メール判定、送信完了の計測まで確認します。画面表示だけでなく、担当者が実際に受信できることが重要です。

DNSを変更するとメールにも影響しますか

変更するDNS設定によっては、メールへ影響する可能性があります。Webサイトとメールの管理者が異なる場合は、公開前に両方の担当者へ影響範囲を確認します。

旧サイトや旧サーバーはすぐ削除してよいですか

公開後の動作確認や問題発生時の切り戻しができる状態を確保してから停止します。必要な期間は、サイト規模、契約内容、移行方法によって異なります。