Webサイトをリニューアルする前に、実際に何を変更する必要があるかを決定します

リニューアルする前に、現在のサイトで何を維持する必要があるか、文書化された問題は何か、提案された各変更をどのようにチェックするかを記録します。外観はレビューの動機になる可能性がありますが、サイトのすべての部分が壊れていることを証明するものではありません。

判断を具体的に示します。提供内容を分かりやすくする、お問い合わせ導線を直す、重要な情報を整理する、などです。問題がまだ仮説なら、好みのデザインを実証済みの答えとせず、調査を依頼内容に含めます。

例えば「サイトをもっとプロらしくする」は、達成したかを確認しにくい指示です。「お問い合わせフォームの前に、評価サービスの成果物を説明する」なら、作成し、確認するものが明確になります。見た目を新しくすること自体も、事業上の選択になり得ます。ただし、測定していない売上の問題を解決するという主張とは分けます。

企画のきっかけを書き出します。意見、サービスの変更、再現できる不具合、事業の打ち出し方の変更などです。理由によって必要な作業は異なります。これで、デザインチームが、見せ方、文章、構造、機能のどれが中心かを推測せずに済みます。

重要なページ、その目的、主要なコンテンツ、訪問者が使用するパスをリストします。関連する観察結果をページと背景や条件とともに保存します。許可されたデータが存在する場合は、後の比較で意味のある根拠が得られるように、期間と条件を記録します。

現在のURL、検索エンジンへの指示、関連するページのつながりを、変更前の記録に含めます。リニューアルで維持し、確認すべき項目です。画像だけでは、導線の動作、お問い合わせの受信、検索エンジンが報告する登録状況は記録できません。

ホーム、主要なサービスページ、役立つガイド、連絡先、お問い合わせ導線から始めます。所有者が情報を提供できる場合は、検索での重要な表示や、業務での用途が分かっているページも加えます。訪問が少ないから不要とは限りません。価値の高い商談で、専門的な疑問に答えているかもしれません。

選択した各ページについて、アドレス、その主な回答、重要な主張、および次のアクションを保持します。別の問題が明らかになったモバイル ビューを保存します。分析機能がない場合でも、ベースラインは現在の Webサイトを正確に説明できます。そのパフォーマンスを測定しないままにしておきます。

• ページの目的：答える疑問や、支える行動。
• 残す価値のある情報：説明、事例、条件、連絡先。
• 導線：訪問者が来る場所、次にできること、再現できる不具合。
• 利用できる所有者のデータ：期間、情報源、関連するお問い合わせや検索の条件。
• 不明: 削除または置換を決定する前に必要なアクセスまたは調査。

変更する理由が新しい依頼内容にない限り、役立つ説明、根拠のある裏付け、正常に機能する導線は残します。見た目が古い部分でも、購入に関する重要な疑問に答えているかもしれません。削除前に、その役割を記録します。

役立っている裏付けと、見慣れていることを分けます。「このページはうまく機能している」とチームが言うなら、何がその裏付けかを尋ねます。裏付けが得られなくても、残す判断は妥当かもしれません。ただし、測定済みの結論ではなく、計画上の判断として扱います。

書体を変えるからといって、明確なサービス説明に新しい約束を加える必要はありません。関連する事例には、結果を理解するための背景を残します。提供内容を変えるなら、現在の説明と事例の両方を見直し、古い実績を別のサービスの裏付けに使ってしまわないようにします。

有用な検索コンテンツも慎重な決定に値します。ガイドがどの質問に回答し、読者がどのようにそこから読み進めたかを記録します。移動またはマージされた場合、置き換える際には、その有用な答えとそこに至るルートが保存される必要があります。アドレス自体は、既存のリンクやブックマークにとって重要な場合があります。

問題の状態と、その影響または未確定の懸念を示します。範囲が説明されていない提供内容には、確認済みの説明が必要です。入力検証の問題があるフォームには、再現できる不具合の修正が必要です。「サイトを今風にする」だけでは、確認できる指示になりません。

依頼内容では、作業の種類を明確にします。新しいレイアウトで事業の条件は決まりませんし、文章を直しても送信の不具合は直りません。問題が重なっていても、各変更が何を解決するか、チームが分かる必要があります。

競合他社を比較すると、答えのない疑問が明らかになることがありますが、別のサイトのプレゼンテーションは、そのデザインをコピーしても機能するという証拠にはなりません。洞察を利用して、対象読者と事実に基づいて独自の要件を作成します。

記録した問題が、どこまで広がっているかを確認します。1つのページに成果物の説明がないなら、文章の変更で済むかもしれません。共通フォームのエラーなら、複数ページへの修正が必要かもしれません。現在のサービスを整理できないナビゲーションなら、構造の見直しが必要になる場合があります。

外観だけでなく、依存関係や維持管理も考慮してください。既存のサイトは必要なコンテンツと導線をサポートできますか?担当チームは結果を維持できるのか？提案されたすべての修正に回避策が必要な場合は、基礎となる構造が問題の一部であるかどうかを調査します。

解消すべき制約を具体的に示せるなら、広い範囲の再構築に理由ができます。決定前に、部分修正と再構築の作業量、残す情報へのリスク、完了の確認方法を比較します。実際の要件を満たす、小さな変更も検討する価値があります。

裏付けが不十分なら、判断を変え得る部分を調べます。例えば、すべてのサービスページの作り直しを依頼する前に、お問い合わせの不具合が共通フォームの問題かを確認します。不確実なことは依頼内容に含め、サイト全体を変える必要があると断定しません。

これらの架空のエントリは、監査によってリニューアルがどのように絞り込まれるかを示しています。決定欄は方向性を示し、検証欄は作業後も何が真実でなければならないかを定義します。保持の決定には、意味を保護しながら新しいプレゼンテーションを含めることができます。

重要な箇所ごとに1行を使います。「ページ・分野」にURLや共通部品を入力します。「残す」には維持する意味や動作、「変更する」には好みではなく具体的なタスクを書きます。「裏付け・理由」には、その行が必要な理由を記録します。

「変更後の確認」に、結果をどう確認するかを書きます。「担当する役割」は、事実を確認する人、変更する人、完了を確かめる人を示します。お客様の個人情報を入れずに、サービス担当者、編集者、デザイナー、開発者などの役割を記せます。

記入済みの行は説明用の例です。空欄は自社の判断に使います。リニューアルの範囲に影響しそうな箇所から始めてください。控えが必要なら、ページを閉じる前に表を印刷します。メモはページを開いている間だけ残り、依頼内容の送信や作業の実施は行いません。

関連するタスクをまとめ、依存関係、未解決の疑問、担当者を特定します。必ず維持すべきものの確認と、任意の実験を分けます。デザイン前に何を決め、実装中に何を確認できるか、チームが分かるようにします。

現在のページ、観察された問題、サポート資料、提案された変更、および受け入れチェックを含めます。リニューアルで保持する必要がある情報を追加します。提案された変更がまだ仮説である場合は、それを最終的な答えとして扱う前に、何をテストする必要があるかを述べます。

以下の架空の依頼内容は、意図して範囲を絞っています。事業者が新しいデザインを選ぶ場合でも、この要件は独立して評価できます。1つの不十分な説明から、サイト全体が売上の損失を生んだという主張へ飛躍することを防ぎます。

完了の確認は、要件に合わせます。範囲を明確にするタスクなら、新しい文章を確認済みの製品情報と比較し、理解できるか試します。導線を変えるなら、リンク先と関連リンクを確認します。フォームを変えるなら、許可された方法で送信完了と受信を確認します。

重要なベースライン 導線と公開サイトに保存されている情報を再確認します。古いアドレスを開き、メイン ナビゲーションと関連リンクに従い、主要なサービス条件を確認し、モバイルとデスクトップで同意されたフォームのチェックを繰り返します。デザイン プレビューでは、リリースされたサイトが同じように動作するかどうかを確認できません。

検索に表示したいページは、担当の専門家やSearch Consoleプロパティの所有者に、意図する検索設定と登録データの比較を依頼します。一般公開は掲載条件の1つであり、実際の登録の証拠ではありません。Googleの技術要件でも、条件を満たすことと登録の保証を明確に区別しています。

要件、結果、残る問題を短く記録します。再現できる公開後の不具合は、マーケティング実験と考える前に修正します。リニューアルが完了し、フォームが動いても、有望なお問い合わせが増えたと言うには、適切な業務データが必要です。

リリース後に変更された領域を確認し、提供内容、対象ユーザー、ナビゲーション、または問い合わせプロセスが変更されたときに、より広範な導線を再検討します。適切な間隔は、目的と変化の規模に従います。すべてのビジネスに役立つ普遍的なスケジュールはありません。

後で動作を比較する場合は、同じ定義を保持し、トラフィック、キャンペーン、サービスの変化に注目してください。直接検証では、要求された変更が機能するかどうかが尋ねられます。パフォーマンス レビューでは、関連するユーザーとビジネスの成果に何が起こったかを尋ねます。両方を保持しますが、一方を他方に置き換えないでください。

リニューアル前の監査は、何を保持し、何を変更するかを決定するのに役立ちます。リニューアル後のレビューでは、それらの決定に照らして実装がチェックされ、新しい問題が特定される可能性があります。どちらも、検索の可視性や売上の増加を保証するものではありません。

サイト全体を変える前に、観察から必要な作業を定めます。コンテンツ、検索、お問い合わせの疑問が重なるなら、AlytixxのWebサイト総合監査で併せて検討し、依頼内容を明確にできます。