静的サイトのロールバック：公開後に前のバージョンへ戻す手順

静的サイトの公開ミスは、最初は小さく見えます。トップページは開くのに下層ページだけ 404 になる。CSS が読み込まれず、スマートフォンの表示だけ崩れる。画像やPDFのパスが変わっている。クライアント確認用のリンクに、まだ承認されていない文言が出てしまう。

そこで慌てて本番の上から直し始めると、問題が広がります。

公開リンクに実害が出ているなら、まず前の安定したバージョンへ戻す。そのあとで、失敗した公開を落ち着いて調べる。この順序の方が、静的サイトでは安全なことが多いです。

すべての修正で戻す必要はない

ロールバックは、普通の編集作業の代わりではありません。小さな誤字や、誰も困っていない表示のずれなら、修正版をアップロードするだけで十分な場合があります。

前のバージョンに戻すべきなのは、今の公開状態が明らかに悪く、見る人に影響しているときです。

判断は難しく考えなくてかまいません。信頼、確認作業、応募、問い合わせ、キャンペーン、授業提出に影響しているなら、先に戻す価値があります。

静的サイトは「公開状態」を戻しやすい

静的サイトは、HTML、CSS、JavaScript、画像、フォント、PDFなどのファイル一式として扱えます。だから、成功した公開ごとに状態が残っていれば、前の状態へ戻すという考え方と相性がよいです。

これは、サーバー上のフォルダを直接上書きしていく運用とは違います。上書き型の運用では、古いHTML、新しいJavaScript、消えた画像、ブラウザキャッシュが混ざり、どこが本当の公開状態なのか分かりにくくなります。

公開を戻すために残しておきたい情報は、だいたい次の4つです。

Cloudflare Pages は、ロールバックを以前の production deployment へ戻す操作として説明しています。Vercel の Instant Rollback も、production domain を以前の deployment に向け直す考え方です。Netlify でも過去の deploy を production として公開できます。実装はそれぞれ違いますが、共通しているのは「前の公開状態が、もう一度出せる形で残っている」ことです。

障害中に古いサイトを作り直さない

「昔のZIPを探して、ローカルでビルドし直して、もう一度アップロードする」ことをロールバックと呼ぶなら、それは本当は緊急再公開です。

緊急再公開でも直ることはあります。ただし、焦っているときほど別のミスが入りやすくなります。

• 古いソースと当時の公開ファイルが一致していない。
• 依存パッケージやビルド環境が変わっている。
• 画像やPDFだけ別フォルダにあった。
• 担当者が間違った dist や out を選んだ。
• 直したつもりのアップロードで、別のパスを壊した。

公開中の事故で必要なのは、作り直すことではなく、まず安定した表示へ戻すことです。だから小さな静的サイトでも、バージョン履歴は単なる便利機能ではありません。

戻すか、前に進めて直すか

迷ったときは、次のように短く判断します。

ロールバックを常に正解にする必要はありません。大事なのは、公開中の状態が前より悪いとはっきりしているときに、迷いすぎないことです。

戻した直後に見るところ

「成功」と表示されても、作業はそこで終わりではありません。公開リンクを実際に開いて確認します。

1. シークレットウィンドウでトップページを開く。
2. よく共有している下層ページを開く。
3. CSS、JavaScript、画像、フォント、PDF、ダウンロードを確認する。
4. 独自ドメインとプレビュー用の公開リンクを両方使っているなら、両方見る。
5. HTTPS が有効か確認する。
6. 最近のアクセスや統計を見て、リクエストが戻した版に届いているか確認する。
7. チームやクライアントに「今はどの版が公開されているか」を伝える。

ドメイン変更を同時に触っていた場合は、DNS と証明書も見ます。静的ファイルのロールバックは、間違った DNS レコードや期限切れの証明書までは直しません。DeployPages では公開前後の確認用に DNSチェック と SSLチェック を使えます。

ロールバックで直らないもの

前のバージョンに戻せるのは、基本的に静的な公開状態です。サイトの外側にあるものまで、すべて元に戻るわけではありません。

ここを勘違いすると危険です。ロールバックは、静的ファイルとフロントエンドの公開事故には強い。一方で、サイトにつながるすべてのシステムを巻き戻す機能ではありません。

アップロード、Git、CLIで考え方は同じ

静的サイトの公開方法はいくつかあります。ブラウザからアップロードする場合も、Gitから公開する場合も、CLIで公開する場合も、復旧の考え方は同じです。

ブラウザアップロード

HTMLフォルダ、AI生成サイト、ポートフォリオ、PDF、1回限りのランディングページ、クライアント確認用ページでは、ブラウザアップロードがよく使われます。

この運用で怖いのは、前の版が担当者のダウンロードフォルダにしか残っていないことです。公開履歴として残っていれば、前の状態は個人の手元ではなくプロジェクト側に残ります。

Gitからの公開

Gitの履歴は助けになります。ただし、Gitのコミットと実際に公開されたファイルは同じものとは限りません。あとから同じコミットをビルドしても、依存関係、設定、環境変数の違いで出力が変わることがあります。

だから静的サイトでも、成功した公開そのものを戻せる状態で持っておく意味があります。

CLI公開

CLI公開は再現性を高めやすい方法です。それでも、正しくビルドできたから安全とは限りません。パス、画像、PDF、文言、リダイレクト、モバイル表示のどこかを壊したまま公開することはあります。

繰り返し公開できることと、すぐ戻せることは別の安全性です。

DeployPages での位置づけ

DeployPages は、公開中のフォルダを手で上書きし続けるより、静的サイトをバージョンとして扱う公開フローに寄せています。

最初はHTMLファイル、フォルダ、ZIP、PDF、AI生成サイト、フレームワークの静的出力をアップロードして公開リンクを作る。あとから同じプロジェクトで 以前のバージョンに戻す操作、統計、独自ドメイン、パスワード保護、CLI公開 を使う。

重要なのは、公開を重ねても戻る道を残しておくことです。新しいアップロードで公開URLが壊れたときに、訪問者を待たせながら昨日のサイトを再構築する必要はありません。

公開前に決めておく簡単な手順

次のような手順を、公開前にチームで共有しておくと十分です。

地味な手順ですが、公開中のページが壊れたときには、この地味さが役に立ちます。

いつロールバックが必須になるか

明日消すだけのプレビューなら、ロールバックはなくても困らないかもしれません。

ただし、次のどれかに当てはまるなら、前のバージョンに戻せる状態を用意しておくべきです。

• 独自ドメインを使っている。
• クライアント、採用担当者、授業の先生、広告の訪問者にリンクを渡している。
• 複数人が同じプロジェクトを更新する。
• 作品、履歴書、キャンペーン、問い合わせ、サポートに影響する。
• AI生成や外部委託の出力を公開前に確認している。
• 更新が増え、手元のZIP管理では信頼できなくなっている。

静的サイトが本当の仕事の一部になったら、公開は一方通行ではなくなります。戻れる状態があるから、落ち着いて更新できます。

参考

• Cloudflare Pages rollbacks
• Vercel Instant Rollback
• Netlify manage deploys
• DeployPages の以前のバージョンに戻す機能