この記事は、住宅会社の経営者・Web責任者に向けた実務ガイドです。
「サイトが古く見えるため全面リニューアルを考えているが、本当に全部作り直す必要があるか判断できない」という状況から、判断の順番と確かめることを示します。
読み終えたときに、事業課題と技術制約を分け、部分改修・再編集・全面刷新を選べる状態をつくるための手順が手元に残ります。
『サイトが古い』という感想を、そのまま発注要件にしないようにします。対応エリアが分からない、施工事例の更新に時間がかかる、スマートフォンで予約できないなど、実際に困っている行動へ言い換えます。見た目を変える必要がある場合も、何を伝えるための変更かを説明できるようにします。
広告から訪れた人が商品を理解できない問題と、社名で検索した人が会社の信用を確認できない問題は異なります。トップページだけを見るのではなく、流入先と次の行動を組み合わせて点検します。
記事、事例写真、問い合わせ導線、URL、管理画面などを棚卸しします。使える素材まで一から作り直すのではなく、現在の内容で役立っている部分を残します。一方、必要な更新ができない、担当交代でアクセスできなくなるなど、運用上の制約はデザインとは別に整理します。
| 確認すること | 部分改修を検討する例 | 基盤刷新を検討する例 |
|---|
| 内容 | サービス説明や事例の材料が不足 | 分類や関係を現在の仕組みで扱えない |
| 導線 | 予約ボタンやページの説明が分かりにくい | 必要な受付処理を安全に組み込めない |
| 更新 | 入力ルールや担当が未定 | 権限管理や引き継ぎが成立しない |
| 技術 | 限定した表示・速度の問題 | 継続的な保守が困難な制約がある |
制作会社へ相談するときは、誰が何を更新するか、既存のデータをどう移すか、公開後に誰が不具合を確認するかを伝えます。画面の好みだけでなく、記事と資料の紐づけ、予約受付、検索設定、担当者の権限などを要件へ入れてください。
GoogleはURL変更を伴うサイト移転について、旧URLと新URLの対応、リダイレクト、サイトマップなどを案内しています。見た目を新しくすることと、過去のURLを引き継ぐことを別作業にせず、公開計画に含めます。［1］
公開前にはフォームの送信だけでなく、受付先への到達、通知、エラー時の表示を確かめます。公開後は旧URL、スマートフォンでの利用、更新担当者の操作を確認します。新しいサイトに変わった直後の数字をすべて改修の成果とせず、広告や季節など同時に変わった条件も残します。
NAYUTAの判断案は、まず重大な詰まりを直す小さな改修を検討し、その範囲で解消できない基盤上の課題があれば全面改修へ進むことです。『新しくなった』ではなく、読者と担当者が何をできるようになったかで検収できる状態にします。
ブランドの伝わり方に支障があるなら見直します。ただし、見た目の変更だけで問い合わせが増えるとは断定せず、情報と導線も確認します。
変更の必要性を個別に判断します。変える場合は旧URLの適切な案内先とリンクの更新を決め、無関係なトップページへ一律に転送しません。
画面数だけでなく、移行、原稿編集、計測、公開後の保守、操作説明まで含まれる範囲をそろえます。金額だけでは同じ仕事の比較にならないことがあります。
出典参照日：2026-09-27。外部資料で確認した内容と、本稿の判断表・手順・設計例を区別しています。設計例や仮定の数字は実際の顧客実績を示すものではありません。
［1］Google Search Central：Site moves with URL changes→URL変更時の対応付け、リダイレクト、移転後の確認。改修の判断表は本稿の提案。
