Chromeの検証ツールでブログのSEO設定を確かめる方法は？ソース表示・検証・URL検査の違い

記事のタイトルや説明文が設定どおりに入っているか、noindexが付いていないか、canonicalが正しいかを、自分で確かめたい。調べると「ページのソースを表示で見る」「検証ツールで見る」「Search ConsoleのURL 検査で見る」と、記事によって言うことが違う。しかも、ソースと検証で見え方が違うことがある。どれで見ればいいのか、違うときはどれを信じればいいのか、そこで止まっていませんか。

この記事は、その3つがそれぞれ何を見せているのかを公式の文書で確かめて、title・メタディスクリプション・robotsのnoindex・canonicalの4つを、どこで見ればよいかを並べたものです。4つそれぞれの意味や直し方は、すでに書いた記事に任せて、この記事では「見る場所」だけを扱います。

根拠にしたのは、Google Chrome ヘルプの「Chrome のキーボード ショートカット」、Chrome for Developersの「Chrome DevTools を開く」「DOM の表示と変更のスタートガイド」「Device Mode でモバイル デバイスをシミュレートする」、Search Console ヘルプの「URL 検査ツール」、Google 検索セントラルの「JavaScript SEO の基本を理解する」「rel="canonical" などを利用して正規ページを指定する方法」「Robots meta タグ、data-nosnippet、X-Robots-Tag の設定」で、2026年10月10日に日本語版と英語版の原文で確かめました。画面の名前とキーボードの近道は、どれも公式の文書の日本語版の字のまま書いています。この記事のために実際の画面では確かめていないので、Chromeの版や表示の言語によっては、名前が違って見えることがあります。

結論:3つは、同じページの別のものを見せている

原文を読んで、ブログで押さえておきたいことは次の5つです。

• ソースの表示は、サーバーが返したHTMLのソースコード。ブログの設定やプラグインが出力した文字が、そのまま並びます
• 検証([要素]パネル)は、ブラウザが組み立てたDOM。JavaScriptがあとから足したり変えたりしたものも入ります
• URL 検査は、Googleが取得したときの記録。ふだんの結果は直近にインデックスに登録された版で、いま公開している版とは限りません
• 4つの項目は、まずソースで見る。ソースと検証で違うなら、JavaScriptが書き換えています
• noindexのヘッダーは、ソースにも[要素]パネルにも出てこない。URL 検査で見ます。Googleが選んだ正規URLも、ブラウザでは分からないのでURL 検査で見ます

3つの見え方の違い

① ページのソース:サーバーが返したHTML

Chrome のキーボード ショートカット(Google Chrome ヘルプ。パソコン向けのページです)には、「現在のページの HTML ソースコードを表示する（編集不可）」という操作が載っていて、近道はWindowsとLinuxが「Ctrl+U」、Macが「⌘+option+u」です。開いたページの中を探すときは、同じヘルプの「現在のページ内を検索する検索バーを開く」(Windowsは「Ctrl+F または F3」、Macは「⌘+f」)を使います。

このサイトの他の記事では、ページを右クリックしたときのメニューの「ページのソースを表示」という呼び方を使ってきました。ただ、この項目名は、今回読んだ公式の文書には出てこず、この記事のために実際の画面でも確かめていません。確かめた字で書けるのは、上の近道のほうです。

ここに並ぶのは、ブラウザが受け取ったHTMLの文字そのものです。次の節で引くDevToolsの文書が「サーバーは HTML ドキュメントを返します」と書いている、そのHTMLにあたるもの、というのが私の整理です。ブログの管理画面で入れたタイトルや、SEOプラグインが出力したタグが、書かれた順に見えます。編集はできません。

② 検証:ブラウザが組み立てたDOM

Chrome DevTools を開くには、「検証するには、ページ上の要素を右クリックして [検証] を選択します。」とあり、続けて「DevTools の [要素] パネルが開き、DOM ツリー内の要素が選択されます。」と書かれています。メニューから開くなら[その他のツール] > [デベロッパー ツール]、キーボードなら次の近道です(表は原文の字のまま)。

ソースとの違いは、DOM の表示と変更のスタートガイドの付録「HTML と DOM」が説明しています。ページをリクエストするとサーバーはHTMLドキュメントを返し、ブラウザはそれを読んでオブジェクトの木(DOM)を作る、という流れです。違いはこう書かれています。

HTML は初期ページのコンテンツを表し、DOM はアクティブな現在のページのコンテンツを表します。JavaScript がノードを追加、削除、編集すると、DOM は HTML と異なるものになります。
— Chrome for Developers「DOM の表示と変更のスタートガイド」

つまり、①のソースと②の検証は、JavaScriptが何もしていなければ同じ中身で、JavaScriptが手を入れていれば違って見えます。[要素]パネルの中を探すときは、パネルにカーソルを合わせて「Ctrl+F キーまたは Command+F キー（macOS）」を押すと、DOMツリーの下に検索バーが開きます。なお、[要素]パネルでは「DOM をその場で編集し、その変更がページにどのように影響するかを確認できます。」とも書かれています。ここで書き換えて見えるのは、自分のブラウザで開いているページの中身で、ブログの記事の設定を直す場所ではない、と私は考えて使っています。

③ URL 検査:Googleが取得したときの記録

①と②は自分のブラウザで見たものですが、URL 検査ツールはGoogleの側の記録です。最初に出る結果は、いま公開しているページではなく、直近にインデックスに登録された版の情報です。その中身は「HTTP リクエストとレスポンス、返された HTML など、リクエストの詳細を確認するには、[クロール済みのページを表示] をクリックします。」と案内されています。いま公開している版を確かめたいときは、[公開 URL をテスト]を押し、結果の[テスト済みのページを表示]を開きます。インデックスの結果とライブテストで表示が違うときの読み方はURL検査のライブテストとは？インデックスの結果と違う表示が出たときの読み方にまとめました。

Googleが、①と②のどちらに近いものを見ているかについては、JavaScript SEO の基本を理解するが手がかりになります。Googleはページを「クロール」「レンダリング」「インデックス登録」の3つのフェーズで処理し、「Google のリソースに空きができると、ヘッドレスの Chromium がページをレンダリングして JavaScript を実行します。」と書かれています。そのうえで、「また、Google はレンダリングされた HTML を使用してページをインデックスに登録します。」とあります。

ただし、URL 検査の[クロール済みのページを表示]で見えるHTMLが、レンダリングの前と後のどちらなのかは、この記事では決めません。ヘルプは同じページの中で、その中身を「返された未加工の HTML」と書く一方、動画の節では、URL 検査ツールで「レンダリングされた HTML」を確かめるように書いていて、私が読んだ範囲ではどちらとも言い切れなかったからです。

3つを並べると

4つの項目を、どこで確かめるか

ここからが本題です。4つとも、まず①のソースを開いて、ページ内検索で探します。先に表で並べてから、1つずつ補足します。

title とメタディスクリプション

ソースで <title と name="description" を探し、管理画面で入れた文字が入っているかを見ます。JavaScript SEO の基本には「<title> 要素とメタ ディスクリプションは、JavaScript で設定または変更できます。」とあるので、ソースと検証で文字が違うなら、テーマやプラグインのJavaScriptが変えている、と読みます。URL 検査ツールのヘルプには、titleや説明文をそのまま表示する欄は出てきませんでした(私が読んだ範囲)。Googleが受け取ったものを見たいときは、[クロール済みのページを表示]で返されたHTMLの中を探します。

入っていることと、検索結果にそのまま出ることは別です。検索結果のタイトルが書き換えられていないかの確かめ方はGoogleにタイトルを書き換えられたときの対処、原因4つと直し方に、説明文の書き方と、書き換えられたときの見方はメタディスクリプションの意味と書き方、書き換えられたら本文の1段落目を直すに書きました。

robotsのnoindex

ソースで noindex を探します。見つからなくても、それで終わりにはできません。noindexはHTMLのmetaタグのほかにHTTPレスポンスヘッダーにも書けて、ヘッダーのほうはソースにも[要素]パネルにも出てこないからです。そこで、URL 検査の[ページのインデックス登録]の中の[インデックス登録を許可？]を見ます。ヘルプは、この欄が「ページでインデックス登録を明示的にブロックしているかどうかを示します。インデックス登録がブロックされている場合は、その理由が示されます。」と書いています。2つの置き場所と、入れた覚えのないnoindexの探し方は「noindexタグによって除外されました」は正常、直すのは意図と違うときだけにまとめました。

JavaScriptとの関係で気をつけたいのは、ソースにnoindexがあって、検証では消えている場合です。JavaScript SEO の基本は「Google が noindex タグを検出した場合は、レンダリングと JavaScript の実行がスキップされる可能性があります。」と書き、続けて「つまり、JavaScript を使用して noindex の robots meta タグを変更または削除しても、想定どおりに動作しない可能性があります。ページをインデックス登録する場合は、元のページコードで noindex タグを使用しないでください。」としています。検証ではnoindexが消えて見えても、元のHTMLに残っていれば、Googleには消えたものとして届かない可能性がある、と私は読んでいます。なお、Robots meta タグの説明には「注: Google 検索では、必ずしも HTML の head にメタ robots を配置する必要はありません。HTML ドキュメントの body セクションにある robots メタタグも尊重します。」とあるので、ソースではhead以外の場所も含めて探します。

canonical

ソースで rel="canonical" を探し、指している URL が、その記事自身の URL(または自分が代表にしたい URL)になっているかを見ます。こちらはnoindexと違って、置き場所が決まっています。rel="canonical" などを利用して正規ページを指定する方法には「rel="canonical" link element は、HTML の <head> セクションに指定されている場合にのみ受け入れられるため、少なくとも <head> セクションが有効な HTML であることを確認してください。」とあります。JavaScriptで変える場合について、JavaScript SEO の基本は「正規 URL を設定する最善の方法は HTML を使用することですが、JavaScript を使用する必要がある場合は、正規 URL を常に元の HTML と同じ値に設定してください。」と書いています。ソースと検証でcanonicalの URL が違うなら、この書き方から外れています。

URL 検査では、「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」の2つの欄を見ます。前者は自分が出している指定、後者はGoogleが実際に選んだURLです。前者について、ヘルプは「正規 URL を指定する方法は複数あり、<link rel="canonical"> タグ、HTTP ヘッダー、サイトマップ、またはその他の方法で指定できます。」と書いているので、ソースに無い指定がここに出ることもあります。後者については「正規バージョンは、インデックス登録されたデータからのみ確認できます。ライブテストでは、テスト対象のバージョンが正規バージョンになるかどうかを予測することはできません。」とあり、ブラウザのソースや検証では分かりません。2つが違うときの見分け方は「ユーザーがマークしたページとは異なるページが正規ページとして選択されました」の対処に、canonicalそのものの考え方はcanonicalタグの使い方、重複コンテンツと、指定が効かない理由に書きました。

WordPressでSEOプラグインを入れていると、titleやcanonicalがテーマとプラグインの両方から出て、ソースの中に2つ並ぶことがあります。何を検索して何個あれば正常かはWordPressのSEOプラグインは必要？二重出力をソースで確かめるで表にしています。

私が見ている順番

ここから先は、このサイトのやり方です。Googleが決めた手順ではありません。記事を公開したときと、タイトルや説明文を直したときに、次の順で見ています。

1. ログインしていない状態で記事を開き、ソースを表示して、4つの項目を探す。管理画面で直した直後は、古いページが出ないように、DevToolsを開いた状態でハード再読み込み(「Ctrl+Shift+R（Windows/Linux）」、Macは「Cmd+Shift+R（macOS）」)をしてから見る
2. ソースの中身が思っていたものと違う、または見つからないときだけ、検証の[要素]パネルで同じ文字を探し、JavaScriptが変えていないかを見る
3. Search ConsoleのURL 検査で、[インデックス登録を許可？]と、2つの正規 URL の欄を見る。直したばかりなら[公開 URL をテスト]で、いまの版も見る
4. 翌月、検索パフォーマンスの数字で、直した記事の表示回数とクリック率が変わったかを見る。直す記事を選ぶときは、平均掲載順位が4.0〜20.5位あたりの記事から見ている

1つ目の「ハード再読み込み」は、Chrome DevTools を開くのページに「ハード再読み込み。キャッシュをバイパスしますが、キャッシュは空になりません。」と書かれている再読み込みです。これはブラウザのキャッシュを使わずに読み直すもので、ブログの側(サーバーやキャッシュ系のプラグイン)が古いページを返しているときは、そちらのキャッシュを消す必要がある、と私は考えています。ログインしていない状態で見るのは、ログイン中だけ表示が変わるブログがあるためで、これも私のやり方です。

4つ目の「4.0〜20.5位あたり」は、このサイトのツールが判定に使っている範囲で、私の基準です。1〜3位はもう上のほうにいるので外し、20.5位より後ろは、このサイトが使っている期待CTRの出典の表が20位までで、数字で判断できないので外しています。

よくある質問

「ページのソースを表示」と「検証」は、どちらを使えばいいですか

私は、4つの項目を確かめるときは先にソースを見ます。ソースは元のHTMLで、ブログの設定やプラグインが出力したものがそのまま並ぶからです。検証は、JavaScriptが手を入れた後の姿なので、ソースと違うときに、何が変わったのかを見るために使います。

ソースにnoindexが無いのに、URL 検査ではブロックされていると出ます

noindexはHTTPレスポンスヘッダーにも書けて、そちらはソースに出てきません。もう1つは、URL 検査の最初の結果が、直近にインデックスに登録された版の記録だということです。外したあとなら、[公開 URL をテスト]で、いまの版を確かめます。

スマホだけで確かめられますか

今回読んだChromeの公式の文書は、パソコン向けのページで、スマホのChromeでソースを見る方法は書かれていませんでした。パソコンで、スマホでの見た目を確かめる機能なら、DevToolsのデバイスモードがあります。Device Mode でモバイル デバイスをシミュレートするは「デバイスモードを使用すると、モバイル デバイスでページがどのように表示され、動作するかを概算で確認できます。」と書いていて、開き方は、DevToolsの上部のアクション バーにある「デバイス ツールバーの切り替え」を押す、という説明です。Search Consoleのモバイル ユーザビリティ レポートが無くなったあとの確かめ方はサーチコンソールのモバイルユーザビリティは廃止されましたに書きました。

検証で書き換えたら、ブログの記事も変わりますか

[要素]パネルで書き換えられるのは、いま自分のブラウザで開いているページのDOMです。ブログの管理画面に保存されている記事を直すものではない、と私は理解して使っています。タイトルや説明文を直すときは、ブログの管理画面かプラグインの設定で直し、そのあとソースで確かめます。

URL 検査で、titleやメタディスクリプションを確かめられますか

私が読んだURL 検査ツールのヘルプには、titleや説明文を表示する専用の欄は出てきませんでした。[クロール済みのページを表示]で見えるHTMLの中を探せば、Googleが受け取ったものを確かめられます。検索結果にどう出ているかは、実際に検索して見ます。

まとめ

• ソースの表示は、サーバーが返したHTMLのソースコード。Chromeヘルプの字は「現在のページの HTML ソースコードを表示する（編集不可）」で、近道はCtrl+U(Macは⌘+option+u)
• 検証([要素]パネル)はブラウザが組み立てたDOMで、JavaScriptが手を入れると元のHTMLと違うものになる
• URL 検査はGoogleが取得したときの記録。最初の結果は直近にインデックスに登録された版で、いまの版は[公開 URL をテスト]で見る
• Googleはレンダリングされた HTML を使ってページをインデックスに登録する、と公式の文書にある
• title・メタディスクリプション・canonicalは、まずソースで探し、検証と違えばJavaScriptが変えている
• noindexのヘッダーはソースにも[要素]パネルにも出ないので、URL 検査の[インデックス登録を許可？]で見る。Googleが選んだ正規 URL は、ブラウザのソースや検証では分からないので、URL 検査で見る

どれで見ればいいか迷ったら、自分が知りたいのが「ブログが何を出しているか」なのか、「Googleが何を受け取ったか」なのかを先に決めます。前者はソースと検証で、後者はURL 検査で分かります。

4つの項目が正しく入っていても、その記事が検索結果でクリックされているかは別の話で、どの記事のタイトルと説明文から見直すかは、Search Consoleの数字で切り分けます。その切り分けのために私が作ったツールがあるので、ここから宣伝として書きます。

Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。診断カードのためにページを取りに行くときに読むのは、title・メタディスクリプション(無ければog:description)・h1〜h3の見出し・本文・本文中の画像のaltで、JavaScriptは実行しません。この記事の言い方でいえば、①のソースの側を読んでいます。このツールは、noindexもcanonicalも読みません。URL 検査の結果も見ないので、インデックスに登録されているかどうかは、Search Consoleで確かめてください。並び順に使う「CTR機会差(回相当)」は、表示回数に、同じ順位帯の期待CTRと実際のCTRの差を掛けた比較の値で、点数ではありません。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。