最近、ポートフォリオサイトに新しいツールページをいくつか追加したので、Googleサーチコンソールにサイトマップとして登録しようとしたのですが、これが地味にハマりました。「XMLファイルを1個置いて送信するだけでしょ?」と軽く考えていたのですが、ブラウザでは正常に表示されているのに、サーチコンソール上ではなぜか「取得できませんでした」の一点張り。原因を切り分けるために、ドメインの勘違い、WordPressのプラグイン疑惑、URL検査ツールでの検証と、一通り遠回りをするハメになりました。
今回登録しようとしたのは、CMSに頼らずHTMLを直接書いて公開している、いわゆる静的ページ群です。WordPress側のサイトマップ（Yoast SEOが自動生成しているもの）とは別枠で、sitemap-static.xml という専用のサイトマップファイルを手動で作成し、それをそのままサーチコンソールに送信する、という運用にしました。ファイルを1個置くだけの単純作業のはずが、思わぬところで足止めを食らうことになります。
同じところで足踏みする人のために、つまずいた箇所と解決の流れをまとめておきます。静的なページを個別にサイトマップ登録している方には、参考になる内容かと思います。
① そもそも本番ドメインを勘違いしていた
まず作業前に、サイトマップに書くべき本番URLを確認しました。GitHubのリポジトリ名や、なんとなく覚えていたドメインから「webstudio168.jp」だろうと当たりをつけて、それで一度サイトマップを作成。
ところが実際にページのソースを確認すると、<link rel="canonical"> タグが指していたのは engineering.webstudio168.jp でした。サブドメイン運用だったことをすっかり失念していたわけです。サイトマップに書くURLとcanonicalタグのURLが食い違っていると、Googleに正しく評価してもらえない可能性があるので、ここは素直にHTMLの中身を確認するのが一番確実でした。「たぶんこのドメインだろう」で進めず、実際のページに書かれている情報を信じるべきだったな、と反省しています。
② 新しく増えたページの拾いこぼし
サイトの更新を重ねるうちに、pixel-ruler や privacy など複数のフォルダが増えていました。最初に作ったサイトマップにはそれらが反映されておらず、「フォルダを追加したから確認して」と言われて初めて気づく始末。
ここで地味に悩んだのが、プライバシーポリシーやお知らせページのような、検索結果に出したいとは限らないページの扱いです。今回は「主要コンテンツのみをサイトマップに載せる」という方針にして、ツールページとトップページだけを対象にしました。サイトマップは全ページを機械的に列挙する場所ではなく、「検索に出したいページのリスト」だと捉えると、判断に迷いにくくなります。
③ ブラウザでは正常なのに「取得できませんでした」
ドメインもページも整理し、意気揚々とサイトマップを送信したのですが、サーチコンソールのステータスは赤字で「取得できませんでした」。ブラウザで直接URLを開くと、XMLはきれいに整形されて表示されているのに、です。
ここで一気に疑心暗鬼になりました。このサイトはWordPressで動いていて、robots.txtもYoast SEOが自動生成しているタイプ。となると疑うべきは、
- セキュリティ系プラグインがGooglebotだけをブロックしている
- メンテナンスモード系プラグインが裏で有効になっている
- キャッシュプラグインがボット向けに壊れたレスポンスを返している
あたりです。実際にプラグイン一覧を確認してみると、「LightStart」と「Maintenance」という、メンテナンスモード系のプラグインがそろって2つも有効化されていました。名前からして怪しさ満点で、見つけた瞬間「これだ」と確信したのですが、念のため設定画面を開いて確認してみると、本体機能自体はオフで、サイトは通常通り公開中。見た目は真犯人っぽかったものの、まさかのシロでした。
ついでにWP Super Cacheの設定も見直しましたが、こちらもクロールを妨げるような設定は見当たりません。プラグイン一覧を上から下まで眺めながら怪しいものを1つずつ潰していく作業は、まるでインストール済みの容疑者リストを尋問しているような気分でした。犯人が見つからないまま候補が尽きていくのは、正直なところかなり焦ります。
④ URL検査ツールで「今アクセスすれば正常」と判明
疑わしいプラグインが空振りだったので、次に頼ったのがサーチコンソールの「URL検査ツール」です。ここで重要なのは、一覧に出てくる「Googleインデックス」のタブではなく、「ライブテスト」を実行すること。前者はあくまで過去にクロールした結果のキャッシュなので、今の状態を知りたいときは後者を見る必要があります。
ライブテストを回してみると、結果は「URLはGoogleに登録できます」。つまり、今この瞬間にGooglebotがアクセスすれば何の問題もない、ということです。ここでようやく話がつながりました。おそらく最初にサイトマップを送信した時点では、まだファイルのアップロードが完了していなかったか、サーバー側の反映にタイムラグがあり、Googleが最初にアクセスしたタイミングでは404だったのだろう、と。
⑤ 一度削除して再送信したら一発で解決
原因の見当がついたので、対処はシンプルでした。サーチコンソールの「送信されたサイトマップ」一覧から該当のサイトマップをいったん削除し、同じURLを入力し直して再送信。それだけです。
数分後に確認すると、ステータスは「成功しました」、検出されたページ数も登録した通りの件数で表示されていました。ファイルやサーバー設定そのものには何の問題もなく、単に「Googleが最初に見に来たタイミングが早すぎた」というだけの話だったわけです。
まとめ
サイトマップまわりのトラブルは、ファイルの中身よりも「タイミング」と「ドメインの思い込み」が原因になっていることが多い、というのが今回の実感です。特に、
- サイトマップに書くドメインは、記憶ではなくcanonicalタグなど実際のHTMLで確認する
- ブラウザで正常に見えても、サーチコンソール側は「取得できませんでした」と表示されることがある
- そんなときはURL検査ツールの「ライブテスト」で今の状態を確認する
- 原因がタイミングのズレだと分かったら、削除→再送信で大抵は解決する
という流れを覚えておくと、次に似た症状に出会っても慌てずに済みそうです。プラグイン一覧を眺めて犯人探しをした時間も、まったくの無駄ではなかったと思うことにします。
