Webサイトのリニューアルは、デザインの作り替えではなく、問い合わせや採用といったビジネス成果を動かすための投資です。目的が曖昧なまま進めると、費用対効果が分からないまま公開を迎えます。この記事は、リニューアルすべきかの判断からSEO移行、デザイン、制作会社の選定と見積もり、公開前チェック、公開後の運用までを、工程順のチェックリストにまとめました。各表は「確認項目/担当/確認方法・証跡」で整理しています。
- 判断・準備:自己診断、KPIと現状値の記録、体制と締切(1章の表)
- SEO移行:URL対応表と301、サイトマップ再送信(2章の表)
- 公開前:noindex・robots.txt・SSL・フォーム・301の確認(6章の表)
- 公開後:404・インデックス監視、計測、更新と保守(6章の各表)
1. リニューアルの目的とゴール設定
リニューアルすべきか判断する自己診断
次の項目を自社サイトに照らし、当てはまる数ではなく、各項目の原因と影響範囲を確認します。そのうえで、部分改修・運用変更・全面リニューアルを比較します。
| 確認項目 | 担当 | 確認方法・証跡 |
|---|---|---|
| お知らせや実績の最終更新が止まっている | Web担当 | 最終更新日の一覧 |
| http のままで「保護されていない通信」と表示される | Web担当 | ブラウザ表示の確認 |
| スマートフォンで表示が崩れる、横スクロールが出る | Web担当 | 実機・開発者ツールでの確認 |
| 主要ページの実ユーザーデータや表示上の問題を確認し、原因と影響を記録する | Web担当 | スコアと実ユーザーデータの記録 |
| CMS・プラグイン・テーマの更新を止めている | Web担当 | 更新履歴の確認 |
| 更新のたびに制作会社へ見積もりと納期調整を依頼している | Web担当 | 依頼履歴の整理 |
| 誰がどのページを更新してよいか決まっていない | 管理部門 | 更新ルールの有無 |
| 解析タグが二重、または計測できていない | Web担当 | タグ設置状況の確認 |
| 問い合わせ数の推移を追えていない | 営業・Web担当 | 問い合わせ記録の集計 |
| 契約名義が自社ではない、または管理画面の権限がない | 管理部門 | 契約書・権限一覧(別々に確認) |
判断項目として、改修範囲(どこまで作り替えるか)、既存資産(コンテンツ・被リンク・計測データ)、運用体制(更新者・承認者)、見積もりに含まれる作業を並べます。当てはまるのが文言や写真の古さだけなら、全面リニューアルではなく更新で足りる場合もあります。
現状の課題を洗い出す
現行サイトの課題は、印象ではなく実データで比較します。アクセス解析の数値、問い合わせ件数の推移、ユーザーや営業部門からのフィードバックを整理し、前年同期や前月との比較、主要な経路ごとの数値を確認します。
- 直帰率・離脱率・コンバージョン率を主要ページごとに確認する
- 主要な問い合わせ経路を特定し、導線が適切かを確認する
- 競合他社サイトと比較し、自社サイトの相対的な課題を洗い出す
- 営業・カスタマーサポート部門から顧客の生の声を集める
課題が「デザインの問題」なのか「コンテンツの問題」なのか「技術的な問題」なのかを切り分けておくと、後の工程で対策を選びやすくなります。
KPIと成功基準を定める
リニューアルの目的が「売上向上」であれば、KPIは「問い合わせ数」や「資料請求数」といった具体的な数値で設定します。目標値は、現状値・対象期間・目標の決め方を確認する項目として扱い、現在の実績値を記録して、いつまでに何をどこまで動かすかを関係者で決めます。「自然検索流入数」「直帰率」「コンバージョン率(CVR)」「平均セッション時間」など、アクセス解析で計測できる指標を選び、リニューアル前の数値を残せば、公開後に効果を客観的に評価できます。
プロジェクト体制とスケジュールの確認
リニューアルは、Web担当者だけでなく、経営層、営業部門、制作会社が一体となって進めます。特に中小企業では専任のWeb担当者がいない場合も多いため、意思決定者を明確にし、各工程の承認フローを先に決めます。あわせて、誰がどのような目的で見て、何を知り、どの行動を取るサイトにするかを、要件の優先順位とともに先に固めます。
| 確認項目 | 担当 | 確認方法・証跡 |
|---|---|---|
| 意思決定者・承認者 | 経営層 | 体制図 |
| 各工程の承認フロー | Web担当 | 進行表 |
| 原稿・写真の担当と締切 | 各部門 | 分担表 |
| 公開日と予備日 | Web担当 | スケジュール表 |
| 公開後の運用担当 | 管理部門 | 運用ルール |
| 主な利用者と、その利用目的 | Web担当 | 利用者像のメモ |
| 利用者が必要とする情報 | 各部門 | 要件一覧 |
| 要件の優先順位(必須・できれば必要・将来対応) | Web担当 | 要件一覧 |
| ページ構成と導線の確認 | Web担当 | サイトマップ案 |
スケジュールには、ヒアリング、ワイヤーフレーム、デザイン、コーディング、コンテンツ作成、テスト、公開後の運用監視までを含めます。社内決裁に時間がかかる場合は、各工程に予備日を設けます。
情報設計やSEO対策の専門知識が必要な工程では、外部の専門家の支援を受ける選択肢もあります。たとえばBENTEN Web WorksのWeb制作では、構成の提案から公開作業までを扱っています。
よくある失敗例と回避策
- 目的が「デザインが古い」で終わる… KPIがないまま公開すると良し悪しを判定できません。計測できる指標と現在値を記録します。
- 既存ページの扱いを決めずに書き換える… 検索流入や問い合わせへの貢献、内容の正確さを確認し、維持・更新・統合を選びます。
- URLの対応表を作らずに構造を変える… 404が増えます。旧URLと新URLの対応表で転送・統合・削除を決め、301の設定後に1件ずつ動作を確認します。
- テスト環境の検索避けを解除し忘れる… 本番ページがGooglebotにクロール可能で、意図しないnoindexやパスワード保護が残っていないか確認します。robots.txtはクロール制御であり、検索結果から確実に除外する手段ではありません。公開手順書に解除を明記します。
- 公開日を決めてから原稿を書き始める… 遅延はここで起きます。原稿の担当者と締切を先に決め、遅れた場合に何を削るかも決めます。
- 更新も運用も制作会社しか触れない状態で納品される… 小さな修正のたびに費用と待ち時間が発生します。誰がどこまで触れるかを公開前に決めます。
2. SEOとコンテンツ移行のチェックリスト
URL変更を伴う移行では、検索順位や流入が変動することがあります。損失や回復期間は一律ではないため、URL対応表、適切な恒久リダイレクト、内部リンク・サイトマップ更新、公開後のエラー監視を具体的に進めます。
既存ページのSEO評価とURL移行
| 作業 | 担当 | 確認方法・証跡 |
|---|---|---|
| サイト全体のURLリストを作成する | Web担当 | URL一覧 |
| 旧URLと新URLの対応表を作る | Web担当 | 対応表 |
| 主要ページの被リンク・検索流入を調査する | Web担当 | Search Console等の記録 |
| 旧URLごとに転送(301)・統合・削除を判断し、対応表に記録する | Web担当 | 対応表 |
| 301リダイレクトを実装する | 制作会社 | 設定後の動作確認 |
| 内部リンク・サイトマップを更新する | 制作会社 | 更新後の確認 |
| 公開後にインデックス・404・リダイレクトを監視する | Web担当 | Search Console |
同等・関連性の高い移行先があるページは301で転送し、適切な移行先がない削除ページは404または410を返します。実装後は主要ページで実際に移動するかを確認し、サイトマップを再送信して、公開後もエラー監視を続けます。
コンテンツの棚卸し
全ページを新規に作り直す必要はありません。既存コンテンツの価値を評価し、「残す」「改善する」「統合する」「削除する」に分類します。アクセス解析で表示回数、平均滞在時間、直帰率、コンバージョン数を抽出し、検索キーワードとの関連性、ビジネス上の重要度を確認します。
削除を検討するのは、アクセスが極端に少ないページ、古すぎて現在の情報と一致しないページ、新しい情報設計に含まれないページです。削除する場合も、関連性の高い移行先があれば301で転送し、適切な移行先がなければ404または410を返します。
メタデータ・構造化データの移行確認
titleタグと見出しタグ(h1〜h3)は、ページの内容を検索エンジンと読者に伝える主要な要素です。meta descriptionは順位を決める要素ではなく、検索結果に表示される説明文の候補です。検索流入の多いページは、titleタグとmeta descriptionの変更が与える影響を確認し、維持・更新を選びます。
構造化データは、Googleが情報を理解し、対象機能の表示資格を得る助けになりますが、表示は保証されません。マークアップは実際の事業情報とページ内容に合うものだけを選び、リッチリザルトテストはエラー確認に使います。移行時は、マークアップが消えていないかを確認します。
3. デザインとユーザー体験(UX)のチェックリスト
デザインの刷新で重要なのは、ユーザーが目的を達成しやすくなることです。訪問者の「知りたい」「問い合わせたい」「資料をダウンロードしたい」といった行動を妨げない設計が求められます。
モバイルファーストとレスポンシブ対応
まず自社の端末別アクセスを確認します。Googleは主にモバイル版のコンテンツをクロール・インデックスに使うため、スマートフォンでも内容と主要機能を確認できるようにします。デザインはモバイルファーストで設計します。
| 確認項目 | 担当 | 確認方法・証跡 |
|---|---|---|
| タップしやすさ、読みやすさ、拡大時の可読性、隣接する操作要素との間隔 | Web担当 | 実機・開発者ツールでの確認 |
| 画面下部の画像や動画のLazy Load(最初に表示される画像・LCP候補の画像には使わない) | 制作会社 | 実装確認 |
| フォーム入力欄の拡大、tel:リンク | 制作会社 | 実機確認 |
| 横スクロールが発生しないレイアウト | Web担当 | iPhone・Androidで確認 |
モバイル表示は実機で確認するのが確実です。実機がない場合は、ブラウザの開発者ツールで画面サイズごとの表示崩れを確認します。
導線設計とCVR改善ポイント
CVR改善では、「ユーザーが迷わず目的のページへ到達できるか」が評価基準です。ページ上部に「電話する」「資料請求」「メールで問い合わせ」のアクションボタンを配置し、訪問者の多いページには、どのページからも行動に移れる導線を設置します。
- ファーストビューに行動を促す要素を配置する。企業名と事業内容を簡潔に伝え、ボタンを上部から見える位置に置く
- お問い合わせページの入力項目を削減する。必須項目を最小限にし、同意チェックの扱いを決める
- パンくずリストと関連コンテンツでページ間の移動をスムーズにする
ユーザビリティテストの実施
公開前に、実際のユーザーがサイトを操作する様子を観察し、改善点を洗い出します。参加者は固定人数ではなく、対象ユーザーに近い人を選び、代表的なタスク(例:「お問い合わせページから入力して送信する」)を決めて、つまずいた箇所や迷った箇所を記録します。記録をもとに導線や文言の改善案をまとめ、修正に反映します。
テストは厳密な環境でなくても構いません。紙のプロトタイプやHTMLのモックアップを使い、デザイン完成前に実施すると効率的です。
4. 制作会社の選定と費用の確認項目
リニューアルの費用は、ページ数だけで決まりません。同じページ数のサイトでも、構成や移行の条件で金額は動きます。見積もりが上下する要因を押さえます。
- ページ数とテンプレートの種類(デザインを何パターン作るか)
- 既存コンテンツの移行量と、URL変更に伴うリダイレクト設計の有無
- 既製テーマの活用かフルスクラッチか
- フォーム、会員機能、予約、多言語、ECなど標準機能以外の実装範囲
- 原稿・写真・イラストを誰が用意するか
- SEO内部対策、計測タグの設定、公開作業、公開後の運用支援が含まれるか
- サーバー・ドメイン・SSLなどのランニング費用が制作費と別か
見積もりと提案書では、次の項目を確認します。
- 見積もりの範囲(何が含まれ、何が含まれないか)
- 追加費用が発生する条件(修正回数、ページ追加、仕様変更の扱い)
- 制作費と月額費用の内訳(保守、サーバー、ドメイン、SSL)
- ドメイン・サーバーの名義と管理権限が自社になるか
- 納品物(ソースコード、テーマ、デザインデータ、各種アカウント)と二次利用の可否
- スケジュールと、遅延が起きた場合の扱い
- 公開後の保守範囲(CMS更新、バックアップ、セキュリティ対応、障害時の窓口と対応時間)
- SEO移行(301リダイレクト、サーチコンソール設定、サイトマップ送信)が作業に含まれるか
金額の目安は条件で変わります。たとえば当社のWeb制作では、新規制作・リニューアルは5万円からで、1ページのLPまたは3ページまでが対象です。構成の提案、お問い合わせフォーム、スマホ・タブレット・PCでの表示確認、公開作業、文言を差し替えるための手順書、納品後30日間の不具合対応が含まれ、原稿・写真は依頼者が用意します。4ページ目以降、デザイン案からの制作、文章の作成、WordPressで自分で更新できる形、予約・会員などの機能は追加見積もりです。比較するときは、総額だけでなく「どこまで含むか」の条件を揃えます。
選定では、採用した技術より「採用しなかった選択肢と、その理由」を聞くと判断材料になります。
5. BENTEN Web Works の対応事例から
チェックリストの各項目が、実際の現場でどこに効くのかを2件の事例で確認します。
自社サイトの全面リニューアルでは「やらないこと」を先に決めた
当社の自社サイト(bentenweb.com の全面リニューアル事例)は、テーマ移管から PageSpeed 60→94 の改善、GA4への一本化、構造化データの実装までを内製で行い、HSTS・Permissions-Policyを適用、CSPはReport-Onlyで検証中です。着手時にやったのは、追加したい機能を並べることではなく、採用しない選択肢を決めることです。ヘッドレスCMSは運用コストと既存資産との互換性から、ページビルダーは表示速度の天井を下げるため、最新フレームワークでの全面再構築は自社サイトに必要な機能はWordPressで足りるため、いずれも見送りました。
もう一つ、着手前の状態を確認しました。PageSpeed Insights のモバイルスコアが60点台、解析ツールが二系統、構造化データは Organization のみ、セキュリティヘッダーは未設定。この状態を基準に、公開後に何がどれだけ変わったかを比較できます。チェックリストの「現状の課題を洗い出す」は、この比較の基準を作る作業です。
読者の状況に置き換えるなら、検討段階で「今回はやらないこと」と「現状の数値」を1枚にまとめておくことです。
運用の手離れを前提にした設計(非営利協会の案件)
スポーツ振興を担う中規模の非営利協会団体のサイト改修(WordPressサイトの改修事例)では、親テーマに直接積まれた修正、ページごとにばらついた見出しスタイル、スマートフォン表示の崩れ、ロゴ差し替えのたびに業者依頼が発生する状態が課題でした。ご相談の入口は見た目の修正でしたが、実際に必要だったのは「このあとも団体側で更新を続けられる仕組み」でした。
そこで採用したのが子テーマ化です。親テーマには手を触れず、軽微な見た目の調整は「追加CSS」で済ませ、PHPの変更が必要なものだけを子テーマに寄せる。テーマが更新されても手元の修正は消えず、日常の修正は団体側で完結し、重い改修だけを外注に切り出せます。テーマの丸ごと乗せ換えやページビルダーへの移行は、運用するスタッフの再学習コストに見合わないと判断して見送りました。
この案件は、チェックリストの「プロジェクト体制」と「公開後の保守運用」が、実は同じ問題だと示しています。誰が更新し、どこから外注に出すのかを公開前に決めておくことが重要です。
6. 公開前最終確認と公開後のモニタリング
公開前の最終確認はテスト用サーバーで実施し、公開後のトラブルを防ぎます。公開後は、不具合の確認と検索エンジンへの反映状況の監視を続けます。
公開前に必ず確認する項目
| 確認項目 | 担当 | 確認方法・証跡 |
|---|---|---|
| テスト環境用のnoindexが解除されているか | 制作会社 | 本番ページのソース確認 |
| robots.txtに全体ブロックやテスト環境の記述が残っていないか | 制作会社 | ファイル確認 |
| Basic認証などのパスワード保護が解除されているか | 制作会社 | アクセス確認 |
| SSL証明書が適用され、httpからhttpsへリダイレクトされるか | 制作会社 | ブラウザ確認 |
| http://の画像・CSS・JSが残っていないか(混在コンテンツ) | 制作会社 | ソース確認 |
| お問い合わせフォームの送信内容が管理者宛に届くか(自動返信を設定していればその受信も確認) | Web担当 | 受信確認(迷惑メールフォルダも確認) |
| OGP・Twitterカードのタイトル、説明、画像、絶対パス | 制作会社 | 表示確認 |
| 本番用サイトマップXMLの内容とURLを確認する | Web担当 | 本番URLの一覧と照合 |
| 404ページ、favicon、プライバシーポリシー、会社情報の表示 | Web担当 | 目視確認 |
| 旧URLからの301リダイレクトが主要ページで機能しているか | 制作会社 | 1件ずつ動作確認 |
| スマートフォン実機、主要ブラウザ、タブレットでのレイアウト崩れ | Web担当 | 実機確認 |
| テスト用の仮テキスト・ダミー画像・サンプルデータが残っていないか | Web担当 | 目視確認 |
| ドメインのDNS切り替え後、メールの送受信が正常か | 管理部門 | 送受信テスト |
公開後に発覚すると影響が大きいのは、noindexとrobots.txt、SSL、フォームです。作業手順書を作り、チェックした日時と確認者を記録すると、担当者の引き継ぎにも使えます。
機能テストと表示速度の検証
機能テストでは、全ページのリンク、フォーム送信、動画や画像の表示を確認します。送信内容がデータベースに保存されるタイプのフォームでは、文字化けやデータ欠落も確認します。
表示速度は、PageSpeed Insightsで確認できるラボデータと、実ユーザーのCore Web Vitals等を区別し、主要ページ・端末条件をそろえて確認します。速度が遅いページはユーザーエクスペリエンスの低下を通じて、コンバージョンにも悪影響を及ぼします。
アクセス解析・サーチコンソールの設定
GA4とGoogleサーチコンソールの設定は、公開日までに完了します。設定漏れがあると、公開直後の計測ができず、リニューアル前後の比較分析ができません。
アクセス解析では、旧サイトのトラッキングコードが消えていないか、新しいページにもタグが正しく埋め込まれているかを確認します。リニューアル後は、「問い合わせフォームの送信完了」をコンバージョンとして設定し、月単位で目標数をモニタリングします。
サーチコンソールでは、サイトマップの送信に加えて、リニューアル前に存在した主要ページが正しくインデックスされているかを確認します。公開後は「ページのインデックス登録」レポートを定期的に確認します。
公開後の監視と改善サイクル
公開直後から、インデックス、404、リダイレクト、フォーム、計測の不具合を確認します。異常がなければ、再クロール・再インデックスの進み方をSearch Console等で継続確認します。
- 検索順位が大幅に変動したページがないか
- 404エラーが発生しているページがないか
- 直帰率が高いページがないか
- 問い合わせ数がリニューアル前と比較して増減しているか
リダイレクトの設定漏れやコンテンツが消えたページ、明らかな技術的エラーは早急に修正します。公開後も定期的にコンテンツを更新し、情報の鮮度を保ちます。
公開後の保守・セキュリティ体制
| 確認項目 | 担当 | 確認方法・証跡 |
|---|---|---|
| 誰がどのページを更新するか(更新者、承認者、外注に出すライン) | 管理部門 | 運用ルール |
| バックアップの取得頻度・保管場所と、復元手順を試したか | Web担当 | 復元テストの記録 |
| CMS本体・プラグイン・テーマの更新方針 | Web担当 | 更新ルール |
| ログイン試行回数の制限、二要素認証、ユーザー権限の見直し | Web担当 | 設定確認 |
| 使っていないプラグイン・テーマ・古いアカウントの削除 | Web担当 | 一覧確認 |
| ドメイン・サーバー・SSL証明書の更新期限と通知先 | 管理部門 | 契約情報 |
| 障害発生時の連絡先と初動 | 管理部門 | 連絡体制表 |
| 公開後の定例(アクセス解析とサーチコンソールの確認頻度) | Web担当 | 定例記録 |
| 本番公開後にサイトマップを送信し、Search Consoleで受理を確認する | Web担当 | 送信記録 |
セキュリティと保守は、リニューアルの見積もりから漏れやすい項目です。
ここまでのチェックリストは、上流の判断から公開後の運用までを一続きで扱っています。すべてを一度に埋める必要はありません。まず自己診断で対象を絞るところから始めてください。
リニューアルの進め方や、現状サイトのどこから手を付けるかで迷っている場合は、30分のオンライン無料相談で現在のお困りごとを伺います。お問い合わせには24時間以内に返信します。見積もりを取る前の段階でも構いません。