熊取町のホームページ修正依頼｜部分改修の範囲と受入確認

会社名や料金を直したい、スマートフォンで文字が重なる、古いサービスページを整理したい、問い合わせまでの道筋を短くしたい。ホームページの悩みが一部に見えても、修正箇所が共通メニュー、テンプレート、URL、フォーム、計測等とつながっていることがあります。

「この一か所だけ」と依頼した後で、関連ページの崩れやリンク切れが見つかると、費用と公開日が変わります。反対に、古く見えるという理由だけで全面リニューアルを選ぶと、残せた内容・URL・計測まで作り直すことになります。

この記事では、熊取町の事業者がホームページ修正を依頼するときに、部分改修で直せる範囲、調査が必要な境界、依頼資料、バックアップ、見積もり、URL、公開後の受入確認を整理します。フォーム障害の緊急復旧や、毎月の更新代行ではなく、「一度の変更を安全に完了させる方法」が中心です。

修正の目的を「見た目」より先に一文で決める

最初に「何を変えるか」ではなく、「誰のどんな判断を助けるか」を一文にします。

古い料金を直し、利用者が現在の総額を判断できるようにする
スマートフォンの表示を直し、電話・問い合わせへ進めるようにする
サービスを整理し、対象外の相談を減らす
採用条件を更新し、応募前の確認電話を減らす
実績の分類を見直し、発注可否を判断しやすくする

目的が「色を変える」だけだと、完成後に効果を判断できません。色変更が、重要な案内を見つけやすくするためなのか、ブランド統一のためなのかを確認します。

部分修正・改善・再設計を三段階で判断する

修正の大きさはページ数だけで決まりません。共通部品、データ、外部連携へ波及するかを見ます。

段階	代表例	既存構造	主な確認
部分修正	文言、画像、色、余白、リンク	そのまま使う	対象箇所と表示確認
部分改善	見出し、順番、導線、入力項目	一部組み替える	関連ページ、計測、受入条件
再設計	ナビゲーション、テンプレート、CMS、URL	役割から見直す	移行、リダイレクト、データ、保守

一ページだけでも、そのページが共通テンプレートで作られていれば全ページへ影響します。反対に、ページ数が多くても同じ定型差し替えなら部分修正として進めやすい場合があります。

部分修正で進めやすい条件

次の条件がそろうほど、範囲と納期を決めやすくなります。

変更後の正しい文章・画像が決まっている
対象URLと箇所を特定できる
共通テンプレートや外部連携へ影響しない
CMSやサーバーへ安全に作業できる
現在のテーマ・プラグイン・実行環境が保守可能である
URLを変えずに目的を達成できる
公開前の確認環境または下書きを用意できる
公開後の合格条件を決められる

誤字、営業時間、既存画像、リンク等は比較的切り分けやすい修正です。ただし電話番号、料金、契約条件、個人情報等は小さな変更でも事業影響が大きいため、内容責任者の承認を必須にします。

調査を先にした方がよい境界

次の場合、すぐに制作見積もりへ進まず、現状調査を分けます。

管理画面へ入れるが、誰が所有しているか不明
制作会社独自の仕組みで、編集方法が分からない
同じ箇所が複数ページへ自動表示される
フォーム、予約、会員、決済等と連携している
URLを変えないと目的を達成できない
スマートフォンだけで広範囲に崩れる
CMS・テーマ・プラグイン・PHP等が古く、更新影響が読めない
不正アクセス、改ざん、個人情報の懸念がある
計測タグ、広告、外部検索・地図等へ同じURLを使っている

見積もり前の調査費と実装費を分けると、原因不明のまま「一式」へ余裕を上乗せする必要が減ります。調査後に、部分修正、段階改修、リニューアルの選択肢を比較します。

影響範囲を五つの層で確認する

修正箇所から外側へ、次の五層をたどります。

内容: 文章、画像、価格、日時、条件
表示: PC、スマートフォン、見出し、表、ボタン
機能: フォーム、検索、予約、地図、ダウンロード
接続: 内部リンク、外部サービス、計測、SNS・広告
基盤: CMS、テーマ、プラグイン、サーバー、DNS

例えば問い合わせボタンの文言だけを変える場合でも、クリック計測がボタンの属性に依存していると、解析が止まる可能性があります。サービス名を変える場合は、本文、メニュー、パンくず、タイトル、構造化データ、PDF、問い合わせ選択肢まで確認します。

依頼資料は「現状・変更後・変えないもの」をそろえる

画面写真へ赤丸を付けるだけでは、どのURLか、スマートフォンだけか、共通部品かが分かりません。依頼票へ次を入れます。

依頼番号、依頼日、希望公開日
対象ページのURL
端末・ブラウザと画面写真
現在の状態と困っている行動
変更後の文章、画像、配置
変更してはいけない内容・機能
関連するページ・外部サービス
内容確認者と公開承認者
公開後の合格条件
元に戻す条件と連絡先

「変えないもの」を書くと、改善提案が依頼範囲を越えにくくなります。文章作成も依頼する場合は、事実を決める担当と表現を整える担当を分けます。

素材は最新版と利用権を確認する

ロゴ、写真、PDF、料金表等は、ファイル名だけでは最新版を判断できません。公開版、差し替え版、公開終了版を分け、更新日と責任者を付けます。

元データとWeb用データの両方があるか
写真の撮影者・被写体・利用範囲を確認したか
退職者、終了商品、旧ロゴが残っていないか
PDF内にも古い情報が残っていないか
画像内文字がスマートフォンで読めるか
代替テキストで画像の役割を伝えられるか

資料の一部だけを直す場合、元のレイアウトデータがないと再制作になることがあります。見積もり前に編集可能な形式の有無を伝えます。

バックアップはファイルとデータベースの両方を確認する

WordPress公式のバックアップ解説は、一般的なサイトの完全復元にはファイルとデータベースの両方が必要と案内しています。画像やテーマだけ、またはデータベースだけでは戻せない構成があります。

修正前に次を確認します。

バックアップ対象: ファイル、データベース、設定、外部データ
取得時刻: どの公開状態へ戻せるか
保存先: 本番サーバー障害時にも取り出せるか
保持期間: 問題発見まで残るか
復元担当: 誰が作業し、誰が判断するか
復元時間: 事業上許容できるか
復元試験: 実際に読み出せることを確認したか

「バックアップあり」という契約名だけで終わらせません。更新代行、制作会社、サーバー会社のどこが復元を担当するかも決めます。

公開前の確認環境と切り戻しを用意する

可能であれば、本番とは別の検証環境またはCMSの下書き・プレビューで確認します。検証環境へ本番の個人情報を無断で複製しません。

公開計画には次を入れます。

反映日時と影響する時間帯
公開担当、確認担当、判断責任者
作業前バックアップと変更一覧
キャッシュ・CDN・検索インデックス等の反映差
公開後に確認するURL・機能
問題時に戻す基準と期限
利用者へ告知が必要な停止・変更

大きな修正を繁忙時間に行う場合、問題発生時の影響が増えます。熊取町内の店舗・予約型事業等では、営業時間、予約受付、キャンペーン開始等と公開日時を合わせます。

URL変更は別案件として扱う

ページ名を直すだけのつもりでも、URLまで変更すると、検索結果、ブックマーク、QRコード、広告、地図、SNS、メール、社内資料等へ影響します。

Google検索セントラルは、URL変更時に旧URLと新URLの対応表を準備し、適切なリダイレクト、内部リンク、canonical、サイトマップ、監視等を行うよう案内しています。また、CMS変更、デザイン変更、ドメイン変更等を同時に進めず、一つずつ変更する考え方を示しています。

URLを変える場合は次を用意します。

項目	確認内容
対応表	旧URLと最も関連する新URL
転送	恒久・一時の目的に合う設定
内部リンク	新URLへ直接更新する
外部掲載	広告、地図、SNS、QR、資料
検索設定	canonical、サイトマップ、noindex
計測	新旧URLとイベントを継続して測る
監視	404、転送誤り、流入、問い合わせ

多数の旧URLを関係の薄いトップページへ一括転送しません。URLを変えなくても目的を達成できるなら、変更しない選択も比較します。

見積もりは作業と不確実性を分けて読む

金額差は、画面数より調査・共通部品・連携・確認の範囲で生まれます。

見積項目	含める内容	確認したい境界
現状調査	CMS、構造、権限、関連機能	調査後の追加承認
デザイン	配置、文字、画像、端末差	修正案・回数
実装	テンプレート、CSS、機能	共通部品への影響
コンテンツ	原稿、画像、表、PDF	事実確認・権利
SEO	URL、メタ、内部リンク	順位保証ではないこと
テスト	端末、リンク、フォーム、計測	対象環境・シナリオ
公開	バックアップ、反映、切り戻し	作業時間・責任者
保証	不具合修正、監視、報告	期間・対象外条件

不明点を「一式」に含めず、調査で判明したら見積もりを更新する承認点を作ります。事業者側の原稿変更と制作側の不具合修正で、修正回数の扱いも分けます。

外注先は説明・証拠・引き継ぎで比較する

近さや価格だけでなく、次の質問へ具体的に答えられるかを見ます。

部分修正で済む根拠と、再設計が必要な境界は何か
どのページ・機能・外部サービスへ影響するか
修正前に何をバックアップし、どう戻すか
どの環境・端末・シナリオで確認するか
URL・検索・計測へ影響するか
公開後に何を成果物として渡すか
契約終了後も別の担当者が保守できるか

専門用語を避けるだけでなく、判断根拠、未確認事項、選択肢を説明できる相手を選びます。「必ず順位が上がる」「絶対に崩れない」等の保証ではなく、確認方法と問題時の対応を見ます。

受入確認は修正目的から逆算する

見た目を眺めるだけでは、完成を判断できません。依頼時の目的ごとに合格条件を作ります。

変更した文章・価格・日時が承認版と一致する
PC・スマートフォンで文字、画像、表がはみ出さない
メニュー、パンくず、関連記事から到達できる
電話、地図、問い合わせ、予約、資料リンクが動く
フォームの完了、自動返信、管理者通知を確認した
画像の代替テキスト、見出し順、キーボード操作を確認した
構造化データ、メタ情報、canonicalが内容と一致する
計測タグと主要行動が記録される
旧URL・旧情報・キャッシュの扱いを確認した
問題時に更新前へ戻せる

デジタル庁のユーザビリティ・アクセシビリティ資料も参照し、利用者が誤操作しにくく、スマートフォン、拡大、読み上げ等でも情報を得られるかを確認します。

セキュリティを弱める近道を選ばない

表示崩れを直すために、保護機能を無効化する、管理者権限を共有する、古いプラグインへ戻す等の一時対応は、新しいリスクを作ることがあります。

IPAの「安全なウェブサイトの作り方」も参照し、入力、出力、認証、アクセス制御等に関わる修正は、見た目の受入だけで終わらせません。外注担当者ごとに必要最小限の権限を発行し、作業後に停止します。個人情報を含む本番データを検証環境へコピーする場合は、必要性、保護、削除を確認します。

公開後は短期確認と中期評価を分ける

公開直後は品質、数週間から数か月では目的への効果を見ます。

時期	主な確認
公開直後	表示、リンク、フォーム、計測、エラー
翌営業日	問い合わせ、担当者受信、キャッシュ、外部掲載
1週間程度	404、端末別問題、利用者からの申告
一定期間後	閲覧、行動、問い合わせ内容、対象外相談

修正前の基準値と、広告、季節、休業、キャンペーン等を記録します。短期間の問い合わせ増減だけで修正の成果を断定しません。