塗装会社サイトのリニューアル失敗例｜公開前の確認項目

塗装会社のホームページをリニューアルした後、画面は新しくなったのに検索から見られなくなった、問い合わせが届かない、施工事例を更新できないといった問題が起こることがあります。制作中は新しいデザインへ意識が向きやすく、現在利用されているURLや受付業務、管理権限の移行が後回しになりがちです。

失敗を防ぐには、着手前に現行サイトの状態を保存し、残す情報と改善する情報を決めます。URLを変えるページは旧新の対応表を作り、施工事例の写真と説明、フォームから社内通知までの動作、ドメインや解析の権限を公開前に確認します。

この記事では、塗装会社サイトのリニューアルで起きる失敗の判定基準、現行資産の棚卸し、URL移行、施工事例と地域ページ、制作会社との分担、公開前のテスト、公開後の監視手順を解説します。

リニューアル失敗の判定基準

リニューアルの成否は、新しい画面の好みだけで決められません。工事内容と施工事例を読み、利用者が問い合わせできる状態が保たれているかを測ります。社内が情報を更新できること、これまで見られていたページへ到達できることも判定に含めます。

基準値は公開直前の一日だけで作らず、季節や工事件数の変動を把握できる期間で保存します。問い合わせについては件数だけでなく、対象地域、対象工事、現地調査、受注まで追える範囲を決めます。流入が同じでも対象外相談が増えていれば、目的を達成したとは判断できません。

目標は、問い合わせを増やす、更新しやすくする、といった表現で終えません。対象地域の外壁塗装相談を受付へ届ける、完工した施工事例を担当者が追加できるなど、利用者と社内の行動で表します。公開前の基準値、改善状態、確認日、担当者を一枚にまとめます。

検索順位や問い合わせは外部要因でも動きます。そのため、公開直後の変化をすべてリニューアルの効果や失敗と断定せず、変更したページ、流入経路、フォーム動作、計測漏れを順に確認します。

現行サイトの資産棚卸し

古いデザインのページにも、検索から読まれている記事、他サイトから参照される施工事例、問い合わせ前に確認される会社情報が含まれます。削除や統合を決める前に、現行URLと利用状況を一覧にします。

URL一覧には、残す、修正する、統合する、削除候補のいずれかを付けます。閲覧が少ないことだけで削除せず、会社名検索で必要な情報、問い合わせ後に案内するページ、法的な表示、外部リンクの有無も見ます。判断理由と承認者を残せば、制作途中で削除方針が変わったときも追跡できます。

工事ページは、外壁、屋根、防水、付帯部などの対象と、相談前に答えている疑問を記録します。似た内容が複数ある場合は、どのページを中心に残すか決めます。本文を一つへ統合する場合も、旧URLから新しいページへ移動できるよう対応を残します。

施工事例はCMSから書き出した本文だけで完了しません。元画像、撮影日、施工箇所、顧客の掲載許諾、担当者、工事後の保証情報がどこにあるかを確認します。画像ファイル名だけでは案件を判別できない場合、移行前に案件IDと結びます。

フォームは画面の入力項目に加え、送信先、返信先、自動返信、添付ファイル、保存先、迷惑送信対策を記録します。現在の受付担当者が実際に使っている処理を聞き取り、新サイトでも必要な動作を移行対象にします。

棚卸し表には作成日とデータの対象期間を付けます。制作中も現行サイトへ施工事例やお知らせが追加される場合は、差分をいつ再取得するか決めます。最初の書き出しだけで進めると、公開直前に追加された情報が新サイトへ移りません。

現行サイトのバックアップも棚卸しに含めます。CMSのデータ、画像、フォーム設定、転送設定を取得し、保存場所、取得日、復元担当を記録します。バックアップファイルがあるだけでは戻せると判断できないため、必要な環境と復元手順を制作会社へ確認します。公開切替後に重大な不具合が見つかった場合、どの状態へ戻すかを事前に決めます。

目的と制作要件の固定

画面案を作る前に、何を改善し、何を保持するかを要件書へまとめます。目的、対象読者、必要ページ、受付、更新、移行、計測が同じ文書にあれば、社内と制作会社が完成条件を共有できます。

発注前には次の項目を決めます。

• 対象とする市区町村と物件種別
• 外壁、屋根、防水など掲載する工事
• 利用者が相談前に確認したい費用条件、工程、保証
• 残すURL、統合するURL、変更するURL
• 移行する施工事例、写真、顧客の掲載許諾
• 電話、フォーム、LINEの受付時間と担当者
• ドメイン、CMS、解析、検索管理の所有者
• 原稿、写真、デザイン、データの承認者
• 公開前に合格が必要な動作と表示
• 公開後に監視する数値と確認日

目的が複数ある場合は優先順位を付けます。主力工事の説明、対応地域の明確化、施工事例の更新、問い合わせ受付の改善などを同時に進めても、公開時に何が達成できていればよいか決めます。素材が不足する機能やページは、必須公開と後続追加へ分けます。

制作範囲はホームページ一式と書かず、構成、原稿、撮影、デザイン、開発、データ移行、転送、フォーム、計測、操作説明、保守を分けます。各作業について、担当、入力資料、承認者、納品物、完了条件を示します。修正回数だけでなく、事実誤認や不具合を直す扱いも確認します。

デザインの要件は、好みの色や参考サイトだけで伝えません。スマートフォンで会社名と工事が読める、電話を押せる、写真の上の文字が見える、表を操作できるなど、利用者の行動へ置き換えます。ロゴ、車両、制服との一貫性も素材一覧へ含めます。

完成条件には、ページ数や公開日だけでなく、旧URLの転送、フォーム通知、計測、管理権限を入れます。公開後の修正期間と窓口も決めます。要件変更が起きた場合は、変更日、費用への影響、公開日への影響、承認者を記録します。

URLと検索評価の移行設計

リニューアルでページの見た目やCMSを変えても、公開URLまで必ず変える必要はありません。現在利用されているURLは可能な範囲で維持し、統合や構造変更で変更が必要なページだけ旧新URL対応表へ載せます。

旧URLをすべてトップページへ転送する状態では、利用者は探していた工事や事例へ到達できません。外壁塗装ページは新しい外壁塗装ページ、施工事例は該当する事例または事例一覧など、内容が対応する移動先を選びます。代替情報がない場合は、削除理由と応答方法を個別に決めます。

旧新URL対応表には、旧URL、新URL、扱い、担当者、実装日、確認結果を記録します。ページタイトル、説明文、H1、正規URL、内部リンクも合わせて確認します。URLの末尾、英字の大文字小文字、末尾スラッシュ、パラメータ付きURLなど、現行環境で使われている形を洗い出します。

公開前には次の順で移行を確認します。

1. 現行サイトのURL一覧を確定する
2. 新サイトのURL一覧と一対一で照合する
3. 維持、統合、変更、削除候補を承認する
4. 転送設定と新しい内部リンクを実装する
5. 確認環境でタイトル、本文、正規URLを確認する
6. 公開後に旧URLから新URLまで実際にアクセスする

検索管理ツールや解析の設定も移します。ドメインが同じでも計測タグが抜ければ、閲覧が減ったのか記録されていないのか判別できません。サイトマップ、クロール制御、正規URL、構造化された情報が意図した設定かを確認します。

公開時にドメインやDNSを変える場合は、ホームページ以外への影響も洗い出します。メール、フォーム、サブドメイン、外部サービスの認証が同じドメインを使う場合があります。切替担当、戻す条件、連絡先を決め、問い合わせを受けられない時間を作らない計画にします。

確認環境には検索を避ける設定を置きますが、本番公開時にその設定が残らないよう切替表へ入れます。反対に、確認環境のURLが検索や外部共有へ出ないようアクセス範囲を管理します。公開直前には現行サイトの更新を止める時間を決め、停止後に追加された原稿、事例、フォーム設定がないか差分確認します。切替中の変更依頼は一つの窓口へ集約します。

施工事例と地域ページの移行

塗装会社の施工事例は、写真と短い説明をコピーするだけでは情報が欠けます。相談内容、現地調査、提案、施工工程、保証を案件単位で対応させ、掲載許諾と公開範囲を確認してから移します。

一件の施工事例について、次の項目を移行台帳へ入れます。

• 案件IDと現行URL
• 公開可能な地域と物件種別
• 顧客が相談した症状と希望
• 現地調査で確認した状態
• 提案内容と採用理由
• 外壁、屋根、付帯部など施工箇所
• 使用材料と必要な工程
• 着工前、施工中、完工後の写真
• 工期、保証、点検、連絡方法
• 写真と情報の掲載許諾
• 新URLと関連する工事ページ

写真は案件ID、撮影日、施工箇所を照合します。別現場の写真や前後写真が混ざる状態を防ぎ、許諾のない表札や車両番号も確認します。元画像と公開用画像の保管先を分け、公開用の加工範囲を決めます。

費用を掲載する事例は、面積、足場、補修、付帯部、材料など含まれる範囲を確認します。古い金額をそのまま移す場合は、現在も案内として適切か担当者が判断します。一件の金額をすべての住宅へ当てはめる表現を避けます。

地域ページは、市区町村名だけを置き換えた重複ページを増やしません。実際の対応範囲、移動条件、相談内容、施工事例、担当拠点など固有情報を確認します。対応実態がない地域や、同じ役割のページが複数ある場合は、統合先を決めます。

事例ページから工事ページ、地域ページ、問い合わせへ移動するリンクも記録します。事例を移した後にリンク先が旧URLのまま残っていないか確認します。統合によって事例URLを変更する場合は、旧ページから対応する新ページへ転送します。

公開後に施工事例を追加する流れも移行対象です。現場が写真を保存する場所、顧客許諾の記録、原稿担当、公開承認、更新期限を決めます。新しいCMSを導入しても、素材が集まる手順がなければ更新は止まります。

制作会社との役割・権限

制作一式という発注だけでは、原稿や写真を誰が用意するか、公開後に誰が更新するか、契約終了時に何を受け取れるかが曖昧になります。制作中の担当と、サイトを継続運用するための所有権を分けて確認します。

ドメイン、サーバー、CMS、解析、検索管理、地図、フォーム、メールについて、登録者と所有者権限を一覧にします。制作会社のアカウントだけで管理する状態では、担当変更や契約終了時に自社で操作できない場合があります。塗装会社が所有者権限を持ち、制作会社へ必要な権限を付ける形を検討します。

原稿、写真、デザイン、コードの利用条件も確認します。素材サイト、フォント、外部機能など契約中だけ利用できるものを分けます。元データを受け取れるか、別の制作会社へ移管できるか、契約書へ記載します。

保守という言葉には、システム更新、バックアップ、障害対応、軽微な本文修正、施工事例追加など異なる作業が含まれます。何を何日以内に対応するか、対象外の作業、連絡方法を明記します。公開後の不具合修正と追加制作も区別します。

承認の流れは、経営者、工事担当、受付担当、制作会社の役割に合わせます。会社情報は経営者、工程と材料は工事担当、フォームは受付担当、技術実装は制作会社が確認するなど、事実を判断できる人へ割り当てます。一人がすべてを画面だけで承認する状態を避けます。

公開前の動作・計測確認

完成画面の確認と、利用者が問い合わせできることの確認は分けて行います。公開判定には、スマートフォン表示、電話、フォーム、社内通知、旧URL、計測、権限、復元を含めます。

公開前には次の項目を実際に操作します。

• 会社名、住所、電話、営業時間が原資料と一致する
• 対応地域、工事、保証、施工事例を担当者が承認している
• スマートフォンでメニュー、表、写真、ボタンを操作できる
• 電話番号を押すと正しい番号へつながる
• フォームへ入力し、完了画面まで進める
• 自動返信と社内通知が正しい宛先へ届く
• 添付ファイルの形式と容量が案内どおりに動く
• 問い合わせが案件管理や受付台帳へ記録される
• 旧URLから対応する新URLへ移動できる
• 内部リンク、外部プロフィール、地図のリンクが正しい
• 解析と検索管理へ閲覧や送信が記録される
• 正規URL、サイトマップ、クロール設定が意図どおりである
• ドメイン、CMS、解析の所有者権限を自社が確認できる
• バックアップを取得し、戻す手順と担当者が分かる

フォームは送信完了画面だけで合格にしません。利用者への自動返信、受付担当への通知、迷惑メール判定、案件への登録、返信担当まで、問い合わせ受付の通しテストを行います。営業時間外の表示や返信予定も実際の体制と合わせます。

計測は、ページ閲覧だけでなく電話ボタン、フォーム開始、送信完了など必要な行動を決めます。確認環境のテストデータと公開後の実データを区別します。古い解析設定を残す場合は、新旧の二重計測が起きていないか見ます。

端末確認は制作者のパソコンだけで終えず、受付担当者が使うスマートフォンや社内端末でも行います。通信速度が遅い状態、文字サイズを大きくした状態でも、会社情報と相談方法へ到達できるか確認します。

チェック結果には、実施者、日時、端末、結果、不具合、修正担当、再確認日を残します。公開を止める問題と、公開後に直せる軽微な問題を事前に分類します。電話やフォーム、会社情報、旧URL移行、権限に不合格がある場合は、修正と再テストを終えてから切り替えます。

公開後の監視と修正手順

公開前に合格しても、本番環境の転送、フォーム通知、計測、検索表示で問題が見つかることがあります。公開責任者と受付担当者が確認する時間を確保し、異常時に旧環境へ戻す条件と連絡先を決めます。

1. 公開直後にトップ、会社、主力工事、事例、問い合わせを表示する
2. 代表的な旧URLから対応する新URLまで移動する
3. スマートフォンから電話とフォームの通しテストを行う
4. 自動返信、社内通知、案件記録、計測結果を確認する
5. 404、転送の繰り返し、画像欠落、表示崩れを記録する
6. 解析、検索管理、サーバー記録で異常な減少やエラーを確認する
7. 公開前のURL別基準値と公開後の推移を同じ条件で比べる
8. 問い合わせ内容、対象地域、現地調査への移行を確認する
9. 不具合を影響範囲と緊急度で分け、一変更ずつ修正する
10. 変更日、対象URL、理由、担当者、次回確認日を残す

公開直後は、会社名やフォーム通知のように事業へ直接影響する項目を優先します。旧URLの404や誤った転送は、URL対応表から対象を特定します。画像や装飾の軽微な問題と同じ一覧へ混ぜず、優先度を付けます。

検索からの閲覧は、サイト全体の合計だけで見ません。旧URLと新URL、工事ページ、地域ページ、施工事例、記事に分けます。計測タグの欠落、正規URLの誤り、転送、検索表示の変化を順に確認します。公開前と公開後で集計方法が同じかも見ます。

問い合わせが減った場合は、アクセス、電話ボタン、フォーム開始、送信完了、社内通知のどこで減っているかを確認します。フォーム送信が記録されても受付へ届いていなければ、ページ改善より通知経路の修正を優先します。対象外相談が増えた場合は、対応地域や工事条件の説明を見直します。

施工事例や地域ページは、移行直後の表示だけでなく、その後に新規追加できるか試します。担当者が一件を登録し、写真、許諾、工事情報、関連リンク、公開承認まで進めます。操作説明を受けても実際に更新できない場合は、権限や入力項目を調整します。

複数の大きな変更を同時に行うと、どの修正が結果へ影響したか分かりません。緊急の不具合を除き、変更対象、期待する状態、確認日を決めて一つずつ反映します。検索や問い合わせの変化は十分な観察期間と件数を確保し、季節や広告など他の変更も記録します。

監視表には正常時の基準と連絡先を入れます。フォーム停止、会社情報の誤り、主要URLの404など事業への影響が大きい問題は、発見者が公開責任者へすぐ連絡できるようにします。担当者が不在の場合の代行者、制作会社へ連絡する条件、修正後の再テストも決めます。問題を閉じるときは、原因、修正内容、影響した期間、再発防止を記録します。

リニューアルは公開日だけで完了しません。現行資産の棚卸し、旧新URL対応、施工事例の移行、受付テスト、権限の引き渡し、公開後監視まで終えて、以前のサイトが担っていた役割を新サイトへ移せます。塗装会社と制作会社が確認項目、担当者、期限を共有すれば、問題を早い段階で見つけ、影響が広がる前に修正できます。