XMLサイトマップの作り方とSEO｜料金ページがGoogleに見つけてもらえていなかった実例と直し方XMLサイトマップの作り方とSEO｜料金ページがGoogleに見つけてもらえていなかった実例と直し方

「サイトマップは最初に送ってある。なのに、あとから作った料金ページだけ検索に出てこない」

サイトを自分たちで更新している担当者から、よく聞く話です。そして、うちのサイトでも同じことが起きていました。2026年9月、料金ページと広告運用のサービスページが、Googleに存在すら知られていなかったのです。

原因はXMLサイトマップの漏れ。ブログ記事は自動で一覧に入るのに、固定ページは手で書き足す作りだったため、あとから増やしたページが入っていなかった。

XMLサイトマップの役目と作り方、何を入れて何を外すか、サーチコンソールで登録状況を確かめる方法までを、そのとき直した手順と今の状態をもとにまとめます。

XMLサイトマップとは、Googleに渡すURLの一覧

XMLサイトマップは、サイトにあるページのURLを、検索エンジンが読める形式で並べたファイルです。ふつうは https://ドメイン/sitemap.xml に置きます。

人が見るための、ページの一覧を並べたHTMLの「サイトマップ」とは別物。こちらは機械向けで、ブラウザで開くとURLと日付が並んでいるだけです。

Googleは、ページ同士のリンクをたどって新しいページを見つけます。サイトマップは、そのリンクとは別の入口。ここに書いておけば、どこからもリンクされていないページでも、Googleに「ある」と伝わります。

ただし、伝わるのは存在までです。Googleのドキュメントにも、サイトマップに入れたすべての項目がクロールされ、インデックスに登録されるとは限らない、と書かれています（Google 検索セントラル「サイトマップについて」、2026年10月5日確認）。

同じページには、なくてもいい条件も載っています。検索に出したいページが500前後以下で、トップページからリンクをたどって大事なページに全部たどり着けるなら、サイトマップは必須ではない。

では小さな会社のサイトは作らなくていいのか。私は置いておくほうを選びます。リンクを張り忘れる人間のミスまで、この条件は面倒を見てくれないからです。うちのサイトは、まさにそこで漏れた。

料金ページがGoogleに見つけてもらえていなかった

2026年9月21日の夜。Search ConsoleのURL検査に料金ページ（/pricing）のURLを入れると、返ってきたのは「URL is unknown to Google」でした。GoogleがこのURLを一度も見たことがない、という意味です。

広告運用のサービスページ（/services/ads）も、制作実績のページの1つも同じ結果。料金とサービスという、問い合わせにもっとも近いページばかりです。

原因はすぐわかりました。このサイトはNext.jsで作っていて、サイトマップは app/sitemap.ts というファイルから自動で出しています。ブログ記事はフォルダの中身を読んで自動で並ぶ。ところが、トップやサービスなどの固定ページは、URLを1行ずつ手で書く作りでした。

その手書きの一覧に入っていた固定ページは9件。別のドメイン（ads.stellarium.jp）から移してきた広告運用のページや、料金ページ、制作実績のページは、作ったときに一覧へ足し忘れていたんです。

その日のうちに直したのは次の2つ。

ブログと同じく、制作実績もファイルを置けば一覧に入るようにしました。手で足す行を減らさない限り、また同じ漏れが起きるからです。

2週間たって、今どうなっているか

10月5日に、Search ConsoleのURL検査（読み取りのみ）で同じページを確かめた結果です。

料金ページも制作実績のページも、URL検査の参照元に sitemap.xml が出ていました。サイトマップ経由で見つけてもらえたことが、画面の上でも確かめられます。

一方で、広告運用のサービスページは2週間たっても未登録のまま。Googleは存在を知っているのに、まだ取りに来ていません。

ここがサイトマップの限界です。見つけてもらうところまでは直せた。そこから先、クロールして登録するかはGoogleが決めます。小さなサイトの新しいページは、順番がなかなか回ってこない。このあたりの話はSEOの内部対策と外部対策でも、同じ自社の数字を使って書いています。

XMLサイトマップの作り方は3通り

使っている仕組みで作り方は決まります。

1. CMSやサービスが自動で作る（WordPress、Shopify、Studioなど）
2. 自分でXMLを書いて、サーバーに置く
3. コードで自動生成する（Next.jsなど）

まず自分のサイトで https://ドメイン/sitemap.xml をブラウザで開いてみてください。URLの並んだ画面が出たら、すでにどれかの方法で作られています。

WordPressのサイトマップ

WordPressは、5.5から本体に機能が入っていて、何もしなくても /wp-sitemap.xml が出ます（Make WordPress Core「New XML Sitemaps Functionality in WordPress 5.5」、2026年10月5日確認）。

Yoast SEOのようなSEOプラグインを入れると、本体のサイトマップは止まり、プラグインのものに切り替わります。このときURLが変わるので、Search Consoleに古いほうのURLを送ったままになっていないかは見ておきたいところ。どちらのURLが生きているか、ブラウザで両方開けばすぐわかります。

手で書くなら、最低限これだけ

ページが数ページしかなく、更新もほとんどないなら、手書きでも作れます。中身はこれだけです。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
  </url>
  <url>
    <loc>https://www.example.com/pricing</loc>
    <lastmod>2026-09-21</lastmod>
  </url>
</urlset>

決まりは多くありません（Google 検索セントラル「サイトマップの作成と送信」、2026年10月5日確認）。

• URLは https:// から始まる完全な形で書く。/pricing のような省略は不可
• 文字コードはUTF-8
• 1つのファイルに入れられるのは5万URLまで、圧縮前で50MBまで。超えるなら分けて、まとめ役のファイル（サイトマップインデックス）を送る

手書きの弱点は、ページを足すたびに書き換えが要ること。うちの漏れもこれでした。ページが月に何本も増えるなら、自動で作る方法に寄せたほうがいい。

Next.jsなら sitemap.ts で自動にする

Next.jsは、app/sitemap.ts にURLの配列を返す関数を書くと、/sitemap.xml を出してくれます（Next.js「sitemap.xml」、2026年10月5日確認）。

うちのファイルから、ブログ記事と制作実績の部分を抜き出すとこうなります。

// 制作実績（content/works の .mdx。draft は読み込みの時点で除外）
const caseUrls = getAllCases().map((c) => ({
  url: `${SITE}/works/${c.slug}`,
  lastModified: new Date(c.frontmatter.lastmod || c.frontmatter.date),
}))

// ブログ記事（content/blog の .mdx。lastmod＝リライト日を優先）
const blogUrls = getAllPosts().map((post) => ({
  url: `${SITE}/blog/${post.slug}`,
  lastModified: new Date(post.frontmatter.lastmod || post.frontmatter.date),
}))

記事のファイルを1つ置けば、サイトマップにも1行増える。下書きにしている記事は、記事を読み込む関数の時点で外しているので、一覧にも出ません。日付は、書き直した日（lastmod）があればそちらを優先。

ページ数が5万を超えるような大きなサイトは、generateSitemaps という関数でファイルを分けられます。会社のサイトでそこまでいくことはまずないので、1ファイルで足りる。Next.jsで作ること自体の向き不向きはNext.jsで作る強みにまとめました。

サイトマップに入れるURLと、外すURL

入れるのは「検索に出したいページの、正式なURL」だけ。逆に言えば、それ以外は全部外します。

同じ中身のページに複数のURLがある場合は、正式なほうを1つ選んで、そちらだけを載せるよう、Googleのドキュメントに書かれています。?utm_source= のような計測用の文字が付いたURLや、末尾のスラッシュ違いが混ざっていないかは、一度目で見ておきたい。

うちでは9月27日に、特定商取引法の表記とプライバシーポリシーを検索結果に出さない設定（noindex）にしました。同じ作業でサイトマップからも2件外した。「検索に出さないで」と言っているページを、別の口で「見つけてください」と渡すのは、言っていることが食い違うからです。

サイトのリニューアルでURLが変わったときは、古いURLを一覧から抜き、新しいURLだけを送ります。手順は古いホームページのリニューアルの、301リダイレクトの章に書きました。

lastmod・priority・changefreqは、どう書くか

自分のサイトのファイルを読み直していて、気づいたことがあります。

Next.jsの例にならって、固定ページ全部に priority（重要度）と changeFrequency（更新の頻度）を書いていました。Googleは、この2つを使っていません。2023年6月の告知で、changefreqは考え方がlastmodと重なり、priorityは書き手の主観が強くて実際の重要度を表していないから、と理由まで書かれています（Google 検索セントラル ブログ「サイトマップの ping エンドポイントのサポートが終了しました」、2026年10月5日確認）。

害はありませんが、意味もないので、この記事を書いた10月5日に全部消しました。時間をかけて数字を調整するところではない。

気になったのは lastmod（最終更新日）のほうでした。

固定ページの lastModified には now、つまりサイトマップを読みに来た時刻がそのまま入る書き方でした。実際、10月5日に取得したら、トップもサービスも料金も、全部その日のその時刻。中身は何も変わっていないのに、です。

Googleは、lastmodが実際の更新と一貫して合っていると確かめられたときだけ使う、としています。同じ告知には、7年前に変えたページを前日に変えたと伝えれば、更新日について信用されなくなる、とまで書いてある。毎回「今変わりました」と言い続ける今の書き方は、まさにそれです。

直し方は2つあります。

• 固定ページのlastmodは書かない（トップやカテゴリーのように、更新日を決めにくいページは外してよいと告知にある）
• ページを本当に書き換えた日を、ファイルの中に持たせて出す

このサイトでは、10月5日に1つ目のやり方で直しました。固定ページとカテゴリーページのlastmodは外し、正確な日付を持っている記事と制作実績だけに残しています。

記事と制作実績は、書き直した日を使う作りになっているので、こちらは今のままで問題ありません。lastmodに入れる「更新」は、本文や構造化データを変えた、リンクを差し替えた、という程度の変更のこと。フッターの年号を変えただけなら、日付は動かさない。構造化データそのものについては構造化データのSEO効果で書いています。

サーチコンソールでサイトマップを登録する手順

Googleにサイトマップの場所を知らせる方法は2つ。まずはSearch Consoleから送る手順です。

1. Search Consoleの［サイトマップ］を開く
2. 「新しいサイトマップの追加」の欄に、サイトマップのURLを入れる
3. ［送信］を押す
4. 一覧のステータスが「成功」になるのを待つ

もう1つは、robots.txt の最後に次の1行を書いておくこと。

Sitemap: https://www.example.com/sitemap.xml

うちはNext.jsの app/robots.ts から、この行を自動で出しています。Search Consoleを使っていない検索エンジンにも伝わるので、両方やっておきます。

昔のやり方で、決まったURLにアクセスして「サイトマップを更新した」と知らせる方法（ping）がありました。Googleはこれを2023年6月に終了すると告知し、今はアクセスしても404が返るだけ。古いプラグインや手順書に残っていても、もう意味はない。

一度送れば、Googleは定期的に読みに来ます。ページを足すたびに送り直す必要はない。Search Consoleのヘルプでも、再送信をすすめているのはサイトマップを大きく変えたときです（Search Console ヘルプ「サイトマップ レポート」、2026年10月5日確認）。

XMLサイトマップが読まれているか、確認する方法

送ったあとに見るのは3か所。

Search Consoleのサイトマップレポート

ステータスは「成功しました」「取得できませんでした」「サイトマップに◯件のエラーがあります」のどれか。成功以外なら、まずブラウザでサイトマップのURLを開いて、表示されるかを見ます。

次に見るのが「検出されたページ数」。サイトマップを読んで見つかったURLの数です。

ここが、自分の想定する公開ページの数と合っているか。合わなければ、どこかで漏れているか、余計なものが入っています。

10月5日の時点で、うちのサイトマップは113件。最後に読み込まれたのは同じ日の18時31分でした（Search Console APIで確認）。

余談をひとつ。同じ情報をSearch ConsoleのAPIで取ると、登録済みの件数の欄が0で返ってきます。この記事のために取ったときも0。料金ページは登録済みなのに、です。APIのドキュメントを読むと、この欄は使わないでと書かれた廃止扱いの項目でした（Search Console API「Sitemaps」、2026年10月5日確認）。登録の状況は、ページ単位で確かめるしかありません。

URL検査で、1ページずつ確かめる

大事なページは、URL検査に1つずつ入れます。見るところは2つ。

• 「参照元のサイトマップ」に自分のサイトマップが出ているか
• インデックス登録の状態（登録済みか、「検出 - インデックス未登録」のままか）

GoogleがこのURLを知らない、という結果が出たら、そのページはまだ見つけられていません。サイトマップに入っているかを最初に疑ってください。

サイトマップの中身を、自分の目で数える

もう1つ、地味ですが確実な方法。ブラウザで sitemap.xml を開き、ページ内検索で「pricing」や「works」のように、入っていてほしいURLの一部を探します。

• sitemap.xml がブラウザで開ける
• Search Consoleのステータスが「成功」
• 検出されたページ数が、公開しているページ数とだいたい合う
• 料金・サービス・問い合わせに近いページが一覧に入っている
• noindexのページや下書きが入っていない
• robots.txt に Sitemap の行がある

Bingには、サイトマップに加えてIndexNowを

Googleはサイトマップを定期的に読みに来ますが、Bingにはもう1つ、更新をその場で知らせる仕組みがあります。IndexNowです。

決めた鍵の文字列をファイルにしてサイトに置き、更新したURLを送る。1回に1万URLまで送れて、送った内容は参加している検索エンジンの間で共有されます（IndexNow「Documentation」、2026年10月5日確認）。参加しているのはBing、Naver、Seznam、Yandex、Yepで、Googleは入っていません。

IndexNowのFAQには、継続的に見つけてもらうにはXMLサイトマップを使う、とあります。サイトマップの代わりではなく、足すもの。

うちは記事を公開するたびに、IndexNowで1本送る運用にしています。BingはChatGPTの検索やCopilotが情報を引く先でもあるので、AIの回答に出るかを気にするなら外せません。その経緯と測り方はLLMOとはに書きました。

サイトマップに入れても登録されないページは、リンクで呼ぶ

広告運用のサービスページは、サイトマップに入れてから2週間、まだGoogleが取りに来ていません。

サイトマップで直せるのは見つけてもらうまで。そこから先は、Googleがそのページをどれくらい大事だと見るかで、順番が決まります。

小さなサイトでできるのは、そのページへの内部リンクを増やすこと。うちでは、トップやフッター、関係のある記事から広告運用のページへリンクを足しました。ECのサービスページは、サイトマップに入る1か月前の8月21日にはもうクロールされていて、URL検査の参照元に出てくるのはブログ記事2本でした。Googleは記事のリンクをたどって見つけていたことになる。リンクのほうが強く呼べる、という手応えはあります。

まとめて確かめるならこの順番で。

1. ブラウザで sitemap.xml を開き、出したいページが全部入っているかを探す
2. 漏れていたら、ページを足すと一覧も増える作りに直す（手書きの行を減らす）
3. noindexや下書きが混ざっていたら外す
4. lastmodが毎回「今日」になっていないか見る
5. Search Consoleで送信し、検出されたページ数を確かめる
6. 大事なページをURL検査にかけ、未登録が続くページには内部リンクを足す

1と6だけなら、今日の昼休みにでもできます。