---

name: wordpress-launch-check description: Verify a WordPress site immediately before and after it goes live, so that it does not launch invisible or half-switched. Use when the user is about to publish a new site, relaunch a redesign, promote a staging site to production, hand a site over to a client, or asks whether a site is ready to go live or why a freshly launched site is not appearing in search. Checks the four independent layers that each keep a live site out of search results (the WordPress search-visibility option, the HTML robots meta tag, the X-Robots-Tag response header, and robots.txt), removes launch-blocking access restrictions, finds leftovers from staging, and opens the paths that stay broken while still returning HTTP 200 such as form delivery, login, checkout and analytics. Does not assume that unchecking "Discourage search engines" is sufficient.

WordPress 公開前チェック

公開作業の事故は「作り忘れ」ではなく 「切り替え忘れ」 で起きる。 作ったものは見えているから気づく。切り替えていないものは、見た目が正常なまま放置される。

最も損失が大きいのは「公開したのに検索に出ない」。気づくのは数週間後、たいてい客からの指摘で。

このSkillは、公開の瞬間に切り替わっていなければならないものを、層ごとに別々に確認する。

最初に捨てる誤解

「Settings → Reading の検索避けチェックを外したから大丈夫」は成立しない。

WordPress公式ドキュメントの記述（Settings Reading screen）で確認できる事実:

• 検索避けを有効にすると、5.3以降は <meta name='robots' content='noindex,nofollow'> が wp_head が使われている場合に <head> へ出力される。→ wp_head を呼ばないテーマや、 出力を固定しているフルページキャッシュの下では、設定と実際の出力がずれる。
• 5.2以前の仮想 robots.txt は、WordPressがサイトルートにあり、かつ物理 robots.txt が存在しない場合にだけ効く。 → 制作中に置いた物理 robots.txt は、設定画面のチェックを外しても消えない。
• 公式の注記そのまま: "Neither of these options blocks access to your site — it is up to search engines to honor your request." → **検索避けはアクセス制限ではない。**ステージングの秘匿には使えない。

さらにGoogleの仕様（Search Central / Block indexing）:

noindex が効くには、そのページが robots.txt でブロックされておらず、クローラーがアクセスできる 必要がある。robots.txt でブロックされていると クローラーは noindex を見ないため、 そのページは検索結果に出続けることがある。

つまり noindex と robots.txt は互いを打ち消す。 片方だけ直すと、直したつもりで直っていない。 だからStep 1で4層を別々に見る。

公開の型を最初に決める

型が確定するまで、公開に関わる設定を変更しない。 L3をL1として扱うのが典型的な事故 （ステージング固有の残骸を探さないまま公開してしまう）。

Step 0. 環境と権限を確定する

wp --version || echo "WP-CLI 無し → 管理画面経路（Step 7）を使う"
curl -sI https://example.com/ | head -1        # 401 なら Basic認証が生きている
curl -sI https://example.com/ | grep -i -E 'x-robots-tag|cf-cache|x-cache|age:'

確認すること。

• WP-CLIが使えるか（日本のレンタルサーバーでは標準提供されていないことが多い）
• キャッシュ / CDN が前にいるか。 いる場合、以降の確認はすべてキャッシュを疑う。 設定を直しても出力が変わらないのは、設定が悪いのではなくキャッシュが古いことが多い。
• 依頼者がそのサイトとDNSの管理権限を持っているか

Step 1. 検索に出るかを「4層」別々に確認する（最重要）

1つ見て問題なしと判断しない。 4層は独立に壊れる。

wp option get blog_public
curl -s  https://example.com/ | grep -i -o '<meta[^>]*robots[^>]*>'
curl -sI https://example.com/ | grep -i 'x-robots-tag'
curl -s  https://example.com/robots.txt

層2と層3は、WordPressの設定以外からも来る。 出所を特定するまで「設定は1だから大丈夫」と言わない。

• SEOプラグイン（Yoast / Rank Math / SEOPress / All in One SEO）の noindex 設定。 サイト全体・投稿タイプ別・タクソノミー別・個別ページの4か所にそれぞれある。
• サーバーやCDNの設定、.htaccess の Header set X-Robots-Tag
• テーマ・プラグインが直接出力しているコード

確認は必ず、下層ページも含めて複数URLで行う。 トップだけ直っていて下層に残るのが典型。

for u in / /about/ /contact/ /news/ /sitemap.xml; do
  printf '%s\t%s\t' "$u" "$(curl -sI "https://example.com$u" | head -1 | tr -d '\r')"
  curl -s "https://example.com$u" | grep -i -c 'noindex'
done

この結果をそのまま利用者へ提示する。 「確認しました」ではなく、値を見せる。

Step 2. 公開を妨げているアクセス制限を外す

制作中の秘匿手段は、外し忘れると公開したことにならない。かつ、外し忘れは トップページだけ見ていると気づくのに、CDNのキャッシュ越しだと気づかないこともある。

• Basic認証（.htaccess / .htpasswd、サーバー管理画面のアクセス制限）
• IP制限、メンテナンスモード、Coming Soon / 準備中プラグイン、WP_MAINTENANCE
• ステージング用のホスト制限、hosts依存の確認しかしていない状態

curl -sI https://example.com/ | head -1          # 200 であること（401/403 でない）
curl -sI https://example.com/wp-login.php | head -1

逆方向も確認する。 ステージング環境が残る場合、そちらにはアクセス制限が必要。 検索避けだけでは秘匿にならない（公式の注記どおり）。本番公開と同時に、 ステージングをBasic認証で閉じるか停止する。

Step 3. ステージング・制作環境の残骸を探す

L2 / L3 / L4 で必ず行う。「見た目が正常」を通過するものだけを列挙する。

DBを書き換える操作（旧URL置換など）は、この Skill では実行しない。 必要な場合は移行Skill（wordpress-migration）の手順に従い、バックアップとdry-runを先に通す。

Step 4. 200を返したまま壊れる箇所を開く

HTTPステータスとページの見た目は、壊れていても正常に見える。次は実際に動かす。

1. 問い合わせフォームの送信 — 送信して受信箱に届くまで確認する。 送信完了画面が出ることと、メールが届くことは別。レンタルサーバーの送信制限、 SPF/DKIM未設定、wp_mail が true を返して届かない、が典型。
2. 管理画面へのログイン — 引き渡し先のアカウントで実際に入れるか。権限も確認。
3. 決済 / カート（ECの場合）— 本番モードでのテスト注文を1件通し、後で取り消す。
4. サイト内検索、絞り込み、ページネーション、フォームのreCAPTCHA
5. 404の挙動（存在しないURLで404が返るか。200を返す設定は事故）
6. L2ならば旧URLのリダイレクトを主要URLで実測する

curl -sI https://example.com/definitely-not-a-page-xyz | head -1     # 404 であること
curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://example.com/old-path/

自分で判定できない項目は「未確認」と報告する。 確認していないものを「問題なし」と書かない。

Step 5. 計測と申請（実行は利用者）

• GA4 / GTM の測定IDが本番用になっているか（Step 3）
• Search Console のプロパティ登録とsitemap送信（所有権確認は利用者が行う）
• サーバーのエラーログに新しい行が出ていないか

外部サービスへの送信・申請は代行しない。 何を、どこで、どの順で行うかだけを示す。

Step 6. 公開判定を出す

判定は3つのうち1つ。「たぶん大丈夫」を出さない。

記録として次を残す。未確認は未確認と書く。

## 公開判定 YYYY-MM-DD  型: L?
検索可視性: blog_public=? / meta=? / X-Robots-Tag=? / robots.txt=?
アクセス制限: 解除済み / 残存（内容）
実測した動作: フォーム到達=? ログイン=? 決済=?
未確認: （項目と、確認する人）
判定: 公開可 / 条件付き / 公開不可

Step 7. WP-CLIが無い場合

順序は変えない。確認手段だけを差し替える。

curl が使えない環境でも、ブラウザだけで層1〜4は全部確認できる。 「コマンドが無いから確認できない」は成立しない。

---

止まる条件（該当したら作業を止めて確認する）

1. 依頼者がそのサイト・DNS・サーバーの管理権限を持っているか確認できない。
2. Step 1の4層のうち、出所を特定できない noindex が残っている。 どこから出ているか分からないまま公開すると、公開後に原因を追えない。
3. 「とりあえず公開して、細かいのは後で」と、Step 1またはStep 4の1〜3を省くよう求められた。 包括的な事前同意は、個々の確認を省略する許可ではない。
4. 問い合わせフォームのメールが届かない。公開してよいサイトではない。
5. 決済が本番モードで1件も通っていないECを公開しようとしている。
6. L2で、旧URLのリダイレクト先が決まっていない（公開後に決めると検索評価を落とす）。
7. キャッシュ / CDN の影響を切り分けられず、直したのに出力が変わらない。
8. 公開の期限が迫っているという理由で、判定を「公開可」に変えるよう求められた。 判定は事実で決まる。締切では変わらない。

このSkillが行わないこと

• DNSの変更、サーバー契約、SSL証明書の発行（手順の提示までで、実行は利用者）
• DBの書き換え（旧URL置換は wordpress-migration の領域）
• 検索順位の改善、コンテンツSEO、表示速度の最適化（公開できる状態かどうかだけを見る）
• Search Console / アナリティクスへの登録・送信の代行
• 「検索避け」を秘匿手段として使う設定（公式にアクセス制限ではないと明記されている）