Search Consoleでよくあるエラー一覧｜原因と対処法をまとめて解説

Search Consoleで表示される404、ソフト404、サーバーエラー、インデックス未登録など、よくあるエラーや問題を一覧で紹介。原因の調べ方から正しい対処法、修正後の確認手順まで初心者向けにわかりやすく解説します。

Search Consoleを開いたとき、「404」「ソフト404」「サーバーエラー」「クロール済み – インデックス未登録」などの表示を見て、「すぐに修正しなければならないの？」と迷うことはありませんか。Search Consoleにはさまざまなエラーや除外理由が表示されますが、すべてが問題とは限らず、原因によって対処方法も異なります。この記事では、Search Consoleでよく見かけるエラーやインデックス登録の問題を一覧で整理し、それぞれの原因と対処法を初心者にもわかりやすく解説します。エラーを見つけたときの確認手順や、やってはいけない対処法も紹介しますので、サイト改善にぜひ役立ててください。

Search Consoleのエラーとは？

Google Search Consoleを利用していると、「404」「サーバーエラー（5xx）」「リダイレクト エラー」「クロール済み – インデックス未登録」など、さまざまな表示を目にします。

初めて見ると「サイトに大きな問題が起きているのでは？」と心配になるかもしれません。しかし、Search Consoleに表示される項目は、すべてが修正しなければならないエラーというわけではありません。

意図的に削除したページの404や、noindexを設定したページなど、サイト運営者の意図どおりの状態がレポートに表示されることもあります。

まずは表示された内容と対象URLを確認し、「正常な状態なのか」「修正が必要な問題なのか」を切り分けることが大切です。

Search Consoleで表示されるエラーとは何か

Search Consoleは、Google検索におけるWebサイトの状態を確認できる無料のツールです。

インデックス登録、クロール、検索パフォーマンス、サイトマップ、Core Web Vitalsなど、SEOやサイト管理に役立つさまざまな情報を確認できます。

その中で問題を発見する手がかりになるのが、エラーやインデックス登録に関する表示です。

例えば、次のような状態があります。

• ページが見つからない
• Googlebotがページへアクセスできない
• サーバーが正常に応答しない
• リダイレクトが正常に処理されない
• robots.txtでクロールが制限されている
• noindexが指定されている
• クロールされたがインデックス登録されていない
• Googleが別のURLを正規ページとして選択している

例えば、公開中の記事へGooglebotがアクセスしたときにサーバー側で問題が発生し、HTTPステータスコード「5xx」が返されれば、Googleが正常にページを取得できない可能性があります。

一方、管理者が意図的に削除したページが404を返しているのであれば、必ずしも異常とはいえません。

つまり、表示名だけで判断せず、「なぜその状態になっているのか」を確認することが重要です。

エラーが発生する主な原因

Search Consoleで問題が表示される原因は一つではありません。

ページそのものの問題だけでなく、WordPressの設定、サーバー、robots.txt、リダイレクト、サイト構造など、さまざまな要因が関係します。

主な原因

原因	具体例	確認するポイント
ページ削除	404	意図的に削除したか
URL変更	404・リダイレクト	301が適切か
サーバー障害	5xx	サーバーの状態
クロール制御	robots.txt	Googlebotを遮断していないか
インデックス制御	noindex	意図した設定か
リダイレクト設定	リダイレクトエラー	転送先・ループの有無
コンテンツ	インデックス未登録	内容・重複・検索意図
正規化	canonical関連	正規URLの指定

例えば、記事URLを変更したのに旧URLから新URLへの301リダイレクトを設定していなければ、旧URLが404になることがあります。

また、WordPressの記事を公開しているつもりでも、誤ってnoindexを設定していれば、そのページがGoogle検索に表示されない原因になります。

このように、**「Search Consoleに問題が出た→すぐ修正」ではなく、「原因を確認→必要性を判断→修正」**という順番で考えましょう。

エラーと警告・除外の違い

Search Consoleを使ううえで特に注意したいのが、表示されている項目すべてを「エラー」と考えないことです。

Search Consoleの画面やレポートでは、問題の種類や状態に応じてさまざまな理由が表示されます。

特に「ページのインデックス登録」では、インデックスされていないURLについて、その理由を確認できます。

例えば、

「noindexタグによって除外されました」

と表示されていても、自分で意図的にnoindexを設定したページなら、基本的には予定どおりの状態です。

また、

「見つかりませんでした（404）」

についても、すでに不要になって意図的に削除したページなら、404自体を無理に直す必要はありません。

判断の考え方

表示された項目を確認
　↓
そのURLは検索結果に載せたい？

はい
→ 原因を調べ、必要に応じて修正

いいえ
→ 意図した状態なら対応不要の場合もある

つまり、

「インデックスされていない＝エラー」

ではありません。

検索結果に載せたいページなのにインデックスされていない場合に、原因を詳しく調べることが重要です。

エラーを放置するとSEOに影響する？

問題の内容によってはSEOや検索流入に影響する可能性があります。

例えば、検索結果に表示させたい重要なページがサーバーエラーによってGooglebotから取得できない状態が長期間続けば、クロールやインデックス登録に問題が生じる可能性があります。

また、重要なページを誤ってnoindexにしていれば、そのページはGoogle検索に掲載されなくなる可能性があります。

優先的に確認したいケース

• 公開中の重要記事が5xxになっている
• 検索結果に載せたいページにnoindexが付いている
• 重要ページがrobots.txtでクロールを制限されている
• リダイレクトエラーが発生している
• 多数の重要ページが突然404になった
• 公開記事がインデックス登録されない
• XMLサイトマップ内の重要URLに問題がある

一方で、意図的に削除したページの404などは、正常なサイト運営でも発生します。

SEOへの影響を判断する早見表

状態	確認の優先度	考え方
重要記事の5xx	高	早めに原因を確認
重要記事のnoindex	高	設定ミスなら修正
リダイレクトエラー	高	転送設定を確認
重要記事のインデックス未登録	高	原因を調査
意図的に削除した404	低	通常はそのままでよい
意図したnoindex	低	正常なら修正不要
適切なcanonicalの代替ページ	低	意図どおりなら問題なし

大切なのは、エラーの「数」だけを減らすことではありません。

Google検索に掲載したい重要なページが、正常にクロール・インデックス登録される状態を保つことを優先しましょう。

初心者が最初に確認する場所

Search Consoleで問題を見つけたら、初心者の方はまず**「ページのインデックス登録」レポート**を確認するとわかりやすいでしょう。

基本的な流れは次のとおりです。

① Search Consoleへログイン
　↓
② 対象のプロパティを選択
　↓
③「インデックス作成」→「ページ」を開く
　↓
④ インデックス未登録の理由を確認
　↓
⑤ 対象URLを確認
　↓
⑥ 必要に応じてURL検査ツールで詳しく調べる

特に最初は、エラー件数だけを見るのではなく、**「どのURLで、なぜインデックスされていないのか」**を確認してください。

初心者向け確認チェックリスト

• □ 検索結果に載せたいページか
• □ URLは現在も存在するか
• □ 実際にページを開けるか
• □ 404・5xxなどになっていないか
• □ noindexを設定していないか
• □ robots.txtでクロールを妨げていないか
• □ リダイレクト先は正常か
• □ canonicalの指定は適切か
• □ XMLサイトマップに必要なURLが含まれているか
• □ URL検査ツールで状態を確認したか

例えば、「クロール済み – インデックス未登録」が100件あったとしても、100件すべてを同じ方法で修正するわけではありません。

重要記事なのか、重複ページなのか、古いURLなのかなど、URLごとの役割を確認して対応を決めることが大切です。

Search Consoleで問題を見つけたときの基本フロー

最後に、初心者向けに流れを整理しておきましょう。

Search Consoleで問題を発見
　　　　↓
対象URLを確認
　　　　↓
検索結果に載せたいページか判断
　　　　↓
実際のページを開く
　　　　↓
URL検査ツールなどで原因を調べる
　　　　↓
必要なものだけ修正する
　　　　↓
修正後に状態を再確認する

この流れを覚えておけば、Search Consoleに大量のURLが表示されても慌てにくくなります。

「エラーの数をゼロにする」のではなく、「重要なページに問題がない状態にする」ことを目標にしましょう。

インデックス登録でよくあるエラー・問題

Search Consoleの「ページのインデックス登録」レポートでは、Googleがページをインデックスできなかった理由や、インデックス対象になっていないURLの状態を確認できます。

代表的なものが、404、ソフト404、サーバーエラー（5xx）、robots.txtによるブロック、noindex、リダイレクトエラーなどです。

ただし、これらが表示されたからといって、すべて修正する必要があるわけではありません。

例えば、自分で削除した不要ページが404になっている場合や、意図的にnoindexを設定したページであれば、その状態が正常なこともあります。

まずは次の表で違いを確認しましょう。

表示・問題	主な意味	修正の判断
404	ページが存在しない	意図しない404なら確認
ソフト404	実質的に内容がないとGoogleが判断	内容やHTTPステータスを確認
5xx	サーバー側の問題	重要ページなら優先的に確認
robots.txtによるブロック	クロールが制限されている	意図した設定か確認
noindex	インデックスしない指定	意図した設定なら問題なし
リダイレクトエラー	転送を正常に処理できない	設定を確認・修正

それぞれ詳しく見ていきましょう。

「見つかりませんでした（404）」が表示される

「見つかりませんでした（404）」は、GooglebotがURLへアクセスしたときに、サーバーから**HTTPステータスコード404（Not Found）**が返された状態です。

簡単にいうと、

「そのURLにページがありません」

ということです。

例えば、

Example Domain

example.com

という記事をWordPressから削除すると、そのURLへアクセスした際に404が返される場合があります。

404が発生する主な原因

• 記事を削除した
• URLを変更した
• 内部リンクのURLを間違えた
• 古いURLが残っている
• 外部サイトから間違ったURLでリンクされている
• パーマリンクを変更した

ここで大切なのは、404＝必ず修正すべきSEOエラーではないという点です。

修正しなくてもよい例

不要になった記事を意図的に削除し、代替ページもない場合です。

この場合、404は「ページが存在しない」ことを正しく伝えているため、通常はそのままで問題ありません。

修正を検討する例

公開しているはずの記事が404になっている場合です。

例えば、

旧URL
example.com/1234/

↓ URL変更

新URL
example.com/5678/

となったのに適切な転送が設定されていない場合は、旧URLへの内部リンクを修正し、必要に応じて301リダイレクトを検討します。

404が表示されたときの確認ポイント

• URLを実際に開く
• 意図的に削除したページか確認する
• 内部リンクが残っていないか確認する
• 新しい移転先があるか確認する
• 必要なら301リダイレクトを検討する

【ブログカード設置おすすめ位置】

404の詳しい原因や対処方法について解説した既存記事がある場合は、ここに内部リンクを置くと非常に自然です。

「404エラーの原因やSearch Consoleでの確認方法については、こちらの記事で詳しく解説しています。」

「ソフト404」が表示される

ソフト404は、サーバー上では正常なページとして**200（OK）**などを返しているものの、Googleがページ内容を見て「実質的には存在しないページと同じではないか」と判断した状態です。

通常の404とは少し違います。

404とソフト404の違い

種類	HTTPステータス	ページの状態
404	404	ページが存在しない
ソフト404	200などの場合がある	内容がない・エラーページのように見える

例えば、削除した商品のURLを開いたとき、

「商品はありません」

という文章だけ表示されるにもかかわらず、サーバーが200を返している場合などが考えられます。

また、内容が極端に少ないページなどをGoogleがソフト404と判断する場合もあります。

主な原因

• ページ内容がほとんどない
• 「ページがありません」と表示しながら200を返している
• 空に近いカテゴリーページ
• 商品・記事削除後も空ページが残っている
• Googleがページに十分な価値がないと判断した

対処方法

本当にページが存在しないのであれば、適切に404または410を返します。

一方、検索結果に掲載したい正常なページなら、

• 本文が十分にあるか
• ページの内容が検索意図に合っているか
• 読者に役立つ独自情報があるか
• ページが正常に表示されているか

などを確認しましょう。

単純に文章量を増やせば解決するとは限りません。そのページが何を提供するページなのかを明確にすることが大切です。

「サーバーエラー（5xx）」が表示される

サーバーエラー（5xx）は、Googlebotがページへアクセスしたときに、サーバー側の問題によって正常にページを取得できなかったことを示します。

代表的なHTTPステータスコードには、

• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

などがあります。

例えば、アクセス集中やサーバー障害によってページを表示できなければ、Googlebotもページを取得できない可能性があります。

主な原因

• レンタルサーバーの一時的な障害
• サーバー負荷
• PHPエラー
• WordPressプラグインの不具合
• テーマの不具合
• データベース接続エラー
• タイムアウト

5xxが一時的に発生しただけなら、すぐ大きな問題になるとは限りません。

しかし、重要な記事で長期間5xxが続く場合は、Googleが正常にクロールできないため、早めに原因を確認しましょう。

確認手順

① 対象URLを実際に開く
↓
② URL検査ツールなどで状態を確認
↓
③ WordPress・プラグインを確認
↓
④ サーバー障害情報やログを確認
↓
⑤ 必要ならレンタルサーバーへ問い合わせる

複数のURLで同時に5xxが発生している場合は、個別記事よりもサーバーやWordPress全体の問題を疑った方がよいでしょう。

「robots.txtによりブロックされました」が表示される

robots.txtは、検索エンジンのクローラーに対して、サイト内のどの場所をクロールしてよいか、または制限するかを伝えるファイルです。

例えばrobots.txtで特定のディレクトリをクロール禁止にしている場合、Googlebotがページ内容を取得できないことがあります。

確認したいこと

• 自分で意図してブロックしているか
• 公開記事まで誤って対象になっていないか
• WordPressの設定変更後に発生していないか
• robots.txtの記述が適切か
• 検索結果に表示させたいページではないか

特に注意したいのが、

「検索結果から消したいからrobots.txtでブロックする」

という使い方です。

robots.txtは基本的にクロールを制御するための仕組みであり、URLをGoogle検索から確実に削除するための方法ではありません。

検索結果に表示させたくないページには、目的に応じてnoindexなど別の方法を検討します。

また、noindexをページに設定してもrobots.txtでクロールを遮断していると、Googleがそのnoindexを確認できない場合があります。

「noindexタグによって除外されました」が表示される

noindexは、

「このページを検索結果に掲載しないでください」

と検索エンジンへ伝えるための指定です。

そのため、Search Consoleに「noindexタグによって除外されました」と表示されても、自分で意図的にnoindexを設定しているのであれば基本的に問題ありません。

例えば、

• サイト内検索結果
• 検索流入を必要としない補助ページ
• 意図的に検索結果から除外したページ

などでnoindexを使う場合があります。

問題なのは、検索結果に表示させたい重要記事へ誤ってnoindexを設定しているケースです。

確認の考え方

noindexが表示された
↓
検索結果に載せたいページ？

いいえ
→ 意図どおりなら基本的に修正不要

はい
→ noindex設定を確認・解除

WordPressやテーマ、SEOプラグインなどでnoindexを設定している場合は、その設定を確認してください。

Cocoonを使用している場合も、投稿・固定ページ側のSEO関連設定を確認しておくとよいでしょう。

noindexを解除した後は、Googleが再クロールして変更を認識するまで時間がかかることがあります。

「リダイレクトエラー」が表示される

リダイレクトは、あるURLへアクセスしたユーザーや検索エンジンを別のURLへ転送する仕組みです。

例えば、

example.com/old-page/

↓ 301リダイレクト

example.com/new-page/

という形です。

しかし、リダイレクト設定に問題があると、Googleが転送先へ正常に到達できず、「リダイレクトエラー」などとして表示されることがあります。

主な原因

• リダイレクトループ
• リダイレクトチェーンが長すぎる
• 転送先URLが存在しない
• URL設定を間違えている
• http・httpsの設定に問題がある
• wwwあり・なしの転送設定に問題がある

特にわかりやすいのがリダイレクトループです。

ページA → ページB → ページA → ページB……

のように転送が繰り返されると、正常なページへ到達できません。

また、

ページA → B → C → D → 最終ページ

のように何段階も転送するより、

ページA → 最終ページ

と直接転送する方がシンプルです。

リダイレクトエラー確認手順

• □ 元URLを確認する
• □ 転送先URLを確認する
• □ 転送先ページが正常に開くか確認する
• □ リダイレクトループがないか確認する
• □ 不要な多段リダイレクトがないか確認する
• □ WordPressやサーバーの転送設定を確認する

URLを変更した記事や統合した記事でリダイレクトエラーが発生している場合は、ユーザーにも影響するため早めに確認しましょう。

インデックス登録でよくある問題の対処法早見表

最後に、6つの代表的な問題を整理しておきます。

表示	まず確認すること	主な対処
404	意図的な削除か	不要ならそのまま、必要なら復旧・転送
ソフト404	ページ内容とHTTP応答	内容改善または404・410
5xx	サーバー状態	サーバー・WordPressを確認
robots.txt	意図した制限か	必要なら記述を修正
noindex	意図した指定か	必要ページなら解除
リダイレクトエラー	転送経路	転送設定を修正

初心者が覚えておきたい判断方法

エラーや問題を見つけたら、

① そのURLは検索結果に載せたいか
↓
② 現在の表示は意図したものか
↓
③ 実際にURLを開いて正常か確認
↓
④ 必要なものだけ修正する

という順番で判断しましょう。

特に404とnoindexは「表示されている＝異常」とは限りません。

一方、検索結果に表示させたい重要記事の5xxやリダイレクトエラーなどは、クロールやインデックス登録に影響する可能性があるため、優先的に確認することをおすすめします。

クロール済み・検出済みなのにインデックスされない原因

Search Consoleの「ページのインデックス登録」を確認すると、

• 「クロール済み – インデックス未登録」
• 「検出 – インデックス未登録」

と表示されることがあります。

どちらも現時点ではGoogleのインデックスに登録されていない状態ですが、意味は異なります。

簡単にいうと、

クロール済み – インデックス未登録
→ Googleはページを訪問したが、現在はインデックスしていない

検出 – インデックス未登録
→ GoogleはURLの存在を知っているが、まだクロールしていない

という違いです。

まずはこの違いを理解してから、対象URLの状態、記事内容、重複ページ、内部リンクなどを確認しましょう。

2つの違い早見表

状態	GoogleはURLを認識	クロール	インデックス
クロール済み – インデックス未登録	○	○	×
検出 – インデックス未登録	○	×	×

どちらの場合も、「インデックス登録をリクエストすれば必ず解決する」というものではありません。

原因を確認して、必要な改善を行うことが大切です。

「クロール済み – インデックス未登録」とは

「クロール済み – インデックス未登録」とは、Googleがそのページをすでにクロールしたものの、現時点ではインデックスに登録していない状態です。

Google公式では、今後インデックスされる場合も、されない場合もあり、この状態だけを理由に再クロールのためURLを再送信する必要はないと説明しています。

つまり、

URLを発見
↓
Googlebotがクロール
↓
ページを取得
↓
現在はインデックス未登録

という状態です。

検索結果に表示させたい重要な記事がこの状態になっている場合は、まずページを確認しましょう。

確認したいポイント

• 記事内容は読者の疑問に十分答えているか
• 他の記事と内容が似すぎていないか
• ページが正常に表示されるか
• canonicalは適切か
• 内部リンクでつながっているか
• サイト内に似たテーマの記事が乱立していないか

例えば、

「トマトの育て方」

「初心者向けトマトの育て方」

「家庭菜園でトマトを育てる方法」

という非常によく似た記事が複数ある場合、内容や検索意図が重複していないか確認する必要があります。

ただし、「クロール済み – インデックス未登録」と表示された理由をSearch Consoleがすべて詳しく説明してくれるわけではありません。

そのため、表示だけを見て「低品質記事だ」と断定しないことも重要です。

「クロール済み – インデックス未登録の原因や具体的な改善方法については、こちらの記事で詳しく解説しています。」

「検出 – インデックス未登録」とは

「検出 – インデックス未登録」は、GoogleがURLの存在を認識しているものの、まだページをクロールしていない状態です。

例えば、XMLサイトマップや内部リンクなどを通じてGoogleがURLを発見していても、すぐにGooglebotが訪問するとは限りません。

Google公式では、GoogleがURLを発見したもののまだクロールしておらず、サイトへの負荷などを考慮してクロールを後回しにする場合があると説明されています。

状態のイメージ

XMLサイトマップ・内部リンクなど
↓
GoogleがURLを発見
↓
まだクロールしていない
↓
検出 – インデックス未登録
↓
後日クロールされる可能性

「検出 – インデックス未登録」があるからといって、すぐにサイトに重大な問題があるとは限りません。

ただし、重要記事が長期間この状態にある場合は、

• XMLサイトマップ
• 内部リンク
• サーバーの応答状況
• 大量の不要URLが生成されていないか
• サイト構造

などを確認してみましょう。

クロール済みとの違い

検出済み
→ Googleはまだページ内容を取得していない

クロール済み
→ Googleはすでにページを取得している

この違いを理解すると、確認すべきポイントも見つけやすくなります。

記事の品質や内容を確認する

「クロール済み – インデックス未登録」の重要記事が多い場合は、記事内容を見直すことも大切です。

ただし、ここでいう「品質」は単純な文字数ではありません。

例えば、2,000文字書けばインデックスされ、1,000文字ならインデックスされない、という基準があるわけではありません。

重要なのは、検索する読者にとって役立つ内容になっているかです。

記事内容の確認ポイント

• 検索意図に答えている
• タイトルと本文の内容が一致している
• 読者の疑問を具体的に解決している
• 独自の説明や具体例がある
• 古い情報を更新している
• 見出し構成がわかりやすい
• 他の記事を言い換えただけになっていない
• 不必要に同じ説明を繰り返していない

例えば、

「Search Consoleで404エラーが出る原因」

を知りたい読者に対して、Search Consoleの登録方法ばかり長く説明していては、検索意図とずれてしまいます。

その場合は、

404とは何か
↓
なぜ表示されたのか
↓
修正が必要か
↓
具体的な対処方法
↓
修正後の確認

というように、読者が知りたい順番で情報を整理するとよいでしょう。

大切なのは、文字数を増やすことではなく、ページを訪れた読者が「この記事で疑問が解決した」と感じられる内容にすることです。

重複コンテンツや類似ページを確認する

サイトの記事数が増えてくると、意図せず似た内容の記事が増えることがあります。

例えば、

記事A：メロンが甘くならない原因

記事B：メロンを甘く育てる方法

記事C：メロンの糖度を上げる方法

のようにテーマが近い場合です。

それぞれ明確に異なる検索意図へ答えていれば問題ありませんが、本文の大部分が同じ内容なら、記事同士の役割を見直した方がよい場合があります。

類似ページの確認ポイント

• タイトルが似すぎていないか
• 狙っている検索キーワードが同じではないか
• H2・H3がほぼ同じではないか
• 本文の内容が重複していないか
• 同じ検索意図の記事が複数ないか
• どの記事を中心記事にするか明確か

内容が大きく重複している場合は、

記事を統合する

役割を明確に分ける

不要なページを整理する

などを検討します。

ただし、似たキーワードを使っているだけで、すぐに「重複コンテンツ」と判断する必要はありません。

それぞれの記事が異なる疑問へ答えているかを見ることが重要です。

内部リンク・サイト構造を見直す

重要な記事なのに、サイト内のどこからも内部リンクされていない場合は、読者だけでなく検索エンジンもページを見つけにくくなります。

そこで、関連する既存記事から自然な内部リンクを追加します。

例えば、

Search Console完全ガイド
↓
Search Consoleのエラー解説記事
↓
404エラーの詳しい記事

というように、関連する記事同士をつなぎます。

内部リンクで確認したいポイント

• 関連記事からリンクされているか
• 孤立した記事になっていないか
• カテゴリーが適切か
• 重要記事へ複数の関連ページからリンクできるか
• アンカーテキストからリンク先の内容が分かるか
• サイトの深い階層に埋もれていないか

例えば、

「詳しくはこちら」

だけではなく、

「Search Consoleの404エラーの原因と対処法はこちら」

のようにすると、読者にもリンク先の内容が伝わりやすくなります。

内部リンクは単に本数を増やすのではなく、関連性の高い記事同士を自然につなぐことがポイントです。

インデックス登録をリクエストする

記事内容や技術的な設定を確認・改善したら、必要に応じてSearch ConsoleのURL検査ツールからインデックス登録をリクエストできます。

基本的な流れ

① Search Consoleを開く
↓
② 上部のURL検査欄へURLを入力
↓
③ URLの状態を確認する
↓
④ 必要な修正を行う
↓
⑤「インデックス登録をリクエスト」を選択
↓
⑥ Googleの再クロールを待つ

ただし、ここで重要なのは、

インデックス登録をリクエスト
＝
必ずインデックスされる

ではないことです。

Google公式でも、インデックス登録をリクエストしても、Googleのインデックスへの登録は保証されないと案内しています。

また、同じURLについて何度もリクエストしても、クロールが早くなるわけではありません。

大量のURLを一つずつリクエストするのではなく、複数ページをGoogleへ知らせる場合はXMLサイトマップも活用しましょう。

リクエスト前チェックリスト

• □ ページが正常に表示される
• □ 検索結果に載せたいページである
• □ noindexになっていない
• □ Googleがクロール可能である
• □ canonicalを確認した
• □ 記事内容を確認した
• □ 重複・類似ページを確認した
• □ 内部リンクを確認した
• □ XMLサイトマップを確認した

これらを確認してからインデックス登録をリクエストする方が、単純にリクエストを繰り返すより適切です。

インデックス未登録の原因と確認方法早見表

状態・原因	確認すること	主な対応
クロール済み – インデックス未登録	記事内容・重複・技術設定	品質・役割を見直す
検出 – インデックス未登録	クロール状況・サイト構造	内部リンクなどを確認
内容が不十分	検索意図・具体性	内容を改善
類似記事が多い	検索意図・重複	統合・役割分担
内部リンクが少ない	サイト内の導線	関連記事からリンク
修正済みの重要記事	URL検査	必要なら登録をリクエスト

初心者が覚えておきたい対処の順番

インデックス未登録を発見
↓
クロール済みか検出済みか確認
↓
検索結果に載せたいURLか確認
↓
記事内容・重複・技術設定を確認
↓
内部リンク・サイト構造を確認
↓
必要な修正を行う
↓
必要に応じてインデックス登録をリクエスト
↓
一定期間後にSearch Consoleで再確認

この順番なら、「未登録を見つけるたびに、とりあえずインデックス登録をリクエストする」という対応を避けられます。

重複・canonical関連でよくある問題

Search Consoleの「ページのインデックス登録」を確認していると、

• 「重複しています。Googleにより、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」
• 「代替ページ（適切なcanonicalタグあり）」

といった表示が出ることがあります。

文章が長いため、「重大なSEOエラーなのでは？」と思うかもしれませんが、重複ページが存在すること自体が、必ずしも問題というわけではありません。

Googleは内容が同一または非常によく似た複数のURLを発見すると、その中から検索結果に表示する代表的なURL（正規URL）を選びます。この処理を**正規化（canonicalization）**といいます。

例えば、ほぼ同じページへ複数のURLからアクセスできる場合でも、Googleは代表となる1つのURLを選んで検索結果に表示しようとします。

まずは、代表的な表示の意味を整理しておきましょう。

Search Consoleの表示	主な意味	基本的な対応
Googleが別の正規URLを選択	指定したURLとGoogleの判断が異なる	URL検査で確認
代替ページ（適切なcanonicalタグあり）	別URLを正規URLとして適切に指定	通常は対応不要
重複・正規URL未指定	Googleが正規URLを選択	意図どおりか確認
正規URLが想定と違う	正規化シグナルが一致していない可能性	設定・リンク等を確認

大切なのは、Search Consoleの表示を消すことではなく、自分が検索結果に表示させたいURLとGoogleが選んだURLが一致しているかを確認することです。

「重複しています。Googleにより、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」とは

この表示は、自分ではあるURLを正規ページとして示しているものの、Googleが別のURLの方を正規ページとして適切だと判断した状態です。

例えば、

自分が正規URLとして示したページ

Example Domain

example.com

に対して、

Googleが選んだ正規URL

Example Domain

example.com

となっているようなケースです。

Googleはこの場合、自分が指定したURLではなく、Googleが正規URLとして選択したページをインデックスします。

まず確認すること

Search ConsoleのURL検査ツールで、

• 「ユーザーが指定した正規URL」
• 「Googleが選択した正規URL」

を比較します。

URL検査
↓
ユーザーが指定した正規URLを確認
↓
Googleが選択した正規URLを確認
↓
2つのページ内容を比較
↓
Googleの選択が適切か判断

Googleが選んだURLが自分の意図と一致する内容であれば、必ずしも修正する必要はありません。

一方、本来インデックスしてほしい重要記事ではないURLが選ばれている場合は、canonical設定や内部リンク、サイトマップ、ページ内容などを確認します。

Google公式でも、この表示が出た場合はURL検査ツールでGoogleが選択した正規URLとユーザー指定の正規URLを確認するよう案内しています。

「代替ページ（適切なcanonicalタグあり）」とは

「代替ページ（適切なcanonicalタグあり）」は、そのURLとは別のページが正規ページとして適切に指定されている状態です。

これは基本的にエラーではありません。

例えば、

ページA（正規ページ）

Example Domain

example.com

ページB（代替ページ）

Example Domain

example.com

があり、ページBからページAへ適切にcanonicalが設定されている場合です。

Googleは、

ページBはページAの代替ページ
↓
ページAを正規URLとして扱う
↓
ページAをインデックス

という処理を行います。

Googleの公式ヘルプでも、正規ページへのリンクが正しく指定され、その正規ページがインデックスされている場合、追加対応は必要ないと案内されています。

したがって、Search Consoleに「代替ページ（適切なcanonicalタグあり）」が表示されていても、

• 正規URLが意図したページになっている
• 正規ページが正常にインデックスされている
• 代替ページを検索結果に出す必要がない

のであれば、基本的にはそのままで問題ありません。

canonicalタグとは何か

canonicalタグ（正規化タグ）は、同一または非常によく似た内容を持つ複数のURLがある場合に、**「このURLを代表的なURLとして扱ってほしい」**と検索エンジンへ伝えるために使用します。

HTMLでは一般的にrel="canonical"という形で指定されます。

例えば、同じ内容のページに複数のURLが存在するとします。

URL①

Example Domain

example.com

URL②

Example Domain

example.com

内容がほぼ同じで、URL①を正規URLとして扱ってほしい場合、URL②側からURL①をcanonicalとして示すことができます。

canonicalの主な役割

• 重複・類似URLの代表ページを示す
• 検索結果に表示してほしいURLを示す
• 複数URLに分散するシグナルをまとめやすくする
• 重複URLへの不要なクロールを抑えやすくする
• URLごとに分散する計測を整理しやすくする

ただし、ここで重要なのは、

canonicalを指定したURLをGoogleが必ず正規URLとして採用するわけではない

という点です。

canonicalはGoogleにとって強いシグナルですが、Googleは複数の情報を使って最終的な正規URLを判断します。

そのため、

canonical指定URL ≠ 必ずGoogleが選ぶURL

と覚えておきましょう。

Googleが別のURLを正規URLに選ぶ原因

canonicalを設定しているにもかかわらず、Googleが別のURLを正規URLとして選択することがあります。

この場合は、サイト内でGoogleへ送っている正規化のシグナルが一致しているか確認します。

確認したいポイント

• canonicalの指定先が正しいか
• canonical先と元ページの内容が十分似ているか
• 内部リンクがどのURLへ向いているか
• XMLサイトマップにどのURLを掲載しているか
• リダイレクト設定に矛盾がないか
• httpとhttpsなど複数URLが存在していないか
• URLパラメータなどで類似ページが生成されていないか

例えば、

canonicalではページAを指定

しているのに、

サイト内の内部リンクはページBばかり

という状態では、サイト側がGoogleへ送る情報が分かりにくくなります。

また、

XMLサイトマップ：ページA

canonical：ページB

内部リンク：ページC

のようにバラバラにするのも避けた方がよいでしょう。

正規化シグナルをそろえるイメージ

canonical
　　↓
正規URL A

内部リンク
　　↓
正規URL A

XMLサイトマップ
　　↓
正規URL A

リダイレクト（必要な場合）
　　↓
正規URL A

このように、検索結果へ表示させたいURLをサイト全体で一貫させることがポイントです。

Google公式では、正規化の方法について、リダイレクトとrel="canonical"は強いシグナル、サイトマップへの掲載はそれより弱いシグナルと説明しています。

また、複数の方法を一貫して組み合わせることで、希望する正規URLが選ばれる可能性を高められます。

重複ページを整理する方法

重複ページを見つけたら、すぐに削除するのではなく、なぜ複数URLが存在するのかを確認します。

まず、次の3つに分けると判断しやすくなります。

① 必要な代替・類似ページ

別URLが必要で、内容がほぼ同じページです。

→ 適切なcanonicalを設定して正規ページを示します。

② 完全に不要な重複URL

同じページへ複数URLでアクセスでき、別URLを残す必要がない場合です。

→ 状況に応じて301リダイレクトなどを検討します。

③ それぞれ検索結果に表示したいページ

似ているものの、それぞれ別の検索意図へ答える重要ページです。

→ 内容や役割を明確に分けます。

例えば、

記事A：Search Consoleの404エラーの原因

記事B：Search Consoleのエラー一覧

であれば、テーマは似ていますが役割を分けられます。

記事Aでは404を詳しく説明し、記事Bでは404・5xx・noindex・リダイレクトなどを一覧で解説する、といった形です。

この場合、単純にcanonicalで一方へまとめるのではなく、それぞれの記事の検索意図と内容を明確にすることが重要です。

重複ページ整理早見表

ページの状態	主な対応
必要な代替ページ	canonicalを確認
完全に不要な重複URL	301リダイレクトなどを検討
同じ記事のURL違い	正規URLへ統一
類似しているが別目的の記事	内容・検索意図を明確化
Googleの正規URLが意図どおり	基本的に対応不要
Googleの正規URLが意図と違う	正規化シグナルを確認

重複・canonical問題の確認手順

Search Consoleでcanonical関連の表示を見つけたら、次の順番で確認しましょう。

① 対象URLを確認
↓
② URL検査ツールを開く
↓
③ ユーザー指定の正規URLを確認
↓
④ Googleが選択した正規URLを確認
↓
⑤ 両ページの内容を比較
↓
⑥ canonical・内部リンク・サイトマップを確認
↓
⑦ 必要なら修正
↓
⑧ Googleの再クロール・再評価を待つ

修正後すぐにSearch Consoleの表示が変わらなくても、何度も設定を変更する必要はありません。

Googleが再クロールして正規URLを再評価するまで、一定の時間が必要になる場合があります。

初心者が覚えておきたい3つのポイント

• 「代替ページ（適切なcanonicalタグあり）」は基本的にエラーではない
• canonicalを指定しても、Googleが必ずそのURLを正規URLに選ぶとは限らない
• canonical・内部リンク・サイトマップなどで正規URLを一貫させることが大切

特に、

「Search Consoleに重複と表示された＝SEOペナルティ」

と考える必要はありません。

Googleは、重複コンテンツがサイト内に存在すること自体は正常に起こり得るとしており、重複ページがあることそのものはスパムポリシー違反ではありません。

大切なのは、検索結果に表示させたい代表URLが適切にGoogleへ伝わっているかです。

XMLサイトマップでよくあるエラー

XMLサイトマップは、サイト内にある重要なURLをGoogleへ知らせるためのファイルです。

Search Consoleの「サイトマップ」では、送信したXMLサイトマップをGoogleが取得・処理できたか確認できます。

ただし、

• 「取得できませんでした」と表示される
• サイトマップを読み込めない
• サイトマップ内に404ページが含まれている
• 古いURLが残っている

といった問題が発生することがあります。

サイトマップに問題があるからといって、サイト全体がすぐ検索結果から消えるわけではありません。しかし、Googleに重要なURLを正しく伝えるためにも、エラーの原因を確認しておくことが大切です。

まず、よくある問題を整理しておきましょう。

状態	主な原因	確認すること
取得できませんでした	URL間違い・アクセス不可など	サイトマップURL
404	サイトマップが存在しない	URL・生成状況
XML解析エラー	XMLの形式に問題	サイトマップの内容
404 URLを含む	削除済みURLが残っている	サイトマップ内URL
古いURLを含む	URL変更が反映されていない	サイトマップ更新
正常	Googleが取得・処理できた	基本的にそのままでよい

「取得できませんでした」と表示される

Search Consoleのサイトマップレポートで「取得できませんでした」と表示された場合は、Googleがサイトマップを取得できていない状態を示します。

Google公式では、主な原因として次のようなものが案内されています。

• サイトマップURLが間違っている
• サイトマップURLが404を返している
• robots.txtによって取得が妨げられている
• サーバー側で一時的な問題が発生している
• XMLサイトマップ自体に問題がある

まずはSearch Consoleだけを見るのではなく、送信したサイトマップURLをブラウザで直接開いて確認してみましょう。

例えば、

Example Domain

example.com

を送信したのであれば、このURLを実際に開きます。

基本的な確認手順

「取得できませんでした」を確認
↓
送信したサイトマップURLを確認
↓
ブラウザで直接開く
↓
サイトマップが存在するか確認
↓
Googleが取得できる状態か確認
↓
原因を修正
↓
Search Consoleで再送信

サイトマップがブラウザで開けても、それだけでGooglebotからも必ず取得できるとは限りません。

必要に応じてURL検査のライブテストなどを使い、Googleから取得可能な状態か確認しましょう。

なお、一時的な問題で取得できなかった場合は、Googleが再度取得を試みることもあります。

サイトマップが読み込まれない原因

サイトマップが読み込まれない原因は、URLの入力ミスだけではありません。

XMLの記述やサーバーの応答なども関係します。

主な原因

原因	具体例
URL間違い	存在しないsitemap.xmlを送信
404	サイトマップファイルが存在しない
robots.txt	Googlebotのアクセスを妨げている
サーバー問題	5xxなどが発生
XML形式	構文エラーがある
URL記述	使用できない文字などがある
アクセス制限	ログインしなければ見られない

Googleのサイトマップには形式上のルールがあります。

例えば、1つのサイトマップに登録できるURLは最大50,000件で、非圧縮時のファイルサイズは50MBまでです。これを超える場合は複数のサイトマップへ分割し、サイトマップインデックスを利用します。

一般的なWordPressサイトでこの上限を超えることは多くありませんが、記事数や商品数が非常に多いサイトでは覚えておくとよいでしょう。

初心者が最初に確認するポイント

• サイトマップURLを直接開けるか
• Search Consoleへ正しいURLを送信しているか
• XMLとして正常に表示されるか
• robots.txtで妨げていないか
• サーバーエラーが発生していないか

原因が分からないまま何度も削除・再送信するより、まず**「Googleがサイトマップを取得できる状態か」**を確認することが大切です。

サイトマップに404ページが含まれている

XMLサイトマップには、基本的にGoogleにクロール・インデックスしてほしい正規URLを掲載するのが適切です。

そのため、すでに削除して404になっているURLがサイトマップに残っている場合は、サイトマップから除外することを検討します。

例えば、

サイトマップ

Example Domain

example.com

↓ Googleがアクセス

404 Not Found

となっている状態です。

重要なのは、

404そのものが必ずSEO上の問題なのではなく、「Googleへ送信しているサイトマップに不要な404 URLが残っている」ことを整理する

という考え方です。

確認すること

• そのページは本当に削除済みか
• 今後復活させる予定があるか
• 代替となる新しいページがあるか
• XMLサイトマップにURLが残っていないか
• 内部リンクが残っていないか

状況別の考え方

404になった理由	主な対応
不要記事を完全削除	サイトマップから除外
URLを変更した	新URLを掲載
記事を統合した	必要に応じて301を検討
誤って削除した	ページを復旧
存在したことのないURL	基本的にサイトマップへ載せない

なお、削除したページに代替ページがないのであれば、404を返すこと自体は正常です。

すべての404を無理にトップページなどへ301リダイレクトする必要はありません。

関連記事

404エラーについて詳しく確認したい場合は、こちらの記事で原因と正しい対処方法を解説しています。

送信したURLと実際のサイトマップを確認する

意外に多いのが、Search Consoleへ送信したサイトマップURLと、現在サイトで使用しているサイトマップが一致していないケースです。

例えば以前、

Example Domain

example.com

を使用していたものの、WordPressやプラグインの変更によって別のサイトマップURLになっている場合です。

そのため、Search Consoleで問題が出たら、まず現在のサイトマップURLを確認してください。

確認手順

① Search Consoleを開く
↓
②「サイトマップ」を開く
↓
③ 送信済みサイトマップを確認
↓
④ URLをブラウザで開く
↓
⑤ 現在のXMLサイトマップと一致するか確認

サイトマップインデックスを使用している場合は、その中に、

• 投稿
• 固定ページ
• カテゴリー
• その他の必要なコンテンツ

などのサイトマップが含まれていることがあります。

ここで確認したいのは、**ファイル名そのものより「現在Googleへ伝えたいURLが正しく掲載されているか」**です。

WordPressのXMLサイトマップを確認する

WordPressでは、XMLサイトマップを自動生成する仕組みがあります。

また、使用しているテーマやSEOプラグインによって、別のXMLサイトマップが生成される場合もあります。

そのため、

「WordPressなら必ずこのURL」

と決めつけず、実際に自分のサイトで生成されているサイトマップを確認することが大切です。

例えばWordPress標準では、一般的に

/wp-sitemap.xml

からサイトマップインデックスへアクセスできます。

ただし、SEOプラグインなどを使用している場合は、別のサイトマップが使われることがあります。

WordPressで確認したいこと

• XMLサイトマップをブラウザで開けるか
• 投稿ページが含まれているか
• 不要な404 URLが残っていないか
• 古いURLが残っていないか
• 正規URLが掲載されているか
• Search Consoleへ正しいサイトマップを送信しているか

サイトマップ確認イメージ

WordPress
↓
XMLサイトマップ生成
↓
公開した重要URLを掲載
↓
Search Consoleへ送信
↓
Googleが取得
↓
URLの発見・クロールに利用

ただし、サイトマップへURLを掲載したからといって、そのページが必ずクロール・インデックスされるわけではありません。

XMLサイトマップは、GoogleへURLを知らせるための重要な手段ですが、インデックス登録を保証するものではありません。

修正後にサイトマップを再確認する

サイトマップの問題を修正したら、それで終わりではありません。

Search ConsoleでGoogleが正常にサイトマップを取得・処理できるようになったか確認しましょう。

修正後の確認手順

① サイトマップURLをブラウザで確認
↓
② XMLが正常に表示されるか確認
↓
③ 不要な404 URLなどが消えているか確認
↓
④ Search Consoleの「サイトマップ」を開く
↓
⑤ 必要に応じてサイトマップを再送信
↓
⑥ ステータスを確認
↓
⑦「ページのインデックス登録」も確認

Search Consoleのサイトマップレポートで正常に処理されると、ステータスに「成功しました」など正常な状態が表示されます。

ただし、サイトマップが正常に読み込まれていても、そこに掲載されたURLがすべてインデックスされるわけではありません。

サイトマップとインデックス登録の違い

サイトマップ送信
↓
GoogleへURLを知らせる
↓
Googleがクロールを判断
↓
ページを評価
↓
インデックスするか判断

したがって、

「サイトマップ成功＝全記事インデックス済み」

ではありません。

サイトマップが正常になった後は、「ページのインデックス登録」レポートなども確認し、重要なページが適切にインデックスされているか見ていきましょう。

XMLサイトマップのエラー対処早見表

問題	最初に確認	主な対処
取得できない	サイトマップURL	URL・アクセス状態を確認
404になる	ファイルの存在	正しいURLへ修正
XMLエラー	XMLの記述	生成方法・構文を確認
5xxになる	サーバー	障害・設定を確認
404 URLを含む	削除ページ	サイトマップから除外
古いURLがある	URL変更履歴	新URLへ整理
成功している	インデックス状況	ページレポートも確認

XMLサイトマップ確認チェックリスト

• □ サイトマップURLをブラウザで開ける
• □ Search Consoleへ正しいURLを送信している
• □ Googlebotがアクセスできる
• □ XMLに重大な構文エラーがない
• □ 不要な404 URLが含まれていない
• □ 古いURLが残っていない
• □ 正規URLを中心に掲載している
• □ サイトマップのステータスを確認した
• □ 「検出されたページ数」だけでインデックス数を判断していない
• □ ページのインデックス登録レポートも確認している

特に初心者の方は、「サイトマップに載っている＝Google検索に登録されている」ではないことを覚えておきましょう。

XMLサイトマップはGoogleがURLを発見するための手助けであり、最終的にインデックスされるかどうかは別の判断になります。

Core Web Vitalsでよくある問題

Search Consoleの「ウェブに関する主な指標（Core Web Vitals）」では、実際のユーザーがページを利用したときのデータをもとに、サイトの表示速度や操作性、レイアウトの安定性を確認できます。

Core Web Vitalsで使われる主な指標は、次の3つです。

• LCP：主要なコンテンツが表示されるまでの速さ
• INP：クリックやタップなどに対する反応の速さ
• CLS：表示中にレイアウトがどれだけずれるか

Search Consoleでは、これらをもとにURLグループが「良好」「改善が必要」「低速」などに分類されます。

まず、現在の基準を確認しておきましょう。

指標	良好	改善が必要	低速
LCP	2.5秒以下	2.5秒超～4秒以下	4秒超
INP	200ms以下	200ms超～500ms以下	500ms超
CLS	0.1以下	0.1超～0.25以下	0.25超

これらは単なる機械的なテスト結果ではなく、Search ConsoleではChrome UX Report（CrUX）による**実際のユーザーの利用データ（フィールドデータ）**が使われています。

「不良URL」「改善が必要」と表示される

Search ConsoleのCore Web Vitalsレポートでは、モバイルとパソコンを分けてページの状態を確認できます。

現在のGoogle公式ヘルプでは、URLグループを主に、

• 良好
• 改善が必要
• 低速

という状態に分類しています。

画面や解説によって「不良URL」と表現されることもありますが、重要なのはLCP・INP・CLSのどの指標が基準を満たしていないのかを確認することです。

例えば、

LCP：良好
INP：良好
CLS：低速

なら、そのURLグループ全体の状態は「低速」になります。

つまり、3つのうち1つだけ問題があっても、全体の評価に影響します。

確認する順番

Core Web Vitalsを開く
↓
モバイル・パソコンを確認
↓
「低速」を優先して確認
↓
問題になっている指標を確認
↓
対象のURLグループを確認
↓
PageSpeed Insightsなどで詳しく調査

初心者の方は、まず**「低速」のURLから優先して改善する**とよいでしょう。

Core Web Vitalsの詳しい見方や、LCP・INP・CLSの確認方法、具体的な改善ポイントについては、こちらの記事で詳しく解説しています。

LCPが遅い原因と対処法

LCP（Largest Contentful Paint）は、ページを開いてから、画面内の主要な大きなコンテンツが表示されるまでの時間を表す指標です。

対象になるのは、大きな画像やテキストブロックなどです。

**2.5秒以下が「良好」**の目安です。

例えば、記事の最初に大きなアイキャッチ画像があり、その表示に時間がかかっていると、LCPが悪化する原因になることがあります。

Core Web Vitalsの詳しい見方や、LCP・INP・CLSの確認方法、具体的な改善ポイントについては、こちらの記事で詳しく解説しています。

LCPが遅くなる主な原因

• アイキャッチ画像などが重い
• 画像サイズが必要以上に大きい
• サーバーの応答が遅い
• CSS・JavaScriptの読み込みに時間がかかる
• Webフォントの読み込みが遅い
• ページ内のリソースが多い
• キャッシュが十分に活用されていない

初心者でも取り組みやすい対策

• 画像を適切な大きさにする
• WebPなど効率のよい画像形式を利用する
• 不要なプラグインを整理する
• キャッシュ機能を適切に利用する
• 不要なJavaScript・CSSを減らす
• サーバーの応答速度を確認する
• PageSpeed InsightsでLCP対象要素を確認する

例えば、横幅1200pxで十分な画像なのに、4000px以上ある写真をそのまま掲載していれば、必要以上にファイルサイズが大きくなることがあります。

画像を適切に圧縮・リサイズするだけでも、表示速度改善につながる可能性があります。

INPが悪い原因と対処法

INP（Interaction to Next Paint）は、ユーザーがページ上で行った操作に対して、ページがどれだけ素早く反応したかを見る指標です。

例えば、

メニューをクリックする
ボタンを押す
フォームを操作する
スマートフォンでタップする

といった操作が対象になります。

現在は、**200ms以下が「良好」**です。

INPが悪くなる主な原因

• JavaScriptの処理が重い
• メインスレッドが長時間占有されている
• 多数のスクリプトが動いている
• 広告や外部サービスの処理が多い
• 操作後に複雑な処理が実行される
• WordPressプラグインなどが大量のJavaScriptを読み込む

例えば、ユーザーがメニューボタンを押しても、別のJavaScript処理が続いていて反応が遅れれば、操作性が悪く感じられます。

INP改善の考え方

• 不要なJavaScriptを減らす
• 重い処理を分割する
• 不要なプラグインを整理する
• 外部スクリプトを見直す
• 広告・計測タグを必要以上に増やさない
• PageSpeed Insightsなどで問題を調査する

WordPressの場合、機能を追加するたびにプラグインを増やしていると、JavaScriptも増える場合があります。

ただし、プラグインが多い＝必ずINPが悪いという意味ではありません。

実際にどの処理が負荷になっているか確認してから改善することが大切です。

CLSが悪い原因と対処法

CLS（Cumulative Layout Shift）は、ページを見ている途中で、文字・画像・広告・ボタンなどが予期せず動いてしまう「レイアウトのずれ」を測る指標です。

**0.1以下が「良好」**です。

例えば、記事を読もうとした瞬間に上部へ広告が表示され、

本文が突然下へ移動する

といった現象がCLS悪化の代表例です。

さらに、押そうとしていたボタンが移動して、別の場所を誤ってクリックしてしまうと、ユーザーにとって大きなストレスになります。

CLSが悪くなる主な原因

• 画像にサイズが指定されていない
• 広告スペースが事前に確保されていない
• 後からコンテンツが挿入される
• Webフォントによって文字サイズが変化する
• 動的コンテンツが突然追加される
• 埋め込みコンテンツの表示領域が確保されていない

CLS改善ポイント

• 画像のwidth・heightを適切に指定する
• 広告表示領域をあらかじめ確保する
• 埋め込みコンテンツのスペースを確保する
• ページ上部へ後から要素を挿入しない
• Webフォントの読み込み方法を確認する

特に広告を設置しているサイトでは、広告が表示される前のスペース確保も確認しておきましょう。

モバイルだけ評価が悪くなる理由

Search Consoleでは、Core Web Vitalsがモバイルとパソコンで別々に評価されます。

そのため、

パソコン：良好
モバイル：改善が必要

ということも珍しくありません。

主な理由は、利用環境の違いです。

モバイルで悪化しやすい要因

• 通信速度がパソコンより遅い場合がある
• スマートフォンの処理能力が低い場合がある
• モバイル画面で広告や画像が大きな割合を占める
• JavaScript処理の負荷を受けやすい
• モバイル専用メニューなどがある
• レスポンシブ表示でレイアウトが変化する

例えば、高性能なパソコンと高速Wi-Fiでは快適に表示されても、古いスマートフォンとモバイル回線では表示や操作に時間がかかる場合があります。

そのため、サイト運営者自身のパソコンだけで、

「自分のサイトは速いから問題ない」

と判断しないことが大切です。

モバイルで確認するポイント

• スマートフォンで実際にページを開く
• ファーストビューの表示を確認する
• メニューをタップする
• スクロール時のずれを確認する
• 広告表示後に本文が動かないか確認する
• PageSpeed Insightsでモバイル結果を確認する

Core Web Vitalsは実際の利用環境を反映するため、モバイルユーザーの体験を意識した改善が重要です。

改善後に検証を開始する方法

LCP・INP・CLSの問題を修正したら、Search ConsoleのCore Web Vitalsレポートから改善状況を確認します。

基本的な流れは次のとおりです。

① Search Consoleを開く
↓
②「ウェブに関する主な指標」を開く
↓
③ モバイルまたはパソコンのレポートを開く
↓
④ 修正した問題を選択する
↓
⑤ PageSpeed Insightsなどで修正を確認する
↓
⑥ 問題詳細画面から検証・トラッキングを開始する
↓
⑦ Search Consoleで経過を確認する

ここで注意したいのは、改善直後にSearch Consoleの数値が変わるとは限らないことです。

Core Web Vitalsレポートは実際のユーザーデータを使用しており、過去28日間のデータをもとに評価されます。

そのため、修正後にPageSpeed Insightsのテスト結果が改善していても、Search Consoleのフィールドデータへ反映されるまで時間が必要な場合があります。

「PageSpeed Insightsでは改善したのにSearch Consoleが変わらない」理由

ページを改善
↓
PageSpeed Insightsなどで確認
↓
テスト結果は改善
↓
実ユーザーデータが蓄積
↓
Core Web Vitalsレポートへ反映

つまり、修正後すぐに何度も設定を変更するのではなく、一定期間データを確認しましょう。

Core Web Vitalsの問題と改善方法早見表

指標	何を見る？	良好の目安	主な改善
LCP	表示速度	2.5秒以下	画像・サーバー・CSSなど
INP	操作への応答性	200ms以下	JavaScriptなど
CLS	表示の安定性	0.1以下	画像・広告領域など

改善の優先順位

初心者の方は、次の順番で進めると分かりやすいでしょう。

①「低速」のURLを確認
↓
② LCP・INP・CLSのどれが問題か確認
↓
③ 影響するURLグループを確認
↓
④ PageSpeed Insightsで詳しく調べる
↓
⑤ 原因に合わせて改善
↓
⑥ 改善結果をテスト
↓
⑦ Search Consoleで検証・経過確認

一度にすべて直そうとするより、重要なページや多くのURLに影響している問題から優先するのがおすすめです。

エラーを見つけたときの基本的な対処手順

Search Consoleでエラーや「インデックス未登録」などを見つけても、慌てて設定を変更する必要はありません。

大切なのは、エラーの種類を確認し、そのURLが本当に修正すべきページなのかを判断してから対処することです。

例えば、404が表示されていても、意図的に削除した不要ページなら正常な場合があります。一方、公開中の重要記事が404になっていれば、URL変更や内部リンクなどを確認する必要があります。

基本的には、次の順番で進めると分かりやすいでしょう。

エラーを確認
↓
対象URLを確認
↓
URL検査ツールで調査
↓
実際のページを確認
↓
原因に合わせて修正
↓
公開URLをテスト
↓
必要に応じて検証・インデックス登録をリクエスト
↓
一定期間後に再確認

エラー対処の基本手順早見表

手順	確認すること	目的
① エラー確認	種類・対象URL	何が起きているか把握
② URL検査	クロール・インデックス状況	Google側の状態を確認
③ ページ確認	表示・リンク・設定	実際の状態を確認
④ 原因を修正	404・noindexなど	問題を解消
⑤ 公開URLをテスト	修正が反映されたか	現在の状態を確認
⑥ 検証・登録リクエスト	必要に応じて実行	Googleへ再確認を促す
⑦ 再確認	Search Console	改善状況を確認

エラーの種類と対象URLを確認する

最初に確認するのは、**「どのような問題が、どのURLで発生しているのか」**です。

Search Consoleにはさまざまな状態が表示されます。

例えば、

• 見つかりませんでした（404）
• ソフト404
• サーバーエラー（5xx）
• robots.txtによるブロック
• noindexによる除外
• リダイレクトエラー
• クロール済み – インデックス未登録
• 検出 – インデックス未登録
• canonical関連の状態

などです。

ここで重要なのは、表示されたものをすべて「直すべきエラー」と考えないことです。

例えば、不要になった記事を削除して404になっているのであれば、意図した状態かもしれません。

また、検索結果に表示する必要のないページへ意図的にnoindexを設定しているのであれば、修正する必要はありません。

最初に確認する3点

• どの種類の問題か
• 何件のURLが対象か
• そのURLは検索結果に表示させたいページか

特に重要なのが3つ目です。

検索結果に表示させたい重要ページなのか？

これを基準にすると、修正の優先順位を決めやすくなります。

URL検査ツールでページの状態を調べる

対象URLが分かったら、Search ConsoleのURL検査ツールを使います。

URL検査ツールでは、GoogleがそのURLについて把握している情報を確認できます。

主に確認したいのは、

• Googleにインデックスされているか
• Googleがクロールできたか
• 最終クロール日時
• インデックス登録が許可されているか
• ユーザーが指定した正規URL
• Googleが選択した正規URL
• サイトマップとの関係

などです。

URL検査の基本手順

① Search Console上部の検索欄を使用
↓
② 調べたい完全なURLを入力
↓
③ インデックス登録状況を確認
↓
④「ページのインデックス登録」の詳細を確認
↓
⑤ 必要なら「公開URLをテスト」を実行

ここで覚えておきたいのが、通常のURL検査結果と「公開URLをテスト」の違いです。

確認方法	主に分かること
通常のURL検査	Googleが現在持っているインデックス情報
公開URLをテスト	現在公開されているページをGoogleが取得できるか

例えば、昨日noindexを解除したばかりの場合、通常のURL検査では古いnoindexの情報が残っていることがあります。

そこで「公開URLをテスト」を実行すると、現在のページでnoindexが解除されているかを確認できます。

ただし、公開URLのテストで問題がなくても、必ずインデックスされるわけではありません。

「URL検査ツールの詳しい使い方や、インデックス登録状況の確認方法については、こちらの記事で詳しく解説しています。」

実際のページを開いて確認する

Search Consoleのデータだけではなく、対象URLを自分のブラウザでも開いて確認しましょう。

これは意外に重要です。

例えばSearch Consoleに404が表示されている場合でも、

• 現在は正常に表示される
• 別ページへ転送される
• 本当に404になる
• レイアウトが崩れている

など、実際の状態はさまざまです。

実際のページで確認すること

• 正常にページが表示されるか
• 404になっていないか
• 別URLへ意図せず転送されないか
• 本文が正常に表示されるか
• 画像が表示されるか
• 内部リンクが正常に動くか
• スマートフォンでも表示できるか

例えば、

Example Domain

example.com

を開いたら、

Example Domain

example.com

へ転送されたとします。

この場合は、「転送されているから問題なし」とすぐ判断するのではなく、その転送先が本当に正しいページなのかまで確認します。

ユーザーが実際に見るページと、Googleが認識しているページの両方を確認することが大切です。

原因に合わせて修正する

問題の原因が分かったら、それぞれの状態に合わせて修正します。

すべてのエラーに同じ対処をするわけではありません。

原因別の対処方法

問題	主な確認・対処
404	削除が意図的か確認、必要なら復旧・転送
ソフト404	内容・HTTPステータスを確認
5xx	サーバー・WordPressを確認
robots.txt	クロール制限を確認
noindex	意図した設定か確認
リダイレクト	転送先・ループなどを確認
canonical	正規URLの指定を確認
クロール済み未登録	内容・重複・内部リンク等を確認
検出済み未登録	サイト構造・内部リンク等を確認
サイトマップ	URL・取得状況・掲載URLを確認

例えば、公開したい記事に誤ってnoindexが設定されていた場合は、noindexを解除します。

一方、削除した古い記事が404になっていて、代替ページもないのであれば、無理に301リダイレクトする必要はありません。

つまり、

「エラー表示を消す」ことが目的ではなく、「Googleとユーザーがページを正しく利用できる状態にする」ことが目的

と考えると分かりやすいでしょう。

修正後に検証・インデックス状況を確認する

修正が終わったら、実際に問題が解決しているか確認します。

まず、URL検査ツールの**「公開URLをテスト」**を使うと、現在公開されているページをGoogleが取得できる状態か確認できます。

例えば、

noindexを解除
↓
公開URLをテスト
↓
インデックス登録可能か確認

という使い方です。

問題が解消していれば、必要に応じて「インデックス登録をリクエスト」を利用できます。

ただし、

インデックス登録をリクエスト＝必ずインデックスされる

という意味ではありません。

Googleはリクエストを受けても、最終的にそのページをインデックスするかどうかを別途判断します。

また、Search Consoleの問題詳細画面に「修正を検証」などの機能が用意されている場合は、問題を修正したあとに検証を開始できます。

修正後の流れ

問題を修正
↓
実際のページを確認
↓
公開URLをテスト
↓
修正内容が反映されているか確認
↓
必要ならインデックス登録をリクエスト
↓
利用できる場合は修正の検証を開始

なお、すべての問題で「修正を検証」が必要なわけではありません。Googleはページを再クロールした際にも状態を更新します。

一定期間後にSearch Consoleを再確認する

修正した直後にSearch Consoleの表示が変わらなくても、慌てて再修正する必要はありません。

Search Consoleのデータはリアルタイムですべて更新されるわけではなく、Googleがページを再クロール・再処理してから状態が変わる場合があります。

再確認する項目

• エラー件数が減っているか
• 対象URLの状態が変わったか
• インデックス登録されたか
• 新しい問題が発生していないか
• 検証のステータスが進んでいるか
• サイトマップが正常に処理されているか

特に、修正翌日に表示が変わらないからといって、

修正 → 再修正 → 設定変更 → 再修正

と短期間に何度も変更すると、どの修正が有効だったのか分かりにくくなります。

Googleのクロール頻度や問題の種類によって反映までの時間は異なるため、一定期間様子を見ながら確認しましょう。

エラー対処の基本チェックリスト

• □ エラーの種類を確認した
• □ 対象URLを確認した
• □ 検索結果に表示したいページか判断した
• □ URL検査ツールで確認した
• □ 実際のページをブラウザで開いた
• □ 原因に合わせて修正した
• □ 公開URLをテストした
• □ 必要ならインデックス登録をリクエストした
• □ 利用できる場合は修正の検証を開始した
• □ 一定期間後にSearch Consoleを再確認した

初心者が覚えておきたいポイント

Search Consoleで問題を見つけたときは、

「表示されたエラーをとにかく消す」

のではなく、

「このURLは本来どういう状態であるべきなのか」

を最初に考えることが重要です。

例えば、削除済みページなら404で正常な場合がありますし、検索結果へ出したくないページならnoindexで正常な場合があります。

一方、公開中の重要記事が404、5xx、誤ったnoindexなどになっていれば、優先して修正する必要があります。

この判断ができるようになると、Search Consoleに多数のURLが表示されても、「修正するURL」と「そのままでよいURL」を切り分けやすくなります。

Search Consoleのエラーでやってはいけないこと

Search Consoleに「未登録」「404」「リダイレクト」などが多数表示されると、「全部直さなければSEO評価が下がるのでは？」と不安になるかもしれません。

しかし、Search Consoleに表示される項目の中には、サイト運営者が意図した正常な状態も含まれています。

そのため、表示をゼロにすることを目標にするのではなく、そのURLが本来どういう状態であるべきなのかを確認してから対応することが重要です。

特に、次のような対応は避けましょう。

やってはいけないこと	なぜ問題？	正しい考え方
未登録をすべてエラー扱い	正常な除外もある	理由を確認する
404を全部修正	正常な404もある	必要なURLだけ対応
何でもリダイレクト	無関係な転送になる	代替ページを確認
登録リクエストを連打	登録を保証しない	原因を先に確認
記事をすぐ削除	改善可能な場合がある	内容・設定を調査
短期間に何度も変更	効果を判断しにくい	再クロールを待つ

すべての「未登録」をエラーだと考える

Search Consoleの「ページのインデックス登録」で「インデックス未登録」のURLが増えていると、すべて問題があるように見えるかもしれません。

しかし、インデックス未登録＝すべてエラーではありません。

例えば、

• noindexを意図的に設定したページ
• 適切なcanonicalが設定された代替ページ
• リダイレクトされたURL
• 削除済みの404ページ
• 重複URL

などは、検索結果に掲載する必要がなければ正常な状態の場合があります。

例えば、100件の未登録URLがあったとしても、

100件未登録 → 100件修正

と考えるのではなく、

100件未登録
↓
理由ごとに分類
↓
意図した未登録／意図しない未登録を判断
↓
重要なURLだけ優先して確認

という考え方が適切です。

特に優先したいのは、本来検索結果に表示させたい記事なのにインデックスされていないケースです。

「未登録件数をゼロにする」ことをSEOの目標にする必要はありません。

404をすべて修正しようとする

404（Not Found）は、指定されたURLにページが存在しないことを示すHTTPステータスコードです。

404がSearch Consoleに表示されても、必ず修正しなければならないわけではありません。

例えば、

古いキャンペーンページを削除した

不要な記事を完全に削除した

代替となるページも存在しない

という場合、404を返すことは正常です。

一方で、

• 公開中の記事が404になった
• URL変更後に古い内部リンクが残っている
• 本来存在するページのURLを間違えている
• 重要ページへのリンクが404になっている

場合は確認が必要です。

判断方法

404を発見
↓
そのページは必要？

不要・代替ページなし
→ 404のままで問題ない場合がある

必要なページ
→ 復旧・URL修正などを検討

新しい代替ページがある
→ 必要に応じて301リダイレクトを検討

404の件数そのものを減らすことより、ユーザーが必要な情報へたどり着ける状態になっているかを確認しましょう。

404について詳しくは、こちらの記事で原因と正しい対処方法を解説しています。

原因を確認せずリダイレクトする

404や削除済みURLを見つけると、すべてトップページへ301リダイレクトすればよいと思うかもしれません。

しかし、関連性のないページへのリダイレクトはおすすめできません。

例えば、

削除した「トマトの育て方」

から、

パソコンの使い方

の記事へ転送しても、ユーザーが期待している情報とは一致しません。

また、削除した大量のURLをすべてトップページへ転送するのも適切とは限りません。

Googleは、内容が大きく異なるページへリダイレクトすると、ソフト404として扱う場合があると説明しています。

リダイレクトの基本的な考え方

状況	主な対応
URLだけ変更した	新URLへ301
記事を別記事へ統合した	統合先へ301
同等の代替ページがある	関連ページへの301を検討
代替ページがない	404・410を検討
全く関係ないページしかない	無理に転送しない

大切なのは、

「404をなくすために転送する」のではなく、「移転先として適切なページがある場合に転送する」

という考え方です。

インデックス登録を何度もリクエストする

記事がインデックスされていないと、URL検査ツールから何度も「インデックス登録をリクエスト」したくなるかもしれません。

しかし、同じURLについて短期間に何度もリクエストしても、インデックス登録が保証されたり、クロールが早くなったりするわけではありません。

まず確認したいのは、

• noindexになっていないか
• Googleがクロールできるか
• canonicalは適切か
• ページが正常に表示されるか
• 内容が検索意図に合っているか
• 類似・重複ページがないか
• 内部リンクがあるか

などです。

避けたい流れ

未登録を発見
↓
すぐ登録リクエスト
↓
翌日も未登録
↓
またリクエスト
↓
さらにリクエスト

ではなく、

未登録を発見
↓
原因を確認
↓
必要なら修正
↓
公開URLをテスト
↓
必要に応じて登録リクエスト
↓
再クロール・処理を待つ

という順番で進めましょう。

XMLサイトマップも、Googleへ多数の重要URLを知らせるための手段として活用できます。

エラー表示だけを見て記事を削除する

「クロール済み – インデックス未登録」などが表示されたからといって、すぐ記事を削除するのは避けましょう。

Search Consoleの表示だけでは、

「この記事には価値がないから削除すべき」

とは判断できません。

まず、

• 検索意図に合っているか
• 情報が古くないか
• 他の記事と重複していないか
• 内容を改善できないか
• 内部リンクが不足していないか
• canonicalやnoindexに問題がないか
• 検索パフォーマンスに実績がないか

などを確認します。

例えば、インデックス未登録の記事でも、内容を整理し、具体例や不足情報を追加して、類似記事との差別化を行うことで改善できる場合があります。

一方、本当に重複していて独立した記事として残す意味がないのであれば、記事統合などを検討できます。

削除前の判断

未登録の記事を発見
↓
技術的な問題を確認
↓
記事内容を確認
↓
類似記事を確認
↓
改善できる？

できる → リライト

類似記事と一本化できる → 統合を検討

不要・価値を持たせにくい → 削除を検討

つまり、削除は最初の対処ではなく、確認したあとの選択肢の一つと考えましょう。

修正後すぐに何度も設定を変更する

Search Consoleのエラーを修正しても、表示がすぐ変わるとは限りません。

Googleがページを再クロールし、情報を再処理してからSearch Consoleへ反映されるためです。

そのため、

月曜日：noindexを解除
↓
火曜日：変化なし → canonicalを変更
↓
水曜日：変化なし → URLを変更
↓
木曜日：さらにリダイレクトを変更

のように、短期間で次々と設定を変えるのは避けましょう。

これでは、どの修正が有効だったのか分からなくなります。

修正後の基本的な考え方

• 修正内容を記録する
• 公開URLで修正を確認する
• 必要なら検証を開始する
• 必要に応じてインデックス登録をリクエストする
• Googleの再クロール・再処理を待つ
• 一定期間後にSearch Consoleを確認する

Googleがページを再クロールするタイミングは一定ではありません。

そのため、「○日待てば必ず反映される」と決めつけないことも大切です。

Search Consoleで避けたい対応早見表

やってはいけない対応	おすすめの対応
未登録を全部修正する	未登録理由を分類する
404を全部なくす	必要な404だけ確認
何でも301転送する	関連する代替ページがあるか確認
登録リクエストを繰り返す	原因を確認してから利用
未登録記事をすぐ削除	改善・統合・削除を比較
修正直後に再修正する	再クロール・処理を待つ

最も大切な判断基準

Search Consoleで問題を見つけたら、まず、

「この表示を消すにはどうするか？」

ではなく、

「このURLは検索結果に表示させたいページなのか？」

と考えてください。

検索結果に表示したい重要記事なら、クロール、インデックス、noindex、canonical、内部リンク、記事内容などを確認します。

一方、意図的に削除したURLや検索結果に載せる必要のないURLなら、未登録のままでも正常な場合があります。

Search Consoleは「エラーをゼロにするためのツール」ではなく、Googleがサイトをどのように認識しているかを確認し、必要な問題を見つけるためのツールとして活用するとよいでしょう。

Search Consoleのエラーでよくある質問

Search Consoleを使っていると、「エラーが残っているとSEOに悪影響がある？」「修正したのに表示が消えない」といった疑問が出てきます。

大切なのは、Search Consoleに表示された項目の名称だけで判断しないことです。

404やインデックス未登録の中には正常な状態もあります。一方で、重要なページがクロールできない、誤ってnoindexになっているなど、確認した方がよい問題もあります。

よくある疑問を順番に見ていきましょう。

よくある質問早見表

疑問	基本的な考え方
エラーがあると順位が下がる？	エラーの種類・対象URLによる
404は全部修正する？	不要ページならそのままでよい場合もある
未登録はエラー？	必ずしもエラーではない
修正しても表示が残る？	再クロール・データ更新に時間が必要な場合がある
反映まで何日？	一定の日数では決まっていない
「検証を開始」は必須？	すべての場合で必須ではない

エラーがあると検索順位は下がりますか？

Search Consoleにエラーや問題が表示されているだけで、検索順位が必ず下がるわけではありません。

重要なのは、問題の内容と対象になっているページです。

例えば、すでに削除した不要ページが404になっていても、それだけを理由にサイト全体の検索順位が下がると考える必要はありません。

一方で、検索流入を獲得したい重要記事に問題が発生して、

• Googlebotがクロールできない
• 誤ってnoindexになっている
• サーバーエラー（5xx）が長く続く
• 不適切なcanonicalによって別URLが正規URLになっている

といった状態なら、そのページが検索結果に表示されなかったり、適切に処理されなかったりする可能性があります。

例えば

重要記事A

正常にクロール
↓
インデックス登録
↓
検索結果に表示可能

重要記事B

誤ってnoindex
↓
インデックスされない
↓
検索結果に表示されない

この場合は、「エラーがあるから順位が下がった」というより、そもそもページが検索結果へ掲載される条件を満たしていないと考えた方が分かりやすいでしょう。

したがって、エラー件数だけを見るのではなく、検索結果に表示したい重要URLに問題が発生していないかを優先して確認してください。

404エラーはすべて修正する必要がありますか？

いいえ。404をすべて修正する必要はありません。

ページを意図的に削除し、代わりになるページもないのであれば、404を返すのは正常な処理です。

例えば、

「2023年限定キャンペーン」

というページを終了後に完全削除し、現在提供している同等のページもなければ、404のままでも問題ありません。

一方、次のような404は確認した方がよいでしょう。

• 公開している記事が404になっている
• 内部リンクのURLを間違えている
• URL変更後に旧URLへのリンクが残っている
• 削除ページに適切な移転先がある
• XMLサイトマップに不要な404 URLが残っている

判断方法

404を発見
↓
必要なページ？

はい
→ 復旧・URL修正などを確認

不要だが代替ページがある
→ 関連性を確認して301リダイレクトを検討

不要で代替ページもない
→ 404または410で問題ない場合がある

つまり、404の件数をゼロにすることが目的ではありません。

404についてさらに詳しく確認したい場合は、既存記事の

「Search Consoleで404エラーが表示される原因と正しい対処方法を解説」

を参考にしてください。

※この記事内ですでに同じ記事をブログカードで紹介している場合、ここではテキストリンクだけで十分です。

インデックス未登録はエラーですか？

インデックス未登録＝すべてエラー、ではありません。

GoogleがURLをインデックスしていない理由には、さまざまなものがあります。

例えば、

• 意図的にnoindexを設定している
• 適切なcanonicalが設定された代替ページ
• リダイレクトされたページ
• 削除済みの404ページ
• 重複ページ

などは、検索結果へ表示する必要がなければ正常な場合があります。

一方、

公開した重要記事なのに「クロール済み – インデックス未登録」

となっている場合は、記事内容や重複、内部リンク、canonicalなどを確認する価値があります。

判断するときのポイント

URLの状態	確認の必要性
意図したnoindex	基本的に問題なし
適切な代替ページ	基本的に問題なし
削除済み404	意図どおりなら問題なし
重要記事が未登録	原因を確認
新規記事が一時的に未登録	しばらく様子を見る場合もある

Search Consoleでは、単純な「未登録件数」よりも、なぜ未登録なのかを理由別に確認することが大切です。

修正してもエラーが消えないのはなぜですか？

修正した直後にSearch Consoleを確認しても、以前のエラー表示が残っていることがあります。

これは珍しいことではありません。

Search Consoleの情報が更新されるには、Googleがページを再クロールしたり、取得した情報を再処理したりする必要があるためです。

例えば、

月曜日：誤ったnoindexを解除

しても、

火曜日：Search Consoleではまだnoindex表示

ということがあります。

この場合は、まずURL検査ツールの「公開URLをテスト」で現在のページを確認します。

確認の流れ

① 実際のページを確認
↓
② 修正内容が反映されているか確認
↓
③ 公開URLをテスト
↓
④ Googleが現在の状態を取得できるか確認
↓
⑤ 必要なら検証・登録リクエスト
↓
⑥ 再クロール・データ更新を待つ

「Search Consoleから表示が消えない＝修正失敗」とすぐ判断しないことがポイントです。

エラー修正後はどのくらいで反映されますか？

「修正から○日後に必ず反映される」という決まった期間はありません。

GoogleがURLを再クロールするタイミングはページによって異なるためです。

例えば、

• サイトのクロール状況
• ページの重要度
• 更新頻度
• サーバーの状態
• 問題の種類
• Google側の処理状況

などによって違いが出ます。

また、Search Consoleのレポートによっても更新方法が異なります。

特にCore Web Vitalsは、通常のインデックス関連レポートとは考え方が異なり、実際のユーザーデータをもとに評価されるため、修正直後に結果が変わるとは限りません。

修正後に大切なこと

• 修正した日を記録する
• 修正内容を記録する
• 公開URLで正常か確認する
• 必要に応じて検証を開始する
• 数日ごとに設定を変えない
• Search Consoleで経過を見る

「まだ変わらないから、さらに別の設定を変更しよう」と急ぐより、まず修正が正しく反映されていることを確認してGoogleの再処理を待つことが大切です。

「検証を開始」は必ず行う必要がありますか？

すべてのケースで「検証を開始」を行う必要があるわけではありません。

Search Consoleの一部のレポートでは、問題を修正したあとに検証を開始して、Googleに修正状況の確認を依頼できます。

ただし、「検証を開始」を押さなければGoogleが二度とページを確認しない、という意味ではありません。

Googleは通常のクロールでもページを再確認し、状態を更新することがあります。

「検証を開始」を利用するとよいケース

• 複数URLで同じ問題を修正した
• Search Consoleに検証機能が表示されている
• 修正が完了したことを確認できた
• 検証の進行状況をSearch Consoleで追いたい

一方、個別URLの内容を修正して再クロールしてほしい場合などは、URL検査ツールの「インデックス登録をリクエスト」を使うケースもあります。

この2つは目的が少し違います。

機能	主な目的
検証を開始	レポートで検出された問題の修正確認
インデックス登録をリクエスト	個別URLのクロールをリクエスト
公開URLをテスト	現在のページをGoogleが取得できるか確認

初心者の方は、

修正 → 公開URLを確認 → 必要に応じて検証・登録リクエスト → 経過確認

と覚えておけばよいでしょう。

Search ConsoleのエラーFAQまとめ

質問	結論
エラーがあると順位が下がる？	必ずではない。問題内容による
404は全部修正する？	不要ページなら修正不要の場合あり
未登録はエラー？	すべてがエラーではない
修正後も表示が残る？	再クロール・処理待ちの場合あり
反映まで何日？	一定ではない
検証は必須？	すべての場合で必須ではない

初心者が覚えておきたいポイント

Search Consoleでエラーや未登録URLを見つけたときに最も大切なのは、件数だけを見て判断しないことです。

まず、

• そのURLは検索結果に表示させたいか
• 現在の状態は意図したものか
• 実際のページは正常か
• Googleがクロール・インデックスできる状態か

を確認しましょう。

「エラーをゼロにする」のではなく、「重要なページがGoogleとユーザーから正しく利用できる状態にする」ことが本来の目的です。

Search Consoleのエラーは原因を確認して正しく対処しよう

Search Consoleには、404、インデックス未登録、noindex、リダイレクト、canonical、XMLサイトマップ、Core Web Vitalsなど、さまざまな問題や状態が表示されます。

しかし、表示された項目をすべて「SEOに悪影響を与えるエラー」と考える必要はありません。

例えば、不要なページを削除した結果として404になっている場合や、意図的にnoindexを設定しているページ、適切なcanonicalが設定された代替ページなどは、正常な状態の場合があります。

大切なのは、エラー件数をゼロにすることではなく、検索結果に表示させたい重要なページに問題がないかを優先して確認することです。

今日覚えておきたい重要ポイント3つ

この記事で特に覚えておきたいのは、次の3つです。

• ① Search Consoleの「未登録」や404は、すべて修正する必要があるわけではない
• ② 検索結果に表示したい重要ページに問題がある場合は優先して原因を確認する
• ③ 修正後はURL検査やSearch Consoleで再クロール・インデックス状況を確認する

特に重要なのは、

「エラー表示を消すこと」＝「SEO改善」ではない

という点です。

例えば、

不要な記事 → 削除 → 404

であれば正常な場合があります。

一方、

公開中の重要記事 → 誤ってnoindex → インデックスされない

のであれば、優先して修正した方がよいでしょう。

Search Consoleでは、そのURLを検索結果に表示したいのかどうかを基準に判断すると、対応の優先順位を決めやすくなります。

Search Consoleの主なエラーと対処法早見表

これまで紹介してきた代表的な問題をまとめると、次のようになります。

表示・問題	主な意味	基本的な対処
404	ページが存在しない	意図した削除か確認
ソフト404	実質的に内容がないと判断	内容・HTTP応答を確認
サーバーエラー（5xx）	サーバー側の問題	サーバー・WordPressを確認
robots.txtによるブロック	クロールが制限されている	意図した設定か確認
noindex	検索結果へ掲載しない指定	意図した設定か確認
リダイレクトエラー	転送処理に問題	転送先・ループなどを確認
クロール済み – インデックス未登録	クロール済みだが未登録	内容・重複・設定などを確認
検出 – インデックス未登録	URL認識済み・未クロール	内部リンク・サイト構造などを確認
canonical関連	正規URLに関する状態	Google選択URLと指定URLを確認
サイトマップエラー	XMLサイトマップに問題	URL・取得状況・内容を確認
Core Web Vitalsの問題	表示・操作・安定性に課題	LCP・INP・CLSを確認

この表を見ても分かるように、エラーごとに対処方法は異なります。

例えば404を見つけたからといって、すべて301リダイレクトするのは適切ではありません。

原因を確認 → 本来あるべき状態を判断 → 必要なものだけ修正

という順番を守ることが大切です。

エラー修正前チェックリスト

Search Consoleで問題を見つけたら、すぐにWordPressやサーバーの設定を変更するのではなく、次の項目を確認してください。

エラー修正前チェックリスト

• □ エラー・問題の種類を確認した
• □ 対象URLを確認した
• □ URLを実際にブラウザで開いた
• □ 検索結果に表示させたいページか確認した
• □ URL検査ツールで状態を確認した
• □ noindexの有無を確認した
• □ canonicalの状態を確認した
• □ リダイレクトの有無を確認した
• □ 内部リンクを確認した
• □ XMLサイトマップを確認した
• □ 類似・重複ページがないか確認した
• □ 記事内容に問題がないか確認した

特に、

「このページは検索結果に残したいのか？」

を最初に考えると判断しやすくなります。

例えば、古い記事を意図的に削除した結果の404なら、そのままで問題ない場合があります。

反対に、公開している重要記事が誤ってnoindexになっていれば修正が必要です。

エラー修正後の確認手順

エラーを修正したら、Search Consoleへ戻って改善状況を確認します。

基本的な流れは次のとおりです。

① 修正したページを実際に開く
↓
② URLや表示が正常か確認する
↓
③ URL検査ツールで確認する
↓
④ 必要に応じて「公開URLをテスト」する
↓
⑤ 必要ならインデックス登録をリクエストする
↓
⑥ 利用できる場合は「検証を開始」する
↓
⑦ Googleの再クロール・再処理を待つ
↓
⑧ 一定期間後にSearch Consoleを再確認する

ここで注意したいのが、修正直後にSearch Consoleの表示が変わらなくても、すぐ再修正しないことです。

Googleがページを再クロールし、取得した情報を処理してからSearch Consoleへ反映される場合があります。

修正前後を記録しておく

複数のエラーを修正するときは、簡単な表を作っておくと管理しやすくなります。

URL	問題	修正内容	修正日	再確認
記事A	404	内部リンク修正	○月○日	確認済み
記事B	noindex	設定解除	○月○日	確認待ち
記事C	リダイレクト	転送先修正	○月○日	確認済み

記事数が増えてくるほど、**「いつ・どのURLを・どう修正したか」**を記録しておくと、後からSearch Consoleの変化と比較しやすくなります。

最後に

Search Consoleでエラーや未登録URLが増えても、件数だけを見て慌てる必要はありません。

まずは**「そのURLは検索結果に表示させたいページなのか」「現在の状態は意図したものなのか」**を確認してください。

そして、404、noindex、canonical、リダイレクト、サイトマップなど、それぞれの原因に合わせて必要なものだけ修正しましょう。

Search Consoleを定期的に確認し、発見 → 原因確認 → 修正 → 検証 → 再確認の流れを身につけることが、SEOに強いサイトを育てる第一歩です。

参考元：

• Google Search Console ヘルプ「ページのインデックス登録レポート」
• Google Search Console ヘルプ「URL検査ツール」
• Google Search Console ヘルプ「サイトマップレポート」
• Google Search Central「404エラー」
• Google Search Central「正規URL・canonical」
• Google Search Central「リダイレクトとGoogle検索」
• Google Search Central「クロールとインデックス登録」
• Google Search Console ヘルプ「Core Web Vitalsレポート」

Googleのクロール時期やインデックス登録の判断、修正内容がSearch Consoleへ反映されるまでの期間は一定ではありません。また、Search Consoleの表示名称や画面構成は仕様変更される場合があるため、実際の管理画面とGoogle公式ヘルプもあわせて確認してください。

まとめ

Search Consoleでは、404やソフト404、サーバーエラー、robots.txtによるブロック、noindex、リダイレクトエラー、インデックス未登録など、さまざまな問題が表示されます。ただし、表示された項目すべてが修正必須とは限りません。まず原因と対象URLを確認し、URL検査ツールなどを使ってページの状態を調べることが大切です。エラーの種類に応じて適切に修正し、その後もインデックス状況や検索結果を確認しながら、SEOに強く利用しやすいサイトを目指しましょう。