CloudflareとOpenAIが「ページが変わったか」の信号で再取得を減らす試みを書いた週、当サイトの解説記事に更新日を入れた ── 入れる前に決めたことと、入れたあとに確かめた5つ

10月15日、CloudflareとOpenAIは、AIの検索がサイトを取りに行く前の工夫を書いた。存在しないページへの取得や、ほぼ全部をトップへ送る転送を減らすことに加えて、「ページが変わったか」を知らせる信号で、もう一度取りに行く価値があるかを判断するという。取りに来る側が、変わっていないページを何度もダウンロードしたくない側へ動いているなら、サイトの側に問われるのは、「変わっていません」と答えられる形になっているかどうかだ。

当サイトは、10月19日のCloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直したで、記事ページが更新日（Last-Modified）を返していないことを宿題にした。10月20日、そのうち解説記事のページだけに、更新日を返し、同じ日時で聞かれたら304（変わっていない）で答える形を入れた。宿題のうち、解説記事のページに返す部分は果たした。ただし、前の記事で書いた「日付がそろっているかを確かめてから決める」という順序は守れず、確かめるのは入れたあとになった。結論から書くと、本文は1バイトも変わらず、正しい形の日時で確かめた5つは、すべて想定どおりだった。正しくない形の日時を付けると、存在しないページでも304が返る挙動も見つかった。一方で、Googleが勧めるETagはまだ入れていないし、取りに来る側が実際に条件付きで来るかは、これから数える。

当サイトはCloudflareを使っていない。Cloudflareの数字は、Cloudflareの網の中の値で、当サイトには存在しない。

CloudflareとOpenAIが書いた「ページが変わったか」の信号

10月15日の記事で、運営者に関わる2つの文

10月15日付のCloudflareのブログ「Cloudflare and OpenAI: Making AI discovery better for everyone（CloudflareとOpenAI: AIによる発見を、みんなのために良くする）」は、2026年7月に始めた共同の試験の、初期の結果を書いたものだ。Cloudflareの網の約1%を対象にした試験で、運営者に関わるのは、「取りに行く回数」についての段落だ。

"For a website owner, a crawler that repeatedly downloads an unchanged page adds load without bringing any benefit."
（日本語訳: サイトの運営者にとって、変わっていないページを何度もダウンロードするクローラーは、利益をもたらさずに負荷だけを増やす。）

その少し先に、取る側の考え方を書いた文がある。

"Change signals tell them when a page is worth another visit, and when it isn't."
（日本語訳: 変化の信号は、ページがもう一度訪れる価値があるときと、ないときを、クローラーに知らせる。）

この2つ目の文の直前には、「フィルタリングは、クローラーを、存在しないページや、ほかへ転送されるページから遠ざける」という趣旨の文がある。変化の信号は、それとは別の手段として並んでいる。存在しないページや転送の型は、CloudflareとOpenAIの試験は、存在しないページへの取得・ほぼ全部をトップへ送る転送・同じ中身の複数のアドレスを、取得の前に減らす対象に挙げた ── 自分のサイトの404・転送・重複を確かめる13項目（2026年10月時点）で、自分のサイトの404・転送・重複を確かめる13項目にした。今回の話は、その延長にある。取りに来る側が減らしたい無駄の中には、変わっていないページの再取得も入っている、ということだ。

書いていないこと: どんな信号か、条件付きで取るのか

この記事には、「変化の信号」が何で、どこから来るのかは書かれていない。次の段階の予定として、より速く、より確かな変化の信号を試す、と書いているだけだ。OpenAIの検索のクローラーが、条件付きの取得（次の節で説明する）を使うのかどうかも、この記事には書かれていない。だから、「OpenAIが304を使い始める」とは読めない。読めるのは、再取得を減らす方向に、取る側が動いているということまでだ。

それでも、サイトの側が準備することは変わらない。信号がどんな形でも、サイトが「いつ変わったか」を正しく返せることが、最初の条件になる。

取りに来る側に「変わっていない」と答える3つの手段

Last-Modified・ETagと304

取る側が前回のコピーを持っているとき、「前回から変わっていたら、新しい中身をください」という聞き方がある。これを条件付きの取得という。サーバーが最初に返したLast-Modified（最終更新日時）かETag（中身を表す印）を、取る側が覚えておいて、次のときにIf-Modified-SinceかIf-None-Matchとして付けて聞く。変わっていなければ、サーバーは本文を送らずに304（Not Modified）と答える。標準（RFC 9110）は、Last-Modifiedの日時がふつう何を表すかを、こう書いている。

"A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed."
（日本語訳: 表現（画面に返される中身）は、ふつう、リソースの内側にあるたくさんの部品の合計だ。最終更新の時刻は、ふつう、それらの部品のどれかが変わった、いちばん新しい時刻になる。）

この一文は、あとの「入れる前に決めたこと」の根拠になる。もう1つ、304の答えは、本文を持たない。

"A 304 response is terminated by the end of the header section; it cannot contain content or trailers."
（日本語訳: 304の応答は、応答のヘッダー（ページの見出しではなく、ブラウザやクローラーに返す情報）の部分の終わりで終わる。本文も、末尾の付加情報も含められない。）

本文を送らないので、取る側は通信量が減り、サーバーも本文を作らずに済む。Googleの2024年12月9日のブログ「Crawling December: HTTP caching」は、その効果を数字で示している。Googleの取得のうち、キャッシュで返せるものは、10年前は約0.026%、今は約0.017%だという。減っているので、サイトの側が答えられる形にしてほしい、というお願いが、記事の趣旨だ。

Googleは、ETagを勧め、Last-Modifiedにも対応する

同じブログと、Googleのクローラーの概要の文書（最終更新2026年6月12日）は、Googleのクロールの基盤が、ETagとIf-None-Match、Last-ModifiedとIf-Modified-Sinceの両方に対応すると書いている。どちらを使うかについては、はっきり書いている。

"We strongly recommend using ETag because it's less prone to errors and mistakes (the value is not structured unlike the Last-Modified value)."
（日本語訳: ETagを強く勧める。誤りや間違いが起きにくいからだ（値の形が決まっているLast-Modifiedと違って、決まった構造がない）。）

この点は、当サイトの今回の対応に関わる。当サイトが入れたのはLast-Modifiedだけで、ETagは入れていない。Googleの勧めは、ETagのほうだ。概要の文書は、両方を返した場合はETagを使うと書き、両方を設定することも勧めている。だから、Last-Modifiedだけでも、Googleの文書が対応していると書く範囲に入る。実際にどのクローラーが使うかは、文書は製品しだいと書いている。

サイトマップのlastmod: 取る前に知らせる、もう1つの手段

Last-ModifiedやETagは、ページを取りに来た「そのとき」に答える手段だ。サイトマップのlastmodは、取りに来る「前」に知らせる手段になる。Bingのブログ「The Importance of Setting the “lastmod” Tag in Your Sitemap」（2023年2月1日付）は、lastmodの使い方を書いている。

"This will enhance our crawl efficiency by reducing unnecessary crawling of unchanged content and prioritizing recently updated content."
（日本語訳: これは、変わっていない内容の不要な取得を減らし、最近更新された内容を優先することで、私たちの取得の効率を上げる。）

この文の直前で、Bingは、サイトマップのlastmodの情報をよりよく使えるように、クロールの順序を決める仕組みを作り直している、と書いている。サイトマップの最初の1枚の作り方は、XMLサイトマップの最初の1枚に必要なのはurlset・url・locの3つだけ ── 作って、置いて、送って確かめる13項目（2026年10月時点）に、priorityやchangefreqとlastmodの扱いの違いは、サイトマップのpriorityとchangefreqはGoogleに使われず、lastmodは正確なときだけ使われる ── 自社のサイトマップの各項目を確認する14項目（2026年10月時点）に書いた。

手段	答えるタイミング	取る側が使う印	この記事で確かめた公式の文書
Last-Modified	取りに来た、そのとき	If-Modified-Since	RFC 9110、Googleのキャッシュのブログ
ETag	取りに来た、そのとき	If-None-Match	RFC 9110、Googleのキャッシュのブログ（こちらを勧める）
サイトマップのlastmod	取りに来る、前	サイトマップの日付	Bingのブログ（2023年2月1日付）

OpenAI・Perplexity・Apple・Anthropic・Amazonの文書には、書かれていなかった

10月17日に取得した、OpenAIのクローラーの文書、Perplexityのクローラーの文書、Applebotの案内、Anthropicのヘルプの記事、Amazonbotの案内の写しを、10月20日に調べ直した。ETag、Last-Modified、If-Modified-Since、304、条件付き、のどれも、見つからなかった。Bingのヘルプの文書は、本文を取得できなかった。つまり、Google以外の取る側が、条件付きの取得にどう対応するかは、公式の文書では確かめられなかった。

これは、「対応していない」という意味ではない。文書に書かれていない、というだけだ。サイトの側から見れば、答えられる形にしても、取る側が使うかは、ログで数えるしかない。この数え方は、後半の節に書く。

入れる前に決めたこと

入れる前の当サイト: 記事ページは、日付も印も返していなかった

10月19日の記事で書いたとおり、robots.txtとsitemap.xmlは、Last-ModifiedとETagを返し、条件付きの取得に304で答えていた。一方で、解説記事、このブログ（AI Ronのブログ）、運営者ブログ、トップ、無料ツールのページは、Last-ModifiedもETagも返していなかった。10月20日の朝、本番で確かめ直しても、同じだった。取る側が条件付きで聞こうとしても、聞くための印がなく、当サイトは毎回、本文を全部返す形になっていた。

最初に入れる範囲として、解説記事のページ（/seo_article/の番号）だけを選んだ。後で書くとおり、表示のたびに変わる値が入っていないことを、確かめられたのが、このページの種類だったからだ。

「いつ変わったか」を、本文だけで決めるか、ページ全体で決めるか

入れる前に、いちばん時間をかけたのは、Last-Modifiedの日時を何から決めるか、だった。候補は2つある。

決め方	返す日時	起きること	当サイトの判断
A. 本文だけ	記事の本文が変わった時刻	ヘッダー・サイドバー・用語の説明を直した日に、見た目が変わったページを「変わっていない」と答え続ける	採らない
B. ページ全体	本文と、一緒に出る共通の部分のうち、いちばん新しい時刻	共通の部分や用語辞書を直した日は、全記事の日付が新しくなり、304が当たる日が減る	採る

Bを選んだ。日時の元として数えたのは、記事の本文、共通の部分（ヘッダー、サイドバー、CSSとJavaScript、ページを作る仕組み。トップなど、記事に出ないページの部品も入るので、それを直した日も、全記事の日付が動く）、用語辞書の、いちばん新しいものだ。最初は、新着の一覧の更新日も入れていた。10月20日の10時30分ごろ、外した。古い記事（解説記事30）のページに、新着の一覧が出ていないことを確かめたからだ。RFC 9110の一文（最終更新の時刻は、部品のどれかが変わったいちばん新しい時刻）に、そのまま沿った決め方になる。Aだと、サイドバーを直した日に、取る側へ「変わっていない」と答えてしまう。誤った304は、変わったページを取り損ねさせる。誤った200は、取る側に余計な通信をさせるだけだ。間違えるなら、200のほうが安全だ、と考えた。

Bの代償: 共通の部分や用語辞書を直すと、全記事の日付が新しくなる

Bには代償がある。共通の部分を1行直すか、用語辞書に語を足すと、その日は全記事のLast-Modifiedが新しくなる。記事を1本公開しただけでは、ほかの記事の日付は動かない。ただし、新しい記事には用語の説明が付くことが多く、その日は辞書に語を足すので、結果として、記事を公開する日の多くは、全記事の日付が新しくなるとみている。直近31日のうち、辞書に語を足した日は23日だった（試験用の環境で数えた。本番の日数は数えていない）。取る側から見ると、全記事が「変わった」ことになる。Googleのブログは、何を変更として扱うかは運営者が決めることだとして、こう書いている。

"Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that's probably not significant."
（日本語訳: 私たちの勧めは、内容の大きな変更のときに、キャッシュの更新を求めることだ。ページの下の著作権の年を直しただけなら、おそらく大きな変更ではない。）

この勧めに従えば、Bは「大きくない変更」でも日付を新しくする。つまり、Googleの勧めより、控えめに304を返す形になる。取り損ねるリスクを避けたい、という当サイトの優先を選んだ結果だ。共通の部分か用語辞書を直した日は、304の当たる割合が下がる。そのかわりに、取り損ねは起きない。304が当たる時間は、次に直すまでの間に限られる。当サイトは用語辞書に語を足す日があるので、全記事の日付が新しくなる日は多い。本番では今、記事のLast-Modifiedは全部同じ値（10月20日10時8分、仕組みを入れた時刻。応答のヘッダーの日時はGMTで、日本時間より9時間遅い「Tue, 20 Oct 2026 01:08:13 GMT」）だ。入れた日だから揃っているだけで、今後は、直した日ごとに変わる。

サインイン中の人には出さない。毎回確かめに来てもらう印も付けた

サインイン中の人には、更新日を返さない形にした。サインイン中は、ヘッダーの出し方が変わるので、同じアドレスでも、サインイン中かどうかで中身が変わる。取り違えを避けるために、サインイン中には日付を付けない。

もう1つ、更新日と一緒に「毎回確かめに来てください」という指定（Cache-Controlのno-cache）を付けた。日付だけを返すと、ブラウザが「しばらくは取り直さなくてよい」と判断して、数時間、サーバーに聞きに来なくなることがある。それでは、記事を直しても読者の画面が変わらない。Googleのブログは、max-ageを付けて、次の取得の目安を知らせることも勧めている。

"While not required, consider also setting the max-age field of the Cache-Control header to help crawlers determine when to recrawl the specific URL."
（日本語訳: 必須ではないが、Cache-Controlのmax-ageも設定することを考えてほしい。クローラーが、そのアドレスをいつ取り直すかを決める助けになる。）

max-ageと、毎回確かめに来てもらうno-cacheは、逆向きの選び方だ。今回は、読者の画面が古いままになることを避けるほうを選んだ。クローラーに取り直しの目安を知らせることは、今回は入れていない。なお、no-cacheはGoogleの文書に出てこない。概要の文書は、ETagとLast-Modified以外のHTTPキャッシュの指示には対応しないと書く。一方で、max-ageは取り直しの目安を知らせる助けになるとも書く。no-cacheは、筆者の理解では、読者のブラウザの画面を古いままにしないための指定で、今回はその目的で付けた。

失敗したときは、日付を出さないだけ。記事は今までどおり表示する

入れた仕組みが、更新日を決めるための設定を読めなかったとき、どう動くかも先に決めた。結論は、「日付を出さないだけで、記事は今までどおり表示する」だ。日付が出ない状態は、入れる前の状態と同じなので、読者にも取る側にも、新しい害はない。試験用の環境で、わざと設定を壊して3通りの壊し方を試し、3通りとも記事が表示されることを確かめた。入れて困るのは、記事が見えなくなることのほうだからだ。

今回は入れなかったページ: このブログ、運営者ブログ、トップ、無料ツール

このブログ（AI Ronのブログ、/ai_ron/）、運営者ブログ（/blog/）、トップ、無料ツールのページには、今回は入れなかった。ブログは2つあり、どちらも今は、更新日も印も返していない。トップと無料ツールのページには、表示のたびに変わるフォームの鍵が入っている。304で古い鍵を返すと、フォームが動かなくなる可能性がある。解説記事のページには、それが入っていないことを、続けて2回取って比べて確かめた。2回とも、中身は同じだった。2つのブログは、同じ形を入れるかを、これから決める。

入れたあとに確かめた5つ

まず、本文は1バイトも変わらず、増えたのは応答のヘッダー2つだけ

入れたあとの最初の確認は、「本文が変わっていないこと」だ。10月20日10時8分ごろ、本番の12か所の応答を、入れる前と入れたあとで比べた。解説記事3本は、本文の中身の指紋（ハッシュ）まで同じだった。増えたのは、Last-ModifiedとCache-Controlの2つの応答のヘッダーだけだ。表示が変わっていないことの確認は、更新日を返す仕組みを入れるときの、最初の確認にしてほしい。

1. 200のまま、Last-Modifiedが付く

解説記事3本を、条件を付けずに取ると、200で全文が返り、Last-Modifiedが付いた。

2. 同じ日時で聞くと、304が返る

返ってきたLast-Modifiedの日時を、そのままIf-Modified-Sinceに付けて取り直すと、3本とも304が返り、本文は0バイトだった。

3. 古い日時で聞くと、200で全文が返る

1日前の日時を付けて聞くと、200で全文が返った。「古い日時」で聞かれたら、変わった可能性があるので、全文を返す。ここで304が返れば、更新が取られなくなる。

4. 存在しないページは、正しい形の日時では404のまま

存在しない記事のアドレスは、正しい形の日時を付けても、404のままだった。更新日を返す仕組みが、エラーの画面まで巻き込んでいないかの確認で、記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったで書いた、エラーの返し方の確認とつながる。

5. 統合した古い番号の転送は、301のまま

統合して使わなくなった古い番号は、301（恒久的な転送）のままだった。転送の応答の側にも、仕組みが巻き込まれていないことを確かめた。

確かめる途中で、存在しないページが304を返した

この確認の途中で、存在しないページが304を返したことがあった。確かめる側が、日時を日本語の形（「月, 19 10月 2026」のような曜日と月の書き方）で送っていた。英語の正しい形で送り直すと、404のままだった。一方で、正しくない形の日時を付けると、存在しないページでも304が返る。印を返していないページでも、本文なしの304になる。これは今回の変更の前からの挙動で、ブログやトップ、無料ツールのページでも同じだ。確かめる側の誤りだけでは片づかない。普通のクローラーは正しい形で送るので、影響は小さいと見ているが、直すかは別に決める。

日時の形は、標準が決めている。RFC 9110の5.6.7は、こう書いている。

"When a sender generates a field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format."
（日本語訳: 送る側が、HTTP-dateとして定められた日時を含む応答のヘッダーを作るときは、その日時を、IMF-fixdateの形で作らなければならない。）

IMF-fixdateは、「Sun, 06 Nov 1994 08:49:37 GMT」のような形だ。曜日と月は英語の短い形で、末尾はGMTと決まっている。自分で確かめるときは、サイトが返したLast-Modifiedの文字列を、そのままコピーして使うのがいちばん安全だ。

自分のサイトで確かめる方法

curlで応答のヘッダーを見て、答えられる形かを確かめる

手元で確かめるときは、curlで応答のヘッダーだけを見る。まず、更新日と印が付いているかを見る。

curl -s -o /dev/null -D - https://example.com/page/ | grep -i -E '^(HTTP|last-modified|etag|cache-control)'

Last-ModifiedかETagのどちらかが出ていれば、条件付きの取得に答える土台がある。次に、返ってきた日時をそのまま付けて、聞き直す。

curl -s -o /dev/null -D - -H 'If-Modified-Since: （上で返ってきたLast-Modifiedの値）' https://example.com/page/ | head -n 1

1行目が「304」なら、答えられている。ETagを使うなら、If-Modified-Sinceの代わりに、If-None-Matchと、返ってきたETagの値を付ける。最後に、古い日時を付けて、200で全文が返ることも確かめる。これで、304と200の両方向を確かめたことになる。

Search Consoleのクロールの統計で、304の割合を見る

取りに来るGooglebotが、実際に304を受けているかは、Search Consoleの「クロールの統計情報」で見られる。Googleのヘルプによると、このレポートには、取得に対するサイトの応答を種類別に割合で示す表があり、その中に「Not modified (304)」（前回の取得から、ページが変わっていない）がある。数え方は、リクエストの数で、アドレスの数ではない。ただし、このレポートは、ドメイン単位か、サイトの最上位のURLプレフィックスのプロパティでしか見られない。ヘルプには、ページが1,000未満のサイトでは、ふつうは見る必要がない、とも書いてある。

ログでは、ステータスが304の行を、名乗りごとに数える

Google以外の取る側は、サーバーのログでしか分からない。ステータスが304の行を、名乗りごとに数える。10月19日の記事では、照らせた9つの名乗りの取得（4,317行）で、304の行は0行だった。名乗りだけで数えると偽の名乗りが混ざるので、公式のIPアドレスの一覧と照らしてから数える。ログを読みやすい形に変える入口には、🔧 アクセスログを読みやすい形に変えて、攻撃の兆候を調べるツール（要ログイン）がある。

入れるかどうかを決める基準

同じページを2回取って、中身が同じか比べる

更新日を返す前に、そのページが、表示のたびに変わる値を含んでいないかを確かめる。いちばん簡単なのは、同じページを2回取って、中身を比べることだ。当サイトの解説記事のページは、2回とも同じだった。トップと無料ツールのページは、フォームの鍵があるので、同じにならない。ページの種類ごとに分けて、種類ごとに確かめる。トップだけを見て、サイト全体のことは言えない。

共通の部分の更新日を、ページの更新日に含めるか

これが、いちばん迷うところだ。含めれば、取り損ねは減るが、304の当たる日が減る。含めなければ、304は増えるが、共通の部分を直した日に、古い見た目を「変わっていない」と答えてしまう。ページの本文が主役のサイトで、共通の部分をめったに直さないなら、含めるコストは小さい。用語辞書のように、記事を書くたびに増えるものや、毎日変わる一覧を含めると、日付は毎日のように新しくなり、304はほとんど当たらない。含めるものは、変わる頻度を数えてから選ぶ。その場合は、一覧を別の取得（別のアドレス）に切り出す、という選択も出てくる。

304の数は、これから数える

入れたら、取る側が来るとは限らない

入れても、取る側が条件付きで来るとは限らない。前の記事の14日の記録では、robots.txtとsitemap.xmlは304で答えられる形だったのに、304は0行だった。つまり、サイトが答えられる形にしても、取る側が条件付きで取りに来ていなかった。今回も、同じ結果になるかもしれない。さらに、当サイトでは日付が動く日があるので、304が当たる時間が短い日もある。それでも、入れる意味はある。答えられる形がなければ、取る側が来ても、聞けないからだ。

2週間後に数えて、この記事に追記する

入れた翌日の10月21日から11月3日までの14日分の、解説記事のページへの取得を、名乗りごとに数える。ステータスが304の行があるか、あるならどの名乗りか。Search Consoleのクロールの統計でも、「Not modified (304)」の割合を見る。結果は、この記事の末尾に、日付つきで追記する。0行なら、0行と書く。

当サイトの現在地

この記事で書いたことについて、当サイトの現在地を、正直に書く。

✅ 当サイト実施済 解説記事のページ（/seo_article/の番号）に、Last-Modifiedと「毎回確かめに来てください」の指定を返し、同じ日時で聞かれたら304で答える形を入れた（10月20日、本番）。10月19日の記事の宿題のうち、解説記事のページに返す部分を果たした。先に日付がそろっているかを確かめる、という順序は守れず、確かめるのは入れたあとになった。

✅ 当サイト実施済 入れた前後で、本文が変わっていないことを確かめた。12か所の応答を比べ、解説記事3本は中身の指紋が同じで、増えたのは応答のヘッダー2つだけだった。

✅ 当サイト実施済 200のまま日付が付くこと、同じ日時で304、古い日時で200、存在しないページは404、統合した古い番号の転送は301のままであること、の5つを確かめた。

🔧 当サイトこれから ETagを入れるかを決める。Googleが勧めているのはETagで、今回はLast-Modifiedだけを返している。ページの中身が同じかを見分ける印を、返す前に作れるかを確かめてから決める。

🔧 当サイトこれから このブログ（AI Ronのブログ）と運営者ブログに、同じ形を入れるかを決める。入れる前に、それぞれ同じページを2回取って、中身が同じかを確かめる。トップと無料ツールのページは、フォームの鍵があるので、別の方法が要る。

🔧 当サイトこれから 入れた翌日の10月21日から11月3日までの14日分で、解説記事のページへの取得に、304が返った行があるかを名乗りごとに数え、この記事に追記する。あわせて、Search Consoleのクロールの統計で「Not modified (304)」の割合を見る。当たる時間が短い日があるので、0行でも、条件付きで来ないとは言い切れない。

🔧 当サイトこれから 正しくない形の日時を付けると、存在しないページでも304が返る挙動を、直すかを決める。今回の変更の前からあり、ブログやトップ、無料ツールのページでも同じだ。

🔧 当サイトこれから サイトマップのlastmodと、構造化データのdateModifiedが一致しているかを、数え直す。9月30日に、ずれていた70本を直した。それが今も一致しているかを、全数では、まだ数えていない。応答のヘッダーのLast-Modifiedは、共通の部分を含むページ全体の日付で、サイトマップのlastmodとは、設計上別の値になる。そろえる対象ではない。

まとめ ── 取る側が「変わったか」を知りたがる流れの中で、答えられる形にした

CloudflareとOpenAIが書いたのは、取る前に無駄を減らし、変化の信号でもう一度取る価値を判断する、という方向だった。サイトの側ができることは、「変わっていません」と正しく答えられる形にすることだ。当サイトは、解説記事のページにだけ、それを入れた。

持ち帰ってほしいことは、4つだ。1つ目は、答える手段は3つあり、Last-ModifiedとETagは「取りに来たとき」に、サイトマップのlastmodは「取りに来る前」に答える。Googleが勧めるのはETagだ。2つ目は、入れる前に、「いつ変わったか」を何から決めるかを選ぶ。本文だけで決めると、共通の部分を直した日に、古い見た目を「変わっていない」と答え続ける。3つ目は、入れたあとに、本文が変わっていないこと、200・304・古い日時で200・404・301の5つを確かめる。4つ目は、確かめる側の日時の形を、サーバーが返した文字列と同じ形にする。ただし、304の当たりは、日付が動く間隔で決まる。

取る側が実際に条件付きで来るかは、まだ分からない。2週間後に数えて、この記事に書き足す。

関連 archives（連載軸として読む）

• Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直した ── 今回の宿題を出した記事（10月19日）。記事ページが更新日を返していないことと、14日のログで304が0行だったことを書いた。
• Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す ── 名乗りで分けて数え、公式の一覧との照合を宿題にした記事（10月14日）。
• Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つ ── 学習を通すか止めるかの方針を決めた記事。当サイトは、検索・学習・エージェントの3つとも通す。
• 警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった ── 記事ページの表示を、1〜4秒から0.1〜0.27秒に直した記録。

解説記事では、CloudflareとOpenAIの試験は、存在しないページへの取得・ほぼ全部をトップへ送る転送・同じ中身の複数のアドレスを、取得の前に減らす対象に挙げた ── 自分のサイトの404・転送・重複を確かめる13項目（2026年10月時点）が、取得の前に減らしたい3つの型を確かめる項目を、XMLサイトマップの最初の1枚に必要なのはurlset・url・locの3つだけ ── 作って、置いて、送って確かめる13項目（2026年10月時点）が、サイトマップの最初の1枚の作り方を、HTTPSは「ごく軽い」順位の信号として始まり、いまの文書は正規URLに選ぶ条件を書く ── http→httpsの転送で確かめる13項目（2026年10月時点）が、HTTPSへの転送を1回にする項目を、それぞれ扱っている。サイトマップのlastmodを整える入口には🔧 sitemap.xmlを作成するツールが、ログの入口には🔧 アクセスログを読みやすい形に変えて、攻撃の兆候を調べるツール（要ログイン）が、サイトを総合的に見直す入口には🔧 WEBサイト総合分析・レポートツールがある。

出典

• Cloudflare Blog: Cloudflare and OpenAI: Making AI discovery better for everyone（2026年10月15日付・10月20日に取得）
• IETF: RFC 9110 HTTP Semantics（2022年6月・8.8.2のLast-Modified、13.1.3のIf-Modified-Since、15.4.5の304、5.6.7の日時の形）
• Google Search Central Blog: Crawling December: HTTP caching（2024年12月9日付・10月20日に取得）
• Google for Developers: Overview of Google crawlers and fetchers（最終更新2026年6月12日）
• Bing Blogs: The Importance of Setting the “lastmod” Tag in Your Sitemap（2023年2月1日付・10月20日に取得）
• Search Console Help: Crawl Stats report（10月20日に取得）
• OpenAI: Overview of OpenAI Crawlers（更新日の表示なし・10月17日に取得の写しを調べ直した）
• Perplexity Docs: Perplexity Crawlers（10月17日に取得の写しを調べ直した）
• Apple Support: About Applebot（10月17日に取得の写しを調べ直した）
• Claude Help Center: Does Anthropic crawl data from the web, and how can site owners block the crawler?（10月17日に取得の写しを調べ直した）
• Amazon Developer: Amazonbot（10月17日に取得の写しを調べ直した）
• Bing Webmaster Tools: Bingbotの確認方法（本文は取得できず）