ホームページを作り直す？直すだけ？「残す・直す・つくる」の整理法

最初に直す一つを、完了条件まで書いてみる

「直す」の箱に項目が増えたら、一つだけ選び、確認できた事実・今回直す箇所・残すもの・完了条件の順に書きます。「問い合わせが少ないから写真が原因だろう」は仮説です。「スマートフォンで予約先へのリンクが開かない」は確認できた事実。この二つを分けると、原因が分からないまま大きな制作を決めずに済みます。

まずは、連絡できない・案内が誤っているなど、今の利用を妨げる問題から。その次に、提供する内容や相談の進め方が伝わらない箇所を選びます。表現の見直しでは、見た目の好みに加えて「どんな印象を、誰に届けたいか」を判断軸にします。

例1：美容室の雰囲気を残し、予約先への迷いを直す

事実：スマートフォンでメニューから予約方法へ進むリンクがない。今回直す箇所：メニューの終わりに、現在利用している予約方法への案内を置く。残すもの：店内写真や色使い。完了条件：メニューから予約先を開けて、店舗名と案内内容が正しいことを確かめる。確認だけで実際の予約は送らないようにします。

例2：専門サービスの説明を残し、初回相談の入口を直す

事実：税理士などの専門サービスで、対応分野は書かれているが初回に伝える内容の案内がない。今回直す箇所：実際の対応範囲に沿って、相談したい内容と現在の状況を伝える手順を添える。残すもの：正確な業務説明。完了条件：社内の確認者が、ページだけを読んで相談窓口と最初に伝える項目を説明できることを確認する。

例3：ものづくりの写真を残し、担当する工程を直す

事実：製品写真には名称しかなく、自社の担当工程が分からない。今回直す箇所：掲載許可を確認できた写真に、実際に担当した範囲と相談できる内容を添える。残すもの：現在も使える製品写真。完了条件：現場の担当者が説明と担当範囲の一致を確認し、非公開の仕様や取引先情報が含まれていないことを確かめる。

以上は考え方を示す仮の例で、GRAVIの顧客事例や制作実績ではありません。飲食・小売、エステ・ネイル、建設・設備工事などでも、実際に確認できた困りごとから同じ順で整理できます。

「直ったか」と「相談が増えたか」は、別に確かめる

リンクが開く、説明が現状と合うといった完了条件は、修正直後に確かめられます。一方、それによって相談が増えたかは、公開後の閲覧や相談操作、実際に届いた問い合わせを分けて見なければ分かりません。ボタンを押した回数を、そのまま問い合わせ件数にはしないでください。

修正日と変更箇所を記録し、次に振り返る日も決めます。計測できる範囲や比較期間が足りなければ「まだ判断できない」と残して構いません。GRAVIへのホームページの見直し相談でも、この一つの記入例と現在のURLが、必要な範囲を話す手がかりになります。

公開前後の確認を、誰がするか決めておく

直したい場所が決まったら、公開してよいと判断する人と、公開後に確認する人も決めてみましょう。見た目の確認だけでは、説明の更新漏れや問い合わせ先の間違いに気づけないことがあります。小さな修正でも、変更した内容から利用者の次の行動まで、ひと続きで確かめます。

公開前：説明と相談先が同じ内容になっているか

サービス名、提供する範囲、受付方法を変えたなら、そのページだけでなく一覧やよくある質問にも同じ説明が残っていないかを確認します。古い資料を参照するリンクがある場合は、リンク先の内容も対象です。変更点と確認する場所を一組でメモに残します。

• 説明は、今提供している商品・サービスと一致しているか。
• 相談ボタンの行き先は正しく、その先で必要な案内を読めるか。
• 写真の切り取りや見出しが、スマートフォンでも内容を隠していないか。
• 変更した条件を、確認担当者が了承しているか。

公開後：実際の入口から、読み手の順番でたどる

トップからサービス紹介へ、紹介から問い合わせへと進んでみます。担当者が編集画面で確認しただけではなく、実際に公開されたページで意図した説明が読めるかを確かめます。フォームを試す場合は送信先とテスト方法を先に共有し、実際の相談と混同しないようにします。

URLを変えるなら、古い名刺やQRコードの行き先も引き継ぐ

サイト内のボタンが正しくても、以前配った名刺、商品案内のPDF、メールの署名には古いURLが残っています。リニューアル前に、「どこから来た人が、何を読みに来るか」を一緒に書き出しましょう。見た目だけの変更でURLをそのまま使えるなら、無理に変える必要はありません。

たとえば、会社案内のQRコードが指す「機器の点検サービス」を、新サイトの「点検・保守」のページへまとめるとします。新ページにも従来の点検内容や相談方法が載っているかを確かめ、そのページへ案内します。これは考え方を示す仮の例で、GRAVIの顧客事例ではありません。

URLを恒久的に変える場合は、古いURLから対応する新ページへ自動的に送る「リダイレクト」を制作担当に相談します。サーバー側の恒久的な転送には301・308という方式があり、使える設定方法はサイトの仕組みによって異なります。読者にも検索エンジンにも移転先を伝えるための仕組みです。技術的な確認には恒久的なリダイレクトの公式説明を使えます。

古いページをすべてトップページへ送ると、探していた説明にたどり着けないことがあります。案内先は内容のつながりで選びましょう。関連の薄い一つのページへの一括転送を避けることや、サイト内のリンクを新URLへ更新することは、URL変更を伴うサイト移転の公式ガイドでも案内されています。終了したサービスなど、引き継ぐ情報がないページは、無関係なページへ自動転送せず、終了の案内や削除の扱いを個別に決めます。

公開後は、メモにある古いリンクや印刷済みのQRコードから開き、意図した説明を読める → 必要な相談先へ進めるまで確認します。自社で直せるメニューやPDF、メール署名のリンクも見直します。GRAVIへ相談する際は、今のURLに「残したいページ」と「変えたいページ」のメモを添えてください。リニューアルの範囲とURLの引き継ぎを相談する際の出発点になります。

困ったときに戻れるよう、変更前の情報を残す

変更前の文章・画像・確認済みの内容を保管し、何をいつ変えたかを記録します。問題を見つけたら、場所、端末、操作、起きたことを短くまとめて担当者へ。元に戻す必要がある場合の連絡先と判断する人も共有しておくと、次の対応を相談しやすくなります。

公開できたことと、問い合わせが増えたことは別です。まずは説明と導線が意図通りになったかを確かめ、その後に取得できるデータや実際の質問を参考に見直します。数値がない段階で成果を決めつけず、今のサイトで困っている場所からご相談ください。

問い合わせで繰り返す説明を、FAQに変える

同じ質問が届くからといって、質問集を大きく増やす必要はありません。まずは、説明が見つからないのか、答えが足りないのか、個別の判断が必要なのかを分けます。サービスページに答えがあるなら案内を直す。共通して答えられるならFAQへ。条件によって変わるなら個別相談への入口を残す。全面リニューアルの前にできる、小さな見直しです。

質問を「載せる・相談へ・元の説明を直す」に分ける

実際に受けた質問を、氏名や取引内容を除いて種類だけ書き出します。受けていない疑問は「確認したいこと」の候補とし、よく聞かれる実績があるように見せません。

「お問い合わせください」だけの回答を、判断できる答えへ

たとえば「初回の相談には、何を用意すればよいですか？」に、連絡先だけを返すと準備の疑問は残ります。答え → 条件 → 次の行動の順にすると、相談する前に分かることが増えます。

これは文章の組み立て方を示す仮例で、士業・店舗などの実際の受付条件やGRAVIの新しい契約条件を示すものではありません。自社で本当に案内できる答えに置き換えます。食品のアレルギー対応、施術の適否、工事の対応可否などは、確認なしに「大丈夫」と言い切りません。

置き場所は、質問が生まれるページから決める

予約の変更方法なら予約案内、対応範囲ならサービス紹介、原稿の準備なら制作前の説明へ置きます。質問を全部FAQページに集めるだけでなく、迷いが起きる場所から短い答えかリンクでつなぎます。同じ回答を何か所も全文コピーすると、更新時に条件が食い違うため、詳しい説明の正本を一つ決めます。

リンク名は「こちら」だけでなく、「初回相談に必要な資料」「予約変更の連絡方法」のように、行き先が分かる言葉にします。分かる見出し・リンク、短い説明は、W3CのWeb文章のガイドでも案内されています（2026年10月14日確認）。

公開前は、答えを知らない人に一問だけ試してもらう

1. 質問だけを渡し、トップから答えを探してもらう。
2. 読んだ人に「できること・条件・次の連絡先」を自分の言葉で説明してもらう。
3. 見つからなければ配置やリンク、誤解があれば回答文を直す。
4. 確認担当と日付、サービス変更時の見直し箇所を記録する。

これは自社で行う確認手順の提案で、実施済みのテストや問い合わせ削減の成果ではありません。公開後も質問が続く場合は、文章だけでなく実際の相談方法とのずれを確かめます。入力や予約の入口は問い合わせと予約の導線、事実の整理は原稿準備のメモ、変更の担当は更新の役割分担で分けて考えられます。

まず一つ、最近繰り返し説明した質問を選んでください。答えられる範囲、個別に確認する条件、今のURLをまとめ、FAQとホームページの見直しをご相談ください。顧客の氏名や問い合わせ原文は不要です。