サイトマップに入れるURL・外すURL｜公開記事の点検手順

当サイトの照合結果：83記事とサイトマップ90URL

2026年9月29日、記事台帳86件と公開サイトマップを照合しました。83件が公開済み、3件が公開予定でした。サイトマップの90URLは公開記事83件とトップ・案内ページ7件で、同じURLの重複、公開済み記事の欠落、公開予定記事の混入はいずれも0件でした。これは当サイトの取得結果であり、推奨の記事数ではありません。

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

当サイトはPHPで公開日を判定してサイトマップを生成しています。静的XMLの手編集例やWordPressプラグインの検証ではありません。WordPressでも、管理画面の投稿数ではなく、実際に配信されたサイトマップと公開URLを比較する考え方は使えます。

作業する順序は「記事台帳から公開済みだけ抽出 → XMLのlocを取得 → 同じURLの重複を除く → 差集合で欠落を調べる → 代表URLをGETで確認」です。lastmodは本文の更新に合わせます。送信受付を検索登録完了として記録しないでください。公開URLの確認結果（JSON・2026年9月29日）に今回の集計と代表例を残しました。

掲載候補を公開状態で分ける

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

大切なのは一覧の行数ではなく、掲載したURLが目的の本文へ届くことです。自動生成される仕組みなら、XMLを直接直す前に元データや公開判定を確認します。手で直しても次回生成で戻ることがあります。

10記事を追加したときの確認例

例として、公開前が40記事、新たに10記事を当日公開した場合を考えます。まず追加した10件をURLで照合し、全件が掲載されているか確認します。サイトマップにはトップや固定ページも含まれるため、URL総数が50でなければ失敗と決めつけないでください。

各URLを直接開き、200応答、主要本文、自己参照または意図したcanonical、noindexの有無を確認します。公開前のURLが混ざっていないか、同じURLが二重に載っていないかも調べます。記事一覧から新記事へ移動できるかも別に確認します。

更新日は実際の変更に合わせる

lastmodを使う場合は、ページの重要な変更を反映した日付にします。毎日すべての記事の日付を今日へ更新しても、内容が新しくなるわけではありません。生成した日時と記事を更新した日時を分けて管理します。

本文を直した日と新規公開日は区別して保存します。共通部品の軽微な変更だけで全記事の公開日を変更すると、読者にも編集履歴が分かりにくくなります。日付の基準を先に決めておくと運用が安定します。

公開日・更新日・資料確認日の付け方

原稿を書いた日、読者に公開した日、内容を改訂した日、参照先を調べた日は、それぞれ別の日付になりえます。下書きを一週間置いてから公開した記事に作成日を公開日として入れると、以前から読めた記事のように見えてしまいます。Google公式の公開日と更新日の情報も、記事で扱う出来事の日ではなくページの公開・更新を表す日付を使うよう案内しており、画面上の値と構造化データの整合も重視しています（2026年9月10日確認）。

スマホでは表を横にスクロールできます。

画面の公開日、構造化データのdatePublishedとdateModified、サイトマップのlastmodが、同じ事実から作られているかを確かめます。共通フッターの年号を変えただけで全記事を改訂済みにする必要はありません。新しく用意した記事に過去の日付を付けても、以前から運営していた記録にはなりません。移転した記事で元の公開日が分からない場合は推測で埋めず、旧サイトの記録や公開履歴を調べてください。

送信成功を登録完了と取り違えない

Search Consoleでサイトマップを送信し、読み取り状態と検出されたURLを確認します。送信の成功はサイトマップを受け付けた・処理できたという情報で、掲載URLがすべてインデックス登録されたという意味ではありません。

Googleの公式資料も、サイトマップはヒントでありクロールや登録を保証しないと説明しています。新記事のURL検査では、申請日時・登録状況・最終クロール日時を分けて書き留めます。新記事が見つからない場合はサイトマップだけでなく、本文の価値や内部リンクも見直します。

公式資料と確認日

以下の公式資料を2026年9月28日に確認しました。実測または実装確認と明記した節以外の記入例は、当サイトが作成した説明用の例です。管理画面の名称や利用できる設定は環境により異なります。

• Google：サイトマップの作成と送信