ホームページ更新が止まった時の再開手順｜原因診断・優先順位・運用表

ホームページの更新が止まったとき、最初にやるのは「古いページを急いで直すこと」ではありません。誰が決めるか、誰が操作できるか、何を正しい情報とするか、どこまで安全に戻せるかを分けないまま触ると、表示崩れ、フォーム不達、メール停止、権限喪失を重ねるおそれがあります。

この記事では、中小企業のWeb担当者が、更新停止を6つの原因へ分け、現行保全、優先順位、検証、更新、受入、定例運用までを7つのゲートで再開する手順を解説します。更新方法や費用を決める前に、まず「どこで止まっているか」を一枚の再開表へ落とします。

更新が止まる原因を6つに分ける

「忙しかったから」だけで終えると、担当を変えても再び止まります。停止点は、担当、権限、技術、情報、承認・契約、定例運用の6つへ分けます。複数が重なる場合も、原因ごとに確認者、期限、合格条件を置きます。

ホームページ更新が止まる6つの原因を担当・権限・技術・情報・承認契約・定例運用に分けた図

ホームページ更新が止まる6原因の診断
停止点	よくある状態	最初の確認	再開条件
1. 担当	退職、兼務、依頼先不明	決定者・依頼者・作業者・確認者	一件ごとの責任者が決定
2. 権限	ログイン不能、個人アカウントだけ	ドメイン、サーバー、CMS、計測	組織側でログイン・回復可能
3. 技術	古いCMS、PHP、テーマ、プラグイン	バージョン、互換性、エラー、復旧先	検証環境と復旧条件が確定
4. 情報	原稿・写真・料金・採用条件が未確定	正本、根拠、適用日、期限	承認可能な素材一式が到着
5. 承認・契約	誰が承認するか、どこまで費用内か不明	作業範囲、回数、期限、追加条件	承認者と受入条件が合意済み
6. 定例運用	依頼方法、棚卸し日、KPIがない	窓口、台帳、月次確認、障害連絡	次回の担当・日付まで登録

契約、ドメイン、制作データ、認証情報そのものが取れない場合は、更新作業を始めずホームページの資産と権限を回収する手順へ分けます。WordPressだけに入れない場合は、データベースやファイルを推測で変更せず、WordPressログイン不能の切り分けを先に行います。

現行状態は一枚の再開シートに集める

担当者の記憶ではなく、確認時刻と証拠をそろえます。公開画面と管理画面は別です。トップページが見えていても、フォーム通知、予約、採用応募、管理画面、更新予約、計測が壊れていることがあります。秘密情報そのものはシートへ貼らず、保管場所と回復方法への参照だけを記録します。

更新再開シートの最低項目
欄	記録する内容	証拠
公開状態	主要URL、HTTP、表示、日付、フォーム、メール	確認時刻、画面、送受信記録
管理入口	ドメイン、DNS、サーバー、CMS、計測	組織側ログイン、所有者、回復先
技術構成	WordPress、PHP、テーマ、プラグイン、外部機能	Site Health、バージョン、エラー
更新候補	URL、変更前後、根拠、適用日、緊急度	正本文書、承認者、差分
実行条件	担当、予定、影響範囲、受入、復旧判定	作業票、試験結果、変更履歴
次回運用	依頼窓口、棚卸し日、KPI、障害連絡	台帳と次回予定

WordPressはRoles and Capabilitiesで、投稿編集、公開、プラグイン・テーマ更新、ユーザー管理の権限が異なります。「管理担当」という肩書ではなく、必要な操作ができるかを確かめます。Search Consoleも組織側の所有権確認を維持し、個人だけが所有者の状態を避けます。

触る前に現行保全と変更停止線を決める

再開初日に、旧投稿を全部更新したり、未使用に見えるプラグインを一括削除したりしません。公開URL、メール、フォーム、予約、決済、計測、検索面の現在値を読み取り、どの異常で作業を止めるかを決めます。本番へ変更を加える作業には、実行者とは別の確認者と復旧判断者を置きます。

WordPressのSite Health画面では、重大な問題、推奨改善、合格した検査、WordPress・テーマ・プラグイン・サーバー・DB・権限等の情報を確認できます。点数だけで安全と判断せず、フォームや外部連携などサイト固有の業務機能も別に試験します。

更新候補は利用者への影響で優先順位を決める

更新日が古い順ではなく、誤情報や停止が利用者へ与える影響で並べます。法令・安全・料金・契約条件、住所・電話・営業時間、採用条件、フォーム・予約・決済、サービス内容、実績・お知らせの順に確認すると、見た目だけの修正へ偏りません。

更新再開時の優先順位
優先	対象	判断理由	受入
A 即時	安全、法令、料金、契約条件、障害告知	誤認・損害・事故へ直結	根拠、責任者、適用日
A 即時	住所、電話、営業時間、休業、採用条件	来訪・連絡・応募の失敗へ直結	全掲載先と案内経路を照合
B 早期	フォーム、予約、決済、メール通知	完了できても社内へ届かない場合がある	入力からDB・通知・返信まで試験
B 早期	サービス範囲、事例、担当、FAQ	問い合わせ前の判断材料	根拠とリンク先を照合
C 計画	デザイン、写真、回遊、古い記事	全体設計とまとめて改善できる	目的、対象URL、測定方法

住所・電話・営業時間の変更は一ページで終わらないため、会社情報を12箇所へ反映する確認表へ分けます。更新範囲と費用を整理する場合は更新・保守費用の見積範囲を使い、緊急修正と改善投資を別の見積にします。

情報が複数の資料に分かれる場合は、更新日が新しい資料を自動的に正本としません。情報の責任部署、承認者、適用開始日、根拠文書を照合し、正本と根拠を一組で指定します。料金や募集条件のように期限がある情報は、公開後の再確認日と失効時の表示方法も決め、次回の棚卸しへ引き継ぎます。

WordPress更新は検証・復旧・互換性を先にそろえる

WordPress本体、PHP、テーマ、プラグインが古い場合も、本番で一斉更新して結果を見る進め方は避けます。公式のUpgrading WordPressは、更新前の復旧可能な状態、プラグイン、ファイル、DB、パーマリンク、更新後確認を扱っています。古い版をまたぐ、独自改修がある、マルチサイトである場合は、検証環境で段階と互換性を確認します。

テーマやプラグインの直接編集は、更新で上書きされるだけでなく、エラーや管理画面不能を起こし得ます。WordPressのEditing Filesも参照し、差分・編集元・反映方法を記録します。サーバーやドメインの移管が必要なら、同じ更新作業へ混ぜずホームページ移管の実行手順へ分けます。

7つのゲートで小さく再開する

ホームページ更新再開の7ゲート
ゲート	合格条件	未達時
1. 現状保全	公開・管理・業務機能の現在値と停止線を記録	変更しない
2. 責任者	決定・依頼・作業・確認・復旧の担当が確定	承認者を決める
3. 優先順位	正本、根拠、適用日、対象URLが確定	原稿作成へ戻す
4. 検証環境	技術更新、差分、互換性、試験、復旧条件を確認	本番へ入れない
5. 更新実施	承認済み差分だけを時間・担当付きで反映	範囲外変更を止める
6. 受入	表示・フォーム・メール・管理・検索面を合格	修正または復旧判断
7. 定例化	台帳、窓口、棚卸し日、次回更新、KPIを登録	完了扱いにしない

内製、スポット外注、継続保守のどれで回すかは、原因診断と再開条件がそろってからホームページ更新方法の選び方で決めます。再開後の月次・四半期運用はホームページ運用の定例表へ引き継ぎ、次回日付が入るまで再開完了と数えません。

受入試験は利用者・管理・業務・検索の4面で行う

見た目が整っていても、送信後に通知が来ない、管理画面で保存できない、検索向け設定が変わる、といった失敗は残ります。PCとスマートフォンの代表幅で、リンク、画像、表、フォーム、キーボード操作、管理操作を確認します。W3CのForms Tutorialも使い、入力欄のラベル、説明、グループ、エラー、完了フィードバックを確認します。

更新後の受入試験
面	試験	証拠
利用者	1440/1024/768/390px、リンク、画像、表、読了	幅、時刻、合否、問題箇所
フォーム	入力、確認、送信、DB、通知、自動返信、エラー	テストID、受信、保存、個人データ削除
管理	ログイン、編集、下書き、保存、公開、予約、権限	役割別の操作結果
技術	HTTP、TLS、404、JS、ログ、Site Health、メール	URL別結果とエラーログ
検索	title、description、canonical、noindex、Article、サイトマップ	HTML、構造化データ、URL検査

フォームで個人データを扱う場合は、個人情報保護委員会の通則編ガイドラインを基に、委託先、安全管理、取扱状況、再委託、テストデータの削除を確認します。実在顧客のデータを安易に試験へ使いません。

更新日は実質変更と表示・構造化データを一致させる

更新再開を示すために、本文を変えず日付だけ新しくするのは避けます。Googleの日付表示のガイドは、公開日・更新日を利用者へ分かる形で示し、構造化データと一致させ、未来日や内容と無関係な日付を使わないよう案内しています。Googleは単一の日付要素だけで判断せず、表示も保証しません。

Article構造化データでは、headline、image、datePublished、dateModified、author等の適用項目を確認します。正規URLだけをサイトマップへ含め、代表URLはSearch ConsoleのURL検査で登録済み情報とライブテストを分けて確認します。再クロール依頼は即時の登録や順位を保証しないため、公開後の取得・インデックス・表示回数を期間で追います。

バックアップは候補制作と本番変更を混同しない

WordPress公式のBackupsが示すように、本番復旧にはファイルとデータベースの両方が必要です。ただし、この記事候補を作る現在の段階では、既存の対象投稿スナップショット1点だけを再利用し、記事ごとのフルバックアップやサイト全体保存を繰り返しません。全48記事の完成後に最終承認が得られた場合だけ、書き込み対象全体について同時点のファイルとDBを一つの検証済みバックアップセットとして用意します。

本番変更時も、同じ変更について似たバックアップを何度も作るのではなく、対象・取得時刻・ファイルとDBの組・保管先・復元確認が特定できる一つの承認済みセットを使います。候補原稿、公開HTMLの要約証拠、本番復旧用バックアップは用途が異なるため、台帳で別々に扱います。