WEBサイトCloudflareのOrigin Range Requestsは全プランで使えるが、配信元が範囲指定に答えられることが前提になる ── 大きなファイルの配り方を確かめる13項目（2026年10月時点）
CloudflareのOrigin Range Requestsは全プランで使えるが、配信元が範囲指定に答えられることが前提になる ── 大きなファイルの配り方を確かめる13項目（2026年10月時点）
目次
- 01 何が書いてあるか — Cloudflareは「範囲の大きさを決める設定」をやめ、配信元に求めることを1つ書いた
- 02 なぜ・背景 — 「途中だけ欲しい」は日常の通信で、答えるかどうかは配信元が決める
- 03 用語 — 要求と応答のヘッダーの言葉を先にそろえる
- 04 型別 — 大きなファイルを配るサイトだけが対象で、確かめる手順は6つある
- 05 明日、自社のサイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 設定を入れるより先に、配信元の答え方と、ファイルの置き方を決める
- 07 当サイトで確かめたこと — 画像と記事のページに、curlで数回だけ取った
- 08 このテーマは、ここまで
- 09 この記事のまとめ
01 何が書いてあるか — Cloudflareは「範囲の大きさを決める設定」をやめ、配信元に求めることを1つ書いた
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflareのブログ、HTTPの仕様書（RFC 9110）、MDNのページからの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月28日に開き、本文を取り直して、引用した文が原文にあることを確かめた。日本語で書いた説明は、原文の要旨であり、引用ではない。
Cloudflareのブログに、2026年10月23日の日付で「Origin Range Requests」の記事が出た。大きなファイルの一部だけを頼まれたとき、Cloudflareがどうさばくかを作り直した、という内容である。この記事は、Cloudflareを使っているサイトだけの話にしない。PDF・動画・配布ファイルを持つサイトなら、Cloudflareを通っていなくても、配信元が「途中だけ欲しい」という頼みに正しく答えているかを確かめられるからである。確かめ方はHTTPの決まりごとで、どの環境でも同じである。
10月23日の発表は、全プランで使える自己設定の機能だった
ブログの記事は、新しい仕組みを次のように紹介している。
"Today, we're making that new implementation available as Origin Range Requests, a self-service feature on all plans."
（訳: 今日、この新しい仕組みを、Origin Range Requestsという、すべてのプランで使える自己設定の機能として公開する。）
設定は、キャッシュルールで大きなファイルの通信に当たる条件を決め、Origin Range Requestsをオンにする。原文は、画面（Caching > Cache Rules）からでも、APIの origin_range_requests: { "mode": "on" } でもできると書いている。範囲の大きさの設定は無く、サポートへの連絡も要らない、とも書いている。原文のブログの「Getting started」の節がこの部分である。
以前の仕組みは、範囲の大きさをゾーンごとに決める設定だった
原文によると、以前のRange付き取得のキャッシュは、ゾーンごとの固定の設定で、範囲の大きさと対象の拡張子を決める形だった。範囲が小さいと配信元への小さな取得が多くなり、大きいと頼まれた以上のデータを取ってくる。範囲の大きさを変えると、その大きさがキャッシュの鍵の一部だったので、保存済みのものが無効になった、とも書いている。
具体例として、動画の途中へ飛ぶ操作が挙がっている。数メガバイトを頼まれただけで、以前の仕組みでは配信元から128MiBを取ってきて、データセンターの間で動かすことがあった、と原文は書く（この例は動画プレーヤーの話で、R2とは書かれていない）。別の箇所には、Cloudflare自身のオブジェクトストレージ（R2）の例がある。R2で設定していた範囲の大きさは64MiBで、範囲の境目をまたぐ小さな読み取りが、128MiBの転送になりえた、と原文は書いている。
新しい仕組みは、固定の大きさのかたまりで保存し、足りない部分だけ取りに行く
新しい仕組みでは、保存済みのファイルを、決まった大きさのかたまり（チャンク）で持つ。範囲を頼まれると、保存済みの部分はそのまま使い、足りない部分だけを、かたまりの境目に合わせて配信元へ頼む。原文の例では、150〜250バイト目を頼まれたとき、その部分を含むかたまりを取ってくるが、利用者へ返すのは150〜250だけである。
原文が数字で書いた効果は、R2での2つだけ
原文が数字で書いている効果は、R2を新しい仕組みへ移した後の2つである。1つは、R2の保存地域をまたいで、応答の最初の1バイトが届くまでの時間（p99）が、キャッシュに当たった場合も外れた場合も、おおよそ半分になったこと。もう1つは、保存済みの部分と配信元から取った部分を1つの応答にまとめる変更で、R2などの段をまたぐ通信が、前の週と比べて約6%減ったことである。どちらもCloudflare自身のサービスの数字で、利用者のサイトの数字ではない。
配信元に求めていることは、範囲の指定に対応していること
配信元に求める条件は、原文では1文である。
"The origin also needs to support byte ranges for partial origin fetches to be useful."
（訳: 配信元の側も、部分的な取得が役に立つためには、バイトの範囲に対応している必要がある。）
同じ節に、もう1つ大事な文がある。この機能を入れても、キャッシュできるかどうかの条件は変わらない、という内容である。
"Enabling it does not make an otherwise uncacheable response cacheable."
（訳: 有効にしても、もともとキャッシュできない応答がキャッシュできるようになるわけではない。）
つまり、配信元が範囲指定に答えられず、応答がキャッシュできない形なら、設定を入れても役に立ちにくい。この記事の05章の確認は、この2つの条件を、自分のサイトの大きなファイルで確かめるためのものである。
02 なぜ・背景 — 「途中だけ欲しい」は日常の通信で、答えるかどうかは配信元が決める
動画の頭出し、ダウンロードの再開、ファイルの末尾だけの確認で使われる
HTTPの範囲指定は、新しいものではない。仕様書は、通信が途中で切れたとき、手元にある部分の残りだけを頼めると便利だ、という理由を最初に書いている。Cloudflareの記事は、動画プレーヤーの頭出し、ダウンロード管理ソフトの再開、パッケージ管理ソフトの一部取得、ファイルの終わりだけを見る使い方を挙げている。ふつうの閲覧では、利用者が気づかないところで使われている。
仕様書は、範囲指定をあってもなくてもよい機能と書いている
RFC 9110（2022年6月）の14章は、範囲指定に答える機能を、選択式の機能と位置づけている。
"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."
（訳: 範囲指定は、HTTPの選択式の機能である。この機能を実装していない（または、その対象には対応していない）受け手は、ふつうのGETの要求であるかのように答えてよく、それで相互の接続に支障は出ないように作られている。）
14.2節には、もっと短い文もある。"A server MAY ignore the Range header field."（訳: サーバーは、Rangeのヘッダーを無視してもよい。）である。範囲指定に答えないこと自体は、仕様の違反ではない。だから、確認の結果が「200で全体が返った」だったときは、不具合と決めつけず、そのファイルに範囲指定が必要かを先に考える。
それでも「答えられるなら答えるのがよい」と、仕様は書いている
同じ14.2節は、配信元と途中のキャッシュは、できるときは範囲指定に対応するのがよい、と書いている。理由は、部分的に失敗した転送からの回復と、大きな表現の一部だけの取得が効率よくできるからである。Cloudflareが範囲指定の扱いを作り直したのも、この効率の話の延長にある。
細かい範囲を大量に頼む要求は、拒否してよいとも書かれている
仕様書は、重なり合う範囲が多い指定や、順番が乱れた小さな範囲を大量に並べた指定は、壊れたクライアントか、わざと負荷をかける攻撃の兆候なので、無視または拒否してよいと書いている。そのとき返すステータスの1つが416である。つまり、416は「範囲が外れている」だけでなく、「範囲の頼み方が不自然」のときにも使われる。確認のときに、自分のサイトに大量の細かい範囲を頼む必要はない。この記事の手順は、どれも数回の取得で終わる。
圧縮された応答では、範囲は圧縮後のバイト列で数える
MDNのRangeの説明は、内容が圧縮されて返る場合、範囲は圧縮後のバイト列を指し、展開したあとのバイト列ではない、と書いている。Cloudflareの原文も、展開して返す応答では範囲をまとめず、全体を返すと書いている。ZIPやMP4のように、もともと圧縮された形式のファイルは、Content-Encodingが付かないことが多い。05章の10番目は、この確認である。
03 用語 — 要求と応答のヘッダーの言葉を先にそろえる
Rangeと、バイトの範囲
Rangeは、利用者が送る要求のヘッダーである。単位として登録されているのは、いまはバイトだけである。MDNの説明にある例では、Range: bytes=0-499 は最初の500バイトである。数え方は0から始まり、終わりの位置も含む。終わりを省くと残り全部、bytes=-100 のようにマイナスから書くと、最後の100バイトを意味する。
206と、Content-Range
206 Partial Contentは、範囲の指定に答えたときのステータスである。応答には、返したバイトの位置と、ファイル全体の大きさを書くContent-Rangeがつく。たとえば Content-Range: bytes 0-99/88980 は、88,980バイトのファイルの先頭100バイトを返した、という意味になる。Content-Lengthは、この場合、返した部分の大きさ（100）になる。
用語
ETagは、ファイルの「版」を表す識別子である。同じ中身なら同じ値、中身が変わると別の値になるのが基本である。範囲を何回かに分けて取るとき、ETagが同じなら「同じ版の続き」とみなせる。Cloudflareの原文は、応答をまとめる前に、ETagが一貫していることを確かめていると書いている。
Accept-Rangesと、If-Range
Accept-Rangesは、サーバーが範囲指定に対応していると伝える応答のヘッダーである。Accept-Ranges: bytes がその例である。MDNは、この値が none 以外なら範囲指定に対応している、と書いている。一方、RFC 9110の14.3節は、これを保証とは読まないよう、念を押している。
"Conversely, a client MUST NOT assume that receiving an Accept-Ranges field means that future range requests will return partial responses."
（訳: 逆に、クライアントは、Accept-Rangesの項目を受け取ったからといって、今後の範囲指定がかならず部分的な応答になる、と思い込んではならない。）
If-Rangeは、ファイルが前と同じ版なら範囲だけを、違うなら全体を返してほしい、と頼む要求のヘッダーで、ETagか日付を値にする。ダウンロードの再開で、途中でファイルが差し替わっていたときに、古い続きと新しい続きが混ざるのを防ぐ。
配信元（オリジン）と、かたまり（チャンク）
配信元は、ファイルの本物を持つサーバーである。CDNは、その手前でコピーを持って配る。チャンクは、Cloudflareが保存済みのファイルを分ける、決まった大きさのかたまりである。
用語
416 Range Not Satisfiableは、頼まれた範囲が、そのファイルでは満たせないときのステータスである。仕様書は、このときContent-Rangeに bytes */総サイズ の形で、現在の大きさを付けるのがよい（SHOULD）と書いている。MDNの説明も同じである。ただし仕様書は、416が返らず、全体が200で返る配信元も多い、と注記している。
04 型別 — 大きなファイルを配るサイトだけが対象で、確かめる手順は6つある
🅰 適用範囲 — どんなサイトが対象か
対象は、PDF・動画・ダウンロードできる資料・ソフトの配布物・大きな画像のような、大きなファイルを配っているサイトである。Cloudflareの原文は、利用に向く通信として、シークできる動画（MP4など）、再開できる大きなダウンロード、ソフトの配布やパッケージの置き場、ディスクイメージや書庫、AIのモデルファイル、大きなファイルの一部だけを読むクライアントを挙げている。
Cloudflareを使っているかどうかで、確認の意味が少し変わる。使っているなら、キャッシュルールの設定を入れる前に、配信元が答えられるかを確かめる。使っていないなら、設定は関係ないが、配信元そのものが範囲指定に正しく答えるかを確かめることで、動画の頭出しやダウンロードの再開がうまく動くかが分かる。
🅱 原文が書いていないこと
原文を読んだ範囲では、次のことは書かれていない。確かめられなかったので、この記事も書かない。
- かたまりの大きさ（原文は、決まった大きさのかたまりと書くだけである）
- 設定の対象にできるファイルの大きさの目安（原文は、大きなファイルの通信と書くだけである）
- 範囲指定ではなく、全体を頼まれたときの、配信元への頼み方
- 他のCDNに、同じ種類の機能があるかどうか
また、原文の数字（R2で半分・約6%）は、Cloudflare自身のサービスの数字である。利用者のサイトが同じ効果を得られる、とは原文は書いていない。
🅲 手順 — 6つの手順で、配信元の答え方を確かめる
手順は、すべて curl で、数回の取得で終わる。大きなファイルを丸ごと取らないために、Rangeで先頭の100バイトだけを頼み、本文は捨てる形にしている。
注意
確認は、自分が管理するサイトのファイルに対してだけ行う。取得は数回にとどめ、同じファイルへ連続して何十回も頼まない。Range付きの取得でも、配信元のログには1回ごとに残る。
手順1: Rangeを付けずに、大きさとETagを取る
最初に、対象のファイルのヘッダーだけを取り、Accept-Ranges・Content-Length・ETagの3行を書き出す。どのファイルを調べるか決めるには、サイト内に書かれているリンクや画像のアドレスを調べる🔧 WEBサイト内のリンク漏れ・チェックツールで、PDFや動画へのリンクを一覧にするとよい。ファイルの大きさを測るツールではないので、大きさは、このあとの curl で見る。
curl -sI https://example.com/files/sample.pdfAccept-Rangesが無くても、範囲指定に答えないとは限らない。次の手順で、実際に頼んで確かめる。
手順2: 先頭の100バイトを頼み、ステータスと2つの数字を見る
curl -s -o /dev/null -D - -H 'Range: bytes=0-99' https://example.com/files/sample.pdf期待する答えは、206と、Content-Range: bytes 0-99/総サイズ、そして Content-Length: 100 の3つがそろうことである。総サイズは、手順1のContent-Lengthと一致する。200で全体の大きさが返ってきたら、範囲指定には答えていない。
手順3: 別の範囲を取り、ETagが同じか比べる
curl -s -o /dev/null -D - -H 'Range: bytes=100-199' https://example.com/files/sample.pdf手順2とこの手順で、ETagの値が同じなら、同じ版の続きとして組み立てられる。値が変わるなら、キャッシュや複数の配信元の間で、同じファイルの版がそろっていない可能性がある。
手順4: If-Rangeに、ETagの値を付けて頼む
手順1で控えたETagの値（引用符も含む）を、そのまま If-Range に付ける。次に、でたらめな値を付けて、もう1回頼む。
curl -s -o /dev/null -D - -H 'Range: bytes=0-99' -H 'If-Range: "手順1のETagの値"' https://example.com/files/sample.pdfETagの値が合っていれば206、合っていなければ全体の200が返る。値が合わないのに206が返るなら、版の確認が働いていない。
手順5: ファイルの外側の範囲を頼み、416を見る
curl -s -o /dev/null -D - -H 'Range: bytes=999999999-' https://example.com/files/sample.pdf期待する答えは、416と Content-Range: bytes */総サイズ である。仕様書は「SHOULD」と書くので、付かなくても違反とまでは言えない。付いていない場合は、結果として控えておく。
手順6: 配信元のログで、Range付きの取得と206の数を数える
取得した結果を、配信元のアクセスログでも確かめる。ページ側の状態もあわせて見たいときは、🔧 WEBサイト総合分析・レポートツールが、URLを入れるだけで、ページの作りや表示の状態をまとめて診断する。範囲指定の応答を調べるツールではない。大きなファイルへの取得のうち、何件がRange付きで、そのうち何件が206だったかを、1日分で数える。ログの書き方は環境ごとに違うので、ステータスの列とURLの列の位置は、自分のログで確かめてから数える。Range付きの取得が多いのに206が少ないなら、配信元が範囲指定に答えていない可能性がある。
確認の結果は、次の表のように読む。
| 見たこと | 読み方 | 次にすること |
|---|---|---|
| 206とContent-Range、Content-Lengthがそろった | 配信元が範囲指定に答えている | ETagの確認（手順3）へ進む |
| 200で、全体が返った | 範囲指定を使っていない。仕様上は許される | そのファイルに範囲指定が要るかを決める（05章の12番目） |
| 206だが、Content-Rangeが無い | 仕様に合わない応答。受け手が続きを組み立てられない | 配信元の設定の担当に、ヘッダーの出力を確かめてもらう |
| ETagが、取得のたびに変わる | 同じ版として扱えない | 複数の配信元の間で、ETagの作り方がそろっているかを聞く |
| 範囲外で416、Content-Rangeは無い | 仕様は付けるのが「SHOULD」。動作に直結しない場合が多い | 結果として控え、直すかは手間と並べて決める |
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトの大きなファイルが、範囲指定に正しく答えているかを確かめる13項目である。1〜5番目は対象のファイルの選び方と応答の形、6〜10番目はETag・If-Range・416・動的なページ・圧縮、11〜13番目はログ・対象外の判断・Cloudflareの設定である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトで大きなファイル（PDF・動画・配布ファイル）が置かれているページを3つ開き、ファイルのURLを書き出す
- 書き出したファイル1つに
curl -sIを使い、Accept-Rangesの行があるかを確かめる - 同じファイルに
Range: bytes=0-99を付けて取り、ステータスが206かを確かめる - 206のとき、Content-Rangeが
bytes 0-99/総サイズの形で、総サイズが実際の大きさと合うかを確かめる - Content-Lengthが100になっているかを確かめる
- 別の範囲（100-199）も取り、2回のETagが同じ値かを比べる
- ETagの値を付けたIf-Rangeで206、でたらめな値で200が返るかを確かめる
- ファイルの大きさを超える範囲を頼み、416とContent-Rangeの行が返るかを確かめる
- ログイン画面や検索結果のような、毎回作るページに同じRangeを付けて取り、200で全体が返ったら「対象外」と書き留める
- ZIPやMP4のような圧縮済みの形式のファイルで、Content-Encodingの行が付いていないかを1つ確かめる
- 配信元のアクセスログで、直近1日の大きなファイルへの取得のうち、Range付きの件数と206の件数を数える
- 置いているファイルの大きさを大きい順に10個書き出し、いちばん大きいものが小さければ、「範囲指定の対象外」と理由を1行で残す
- Cloudflareを使っているなら、Caching > Cache Rulesの画面を開き、大きなファイルに当たる規則があるかを確かめる。使っていなければ「使っていない」と書く
06 代替・他の選択肢 — 設定を入れるより先に、配信元の答え方と、ファイルの置き方を決める
4つの選択肢を、向いている場合と注意で比べる
次の表は、大きなファイルを配るときの選び方を、筆者が整理したものである。Cloudflareの原文は、1つ目の選択肢の説明であり、他の3つについては、この記事では原文を確かめていない。一般的な考え方として書く。
| 選択肢 | 向いている場合 | 注意 |
|---|---|---|
| CDNの機能を入れる（Origin Range Requests） | すでにCloudflareを通していて、大きなファイルへの範囲指定が多い | 配信元が範囲指定に答え、応答がキャッシュできる形であること（原文） |
| 配信元を直す | 206とContent-Rangeが返っていない | ファイルの種類ごとに設定が違う場合がある。直したあとで、手順2〜5をやり直す |
| ファイルを分けるか、置き場を替える | 1本が非常に大きく、一部だけ読まれる | リンクの書き換えが要る。古いURLの行き先を決める |
| 対象外と決める | 最大のファイルが小さく、利用者も頭出しや再開を使わない | 確認した日と理由を残し、ファイルが増えたら見直す |
設定を入れる前に、決めておくこと
設定を入れる前に、対象のファイルを決める。Cloudflareの設定は、通信を条件で選ぶので、「どのファイルを対象にするか」を先に決める必要がある。原文は、対象の通信は利用者が選び、キャッシュの調整と正しさの条件はCloudflareの側が扱う、と説明している。05章の1番目と12番目で、対象になりうるファイルの数と大きさを控えておくと、条件を書くときに迷わない。
設定のあとに、同じ手順をやり直す
CDNを通した後は、配信元に直接つなぐ取得と、CDNを通る取得の両方で、手順2〜5を取り直す。2つの結果が違うなら、どちらが答えているかを分けて考える。CDNの設定画面の状態だけを見て終わらせない。
07 当サイトで確かめたこと — 画像と記事のページに、curlで数回だけ取った
当サイトはCloudflareを使っていない。だから、Origin Range Requestsは当てはまらない。この章は、記事の手順2〜5を、公開中の画像1本と記事のページ1本に当てた結果である。2026年10月28日に、取得は全部で十数回にとどめた。
画像は、206とContent-Range、Content-Lengthがそろった
88,980バイトの画像に Range: bytes=0-99 を付けて取ると、206が返り、Content-Range: bytes 0-99/88980 と Content-Length: 100 がそろっていた。Accept-Rangesの行もあった。公開中のrobots.txtでも同じ形で、206と、総サイズ370バイトのContent-Rangeが返った。
別の範囲を取っても、ETagは同じ値だった
同じ画像に bytes=100-199 を頼んでも、206と正しいContent-Rangeが返り、ETagの値は1回目と同じだった。複数の範囲（bytes=0-9,20-29）を1回で頼むと、206で、複数の部分をまとめた形式の応答が返った。
If-Rangeは、仕様どおりに働いた
ETagの値を付けたIf-Rangeでは206、でたらめな値を付けると、全体の88,980バイトが200で返った。仕様書が書く、版が違えば全体を返す動きである。
416のとき、Content-Rangeの行は付いていなかった
ファイルの外側（bytes=99999999-）を頼むと、416が返った。ただし、応答のヘッダーに、Content-Rangeの行は無かった。仕様書は「付けるのがよい（SHOULD）」と書いていて、付けないことは違反とまでは言えない。画像のような小さいファイルで、困る場面は見つけていない。これは、05章の8番目の項目で見つかる種類の結果であり、直すかどうかは、まだ決めていない。
毎回作る記事のページは、Rangeを使わず200で全体が返った
記事のページに Range: bytes=0-99 を付けても、200で全体が返った。仕様書が、サーバーはRangeを無視してもよい、と書いている動きである。05章の9番目で「対象外」と書き留める結果に当たる。
当サイトで確かめていないこと
- 動画・PDF・数十メガバイトのファイル（取得で負荷をかけないよう、小さいファイルだけを測った）
- 圧縮をかけて返すファイルの範囲指定の動き
- 配信元のログの数え方（この記事の手順6）。当サイトのログでは、まだ数えていない
- CDNを通した場合の動き（当サイトはCDNを使っていない）
08 このテーマは、ここまで
範囲指定そのものの記事は、これまで書いていない。近いところでは、次の記事がある。
条件付きの取得で、記事ページの更新日を返した記録
CloudflareとOpenAIが「ページが変わったか」の信号で再取得を減らす試みを書いた週、当サイトの解説記事に更新日を入れた ── 入れる前に決めたことと、入れたあとに確かめた5つは、ページが変わったかを伝える信号（更新日と304）を入れた記録である。範囲指定のIf-Rangeも、同じ「版が同じか」を確かめる仕組みの仲間である。
外から取った応答は、目当てのものとは限らない
外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、取った応答の中身を確かめずに結論を出しかけた記録である。05章の手順で、200が返っても、全体が返ったのか範囲だけが返ったのかは、本文の大きさで見分ける。
画像の置き場と、運ばれた時刻の記録
見た目では区別できない ── 時刻の記録を読んだら、画像147本のうち45本が「運ばれてきた」側だったと、仕組みは在った。運ぶ気もあった。探す形が違っていた ── サムネイルが本番から消えていた日、ログは一度も鳴らなかったは、画像のファイルの置き場の話である。ファイルの版は、置いた日時でも変わる。ETagに時刻が入る配信元では、運び方で値が変わりうる。
警告の数より、自分で取り直した結果を信じた記録
警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったは、点検ツールの警告1,440件を種類ごとに数え、本物の2件と、本当に遅かったページを見つけた記録である。範囲指定の確認も、ツールの画面より、curlで取った応答のほうが確実である。
PDFを載せているサイトと、HTTPのステータスの扱い
Googleの番組は、PDFを内部でHTMLに変換して扱うと説明した ── PDFを載せている会社が、文字が取れるか・同じ中身の重複・置き場所を確かめる13項目（2026年10月時点）は、PDFの置き場所の確認を、robots.txtがエラーを返し続けると、最後は「制限なし」に行き着く ── HTTPステータス別の扱いを確認する13項目（2026年9月時点）は、ステータスごとの扱いを書いた。この記事の確認は、その続きとして使える。
2026年10月28日 — この記事の確認日
この記事の内容は、2026年10月28日に、公式のページ11本と、当サイトの公開中の画像・記事のページを開いて確かめた時点のものである。Cloudflareの記事や、HTTPの仕様書、MDNの説明に新しい変更が出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
