「ブログ記事を書くたびに、Google Search Consoleで
手動のインデックスリクエストをするのが正直しんどい……。
せっかくだし、APIを使って自動化できないかな？」
そんな効率化への挑戦が、思わぬ「足元のガタつき」を見つけるきっかけになりました。
今回は、自動化設定の前提となる
XMLサイトマップが404エラーで表示されなかった問題と、
その意外すぎる原因・解決策をシェアします。
異変：設定は正しいはずなのに「404 Not Found」
インデックス登録の自動化を検討し、
まずは自分のサイトの状況をチェックしたところ、
Google Search Consoleで「サイトマップが取得できませんでした」という
不穏なエラーが出ていました。
「設定ミスかな？」と思い、
ブラウザで直接 https://p-o-chitto.com/sitemap.xml を叩いてみると……。
「404 Not Found」
All in One SEOの設定画面では「有効」になっているし、
パーマリンクの設定も問題ない。
キャッシュを消しても、プラグインを再起動しても直らない。
ここで私は仮説を立てました。
「WordPress（プログラム）がURLを生成する前に、
サーバー上の物理レイヤーで何かが衝突しているんじゃないか？」
原因：そこにいたのは「ファイル」ではなく「フォルダ」だった
エックスサーバーのファイルマネージャーを開き、public_html 直下（ルートディレクトリ）を覗いてみると、犯人がすぐに見つかりました。
そこにあったのは、sitemap.xmlという「ファイル」ではなく、
sitemap.xmlという名前の「ディレクトリ（フォルダ）」でした。
中を確認すると、以前にGoogleの所有権確認のために
アップロードした認証用HTMLファイル（google85fa...html）がポツンと入っていました。
なぜこれが404の原因になるのか？
Webサーバー（ApacheやNginx）には、
「物理的に存在するディレクトリやファイルを、
システムが動的に生成するURL（仮想URL）よりも優先して表示する」というルールがあります。
- 理想：
sitemap.xmlを叩いたら、All in One SEOが動的に生成したXMLを表示したい。 - 現実： サーバーが「お、
sitemap.xmlっていうフォルダがあるな。こっちを表示しよう。あ、でもこのフォルダの中にindexファイルがないから404だ！」となってしまっていたわけです。
【考察】なぜこんなフォルダが生まれたのか？
心当たりを探ってみると、過去の自分の「作業ミス」が浮かび上がってきました。
おそらく、Google Search Consoleの認証作業（HTMLファイルのアップロード）と、
サイトマップの設定作業を同時に進めていた際、
「サイトマップ用の場所を作らなきゃ」と勘違いして sitemap.xml という名前の
フォルダを作成し、そこに認証ファイルを放り込んでしまったのだと推察されます。
「サイトマップ」と「サイト認証」。
別々のタスクを並行して進めるうちに、頭の中で情報が混ざってしまった結果の、
人間味あふれるケアレスミスだったかもしれません。
解決手順：物理的な障害物を取り除く
原因がわかれば、あとは掃除するだけです。
エックスサーバーのファイルマネージャーで以下の手順を行いました。
- ファイルの救出：
sitemap.xmlフォルダ内にある認証用HTMLを、一つ上のpublic_html直下にコピー。- ※コピー後のパーミッションは
604になりましたが、エックスサーバーの標準仕様なのでGooglebotの読み取りには問題ありません。
- ※コピー後のパーミッションは
- ディレクトリの削除：
sitemap.xmlフォルダをコピー元認証用HTMLごと削除。 - リライトルールの再生成： WordPress管理画面の「設定 > パーマリンク」を開き、何も変更せずに「変更を保存」をクリック。
まとめ：自動化の前に「土台」を疑おう
以上の手順で、無事に sitemap.xml が表示されるようになりました！
今回、「インデックス登録の自動化」という一歩先の効率化を目指したおかげで、
隠れていた根本的なエラーに気づくことができました。
もし、All in One SEOなどのプラグインでサイトマップが表示されないときは、
設定画面をいじる前に一度
「サーバーのルートディレクトリに変な名前のフォルダやファイルが残っていないか」
を疑ってみてください。
これでようやく、本来の目的だった「インデックス自動化」のスタートラインに立てそうです！
コメント