📖 11 分で読めます

Google Search Console にサイトマップを送信する方法（2026年版）

ステップごとに解説：サイトの所有権を確認し、sitemap.xml を送信し、インデックス登録をリクエストし、「取得できませんでした」ステータスを解消する。

  • Google Search Console
  • Sitemap
  • Indexing

サイトをリリースした。ページは公開され、HTML はきれいで、コンテンツも良い。それなのに site:yourdomain.com を検索しても何も出てこない。Google はあなたの存在を知らないのだ。

サイトマップとは、クロールしてほしい URL の一覧を機械可読な形で Google に渡す手段だ。これを Google Search Console（GSC）経由で送信することで、「これが私のサイトの正規な目録です。ここから始めてください」と Google に伝えることになる。インデックス登録を保証するものではないが、発見（discovery）の問題は解消できる。新規サイトにとって、これが最も時間のかかる部分なのだ。

このガイドは実践的で開発者向けの内容だ。所有権の確認、サイトマップの送信、重要ページのインデックス登録リクエスト、紛らわしい Couldn't fetch ステータスの読み解き、そしてすべてのクローラーがサイトマップを見つけられるよう robots.txt に組み込む方法を扱う。余計な飾りはなく、実際に使えるコマンドだけだ。

🧑‍💻 開発者視点：サイトマップは <loc> URL のリストとオプションの <lastmod> ヒントを並べただけの XML ドキュメントにすぎない。GSC は Google のクロール／インデックスパイプラインを覗くダッシュボードだ。サイトマップの送信は「これが私の URL リストです」という POST のようなシグナルであり、魔法のような処理は何も起こらない。あなたは「ページが存在する」状態から「Googlebot が取得する」までの経路を短くしているだけだ。

所有権を確認する

GSC が何かを表示する前に、まずそのサイトを自分が所有していることを証明する必要がある。GSC には2種類のプロパティタイプがあり、どちらを選ぶかは重要だ。確認方法と表示されるデータの両方を左右するからだ。

ドメインプロパティURL プレフィックスプロパティ
カバー範囲全サブドメイン + http/https1つの正確なオリジンのみ
スコープの例example.com、www.、blog.、http と httpshttps://example.com/ のみ
確認方法DNS TXT レコードHTML タグ、HTML ファイル、GA、GTM、または DNS
*.pages.dev で使えるか不可（DNS を編集できない）可
最適な用途DNS を自分で管理しているサイトサブドメイン、手早く始めたい場合、細かいデータが欲しい場合

ドメインプロパティは DNS TXT レコードで確認し、その後ドメイン配下のすべて（あらゆるサブドメイン、両プロトコル）をカバーする。DNS ゾーンを自分で所有している場合には最もすっきりした選択肢だ。GSC は追加すべきトークンを提供してくれる：

# Add this as a TXT record on the apex (@) of your zone
google-site-verification=AbC123dEf456GhI789jKl0mNoPqRsTuVwXyZ_example

たいていのレジストラや Cloudflare DNS では、次のように追加する：

Type:  TXT
Name:  @            (or yourdomain.com)
Value: google-site-verification=AbC123...
TTL:   Auto

GSC で「確認」をクリックする前に、伝播済みかどうかを確認しよう：

dig +short TXT yourdomain.com | grep google-site-verification
# or
nslookup -type=TXT yourdomain.com

URL プレフィックスプロパティは1つの正確なオリジンを確認する（プロトコル + ホスト + 末尾のスラッシュすべてが意味を持つ。https://example.com/ と https://www.example.com/ は別のプロパティだ）。DNS に触れずに、いくつかの方法で確認できる：

<!-- Option A: meta tag in the <head> of your homepage -->
<meta name="google-site-verification" content="AbC123dEf456GhI789jKl0..." />
# Option B: upload a verification file to the site root
# GSC gives you something like: google1234567890abcdef.html
# It must be reachable at:
https://example.com/google1234567890abcdef.html

確認する前に、ファイルが実際に配信されているかをチェックしよう：

curl -sI https://example.com/google1234567890abcdef.html | head -n 1
# Expect: HTTP/2 200

⚠️ pages.dev（および類似の *.vercel.app、*.netlify.app、*.workers.dev）の落とし穴：DNS を管理していないサブドメインに対しては、ドメインプロパティを作成できない。pages.dev ゾーンを所有しているのはあなたではなく Cloudflare なので、そのレベルで追加できる TXT レコードが存在しないのだ。プレビュー／ステージング用のサブドメインには、URL プレフィックスプロパティを使い、HTML メタタグまたはアップロードしたファイルで確認しよう。サイトを自分のカスタムドメインに移したら、ドメインプロパティに切り替える（または追加する）こと。

カスタムドメイン上の本番サイトの大半では、ドメインプロパティを使おう。*.pages.dev の URL やその他プラットフォームのサブドメインには、ファイル／メタ確認によるURL プレフィックスプロパティを使う。

サイトマップを送信する

ビルドがサイトマップインデックスを生成する場合（ほとんどのフレームワークはそうする。例えば Astro のサイトマップ統合は、1つ以上の sitemap-0.xml チャンクを指す sitemap-index.xml を出力する）、送信するのは個別のファイルではなくインデックスだ。Google はインデックスをたどってすべての子を読み取る。

まず、ファイルが実際に公開されていて整形式かどうかを確認しよう：

curl -s https://example.com/sitemap-index.xml | head -n 20
# Should return XML, not an HTML 404 page

# Check the status code and content type explicitly
curl -sI https://example.com/sitemap-index.xml | grep -iE 'HTTP/|content-type'
# Expect:
#   HTTP/2 200
#   content-type: application/xml   (or text/xml)

有効なサイトマップインデックスはこのような形だ：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-0.xml</loc>
    <lastmod>2026-06-23T00:00:00.000Z</lastmod>
  </sitemap>
</sitemapindex>

次に GSC で：

  1. Search Console → 対象プロパティ → インデックス作成 → サイトマップ（左サイドバー）を開く。

  2. 新しいサイトマップの追加欄に、プロパティのルートを基準とした相対パスを入力する。ほとんどのサイトでは単に sitemap-index.xml だ。GSC がドメイン部分を補完してくれるので、入力するのはパスだけでよい：

    sitemap-index.xml

  3. 送信をクリックする。

  4. ステータスが成功（または最初のうちは一時的な状態であることが多い。次のセクションを参照）となった行が表示される。その行をクリックすると、Google が発見した URL の数を確認できる。

💡 インデックスファイルは1回だけ送信すればよく、子ファイルを毎回送る必要はない。Google は独自のスケジュールで再読み込みするので、新しいページを公開しても再送信は不要だ。ビルドが XML を再生成するだけで、Google は次回の巡回で新しい <loc> エントリを拾ってくれる。

インデックス登録をリクエストする

サイトマップの送信は、URL を Google の発見キューに入れてくれる。特に大事にしている少数のページ（トップページ、主要なランディングページ、自信のあるコンテンツ）については、URL 検査ツールで Google に直接後押しをかけられる：

  1. GSC の最上部にある検索バー（「…内の任意の URL を検査」と表示されている）にフル URL を貼り付ける。
  2. GSC がインデックスから URL を取得し、すでにインデックスされているかどうかを表示する。
  3. 公開 URL をテストをクリックして、Google が現在のバージョンを取得できることを確認する（これによりレンダリングの問題、robots によるブロック、noindex タグも明らかになる）。
  4. 問題なさそうなら、インデックス登録をリクエストをクリックする。これで URL が優先クロールキューに追加される。
Inspect:  https://example.com/                 → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/pricing           → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/blog/launch-post  → "URL is not on Google" → Request Indexing

⚠️ インデックス登録のリクエストにはレート制限があり（1日あたりのわずかなクォータ）、重要な個別の URL 向けの機能だ。5,000 ページのサイトを無理やり流し込むためのものではない。大量処理にはサイトマップが正しいツールであり、クロールは規模に応じて自然に進ませればよい。手動リクエストは、今まさに最も重要な5〜20ページのためのものだ。

「取得できませんでした」はたいてい誤報

新規サイトオーナーが最も陥りがちなパニックの瞬間：sitemap-index.xml を送信して更新すると、ステータスが**Couldn't fetch（取得できませんでした）と表示される。XML を書き直し始める前に、これを知っておこう。送信直後のこのステータスは、しばしば一時的なものだ。Google は取得をキューに入れたものの、まだ実際には取得・処理しておらず、ダッシュボードはプレースホルダーを表示しているだけだ。多くのケースでは、あなたが何も変更しなくても数時間から2日程度でSuccess**（成功）に変わる。

だから最初のステップは本当に：1〜3日待って再確認することだ。

とはいえ、状態が続く場合は、このチェックリストをたどろう。これらが実際の原因であり、いずれもターミナルから検証できる：

  • 200 を返すか。 サイトマップの URL は、リダイレクトの連鎖や 403、404、5xx ではなく、200 OK で応答しなければならない。

    curl -sI https://example.com/sitemap-index.xml | head -n 1
# HTTP/2 200   = good   |   anything else (301/302/403/404/5xx) is a problem

  • 正しいコンテンツタイプか。 application/xml または text/xml を配信すること。サーバーが text/html を返す場合（SPA のフォールバックや 404 ページがファイルの代わりに返されるとよく起こる）、Google はそれを拒否することがある。

    curl -sI https://example.com/sitemap-index.xml | grep -i content-type
# content-type: application/xml   = good
# content-type: text/html         = bad (you're serving an HTML page, not the sitemap)

  • robots.txt がブロックしていないか。 うっかり書いた Disallow: /sitemap や、広すぎるルールが Googlebot のファイル読み取りを妨げることがある。robots を取得して中身を読もう：

    curl -s https://example.com/robots.txt
# Make sure nothing disallows the sitemap path for Googlebot

  • プロトコル／ホストの不一致がないか（クロスオリジンの落とし穴）。 サイトマップ内のすべての <loc> は、プロパティおよびサイトマップファイル自体と同じプロトコル・同じホストでなければならない。プロパティが https://example.com の URL プレフィックスなのに、<loc> エントリが http:// や www.example.com を指していると、Google はそれらをクロスサイトと見なして無視する。いくつか抜き取りチェックしよう：

    curl -s https://example.com/sitemap-0.xml | grep -oE '<loc>[^<]+' | head
# Every URL should start with https://example.com/ — no http://, no bare www mismatch

  • サイトマップパスに noindex や認証の壁がないか。 ステージングサイトはしばしば HTTP ベーシック認証や Cloudflare Access ポリシーの背後にある。サイトマップにログインが必要だと、Googlebot は 401／403 を受け取り、取得できない。

5つすべてをパスしても、1週間経ってステータスが解消しない場合は、URL 検査でサイトマップ URL に対して公開 URL をテストを使おう。Googlebot が見ている正確なレスポンスを表示してくれるので、たいていは不一致を即座に特定できる。

インデックスされるまでどれくらいかかるか

正直に期待値を設定しよう。焦りは、壊れていないものを「修正」させる原因になるからだ：

サイトの状況最初のページがインデックスされるまでの典型的な時間
真新しいドメイン、被リンクなし数日から数週間
確立済みで頻繁にクロールされるサイトの新規ページ数時間から数日
大規模サイト、内容の薄いまたは重複したコンテンツ遅い／部分的（Google がページをスキップすることもある）

発見（Google が URL の存在を知ること）は、サイトマップを送信すれば速い。時間がかかるのはインデックス登録（Google がページを取得し、レンダリングし、評価し、保存すると判断すること）の部分であり、これは単なるキュー処理ではなく品質と信頼の判断だ。リンクも履歴もない新しいドメインは優先度が低くなる。これは正常であってバグではない。公開を続け、いくつかリンクを獲得すれば、クロール頻度はおのずと上がっていく。

💡 ページレポートの「検出 - インデックス未登録」と「クロール済み - インデックス未登録」はエラーではない。Google が URL を見つけた（または取得した）が、まだインデックスしないことを選んだという意味だ。新規サイトでは、たいてい内容の薄さや優先度の低さを示すシグナルである。再送信するのではなく、ページを改善するかリンクを獲得しよう。

robots.txt からリンクする

GSC への送信はGoogleに伝える行為だ。robots.txt に Sitemap: 行を追加すると、エンジンごとのダッシュボードを使わずに、すべてのクローラー（Bing、DuckDuckGo、そして標準を尊重するその他すべて）に伝えられる。これは1行で済む念には念を入れた一手であり、サイトマップを告知する正規の方法だ。

# robots.txt
User-agent: *
Allow: /

# Absolute URL, one per line; you can list multiple sitemaps
Sitemap: https://example.com/sitemap-index.xml

つまずきやすいルールがいくつかある：

  • Sitemap: の URL は相対パスではなく、絶対 URL（完全な https://...）でなければならない。
  • これは User-agent ブロックとは独立している。ファイル内のどこに置いてもよく、慣例的には先頭か末尾に置く。
  • サイトマップをセクション別や言語別に分割している場合は、複数の Sitemap: 行を記載できる。

公開されているか確認しよう：

curl -s https://example.com/robots.txt | grep -i sitemap
# Sitemap: https://example.com/sitemap-index.xml

🧑‍💻 このサイトでどうやったか：まさにこの構成だ。自動生成した sitemap-index.xml、robots.txt の Sitemap: 行、GSC のドメインプロパティ、そして主要ページに対する数回のインデックス登録リクエスト。XML を手で編集せずにきれいな robots.txt とサイトマップエントリを生成したいなら、robots & sitemap ツール が代わりにやってくれる。そして Google がクロールを始めたら、ログ解析とクロールバジェット のガイドで、Googlebot がサイトマップで告知した URL を実際に取得しているか確認する方法を解説している。

まとめ

全体の流れを順番に：

  1. 所有権を確認する — DNS を管理しているならドメインプロパティ（DNS TXT）、pages.dev やその他プラットフォームのサブドメインなら URL プレフィックス（HTML タグ／ファイル）。
  2. sitemap-index.xml を送信する — インデックス作成 → サイトマップから。子ではなくインデックスを送信する。
  3. インデックス登録をリクエストする — URL 検査経由で、最も重要な5〜20の URL について。
  4. Couldn't fetch で慌てない — 1〜3日待ってから、200／コンテンツタイプ／robots／クロスオリジン／認証のチェックリストを実行する。
  5. 辛抱強く — 発見は速いが、新しいドメインのインデックス登録には数日から数週間かかる。
  6. robots.txt に Sitemap: 行を追加する — すべてのクローラーが見つけられるように。

次のステップ：robots & sitemap ツール で robots.txt とサイトマップ設定を生成し、クロールバジェットガイド でサーバーログ内の Googlebot の挙動を観察しよう。送信は Google との対話の始まりにすぎない。耳を傾けてくれているかどうかは、ログが教えてくれる。