導入：引っ越し後のエラーの嵐
BloggerからWordPress（リトルサーバー）への引っ越し。 ローカル環境（Local WP）でちまちま作ったデータを本番サーバーに流し込み、「よっしゃ、これで俺のWordPressブログが爆誕したぜ！」と最高の気分に浸っていた。
……が、最後の最後で最大の絶望が待っていた。
Googleサーチコンソールにサイトマップ（sitemap.xml）を登録しようとした瞬間、「無効なパスです」という冷酷なエラー。
ネットの解説記事を漁り、Cloudflareの設定を変え、ブラウザをシークレットモードにしても、1ミリも状況が変わらない。ボタンを押した瞬間に、ラグすらなく秒速で弾かれる絶望のループ。
もし、あなたも同じエラーでハゲそうになっているなら、今すぐネットの「一般的なマニュアル記事」を閉じてほしい。原因はそこじゃない。真犯人はGoogle側にいる。
今回は、素人がインフラのバグに正面から殴り込みをかけ、完全勝利するまでの泥臭いデバッグの全記録を公開する。
容疑者その①：Cloudflareの「ボットファイトモード」強すぎ問題
まず最初に疑ったのは、セキュリティの壁だ。 このブログはCloudflareを噛ませているのだが、こいつのセキュリティが強すぎて「Googleのクローラーすらハッカー扱いして水際ブロックしているんじゃないか？」という仮説を立てた。
対策：一時的にボット保護をユルくしてみる
Cloudflareの管理画面にログインし、「セキュリティ」➔「ボット」にある「ボットファイトモード」を一度オフにしてみた。
結果：ダメ。相変わらずサチコは「無効なパス」と即答で弾いてくる。
ただ、ネットワークの壁が原因ではないという選択肢を1つ潰せたので、これは無駄な検証ではなかった。次だ。
容疑者その②：ブラウザのキャッシュの呪い
「画面がバグっているときは、とりあえずシークレットウィンドウ」というのがセオリーだ。ブラウザが古いキャッシュを掴んだまま、狂った画面を表示し続けている可能性を疑った。
対策：シークレットモードで再挑戦
Chromeのシークレットウィンドウを開き、クリーンな状態でサーチコンソールにログインして、魂のサイトマップ送信。
結果：やっぱりダメ。一瞬で弾かれる。
ここで、ある重大な「違和感」に気づく。 外部の通信エラーやサーバーの応答待ちなら、ボタンを押したあとに数秒の「ラグ（待ち時間）」があるはずだ。なのに、ボタンを押した1ミリ秒後には「無効！」と画面に突き返される。
つまり、これは通信が外に出ているのではなく、サチコのシステム内部の時点でハナから処理を拒否して即死させているという肌感（確信）を得た。
【真犯人】Googleサチコ側の「幽霊プロパティ」の罠
ここでようやく、最大の盲点にたどり着く。
原因は自分のWordPressでもサーバーでもなく、「過去のBlogger時代の記憶を引きずってシステム内部でフリーズしている、サーチコンソール自体のバグ」だった。
今回、ドメインプロパティ（サチコの左上で地球儀マークがついている、ドメイン丸ごとを管理する枠）を使っていた。これが、大昔のBlogger時代の古いデータや設定の残像をデータベースの奥底でガッチリ掴んだままロックがかかり、新しいWordPressのサイトマップを一切受け付けない「幽霊プロパティ」と化していたのだ。
これが、秒速でエラーが返ってくる本当の理由だった。内部で回路がショートしているのだから、WordPress側で何をいじっても直るわけがない。
【一撃解決】狂ったプロパティは「即削除」して右側で作り直せ！
原因さえ分かれば、やることは一つ。 システムが狂っているなら、物理的に一度ぶっ壊して作り直すのがDIYの基本だ。
手順1：未練なくドメインプロパティを削除する
サーチコンソールの「設定」から、大昔の記憶を引きずってフリーズしているドメインプロパティをサクッと消去（削除）した。
手順2：右側の「URLプレフィックス」でゼロから登録し直す
プロパティを新しく追加する画面で、左側の「ドメイン」ではなく、右側の「URLプレフィックス」を選択。そこに新居のURL（https://grunge-diy.com/）を入力して、新しく枠を作り直した。
手順3：親玉 sitemap.xml を送信する
まっさらな状態で生まれ変わったサチコの画面で、プラグイン（XML Sitemap Generator for Google）が吐き出した親玉URL sitemap.xml を入力し、祈るような気持ちで送信ボタンをポチリ。
結果：
「サイトマップ インデックスは正常に処理されました」の鮮やかな緑の文字。
勝った。一撃で開通した。
最後の仕上げ：古いBloggerの記事は「放置」すると死ぬ
サチコが開通した瞬間、裏で連動して post-sitemap.xml などの子分サイトマップも自動で読み込まれ、移行した大切な記事たちが一気にGoogleの巡回ルートに乗った。
しかし、ここで最後の罠がある。 「Blogger側の記事、インデックス登録いっちょんされてないし、めんどいから放置でいいか」は絶対にNGだ。
同じ内容の記事がネット上に2つ存在していると、Googleから「悪質なパクリ・重複コンテンツ」と判定され、せっかく作ったWordPress側の評価がガタ落ちする。さらに、過去のセキュリティ警告の元凶が残り続けるリスクもある。
私は「めんでぃー」と感じつつも、Blogger側のブログを丸ごと完全に消去（または下書き化）した。 これでGoogleを惑わすノイズは消滅し、正解のページはWordPressのほうだけだと100%理解させることができる。
最後にサチコの「セキュリティの問題」画面から、「サーバー移転してフルスキャン完了、完全潔白です」と堂々と審査リクエストを送信して、すべての戦いに終止符を打った。
まとめ：AIをナビに、最後は自分の「肌感」でバグをブチ破れ
今回のトラブルで痛感したのは、ネットの転がっているマニュアルをなぞるだけでは、イレギュラーなインフラのバグには立ち向かえないということだ。
AI（Gemini）をナビゲーターにして可能性を1つずつ潰しつつ、最終的に「このエラーの返り速度はおかしい」という現場の肌感を信じてプロパティの物理削除に踏み切ったからこそ、この大勝利を掴むことができた。
もしあなたもサチコのエラーで無限ループに陥っているなら、一度そのプロパティを疑ってみてほしい。 工具（AI）を使いこなし、泥臭く手を動かせば、素人でも数万円の業者コストをすっぱ抜いて、完璧なシステムを構築できる。
これだから、DIYはやめられない。
コメント