サイトリニューアルの進め方｜工程・URL移行表・公開判断のチェック例

リニューアルで解決する課題と評価条件を決める

最初に「古く見える」を、利用者と運用者の具体的な困りごとへ言い換えます。対象者が必要なサービス情報を見つけられない、原稿の確認に時間がかかる、問い合わせフォームで入力を完了できない、などです。観察した事実と、原因の仮説を分けてください。流入減少だけでは、見た目や文章が原因だと決まりません。

事業目標と納品条件も分けます。問い合わせ増加は事業として追う目標であり、フォームが仕様どおり動くことは試験で確認する条件です。広告、季節性、競合、営業対応なども事業結果へ影響します。制作の完了だけで成果を保証する計画にしないことが大切です。

計画の開始時点で、対象者、対象範囲、予算、動かせない日付、承認者、成果の測り方を残します。不明な点は調査の担当と決定日を置き、全体刷新が必要か、部分改善で足りるかを判断します。

現行ページを棚卸しし、残す資産と対象範囲を選ぶ

現行ページは、タイトルとURLだけでなく、役割、内容の管理者、利用状況、更新必要性、移行判断を一覧にします。検索や外部リンクから入るページ、重要な説明、問い合わせ後の確認ページなども対象です。閲覧が少ないことだけを理由に削除せず、契約・サポート・利用者の必要性を確認します。

判断は、維持、修正、統合、廃止に分けます。統合する場合は、旧ページが担っていた情報や目的を新しいページが引き継ぐか確認します。移行対象外にしたページにも、旧URLをどう扱うかという判断が残ります。本文を移さないことと、URLの処理を考えなくてよいことは同じではありません。

対象一覧には、画像、添付ファイル、フォーム、外部サービスとの接続、言語別ページも含めます。原稿や画像を発注側が支給するなら、利用権、担当、期限を明示します。旧サイトの件数だけで見積もらず、移行に必要な整形や確認の量を確認してください。

検索実績のあるURLは、引き継ぐ情報と新しい導線を優先してレビューします。ただし過去に表示されたことだけから、現在の検索登録状態やページ品質を断定しません。分析で分かる事実、技術試験で分かる事実、利用者への確認が必要な仮説を分けると、対象範囲の議論が進みます。

工程ごとの成果物・担当者・公開条件をそろえる

架空の小規模案件を12週で組むなら、棚卸し1〜2週、設計3〜4週、制作5〜8週、移行試験9〜10週、修正と公開判断11週、公開と初期確認12週、という置き方ができます。原稿整理は3〜8週に並行する前提です。主工程の配分は2 + 2 + 4 + 2 + 1 + 1 = 12週ですが、並行する原稿期間をさらに足しません。

この週数は標準納期ではありません。レビュー枠、支給物、担当稼働を確保できるという架空の仮定です。順序の前提、外部回答、承認に必要な時間を確認し、完成見込みを作り直します。工数の合計を、そのまま経過日数へ置き換えないでください。

各工程に「作った資料」だけでなく、誰が何を見て次へ進めるかを置きます。必須条件が残るときは、公開を待つか、範囲変更と影響を合意します。締切が来たことだけで確認を完了扱いにしません。

URL移行表の記入例とcanonical・リンク・サイトマップ

URLを変えないページにリダイレクトは不要です。変える場合は、旧URLから関連する新URLへ対応を作ります。以下のパスは架空例です。新しい表示先が200を返すことと、旧URLの転送を別々に確認します。

Google Search CentralのURL変更を伴う移転ガイドは、旧新URLの対応、恒久転送、canonical、内部リンク、該当するhreflang、サイトマップの更新を案内しています。代替のない廃止ページは404/410とし、無関係なトップページへ一律に転送する設計を避けます。関連性のある内容をまとめる転送とは区別してください。

移転先では自己参照canonicalと、同言語の内部リンクをそろえます。言語版がある場合は対応するhreflangも見直し、新しい正規URLをサイトマップへ反映します。転送が多段になっていないか、旧パスが意図せず復活しないかも確認します。

恒久転送は、Googleの案内では一般に少なくとも1年維持する計画が必要です。利用者や外部リンクへの対応から、より長く残す判断もあります。アドレス変更ツールはドメイン等の移転向けで、パスだけの変更に使うものではありません。設定をそろえても順位や処理期間の保証にはなりません。

公開前テストと問題発生時の戻し方を合意する

公開前には、必要な画面、入力と送信、エラー表示、通知先、権限、データ移行、URL対応、対応環境を試験します。テスト担当と公開可否を判断する人を分け、結果、対象版、証拠、未解決事項を残します。成功画面が出るだけで送信先へ届いたとみなさず、合意した到達確認まで行います。

復旧計画は「バックアップがある」で終わらせません。戻す対象、保存時点、必要な権限、担当、連絡方法、戻した後の確認を決めます。新環境で受け付けた問い合わせや更新データを、旧環境へ戻す際に失わないかも検討します。移行と切り戻しの手順は事前に試せる範囲で確認します。

重大な送信不能や権限問題を中止条件とするなら、発見時の連絡先と判断期限も決めます。軽微な表示差は、受容する条件と修正日を残して進めることもできますが、重大・軽微の区分を公開直前に都合よく変えないでください。

公開後のクロール・検索・問い合わせを条件をそろえて確認する

公開直後は、重要ページへのアクセス、転送先、フォーム、権限、エラーを優先して確認します。その後、クロールや検索表示、自然検索の入口、問い合わせを別々に追います。検索表示、訪問、送信、営業上の有効な問い合わせは同じ数ではありません。

前後比較では、日数、言語、対象URL、検索タイプ、流入経路、国や端末などの条件をそろえます。旧新URLは対応表で結び、URL変更による集計先の移動と、実際の利用変化を区別します。少数件数では増加率だけでなく実数も見て、季節性や施策変更を記録します。

公開後の順位変動を一律に正常とも失敗とも判定せず、技術上の問題と利用者の反応を証拠から調べます。運用担当には対象一覧、URL表、未解決事項、変更手順を渡し、次の確認日を決めます。計画を工程表で終わらせず、公開後に誰が何を確かめるかまでつなげてください。

次の作業に合わせて、要件定義書テンプレート｜記入例・受入基準・変更履歴の作り方、WBSの作り方｜成果物を分解する記入例と工数の二重集計を防ぐ方法、ガントチャートの作り方｜Excel・スプレッドシートの記入例と数式を参照してください。