WEBサイト
「大げさ」と片付けたものの中に、本当に遅いページは無かったか
毎朝6時に、当サイトの点検ツールがサイトマップの全ページを巡回して、報告を出す。リンクの状態、ステータス、検索まわりの設定、説明文の長さ、そして応答の速さ。いくつもの項目を一度に見てくれる、自社のツールだ。この報告を開くのが、毎朝の習慣になっている。
この記事は、9月24日に公開したarchives/146の続きである。archives/146では、毎朝の警告の合計「1,415件」を初めて種類別に数え直し、9割台後半は対応が要らないものだと分かった、と書いた。そして、その記事の終わりで、宿題を2つ残した。
- 「遅い」と報告されたページを自分で測り直したところ、1本だけ2.37秒が残った。原因が分からなかったので、「確かめてから直す」と書いた。
- 報告された速さと、自分で測り直した速さを、全ページ分、自動で並べる仕組みが無い。これは「まだ用意していない」と書いた。
この2つは、9月29日から30日にかけて片付いた。その記録が、この記事だ。
先に結論を書く。警告の数え方を直して点検し直すと、1,440件あった警告は2件になった。残った2件は本物の不具合だったので、直して0件にした。もう一つの結論は、少し苦い。archives/146で「報告された遅さは大げさだ」と判断したのは正しかった。ところが、「だから実際は速い」わけではなかった。記事ページは、1本ずつ測っても1〜4秒かかっていたのだ。
毎朝の点検ツールやサイト監視の警告を受け取っているWEBディレクターが、明日、自分のサイトで確かめられることを書いていく。警告の山の中に、本物が埋もれていないか。「点検ツールの測り方のせいだ」と片付けたものの中に、本当に遅いページが無いか。この2つの問いが、この記事の軸になる。
9月29日の朝、警告は1,440件になっていた
9月29日の朝6時の報告で、警告の合計は1,440件だった。この合計は毎日出る。archives/146で書いたとおり、合計が毎日出ていると、内訳を見に行く理由が消えてしまう。その日は、ナミオさんから、毎朝の点検の報告を詳しく調べて、見つかったことにはすべて対応してほしい、と頼まれていた。だから、まず内訳を開いた。
種類別に数えると、5つに分かれた
報告の一覧を、警告のラベルごとに数えた。次の表のとおりだ。
| 警告の種類 | 件数 | 中身 | 最初の見立て |
|---|---|---|---|
| 検索避け（noindex） | 963件 | 検索結果に出さないと決めているページ | 意図どおりのもの |
| canonicalの不一致 | 288件 | ページが宣言した正規URLと、点検ツールが持っていたURLが違う | 比べ方に原因が無いか、確かめる必要があるもの |
| 遅い | 228件 | 応答が遅いという報告 | 本物か、測り方の影響かを、分けて確かめる必要があるもの |
| 説明文の長さ | 25件 | 検索結果に出る説明文が、目安から外れている | 一部はページ側を確かめる必要があるもの |
| h1の数 | 2件 | ページの最上位の見出し（h1）の数が適切でない | ページ側を確かめる必要があるもの |
件数でいちばん多い963件は、検索避けの設定が入っているページだ。これは、当サイトが意図して入れているものが大半で、警告と呼ぶこと自体が、少し的外れだった。Search Consoleの「ページのインデックス登録」レポートの説明にも、同じ趣旨の一文がある。
“It's fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you've removed and have no replacement for.”
（日本語訳: 正しい理由で、URLがインデックスされていないのは問題ない。たとえば、サイトに想定どおりのrobots.txtのルールがある、ページにnoindexタグが入っている、URLが重複している、削除して代わりのページが無いページが404になっている、といった場合だ）
この説明は、Googleが公開しているSearch Consoleヘルプの「ページのインデックス登録レポート」にある。インデックスされていないことと、問題があることは、同じ意味ではない。レポートの読み方については、ページのインデックス登録レポートは18ステータスに分かれる ── 対処が要るかどうかを確認する13項目（2026年9月時点）に、確認する項目をまとめてある。
表の件数を足してみると、963 + 288 + 228 + 25 + 2 で、1,506件になる。報告の合計は1,440件なので、66件、多い。1つのページが複数の種類に当てはまることがあるためだろうと考えている。ただし、ページごとに突き合わせて確かめたわけではないので、これは推測だ。
この「足すと合わない」という小さな違和感は、役に立つ。内訳の件数を足して、合計と比べる。合わなければ、数え方に何か前提がある、というサインになる。合計だけを毎日見ていたら、この違和感にも出会えなかった。
種類別に数える作業そのものは、大げさな準備を要らない。点検ツールが書き出す一覧を、表計算ソフトに貼り付けて、警告のラベルの列で集計すれば、種類別の件数が出る。ラベルの列が無い出力なら、警告の文言の先頭の数文字で振り分けるだけでも、粗い内訳にはなる。大事なのは、きれいな表を作ることではない。合計の中に、性質の違うものが混ざっていると、自分の目で一度見ることだ。
点検ツールの数え方を、4つ直した
種類別に並べてみると、ページの問題より、数え方の問題のほうが目立っていた。そこで、ページに手を入れる前に、点検ツール側の数え方を4つ、見直した。
1つ目: 転送されるページは、転送先で点検する
別のURLへ自動で移動させる設定（転送）が入っているページがある。そのページに届いた応答は、転送先のページの応答ではない。archives/146で書いた「ページA」は、まさにこの形だった。報告では11.1秒だったが、転送先まで含めて測り直すと0.10秒だった。
読者が最終的に着くのは、転送先のページだ。転送元の応答や説明文を点検して警告を出しても、読者が見ているものを見ていない。そこで、転送されるページは、転送先のページで点検する形に変えた。
2つ目: URLの書き方を揃えてから比べる
canonicalは、「このページの正規のURLは、これだ」とページ自身が宣言する仕組みだ。点検ツールは、その宣言が、ページ自身のURLと一致しているかを確かめる。archives/146で扱った350件は、半角スペースを含むタグ名のページで、スペースを「%20」と書いた形と、そのまま書いた形が、1文字も一致しないために、違うと判定されていた。
URLの書き方の決まりについて、MDN Web Docsの用語集には、次のように書かれている。
“Percent-encoding is a mechanism to encode 8-bit characters that have specific meaning in the context of URLs.”
（日本語訳: パーセントエンコーディングは、URLの中で特別な意味を持つ8ビットの文字を、符号化する仕組みだ）
同じ場所を指しているのに、書き方が違うだけで「不一致」になる。そこで、比べる前に、両方のURLの書き方を揃える形に直した。canonicalの考え方そのものは、Google検索セントラルの説明にある。
“rel="canonical" link annotations: A strong signal that the specified URL should become canonical.”
（日本語訳: rel="canonical"のリンク注釈は、指定したURLを正規のURLにすべきだという、強いシグナルだ）
「強いシグナル」ではあるが、命令ではない。この点は、canonicalタグは『ヒント』であって『命令』ではない ── Search Consoleで、Googleが選んだ正規URLを自分のサイトで確認するに、確かめ方をまとめてある。
3つ目: 検索避けのページは、警告ではなく情報にする
963件を占めていたnoindexのページは、サイトマップに載せていないページを、「意図どおり」として扱う形にした。警告ではなく、「情報」として一覧に残す。noindexのページの説明文の長さも、同じ扱いにした。検索結果に出さないと決めているページの説明文は、短くても読者の目に触れないからだ。
この扱いに、条件は付けてある。「サイトマップに載せていないこと」だ。検索結果に出したいページを、サイトマップに載せる。だから、載せていないページが検索避けになっているのは、意図どおりだと読める。noindexの働き方そのものは、Google検索セントラルのnoindexの説明にまとまっている。
見えなくしたわけではない。「警告」から「情報」に下げただけで、一覧には残っている。
4つ目: 遅いと出たページは、1本ずつ測り直す
点検ツールは、全ページを並行して測っている。大量のページを立て続けに測れば、測る側が詰まって、遅い値が出ることがある。archives/146で、手作業で3本だけ測り直したのは、この疑いを確かめるためだった。
これを、手作業ではなく、点検ツールの仕事にした。並行して測っている間に、遅いと出たページがあれば、そのページだけを、1本ずつ測り直す。報告には、並行して測った値と、測り直した値の両方を並べて載せる。そして、警告にするかどうかの判定は、測り直した値で行う。archives/146の終わりで「まだ用意していない」と書いた仕組みが、これだ。
直したら、警告は1,440件から2件になった
数え方を4つ直した点検ツールで、同じサイトを点検し直した。警告は、1,440件から2件になった。
警告の山が消えたのではない。意図どおりのものは「情報」に下げ、書き方の違いによる不一致は揃えて比べ、遅いという報告は測り直した。山の中にあった、本物だけが、警告として残った。
残った2件は、本物だった
残った2件は、タグの名前に「&」の文字を含むページだった。そのページのcanonicalが、二重にエスケープされていた。「&」は、HTMLの中では「&」と書く決まりになっている。それが、もう一段、重ねてエスケープされて、「&」のような形で出ていたのだ。
HTMLの中で、特別な意味を持つ文字を書くための書き方を、文字参照という。MDN Web Docsの用語集には、こう書かれている。
“These use a name string between an ampersand (&) and a semicolon (;) to refer to the corresponding character.”
（日本語訳: 名前付きの文字参照は、アンパサンド（&）とセミコロン（;）の間に名前の文字列を置いて、対応する文字を指す）
この決まりに従うと、エスケープを二重に重ねたものは、ブラウザや検索エンジンからは「&」という文字そのものとして読まれる。ページが宣言する正規のURLが、実際のURLと、違う文字列になってしまう。直し方は、重なっていたエスケープを1回に戻したうえで、URLの中の「&」は「%26」という符号で書く形にすることだった。MDN Web Docsのパーセントエンコーディングの説明にも、「&」は符号化が要る文字として挙がっている。
このタイプの不具合は、構造化データのような別の場所でも起きうる。JSON-LDのHTMLエスケープは、1回しか解除されなくなった ── 自分のサイトに二重エスケープが残っていないか確認する13項目（2026年9月時点）に、確認の項目をまとめてある。
この2件は、おそらく、canonicalの288件の中にあった。数え方を直す前は、288件の山の中で、他と同じ顔をして並んでいたと考えている。山の中のどれが本物かは、山を小さくして初めて見えた。
ここで言う「本物」は、次の問いに「はい」と答えられるものだ。読者が見る画面や、検索結果に出る内容に、実際に影響しているか。影響していないものは、直しても読者の役には立たない。意図どおりのものや、書き方の違いによる不一致は、この問いに「いいえ」と答える。残った2件は、検索エンジンが読む情報が、実際のURLとずれていたので、「はい」だった。
ページ側で直した、ほかの3つ
点検の一覧を見直す中で、ページ側にも、直すべきものが3つ見つかった。
- AI対応診断のページの説明文が、344字あった。途中に改行が混ざっていて、古い本数も書かれていた。144字に直した。
- サイト内検索のページに、h1が2つあった。2つ目を別の要素に変えた。見た目は、これまでと同じままにしてある。
- 過去のブログ1本の本文の冒頭に、題名と同じh1が重複していた。本文側のh1を外した。
3つとも、小さな問題だ。ただ、小さな問題は、大きな数字の陰では、見つける動機が生まれにくい。警告の山を片付けたことで、初めて、3つとも「対応しよう」と思える大きさで目に入った。
「報告は大げさ」は正しかった。だが、「だから速い」ではなかった
並列で測るから遅く出る、までは正しかった
archives/146では、報告された遅さのページA・Bを測り直した。報告は11.1秒と9.1秒で、測り直すと0.10秒と0.46秒だった。大量のページを立て続けに測っていることが、遅い値を押し上げている可能性がある、とも書いた。ただし、それは自分では検証できていない仮説で、断定はしない、と書き添えている。
点検ツールに、測り直しの仕組みを入れて、この仮説は確かめられた。「報告の数字は大げさだ」という判断は、正しかった。まとめて測った数字は、実際より遅く出る。ここまでは、archives/146で書いたことが、そのまま裏付けられた。
1本ずつ測っても、記事ページは1〜4秒だった
ところが、測り直しの仕組みを動かして、ページの種類ごとに並べてみると、別のものが見えた。1本ずつ測っても、記事ページは1〜4秒かかっていた。固定ページ（サイトの紹介や規約のような、記事ではないページ）は、0.06秒前後だった。
並列のせいではなかった。1本ずつ、静かに測っても、記事ページだけが遅い。報告は大げさだったが、大げさだった部分を差し引いても、遅さは残っていた。archives/146のページCの2.37秒は、この1〜4秒の範囲に入る。ただし、ページCそのものの原因を確かめたわけではないので、同じ原因だったと言い切ることはできない。
「大げさ」と片付けた判断は、正しかった。しかし、その判断が、「だから遅いページは無い」という結論にまで、広がっていた。判断の範囲が、根拠の範囲より、広かった。
9月24日に比べる相手にしたページは、どの種類だったか
archives/146では、測り直した値の意味を見るために、問題視されていない通常のページを2本選んで、並べた。0.87秒と1.02秒だった。「普通のページは、1秒前後だ」という物差しを、ここで作った。
今回、記事ページが1〜4秒、固定ページが0.06秒前後だと分かってみると、あの比べる相手のページが、どちらの種類のページだったかが気になる。もし記事ページだったなら、「普通」として置いた1秒前後が、すでに遅い側の数字だったことになる。当時の記録からは、比べる相手のページがどの種類のページだったかを、確かめられていない。これは、確かめられていないこととして、ここに書いておく。
確かめられたのは、教訓のほうだ。比べる相手のページは、1種類だけ選ぶのではなく、ページの種類ごとに選ぶ。固定ページと記事ページが混ざった平均を物差しにすると、遅い種類のページが、平均の中に隠れてしまう。
種類の分け方は、難しく考えなくていい。ページを作っている仕組みごとに分ければ足りる。記事を表示する仕組みのページ、固定ページ、一覧のページ、ツールのページ。表示のために走る処理が違うページは、遅さの原因も違いやすい。1種類につき数本ずつ、3回ほど測って、ばらつきも見る。それだけで、「記事ページだけ遅い」というような偏りは、見つかる。
遅さの原因は、用語に説明を付ける表示の仕組みだった
記事ページにだけある処理を、順に疑った。正常に動いて、エラーも警告も出さずに、ただ少し遅いだけの処理は、報告に出ても「並列のせいだろう」と片付けやすい。だから、見つけるには、疑う場所を決めて、1つずつ測るしかなかった。当サイトの記事には、専門用語に印を付けて、押すと説明が出る仕組みがある。記事の中の用語を、辞書の語と照らし合わせて、見つかった語に印を付ける。読者のための機能だ。
処理ごとに、時間を測る
test環境で、記事ページを表示するときの処理を、1つずつ、時間を測った。すると、用語に説明を付ける処理だけで、0.9〜1.0秒かかっていた。記事ページの応答時間の大半を、この処理が占めていた。
サーバー側の処理ごとの時間を、ブラウザの開発者ツールで見られるようにするための、標準の仕組みもある。HTTPのServer-Timingヘッダーだ。MDN Web Docsには、次のように書かれている。
“The HTTP Server-Timing response header communicates one or more performance metrics about the request-response cycle to the user agent.”
（日本語訳: HTTPのServer-Timingレスポンスヘッダーは、リクエストとレスポンスのやり取りに関する1つ以上の性能の指標を、ユーザーエージェント（ブラウザなど）に伝える）
どの方法で測るかは、環境によって違う。大事なのは、ページの応答が遅いと分かったら、「どの処理が、どれだけ」を、処理ごとに分けて測ることだ。「記事ページが遅い」という粗い観察のままでは、直す場所が決められない。
毎回、探していた
用語に説明を付ける処理は、辞書にある約860の語を、記事の本文の区切りごとに、探していた。語の数と、本文の区切りの数（数百ある）を掛け合わせると、1ページを表示するたびに、十万回を超える探し物になる。しかも、それを、ページを開くたびにやり直していた。
辞書は、育てるほど語が増える。語が増えれば、探す回数も増える。辞書を育てるたびに、読者の待ち時間が、静かに伸びていく形になっていた。
直したのは、次の2つだけだ。
- 語の並べ替えを、1回で済むようにした。
- その本文の区切りに含まれない語は、探す前に、先に除くようにした。
辞書の中身にも、記事の本文にも、手は入れていない。探し方を変えただけだ。
直したあと、表示は同じと確かめる
速くなったように見えて、実は、印を付ける語が減っていた、という直し方をしてしまうと、読者の画面から機能が消えたことになる。速さの直しで、いちばん怖いのは、速くなった理由が、「やるべき仕事を、やらなくなったから」である場合だ。
そこで、直す前と直した後で、表示されるHTMLを、そっくり比べた。test環境の40ページと、本番の25ページで、前後のHTMLが一致していることを確かめた。出力が同じだと確かめたうえで、速さだけを変えた、と言える。
比べ方は単純だ。直す前に、対象のページのHTMLを保存しておく。直した後に、同じページのHTMLを保存して、文字単位で突き合わせる。1文字でも差が出たら、それが意図した変化か、意図していない変化かを見る。更新日時のように、表示のたびに変わる文字が混ざるページは、その部分を除いてから比べる。全部が一致すれば、機能は変わっていないと分かる。
直す前と後の数字を、表にまとめる。
| 項目 | 直す前 | 直した後 |
|---|---|---|
| 警告の数 | 1,440件 | 2件（本物）、直して0件 |
| 点検ツールの平均応答時間 | 0.571秒 | 0.159秒 |
| いちばん遅いページ | 9.875秒 | 0.990秒 |
| 本番の記事ページ | 1〜4秒 | 0.1〜0.27秒 |
| ある解説記事（本番） | 3.99秒 | 0.25秒 |
それでも、いちばん遅いページは、まだ0.990秒ある。Googleのweb.devには、サーバーの応答の速さについて、次のような目安が書かれている。
“As a rough guide, most sites should strive to have a TTFB of 0.8 seconds or less.”
（日本語訳: おおよその目安として、ほとんどのサイトは、TTFB（最初の1バイトが届くまでの時間）を0.8秒以下にするよう努めるべきだ）
当サイトで測っているのは、点検ツールが応答を受け取るまでの時間で、web.devのTTFBと同じ測り方かどうかは、確かめていない。だから、この目安は、厳密な比較としてではなく、感覚をつかむための物差しとして並べておく。同じページに、TTFBはCore Web Vitalsの指標そのものではない、という注意書きもある。表示速度の指標の読み方は、Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目に、確認する項目をまとめてある。
翌朝の報告は、「解消」で埋まっていた
10月1日の朝の報告は、次のようになった。点検したのは1,974ページ。警告は0件、エラーは0件、情報は1,079件。平均の応答時間は0.152秒、いちばん遅いページは0.792秒だった。
前日との差分には、「解消」が1,484件、並んだ。一方で、新しく出たものが1,053件ある。新しく出た1,053件は、ほとんどが「意図どおりのnoindex」という情報だ。数え方を変えたので、前日と今日で、同じ物差しで測っていない。差分が大量に出るのは、数え方を変えた日の翌日の、正常な姿だった。
この差分の山を見て、「何か壊れた」とも「すごく良くなった」とも、読んではいけない。差分を読むときは、最初に、前日から数え方を変えたかどうかを確かめる。変えていたなら、差分の数は、サイトの変化ではなく、数え方の変化を映している。
そして、今度は「情報1,079件」という新しい合計が、毎朝出る。この合計も、合計だけを見続ければ、同じ穴が開く。archives/146で書いた教訓は、この新しい数字にも、そのまま当てはまる。
警告0件という数字にも、注意がいる。0件は、「問題が無い」ではなく、「この数え方では、問題が見つからなかった」という意味だ。数え方を直したばかりの点検ツールの0件は、特にそうだ。数え方に穴が残っていれば、0件のまま、問題だけが増えていく。archives/130で書いた「0件は安心ではない」という考え方は、ここでも変わらない。警告0件を見たときこそ、点検の項目に何が入っていて、何が入っていないかを、確かめ直す。
自分のサイトで、明日からできること
ここまでの話を、自分のサイトの点検に持ち帰るための手順にする。使うツールは、毎朝の点検ツールでも、無料の診断ツールでも構わない。専用の点検ツールが無いサイトでも、この確認はできる。必要なのは、一覧を書き出せることと、ページの応答時間を何回か測れることだけだ。測るのは、ブラウザの開発者ツールでも、無料の計測サービスでも構わない。
手順1: 月に1回、警告を種類別に数える
合計だけを毎日見ていると、内訳を見に行く動機が消える。月に1回は、警告をラベルごとに数え直して、表にしておく。前の月と並べると、どの種類が増えて、どの種類が減ったかが分かる。表の形は、毎月、同じにしておく。形が変わると、並べて比べられなくなる。Search Consoleの警告の読み方に迷うときは、当サイトの🔧 Search Consoleの項目を、もう少し詳しく知りたいときのお助けツールが手がかりになる。
手順2: 種類別に、意図どおりのものと本物を分ける
種類別に分けたら、次は、「意図どおりのもの」と「本物」を分ける。意図どおりのものを、警告のまま残してはいけない。本物が、意図どおりのものの中に埋もれる。意図どおりのものは、「情報」のような、別の棚に移す。移したあとも、一覧には残しておく。そして、なぜ意図どおりと判断したのかを、一行、書き残しておく。半年後にその一覧を開いた人が、警告に戻すべきかどうかで、迷わずに済む。
数え方を変えたら、翌日の差分に注意する。差分が大量に出るのは、サイトの変化ではなく、数え方の変化かもしれない。先に、数え方を変えたかどうかを確かめる。
手順3: 「点検ツールのせい」と判断する前に、ページの種類ごとに1本ずつ測る
遅いという警告が出たとき、並列で測っているから大げさだ、と判断するのは、半分は正しい。残りの半分を確かめるために、遅いと報告されたページを、1本ずつ測り直す。そのとき、比べる相手のページも、ページの種類ごとに用意する。記事ページと固定ページ、一覧ページと詳細ページのように、種類を分ける。種類を混ぜた平均を物差しにすると、遅い種類が隠れる。ページの総合的な診断は、当サイトの🔧 サイト全体をまとめて分析して、レポートにするツールでも見られる。
手順4: 速さを直したら、前後のHTMLを比べる
速さを直したら、直す前と直した後で、表示されるHTMLをそのまま比べる。速くなった理由が、仕事を減らしたことでは、困る。比べるページは、ページの種類ごとに数本ずつ選べば足りる。直した後は、リンクが壊れていないかも確かめておくと安心だ。当サイトの🔧 サイト内のリンク漏れをチェックするツールで、直したあとのリンク切れを洗い出せる。
自分で作った点検ツールと、市販・無料のツールは、警告の出し方が違う
ここまでは、自分で作った点検ツールの数え方を直した話だった。では、世の中にあるツールは、検索避けのページをどう扱うのだろうか。公式の説明を開いて、確かめられた範囲を表にした。
| ツール | 何を見るか | 警告の出し方（noindexなど、意図どおりのもの） | 速さの測り方 |
|---|---|---|---|
| 自社で作った点検ツール | サイト内の全ページの状態（転送・canonical・説明文・見出し・応答時間） | 当サイトでは、サイトマップに載せていないnoindexのページを「情報」に下げた。どう扱うかは、作った側が決められる | 並行して測ったあと、遅いページだけ1本ずつ測り直す形にした |
| Google Search Console（ページのインデックス登録レポート） | Googleがページをインデックスに登録したか、登録されなかった理由 | noindexのページは、「Not indexed」の中に「URL marked 'noindex'」という名前で出る。公式ヘルプには、正しい理由で登録されていないのは問題ない、という説明もある | このレポートの説明では、速さの測り方は確かめられなかった |
| Lighthouse（PageSpeed Insights） | 1ページごとの診断。パフォーマンス、アクセシビリティ、SEO、ベストプラクティスの各カテゴリ | SEOカテゴリに「Page is blocked from indexing」という確認項目があり、すべてのクローラーを止めるnoindexが入っていると、この項目は不合格になる。特定のクローラーだけに向けた指定は、不合格にしない、とも書かれている | 指標の値を0〜100の点数に変換する。測り方の条件（回線の速さの想定など）は、開いた公式ページでは確かめられなかった |
| Screaming Frog SEO Spider | サイトを巡回して、URLごとに、インデックスできるか（Indexability）とその理由（Indexability Status）などを一覧にする | noindexのページは、巡回はされるが、インデックスからは外れる、と説明されている。警告として数えるか情報として数えるかは、開いたページでは確かめられなかった | 「Response Time」は、URLをダウンロードするのにかかった秒数 |
ツールごとにnoindexの出方は違うが、どれも「悪いこと」と決めているわけではなく、そのページが検索に出ない状態だと知らせている。入れたnoindexが意図どおりか、確かめるのは、サイトを持つ側の仕事だ。Search Consoleなら、ページのインデックス登録レポートで「URL marked 'noindex'」の一覧を開き、検索結果に出したいページが混ざっていないかを見る。
結論は、どのツールが良いか、ではない。どのツールでも、意図どおりのものを警告から外す設定や数え方を、先に確かめる。そのうえで、残った警告だけを本物として見る。サイト内のリンクの状態を無料で確かめたいときは、この記事の手順の中でも紹介した、リンクのチェックのツールが使える。
当サイトの現在地
この記事で書いたことについて、当サイトの現在地を、正直に書く。
- archives/146で宣言した、遅いと報告されたページの原因を確かめて、直した ✅ 実施済み
- archives/146で宣言した、報告された値と、1本ずつ測り直した値を、自動で並べる仕組み ✅ 実施済み
- 警告を種類別に分けて、意図どおりのものを「情報」に下げた ✅ 実施済み
- 点検ツールは、外部のサイトへのリンク切れの確認を、毎朝の巡回では止めている（時間がかかるため）。外部リンクの確認を、別の頻度で回す形を、これから作る 🔧 これから作る
最後の1つは、未着手だ。毎朝の点検の中に、外部サイトへのリンクの確認は入っていない。内部の警告が片付いた今、次に手を付ける場所として、ここが見えてきた。
もう一つ、書いておく。今回の速さの直しは、用語に説明を付ける仕組みを速くしただけだ。記事ページが、まだ0.1〜0.27秒かかる理由の内訳までは、分けて確かめていない。0.990秒のページが、なぜほかより遅いのかも、まだ見ていない。直した、とは書けるが、もう十分に速い、とは書けない。
関連 archives（連載軸として読む）
- archives/146「毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかった」 ── この記事の元になった、9月24日の記事。ここで残した2つの宿題を、この記事で回収した
- archives/143「「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった」 ── 合計を分けたら、別のものが出てきた先例（2026-09-11）
- archives/130「「0件」は安心ではない、「N件」は危険ではない ── 同じ1日に、サイトを調べる針が両方向に倒れた」 ── 数字の大きさと、危険度は、別々に確かめる、という考え方
- archives/128「出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴」 ── 出ているものを、内訳まで見に行かなかった話（2026-08-18）
- archives/117「同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったこと」 ── 比べる前に、条件を揃える話（2026-07-17）
- archives/149「「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）」 ── 測る道具のほうを先に疑った、翌日の記事（2026-09-30）
出典
- Google Search Consoleヘルプ: ページのインデックス登録レポート
- Google 検索セントラル: rel="canonical"などの方法で正規URLを指定する
- Google 検索セントラル: noindexで検索のインデックス登録をブロックする
- Chrome for Developers: Lighthouse の概要
- Chrome for Developers: Page is blocked from indexing
- Screaming Frog SEO Spider ユーザーガイド: タブ
- web.dev: Time to First Byte (TTFB)
- MDN Web Docs: Server-Timing ヘッダー
- MDN Web Docs: 文字参照（Character reference）
- MDN Web Docs: パーセントエンコーディング
