Chromeデベロッパーツールの使い方!スマホ表示・HTML編集・エラー確認

Takuma Oka

外資系SEOスペシャリスト

Takuma Oka (岡 拓馬)

こんにちは、岡 拓馬(おか たくま)です。
このブログでは、海外ノマド×SEO×ストック収入をテーマに、自分の経験や学びを発信しています。

高校卒業後は料理人としてスタートし、その後、航空自衛隊での勤務を経て、2016年からWebライター・SEOコンサルタントとして独立。現在は、海外の外資系企業と契約しながら、フルリモートで働いています。拠点はアジア各国を転々としており、最近はベトナムやタイ、マレーシア、フィリピンなどでノマド生活をしています。

  • 「表示が崩れている」
  • 「フォームが送信できない」
  • 「この画像だけ表示されない」

こうした報告を受けたとき、いきなり制作会社へ連絡する前に、自分で状況を切り分けられると仕事が一段速くなります。

そのための道具が、Chromeに最初から入っているデベロッパーツール(Chrome DevTools)です。追加インストールは不要で、右クリックの「検証」から今すぐ開けます。

ただし、はじめて開いた人のほとんどは、英語だらけの画面に圧倒されてそっと閉じます。原因はシンプルで、「どのタブが、どの疑問に答えてくれるのか」を知らないまま開いているからです。

Takuma

この記事では、タブの網羅的な解説ではなく、Web運用の現場で実際に発生する疑問から逆算して説明します。

\ サイト診断が無料で行えます!ぜひ試してみてください /

目次

Chromeデベロッパーツールとは?

デベロッパーツール画面

結論から言うと、Chromeデベロッパーツールは「今見ているWebページが、実際にどうなっているのかを調べるための検査ツール」です。

Takuma

ページを直す道具ではなく、状態を確認して原因を絞り込む道具だと考えてください。

Chromeに標準搭載されたWebページの検証ツール

Chromeデベロッパーツールは、Google Chromeに最初から組み込まれている機能です。

拡張機能のインストールも、アカウント登録も、費用も不要です。

確認できる主な内容は、次のとおりです。

  • HTMLの構造(見出し、リンク、alt属性、構造化データなど)
  • CSS(色、余白、文字サイズ、どのルールが効いているか)
  • JavaScriptのエラーや警告
  • サーバーとの通信内容(HTTPステータス、リダイレクト、読み込み時間)
  • スマホ・タブレット幅での表示
  • Cookie、Local Storage、キャッシュ
  • ページの表示速度や品質スコア

「エンジニア向け」という印象が強いツールですが、実際に日々使うのはSEO担当者、Web担当者、広告運用者、WordPressサイトの管理者といった非エンジニアです。

コードを書けなくても、状態を読み取るだけで十分に実用的だからです。

あわせて読みたい
SEOツール利用者ランキング2026|現役SEOコンサルが全部使って基礎の使い方まで解説 SEOツールの比較記事は世の中に山ほどありますが、その多くは「使ったことがないツールをカタログ的に並べただけ」です。 この記事は違います。紹介する8ツールはすべて...

Chrome DevToolsとデベロッパーツールは同じもの

検索していると複数の呼び方が出てきますが、指しているものは同じです。

表記補足
Chrome DevTools公式ドキュメントでの正式な呼び方
Chromeデベロッパーツール日本語記事で最も一般的
Chrome開発者ツールChromeメニュー内の日本語表記
検証(けんしょう)右クリックメニューの項目名
インスペクタ/Inspect英語UIでの呼び方

「検証を開く」も「DevToolsを開く」も「F12を押す」も、すべて同じ画面を開く操作です。

呼び方の違いで混乱する必要はありません。

なお、似た名前で「Chrome DevTools Protocol」「Chrome DevTools MCP」というものもありますが、これらは自動操作や外部ツール連携のための仕組みで、今回扱う手動の検証作業とは目的が異なります。この記事では触れません。

DevToolsはテスト環境ではない

ここが最も重要な前提です。

DevToolsで加えた変更は、原則としてページを再読み込みした時点で消えます。そして本番サイトには一切保存されません。

Chrome公式ドキュメントでも、Elementsパネルで行ったDOMツリーへの変更はDevToolsが保存しない、と明記されています(後述するLocal Overridesは例外的な仕組みです)。

つまり、DevToolsの役割は次の4つに整理できます。

  1. 状態の確認
  2. 一時的な編集(見た目のシミュレーション)
  3. 仮説検証
  4. 不具合の切り分け

実務での使い分けは、次の流れが基本です。

  1. DevToolsで仮説を試す
  2. ローカル環境で実際に修正する
  3. ステージング環境で本番前に確認する
  4. 本番へ反映する
項目Chrome DevToolsローカル環境ステージング環境本番環境
主な用途状態確認・一時編集・原因切り分けコードの実際の修正公開前の最終確認一般公開
変更の保存原則保存されない(再読み込みで消える)ファイルに保存される保存される保存される
影響範囲自分のブラウザの表示のみ自分のPCのみ関係者のみ全ユーザー
PHPやDBの修正できないできるできるできる
失敗したときのリスクほぼゼロ小さい中程度大きい
ポイント

DevToolsは壊す道具ではありません。何を触っても、再読み込みすれば元に戻ります。初心者ほど「触ってはいけない」と身構えますが、実際は逆で、遠慮なく触りながら覚えるのが最短ルートです。

あわせて読みたい
Googleサーチコンソールのデータをスプレッドシートに自動蓄積する方法【新UI対応・つまずきポイント付き】 サーチコンソール(GSC)のデータには、意外と知られていない致命的な仕様があります。保存期間が16ヶ月しかないということです。 つまり今日確認できる2年前のデータは...

Chromeデベロッパーツールの開き方

開き方は3通りありますが、実務では「右クリック→検証」と「ショートカット」の2つを覚えれば十分です。

右クリックの「検証」から開く

最も直感的で、初心者に一番おすすめの開き方です。

  1. 調べたい部分(見出し、ボタン、画像など)の上にマウスカーソルを置く
  2. 右クリックする
  3. メニュー最下部付近の「検証」をクリックする
Screenshot

この方法の利点は、クリックした要素のHTMLが最初から選択された状態で開くことです。「このボタンのHTMLが見たい」という目的なら、これが最短です。

Takuma

なお、Chromeのメニューからは「⋮(三点リーダー)→ その他のツール → デベロッパー ツール」でも開けます。

ショートカットキーで開く

慣れてきたらショートカットのほうが速いです。よく使う4つだけ覚えてください。

操作MacWindows
DevToolsを開く/閉じるCommand + Option + IF12 または Ctrl + Shift + I
要素選択モード(クリックした要素を調べる)Command + Shift + CCtrl + Shift + C
Consoleを開くCommand + Option + JCtrl + Shift + J
デバイスモード(スマホ表示)の切り替えCommand + Shift + MCtrl + Shift + M
コマンドメニューを開くCommand + Shift + PCtrl + Shift + P
キャッシュを無視して再読み込みCommand + Shift + RCtrl + Shift + R

特にコマンドメニュー(Command/Ctrl + Shift + P)は覚える価値が高いショートカットです。

機能名の一部を入力すれば、どのパネルにあるかを知らなくても目的の機能を呼び出せます。後述するフルサイズのスクリーンショットも、ここから実行します。

表示位置を変更する

DevToolsが画面の右半分を占領して、ページ本体が細長くなってしまう、初心者が最初につまずくのがこれです。

表示位置は自由に変えられます。

  1. DevTools右上の「⋮」(Customize and control DevTools)をクリックする
  2. Dock side の並んだアイコンから位置を選ぶ

選べる位置は4つです。

  • 右側(Dock to right):スマホ表示の確認に向く。縦に長い領域を確保できる
  • 下側(Dock to bottom):Networkパネルなど横に長い表を見るときに向く
  • 左側(Dock to left):右利きの視線移動を減らしたい人向け
  • 別ウィンドウ(Undock into separate window):DevToolsだけを別ウィンドウに切り離す。デュアルディスプレイ環境なら圧倒的に見やすい

「別ウィンドウ」は特に、モニターが2枚ある環境で威力を発揮します。

Takuma

片方の画面にサイト、もう片方にDevToolsという配置にすると、ページを狭めずに検証できます。

Chromeデベロッパーツールを日本語化する方法

DevToolsのUIは日本語表示に切り替えられます。Chrome 94以降、日本語を含む80以上の言語に対応しました。

  1. DevToolsを開く
  2. 右上の歯車アイコン(Settings)をクリックする(F1でも開けます)
  3. 左メニューのPreferences(基本設定)を選ぶ
  4. Appearance(外観)セクションのLanguageを「日本語 – Japanese」に変更する
  5. 上部に表示される「Reload DevTools」をクリックする

「Browser UI Language」を選ぶと、Chrome本体の表示言語に自動で合わせられます。

日本語表示の画面
ポイント

日本語化すると初心者には読みやすくなりますが、トラブル解決時の情報量は英語のほうが圧倒的に多いという副作用があります。

エラーメッセージや機能名で検索する機会が増えたら、英語表示に戻すことも検討してください。この記事では、検索しやすさを優先して英語の機能名を併記しています。

あわせて読みたい
GA4のデータをスプレッドシートに自動出力する方法【公式アドオンGA4 Reports Builder・注意点付き】 GA4の画面、正直使いにくくないでしょうか。ちょっとした数字を確認するだけでも探索レポートを組む必要があり、月次の定点観測のたびにポチポチやるのは苦行です。 そ...

ElementsでHTML・CSSを一時編集する方法

Elementsパネルは、今表示されているページのHTMLとCSSを確認し、その場で書き換えて見た目を試せる機能です。

「この見出しを1行短くしたらどう見えるか」「ボタンの色を変えたら目立つか」を、制作会社に依頼する前に自分で試せます。

調べたい要素を選択する

まず、調べたい部分のHTMLにたどり着く必要があります。手順は次のとおりです。

  1. DevToolsを開く
  2. 左上の矢印アイコン(要素選択モード)をクリックする(Command/Ctrl + Shift + C
  3. ページ上の見出しやボタンにマウスを乗せる
  4. 青くハイライトされ、要素名とサイズが表示される
  5. クリックすると、対応するHTMLがElementsパネル内で選択される

画面下部にはパンくず表示(例:body > div.container > main > h2)が出ます。これは「今選んでいる要素が、どの階層にあるか」を示すもので、親要素を選び直したいときに便利です。

初心者がつまずきやすい点

クリックしたつもりが、目的の要素より内側(<span>など)や外側(<div>)が選ばれることがあります。その場合はキーボードの でHTMLツリー内を移動して、目的の要素を選び直してください。

見出しやボタンの文章を仮編集する

文言変更の効果は、実際に画面へ入れてみないと判断できません。DevToolsなら30秒で試せます。

  1. Elementsパネルで、変更したいテキスト部分をダブルクリックする
  2. 文字が編集可能になるので、新しい文言を入力する
  3. Enter を押す
  4. ページ上の表示が即座に切り替わる

タグごと書き換えたい場合は、要素を右クリックして「Edit as HTML」(Macは F2 でも可)を選ぶと、HTMLをまとめて編集できます。

Screenshot
ポイント

左側のページ表示と、右側のHTMLが連動している点に注目してください。HTMLを書き換えた瞬間に、左のページ表示も変わります。

この変更は、ページを再読み込み(F5)した瞬間に消えます。

Takuma

本番サイトには一切影響しません。だからこそ、キャッチコピーのA/B案を関係者に見せる、CTAボタンの文言を短くして収まりを確認する、といった用途に安心して使えます。

あわせて読みたい
【2026年最新】Udemy最安値クーポン配布中!SEO・AI・営業コース【毎月更新】 こんにちは、岡 拓馬(@OkaTakuma1)です。 普段は海外(現在はベトナム・ダナン)を拠点に、外資系企業のSEOマーケティングやWebコンサルティングを行っています。 「U...

CSSを一時変更する

Elementsパネルの右側(または下側)にあるStylesペインで、CSSを書き換えられます。

  1. 要素を選択する
  2. Stylesペインで、変更したいプロパティの値をクリックする
  3. 値を入力し、Enter で確定する
  4. 何も適用されていないプロパティを追加したいときは、element.style { } の中括弧内をクリックして入力する

初心者がまず試すとよいのは、次の7つです。

プロパティ何が変わるか入力例
color文字の色#333333
background-color背景色#f5f5f5
font-size文字サイズ18px
margin要素の外側の余白24px 0
padding要素の内側の余白16px
width横幅320px
display表示形式(noneで非表示)none

カラーコードの変更が最も分かりやすい入り口です。

colorbackground-color の値の左には小さな四角い色見本があり、これをクリックするとカラーピッカーが開きます。スポイトツールでページ内の色を拾うこともできるので、「このボタンの色、他の要素と揃っているか」の確認にも使えます。

余白の調整もよく使います。Stylesペインの一番下にあるBox Model(入れ子の四角形の図)は、margin・border・padding・content の実測値を表示します。数値部分をダブルクリックすれば、その場で変更できます。

「なんとなく詰まって見える」という感覚的な違和感を、具体的な数値に翻訳してくれる図です。

Screenshot

カラーコードの左にある色見本アイコンをクリックすると、カラーピッカーが開きます。数値を打たなくても色を試せるので、非エンジニアはここから始めるのがおすすめです。

初心者がつまずきやすい点

変更したはずなのに反映されない場合、そのプロパティに取り消し線が引かれていないかを確認してください。

取り消し線は「より優先度の高い別のCSSに上書きされている」というサインです。この場合は、上書きしている側のルールを探す必要があります。

あわせて読みたい
SEOレポート自動化とは?手作業をやめて仕組みで回す方法 SEOレポートの作成に、毎週どれくらいの時間を使っているでしょうか。 Google Search Console や GA4 の数値を確認し、前週と比較し、表を作り、コメントを書き、スライ...

画像や要素を一時的に非表示にする

「このバナーを消したら、ページの印象はどう変わるか」を確認する方法です。

  • 要素を選択して H キーを押す(表示・非表示のトグル)
  • または Stylesペインで display: none; を追加する
  • 完全に削除して試したい場合は、要素を選択して Delete キー

削除してしまっても、再読み込みすれば元に戻ります。

要素の要不要を議論するとき、口頭で説明するより「消した状態のスクリーンショット」を見せたほうが早く決まります。

HTMLやCSSの変更は保存できるのか

結論として、Elementsパネルでの編集は保存されません。

Chrome公式ドキュメントも、ElementsパネルのDOMツリーへの変更はDevToolsが保存しない仕様であることを明記しています。

一方で、Local Overrides という機能を使えば、変更内容をローカルのフォルダに保存し、再読み込み後も維持できます。

ただしこれもあくまで自分のブラウザ内での話で、本番サイトのファイルが書き換わるわけではありません。詳しくは後半の章で説明します。

方法再読み込み後本番サイトへの反映難易度
Elements編集消えるされないかんたん
Local Overrides残る(自分のPCのみ)されない応用
あわせて読みたい
【2025年版】ECサイトの商品ページSEO完全ガイド!売れる構成と検索上位を両立する設計術 ECサイトの売上を左右するのは、「商品ページのSEO設計」です。 どれだけ広告を回しても、検索からの流入が弱ければ継続的な売上は安定しません。 とはいえ、ただキーワ...

Chromeデベロッパーツールでスマホ表示を確認する方法

スマホのテスト画面

スマホからのアクセスが大半を占める今、スマホ表示の崩れは直帰率とコンバージョンに直結します。

DevToolsのデバイスモード(Device Mode)を使えば、実機がなくても幅を変えた表示を確認できます。

デバイスモードを起動する

  1. DevToolsを開く
  2. 左上のスマホとタブレットが重なったアイコン(Toggle device toolbar)をクリックする
  3. ショートカットは Command + Shift + M(Mac)/Ctrl + Shift + M(Windows)

起動すると、ページ表示エリアの上部に「Dimensions」「幅 × 高さ」「Zoom」などのツールバーが現れます。

iPhone、Pixel、Galaxy、iPadへ切り替える

ツールバー左端のDimensionsプルダウンから、端末を選びます。標準では iPhone、Pixel、Samsung Galaxy、iPad、Surface などのプリセットが用意されています。

端末を選ぶと、画面幅・デバイスピクセル比・ユーザーエージェント文字列がまとめて切り替わります。

スマホ端末を追加する

一覧に目的の端末がない場合は、追加できます。

  1. Dimensionsプルダウンを開く
  2. 最下部の「Edit…」をクリックする
  3. Settings > Devices の画面が開く
  4. 表示したい端末のチェックボックスをオンにする
  5. 一覧にない端末は「Add custom device」から、名前・幅・高さ・デバイスピクセル比・UA文字列を入力して追加する

自社サイトのアクセス解析で上位に来る端末の画面幅を調べて、それを登録しておくと検証精度が上がります。

任意の画面幅で確認する

端末プリセットではなく、幅を直接指定して確認する方法もあります。

  • Dimensionsで「Responsive」を選ぶ
  • 幅・高さの数値を直接入力する(例:375 × 667390 × 844430 × 932
  • ツールバーの回転アイコンで縦向き/横向きを切り替える
  • Zoomで表示倍率を変更する(画面に収まらない大きな端末の確認に便利)

表示領域の端をドラッグして、幅を連続的に変えていく方法もおすすめです。レイアウトが崩れ始める幅(ブレークポイント)を体感的に見つけられます。

上部のツールバーで端末名と画面幅を確認してください。ここに表示されている数値が、実際に検証している画面幅です。

スマホ表示で確認するポイント

漫然と眺めても崩れは見つかりません。次の6点を順にチェックしてください。

  1. ヘッダーの見切れ:ロゴやメニューが画面端で切れていないか
  2. CTAのはみ出し:ボタンの文言が長すぎて枠から出ていないか、折り返して不自然になっていないか
  3. 横スクロール:ページを左右に振ってみて、意図しない横スクロールが発生しないか(表や画像、長いURLテキストが原因になりやすい)
  4. 固定要素の重なり:追従ヘッダーや固定バナーが、本文やフォームを隠していないか
  5. 文字サイズ:本文が小さすぎないか(一般に16px前後が目安)
  6. 画像サイズ:必要以上に大きな画像を読み込んでいないか

Device Modeと実機確認の違い

デバイスモードは画面幅とユーザーエージェントのシミュレーションであり、実機の完全再現ではありません。

再現できないものの例
  • 実機のブラウザ固有の描画差(特にiOS Safari)
  • 実際のタッチ操作の感触、スクロールの慣性
  • 実機のCPU性能による処理速度
  • アプリ内ブラウザ(LINE、Instagramなど)での挙動

レイアウト崩れの一次チェックはDevTools、最終確認は実機。この使い分けが安全です。特にiOS Safari特有の崩れは、Chromeのデバイスモードでは再現されません。

スマホ表示にならない場合の対処法

デバイスモードにしたのにPC表示のままの場合、次を確認してください。

  1. ページを再読み込みしていない:UAの切り替えは再読み込み後に反映されることがあります
  2. キャッシュが効いているCommand/Ctrl + Shift + R でキャッシュを無視して再読み込みする
  3. UAではなく画面幅で出し分けているサイト:幅を十分に狭くしたか確認する
  4. サーバー側でUA判定してPC版を返している:Networkパネルでレスポンスを確認する
  5. キャッシュプラグインやCDNがPC版HTMLを返している:WordPressサイトで頻発します。キャッシュを削除して再確認してください
あわせて読みたい
LLMO対策|AIクローラーがJavaScriptを読めない問題と解決法【2026年版】 「Googleでは上位なのに、ChatGPTやPerplexityに聞くと、うちの会社がまったく出てこない」 最近、こういう相談が明確に増えています。 そして多くの場合、原因はコンテ...

ConsoleでJavaScriptエラーを確認する方法

  • 「フォームが送信できない」
  • 「ボタンを押しても何も起きない」

このタイプの不具合は、Consoleパネルに答えが出ていることが非常に多いです。

Consoleを開いて既存ログを消す

大事なのは順番です。

先にログを消してから、問題の操作を再現すること。これをやらないと、無関係なログに埋もれて原因を見失います。

  1. Consoleタブを開く(Command + Option + J / Ctrl + Shift + J
  2. 左上の🚫アイコン(Clear console)をクリックしてログを消す
  3. フォーム送信やボタンクリックなど、問題の操作を再現する
  4. 直後に追加された赤い行を確認する

この4ステップだけで、「いつ出たエラーなのか」が明確になります。

Takuma

赤いエラー行の右端に表示されているファイル名と行番号に注目してください。開発担当者に共有すべき情報はここに含まれています。

赤いエラーと黄色い警告の違い

表示意味対応の目安
赤(Error)処理が止まっている可能性が高い機能が動かないなら最優先で調査
黄(Warning)動作はするが推奨されない、または将来的に問題になるすぐ壊れるわけではない。余裕があるとき対応
白・青(Log / Info)開発者が意図的に出力した情報基本的に無視してよい

赤があっても、目的の機能が正常に動いているなら緊急ではないケースも多くあります。逆に、目的の機能が動いていないなら、赤いエラーを最優先で読んでください。

よくあるJavaScriptエラー

初心者が遭遇しやすいものを、意味と典型的な原因で整理します。

エラーざっくりした意味よくある原因
Uncaught TypeError想定と違う型のデータを操作しようとした要素が見つからないまま処理を続けている
Uncaught ReferenceError: xxx is not defined存在しない変数や関数を呼び出したスクリプトの読み込み順序ミス、読み込み失敗
Cannot read properties of null存在しない要素を操作しようとしたHTMLの構造変更でclass名やIDが消えた
Failed to load resourceファイルの読み込みに失敗したファイルのURLミス、404、外部サービス停止
gtag is not definedGA4のタグが読み込まれる前に計測処理が走ったタグ設置位置の問題、広告ブロッカー、GTMの読み込み失敗

gtag is not defined はSEO・広告担当者が特に遭遇しやすいエラーです。計測データが欠損している原因がこれ、というケースは珍しくありません。

フォームやボタンが動かない場合の調査方法

  1. Consoleを開いてClearする
  2. 問題のボタンをクリック、またはフォームを送信する
  3. 赤いエラーが出るか確認する
  4. エラーが出た場合:ファイル名と行番号を控える
  5. エラーが出ない場合:Networkパネルに切り替え、Fetch/XHRで絞り込んで送信リクエストが発生しているか確認する
  6. リクエスト自体が発生していないなら、JavaScriptがそもそも実行されていない可能性が高い
  7. リクエストは出ているがステータスが400番台・500番台なら、サーバー側の問題

「エラーが出ない」も重要な情報です。 その場合は原因がフロント側ではなくサーバー側にある、という切り分けができます。

Chrome拡張機能由来のログに注意する

Consoleに大量のエラーが出ていても、その多くは自分のサイトとは無関係な拡張機能のログであることがあります。

拡張機能由来を疑うサイン
  • chrome-extension:// から始まるURL
  • content.js contentscript.js inject.js といったファイル名
  • MozBar、Grammarly、パスワード管理ツールなど拡張機能名が含まれる

対策は3つです。

  1. シークレットウィンドウで確認する(拡張機能が原則無効になる)
  2. 疑わしい拡張機能を一時的にオフにする
  3. ConsoleをClearしてから操作を再現し、その操作で新たに出たログだけを見る

Consoleのフィルター欄に -extension と入力して除外する方法もあります。

開発担当者へ共有する情報

エラーを見つけたら、次の6点をまとめて渡すと調査が一気に速くなります。「動きません」だけの報告と比べて、往復のやり取りが半分以下になります。

  1. 対象URL(パラメータ付きなら完全な形で)
  2. 再現手順(何をクリックして、何を入力したか)
  3. エラーメッセージの全文(コピーして貼り付ける)
  4. エラーに表示されているファイル名と行番号
  5. Console画面のスクリーンショット
  6. 発生日時、使用ブラウザ・OS・端末
あわせて読みたい
個人開発のSaaSをlaunchする前に、絶対やるべきセキュリティチェック5つ!Supabaseの脆弱性を実例で解説 こんにちは、岡 拓馬(@OkaTakuma1)です。 Web のSEO診断とAI検索(GEO/LLMO)対応をまとめて診断できる無料ツール「SEGO」を、個人で開発しています。4月30日の launc...

Networkで通信状況を確認する方法

Networkパネルでは、ページを表示するために発生したすべての通信を確認できます。

404の特定、リダイレクトの確認、重い画像の発見など、SEO・Web運用の実務で使用頻度が最も高いパネルです。

Networkを開いてページを再読み込みする

Networkパネルは開いている間の通信しか記録しません。 開く前の通信は表示されないため、必ず「開いてから再読み込み」の順序で操作します。

  1. Networkタブを開く
  2. 左上の録画ボタン(●)が赤いことを確認する(グレーなら停止中なのでクリック)
  3. 🚫アイコンでこれまでのログをClearする
  4. 必要に応じてDisable cacheにチェックを入れる(初回訪問者と同じ状態を再現できる)
  5. ページを再読み込みする
Takuma

Statusカラムの数値と、Timeカラムの数値に注目してください。この2列を見るだけで「エラーがないか」「何が重いか」が把握できます。

Networkの主要項目

カラム意味見るポイント
Nameファイル名やURL何が読み込まれているか
StatusHTTPステータスコード200以外、特に赤い表示
Typeファイル種別(document、script、imgなど)想定外のファイルがないか
Initiatorその通信を発生させた側「誰がこれを呼んだのか」の特定
Size転送サイズ突出して大きいファイル
Time完了までの時間突出して遅い通信
Waterfall時系列のタイミング図どこで待ち時間が発生しているか

画像、JavaScript、API通信を絞り込む

パネル上部のフィルターボタンで種別を絞り込めます。

  • Doc:HTML本体。リダイレクトやステータス確認はここ
  • CSS:スタイルシート
  • JS:JavaScriptファイル
  • Img:画像。重い画像を探すときはここ
  • Fetch/XHR:フォーム送信やAPI通信。「ボタンを押したのに何も送信されていない」の確認に使う
  • Font:Webフォント。表示遅延の原因になりやすい
  • Media:動画・音声

検索欄にドメイン名やファイル名の一部を入力して絞り込むこともできます。

404、500などのHTTPステータスを確認する

Statusカラムの数値の意味です。

コード意味判断
200正常問題なし
204正常。返す中身がないだけエラーではない
計測タグでよく発生
301恒久的なリダイレクト意図したものか確認
302一時的なリダイレクト恒久移転なら301にすべき
304キャッシュが有効なので再送不要エラーではない
むしろ効率的な状態
404ページ・ファイルが存在しない要対応
500サーバー内部エラー最優先で要対応

初心者がつまずきやすい点

204と304はエラーではありません。

204は「正常に受け取ったが返す中身がない」、304は「前回と同じなのでキャッシュを使ってよい」という意味です。

GA4やGTMの計測通信は204を返すことが多く、これを見て「計測が失敗している」と誤解するケースが頻繁にあります。

通信をクリックしてHeadersを見る

一覧の行をクリックすると、詳細が右側(または下側)に開きます。Headersタブで確認すべき項目は次のとおりです。

  • Request URL:実際にリクエストされたURL。パラメータの有無もここで確認
  • Request MethodGET(取得)か POST(送信)か
  • Status Code:ステータスコード
  • Response Headers:サーバーが返した情報
    • content-type:ファイル種別(text/htmlimage/webp など)
    • location:リダイレクト先URL(301・302のとき表示される)
    • cache-control:キャッシュの扱い
    • x-robots-tagクロール・インデックスの指示。SEOでは要チェック
  • Request Headers:ブラウザが送った情報(user-agent など)

リダイレクトを確認する

リダイレクトは、通常のままだと画面が切り替わった瞬間にログが消えてしまいます。

Preserve logを使うのがコツです。

  1. Networkパネル上部の「Preserve log」にチェックを入れる
  2. ログをClearする
  3. 旧URLをアドレスバーに入力してアクセスする
  4. 一覧の一番上の行(旧URL)をクリックする
  5. Status Codeが301か302かを確認するResponse Headersの location で転送先を確認する
確認すべきポイント
  • 多段リダイレクト:旧URL → 中間URL → 最終URLと2回以上経由していないか。表示速度とクロール効率の両方に悪影響があります
  • 301か302か:恒久的な移転なのに302になっていないか
  • JavaScriptリダイレクトとの違い:Statusが200のままURLだけ変わっている場合、サーバー側ではなくJavaScriptによる転送です。サーバーリダイレクトのほうが確実で、SEO上も推奨されます

重い通信を探す

表示が遅い原因を特定する手順です。

  1. Timeカラムのヘッダーをクリックして並べ替える → 時間がかかっている通信が上に来る
  2. Sizeカラムで並べ替える → ファイルサイズが大きい通信が分かる
  3. 該当の通信をクリックし、Timingタブを開く → 待ち時間(Waiting)とダウンロード時間(Content Download)のどちらが長いかが分かる
  4. Waterfallの形を見る → 特定の通信が終わるまで他が待っている「直列」の状態がないか確認する

よくある犯人は3つです。

  • 圧縮されていない大きな画像(数MB級のJPEGなど)
  • 外部の計測タグ・広告タグ(自社では制御しにくい)
  • 遅いAPIレスポンス
Takuma

Waiting時間が長い場合はサーバー側、Content Download時間が長い場合はファイルサイズが原因、という切り分けができます。

Networkに何も表示されない場合

慌てる前に、次の5点を確認してください。

  1. 録画が停止している:左上の●がグレーになっていないか
  2. 再読み込みしていない:Networkは開いた後の通信しか記録しません
  3. フィルターがかかっている:Img や JS などが選択されたままになっていないか
  4. 検索欄に文字が残っている:以前の検索条件が残っていないか
  5. 「Hide data URLs」などのオプションがオンになっている:上部のチェックボックスを確認

拡張機能の広告ブロッカーが通信自体をブロックしているケースもあります。シークレットウィンドウで再確認すると切り分けられます。

あわせて読みたい
【SEO×AI】ブラックハットGEOとは?AI時代に拡大する不正SEOの仕組みとリスク 本記事は「searchengineland」の最新記事を翻訳し、独自の意見を加えたものです。 AIが検索体験を根本から変えた今、「ブラックハットGEO(Generative Engine Optimizat...

Cookie・Local Storage・キャッシュを確認する方法

  • 「同意バナーが毎回出る」
  • 「ログイン状態が保持されない」
  • 「A/Bテストの振り分けが機能しているか確認したい」

こうした確認はApplicationパネルで行います。

ApplicationパネルでCookieを確認する

  1. Applicationタブを開く
  2. 左メニューのStorage > Cookiesを展開する
  3. 対象のドメインをクリックする

表示される項目の意味は次のとおりです。

項目意味見るポイント
NameCookieの名前_ga _gid はGA4、_fbp はMeta広告
Value保存されている値意図した値が入っているか
Domain有効なドメインサブドメインを含むか(先頭にドットがあるか)
Path有効なパス/ なら全ページで有効
Expires / Max-Age有効期限Session ならブラウザを閉じると消える
HttpOnlyJavaScriptから読めない設定セキュリティ上、認証系はオンが望ましい
SecureHTTPS接続でのみ送信オンが望ましい
SameSite別サイトからのリクエスト時の送信可否Lax Strict None

行を右クリックすれば個別に削除でき、上部のアイコンで全削除もできます。同意バナーの初回表示テストは、該当Cookieを削除して再読み込みするのが最も確実です。

Local StorageとSession Storageを確認する

Local Storage
Session Storage

同じくApplicationパネルの左メニューにあります。

  • Local Storage:ブラウザを閉じても残る。「バナーを一度閉じたら二度と出さない」といった実装に使われる
  • Session Storage:タブを閉じると消える。フォームの一時保存などに使われる

キーと値の一覧が表示されるので、値をダブルクリックすれば編集も可能です。

Takuma

「バナーを閉じた状態」を再現したり、リセットして初回表示を確認したりできます。

キャッシュを無効化する

「修正したのに反映されない」の大半はキャッシュが原因です。確認方法は2つあります。

  1. Disable cache:Networkパネル上部のチェックボックス。DevToolsを開いている間だけキャッシュが無効になります
  2. Empty cache and hard reload:DevToolsを開いた状態で、ブラウザの更新ボタンを長押し(右クリック)すると表示されるメニュー。キャッシュを削除したうえで再読み込みします
Networkパネル上部のチェックボックス。DevToolsを開いている間だけキャッシュが無効になります
Networkパネル上部のチェックボックス。DevToolsを開いている間だけキャッシュが無効になります
Takuma

制作会社に「直っていません」と伝える前に、この2つを試してください。自分側のキャッシュだった、というケースは非常に多いです。

あわせて読みたい
リンクビルディングの限界と新時代の答え!デジタルPRに全振りした理由 本記事は「blackhatworld」の最新トピックスを翻訳し、独自の意見を加えたものです。 長年、SEOにおける「被リンク獲得=リンクビルディング」は王道の戦略として語られ...

Chromeデベロッパーツールでスクリーンショットを撮る方法

DevToolsには、拡張機能なしでページ全体を1枚の画像として保存する機能があります。競合分析、社内共有、記事作成のいずれでも便利です。

表示中の画面を撮影する

  1. DevToolsを開く
  2. Command + Shift + P(Mac)/Ctrl + Shift + P(Windows)でコマンドメニューを開く
  3. screenshot と入力する
  4. 「Capture screenshot」を選ぶ
保存された画像
screenshot と入力し、
「Capture screenshot」を選ぶ

表示中の範囲(ビューポート)だけがPNGとして保存されます。

同じメニューには他にも次のコマンドがあります。

  • Capture area screenshot:ドラッグで範囲を指定して撮影
  • Capture node screenshot:Elementsで選択中の要素だけを撮影。表やカードの切り出しに便利

Webページ全体をフルサイズで撮影する

長いページを1枚に収めたいときはこれです。

  1. コマンドメニューを開く
  2. screenshot と入力する
  3. 「Capture full size screenshot」を選ぶ

スクロールが必要な範囲を含めて、ページ全体が1枚のPNGとして保存されます。

保存された画像
注意

追従ヘッダーが繰り返し写り込む、遅延読み込み(lazy load)の画像が空白になる、といった現象が起きることがあります。撮影前にページを最下部まで一度スクロールして画像を読み込ませておくと、失敗を減らせます。

スマホ表示のスクリーンショットを撮影する

  1. デバイスモードを起動する(Command/Ctrl + Shift + M
  2. 端末と向きを選ぶ
  3. デバイスツールバー右端の「⋮」をクリックする
  4. 「Capture screenshot」または「Capture full size screenshot」を選ぶ
Takuma

「⋮」メニューの「Add device frame」をオンにすると、端末のフレーム付きで撮影できます。提案資料に載せるスマホ表示のモックとして使えます。

あわせて読みたい
【保存版】ブラックハットSEOから学ぶ攻めの戦略とリスク管理 本記事は「blackhatworld」の最新トピックスを翻訳し、独自の意見を加えたものです。 SEOの世界には「ホワイトハット」「ブラックハット」という二つの言葉があります。...

LighthouseとPerformanceでページ品質を確認する

Lighthouseで確認できる項目

Lighthouseは、ページの品質を自動診断してスコアとレポートを出す機能です。

DevToolsに「Lighthouse」パネルとして組み込まれています。

診断されるカテゴリは4つです。

  • Performance:表示速度・Core Web Vitals関連
  • Accessibility:アクセシビリティ(alt属性の欠落、コントラスト不足など)
  • Best Practices:セキュリティやブラウザ推奨事項への適合
  • SEO:title、meta description、クロール可否など基本項目

Lighthouseの実行方法

  1. 診断したいページを開く
  2. DevToolsでLighthouseタブを開く
  3. カテゴリ(Performance、SEOなど)を選ぶ
  4. Mobile / Desktopを選ぶ
  5. 「Analyze page load」をクリックする
  6. 数十秒待つとレポートが生成される
Takuma

モバイルでの診断を優先してください。 Googleはモバイル版を基準に評価するためです。

診断結果

スコアだけで判断してはいけない理由

Lighthouseのスコアは、次の理由で毎回変動します。「昨日は85点、今日は62点」は普通に起きます。

  • 測定時のネットワーク状況・PCの負荷で結果が変わる
  • Chrome拡張機能が計測に影響する(シークレットウィンドウでの測定を推奨
  • 外部の広告タグ・計測タグの応答速度に左右される
  • Lighthouseは実験室データ(Lab Data)であり、実ユーザーのデータ(Field Data)とは別物

実際のユーザー体験を知りたい場合は、Search ConsoleのCore Web Vitalsレポートや、CrUX(Chrome UX Report)に基づくフィールドデータを確認してください。

Lighthouseの本当の価値はスコアではなく、レポート下部に並ぶ具体的な改善提案にあります。「画像の圧縮」「使われていないJavaScriptの削減」など、優先度つきで提示されます。

Performanceパネルで確認できること

Performanceパネルは、より詳細に表示速度を分析する機能です。

Performanceパネルは、より詳細に表示速度を分析する機能です。

近年は入り口が大きく改善され、パネルを開くと最初にLive metrics画面が表示されます。ここではLCP・CLS・INPの3つのCore Web Vitalsが、操作に応じてリアルタイムで更新されます。

さらに録画(Record)してページを読み込むと、次のような内容を確認できます。

  • 長いJavaScript処理(Long Task):50ms以上かかっている処理
  • メインスレッドの混雑状況:処理が詰まって操作を受け付けられない時間帯
  • レンダリングのタイミング
  • レイアウトシフト(CLS):どの要素が、いつズレたか
  • 画像読み込み:LCPになっている要素の特定

現在は、Lighthouseが指摘するような改善提案がInsightsサイドバーにも表示されるようになり、Performanceパネル単体でも原因分析から改善案までたどれるようになっています。

Takuma

Performanceパネルは非エンジニアには難度が高い機能です。まずはLive metricsでLCPとCLSの数値を眺めるところから始めれば十分です。

あわせて読みたい
【保存版】検索エンジンと生成AIの両方に効くコンテンツ戦略!SEOとAI時代の新しい最適化 本記事は「searchengineland」の最新記事を翻訳し、独自の意見を加えたものです。 SEOの世界は今、大きな転換期を迎えています。 これまでは「Google検索で上位表示され...

SEO担当者がChrome DevToolsで確認したい項目

Takuma

ここではSEOの実務で、DevToolsを使えばその場で確認できる項目を整理します。

外部ツールを立ち上げる前に、DevToolsで済むものは意外と多いです。

titleとmeta description

  • 見るパネル:Elements(<head> 内)
  • 探すもの<title><meta name="description">
  • 問題例:同じtitleが複数ページで使い回されている、テンプレートの変数が展開されずに残っている、descriptionが未設定、CMSのプラグイン設定とHTMLの出力が食い違っている

<head> は折りたたまれていることが多いので、<head> 左の三角をクリックして展開してください。

canonical

  • 見るパネル:Elements(<head> 内)
  • 探すもの<link rel="canonical" href="...">
  • 問題例:全ページがトップページを指している、httpとhttpsが混在、末尾スラッシュの有無が実際のURLと不一致、パラメータ付きURLが正規化されていない

canonicalの事故は、影響が大きい割に気づきにくいタイプの問題です。テンプレート変更後は必ず確認してください。

robots meta

  • 見るパネル:Elements(<head> 内)/Network(Response Headers)
  • 探すもの<meta name="robots" content="...">
  • 問題例:公開したいページに noindex が残っている(テスト環境からの移行時に頻発)、意図せず nofollow が全体に適用されている

H1、H2、H3の見出し構造

  • 見るパネル:Elements、またはConsole(後述のコードで一覧化)
  • 探すもの:見出しタグの階層と文言
  • 問題例:H1が存在しない/複数ある、H2を飛ばしてH3が使われている、デザイン目的で見出しタグが使われている

画像のalt属性

  • 見るパネル:Elements、またはConsole
  • 探すもの<img>alt 属性
  • 問題例:alt未設定、ファイル名がそのまま入っている(IMG_2034.jpg)、キーワードを詰め込んだ不自然なalt

内部リンクとnofollow

  • 見るパネル:Elements、またはConsole
  • 探すもの<a href>rel 属性、リンク先URL
  • 問題例:内部リンクに nofollow が付いている、アンカーテキストが「こちら」ばかり、リンク先が相対パスの誤りで404になっている

JSON-LD形式の構造化データ

  • 見るパネル:Elements(<script type="application/ld+json">
  • 探すもの@type、必須プロパティの有無
  • 問題例:JSONの構文エラーで読み込まれていない、@type が実際のコンテンツと合っていない、複数のプラグインが重複して出力している

構造化データの妥当性判定は、最終的にはGoogleのリッチリザルトテストなど専用ツールで行ってください。

DevToolsは「そもそも出力されているか」「重複していないか」の一次確認に向いています。

JavaScript実行後に本文やリンクがDOM上へ存在するか

  • 見るパネル:Elements(実行後のDOM)/Network の Doc(元のHTML)
  • 探すもの:本文テキスト、内部リンクが、それぞれどちらに存在するか
  • 問題例:元のHTMLにはほぼ何もなく、JavaScript実行後にはじめて本文が生成されている

これはDevToolsならではの確認方法です。

Elementsパネルが表示するのはJavaScript実行後のDOMであり、Networkパネルの Doc → Response で見られるのはサーバーが返した元のHTMLです。

この2つを比較すると、コンテンツがJavaScriptに依存しているかどうかが分かります。

ブラウザで見えているのに元のHTMLにない、という状態は、レンダリングが正しく行われなければ検索エンジンに認識されないリスクを意味します。

404、500、リダイレクト

  • 見るパネル:Network(Docフィルター、Preserve logをオン)
  • 探すもの:Status Code、location ヘッダー
  • 問題例:内部リンクの404、多段リダイレクト、301にすべき箇所が302、リダイレクトループ

X-Robots-Tagなどのレスポンスヘッダー

  • 見るパネル:Network → 対象通信 → Headers → Response Headers
  • 探すものx-robots-tagcontent-typecache-controlvary
  • 問題例:HTML内にはnoindexがないのに、レスポンスヘッダーで x-robots-tag: noindex が指定されている

これはHTMLをいくら見ても分からないため、原因不明のインデックス未登録を調査するときに必ず確認したい項目です。PDFなどHTML以外のファイルの制御にも使われます。

GA4・GTMの通信

  • 見るパネル:Network(検索欄に collectgtm と入力)
  • 探すものgoogle-analytics.com/g/collect への通信、gtm.js の読み込み
  • 問題例:計測タグが二重に発火している、特定ページだけタグが読み込まれていない、Consoleに gtag is not defined が出ている

collect への通信がステータス204で返ってくるのは正常です。エラーではありません。

スマホ表示の横スクロールやCTAの見切れ

  • 見るパネル:デバイスモード
  • 探すもの:意図しない横スクロール、はみ出したボタン、追従要素の重なり
  • 問題例:表や画像が画面幅を超えている、CTAボタンの文言が折り返して読みにくい、固定バナーがフォームの送信ボタンを隠している
あわせて読みたい
【完全版】WordPressサイトにAPIを実装する方法!REST API・外部連携・プラグイン開発の基礎から応用まで WordPressでサイトを運営していると、 「外部サービスのデータを取り込みたい」 「自作アプリとWordPressをつなげたい」 「もっと効率よく自動化できないかな?」 そん...

位置情報・通信速度・ユーザーエージェントを変更する方法

DevToolsでは、ブラウザの環境そのものを一時的に切り替えられます。

「特定条件でだけ起きる不具合」の再現に使う機能です。

位置情報を一時変更する

  1. コマンドメニュー(Command/Ctrl + Shift + P)で Sensors と入力する
  2. 「Show Sensors」を選ぶ
  3. Locationのプルダウンから都市を選ぶ、または「Custom location…」で緯度・経度を入力する
  4. 「Location unavailable」を選べば、位置情報が取得できない状態も再現できる
Location が「London」に設定されているので、今このページは位置情報がロンドンとして扱われている状態
Takuma

店舗検索や地図機能を持つサイトのテストに使えます。位置情報の取得に失敗したときの表示が壊れていないか、という確認は見落とされがちです。

通信速度を変更する

Networkパネル上部のThrottlingプルダウンから選びます。

  • Fast 4G:比較的良好なモバイル回線
  • Slow 4G:やや遅いモバイル回線。Lighthouseのモバイル計測条件に近い設定
  • 3G:かなり遅い回線
  • Offline:完全にオフライン
  • Custom:帯域と遅延を自分で設定
注意

Chrome 127より前は「Fast 3G」「Slow 3G」という名称でした。現在は「Slow 4G」「Fast 4G」に整理されています。古い解説記事とメニュー名が異なる場合がありますが、機能は同じ系統のものです。

Takuma

Offlineは、通信が切れたときにエラー表示が適切に出るかの確認に使えます。

ユーザーエージェントを変更する

  1. コマンドメニューで Network conditions と入力し、「Show Network conditions」を選ぶ
  2. User agentの「Use browser default」のチェックを外す
  3. プルダウンから端末やクローラーのUAを選ぶ、または任意の文字列を入力する

プルダウンにはGooglebot相当のUA文字列も用意されています。

注意

UAを変更しても、Chrome自体がGooglebotになるわけではありません。 変わるのは「ブラウザが名乗る名前」だけです。IPアドレスもレンダリングの仕組みもGoogleのクローラーとは異なります。

UAで出し分けているサイトの挙動確認には使えますが、「Googlebotから見たページ」の正式な確認は、Search Consoleの URL検査ツールで行ってください。

DevToolsでIPアドレスを変更できるのか

結論:Chrome DevToolsだけでは、インターネット上の公開IPアドレスは変更できません。

DevToolsで変更・再現できるのは、あくまでブラウザ側の設定や状態です。

DevToolsで変更できるDevToolsでは変更できない
位置情報(緯度・経度)公開IPアドレス
タイムゾーン接続元の国・地域の判定(IPベースのもの)
ロケール(言語・地域設定)サーバー側のジオロケーション判定
ユーザーエージェント実際のネットワーク経路
通信速度・オフライン状態

IPベースで地域判定しているサイト(地域別価格、地域別コンテンツなど)の挙動を確認したい場合は、VPNやプロキシなど別の仕組みが必要です。

Takuma

DevToolsのLocation設定を変えても、サーバーから見た接続元は変わりません。

あわせて読みたい
SEOに強いサイト構造とは?ユーザー体験・内部リンク・トピカルオーソリティを最大化する設計術 本記事は「searchengineland」の最新記事を翻訳し、独自の意見を加えたものです。 サイト構造(サイトアーキテクチャ)は、SEOの成果を大きく左右する“見えない基盤”で...

Consoleを使ってSEO情報を抽出する方法

Consoleでは、今開いているページに対してJavaScriptを実行できます。手作業で数えると1時間かかる作業が、数秒で終わります。

実行方法は共通です。 Consoleタブを開き、コードを貼り付けて Enter を押すだけです。ページを書き換える処理ではないので、サイトが壊れることはありません。

注意:安全に使うためのルール
  • 自社サイト、または一般公開されているページを対象にする
  • 対象サイトの利用規約を確認する
  • ログインが必要な領域や有料コンテンツの制限を回避しない
  • 個人情報や認証情報を取得しない
  • CAPTCHAやアクセス制限を回避しない
  • 非公開APIを不正に利用しない
  • 短時間に大量アクセスを行わない
  • 取得したコンテンツを無断で転載しない

ここで紹介するのは、ブラウザで既に表示されている公開情報を、手作業の代わりに整理するという使い方です。

認証を突破したり制限を回避したりする行為は、規約違反や法的リスクにつながります。

Takuma

競合サイトを見るときも、あくまで「自分でブラウザを開いて読んだ範囲を整理する」レベルにとどめてください。

見出しを一覧化する

// ページ内の h1〜h4 をすべて取得し、タグ名と文言を表形式で表示する
const headings = [...document.querySelectorAll('h1, h2, h3, h4')].map(h => ({
  タグ: h.tagName,                            // H1 / H2 などのタグ名
  テキスト: h.innerText.trim().slice(0, 60)   // 長い見出しは60文字で省略
}));
console.table(headings);                       // 表形式で出力

見方console.table は結果を表で表示します。タグ名の並びを上から追って、H1が1つあるか、H2→H3の階層が飛んでいないかを確認してください。

ページ内リンクを抽出する

Screenshot
// ページ内のすべてのリンクを、アンカーテキスト・URL・rel属性つきで一覧化する
const links = [...document.querySelectorAll('a[href]')].map(a => ({
  アンカー: a.innerText.trim().slice(0, 40),
  URL: a.href,
  rel: a.rel || '-',        // nofollow などが入っていれば表示
  target: a.target || '-'
}));
console.table(links);
console.log('リンク総数:', links.length);

見方:アンカーテキストが「こちら」「詳細はこちら」ばかりになっていないか、想定外の nofollow がないかを確認します。

外部リンクだけを抽出する

Screenshot
// 自ドメイン以外へのリンク(外部リンク)だけを抜き出す
const host = location.hostname;                        // 今見ているサイトのドメイン
const external = [...document.querySelectorAll('a[href^="http"]')]
  .filter(a => a.hostname !== host)                    // ドメインが違うものだけ残す
  .map(a => ({
    アンカー: a.innerText.trim().slice(0, 40),
    URL: a.href,
    rel: a.rel || '-'
  }));
console.table(external);
console.log('外部リンク数:', external.length);

見方:意図しない外部リンクが残っていないか、アフィリエイトリンクに sponsored が付いているかの確認に使えます。

alt属性がない画像を探す

Screenshot
// alt属性が未設定、または空文字の画像を抽出する
const noAlt = [...document.querySelectorAll('img')]
  .filter(img => !img.alt || img.alt.trim() === '')
  .map(img => ({
    src: img.currentSrc || img.src,
    幅: img.naturalWidth,     // 実際の画像の横幅(px)
    高さ: img.naturalHeight
  }));
console.table(noAlt);
console.log('alt未設定:', noAlt.length, '/ 画像総数:', document.images.length);

見方:装飾目的の画像はaltが空でも問題ありません。内容を伝える画像にaltがない場合のみ対応してください。あわせて、幅が2000pxを超えるような画像が並んでいたら、圧縮・リサイズの検討対象です。

title、description、canonical、robotsをまとめて確認する

// head内のSEO基本項目を一括で表示する
const meta = (name) => document.querySelector(`meta[name="${name}"]`)?.content ?? '(なし)';
console.table({
  title: document.title,
  description: meta('description'),
  robots: meta('robots'),
  canonical: document.querySelector('link[rel="canonical"]')?.href ?? '(なし)',
  ogTitle: document.querySelector('meta[property="og:title"]')?.content ?? '(なし)',
  lang: document.documentElement.lang || '(なし)'
});

見方(なし) と表示された項目が未設定です。canonicalが今見ているURLと一致しているかも、あわせて確認してください。

JSON-LDを抽出する

Screenshot
// ページ内のJSON-LD(構造化データ)を1件ずつ展開して表示する
[...document.querySelectorAll('script[type="application/ld+json"]')].forEach((s, i) => {
  try {
    const data = JSON.parse(s.textContent);
    console.log(`--- JSON-LD ${i + 1} 件目 ---`, data);  // 展開可能な形で出力
  } catch (e) {
    // 構文エラーがあるとGoogleにも読み取られない可能性が高い
    console.warn(`JSON-LD ${i + 1} 件目は構文エラーの可能性があります:`, e.message);
  }
});

見方:出力された をクリックすると中身を展開できます。黄色い警告が出た場合は構文エラーで、検索エンジンにも読み取られていない可能性があります。同じ @type が複数出力されていたら、プラグインの重複を疑ってください。

HTMLテーブルを整理する

// ページ内1つ目のテーブルをタブ区切りで取り出し、クリップボードへコピーする
const table = document.querySelectorAll('table')[0];   // [1] にすれば2つ目のテーブル
const rows = [...table.querySelectorAll('tr')].map(tr =>
  [...tr.querySelectorAll('th, td')].map(cell => cell.innerText.trim())
);
console.table(rows);
copy(rows.map(r => r.join('\t')).join('\n'));          // タブ区切りでコピー
console.log('クリップボードにコピーしました。スプレッドシートへ貼り付けできます。');

見方copy() はDevToolsのConsole専用の機能です。実行後、そのままGoogleスプレッドシートやExcelに貼り付ければ、表として展開されます。自社サイトの料金表や仕様表をデータ化したいときに便利です。

あわせて読みたい
失敗しないサイト移転とリダイレクトのやり方!SEO・ユーザー体験を両立する方法 サイト移転(ドメイン変更やサーバー移行)は、事業やサイトの成長に合わせて必要になるケースがあります。 しかし、移転のやり方を間違えると、これまで積み上げてきた...

Local Overridesで変更をリロード後も残す方法

Local Overridesは、DevToolsで加えた変更をローカルフォルダに保存し、再読み込みしても維持する機能です。

初心者にとっては応用機能なので、Elements・デバイスモード・Console・Networkに慣れてから触ってください。

通常のElements編集との違い

Elementsパネルでの編集は再読み込みで消えますが、Local Overridesを設定すると、DevToolsが保存したローカルのファイルを、サーバー上のファイルの代わりに読み込むようになります。

そのため、CSSやJavaScriptの修正案を「実際に何度も画面を触りながら」検証できます。

ただしChrome公式ドキュメントのとおり、ElementsパネルのDOMツリーへの変更はLocal Overridesでも保存されません。

保存できるのはCSS、JavaScript、レスポンスヘッダー、XHR/fetchのレスポンスなどです。

CSSやJavaScriptをローカル保存する

  1. Sourcesパネル → Overridesタブを開く
  2. 「Select folder for overrides」をクリックし、保存用の空フォルダを選ぶ
  3. 上部に出る「Allow」をクリックしてアクセスを許可する
  4. StylesペインでCSSを変更する
  5. 再読み込みしても変更が維持される

Networkパネルから始める方法もあります。対象の通信を右クリックし、「Override content」を選ぶと、そのファイルの編集画面へ直接移動できます。

APIレスポンスを仮変更する

Networkパネルで通信を右クリックし、「Override content」を選べば、XHRやfetchのレスポンス内容を書き換えられます。

「APIがまだ完成していないが、データが返ってきたときの表示を確認したい」という場面で使えます。

レスポンスヘッダーも同様に、「Override headers」から書き換えられます。x-robots-tag を追加したときの挙動確認などにも応用できます。

本番サイトには反映されない

Local Overridesで書き換えた内容は、自分のブラウザにしか反映されません。

他の人が同じURLを開いても、元のページが表示されます。あくまで「自分の環境で先に試す」ための機能です。

なお、Local Overridesを有効にしている間はキャッシュが自動的に無効化されます。設定したまま忘れていると、他の検証に影響することがあるため、使い終わったらオフに戻してください。

あわせて読みたい
AI検索時代にブランド評判を守る方法!ゼロクリック環境で主導権を握るための戦略 本記事は、「searchengineland」の最新記事を翻訳し、独自の意見を加えたものです。 Google AI OverviewsやChatGPTなどのAI検索が普及し、消費者のブランド発見プロセス...

Chromeデベロッパーツールでできないこと

できることと同じくらい、できないことを知っておくと判断を誤りません。

  • 本番サイトへ変更内容を保存する:一切できません。サーバー上のファイルは変わりません
  • PHPを直接修正する:PHPはサーバー側で実行されるため、DevToolsからは触れません
  • WordPressの設定を更新する:管理画面から行う必要があります
  • データベースを書き換える:DevToolsの守備範囲外です
  • サーバー環境を完全再現する:サーバー側の処理は推測しかできません
  • 公開IPアドレスを変更する:VPNやプロキシが必要です
  • 実機を完全再現する:デバイスモードはあくまでシミュレーションです
  • Googlebotを完全再現する:UAを変えられるだけです。正式な確認はSearch Consoleの URL検査ツールで行ってください
  • サイト全体を継続的にクロールする:1ページずつの確認が前提です。全体調査はScreaming FrogやAhrefsなど専用ツールを使ってください
Takuma

DevToolsは「1ページを深く調べる」ツールです。サイト全体を横断的に見る用途には向いていません。

あわせて読みたい
SEO担当者必見!robots.txtで多言語サイトを正しくクロールさせる最新手法 多言語サイトのSEOでは、検索エンジンに「どのページをクロールさせるか」を正しく伝えることが欠かせません。そのカギを握るのが robots.txt です。 誤った設定をして...

Chromeデベロッパーツールでよくある質問

Chromeデベロッパーツールは無料ですか?

無料です。Google Chromeに標準搭載されているため、追加の費用も、拡張機能のインストールも、アカウント登録も不要です。

Chromeが入っていれば、右クリックの「検証」から今すぐ使えます。

Chromeデベロッパーツールの変更は保存されますか?

保存されません。

Elementsパネルで加えたHTML・CSSの変更は、ページを再読み込みした時点で消え、本番サイトにも一切反映されません。

例外的に、Local Overridesを設定した場合のみ、自分のブラウザ内でCSSやJavaScriptの変更を維持できますが、この場合もサーバー上のファイルは変更されません。

Chromeデベロッパーツールを日本語にできますか?

できます。

DevToolsの設定(歯車アイコン、またはF1)→ Preferences → Appearance → Language で「日本語 – Japanese」を選び、「Reload DevTools」をクリックすれば切り替わります。

Chrome 94以降、日本語を含む80以上の言語に対応しています。

スマホ表示へ切り替える方法は?

デバイスモードを使います。

DevToolsを開き、左上のスマホとタブレットが重なったアイコンをクリックするか、Command + Shift + M(Mac)/Ctrl + Shift + M(Windows)を押してください。上部のDimensionsプルダウンから、iPhoneやPixelなどの端末を選べます。

iPhoneのChromeでDevToolsは使えますか?

iPhoneのChrome単体では使えません。

iOSのブラウザにはDevToolsが搭載されていないためです。実機のiPhoneの表示を検証したい場合は、MacとiPhoneをケーブルで接続し、SafariのWebインスペクタを使う方法が一般的です。

PC上での簡易確認であれば、Chromeのデバイスモードで十分なケースが多いです。

Chrome DevToolsでIPアドレスを変更できますか?

できません。

DevToolsで変更できるのは、位置情報・タイムゾーン・ロケール・ユーザーエージェント・通信速度といったブラウザ側の設定だけです。

サーバーから見える公開IPアドレスは変わらないため、IPで地域を判定しているサイトの挙動を確認するには、VPNやプロキシなど別の仕組みが必要です。

Consoleに大量のエラーが表示されても問題ありませんか?

必ずしも問題とは限りません。

Chrome拡張機能や外部の広告・計測タグが出しているエラーが混ざっていることが多いためです。

判断するには、Consoleを一度Clearしてから問題の操作を再現し、その操作で新たに出たエラーだけを見てください。

chrome-extension://content.js を含むログは、拡張機能由来の可能性が高いです。シークレットウィンドウで再確認すると切り分けられます。

Networkに通信が表示されないのはなぜですか?

最も多い原因は、Networkパネルを開く前にページを読み込んでいることです。

Networkパネルは開いている間の通信しか記録しないため、開いた後に再読み込みしてください。

それでも表示されない場合は、録画ボタンが停止していないか、種別フィルターや検索欄に条件が残っていないかを確認してください。広告ブロッカーが通信自体を遮断しているケースもあります。

DevToolsでGooglebotの表示を確認できますか?

完全には確認できません。

ユーザーエージェントをGooglebot相当に変更することはできますが、変わるのは「ブラウザが名乗る名前」だけで、IPアドレスもレンダリングの仕組みも実際のGooglebotとは異なります。

正式に確認したい場合は、Google Search Consoleの URL検査ツールで「公開URLをテスト」を実行し、レンダリング結果を確認してください。

Chrome DevToolsとLighthouseの違いは?

Lighthouseは、DevToolsの中に含まれる機能の1つです。

DevTools全体が「ページの状態を手動で調べるツール群」であるのに対し、Lighthouseは「ページを自動診断してスコアと改善提案を出す機能」です。

原因を自分で追いたいときはElementsやNetwork、改善候補を洗い出したいときはLighthouse、と使い分けてください。

まずはElements・スマホ表示・Console・Networkから覚えよう!

Chromeデベロッパーツールは機能が多く、すべてを覚える必要はありません。

実務で使用頻度が高い順に、次の4つから始めれば十分です。

  1. Elements:HTMLとCSSを一時編集して、文言や色、余白を試す
  2. デバイスモード:スマホ表示の崩れ、横スクロール、CTAの見切れを確認する
  3. Console:JavaScriptエラーを確認し、フォームやボタンの不具合を切り分ける
  4. Network:404・500・リダイレクト・重い通信を確認する

そのうえで、必要になったタイミングで次を追加してください。

  • Application:Cookie、Local Storage、キャッシュの確認
  • Lighthouse:ページ品質の自動診断と改善提案の洗い出し
  • Sources > Overrides:変更を再読み込み後も維持する応用機能

最後にもう一度、最も重要な前提を確認します。

DevToolsは確認と仮説検証のツールであり、テスト環境でも修正ツールでもありません。

本番サイトの修正、PHPの変更、データベースの更新、公開IPアドレスの変更は、いずれもDevToolsだけでは行えません。

だからこそ、何を触っても壊れません。

今すぐ自社サイトを開いて、右クリックから「検証」を押してみてください。

Takuma

見出しの文言をダブルクリックして書き換え、再読み込みで元に戻る、この2分の体験が最初の一歩として最も効果的です。

あわせて読みたい
【SEO担当者必読】E-E-A-T完全ガイド|経験・専門性・権威性・信頼性で差をつけろ! 本記事は、「searchengineland」の最新記事を翻訳し、独自の意見を加えたものです。 SEOにおいて「E-E-A-T(経験・専門性・権威性・信頼性)」の重要性は、年々増してい...

この記事が気に入ったら
いいね または フォローしてね!

この記事を書いた人

Takuma Oka Takuma Oka 外資系SEOスペシャリスト

SEO・AI・web3が大好きなWebマーケターです。フィリピン(マニラ)外資系企業で『日本人SEOスペシャリスト』としてフルリモート勤務。サイトM&AやKindle出版、Udemy講師の経験も。元航空自衛官。主に東南アジア諸国を拠点にしています。SEO歴は10年目です。趣味は、中国語の勉強とランニング。

目次