緊急のウェブサイト修復と、サイトを止めない再構築.

ウェブサイトの緊急修復にはどのような作業が含まれるのでしょうか?

緊急対応でやることは4つです。何が壊れているかの確認、被害の拡大を止めること、正常なコピーの復元、そして攻撃者が入った経路を塞ぐことです。まず、トップページ、内部ページ、管理画面のログインページを読み込んでください。そのうえで、エラーが出るページ、異常なコンテンツが出るページ、正常に動くページを見分けます。確認した内容はすべて書き留めてください。焦っていると記憶は曖昧になりますが、リストがあれば必要な修復作業を一目で追えます。

サイトがハッキングされたかもしれませんか？まず被害を確認してください。Googleのガイダンスは、サイト内のファイル改ざんやサーバー上の不審な動きを確認し、すぐにホスティングプロバイダーへ連絡するよう勧めています。ご自身のサーバーでも、同じように確認してください。アップデートが原因でサイトが動かなくなっていることもあります。その場合は、変更箇所を特定して戻してください。サイトが消えてしまったなら、バックアップ、データベース、アーカイブされたコピーなど、コンテンツの元になるものが必要です。ここで無料の診断ツールが役立ちます。公開中のサイトが応答しなくても、ウェイバックマシンの公開インデックスは読み取れるからです。動かなくなっても、手詰まりではありません。使える材料は、まだ残っています。

サイトがダウンしたり、ハッキングされたりした後の最初の1時間は、どうすべきでしょうか?

最初の1時間は、どこがダウンしているかを確認します。ログとバックアップは安全な場所にコピーし、持っている認証情報はすべて変更してください。証拠が上書きされるため、再インストールはしないでください。別のネットワークから、トップページ、内部ページ、管理画面へのログインを確認します。これで、サイト全体がダウンしているのか、一部だけなのかが分かります。ログと最新のバックアップは、誰かがサーバーに触る前にダウンロードしてください。Googleの助言どおり、すぐにホスティングプロバイダーへ連絡します。最後に、ホスティング、管理画面、データベース、FTPのパスワードを変更してください。

ハッキングされたら、サイトをオフラインにするか、503ステータスコードを返すようにしてください。Googleによると、robots.txtでクロールをブロックするより、こちらのほうが効果的です。マルウェアが訪問者に届くのを防げるからです。再インストールの前に、ファイルとログをコピーしてください。捨ててしまう人が多いのですが、そのコピーには、攻撃者がどう侵入したかが残っています。Googleが勧めるサーバー復旧は、信頼できるソースからOSを完全に再インストールし、そのあとクリーンなバックアップから復元する手順です。復旧したら再審査を依頼し、その後も状況を監視してください。

Wayback Machineからウェブサイトを復元できますか?

はい、多くの場合は復元できます。ウェイバックマシンから取り出せるのは、サイトの表示部分（フロントエンド）です。ただし、そのクローラーが取得したページ、画像、ファイルに限られます。ホームページのスナップショットを開くと、web.archive.org/web/ の後ろに14桁のタイムスタンプ（YYYYMMDDhhmmss）が付いています。ここに修飾子を足すと、生データファイル（id_）、スクリーンショット（im_）、JavaScript（js_）、CSS（cs_）を取得できます。

キャプチャデータは、公開CDXインデックスに入っています。記録されているのは、タイムスタンプ、元のURL、MIMEタイプ、ステータスコード、ダイジェスト、長さです。評価ツールはこのインデックスを読むので、ホームページのキャプチャがある月数、最初と最後の正常なキャプチャの日付、アーカイブ済みの固有ページ、画像、PDFの数を確認できます。稼働中のサイトが応答するかどうかは関係ありません。サイトがダウンしているときは、スコアの代わりにアーカイブ記録を表示します。作り直す前に、キャプチャの中身を確認してください。今何が残っているかを、正確に把握できます。

アーカイブされたコピーからは何が復元でき、何が永久に失われてしまうのでしょうか?

アーカイブコピーから復元できるのは、訪問者が実際に見ていた内容です。つまり、レンダリングされたHTML、画像、ファイルです。データベース、ユーザーアカウント、フォーム処理、サーバー側のコードは含まれません。アーカイブされた内部ページを開いて、ソースコードを見てください。表示されるのは、ページを組み立てたテンプレートやクエリではなく、完成後のマークアップのはずです。公開キャプチャに含まれるのは、フロントエンドのコードだけです。いわば建物の写真です。持っていて損はありませんが、そこに住むことはできません。運営していた建物そのものではないのです。

アーカイブには欠けがある前提で見てください。クローラーがCSSファイルや内部ページを取りこぼしていたら、あとから再生成できる人はいません。すべてのページや更新内容が保存されているとも限りません。特に動的コンテンツは欠けやすく、動画、スクリプト、インタラクティブなコンテンツが読み込まれないことがあります。スナップショットによっては、画像も欠けている可能性があります。アーカイブがブロックされていたり、robots.txtのルールが厳しかったりした場合も、欠落が起きます。サイトがReact、Vue、Angularのアプリケーションだったなら、キャプチ

古いサイトを改修すべきか、それとも一から作り直すべきか?

小規模なパンフレットサイトで、原因を1つの変更に絞り込めるなら、既存のサイトを修復してください。同じ不具合が繰り返し起きる場合や、ソフトウェアのサポート期限が切れている場合は、サイトを再構築してください。まずバージョンを確認してください。Drupal 7は2025年1月5日にサポートが終了し、コア、サードパーティ製モジュール、テーマのいずれにもセキュリティアドバイザリが出なくなりました。Adobe Commerce 2.3をお使いですか？その場合、通常サポートは2022年9月8日に終了しています。どちらかを使っているなら、セキュリティ上の脅威からサイトを守る手段はもうありません。

「修復」が向いているのは、あるアップデートやパスワードの盗難が起きるまで、サイトが正常に動いていた場合です。クリーンなバックアップを作り、パッチを当て、パスワードを新しくするだけで済み、そこで終わらせられることもあります。「再構築」が向いているのは、すでにサイトを1回以上復元している場合や、コンテンツの唯一のコピーがアーカイブにしか残っていない場合です。評価の各柱の根拠は、ご自身がどちらのケースに当たるかを判断する材料になります。目的は迷いをなくすことで、問題を長引かせることではありません。

なぜプラグインベースのサイトは頻繁に不具合を起こすのでしょうか?

プラグイン中心のサイトで不具合が続くのは、入れているプラグインがすべてリクエストパス上のサードパーティ製コードで、更新のタイミングがご自身ではなく他の作成者の都合で決まるためです。プラグイン一覧を開いて、作成者の数を数えてみてください。その一人ひとりに、サイトを左右する権限を渡していることになります。更新のたびに、どの2つのプラグインの間でも競合が起こりえます。Patchstackの2026年レポートによると、新規の脆弱性の91％はプラグインに、9％はテーマにあり、WordPressコアは6件だけで、そのすべてが低優先度でした。コアが弱点になることはめったにありません。弱点になるのはプラグインとテーマです。プラグインを入れれば、その分リスクも増えます。

Patchstackの報告では、脆弱性の46％は公開された時点で開発者による修正がありませんでした。そのため、セキュリティ対策をプラグインの更新だけに頼ることはできません。WordPressでは、2025年に直面した脆弱性が新たに11,334件ありました。2024年の7,966件から42％の増加です。最も狙われる脆弱性では、大規模な悪用が始まるまでの時間の中央値が5時間です。1日の勤務時間より短い時間です。パッチ適用は、それより早く済ませる必要があります。

Next.js、Astro、Sanity、Supabaseは、どのようにして同じ失敗を回避しているのでしょうか?

訪問者に届くのは、あらかじめ生成されたページです。リクエストパス上にデータベースもPHPもありません。編集作業とデータは、別のホスティングサービスで管理します。Astroは標準でほとんどのページを静的HTMLとして出力し、クライアントサイドのJavaScriptを取り除くので、JavaScriptを足すのはインタラクティブなコンポーネントだけで済みます。Next.jsの「Incremental Static Regeneration」を使えば、サイト全体を再構築せずにコンテンツを更新できます。バックグラウンドでの再生成に失敗しても、変更前の古いページを配信し続けます。Sanityは、コンテンツをリビジョン履歴付きの構造化されたJSONドキュメントとして保持し、CDN経由のAPIで提供します。

Supabaseでは、データとログイン情報を行レベルのセキュリティで守ります。この設定がないと、権限を持つロールなら誰でも、公開スキーマ内のテーブルを読み書きできてしまいます。ポリシーは必ず確認してください。ホスティング側では、本番に出す前にプレビューデプロイメントで変更を確認できます。Vercel Instant Rollback を使えば、数秒で以前の本番デプロイメントに戻せます。依存関係の更新は必要で、ビルドが失敗することもあります。それでも減らせるのは影響範囲で、メンテナンスが要らなくなるわけではありません。

WordPress、Drupal、Magento、またはWixのサイトを、最新のヘッドレス・スタックに移行することは可能でしょうか?

はい。サイトがWordPress、Drupal、Magento、Wix、Squarespace、Joomlaのどれで動いていても、最新のヘッドレス・スタックへ移行できます。不具合のあるサイトは、このスタック上で再構築します。コンテンツは稼働中のデータベースから、データベースが失われている場合はサイトのアーカイブから引き継ぎます。再構築にCMSプラグインは一切使いません。ご要望の機能はすべて、サイト専用のリポジトリにコードとして置き、レビューしたうえでバージョン管理します。サードパーティ製の要素がページに残って、古くなったり、競合したり、脆弱性を抱えたりすることはありません。

これらのプラットフォーム自体が問題なのではありません。問題になるのは多くの場合、プラットフォームに付随するコードで、ご自身のサイトで確認できます。例外はWixで、レイアウトを一から作り直す必要があります。サイトがWixのサーバーでホストされている必要があります。連絡先や商品情報はエクスポートできますが、Wix Storesの商品エクスポートはCSVファイル1つにつき5,000行までで、デジタル商品には対応していません。サイトがすでに削除されている場合は、まず無料の診断を実行してください（所要時間は2分程度です）。アーカイブにサイトのページ、画像、PDFがいくつ残っているかが分かります。それを見てから、次の対応を決めてください。

よくある質問.

次に読む.

1. 01サイトリニューアルのSEO事前に基準を記録し、事後に照合する。
2. 02レガシーCMSコンサルタント老朽化したプラットフォームについて、コンサルタントがまず確認すること。
3. 03ヘッドレスCMSのSEO監査レンダリング、canonical、プレビュー、テンプレート由来の構造化データ。
4. 04Vibeコーディングのセキュリティ：公開済みのAIサイトからどのような情報が漏洩しているか、そして外部からそれを確認する方法What Ships・セキュリティ