WordPressサイトマップの作り方｜XML・HTMLの違いと送信後の確認

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

WordPressのサイトマップを作ろうとして、「プラグインは必要なのか」「XMLとHTMLは何が違うのか」「送信したのに記事が検索に出ない」と迷うことはありませんか。最初に知っておきたいのは、サイトマップを新しく作る前に、すでに出力されているものを確認することです。生成元が分かれば、必要のない機能追加や重複設定を避けやすくなります。

この記事では、WordPressの既存出力を調べ、含めるURLを整理し、Google Search Consoleへ場所を知らせ、取得結果を確認するまでを説明します。検索結果への掲載や順位上昇を保証する方法ではありません。記事内のサイト例、管理表、相談文は独自の仮定例で、図版は説明用の生成イメージです。

WordPressサイトマップの役割をXMLとHTMLに分けて理解する

XMLサイトマップは、検索エンジンへページを知らせる資料

XMLサイトマップは、サイトにあるページなどのURLや関連情報を、検索エンジンが読み取れる形でまとめたものです。読者向けの見栄えを整えるページではなく、どのURLを知らせたいかを機械に伝えるための資料と考えると分かりやすくなります。

Googleのサイトマップの公式説明でも、サイト内のページやファイルの発見を助けるものとして整理されています。ただし、サイト内の通常のリンクも重要です。サイトマップさえあれば記事から記事へ移動できなくてもよい、という意味ではありません。

個人ブログなら、新しい記事や重要な固定ページが正しいURLで含まれているかを確認することが実用的な目的になります。難しいXMLの構文を一から手入力する前に、WordPressや既存機能が自動で作る出力を利用できないかを調べましょう。

HTMLサイトマップは、読者が探すための案内ページ

HTMLサイトマップは、サイト内の主要ページへのリンクを、人が読めるページとしてまとめるものです。「初めて読む方へ」「テーマ別の記事案内」などに近い役割を持たせることもできます。XMLのファイルを読者へ見せれば同じ目的を果たせる、とは限りません。

読者向けの案内では、すべてのURLを順番に並べるより、探す目的に沿って整理することが大切です。例えば副業ブログなら、始める準備、記事制作、運用の困りごとという区分が考えられます。実際のサイトの内容に合わせて、名前と順序を決めます。

XMLとHTMLは、どちらか一つを作ればもう片方の作業が不要になる関係ではありません。一方で、小さなサイトに専用のHTMLサイトマップが必ず必要というわけでもありません。メニューやカテゴリー、記事内リンクで十分探せるなら、その導線を維持する選択もあります。

「サイトマップインデックス」と「検索インデックス」は別の言葉

サイトマップを開くと、記事のURLではなく、複数のXMLファイルへのリンクが表示されることがあります。これはサイトマップインデックスという、サイトマップをまとめる一覧です。投稿用、固定ページ用、カテゴリー用など、種類ごとに分かれた子のサイトマップへ進めます。

ここでいうインデックスは、Googleの検索対象に登録されるという意味のインデックスと同じではありません。「サイトマップインデックスがあるから検索登録済み」とは判断できないので注意しましょう。言葉が似ていても、見ているものがファイル一覧か、検索への登録状態かを分けます。

例えば、一覧に投稿用XMLが三つあるなら、一つの投稿用ファイルだけを見て「記事が足りない」と決めないようにします。分割先も含めて目的のURLを探してください。ファイル数と記事数を取り違えないことが、出力確認の基本です。

※表は横にスクロールできます。

役立つ場面と、サイトマップだけでは解決しないこと

新しいサイトで外部からのリンクが少ない、ページ数が多く内部リンクだけでは発見しづらい、特定の画像や動画の情報を伝えたい、といった場合はサイトマップが役立つ可能性があります。まず自分のサイトで、何を知らせるために使うのかを言葉にしましょう。

一方、内容が重複している、ページが公開されていない、アクセスに認証が必要、検索対象外の指定がある、といった問題は、送信ボタンを押すだけでは解決しません。サイトマップに載せた後も、個々のページが検索エンジンに取得・理解できる状態かを確認する必要があります。

「作成」「Googleへ通知」「Googleによる取得」「ページの検索登録」「検索結果での表示」を一つの出来事にしないことが大切です。段階を分ければ、どこまでは確認できていて、次に何を調べるべきかを落ち着いて判断できます。

サイトマップを追加する前に、WordPressの現在の出力を確認する

WordPress本体の標準機能を調べる

WordPressには、5.5から基本的なXMLサイトマップ機能が入っています。WordPress公式の機能説明では、標準のサイトマップインデックスとしてwp-sitemap.xmlが案内されています。標準機能が有効な構成なら、追加プラグインなしで出力されている場合があります。

自分のサイトの正しいURLを確認し、その設置構成に対応するサイトマップの場所を調べます。例えば説明用のドメインなら、https://example.com/wp-sitemap.xmlのような形です。これは架空の例で、実際には自分のサイトのドメインと設置場所を使います。

この場所が開かなかった場合も、直ちにWordPressが壊れているとは考えないでください。SEOプラグインなどが標準機能に代わって出力している、サイトの公開設定で無効になっている、独自の構成になっている可能性があります。先に現在の設定と利用機能を確認します。

開いた画面が、目的のXMLかどうかを確かめる

サイトマップをブラウザーで開いたとき、見やすい表が表示される場合も、XMLの文字がそのまま表示される場合もあります。装飾された一覧でないから失敗、とは限りません。URLの一覧や、子サイトマップへの参照があるかを見ます。

反対に、普通のホームページ、ログイン画面、エラーページが出たなら、そのURLがXMLを返しているとは言えません。画面上にサイト名が出ているだけで成功と判断しないようにしましょう。転送がある場合は、開いた先のURLも記録します。

初心者の確認では、サイトマップのURL、表示された種類、投稿用の子ファイル、代表記事が含まれるかを一枚のメモにまとめるだけでも役立ちます。分からない文字列を無理に編集する必要はありません。現状を読み取る作業と、設定を変える作業を分けて進めます。

既存のSEO機能やテーマが担当していないかを見る

すでにSEO関連のプラグインを使っているなら、その設定内にXMLサイトマップの項目がないか確認します。機能が有効であれば、専用プラグインを追加する前に、現在の出力URLと対象の種類を調べてください。

プラグインごとにファイル名や分割方法は異なる場合があります。インターネットの記事に出てきた別製品のファイル名を、そのまま自分のサイトへ当てはめないようにします。利用中の製品の公式案内と、管理画面が示すURLを合わせて確認することが大切です。

複数のサイトマップが存在すること自体が、直ちに問題とは限りません。サイトの用途に応じて分割されていることもあります。問題は、どの機能が何を出力し、どれをGoogleへ知らせているかが分からない状態です。重複や古い出力があるなら、担当する仕組みを整理します。

※表は横にスクロールできます。

作成方法は、必要な機能と管理できる範囲で選ぶ

標準出力で必要なURLが正しく含まれ、運用できるなら、まずそのまま使う選択があります。既存SEO機能で細かな対象設定が必要なら、その機能を活用できるか検討します。独立した専用機能を加えるのは、今ある方法では足りない理由が明確な場合にします。

選ぶ際は、更新の担当者、設定の分かりやすさ、既存機能との関係、出力を止めたときの影響を確認します。評価数や導入数だけで決めず、自分のサイトで何を担当させるのかを一文にしましょう。「サイトマップのためだけに、別のSEO設定も一度に変える」ことは避けます。

新しく有効化する場合は、変更前の出力URLと設定を控え、変更後に代表URLの掲載、取得できる状態、Search Consoleへの登録先を確認します。導入しただけで終了にせず、以前の出力との関係まで整理できた状態を完成と考えます。

検証用・非公開サイトの設定を、公開のためだけに外さない

サイトが制作途中なら、検索エンジンへ知らせない設定や、認証による保護が意図的に使われていることがあります。サイトマップを出したいという理由だけで、それらを解除してはいけません。先に、そのサイトを一般公開してよい段階かを確認してください。

WordPress本体の標準サイトマップは、検索エンジンのインデックスを抑制する公開設定などの影響を受けます。出力されない原因を調べるときはその設定も確認しますが、チェックを外すこと自体を汎用的な解決策にはしません。本番とテスト環境を取り違えると、未完成のページを外へ知らせる原因になります。

管理担当が複数いるなら、「公開する対象サイト」「公開してよい内容」「変更する設定」を確認してから進めます。非公開資料、個人情報、顧客用のページは、サイトマップの都合で公開範囲を広げないようにしてください。取得できることと、公開してよいことは別の判断です。

サイトマップへ含めるURLを、公開状態と正規URLから整理する

検索結果へ出したい公開ページを基本にする

まず、読者に見つけてほしい公開ページを整理します。ブログ記事、必要な固定ページ、役割のある一覧ページなどです。下書きや管理画面、テスト用のURLを、公開記事と同じように含める必要はありません。

Googleのサイトマップ作成ガイドでは、検索結果へ表示したい正規URLを含め、完全なURLで記載することなどが示されています。同じ内容に複数の入口がある場合は、主要なURLをどれとするかを、サイトのほかの設定とも揃えて考えます。

URLのリストを見たら、代表的なページを実際に開いて内容と一致するか確かめます。似た末尾のURL、古いドメイン、転送前のURLなどが混ざっていないかを見る作業です。長い一覧を目視する場合も、まず種類ごとに数件を確認し、問題の傾向を見つけてから範囲を広げます。

カテゴリー・タグ・著者ページは、役割を見て判断する

投稿本文以外に、カテゴリー、タグ、著者の一覧ページがサイトマップへ含まれることがあります。これらを一律に全部消す、全部残すと決めるのではなく、実際に読者へ提供している内容とサイトの設計を確認しましょう。

例えば、テーマ別に記事を探せる充実したカテゴリーは、独立した入口として役立つかもしれません。一方、似た名前のタグが大量にあり、同じ記事がほぼ同じ組み合わせで並ぶだけなら、分類全体を見直す余地があります。サイトマップの設定だけで分類上の問題を解決しようとしないことが大切です。

著者ページも、複数執筆者のプロフィールを伝えるサイトと、個人が一人で書くブログでは役割が異なります。何のためのページかを確認したうえで、検索対象の設定とサイトマップへの掲載を整合させます。「この種類は必ず検索に弱い」といった断定で削除しないようにしましょう。

サイトマップから外しても、ページが非公開になるわけではない

重要な注意点として、サイトマップからURLを外しても、ページ自体へのアクセスが止まるわけではありません。サイト内外のリンクや既知のURLから、読者や検索エンジンが訪れる可能性があります。個人情報を隠すための仕組みとして使わないでください。

検索結果へ出したくないページの扱いは、noindexなどの検索向け指定や、認証によるアクセス保護と分けて考えます。Googleのnoindex公式説明にも、指定を認識させるために必要な取得条件が示されています。robots.txtで止めれば何でも非表示になる、という理解も正しくありません。

非公開にしたい理由が機密性なら、検索設定より先に、誰が閲覧できるべきかを管理者へ確認します。逆に公開して検索にも出したいページが、意図せず検索対象外になっているなら、その理由を調べます。サイトマップへ載るかどうかと、公開・検索の各設定を別々に確認することが必要です。

※表は横にスクロールできます。

更新日時や優先度の数字を、順位対策のために操作しない

生成されたサイトマップに更新日時などの情報がある場合は、実際の内容と合っているかを見ます。ページを更新していないのに毎日新しい日時に見せるなど、見かけ上の鮮度を作る目的で変更しないようにしましょう。

Googleの作成ガイドでは、priorityとchangefreqの値を利用しないこと、lastmodは正確な更新情報として確認できる場合に使うことが説明されています。数字を高くすれば上位になるという設定ではありません。利用する生成機能がどの情報を出すかを確認し、不要な手作業を増やさないようにします。

サイトマップが大きい場合には分割やインデックスが必要になることがありますが、小規模ブログの最初の課題は、上限ぎりぎりまで詰めることではありません。正しいURL、正しい対象、更新への追従を先に確認します。細かい仕様は利用中の生成機能とGoogleの現行案内で照合してください。

仮のサイトで、URLの扱いを判断してみる

ここで、記事20本、固定ページ4本、テストページ2本を持つ架空のブログを考えます。記事と固定ページがすべて同じ価値を持つと決めず、公開状態、内容、検索に出す意図を一つずつ確認します。テストページは、一般公開してよいものかを先に点検します。

たとえば、お問い合わせ完了後だけに表示するページ、古いキャンペーンの控え、公開前のデザイン案がある場合、それぞれ扱いが違います。「記事ではないから対象外」という分類だけでは判断できません。運営上の役割と、公開・検索設定の理由を並べることが役立ちます。

この棚卸しの結果は、投稿数とサイトマップ内のURL数が同じでなくても説明できる形になります。数を一致させることを目標にせず、必要なページが不足せず、不要なURLが混ざっていない状態を目指してください。件数の違いに理由があるかを確かめる作業です。

Search Consoleへサイトマップを送信し、取得結果を確認する

正しいプロパティと、操作できる権限を確認する

Search Consoleを開いたら、対象サイトのプロパティを選びます。複数サイトを管理している場合や、HTTPとHTTPS、wwwの有無などに関係するプロパティがある場合、別の対象へ送らないよう注意してください。いま表示しているサイト名だけでなく、対象範囲を確認します。

Googleのサイトマップレポートの公式ヘルプでは、送信に必要な権限と操作手順が説明されています。必要な権限がなければ、正当なオーナーへ依頼します。サイトの所有確認を知らない人の案内どおりに進めたり、不要な権限を広く配ったりしないようにしましょう。

共同運営なら、誰が送信と結果確認を担当するかも決めておきます。複数人が別のXMLをそれぞれ送ると、どの出力を正として管理するか分からなくなる場合があります。最初に共有する情報は、対象プロパティ、サイトマップURL、生成元、確認担当です。

送信前に、XMLのURLが読み取れる状態か確かめる

Search Consoleに渡す前に、自分のサイト上のサイトマップURLを開いて確認します。ログイン画面やエラーへ転送されず、期待するサイトマップが返るかを見てください。管理者としてログインしているから見えるだけ、という状態にも注意が必要です。

ただし、自分のブラウザーで開けることだけで、Googlebotにも必ず取得できるとは断定できません。アクセス制限、サーバー応答、認証などの条件が異なる可能性があります。公式ヘルプが案内する取得確認も活用し、問題がある場合は管理担当へ状況を伝えます。

取得のために非公開サイトの認証を外すことが目的ではありません。一般公開する本番のサイトマップで、正当なクローラーが読めるべき範囲を確認する作業です。テスト環境や会員専用のページを、送信の都合で公開しないようにしてください。

送信するのは、Googleへファイルをアップロードする操作ではない

Search Consoleのサイトマップ送信は、サイト上のどこにサイトマップがあるかを知らせる操作です。パソコンにあるXMLファイルをGoogleへ直接アップロードするという意味ではありません。まず自分のサイト上で取得できる場所が必要です。

サイトマップレポートを開き、新しいサイトマップを追加する欄へ、確認済みのURLを指定して送信します。画面がすでにドメインを補っている場合は、入力欄の表示に合わせ、最終的に意図したURLになるか確認します。同じドメインを二重に入れるなどのミスを防ぎましょう。

送信した日時と対象URLを記録したら、その場で連打する必要はありません。表示されるステータスを確認し、成功しなければ詳細を読みます。画面上の操作が完了したことと、サイトマップの取得・読み取りが終わったことを分けて扱います。

※表は横にスクロールできます。

「成功」と表示されても、全記事の検索登録とは限らない

サイトマップレポートの成功は、サイトマップの取得と読み取りの状態を表します。すべてのページが検索に登録され、希望するキーワードで表示されることを示すものではありません。サイトマップの状態と、個別ページの状態は別の確認です。

検出されたURL数がWordPressの投稿数と違う場合も、固定ページ、一覧ページ、分割先、対象外設定などの理由が考えられます。数字だけを見て「検索に全部出た」「半分消えた」と判断せず、まずその件数が何を数えているかを確認しましょう。

重要な記事が見つからないときは、その記事の公開状態、正規URL、検索向け指定、サイト内リンクなどを個別に調べます。サイトマップを再送することだけに集中せず、ページ自身の問題を切り分けることで、次の改善へ進みやすくなります。

取得できない・形式エラーのときは、詳細から直す

「取得できませんでした」と「読み取り時にエラーがある」は、同じ問題とは限りません。前者ならURLの間違い、認証、アクセス制限、サーバーの応答などを調べます。後者なら、XMLとして不正な出力や、含まれるURLの問題など、表示された詳細を確認します。

例えばXMLのURLを指定したつもりでも、普通のHTMLページが返っていれば、送信先が違う可能性があります。生成機能を変更した直後なら、旧URLを送っていないか、古いキャッシュが残っていないかも調べます。エラーメッセージを読まず、別のプラグインを次々追加する方法は避けましょう。

修正したら、同じURLを開いて内容を確かめ、必要に応じて再送信し、結果を記録します。一度の画面更新で直ったように見えても、取得時刻が変更前のままなら判断を保留します。何を直し、いつの取得結果を見たのかを一緒に残すことが重要です。

記事追加や設定変更の後も、サイトマップを管理できる状態にする

毎回の投稿で、同じサイトマップを手動送信し続けない

自動生成の仕組みが正常に働いていれば、新しい公開記事がサイトマップへ反映される運用を作れます。記事を増やすたびにファイルを手作りし直すのではなく、代表的な新規URLで更新への追従を確認しましょう。

Googleの公式ヘルプでは、正常に取得されたサイトマップは再クロールされることや、大きな変更などで再送信を検討することが説明されています。通常の更新のたびに、何度も同じURLを送信することを日課にする必要はありません。結果が遅いからと回数を増やしても、原因の診断にはなりません。

日常点検は、記事が公開されたか、対象の子サイトマップに含まれるか、取得エラーがないかに絞ると続けやすくなります。毎日全URLを目視するのではなく、サイトの規模や更新頻度に合わせて、何をいつ見るかを決めます。運用の負担と確認の必要性を釣り合わせましょう。

URL変更や生成元の切り替えでは、前後の対応を残す

ドメイン移転、パーマリンク変更、SEOプラグイン変更などを行った場合は、サイトマップのURLや含まれるURLにも変化が出る可能性があります。変更前の出力と送信先を控え、変更後の状態と照合してください。

新しいサイトマップが取得できても、古いドメインの記事URLが混ざっていると、期待した案内になっていません。逆に、出力URLだけが変わり記事URLは同じという場合もあります。どちらを変えたのかを区別し、関連する設定を一度に推測で直さないようにします。

サーバー移行が関係する方は、WordPress引っ越しの準備と確認ガイドで、新旧環境を点検する順序も確認できます。サイトマップの整理は移行後の確認の一部であり、データ移行や転送の準備を代わりに行うものではありません。

読者向けHTMLサイトマップは、探す順番を設計する

HTMLサイトマップを作る場合は、固定ページなどに主要な分類とリンクをまとめます。最初に、読者がどんな目的で探しに来るかを考えます。「記事一覧を全部見たい」のか、「初めて何を読めばよいか知りたい」のかで、載せる情報は変わります。

作成手順の例は、主要テーマを三つから五つ程度に仮分類し、各分類へ代表記事を選び、短い説明を付け、必要なページへ移動できるかを確認する流れです。この分類数は本記事の整理例で、必須の基準ではありません。記事が少なければ、もっと単純な案内で構いません。

作ったページへの入口も必要です。フッターや適切な案内箇所から見つけられるかを確認してください。固定ページとメニューの関係は、WordPress固定ページの作り方で詳しく整理しています。ページを作っただけで、読者が自然にたどり着けるとは限りません。

※表は横にスクロールできます。

三つの架空ケースで、次にすることを選ぶ

ケースAは、サイトマップが取得でき、記事も含まれるのに検索で見つからないブログです。この場合、同じサイトマップの送信回数を増やすより、対象記事の公開・検索設定や、個別の状態を確認します。取得が成功している段階と、記事自身の検索登録を分けることがポイントです。

ケースBは、SEO機能を変えた後に取得エラーが出たブログです。旧URLを送っていないか、新機能の出力先が何か、標準機能との関係がどうなったかを調べます。新しい機能をさらに追加する前に、生成元を一つずつ説明できる状態へ戻します。

ケースCは、公開前のテストサイトでサイトマップが出ない場面です。まず公開してよいかを確認し、非公開設定が意図的なら維持します。取得を成功させることより、公開範囲を守ることが優先です。同じ「出ない」でも、直すべき不具合と、正しく保護されている状態は区別します。

作成完了は、担当・URL・確認結果を残して判断する

最後に、生成元、サイトマップURL、対象のページ種類、Search Consoleのプロパティ、送信日、最新の取得結果、確認担当をまとめます。担当者が変わっても「どれが今使われているサイトマップか」を説明できる状態にしてください。

記事運用全体をこれから整える方は、会社員向けの副業ブログの始め方も参考になります。サイトマップの設定は、記事の内容、分類、内部リンク、公開後の確認と組み合わせて管理するものです。設定だけで読者の役に立つブログが完成するわけではありません。

まずは、現在の出力を一つ確認し、代表ページが含まれるかを見て、必要なら正しい場所を通知します。その後の結果を取得と検索登録に分けて読めれば、サイトマップに振り回されず、次に必要な作業を選びやすくなります。