技術SEOは何から確認する？点検の順番と担当者への伝え方

技術SEOは、検索対象にしたいURLを決め、取得・登録の妨げ、正規URLと発見経路、表示・操作の順に点検し、URLごとの観測事実と未確認事項を分けて担当者へ伝えます。

技術SEOとは、検索エンジンがページを取得・登録し、内容を把握できるように技術面を整える取り組みです。点検では、意図した非公開設定と修正が必要な制限を区別することから始めましょう。

ここで紹介する点検順と引継ぎ方法は、Googleの公式資料を基にした編集部の提案です。全項目への対応やツールの満点を目指すのではなく、自社サイトで何が妨げられているかを調べ、必要な調査・修正へつなげます。なお、最低限の技術要件を満たしても、Googleへのインデックス登録は保証されません。

出典：Google検索の技術要件

まず、検索対象にしたいURLと現在の登録状態を整理する

最初に、対象ページを一般公開するのか、検索対象にするのか、同じ内容の別URLがあるならどれを代表にしたいのかを整理します。未登録のURLをすべて修正対象にする必要はありません。

架空の例として、検索から読んでもらいたい解説記事、ログインが必要な会員向けページ、同じ記事を表示する別URLを考えてみます。いずれも未登録だったとしても、解説記事は調査対象、会員向けページは意図した制限、別URLは代表URLの確認対象というように、進める作業が変わります。

運営側の意図を整理したら、Search ConsoleでGoogle側の情報と照合します。Search Consoleは、自社サイトのGoogle検索での状態を確認するツールです。クロールはGoogleがページを取得すること、インデックス登録は検索に使う情報へページを登録することを指します。

サイト全体のインデックス登録レポートで対象を絞り、個別のURL検査では、次の情報を控えましょう。

• 登録状態と、未登録の場合はその理由
• 前回クロール日時、または日時が表示されていないこと
• ページの取得結果、クロールや登録の許可状態

URL検査の「Googleインデックス」側には、Googleが保持する情報が表示されます。現在の公開ページと一致するとは限りません。一方、「公開URLをテスト」は、その時点のページを調べる機能です。ライブテストで登録可能と判定されても、実際に登録されたことにはなりません。

登録済みなのに検索で見つからない場合も、未登録を前提に設定を変更せず、検索表示の問題として切り分けます。登録済みという判定も、実際の検索結果への表示を保証するものではありません。

権限がなく検査できない項目は未確認として残し、Search Consoleの管理者へ確認を依頼してください。

出典：Google「Search Consoleを使ってみる」、Google「URL検査ツール」

取得・登録を妨げる応答や設定を確認する

検索対象にしたいURLが決まったら、現在のページにアクセスできるか、意図しない登録除外の指定がないかを調べます。

HTTP応答と、実際に返るページを照合する

HTTP応答は、ページへのアクセスに対してサーバーが返す情報です。応答コードだけでなく、返された本文と転送先も一緒に確認しましょう。

自分で調べる場合は、次の流れで確認できます。

1. サイトにログインしていないブラウザで対象URLを開き、本文を読めるか、認証を求められないかを確かめます。
2. ブラウザの開発者ツールで「Network」などの通信一覧を開き、ページを再読み込みして、ページ本体の応答コードと応答ヘッダーを調べます。
3. 別のURLへ転送される場合は、入力したURLの応答と転送先を分けて記録します。

成功を示すHTTP 200でも、本文が空白だったり、エラーメッセージを表示していたりする場合があります。Googleが内容をエラーページに相当すると判断すると、Search Consoleでsoft 404が報告されることがあります。200というコードだけで、登録や内容に問題がないとは判断できません。

また、公開したい記事の取得失敗と、意図して削除したページの404は分けて扱います。応答の確認が難しければ、対象URLと取得失敗の表示をサイト管理者へ渡し、現在の応答と認証・転送設定の調査を依頼しましょう。

出典：Google「HTTPステータスコードがGoogleのクローラーに及ぼす影響」

robots.txtとnoindexを別々に確認する

robots.txtはクローラのアクセスを制御するファイルです。noindexは、ページをインデックス登録から除外する指定です。役割が異なるため、次の場所を分けて確認します。

• robots.txt：対象URLとGoogleのクローラに適用されるアクセス制限
• HTML：robotsまたはgooglebotのmetaタグにあるnoindex指定
• HTTP応答ヘッダー：X-Robots-Tagにあるnoindex指定

ブラウザで本文を読めても、応答ヘッダーで登録を除外している場合があります。見た目の確認だけで終えず、HTMLとヘッダーの両方を調べることが大切です。

Googleがnoindexを認識するには、そのページをクロールできる必要があります。robots.txtでアクセスを遮断すると、noindexを読み取れません。また、robots.txtによる遮断だけでは、ウェブページのURLが検索結果から除外されることを保証できません。Googleは、robots.txt内のnoindex指定をサポートしていません。

意図に反する指定が見つかったら、一律に解除するのではなく、CMSやサーバーのどの設定が出力しているか、どのURLに適用されるかを担当者へ調査してもらいましょう。

出典：Google「robots.txtの概要」、Google「noindexを使用してコンテンツをインデックスから除外する」

代表にしたいURLと、ページを発見する経路を照合する

取得・登録の制限を確認したら、どのURLを代表として扱うかを調べます。URL検査ですでに重複・代替ページと分かっている場合も、この確認へ進みます。

正規URLとは、重複または非常に似たページの代表となるURLです。canonicalは、希望する正規URLをGoogleへ強く示すシグナルですが、指定先の選択を強制するものではありません。指定がないことだけで不備とは判断しません。

次のURLを並べると、指定や選択の食い違いを調べやすくなります。

• 運営側が代表にしたいURL
• HTMLやHTTP応答ヘッダーのcanonical指定先
• Googleが選択した正規URL
• リダイレクトがある場合の転送先
• サイトマップに記載したURLと、サイト内リンクのリンク先

Googleが選んだ正規URLは、情報が表示される場合に、URL検査の「Googleインデックス」側で確認します。ライブテストでは、どのURLが正規として選ばれるかを予測できません。

架空の例として、https://example.com/guide/?ref=mailとhttps://example.com/guide/で同じ記事を表示している場合を考えます。後者を代表にしたいなら、canonical、転送先、サイトマップ、内部リンクがその意図とそろっているかを比べます。パラメータが付いていることだけで、前者が代替ページになるとは決まりません。

Googleの選択先が意図と異なる場合も、canonicalだけが原因とは断定せず、ほかの指定との食い違いを調べます。正規URLを選ばせる目的でrobots.txtやnoindexを使う方法は、Googleから推奨されていません。

発見経路については、サイト内の一覧や関連ページからリンクをたどって到達できるかを確認します。サイトマップを利用している場合は、対象URLの収録とSearch Consoleでの送信・読み取り状況も調べましょう。Googleはリンクからページを発見し、サイトマップも発見を助けます。ただし、サイトマップ送信は必須ではなく、未送信や収録漏れだけで未登録の原因は確定できません。

代替ページとして扱われているURLの判断は、「代替ページ（適切なcanonicalタグあり）」の確認方法で詳しく説明しています。

出典：Google「正規URLを指定する方法」、Google「URL検査ツール」、Google「SEOスターターガイド」、Google「Search Consoleを使ってみる」

表示・操作の支障と、速度の測定条件を確認する

URLの扱いと到達経路を整理したら、ページを読んだり操作したりできるかを調べます。ここでは点検の順番を示していますが、フォームを操作できないなど大きな支障があれば、対応を先にする場合もあります。

モバイル表示とGoogleからの見え方を確かめる

自社サイトでは、次のような点を実機で確認する方法をおすすめします。

• スマートフォンで本文を無理なく読めるか
• 表や画像がはみ出し、必要な情報が見えなくなっていないか
• メニューやフォームを操作できるか
• HTTPSで安全に接続できるか
• 広告や画面を覆う表示が本文の閲覧を妨げていないか

必要に応じて、URL検査のスクリーンショットや読み込まれたリソースも、通常のブラウザ表示と照合します。CSSは見た目、JavaScriptは動きや表示処理などを担うファイルです。Googleが重要なCSSやJavaScriptへアクセスできないと、ページ内容の把握に支障が出る場合があります。

表示が違う場合は、違った箇所と取得できなかったリソースを記録します。表示の違いだけで原因を決めず、開発担当に調査を依頼しましょう。

出典：Google「ページエクスペリエンスとGoogle検索結果への影響」、Google「SEOスターターガイド」

PSIは、ラボ診断と実ユーザーデータを分けて読む

PageSpeed Insights（PSI）は、ページの表示性能などを調べるツールです。Core Web Vitalsは、読み込み、表示の安定性、操作への応答に関する指標群です。

PSIでは、次のデータを区別して読みます。

• ラボデータ：指定URLを模擬環境で診断した結果です。問題の調査に使います。
• 実ユーザーデータ：過去28日間に収集された、実際の利用体験の集計です。

収集条件が異なるため、両者の結果が一致しない場合があります。点数だけを転記せず、対象URL、確認日時、モバイル・パソコンの区分、指標値と診断内容を残しましょう。

実ユーザーデータは、対象URL単位かオリジン単位かも確認します。オリジンは、通信方式・ホスト名・ポートの組み合わせで区切られる範囲です。URL単位のデータが不足するとオリジン単位に切り替わる場合があり、オリジンのデータも不足すると表示されません。

架空の記録例で、ラボ診断は記事URL、実ユーザーデータはオリジン単位だったなら、後者をその記事だけの利用体験として扱いません。データが表示されなければ、その項目は判断できないと残します。

Core Web Vitalsや外部ツールの結果が良好でも、検索上位表示は保証されません。測定結果は、どの表示や操作に支障があり、何を調べるべきかを担当者と共有するために使いましょう。

出典：Google「PageSpeed Insightsについて」、Google「ページエクスペリエンスとGoogle検索結果への影響」

構造化データは、検索結果の拡張表示に関わる項目として扱う

構造化データは、ページの情報を一定の形式で伝える記述です。点検では、ページそのものの取得・登録を妨げる問題と、検索結果の拡張表示に関わる問題を分けて記録しましょう。

対象の構造化データとSearch Consoleの該当レポートがある場合は、読み取り状況やエラー・警告を確認できます。対象URLと表示された詳細を保存し、実装担当へ、ページ内の記述と対象機能の現行要件を照合するよう依頼します。

未導入という理由だけで、全URLの必須修正にはしません。導入判断や修正内容は、対象機能の適用条件を確かめてから決めます。

出典：Google「Search Consoleを使ってみる：構造化データの実装に関する問題を確認する」

観測した事実を、優先度付きの調査依頼にまとめる

担当者へ渡すときは、確認した事実と原因の仮説を分けます。原因を特定できていなくても、再現するURL、期待する状態、調べてほしいことが分かれば、調査を依頼できます。

優先度は、項目名で固定せず、次の観点から理由を添える方法をおすすめします。

• 取得・登録・利用をどの程度妨げているか
• 影響を確認できた範囲はどこまでか
• 対象ページがどのような役割を持つか

たとえば、公開したいページを取得できない問題や、申し込みに必要なフォームを操作できない問題は、明確な支障がまだ確認されていない改善候補より先に調査する判断ができます。一方、意図した制限は変更対象から外し、状態が分からない項目は追加調査へ回します。

以下は、検索対象にしたい記事でnoindexが見つかった場合の架空の記入例です。実際の点検では、日時や環境を含め、自分が確認した内容に置き換えて使ってください。

この例で確認できたのは、対象URLにnoindexが出力されていることです。同じテンプレートのページや、サイト全体に適用されているとまでは判断できません。

担当者への依頼文にするなら、たとえば「このURLの応答ヘッダーにあるnoindexについて、出力元を調べてください。」「ほかのURLにも適用される設定か確認してください。」と、作業ごとに分けると伝えやすくなります。

この記録方法は、Google側の保存情報と現在のページ、測定条件の異なるデータを混同せずに引き継ぐための提案です。

参考：Google「URL検査ツール」、Google「PageSpeed Insightsについて」

修正後は、公開ページとGoogle側への反映を別々に確かめる

担当者の作業が終わったら、依頼時に決めた方法で、修正箇所を再確認します。その際、公開ページでの解消と、Google側への反映を別々に記録しましょう。

公開ページでは、同じURLの応答コード、ヘッダー、HTML、表示・操作など、修正対象を確かめます。Google側では、URL検査の登録状態、未登録理由、前回クロール日時、選択された正規URLを確認します。修正日時と再検査日時も対応させて残してください。

先ほどの架空の例で、公開ページからnoindexが解消しても、Googleインデックス側には修正前の情報が残っている場合があります。このときは「公開ページの指定は解消」「Google側への反映は未確認」と分けます。前回クロールが修正前なら、Googleが保持する情報に変更が反映されていない可能性があります。

必要に応じて、URL検査から再クロールを依頼する選択肢もあります。依頼には、対象サイトのSearch Consoleで所有者またはフルユーザーの権限が必要です。リクエストは検索表示を保証せず、同じURLへの依頼を繰り返してもクロールは早まりません。

表示性能を修正した場合も、修正直後のラボ診断と、過去28日間の実ユーザーデータを区別します。直後に表示された集計には、修正前の利用体験も含まれ得るためです。

出典：Google「URL検査ツール」、Google「URLの再クロールをリクエストする」、Google「PageSpeed Insightsについて」

個別URLの未登録理由をさらに調べる場合は、公開した記事がGoogleに登録されないときの確認方法へ進んでください。改善の優先度や、Search Consoleを見た改善ポイントの整理に迷う場合は、aimarkelaboの相談ページで相談できる範囲を確認できます。