古く見えるホームページでも、すべてを作り直す必要があるとは限りません。情報の更新、スマートフォン表示、フォーム、CMS、サーバー、URL構造のどこに問題があるかで、適する方法は変わります。
TRAILでは、現行サイトを残して直す方法、重要ページから段階的に移す方法、全面リニューアルを比較します。見た目だけを新しくするのではなく、既存URL・検索流入・問い合わせ受付・管理権限を失わず、公開後に運用できる状態を検収します。
古いホームページで最初に確認すること
情報
サービス、料金、営業時間、採用条件、会社情報、担当者、写真が現在も正しいか。
利用
スマートフォンで読めるか、目的のページや問い合わせ方法を見つけられるか。
技術
CMS、PHP、テーマ、プラグイン、SSL、バックアップ、外部連携を維持できるか。
所有
ドメイン、DNS、サーバー、CMS、メール、解析、広告の契約者と管理者が分かるか。
「何年前に作ったか」だけでは刷新の根拠になりません。古さによる具体的な支障と、変更しない場合の影響を確認して優先順位を決めます。
リニューアルを検討する具体的な兆候
- スマートフォンで文字やボタンが小さく、横スクロールが発生する。
- 料金、受付条件、所在地、電話番号、営業時間などに古い情報が残る。
- フォームの完了画面は出るが、担当者へ届いているか確認できない。
- 更新担当者が分からない、または軽い修正にも外部作業が必要になる。
- CMSや実行環境の更新を止めており、脆弱性・互換性の判断ができない。
- 重要ページのURL、title、見出し、canonical、noindexの状態を把握できない。
- ドメインやサーバーが制作会社名義で、契約・移管条件が不明である。
- 解析やSearch Consoleの権限がなく、流入・問い合わせを確認できない。
部分改修・段階移行・全面刷新を比較
| 方法 | 向いている状態 | 主な作業 | 注意点 |
|---|---|---|---|
| 現行サイトの部分改修 | 基盤は維持でき、問題が情報・表示・導線に限られる | 原稿、見出し、CTA、フォーム、CSS、画像等の修正 | 古い基盤へ追加し続けると保守が複雑になる |
| 重要ページから段階移行 | 全体量が多く、優先ページから改善したい | サービス・料金・問い合わせ等を順番に再設計 | 新旧のデザイン、ナビゲーション、計測を共存させる期間がある |
| 全面リニューアル | 基盤、構造、デザイン、運用方法をまとめて変える必要がある | 棚卸し、設計、制作、URL移行、検収、公開 | 移行対象と終了対象をURL単位で決める必要がある |
| 新規サイトを別に構築 | 別事業・別ブランド・別対象として分ける合理的理由がある | 新しい情報設計、ドメイン・運用の設計 | 重複ページ、運用分散、ブランド・検索評価の分散を避ける |
リニューアル前の資産棚卸し
画面に見えるページ以外にも、運用を支える契約とデータがあります。制作開始前に、所有者、管理者、更新期限、復旧先を一覧にします。
| 領域 | 確認する資産 | 受領・検証 |
|---|---|---|
| ドメイン・DNS | 契約者、管理サービス、更新期限、ネームサーバー、DNSレコード | 管理画面権限、移管条件、現行設定の記録 |
| サーバー・SSL・メール | 契約、容量、実行環境、証明書、メールアドレス | ファイル・DB、メール影響、復元方法 |
| CMS | 管理者、テーマ、プラグイン、個別開発、投稿タイプ | 編集、更新、バックアップ復元の試験 |
| コンテンツ | 原稿、画像、動画、PDF、事例、レビュー、許諾 | 原版、利用範囲、更新責任、廃止判断 |
| 外部サービス | フォーム、予約、決済、CRM、地図、SNS、チャット | 契約名義、API、通知先、データ出力 |
| 検索・計測 | Search Console、解析、タグ管理、広告、計測仕様 | 所有権、管理者、基準値、公開後比較 |
残す・直す・統合する・終了するをURL単位で決める
旧サイトのページ一覧を作り、アクセス数だけでなく、問い合わせへの近さ、外部リンク、検索表示、法的・契約上の保存要件、更新可能性から判断します。
- 維持：URLと目的を保ち、本文や表示だけを改善する。
- 改稿：URLを保ちながら、検索意図と現在の提供内容に合わせて再設計する。
- 統合：重複・競合する複数ページを代表ページへまとめる。
- 新規：既存ページで扱えない明確な目的がある場合に追加する。
- 終了：代替先がない情報は削除、代替先がある場合は対応関係を確認する。
旧URLをすべてトップページへ転送すると、利用者が探していた情報に着けません。旧URLと新URLの対応表を作り、同等またはより適切なページへ個別に設定します。
URL変更とSEO移行
URLを変える場合は、旧URL、新URL、移行理由、リダイレクト種別、内部リンク、canonical、サイトマップ、確認担当を移行表に残します。恒久移転にはサーバー側の恒久リダイレクトを用い、リダイレクトチェーンやループを避けます。
Google検索の公式資料では、URL変更を伴う移行について、事前テスト、URL対応表、リダイレクト、Search Console、サイトマップ、公開後の監視が案内されています。詳しくはサイト移行の公式ガイドとリダイレクトの公式資料を確認できます。
リニューアルによって検索順位が維持・向上することは保証できません。変更前の基準値と公開後の推移を記録し、技術エラーと需要・競合等の外部要因を分けて確認します。
原稿は現在の事業情報を正本にする
旧サイトの文章を移すだけでは、古い条件も引き継ぎます。サービスの対象、対応範囲、料金を決める条件、追加費用、納期、受付、対象外、会社情報を担当部署へ確認します。
- 事実の正本となる資料・管理画面・担当者を決める。
- 数字、実績、資格、受賞、レビューには期間・条件・掲載許諾を持たせる。
- 料金や受付条件には適用日・確認日を持たせる。
- 古いキャンペーン、終了商品、退職者、移転前住所を終了処理する。
- 画像・ロゴ・フォント・動画・PDFの利用権を確認する。
スマートフォン・アクセシビリティ・表示性能
- 画面全体に横スクロールがなく、表や長いURLは個別の領域に収める。
- 文字、ボタン、フォームを拡大せず操作できる大きさにする。
- 見出し順、リンク文言、画像の代替テキスト、ラベル、エラー表示を確認する。
- キーボード操作、フォーカス表示、色のコントラストを確認する。
- 画像、フォント、動画、外部タグ、スライダーの読み込み負荷を確認する。
- 固定CTAや同意表示が本文・フォームを隠さないようにする。
表示性能は実験環境だけでなく、公開後の実利用データも確認します。指標の意味はGoogleのCore Web Vitals公式資料を参照できます。単一のスコアだけで検索順位や成果を断定しません。
CMS・更新運用・セキュリティ
更新しやすさはCMSを導入しただけでは決まりません。誰が、どの情報を、どの承認で、いつ公開し、誤りをどう戻すかを決めます。
- 管理者・編集者・投稿者の権限を業務に合わせ、共用アカウントを避ける。
- CMS、テーマ、プラグイン、個別開発、外部サービスの責任範囲を分ける。
- 本番更新前にバックアップを取得し、復元できる形式と保管先を確認する。
- 検証環境と本番環境のバージョン、データ、外部連携の差を記録する。
- 障害、脆弱性、契約切れ、担当変更の連絡先と優先度を決める。
フォーム・予約は担当者の実着信まで確認
フォームの「送信完了」だけでは受付確認になりません。公開前後に、入力、形式検証、完了表示、自動返信、担当者メール、共有受信箱、CRM・予約台帳、振り分け、一次対応までを通して試します。
| 状態 | 確認内容 | 記録 |
|---|---|---|
| 入力 | 必須、形式、文字数、同意、添付 | 正常・異常入力の結果 |
| 送信 | 二重送信防止、完了表示、エラー時の案内 | 日時、端末、ブラウザ |
| 通知 | 自動返信、担当メール、迷惑メール判定 | 送信元、件名、受信時刻 |
| 業務 | CRM・予約台帳、担当分配、初回返信 | 受付番号、担当、対応状態 |
| 障害 | 代替連絡先、復旧、未着分の確認 | 影響範囲と再送方法 |
氏名、メール、電話番号、相談内容などをURLや解析イベントへ含めません。保存期間、閲覧権限、削除方法、委託先も確認します。
費用を左右する条件
リニューアル費用はページ数だけでなく、調査・移行・原稿・機能・検収の範囲で変わります。要件確認後に個別見積もりとし、根拠のない一律価格は提示しません。
- 現行サイト・契約・権限・検索データの調査。
- URL一覧、統合・終了判断、リダイレクト設計。
- 情報設計、原稿作成、取材、撮影、図版、素材購入。
- デザイン案、レスポンシブ、アクセシビリティ、個別UI。
- CMS、投稿タイプ、フォーム、予約、決済、外部連携。
- データ移行、SEO設定、計測、同意管理、公開作業。
- テスト、実着信、復元、切り戻し、公開後監視。
- 保守、更新、レポート、追加制作、第三者サービス費用。
制作費の比較項目はホームページ制作費用、全面刷新の判断はホームページリニューアルでも確認できます。
制作会社への確認項目
- 現行URL・検索流入・問い合わせの調査範囲。
- 維持、改稿、統合、新規、終了の判断方法。
- 原稿・写真・事実確認・法務確認の担当。
- フォーム実着信、予約・決済・外部連携の検収範囲。
- URL移行、canonical、noindex、サイトマップ、構造化データの担当。
- ドメイン、サーバー、CMS、解析等の契約名義と管理権限。
- 検収、修正、公開、延期、切り戻しの条件。
- 公開後の保守、障害連絡、追加費用、契約終了時の引継ぎ。
制作会社を変更する場合は、契約・データ・移行の確認項目もご覧ください。
ご相談から公開までの工程
- 目的、困りごと、変更期限、承認者を確認。
- URL、コンテンツ、契約、権限、技術、計測を棚卸し。
- 部分改修・段階移行・全面刷新を比較。
- 対象範囲、責任、見積もり、日程、検収条件を合意。
- 情報設計、URL対応表、原稿、素材を作成・承認。
- デザイン、実装、CMS・フォーム・計測を設定。
- テスト環境で表示、リンク、実着信、権限、復元を検収。
- バックアップ、公開・延期・切り戻し判断を確認。
- 本番公開し、旧新URL、検索設定、フォーム、計測を再確認。
- 公開後の変更履歴と課題を記録し、保守・改善へ移行。
公開前後の検収と切り戻し
| 時点 | 主な確認 | 判断 |
|---|---|---|
| 公開前 | バックアップ、復元、DNS、SSL、URL対応、フォーム、計測 | 公開・延期の条件を満たすか |
| 公開直後 | HTTP状態、リダイレクト、主要画面、H1、canonical、noindex、JSON-LD | 継続・修正・切り戻し |
| 当日 | 実着信、予約・決済、メール、アクセス、エラーログ | 影響範囲と優先度 |
| 公開後 | クロール、インデックス、検索流入、問い合わせ品質、運用負荷 | 技術修正・内容改善・経過観測 |
表示崩れ、問い合わせ未着、誤った料金・条件、個人情報露出、重要ページのnoindexなどは、事前に決めた重大条件として扱います。
公開後に残す変更台帳
公開日だけでなく、対象URL、変更内容、承認者、確認項目、結果、切り戻し先、次回確認日を残します。料金・営業時間・受付停止・採用終了など期限のある情報は、開始だけでなく終了と通常表示への復帰も管理します。
検索表示、訪問、CTA、送信完了、担当者実着信、相談、見積もり、契約を別の状態として計測し、ページ変更との関係を確認します。アクセス増加や順位だけを事業成果と同一視しません。
全面リニューアルを急がない方がよい場合
- サービス内容や会社情報が大きく変わる予定で、正本がまだ決まっていない。
- ドメイン・サーバー・CMSの権限や現行契約を確認できていない。
- 問い合わせ後の担当・受付・返信方法が決まっていない。
- 数ページの情報修正やフォーム修復で主要な支障を解消できる。
- 繁忙期や重要キャンペーン直前で、検収・切り戻しの時間を確保できない。
まず現行サイトの問題箇所を分け、優先ページだけを改善する方法も検討します。問い合わせ導線の確認はホームページの問い合わせ改善をご覧ください。
古いホームページのリニューアルでよくある質問
何年たったらリニューアルすべきですか？
年数だけでは決まりません。情報の正確性、スマートフォン表示、CMS保守、フォーム、権限、事業変更への対応可否で判断します。
URLは変えない方がよいですか？
問題なく機能し、内容の目的も同じなら維持を優先します。変更が必要な場合は旧新URLの対応表と恒久リダイレクトを準備します。
今の制作会社が作ったサイトでも相談できますか？
相談できます。契約、権利、データ提供、管理権限は推測せず、現行契約と受領可能な資料を確認して進めます。
WordPressにすれば更新しやすくなりますか？
更新画面だけでなく、投稿項目、権限、承認、バックアップ、保守担当を設計する必要があります。WordPressが適さない条件も含めて比較します。
リニューアルで検索順位は上がりますか？
順位は保証できません。URL・本文・内部リンク・表示性能等の変更影響を管理し、公開後にSearch Console等で確認します。
まず何を共有すればよいですか？
現行URL、困っている点、変更したい事業情報、希望時期、分かる範囲の管理会社・CMS・ドメイン情報をお知らせください。
古いホームページの改修・リニューアル相談
全面刷新を前提にせず、現行サイトを残せる範囲、先に直すページ、移行が必要な資産を整理します。現行URLと困りごとをご共有ください。