WEBサイト
2026年8月18日から19日にかけて、当サイトは本番のセキュリティ穴を塞ぐ作業を進めていた。その途中で、性質のよく似た2つの検出作業を行った。1つは「この形のコードがどこにあるか」を数える作業。もう1つは「同じ値を、別の書き方で扱っている箇所がどこにあるか」を数える作業だ。どちらも、コマンド1本を走らせて、返ってきた件数を見て「対処すべき件数」を判断する、という点では同じだった。
そして、どちらの結果も間違っていた。1つ目は「多すぎる方」に倒れた。検出コマンドが9件をヒットさせたが、1件ずつ中身を開いて分類し直したら、実際に危険な形は0件だった。全部が偽陽性だった。2つ目は「少なすぎる方」に倒れた。別の検出コマンドは14件を数えたが、同じ値を別の経路で取っている箇所まで含めて数え直したら263件あった。約19倍、見落としていた。これは、archives/129「『自分のサイトに、同じ記事が2本ないか』を5分で確かめる」で書いた「タイトルで探すと45組、元記事で探すと139組、3倍違った」という話と、数の性質としてよく似ている。数え方を1つ変えるだけで、答えが何倍にも動く。
この2つを並べたとき、頭に浮かんだのは、当サイトが読者に毎日紹介しているもう1つの数字のことだった。Search Console やsite:検索が返す「0件」だ。読者がSCで「0件」を見たとき、それは「本当に何もない」のか、それとも「見えていないだけ」なのか。逆に「N件」が出たとき、それは本当に危険なのか。前日に公開したarchives/128「出力は在った。だから誰も測らなかった」で扱ったのも、「値は入っているのに、中身が違う」という、見た目と実態がずれる話だった。今回の実測でぶつかった罠と、Googleの公式ドキュメントが繰り返し書いている注意書きは、根っこが同じだった。この記事は、その根っこを1本の線でつなぐ。
1. 実測①：検出コマンドが「多すぎる方」に倒れた日
本番のReflected XSSを塞ぐ作業の一環で、似た危険がまだ残っていないかを確かめる検出コマンドを走らせた。想定していたのは、多くても数件のヒットだった。返ってきたのは9件だった。
1-1. 9件のヒットを、1件ずつ開いてみた
9件をそのまま「危険なコード9箇所」として扱う前に、1件ずつファイルを開いて、実際にどう書かれているかを確認した。結果は、9件のうち危険な形は0件だった。すべてが、検出コマンドの正規表現が反応しただけの、無関係な記述だった。
もう少し具体的に言うと、検出コマンドは「ある特殊文字の並び方」を目印にしていた。だが、その並び方は、危険なコードでなくても、別の目的で普通に使われる書き方の中にも現れる。検出コマンドは「その並び方があるかどうか」しか見ておらず、「その並び方が、値をどう扱う文脈の中に置かれているか」までは見ていなかった。
1-2. 針が見ていたのは「見た目」で、本物は「意味」だった
9件のうち何件かは、値がクォート（引用符）で正しく囲まれた形の中にあった。クォートで囲まれていれば、そこに何が入っても、値として扱われるだけで、コードとして実行されることはない。検出コマンドが目印にしていた「特殊文字の並び方」は、クォートの有無にかかわらず反応する作りだった。だから、安全な書き方と危険な書き方の両方を、同じ1件として数えていた。
これは、検出コマンドが嘘をついていたわけではない。検出コマンドは「この並び方がある」という事実を、正確に報告していた。ただ、その事実が「危険である」ことを意味するとは限らなかった。判定を最後まで人がやらずに、検出コマンドの件数だけで「9件を直さなければならない」と決めていたら、9件すべてに対して不要な修正を加えていたことになる。読者のサイトで検出ツールを使うときも、同じことが起きうる。件数を見た瞬間に対処を始めるのではなく、まず何件かを目視で確認する1手を挟む価値がある。
さらに、9件のうち1件だけは、確認しないと判断できない形をしていた。値がそのまま出力される関数を呼んでいる箇所で、その関数自体が何をしているかを、別のファイルまで遡って読まないと安全かどうか決められなかった。追った先には、値を受け取った時点で無害化する処理が既に入っていた。「呼び出し1箇所」だけを見ていたら、危険だと誤判定していたところだった。件数を数える作業は、コードの表面をなぞる作業であって、コードの意味を追う作業ではない。この2つは、同じ検出作業の中でも別の手間として区別しておく必要がある。
2. 実測②：検出コマンドが「少なすぎる方」に倒れた日
もう1つの作業では、逆方向に倒れた。ある値を直接参照している箇所を検出コマンドで数えたところ、14件だった。この14件を直せば範囲は網羅できたと考えかけた。
2-1. 14件と263件、19倍の差
念のため、同じ値を「直接の参照」ではなく「別の経路を通した参照」まで含めて数え直した。結果は263件だった。最初の14件は、氷山の一角どころか、全体の5%程度でしかなかった。
直接参照は、値の出どころが1行で見えるので見つけやすい。だが同じ値は、フレームワークが提供する別の入り口からも、同じように取り出せるようになっていた。検出コマンドは「ある1つの取り出し方」しか目印にしておらず、「同じ値を取り出す別の道」までは見ていなかった。
2-2. 同じ値を、違う道が運んでいた
この差が生まれた理由は単純だった。同じ入力元から来る値でも、コードの書き方は1通りではない。今回のサイトでは、古い時期に書かれたコードが直接参照の形を使い、比較的新しい時期に書かれたコードが別の入り口を使っていた。書いた時期が違えば、書き方の癖も違う。検出コマンドを1つの書き方に合わせて作ると、別の書き方で書かれた箇所は、存在しないことになってしまう。
実測①と実測②は、正反対の失敗に見えて、実は同じ失敗をしている。どちらも「検出コマンドが返した件数」を、そのまま「実際に対応が必要な件数」だと思い込みかけた。1つは多く数えすぎ、もう1つは少なく数えすぎたが、原因は同じで、検出コマンドが「見た目の1パターン」しか見ていなかったことにある。
3. 実測③：長さで切ったら、消してはいけないものが混ざっていた
3つ目の作業は、少し違う形の罠だった。今度は「探しているものを取り除く」作業で、対象を「文字列の長さ」で絞り込もうとした。
3-1. 9種類の長さの中に、探しているものは1つだけだった
該当しそうな文字列を全部拾って、長さ別に分類したところ、9種類の長さ（5文字・9文字・14文字・15文字・20文字・30文字・39文字・42文字・44文字）が出てきた。探していたものは39文字の形だと分かっていた。もし「30文字以上はまとめて対象にする」というやり方で処理していたら、42文字と44文字も一緒に巻き込んでいた。
44文字のものを個別に確認したところ、これは探しているものとはまったく別の種類のデータ（別の符号化方式で表現された値）の一部が、たまたま同じ文字の並びを含んでいただけだった。もしまとめて処理していたら、無関係なデータを壊していたことになる。長さという1つの軸だけで「同じ種類のものだ」と判断すると、たまたま似た形をした無関係なものまで巻き込む。✅ 当サイト実施済 今回は処理前に9種類すべてを個別確認したため、実害はゼロで済んだ。
4. 実測④：ブラウザが作るものを、サーバーの返事の中に探した
4つ目は、確認作業そのものの中で起きかけた誤読だった。ページの目次やチェックリストの項目が正しく出ているかを、サーバーの応答を直接取得するコマンドで確認しようとした。
4-1. 0件は「無い」のか「見ていない」のか
目次の項目を検索したところ、0件だった。一瞬「目次が壊れている」と判定しかけたが、その前に、目次がどうやって作られているかを確認した。目次とチェックリストの一部は、ページを読み込んだ後にブラウザ側の処理で作られる仕組みになっており、サーバーが最初に返す応答の中には、まだ存在しない。サーバーの応答だけを見ている限り、この0件は「壊れている」ことの証拠にはならなかった。同じ0件でも、道具が見ている場所によって、意味がまったく違う。
| 実測 | 何を数えたか | 最初の数字 | 数え直した数字 | 倒れた方向 |
|---|---|---|---|---|
| ① | ある形のコードの出現 | 9件 | 危険な形 0件 | 多すぎる方（偽陽性） |
| ② | ある値の参照箇所 | 14件 | 263件 | 少なすぎる方（見落とし） |
| ③ | 対象文字列の長さの種類 | 1種類のつもり | 9種類（うち別データが1種類混入） | まとめすぎる方（誤爆） |
| ④ | ブラウザ生成の項目 | 0件 | 0件（ただし理由が違う） | 誤読しかけた方（判定保留で回避） |
4つの実測を並べて分かるのは、「件数」という1つの数字が、まったく違う理由から同じ値になりうるということだ。0件は「本当に無い」ことも意味するし、「その方法では見えない」ことも意味する。9件は「9件が全部危険」なこともあれば、「9件が全部無害」なこともある。数字そのものより先に、その数字がどうやって作られたかを確認しないと、判定を誤る。
5. Google公式が言っている「0」の2つの顔
この4つの実測を終えたあと、Search Console のヘルプページを読み返した。読み返す前は、SCの数字は「表示された通りの値」だと思っていた。だが公式ドキュメントには、当サイトが今日踏んだのとよく似た注意書きが、はっきり書かれていた。
5-1. CSVに書き出すと、「該当なし」も「0」になる
Search Console のレポートには、値が「~」や「-」で表示される項目がある。これは「データがない」または「該当しない」という意味の記号で、実際の値が0であることを意味しない。ところが、このレポートをCSVとしてダウンロードすると、これらの記号はすべて数字の0に置き換わる。
"Values shown as either ~ or - in the report (not available/not a number) will be zeros in the downloaded data."
（日本語訳: レポート上で「~」や「-」（データなし・該当しない）と表示されている値も、ダウンロードしたデータでは0になります）
この一文は地味に見えるが、意味は大きい。画面上で「~」を見ているうちは、「この項目は測定していない」と正しく認識できる。だが同じ数字をCSVでダウンロードして別のツールで集計に使うと、「0」という、本当にゼロだった値と見分けがつかない数字に化ける。当サイトの実測③（44文字が別データの一部だった話）と同じ構造だ。元の形では見分けがついていたものが、加工の過程で見分けがつかなくなる。
5-2. 表の「0」と、ダウンロードした後の「0」は違う数字
さらに厄介なのは、この変化が「ダウンロードする」という、一見無害な操作だけで起きることだ。ブラウザの画面を見ている担当者と、ダウンロードしたCSVを見ている担当者が別人だった場合、2人は同じレポートについて、まったく違う前提で話すことになる。前者は「~」を見て「未測定」と判断し、後者は「0」を見て「ゼロ件」と判断する。どちらも自分が見ている数字を正確に読んでいるのに、結論が食い違う。
もう1つ、SCの検索パフォーマンスレポートには、別の種類の「見えないズレ」もある。プライバシー保護のために件数がごく少ないクエリ（匿名化クエリ）は、クエリ別の一覧表には表示されないが、グラフの合計値には含まれる仕組みになっている。つまり、一覧表に出ているクエリの数値を全部足しても、グラフに表示されている合計とは一致しないことがある。表の中の数字だけを見ていると、「合計が合わない」という別の誤読を招く。
6. site: 検索の0件は、未掲載の証明にならない
もう1つ、SEOの現場でよく使われる確認方法にsite:検索がある。site:example.com キーワードで検索して0件だったら「そのページはインデックスされていない」と判断する使い方だ。この使い方についても、Google自身が公式に注意を出している。
6-1. Google自身が「全部を返すとは限らない」と書いている
"The site: operator doesn't necessarily return all the URLs that are indexed under the prefix specified in the query."
（日本語訳: site: 演算子は、クエリで指定したプレフィックス配下のインデックス済みURLを、必ずしもすべて返すとは限りません）
これは、当サイトの実測①（検出コマンドが多すぎる方に倒れた）とは逆の性質を持つ罠だ。site:検索は「見えている数が実態より少なく出る」方向に倒れやすい。0件だったからといって、そのURLが本当に未インデックスだとは限らない。単に、site:検索という道具の仕組み上、拾いきれていないだけの可能性がある。
6-2. 0件のあと、次にやることまで公式が書いている
"If a URL doesn't show in a `site:` query, use the URL Inspection tool to make sure the URL can be indexed."
（日本語訳: URLがsite:クエリに出てこない場合は、URL検査ツールを使って、そのURLがインデックス可能かどうかを確認してください）
この一文が重要なのは、「0件だから安心してはいけない」で終わっていない点だ。「次にどの道具を使えばいいか」まで、公式ドキュメントが名指ししている。当サイトの実測④で、ブラウザ生成の項目を疑う前に「作られる仕組みを確認する」という1手を挟んだのと同じ構造だ。数字だけで判定を止めず、判定するための次の一手を用意しておく。
SCの「ページ」レポートで表示される例示URLの一覧にも、上限がある。ある状態に該当するURLの例示リストは、たとえ実際の該当件数が1,000件未満であっても、最大1,000件までしか表示されない仕組みになっている。また、URLが「Discovered（発見済みだが未クロール）」と「Crawled（クロール済みだが未インデックス）」のどちらの状態にあるかによって、レポート上の見え方も変わる。前者はまだクロールされていないため最終クロール日が空欄になり、後者はクロールはされたがインデックスされなかったことを示す。同じ「未インデックス」でも、途中の段階が違えば、次に取るべき対応も違う。
この「Discovered」と「Crawled」の違いをさらに詳しく整理したのが、「クロール済み」と「検出」、インデックス未登録の違い ── Search Console「ページのインデックス登録」レポートの読み方（2026年8月時点）だ。レポートの各状態が何を意味し、どう対応すべきかを1項目ずつ確認できる。
7. URL検査ツールの中にある、2つの答え
ではsite:検索の代わりにURL検査ツールを使えば安心かというと、そちらにも同じ形の注意書きがある。URL検査ツールは、Search Console内で個別のURLのインデックス状態を確認できる機能だ。
7-1. 「これはライブテストではない」
"This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web."
（日本語訳: これはライブテストではありません。表示される結果は、そのページの直近のインデックス版のものであり、Web上の現在のライブ版ではありません）
URL検査ツールを開いて最初に表示される結果は、「今のページ」ではなく「Googleが最後にインデックスしたときのページ」だ。この間にページを修正していれば、表示されている結果は、もう古い。
7-2. インデックス済み版とライブ版がずれることがある
"The Indexable status in the live URL can be different from the Page availability status on the indexed URL."
（日本語訳: ライブURLのインデックス可能ステータスは、インデックス済みURLのページ利用可能性ステータスと異なる場合があります）
つまり、同じ画面の中に「古い答え」と「今の答え」の両方が存在しうる。ツールには「ライブテストを実行」というボタンが用意されており、これを押すと、今のページを対象に測り直してくれる。当サイトの実測でも、検出コマンドの1回目の結果を鵜呑みにせず、中身を1件ずつ開いて測り直したことで、9件と14件という最初の数字を訂正できた。URL検査ツールが持つ「ライブテスト」ボタンは、それと同じ役割を果たす。
8. 「N件」も危険とは限らない
ここまでは「0件」側の話だったが、逆側にも同じ注意が必要だ。SCの「ページ」レポートで、インデックスされていないページが「N件」と表示されたとき、これは必ずしも問題を意味しない。
8-1. Not indexed is not necessarily bad
"Remember that Not indexed is not necessarily bad. Examine the reason given for not indexing a given URL."
（日本語訳: 「未インデックス」は必ずしも悪いことではありません。そのURLがインデックスされていない理由を確認してください）
当サイトには、これに近い実例がある。archives/98「1,238記事の8割が『土俵に上がっていない』ことに気づいた日」で書いた、addview.html未生成による静かなnoindex状態だ。あのときの「N件」は、本当に対処が必要な数字だった。だが、Googleの公式説明が言っているのは、すべての「N件」が同じ重さを持つわけではない、ということだ。重複URLの正規化や、意図的なnoindex設定によって「未インデックス」になっているページも、同じ「N件」の中に混ざる。件数だけを見て「多いから危険」「少ないから安全」と判定するのではなく、1件ずつ理由を確認する手順が要る。
似た注意は、クロールエラーの世界にもある。SCの「404」エラーは、確認した上で「そのURLがサイト上に存在してはならないと確信できる」場合に限って、無視してよいとされている。無条件に無視してよいわけではない。「エラーの件数が多いから危険」「少ないから安心」という短絡も、この一文の前では成立しない。件数の大小より先に、1件ずつの理由が問われている点は、未インデックスの話とまったく同じ構造だ。
当サイトの実測に戻ると、実測②で見つかった263件も、この「1件ずつの理由」を確認する作業を避けて通れなかった。263件のすべてが、同じ重さの修正を必要としたわけではない。値の出どころが外部からの入力そのものである箇所と、既に内部で加工済みの値を再利用しているだけの箇所とでは、対処の優先度が違う。件数を1つの塊として扱うと、この優先度の違いが見えなくなる。「N件」という数字を受け取ったら、まずその中身を、危険度で並べ直す1手が要る。
こうした「1件ずつ理由を確認する」作業は、対象が多いほど後回しにされやすい。当サイトが用意している🔧 外からできるセキュリティ対策監査ツール（要ログイン）は、自分のサイトに対してこの仕分け作業の起点を機械的に洗い出す用途で使える。
9. 針を疑うための4象限
実測①〜④とGoogle公式の注意書きを並べて見えてきたのは、「検出した/検出しなかった」と「実際に問題がある/ない」という2つの軸を、常に別々に確認する必要があるということだ。この考え方は、セキュリティ業界の団体OWASPが、検出ツールの性能を評価する枠組みとして使っている。
9-1. 「何でも危険と言う道具」と「何も言わない道具」
OWASPは、テストの結果を4つに分類する。危険が実在し正しく検出できたものを真陽性（True Positive）、危険が実在するのに検出できなかったものを偽陰性（False Negative）、危険がなく正しく「問題なし」と判定できたものを真陰性（True Negative）、危険がないのに誤って「危険」と判定したものを偽陽性（False Positive）と呼ぶ。
"True Positives: Tests with real vulnerabilities that were correctly reported as vulnerable by the tool."
（日本語訳: 真陽性: 実在する脆弱性が、正しく報告されたテスト）
| 分類 | 実際の状態 | 検出結果 | 今回の対応する実測 |
|---|---|---|---|
| 真陽性（True Positive） | 危険が実在 | 正しく検出 | 実測②で見つかった263件のうち、実際に修正が必要だった箇所 |
| 偽陰性（False Negative） | 危険が実在 | 検出できず | 実測②で最初の14件しか数えていなかった状態 |
| 真陰性（True Negative） | 危険なし | 正しく「問題なし」 | 今回の4つの実測では測っていない（検出されなかったものの中の安全な箇所は、数えていない） |
| 偽陽性（False Positive） | 危険なし | 誤って「危険」と判定 | 実測①の検出コマンドが最初に返した9件 |
OWASPはさらに、検出精度を測る指標として「感度＋特異度－1（Youden Index）」という計算式を使い、この値がゼロに近い道具は、たとえ多くのヒットを出しても実質的に無価値だと評価する。「何でも危険だと言う道具」は真陽性を取りこぼさない代わりに偽陽性を量産し、「何も言わない道具」は偽陽性を出さない代わりに真陽性まで取りこぼす。どちらも、この指標ではゼロに近づく。件数の多さそのものは、道具の良し悪しを保証しない。
9-2. 自分のサイトで、いますぐできる2つの確認
この4象限を、当サイトの実測に当てはめ直すと、実測①と実測②は、まさに軸の両端で失敗していたことが分かる。実測①は偽陽性を出しすぎ、実測②は偽陰性を出しすぎていた。どちらも「検出した件数」だけを見ていたら気づけなかった。1件ずつ開いて分類する（陽性側の確認）と、検出条件を変えて数え直す（陰性側の確認）を、両方やって初めて、本当の数が見えた。
この考え方は、当サイトのarchives/124「猫のファイルが『効いている証拠』を無効化した日」で扱った「陰性対照」の話とも重なる。あの記事で書いたのは、「効いている証拠」を示すには、鳴るべきものが鳴るだけでなく、鳴らないはずのものが鳴らないことも確認しなければならない、という話だった。今回の実測①②は、その逆側の実例になった。鳴らないはずのもの（偽陽性）が鳴り、鳴るはずのもの（偽陰性）が鳴らなかった。
Googleの公式ドキュメントには、検索演算子（site:を含む）よりURL検査ツールの方が信頼できる、と明記した一節もある。理由は、検索演算子がインデックスや検索の仕様上の制約を受けるのに対し、URL検査ツールはデバッグ用に個別のURLを直接確認できる作りになっているからだ。粗い道具と精密な道具が食い違ったら、精密な方を信じる、というのは、当サイトの実測②（直接参照だけでなく別経路も数え直した）でやったことと同じ順番になっている。
ここで気をつけたいのは、「精密な道具の方が常に正しい」という単純な話ではない点だ。精密な道具は、対象を1件ずつ、粒度細かく見る分、確認に時間がかかる。粗い道具は、全体をざっと眺めるには向いているが、個別の判定には向かない。実測①で9件を1件ずつ開いたのも、実測②で263件を経路別に数え直したのも、時間をかけたからこそ気づけたことだった。粗い道具で全体の当たりをつけ、精密な道具で個別に確定する、という2段構えを、最初から前提にしておく方が現実的だ。1つの道具だけで、多い方にも少ない方にも倒れない答えを一発で出そうとすると、たいてい失敗する。
10. 今日から使えるチェックリスト
ここまでの実測とGoogle公式の注意書きから、読者が自分のサイトで今すぐ使える確認事項を、行動としてまとめる。
10-1. 数字を見るたびに聞く、1つの質問
SCの数字にせよ、自分で書いた検出コマンドの結果にせよ、件数を見た瞬間に自分に問う質問は1つで足りる。「この数字は、何を測ろうとして、何を測り損ねているか」。0件を見たら、測る方法そのものが対象を捉えられているかを確認する。N件を見たら、その全件が同じ理由で数えられているかを確認する。
- ✅ 当サイト実施済
site:検索の0件を鵜呑みにせず、URL検査ツールで個別確認する運用に切り替えた（本記事の実測を機に） - ✅ 当サイト実施済 検出コマンドの結果は、必ず1件ずつ開いて陽性・陰性の両方を確認してから対処を決める（実測①②で実践）
- 🔧 当サイト着手中 SCレポートのCSVダウンロードを扱う際、「~」表示だった項目と本当の0件を区別する運用の整備
- 🔧 当サイト着手中 「N件」が出た未インデックスページを、理由別に分類して記録する仕組みの整備
SCの数字の癖にいちいち振り回されないために、当サイトは🔧 Search Consoleの見方に迷ったらこちらの解説ツールを用意している。「~」と「0」の違いや、URL検査ツールが返す結果の意味を、レポートの項目ごとに確認できる。
件数という数字は、事実を要約してくれる便利な道具だが、要約である以上、要約する過程で何かを均している。0が2つの意味を持ち、Nが2つの重さを持つのは、その要約の性質そのものだ。数字を見て動く前に、その数字がどこから来たかを、1回だけ確かめる。今回の3つの実測が示したのは、その1回を省略すると、多い方にも少ない方にも、同じ確率で倒れるということだった。
この記事に書いた内容には、限界もある。実測①〜④は、当サイトが今回たまたま踏んだ4つの罠であって、検出コマンドが倒れる方向のすべてを網羅したものではない。同じ考え方を別のサイト、別の道具に当てはめたとき、まったく別の理由で0件やN件が出ることもあるはずだ。だから、この記事が伝えたいのは「この4つを確認すれば安全だ」というチェックリストではなく、「数字を受け取ったら、その数字の作られ方を1回疑う」という、確認の手前にある姿勢そのものだ。手順は状況ごとに変わるが、この姿勢だけは、どのサイトでもそのまま使える。
もう1つ付け加えておきたいのは、この姿勢を毎回律儀に発動させる必要はない、ということだ。すべての数字を毎回疑っていては、作業が前に進まない。今回、当サイトが数字を疑う手を止めなかったのは、対象が本番のセキュリティ修正という、間違えた場合の影響が大きい作業だったからだ。影響が小さい確認であれば、最初の数字をそのまま信じて先に進んでも、大きな問題にはならないことが多い。数字を疑う1手をどこで挟むかは、その数字を使って何を決めるか、という判断とセットで考えるのが現実的だ。
関連 archives（連載軸として読む）
- archives/129「『自分のサイトに、同じ記事が2本ないか』を5分で確かめる」 ── 数え方を変えると答えが3倍違った、直前の実測（2026-08-18）
- archives/128「出力は在った。だから誰も測らなかった」 ── 値は入っているのに中身が違う、という見た目と実態のズレ（2026-08-17）
- archives/124「猫のファイルが『効いている証拠』を無効化した日」 ── 陰性対照を置く考え方の起点
- archives/98「1,238記事の8割が『土俵に上がっていない』ことに気づいた日」 ── 「N件」が本当に危険だった実例
- archives/117「同じ条件で測っていなかった」 ── 測定条件をそろえずに数字を比べることの危うさ
一次情報出典
- Search Console Help: Index Coverage report
- Google Search Central: site: search operator
- Search Console Help: Inspect URLs
- Search Console Help: About Search Console data
- Search Console Help: Performance report
- Search Console Help: Crawl errors report
- Google Search Central: Search operators
- OWASP Benchmark Project: Reporting Format
