2026年9月4日

pages.devでインデックスされないのは「一律noindex」のせいではない。1ヶ月半入らなかった実例とヘッダーの実測

Search Consoleに、7本中6本ぶんこの表示が並んでいた。

URL が Google に登録されていません
URL が Google に認識されていません

Cloudflare Pagesの無料ドメイン（jidokacho.pages.dev）でブログを公開して、1ヶ月が過ぎたころだ。検索して調べると、こういう説明が出てくる。

*.pages.dev にはCloudflareが X-Robots-Tag: noindex を付けているので、検索結果に出ない

これを読んだとき、正直ほっとした。自分の記事が悪いのではなく、ドメインのせいだと分かったから。

その安心は、根拠が薄かった。

まず、ヘッダーを実測した

X-Robots-Tag はHTTPヘッダーなので curl -I で見える。旧ドメインは今も生きているので、そのまま叩いた。

curl -s -I https://jidokacho.pages.dev/posts/server-erabi/

Cloudflareの公式ドキュメントを読み直すと、noindexが自動で付くのはプレビュー配信——<ハッシュ>.<プロジェクト>.pages.dev や <ブランチ名>.<プロジェクト>.pages.dev のほうだった。

ここから言えるのは、Cloudflareが本番の <プロジェクト>.pages.dev に一律でnoindexを付ける仕様ではない、というところまでだ。少なくとも、公式が説明している対象URLと、通説が指しているURLは違う。通説がどこで生まれたのかまでは分からない。

そしてこれは2026年9月4日に測った結果で、7月時点のヘッダーは保存していない。当時も同じだったとは言い切れない。

——ただ、当時のSearch Consoleの表示にも、noindex説と噛み合わない点があった。

症状の名前が、答えを言っていた

インデックスされない状態は、ひとつではない。Googleがページを載せるまでには「①URLを発見する → ②クロールする → ③登録するか判断する」という流れがあり、処理がどこまで進んだかに応じて、Search Consoleに異なる表示が出る。

大事なのは、noindexが働くのは③の判断の場面だということだ。noindexはHTMLまたはHTTPレスポンスに含まれる指示なので、Googleがそれを検出するには、まずそのURLをクロールする必要がある。「クロール済み - インデックス未登録」も同じで、これも一度来たあとの結果だ。

私の6本について、Search Consoleはそこまで進んだと示していなかった。表示は「URL が Google に認識されていません」——noindexを検出済みと示す状態ではない。 少なくとも、noindex説はここで症状と噛み合わなくなる。

補強がもうひとつある。同じ時期、トップページ・claude-code-fukugyo・about・privacyの4ページはインデックスされていた。 同じ pages.dev ドメインの、同じ配信元から出ている4ページが。同じ期間、このドメインの全URLに一律でnoindexが付き続けていたなら、この非対称は起きない。

（※ここに挙げた表示名は代表的な例で、Search Consoleは画面や時期によって文言が変わることがある）

では何が詰まっていたのか。当時のサイトマップは1ヶ月半「取得できませんでした」のままで、検出ページ数は0だった。私の観測は「発見経路が細っていた」という説明と整合する。 ただしURLは内部リンクや外部リンクからも見つかるので、サイトマップだけが原因だったと確定はできない。この経緯はサイトマップが1ヶ月半読まれなかった話に細かく書いている。

移したあと入った。ただし因果は証明できていない

2026年8月22日に独自ドメイン jidokacho.com へ移した。その日のうちにサイトマップが「成功しました」に変わり、8月24日にはURL検査で確認した5URLすべてが「登録されています」になった。（時系列の詳細は前述の記事に載せている）

旧ドメインで「認識されていません」だった記事が、移行後に確認した範囲ではすべて登録されていた。1ヶ月半動かなかったものが、数日で動いたことになる。

それでも「独自ドメインにしたから入った」とは書けない。同じ期間に、サイトマップが読まれるようになったこと、Search Consoleのプロパティを作り直したこと、公開から時間が経ったことが同時に起きている。どれが効いたのかを分離する実験を、私はしていない。

それでも独自ドメインは取る。理由はSEOではない

ここまで書いておいて結論はこれだ。検索から人を呼び続けるつもりなら、早めに独自ドメインを取ったほうがいい。 ただし「pages.devだとインデックスされないから」ではない。

理由は、URLを自分の資産として持てることと、あとから移すほど確認の範囲が広がることの2点だ。移行ではSearch Consoleのプロパティを作り直し、サイトマップを登録し直すことになる。canonicalは私のサイトでは設定ファイルから生成しているので書き換え自体は軽かったが、記事の中に直接書いたリンクと、移行後の表示確認は記事数だけ増える。 私が移したのは8本の時点だった。

.com の実費は年1,600円前後（取得先の比較は独自ドメインはどこで取ると安いのかにまとめている）。金額として安いと証明したわけではなく、私は年1,600円より、後日の移行作業のほうを重く見たということだ。

逆に、検索流入を狙わない用途——社内向けの資料や動作確認用のページなら、pages.devのままで困らない。

移したあと、旧pages.devは消えない

最後に、移行時に見落としやすい点をひとつ。

少なくとも私の構成では、独自ドメインを設定しても旧 pages.dev は自動では消えなかった。 今日確認したら、私の jidokacho.pages.dev も200を返して普通に読める状態のままだった。この記事のためにcurlを叩くまで、私は気づいていなかった。

同じ中身が2つのURLで読める状態になるので、放っておくと新旧が別々のURLとして扱われる可能性がある。私の場合は旧ドメイン側のHTMLにも <link rel="canonical" href="https://jidokacho.com/..."> が入っていて、新ドメインを正規URLとして示せている（canonicalは指示ではなくシグナルなので、必ずそのとおり採用されるとは限らない）。旧URLに来た人もまとめて新URLへ送りたいなら、Cloudflareの一括リダイレクトで301を設定する手もある。

この記事で言えたのは2つだ。本番の pages.dev に一律でnoindexが付くという説明は、Cloudflare公式の仕様・今日の実測・当時4ページが登録されていた事実のどれとも合わない。 そして私のケースでSearch Consoleが出していたのは、noindexを検出済みと示す表示ではなかった。

原因を1つに特定するところまでは、私にはできていない。ただ、pages.dev でインデックスされないとき、まず見るのはSearch Consoleがどの表示を出しているかだと思う。「認識されていません」なら、まずサイトマップや内部リンクといった発見経路のほうを確認する。