サイトリニューアルの判断基準｜部分改修で足りるか見極める

← Blogに戻る

サイトリニューアルは、解決したい問題に合わせて範囲を決める

サイトのリニューアル判断とは、今の事業で成果を出すために、既存サイトのどこを残し、どこを直すかを決めることです。見た目が古いという理由だけで全面的に作り直す必要はありません。

まず、困っていることが特定のページにあるのか、複数ページに共通する作りにあるのか、事業の説明全体にあるのかを分けます。 要点は3つです。

①問題が限られ、原因を確かめられるなら部分改修を検討する。②事業の説明や更新方法から見直す必要があるなら全体設計を先に行う。

③どちらの場合も、今うまく働いている内容と導線を先に記録する。この順序なら、「新しくすること」ではなく「解決すること」に予算を使えます。

この記事では、ホームページの部分改修と全面リニューアルを比べるために、「原因・変更範囲・確認範囲」の3欄を使います。症状が多いから全面刷新、少ないから部分改善と数だけで決めないための整理方法です。

例えば全ページで文字が小さくても、共通の表示設定が原因なら修正箇所を絞れる可能性があります。反対に、トップページだけの相談でも、誰に何を提供する事業かが変わっていれば、下層ページを含む設計の見直しが必要になります。

最初の棚卸しは、トップではなく相談につながる一連のページで行う

最初に確認するのは、見込み客が入口から相談に進むまでの一連のページです。トップだけを眺めて評価せず、サービス説明、実績、問い合わせ画面まで実際にたどります。

検索や広告からサービスページに直接入る場合も想定し、途中から読んでも何を頼めるかが分かるかを確認します。 調査メモには、ページの場所、困っている症状、確認できた事実、まだ分からないことを書きます。

例えば「相談が少ない」は症状であり、フォームが原因だと確認した事実ではありません。「スマートフォンで送信するとエラーになる」は再現した事実です。

「料金が分からず迷ったのか」は仮説として別に残します。ここを混ぜると、印象だけで改修範囲が膨らみます。

数字が取れる場合は、対象ページへの訪問、問い合わせ画面への移動、実際の受付件数を、同じ期間で並べます。アクセス解析の送信記録と受信箱の件数が異なるなら、計測の不具合やテスト送信も切り分けます。

数字がない場合は、空欄をゼロにせず「未計測」と書き、テスト操作や営業担当者への聞き取りで確認できた範囲から始めます。 同時に、残す資産も書き出します。

顧客に説明するとき使っている事例、検索から読まれている解説、紹介時に送る会社案内などが候補です。訪問が少ないページでも、契約前の確認に使う情報なら役割があります。

流入件数だけを理由に捨てず、誰が何のために使っているかを記録します。新しい見た目を考える前に、現状の役割を把握する作業です。

部分改修が向くのは、原因と直す場所を限定できる状態

部分改修を選びやすいのは、事業の説明や運用の土台は使え、特定の不足を埋めればよい状態です。例えば、提供するサービスは変わっていないが、対応範囲が書かれていない場合は、その説明と必要な事例を足す案から検討できます。

会社全体の構成や記事管理の仕組みまで変える理由には直結しません。 ただし、「ボタンを1個直すだけ」のように、目に見える変更の小ささだけでは判断しません。

全ページで同じボタン部品を使っているなら、変更の影響は広がります。原因は共通部品、変更範囲はその部品、確認範囲はサービス・記事・フォームの各画面、というように3欄を分けます。

作業が小さくても、確認を省けるとは限りません。 仮に、サービス説明は理解できるのに、問い合わせ前に必要な準備物が分からないサイトがあるとします。

最初の改修案は、対象ページに準備物と相談後の流れを追加することです。確認は、その説明を読んだ人が何を用意すればよいか答えられるか、問い合わせ画面まで進めるかで行います。

「サイトがおしゃれになったか」だけでは、解決したかを判定できません。 ホームページの部分改修では、やらない範囲も残します。

例えば「サービス説明と関連導線を対象とし、ロゴ、ドメイン、記事管理は対象外」と書けば、後から別の要望が出ても分けて見積もれます。修正案には、変更前の記録と元に戻す方法も含めます。

これで小さく試すという選択が、場当たり的な修正ではなく、比較できる案になります。

全面刷新を検討する前に、事業の説明と更新の土台を確かめる

全面リニューアルを検討する理由は、個々の不具合より、今の事業を説明し続ける土台が合わないことにあります。例えば、以前は商品別だったサービスを現在は課題別に提供しているのに、サイトでは古い商品名ごとに説明が分かれている場合です。

文章だけを差し替えると、各ページの対象や案内先が食い違う可能性があります。 この場合も、先に全ページのデザインを作るのではなく、対象顧客、提供内容、判断に必要な情報、次の行動を並べます。

そのうえで、既存のページの役割を新しい説明に当てはめられるかを確認します。当てはまるなら段階的な改修も候補です。

当てはまらず、新しい分類やページ同士の関係から設計し直すなら、全体設計を先に進めます。 更新しにくい場合は、管理システムの問題と社内の手順を分けます。

画面では更新できるのに原稿の承認者が決まっていないなら、システムを変えても承認待ちは残ります。反対に、定期的に変える情報を担当者が編集できず、毎回個別の制作作業が必要なら、入力画面や公開手順を見直す理由になります。

実際の更新1件を、原稿準備から公開確認までたどると切り分けられます。 なお、送信不能や誤ったサービス案内など、営業に支障が出ている問題は、大きな計画の完成まで放置しません。

直近の復旧と将来の設計を別の作業として整理します。緊急対応を行ったから全面刷新が不要になるとも、全面刷新するから応急対応が不要になるとも限りません。

同じ症状でも結論が変わる、3欄の判断メモ

判断を社内で共有するには、「原因・変更範囲・確認範囲」の順で、1つの課題を短く記入します。次の例は実績ではなく、判断手順を示す仮想例です。

すべてに共通する症状を「サービスを見た人が相談へ進みにくい」とします。 例A：原因はサービスページに対応対象の説明がないこと。

変更範囲は対象ページの原稿と問い合わせへの案内。確認範囲は、説明を読んだ人が対象かどうか判断できるか、案内先が適切か。

事業の分類と更新方法に問題がなければ、部分改善から着手する案になります。 例B：原因は顧客別に異なるサービスが、同じ名称で複数の場所に載っていること。

変更範囲はサービスの分類、ページの役割、関連する案内文。確認範囲は、入口が違っても同じサービスの条件にたどり着けるか。

特定ページだけを書き換えても説明がそろわないため、全体の情報設計を先に行う案になります。 例C：原因は未確認。

サービスページの閲覧数は分かるが、フォームへの移動も受付記録との一致も調べていない。変更範囲は保留し、確認範囲をテスト送信と計測の点検に置きます。

すぐ全面刷新か部分改修かを選ばず、調査を先に発注する選択です。判断材料が足りないときに「保留」を選べることも、このメモの役割です。

最後に各例へ「残すもの」を添えます。例Bでも、掲載許諾が確認できた写真や事例の原稿は再利用候補です。

全体設計を変えることと、すべてを捨てることは別です。CATARIVEでは、世界観を整える作業も、顧客の理解や社内の更新につながる範囲で考えます。

刷新する面積より、残す理由と変える理由を説明できることを判断の軸に置きます。

見積もりは同じ目的で、調査・制作・移行・運用を比べる

サイトリニューアルの費用を比較するときは、合計額だけでなく、何が含まれるかをそろえます。部分改修と全面刷新では成果物の量が異なるため、「安い方」を選ぶだけでは、解決したい問題に届くか判断できません。

依頼時は、目的、確認した事実、未調査の点、残したい資産を同じ資料で伝えます。 見積書では、現状調査、情報の整理、原稿と写真、デザインと実装、既存情報の移行、動作確認、公開後の保守を分けて確認します。

例えば原稿は自社が用意する条件なら、制作費とは別に社内の作業時間が必要です。移行は記事本文だけなのか、画像や添付資料も含むのか、確認する件数はどこまでかを聞きます。

仕様が分からない段階で相場の金額だけを当てはめず、未確定部分を明示してもらいます。 比較する期間もそろえます。

仮に半年後にサービスを増やす予定があるなら、今の部分改修のあとに追加対応が必要か、新しい設計なら同じ枠で増やせるかを確認します。全面刷新の制作費が高くても必ず得とは限らず、部分改修を重ねる方が安いとも限りません。

初期費用と、その後に予定される更新の費用を別々に並べると比較できます。 段階的な改修を選ぶ場合は、順番にも条件が必要です。

「サービス説明を整理する」「主な導線を直す」「更新方法を改善する」の各段階で、何を確認したら次へ進むかを決めます。途中で再利用できない原稿や部品を作らないよう、将来の全体像を共有したうえで範囲を区切ります。

見積もり依頼の文面にも、完了条件を入れます。例えば「サービスの対象を読者が判断できるようにしたい。

現状は対象外の相談が含まれるが、件数は集計前。まず相談記録とページ内容を照合し、原稿改修で足りる案と分類から見直す案を出してほしい」という書き方です。

調査前の段階で、問い合わせ増加の保証を求める条件にはしません。 提案を受け取ったら、「この作業を省くと何が未解決になるか」を項目ごとに確認します。

必要な確認作業を削って金額だけを合わせると、公開後に不具合の調査費が必要になる可能性があります。予算に収まらない場合は、確認を削る前に、対象サービスや対象ページを絞る案を比較します。

作り直す場合も、公開前に失うものを点検する

全面刷新を決めた後は、新しく増える機能だけでなく、引き継げないものを点検します。対象は本文や画像に加えて、営業資料から案内しているページ、ダウンロード資料、問い合わせの受付先、解析の設定、更新担当者の操作です。

デザインの確認だけで公開を判断しないよう、業務ごとに確認者を決めます。 準備段階では、現在のページ一覧に「そのまま残す・内容を直す・統合を検討・要確認」の区分と理由を付けます。

アクセスがないという理由だけで機械的に削除しません。特に住所にあたるURLを変える場合は、旧ページへのリンクや検索経由の入口への影響があるため、対応方針を専門担当者に確認します。

URL変更や転送の設計は、見た目の刷新と一緒に自動承認せず、別の確認事項として扱います。 公開前の確認には、ページを読む確認と、仕事が完了する確認の両方を入れます。

例えば問い合わせなら、画面に完了表示が出るだけでなく、受付先に届き、担当者が内容を確認できるところまでを試します。資料を添付する機能があるなら、そのファイルを受け取れるかも確認します。

実際に使う機能を短い手順書にすると、確認漏れを見つけやすくなります。 公開後も、主要ページの表示、受付、計測、更新操作を再確認します。

不具合が起きた場合の連絡先、修正担当、以前の状態へ戻す判断者を公開前に決めておきます。すべてが完全になるまで何も出せない状態を避けつつ、営業を止める欠損があるまま公開しないための境界です。

迷いやすい質問と、次に用意する1枚

何年経ったらリニューアルすべきでしょうか。年数だけで決める共通の期限は置かず、事業との一致、操作、更新、安全に維持できるかを確認します。

新しいサイトでも説明が事業と合わなければ見直しが必要ですし、公開から年数が経っていても、必要な情報と運用が保たれていれば部分改善を検討できます。 アクセスが少ない場合は、先に全面リニューアルすべきでしょうか。

まずサイトに来る入口があるか、来た人に必要な説明があるかを別々に確認します。流入が少ない状態で受付件数だけを比べても、見た目が原因かは分かりません。

サイト内の改善と、見込み客へ届ける施策を混ぜずに計画します。 改修後、どれくらいで判断できるでしょうか。

表示崩れや送信不具合はテストで確認できますが、問い合わせの増減は流入量や相談の周期に左右されます。一律に1週間で結論を出さず、変更日、変更箇所、比較期間、流入元、受付件数、相談の内容を残します。

件数が少なければ、効果なしと断定せず観察を続ける判断も必要です。 次に用意するのは、困っているページ1つについての判断メモです。

「症状と事実」「原因または未調査」「変更範囲」「確認範囲」「残すもの」を1枚にまとめます。それを基に、部分改修、全体設計、追加調査のどれへ進むかを決めます。

サイトを新しくする前に、成長を妨げている場所と、今も働いている資産を見分けることが出発点です。

まずは無料相談

この内容、うちの場合はどうなる？を、直接聞いてみませんか。

Web・EC・広告・AI活用まで、事業の現在地に合わせてCATARIVEがお話をお伺いします。

↗