DOCUMENT · 6.2 KB

skills/wordpress-launch-check/references/LAUNCH-DAY-RUNBOOK.md

Workspace snapshot · 09/04 13:33

公開当日ランブック

SKILL.md の手順を、時間軸に並べたもの。 当日にまとめてやろうとすると必ず削られる。 削られるのは Step 4（実測）で、そこが本体。

対象は L1（新規公開）／L2（リニューアル）／L3（ステージング本番化）。 L4（ドメイン変更を伴う公開）は、URL置換を wordpress-migration で終えてからここへ入る。

T-72時間 — 合意する

技術的な準備より先に、決まっていないことを潰す。 当日に決めることを残さない。

公開日時と、作業する時間帯。ECや会員制なら営業時間外
誰が最終判定するか（判定できる人が当日いない、が最も多い延期理由）
公開後に問題が出たとき、戻すのか直すのか。戻す場合の判断者と手段
L2: 旧URL → 新URLの対応表。1対1でないURLの扱い（統合、削除、410）
問い合わせメールの最終的な宛先と、届いたことを誰が確認するか
計測: GA4 / GTM の本番測定ID、Search Consoleの所有者
DNSを触る場合、TTLを短くしておく（切替の48〜72時間前）
SSL証明書が新しいホスト名で発行済みか

合意テンプレート:

公開日時: YYYY-MM-DD HH:MM (JST)
型: L1 / L2 / L3
最終判定者:
問題発生時: 戻す / 直す  判断者:
問い合わせ宛先:
測定ID: G-____  / GTM-____
旧URL対応表: あり（件数 __）/ 不要

T-24時間 — 状態を記録する

mkdir -p ~/wp-launch/$(date +%Y%m%d) && cd ~/wp-launch/$(date +%Y%m%d)
wp core version                > core.txt
wp option get blog_public      > blog_public-before.txt
wp option get siteurl          > siteurl.txt
wp plugin list --fields=name,status,version --format=csv > plugins.csv
curl -s  https://example.com/robots.txt > robots-before.txt
curl -sI https://example.com/  > headers-before.txt

DBとファイルのバックアップを取り、空でないこと・末尾まで書けていることを確認
復元手順を先に確認する（取得できた ≠ 戻せる）
公開直前に更新作業を入れない。 プラグイン更新と公開を同じ日に重ねると、問題が出たときにどちらが原因か分からなくなる

T-1時間 — 切り替える

順序を守る。robots.txt を先に開け、次に noindex を外す（理由は INDEXABILITY.md）。

robots.txt の Disallow: / を解除（物理ファイルの存在を確認）
検索避けを解除 → wp option update blog_public 1
SEOプラグインの noindex を解除（サイト全体／投稿タイプ／タクソノミー／個別）
X-Robots-Tag を出しているサーバー設定・.htaccess の行を削除
キャッシュとCDNを消す（ここを飛ばすと以降の確認が全部嘘になる）
Basic認証 / IP制限 / Coming Soon / メンテナンスモードを解除
計測IDを本番へ差し替え
決済を本番モードへ
メール通知先を本番へ

T+0 — 判定する（30分以内）

SKILL.md の Step 1〜4 を実行する。ここは省略しない。

for u in / /about/ /contact/ /news/ /sitemap.xml /robots.txt; do
  printf '%s\t' "$u"; curl -sI "https://example.com$u" | head -1 | tr -d '\r'
done
curl -s  https://example.com/ | grep -i -o '<meta[^>]*robots[^>]*>' || echo "robots meta: なし（正常）"
curl -sI https://example.com/ | grep -i x-robots-tag || echo "X-Robots-Tag: なし（正常）"
curl -sI https://example.com/definitely-not-a-page-xyz | head -1   # 404 であること

手で動かす（自動判定できない = 省略してよい、ではない）:

問い合わせフォームを送信し、受信箱に届くまで確認
引き渡し先のアカウントでログイン
EC: 本番モードでテスト注文1件 → 確認後に取り消し
L2: 旧URLの主要なものを実測

while read -r old; do
  printf '%s -> %s %s\n' "$old" \
    "$(curl -s -o /dev/null -w '%{http_code}' "$old")" \
    "$(curl -s -o /dev/null -w '%{redirect_url}' "$old")"
done < old-urls.txt

判定を出す（公開可 / 条件付き / 公開不可）。未確認は未確認と書く

T+24時間

サーバーのエラーログに新しい行が出ていないか
問い合わせが実際に届いているか（当日1件通っても、翌日届かないことがある）
計測にデータが入っているか（0件なら差し替え漏れ）
Search Console のカバレッジに noindex 由来の除外が出ていないか
L2: 旧URLのリダイレクトがキャッシュ越しでも効いているか

T+7日

site:example.com でインデックスが増えているか（0件なら4層を再確認）
404の発生（対応表から漏れたURL）
旧サーバー・旧ステージングの停止または閉鎖 **DNSのTTL経過 + 7日は残す。**先に消すと戻せない
バックアップの保管期限を決めて記録（認証情報とDBの中身を含むため放置しない）

報告テンプレート

## 公開報告 example.com / YYYY-MM-DD / 型: L?

### 切り替えたもの
- robots.txt: Disallow: / を解除
- blog_public: 0 → 1
- Basic認証: 解除
- 計測ID: G-XXXX（本番）
- 決済: 本番モード

### 実測した結果
- 検索可視性 4層: blog_public=1 / meta なし / X-Robots-Tag なし / robots.txt 許可
- 主要URL: / 200, /about/ 200, /contact/ 200, /sitemap.xml 200, 存在しないURL 404
- 問い合わせフォーム: 送信 → 受信確認 済（HH:MM）
- ログイン: 済（アカウント名）

### 未確認（確認する人）
- 決済のテスト注文（○○様側で実施予定）

### 判定
条件付き公開 — 上記の未確認1件を除き問題なし

### 次に見る日
T+24h: MM/DD、T+7d: MM/DD

「問題なく公開できました」で終わらせない。 何を切り替え、何を実測し、何を確認していないかが残っていることが、次の作業者への資産になる。