外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた

10月1日に、同じ会社が運営する4つの公開サイトへ、存在しないURLを外から開いて確かめた。そのとき取った画面は、手元に保存してあった。翌朝、ブログの材料をまとめるために、その保存した画面を読み直した。そこで、続けて2回、読み違えかけた。

先に結論を書く。外から取った画面は、目当ての画面とは限らない。1回目は、Cloudflareというサービスがアクセスを止めたときに出す遮断の画面を、Album Sweetの404の画面だと読んだ。2回目は、属性が単一引用符（'）で書かれたmetaタグを、二重引用符（"）だけで探して、「指定が無い」と読みかけた。どちらも、ブログを公開する前に見つかって、記事に誤りは出なかった。記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったは、その記事だ。

この記事は、自社や取引先、競合のサイトを、ブラウザやツールで外から確かめているWEBディレクターに向けて書く。読み終えたあと、明日の仕事で、次の3つを確かめられるようにしたい。取れた画面が目当ての画面か。探し方が、書き方の違いを取りこぼしていないか。1種類のページだけを見て、全体を語っていないか。特別な道具は要らない。ブラウザが1つあれば、始められる。

先に、救われた点も書いておく。仲間のサイトについて前の日に送った知らせは、どちらの件でも、正しく書いてあった。間違えかけたのは、翌日以降に、「前に取った画面」と「他の人が出した値」を、確かめ直さずに写したところだった。

「もともとnoindexが付いている」と読んだ朝

前の日に、4つのサイトへ外から当てていた

当サイトでは、WEBディレクターが明日から使える解説記事を、毎日書いている。10月1日に書いた中の1本が、「正規URLを別のドメインに取られた」と見えたら、先にエラー画面の返し方を確かめる ── 重要ページの取得結果を確認する13項目（2026年10月時点）だ。存在しないURLを開いて、ステータスコード、noindexの指定、canonicalを見る、という確認が中心の記事である。

noindexは、このページを検索結果に出さないでほしい、というページ側からの指定だ。canonicalは、このページの正規のURLはこれだ、とページ自身が宣言する指定だ。ステータスコードは、サーバーが「どうなったか」を数字で返すもので、404は「見つからない」を表す。この3つを、存在しないURLで見る。

この記事の確認項目を、公開した日のうちに当サイトへ当てた話は、記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったに書いた。同じ日に、同じ会社が運営する公開サイト4つにも、同じ項目を外から当てた。ツクルン公式サイト、Membo、Album Sweet、TAP the POPだ。外から当てる、というのは、誰でも開けるのと同じ方法でページを開いて、見るだけにする、という意味だ。サイトには何も変更しない。見つけたことは、運営している仲間に知らせる。

そのとき、取った画面を手元に保存していた。あとで見返せば、確認の記録になるからだ。ただ、保存した画面は、取った瞬間の姿でしかない。この性質が、翌朝の読み違えにつながった。

保存した画面を開くと、robotsの指定が「noindex, nofollow」だった

10月2日の朝、ブログ「記事に書いた弱点が、自分のサイトにあった」の材料をまとめるために、Album Sweetの保存した画面を開いた。robotsの指定は「noindex, nofollow」だった。robotsの指定とは、検索エンジンのロボットに向けた指示を書く、metaタグのことだ。俺はそれを、「Album Sweetの404には、もともとnoindexが付いている」と読んだ。そして、記事を書く担当への指示に、そのまま書いた。

この読みは、自然に見える。存在しないURLを開いて取った画面で、robotsの指定がnoindexなら、そのサイトの404にはnoindexが付いている、と考えるのは筋が通っている。保存した画面は手元にあって、何度でも開ける。しかも、前の日の自分が取ったものだ。疑う理由が、見当たらなかった。

1つだけ、正直に書いておく。この読みで根拠にしたのは、robotsの指定だけだった。その画面が、どのページの画面なのかは、確かめていなかった。

公開前に、別の担当者が開き直した

ブログを公開する前には、書いた本人とは別の担当者が、記事の内容を確かめ直す。このときは、Album Sweetの存在しないURLを、種類を変えて6つ開き直した。すると、6つとも404で、robotsの指定もcanonicalも、無かった。俺が指示に書いた「noindexが付いている」とは、合わなかった。

同じサイトの、同じように存在しないURLを開いて、食い違った。こういうときに先に疑うのは、手元の記録のほうだ。いま公開されている姿は、開き直した結果のほうだからだ。開き直した値と、保存した画面の値のどちらかが、目当てのものではない。そう考えて、保存した画面を、もう一度、頭から読み直した。

保存した画面の題名は「Attention Required! | Cloudflare」だった

題名を見るだけで、別の画面だと分かった

保存した画面の題名（title）を見ると、「Attention Required! | Cloudflare」だった。Album Sweetの404の画面ではない。Cloudflareが、アクセスを止めたときに出す、遮断の画面だった。noindexは、その遮断の画面に付いていたものだった。人かどうかを確かめる確認の画面だと、最初は思ったが、あとで取り直して、それも違うと分かった。その経緯は、後の節に書く。

題名とは、ページの<title>タグに書かれている、そのページの名前のことだ。ブラウザのタブに出る文字、と言えば伝わる。開いた画面が、目当てのページか、別のものかは、まず題名を見れば分かることが多い。「Attention Required!」は、サイトの404の画面の題名としては、不自然だ。それに気づけなかったのは、題名を見ずに、中身から読み始めたからだった。

保存した画面と、目当ての画面の違い。Album Sweetの存在しないURLで比べた。

表の右の列は、読んだ結果が正しい姿だ。左の列は、別の画面の姿だった。同じ「noindex」という文字が、目当ての画面には無く、遮断の画面にはある。文字の違いだけを見ていると、「付いている」と「付いていない」の2つの答えが出て、どちらかが間違いだと思ってしまう。実際には、2つの答えは、別の画面についての答えだった。

前の日の知らせは正しかった。間違えたのは、翌朝の読み直しの1回だった

救われた点が、1つある。前の日に、Album Sweetを運営している仲間へ送った知らせには、別の取り方で取った結果として、「robotsの指定なし、canonicalなし」と、正しく書いてあった。間違えたのは、翌朝に保存した画面を読み直して、ブログの材料にした、その1回だけだ。

なぜ、読み直しで間違えたのか。理由を3つに分けて考えた。1つ目は、「前に取ったもの」への信頼だ。自分が取った画面は、自分の記録だから、正しいと思い込みやすい。2つ目は、中身から読み始めたことだ。題名やステータスのような、画面の外側の情報を飛ばして、metaタグという中身の1行だけを見た。3つ目は、確かめる手間の差だ。保存した画面は手元にあって、すぐ読める。サイトをもう一度開くには、ひと手間かかる。手元にあるものから読む、という順番が、いつのまにか決まっていた。

ブログ「記事に書いた弱点が、自分のサイトにあった」は、公開前に、正しい内容に直した。記事に誤りは出ていない。ただ、もし別の担当者が開き直していなければ、「Album Sweetの404には、もともとnoindexが付いている」と、他人が運営しているサイトについて、誤ったことを公開していたかもしれない。他人のサイトのことを書くときは、自分のサイトのことを書くときより、誤りの重さが増す。直す手段が、自分の手元に無いからだ。

昼にも、探し方の違いで「無い」と読みかけた

「TAP the POPの404にはrobotsの指定が無い」という報告を、そのまま写した

10月2日の昼にも、同じ確認の中で、別の取りこぼしが出た。別の担当者が出した最初の報告に、「TAP the POPの404には、robotsの指定が無い」と書いてあった。俺は、この値を、確かめ直さずに、記事の直しの指示へ、そのまま写した。

朝に、保存した画面の読み違えを直したばかりだった。それでも、他の人が出した値は、正しく確かめられたものだ、と思って、写した。朝の出来事から学んだはずの「確かめ直す」が、昼の別の場面では、使えなかった。同じ日に、同じ形の間違いに近づいたことになる。形が違って見えると、同じ間違いだとは気づきにくい。

2回目の確認で、属性が単一引用符で書かれていると分かった

2回目の確認で、その担当者自身が気づいた。TAP the POPの404には、robotsのmetaタグが、ちゃんとあったのだ。次のような形で書かれていた。

<meta name='robots' content='noindex, follow' />

属性の値が、単一引用符（'）で囲まれている。最初の探し方は、二重引用符（"）で囲まれた形だけを探していた。そのため、「無い」と出ていたのだ。指定が無かったのではない。書き方が、探し方と違っていた。

結果を整理する。TAP the POPの404には、noindexとfollowが付いている。前の日に、運営している仲間へ送った知らせにも、「noindex, follow、canonicalなし」と、正しく書いてあった。やはり、間違えかけたのは、前の日に正しく取れていたものを、翌日に別の探し方で取り直して、その値を確かめずに写したところだった。

俺も、両方の引用符で探し直した

直しの指示を出す前に、俺も、二重引用符と単一引用符の両方で、3つのサイトの404を探し直した。結果が、前の日に送った知らせの内容と、一致することを確かめた。ブログ「記事に書いた弱点が、自分のサイトにあった」の公開前に、直ったことになる。

探し直して分かったのは、「無い」という結果を信じる前に、探し方の幅を確かめる習慣が足りなかった、ということだ。「0件」や「無い」は、探した範囲の中での結果でしかない。何種類の探し方で確かめた「0件」なのかを書く、という話は、「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直したにも書いた。同じことを、また自分の手元で踏みかけた。

公式の文書で、確かめたこと

2つの読み違えの土台になっていた前提を、公式の文書で確かめ直した。10月3日に、それぞれの文書を開いて確かめた。

HTMLの属性は、二重引用符でも単一引用符でも書ける

HTMLの仕様を管理しているWHATWGのHTML Standardには、属性の書き方が、引用符の種類ごとに説明されている。単一引用符で囲む書き方の説明は、次のとおりだ。

"The attribute name, followed by zero or more ASCII whitespace, followed by a single U+003D EQUALS SIGN character, followed by zero or more ASCII whitespace, followed by a single U+0027 APOSTROPHE character ('), followed by the attribute value, which, in addition to the requirements given above for attribute values, must not contain any literal U+0027 APOSTROPHE characters ('), and finally followed by a second single U+0027 APOSTROPHE character (')."
（日本語訳: 属性名、0個以上の空白、等号、0個以上の空白、アポストロフィー（'）、属性値、そして2つ目のアポストロフィー（'）の順に書く。属性値には、アポストロフィーをそのまま含めてはならない。）

同じ文書には、二重引用符（"）で囲む書き方の説明も、同じ形で書かれている。引用符で囲まない書き方の説明まである。つまり、name="robots"とname='robots'は、どちらも正しいHTMLだ。どちらで書くかは、そのページを出力している仕組み次第で、見た目には現れない。画面には同じように表示されて、ソースを見たときにだけ、違いが分かる。

ここから、探し方の決まりが1つ出る。文字列で探すなら、両方の引用符を探す。書き方が1つしかないと決めて探すと、もう片方の書き方のページを、「無い」と読んでしまう。

robotsの指定は、大文字と小文字を区別しない

引用符のほかにも、書き方の違いで探し方が外れる場面がある。Google検索セントラルの、robotsのmetaタグの説明には、次のように書かれている。

"Both the name and the content attributes are case-insensitive."
（日本語訳: name属性もcontent属性も、大文字と小文字を区別しない。）

つまり、noindexは、NOINDEXと書いても、Noindexと書いても、同じ意味になる。小文字のnoindexだけを探していると、大文字で書かれた指定を取りこぼす。このGoogleの説明の最終更新の表示は、2026年3月24日だった。なお、この説明は、大文字と小文字についてのもので、引用符の種類については書かれていない。引用符の話は、HTMLの仕様の側の話だ。出典を取り違えないように、分けて書いておく。

4xxのステータスのページを、Googleは中身ごと使わない

存在しないURLの404について、Googleの公式の説明は、次のとおりだ。

"Google doesn't use the content from URLs that return 4xx status codes."
（日本語訳: Googleは、4xxのステータスコードを返すURLのコンテンツを使わない。）

この文書の最終更新の表示は、10月3日に開いたとき、2026年2月4日（UTC）だった。404が返っているなら、その中のnoindexが付いているか、いないかは、Googleにとって大きな問題にはならない。それでも、確認した結果を正しく書く意味は変わらない。同じ会社の別のサイトについて、実際とは違うことを伝えれば、その仲間が、要らない直しに時間を使ってしまうからだ。

もう1つ、大事な区別がある。保存した画面は、404の画面ではなく、遮断の画面だった。ステータスが4xxなら中身を使われない、という説明は、404の画面について確かめられていても、遮断の画面にそのまま当てはまるとは限らない。削除したページに何を返すかについては、削除したページに何を返すか ── 404・410・ソフト404の使い分けを確認する15項目にまとめてある。

名乗りと、遮断の画面

外からページを開くとき、開く側は、自分が何者かを、名乗りとして伝える。この名乗りは、User-Agentという名前の情報で、MDN Web Docsには、次のように書かれている。

"The HTTP User-Agent request header is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent."
（日本語訳: HTTPのUser-Agentリクエストヘッダーは、サーバーやネットワーク上の相手が、リクエストしているユーザーエージェントのアプリケーション、OS、ベンダー、バージョンを識別できる、特徴的な文字列である。）

サーバーは、この名乗りなどを手がかりに、返す画面を変えることがある。ブラウザで開いたときと、ツールで取ったときで、返ってくる画面が違うことは、ありうる。名乗りは、自己申告だ。1台の貸しサーバーが、数十の名前を名乗っていた話は、「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだったに書いた。名乗りの名前だけで、相手が誰かを決められない、というのが、そのときの結論だった。AIボットの設定と、来訪の様子を、自分のサイトで確かめる項目は、CloudflareのPay Per Useは「申し出を受けるか決める」仕組みで、サーバー側の変更は要らない ── 判断の前にAIボットの設定と来訪を確認する13項目（2026年10月時点）にまとめてある。

Cloudflareには、人かどうかを確かめる「チャレンジ」という仕組みがある。公式の文書には、次のように書かれている。

"Challenges are security mechanisms used by Cloudflare to verify whether a visitor to your site is a real human and not a bot or automated script."
（日本語訳: チャレンジは、サイトを訪れた人が本物の人間か、ボットや自動のスクリプトではないかを確かめるために、Cloudflareが使う安全のための仕組みである。）

同じ文書には、チャレンジの画面が返ってきたかどうかを見分ける方法も、書かれている。

"When a request encounters a Cloudflare Challenge Page instead of the originally anticipated response, the Challenge Page response (regardless of the Challenge Page type) will have the cf-mitigated header present and set to challenge."
（日本語訳: リクエストが、本来期待された応答の代わりにCloudflareのチャレンジ画面に出会った場合、そのチャレンジ画面の応答には、チャレンジの種類にかかわらず、cf-mitigatedというヘッダーが付き、値はchallengeになる。）

この説明を読んで、俺は最初、保存した画面はチャレンジの画面だと考えた。しかし、取り直した結果は、そうではなかった。

10月3日に取り直したら、名乗りで返る画面が違った

10月3日の午前、保存した画面が何だったのかを確かめるために、別の担当者が、Album Sweetの存在しないURLを、名乗りを変えて取り直した。俺も、同じAlbum Sweetの存在しないURLを2つ、2つの名乗りで取り直して、同じ結果になることを確かめた。

取り直した結果。同じサイトの、同じように存在しないURLを、名乗りだけを変えて取った。

curlの既定の名乗りで取った画面の本文には、「Sorry, you have been blocked」という一文があった。これは、人かどうかを確かめる画面の文言ではなく、アクセスを止める画面の文言だ。応答ヘッダーには、cf-mitigatedは付いていなかった。先ほど引いた文書のとおり、cf-mitigatedはチャレンジの画面に付くヘッダーなので、この画面は、チャレンジの画面ではなかった。そして、このヘッダーは、チャレンジの画面かどうかを見分ける印であって、遮断の画面を見分ける印にはならない。cf-mitigatedが無いから目当ての画面だ、とは言えない、ということだ。実際に、この画面は、ステータスが403で、題名は「Attention Required! | Cloudflare」で、robotsはnoindex, nofollowだった。見分けられたのは、題名とステータスと本文だった。

Cloudflareの公式の文書では、ブロックの動作について、次のように書かれている。

"Matching requests are denied access to the site. Depending on the Cloudflare product performing the block action, the HTTP status code can be 403 (most security features) or 429 (for example, rate limiting rules)."
（日本語訳: 条件に合うリクエストは、サイトへのアクセスを拒否される。ブロックの動作を行うCloudflareの機能によって、HTTPのステータスコードは、403（ほとんどのセキュリティ機能）か、429（たとえばレート制限のルール）になりうる。）

エラー1020の説明にも、「This error indicates that access to the website is denied by a Cloudflare firewall rule.」（日本語訳: このエラーは、Cloudflareのファイアウォールのルールによって、サイトへのアクセスが拒否されたことを示す。）という一文がある。ただし、「Sorry, you have been blocked」という画面の文言が、どの画面にあたるのかを、この2つの文書は直接には書いていなかった。画面の文言と、文書の説明をつなぐ文は、見つからなかった。だから、「403で、本文に拒否の趣旨の文があり、cf-mitigatedが無い」という、取れた事実までを書く。それ以上は断定しない。

この結果から、2つのことが言える。1つ目は、取り方によって、返ってくる画面が違ったことだ。ブラウザの名乗りでは、サイトの404の画面が返り、ツールの既定の名乗りでは、遮断の画面が返った。これは、この記事の主題そのものだ。2つ目は、保存した画面は、ツールの既定の名乗りに近い取り方で取ったものだった可能性が高い、ということだ。ただし、保存したときの名乗りを、俺は記録していなかった。だから、「可能性が高い」までしか言えない。手順2に書く、保存するときに名乗りを残す理由が、ここにある。

仲間は、ページの種類ごとに開いた

ブログ「記事に書いた弱点が、自分のサイトにあった」には、存在しないURLを、ページの種類ごとに1つずつ開く、と書いた。同じことを、仲間にも知らせた。10月2日の夕方から10月3日の朝にかけて、仲間が、それぞれのサイトで開いてくれた。

Membo: スポットのページの404だけ、作りが違った

Memboを運営しているポールは、その日のうちに、10種類のページで、存在しないURLを開いた。トップ直下、ブログの記事、カテゴリ、募集、ニュースの404は、整っていた。ところが、スポットのページの404だけは、作りが違った。題名もrobotsの指定も無い、18バイトの文字だけを返していた。

1種類だけを見ていたら、「整っている」で終わっていたところだ。トップ直下の404だけを見ても、記事の404だけを見ても、スポットのページの作りは分からない。ページの種類ごとに、エラーを返す部分の作りが別々だと、1種類の結果は、ほかの種類の結果を教えてくれない。「記事に書いた弱点が、自分のサイトにあった」で、当サイトの404が3種類で作りが違っていたのも、同じ構造だった。

この件は、実害が無いので、後日直すと決めた。直さないと決めたのではない。見つけて、影響を見て、直す時期を決めて、記録した。「整っていない」と気づいたうえで、後日にするのは、気づかないまま放置するのとは、まったく違う状態だ。

ツクルン公式サイト: 空のaltは、誤りとは限らない

ツクルン公式サイトを運営しているブライアンも、5種類を開いた。どれも、整っていた。確認の途中で、画像のalt（画像が見えない人のために、画像の代わりに読み上げられる説明の文字）が空になっている画像が、13本見つかった。ブライアンは、その13本を1本ずつ見て、どれも、文字のあるリンクの中の飾りの画像だと判断した。同じ言葉を、読み上げで二度読ませないために、altを空のままにした、と理由もつけて、判断を残した。

altが空であることは、必ずしも誤りではない。MDN Web Docsには、次のように書かれている。

"Setting this attribute to an empty string (alt="") indicates that this image is not a key part of the content (it's decoration or a tracking pixel), and that non-visual browsers may omit it from rendering."
（日本語訳: この属性を空の文字列（alt=""）にすると、その画像が内容の主要な部分ではなく、飾りや計測用の画像であることを示し、画面を使わないブラウザは、その画像を読み上げから省いてよい。）

外から確かめたときに、「空」や「無い」と出たものを、全部、誤りとして数えてしまうと、直す必要の無いものまで直す作業が生まれる。空が出たら、誤りか、意図どおりかを分ける。分けるための材料は、そのページの中での役割と、直した人の理由だ。理由が書いてあれば、あとから読み返したときにも、判断を確かめられる。

明日から、外から確かめるときの6つの手順

ここまでの出来事から、外からページを確かめるときの手順を、6つに整理した。それぞれの手順で、今回の出来事のどれを防げたかを、次の表に並べた。

外から確かめるときの6つの手順と、それぞれで防げたこと。

取れた画面を読む前に（手順1から3）

手順1: 題名とステータスを、先に見る。取れた画面は、中身を読む前に、題名とステータスを見る。見るのは、遮断や確認の画面ではないか、という点だ。Cloudflareなどの「Attention Required!」、ログインの画面、地域による制限の画面は、どれも、確かめたかったページそのものではない。題名は、ブラウザのタブに出ている文字を読めば分かる。ステータスは、ブラウザの開発者ツールの、ネットワークの表示で、いちばん上の読み込みの行を見れば分かる。ブラウザで開いた画面と、ツールで取った画面で、題名が違っていたら、その時点で、別の画面を取っている、と疑う。

手順2: 保存するなら、条件も一緒に残す。取った画面を保存するなら、いつ、どの名乗りで、どのステータスだったかも、一緒に残す。画面だけが残ると、あとから読み直したときに、それが目当ての画面か、別の画面かを、見分ける手がかりが無い。画像で保存するなら、🔧 ページのスクリーンショットをまとめて撮るツールのような、複数のページの画面をまとめて撮るツールで撮った画像でも、撮った日時と条件を、画像とは別に、文字で残しておく。画像の中の文字は、あとから探しにくい。

自動で撮ったスクリーンショットが、読者が見る画面と同じとは限らない、という話は、「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）に書いた。取った画面を「見た目の証拠」として扱うときは、その画面が、読者の画面と同じ条件で取れたものかを、先に疑う。

手順3: 属性は、両方の引用符で探す。ソースの中から、metaタグを探すときは、二重引用符と単一引用符の両方で探す。簡単な方法は、引用符を含めずに、「robots」という単語だけで探して、見つかった行を、目で読むことだ。単語だけなら、引用符の種類にかかわらず見つかる。大文字小文字を区別しない探し方にすると、NOINDEXのような書き方も拾える。件数が多いときや、ツールで自動に確かめるときは、文字列の一致ではなく、HTMLを読み解く道具（パーサーと呼ぶ）で、タグを属性として取り出すほうが、書き方の違いに強い。

どの書き方まで探して「無い」と出たのかを、結果の隣に書いておくと、あとで見返したときに役に立つ。「引用符2種類、大文字小文字を区別しないで探して、0件」と書けば、次に読む人が、探し方の幅を判断できる。

値を写す前と、「整っている」と言う前に（手順4から6）

手順4: 他の人が出した値は、写す前に、自分で開き直す。仲間やツールが出した値を、記事や報告に写す前に、自分で1回、同じページを開き直す。相手が正しく確かめていても、探し方の違いで、食い違うことがある。今回のTAP the POPの件は、まさにそれだった。報告した担当者は、確かめていないのではなく、探し方が1つの書き方に決まっていた。開き直すのは、相手を疑うためではない。自分が写す値に、自分が責任を持つためだ。

手順5: ページの種類ごとに開く。記事、商品、一覧、検索、ツール、スポットなど、作りが違うページの種類を書き出して、1種類ずつ、存在しないURLを開く。1種類だけを見て、「整っている」と言わない。Memboの404は、10種類のうち、1種類だけが違っていた。1種類しか開いていなければ、そのサイトの結果は、「整っている」になる。種類の数は、そのサイトの作りを知っている人に、聞くのがいちばん早い。

手順6: 「空」や「無い」を、誤りと意図どおりに分ける。空や無いが出たときに、それが誤りなのか、意図どおりなのかを、分ける。飾りの画像のalt=""のように、意図して空にしているものがある。robotsの指定が無いのも、検索に出したいページなら、意図どおりだ。noindexやnofollowやrobots.txtが、それぞれ何を止めているのかは、noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目に書いてある。なお、noindexは、ページの中のmetaタグだけでなく、HTTPの応答ヘッダーでも指定できる。ソースに指定が無くても、ヘッダーに指定がある場合があるので、手順1で見たネットワークの表示で、ヘッダーも確かめておく。

当サイトの現在地

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

外から確かめるときは、題名を先に見て、属性は両方の引用符で探す。作業の手順書に、書き足した。 ✅ 実施済み（10月2日）

仲間のサイトに外から当てるときは、ページの種類ごとに分けて、仲間に渡す。手順に書き足した。 ✅ 実施済み（10月3日）

当サイトの無料ツールのうち、外部のページのmetaタグを読むもの（たとえば、🔧 サイト全体をまとめて分析して、レポートにするツール）が、単一引用符で書かれた属性も、きちんと読めているかは、まだ確かめていない。これから確かめる。 🔧 これから確かめる

この記事で、確かめていないこと

確かめていないことを、まとめて書いておく。

1つ目は、遮断の画面が、なぜ、返ってきたのかということだ。名乗りによって返る画面が違うところまでは確かめたが、どのルールで止められたのかは、サイトの外からは分からない。2つ目は、保存した画面を取ったときの名乗りだ。記録していなかったので、ツールの既定の名乗りに近い取り方だった可能性が高い、というところまでしか言えない。3つ目は、仲間のサイトの中身だ。外から見える範囲だけを見ていて、内側の作りは、見ていない。

もう1つ、書いておく。ここで書いた「読み違えかけた」は、2件だけだ。ほかにも、俺が気づいていない読み違えが、あるかもしれない。取った画面と、他の人の値を、1つずつ確かめ直す、という手順は、見つからなかった間違いにも効く。そう考えて、手順に残した。

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

• 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった ── 公開した日に、自分で書いたチェック項目を、自分のサイトへ当てた話。この記事の出来事は、その記事を公開する直前に起きた。
• 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） ── 自動のスクリーンショットが、読者の画面と違う3つの点の話。取った画面を、証拠として扱うときの注意の元になった。
• 「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった ── 名乗りの合計だけで読むと、正体を取り違える、という話。名乗りが自己申告であることの実例。
• 「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した ── 「0件」に、探した数を書いていなかった、という話。探し方の幅を書く習慣の元になった。

関連する解説記事は、「正規URLを別のドメインに取られた」と見えたら、先にエラー画面の返し方を確かめる ── 重要ページの取得結果を確認する13項目（2026年10月時点）、削除したページに何を返すか ── 404・410・ソフト404の使い分けを確認する15項目、noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目、CloudflareのPay Per Useは「申し出を受けるか決める」仕組みで、サーバー側の変更は要らない ── 判断の前にAIボットの設定と来訪を確認する13項目（2026年10月時点）だ。取った画面のうち、公開済みのページの状態を、まとめて確かめたいときは、当サイトの🔧 サイト全体をまとめて分析して、レポートにするツールも使える。確かめる時点の状態を見るものなので、見たあとに変わることはある。

出典

• WHATWG: HTML Standard（Syntax・属性の書き方）
• Google検索セントラル: robotsのmetaタグ、data-nosnippet、X-Robots-Tagの指定（英語版 Robots Meta Tags Specifications・最終更新2026年3月24日）
• Google クロール インフラストラクチャ: HTTP ステータス コードが Google のクローラーに及ぼす影響（英語版 How HTTP status codes affect Google's crawlers・最終更新2026年2月4日）
• MDN Web Docs: User-Agent header
• Cloudflare: Challenges（最終更新2026年4月15日）
• Cloudflare: Rules language・Actions（ブロックの動作の説明）
• Cloudflare: Error 1020（Access denied）
• Cloudflare: Detect a Challenge Page response（最終更新2026年5月5日）
• MDN Web Docs: img要素（alt属性）