テクニカルSEO監査:2026年版・優先順位つきチェックリスト

要点: テクニカルSEO監査では、次の4つの問いに順番に答えます。Googleはページに到達できるか。各ページの正しいバージョンをインデックスできるか。各ページの内容を理解できるか。そして、送客したユーザーにとってページは快適に動作するか。まずステータスコード、robots.txt、noindexルールを確認し、次にリダイレクト、canonical、サイトマップ、その後にタイトル、構造化データ、hreflang、最後にHTTPS、モバイルのパリティ、Core Web Vitalsを確認します。課題リストの長さではなく影響度で優先順位を付けて修正し、リリースのたびに再確認しましょう。

多くの監査は同じ形で失敗します。クローラーが「問題」214件を件数順に並べ、チームは装飾画像にalt属性を付ける作業に1週間を費やします。その間も、ステージング環境から残ったnoindexタグのせいで、料金ページはGoogleに表示されないままです。件数の多さは優先度ではありません。

このチェックリストは、ページがGoogleの中で辿る経路、つまりクロール、インデックス、理解、配信の順に沿っています。この連鎖の前半に問題があると、後半の対策はすべて意味を失います。だから、この順番で監査し、この順番で修正します。以下のルールはすべてGoogleの公式ドキュメントに基づいています。

テクニカルSEO監査の対象範囲

テクニカル監査が扱うのは、アクセスのしやすさと解釈のされ方であり、コンテンツが上位表示に値するかどうかではありません。Googleの技術要件は簡潔です。Googlebotがブロックされていないこと、ページがHTTP 200を返すこと、インデックス可能なコンテンツがあること。Googleは、これらを満たしても「ページがインデックスされるとは限らず、インデックスは保証されない」と補足しています。監査のそれ以外の項目は、Googleがページをスキップしたり、誤解したり、評価を下げたりする原因を取り除くためのものです。

始める前に:4つの情報源

1. Search Consoleの「ページのインデックス登録」レポート: Googleがインデックスした URL と、それ以外をスキップした理由がわかります。
2. URL検査ツール: 1つのURLについて、レンダリング済みHTMLやGoogleが選んだcanonicalなど、Googleから見た状態を確認できます。
3. サイトクローラー: 到達できるすべてのページについて、ステータスコード、リダイレクト、タイトル、canonicalを調べます。
4. ページ単位のチェッカー: 無料のウェブサイトSEOチェッカーは、入力したページ(デフォルトはトップページ)とその周辺のサイトファイルに対して、約20秒で38項目のチェックを実行します。

まずベースライン(インデックス済みページ数、理由別の未インデックスページ数、クローラーが見つけたURL数)を記録しておきましょう。そうしないと、修正の効果を判断できません。

ステップ1:Googleはページに到達できるか?

ステータスコード

検索に表示したいURLは、すべて200で応答する必要があります。Googleは各コードの扱いをHTTPステータスコードがGoogle検索に与える影響とリダイレクトとGoogle検索で説明しています。

実務で重要な点が2つあります。Googleは「429を除くすべての4xxエラーは同じ扱い」と述べているため、404と410は同じ結果になります。また、429はファイアウォールやボット対策が「クローラーの速度が速すぎる」と判断したときに返すコードです。そのため、セキュリティ製品が気づかないうちにインデックス登録を遅らせることがあります。

Googleは、即時のmeta refreshを恒久的、遅延のあるものを一時的と解釈します。JavaScriptによるリダイレクトはレンダリングが成功した場合にのみ機能するため、サーバーサイドやmeta refreshのリダイレクトが使えない場合に限って使うよう、Googleは推奨しています。

robots.txt

robots.txtはクローラーのトラフィックを管理するものです。Googleのrobots.txtの概要によれば、「ウェブページをGoogleに表示させない仕組みではありません」。disallowされたページでも、「他のサイトからリンクされていればインデックスされる可能性があり」、その場合は説明文なしで表示されます。

確認するのは次の3点です。

• ファイルがルートに存在し、HTMLページではなくプレーンテキストとして200を返すこと。ルールが不要なら、きちんとした404でも構いません。5xxは厳禁です。Googleがクロールを一時停止します。
• 検索に表示したいセクションをブロックするルールがないこと。ステージング環境からDisallow: /をそのままコピーしてしまうのが典型的な失敗です。
• ページのレンダリングに必要なCSSとJavaScriptがブロックされていないこと。

robots.txtチェッカーは、Googlebotと同じ方法でファイルを読み取ります。サイト全体や入力したページをブロックするルール、サーバーエラーを返すrobots.txtを検出します。

noindexとX-Robots-Tag

noindexメタタグまたはX-Robots-Tag: noindexHTTPヘッダーを使うと、ページを検索結果に表示させないようにできます。ヘッダー形式は、メタタグを持てないPDF、画像、動画にも使えます(noindexで検索インデックスをブロックする)。

落とし穴は、同じURLをrobots.txtでもブロックしている場合です。「クローラーはnoindexルールを認識できず、ページが検索結果に表示され続ける可能性があります」。ページを削除したいときは、クロールを許可したうえでnoindexを返してください。CDNやプラグインは、ページを編集しなくてもX-Robots-Tagを追加できるため、HTMLとレスポンスヘッダーの両方を監査しましょう。

ステップ2:Googleは正しいバージョンをインデックスできるか?

1サイト、1アドレス

http://example.com、http://www.example.com、https://example.com、https://www.example.comは、クローラーから見ると4つの異なるURLです。1つを選び、残り3つをそこへ1回のホップで恒久リダイレクトしてください。サーバーが両方の形で応答する場合は、末尾スラッシュや大文字のパスも同様に統一します。リダイレクトチェッカーは4つのホストバージョンをすべてテストし、各ホップのステータスコードを表示して、一時的リダイレクト、ループ、長いチェーンを検出します。

canonicalタグ

Googleのcanonical化ガイドは、シグナルの強さを整理しています。リダイレクトとrel="canonical"は強いシグナル、サイトマップへの記載は弱いシグナルです。いずれもシグナルであって命令ではなく、Googleは別のcanonicalを選ぶことがあります。ベストプラクティスは次のとおりです。

• canonicalタグには絶対URLを使う。
• canonicalページ自身に、自己参照のcanonicalを設定する。
• すべての方法(タグ、ヘッダー、サイトマップ)で同じcanonicalを指定する。
• 「canonical化の目的でrobots.txtファイルを使用しない」。

よくある指摘事項は、すべてのページがトップページをcanonicalにしているケースや、canonicalがリダイレクト先や404のURLを指しているケースです。

XMLサイトマップ

サイトマップの作成と送信より。

• 1つのサイトマップの上限は、50,000 URLまたは非圧縮で50 MBです。大規模サイトは複数ファイルに分割し、サイトマップインデックスに列挙します。
• Googleは<priority>と<changefreq>を無視します。
• Googleが<lastmod>を使うのは、「一貫して検証可能な形で正確である」場合に限られます。著作権表示の年が変わった程度ではなく、重要な変更を反映させてください。
• Search Consoleで送信し、robots.txtにSitemap: https://example.com/sitemap.xmlのような行で記載します。

サイトマップには、200を返すcanonicalかつインデックス可能なURLだけを載せましょう。リダイレクト、404、noindexのページが含まれていると、シグナルが矛盾します。これはクロールでもっともよく見つかる指摘事項の1つです。

soft 404

soft 404とは、200を返しながらエラーページのように見えるページです。空のカテゴリ、「商品が見つかりません」というメッセージ、結果が0件の検索ページなどが該当します。Search Consoleでは「ソフト404」として報告されます。存在しないコンテンツには本物の404か410を返すか、そのURLに有益なコンテンツを置いてください。

JavaScriptレンダリング

Googleはクロールし、ヘッドレスChromiumでレンダリングしてから、レンダリング後のHTMLをインデックスします(JavaScript SEOの基本)。レンダリングは「Googleのリソースに余裕ができたとき」に行われるため、スクリプト実行後にしか存在しないコンテンツは反映が遅れ、不安定になりがちです。次の点を確認してください。

• リンクはhrefを持つ<a>要素であること。Googleは、その形式でしか「リンクを検出できない」と述べており、<div>や<span>のクリックハンドラは認識されません。
• クライアントサイドのルーティングには、#フラグメントではなくHistory APIを使うこと。
• シングルページアプリでは、404を返すURLへリダイレクトするか、エラー画面にnoindexを追加して、soft 404を避けること。
• 重要なテキストがサーバーレスポンスに含まれていること。Googleは今もサーバーサイドレンダリングやプリレンダリングを推奨しており、「すべてのボットがJavaScriptを実行できるわけではない」と指摘しています。AIクローラーにとっては、これがさらに重要です(ステップ5参照)。

URL検査のライブテストで、タイプごとに1つのテンプレートについて、生のHTMLとレンダリング後のHTMLを比較しましょう。

ステップ3:Googleは各ページを理解できるか?

タイトル

Googleのタイトルリンクに関するドキュメントは、すべてのページに、固有で内容がわかる簡潔な<title>を設定するよう求めています。キーワードの詰め込みや定型文は避けます。文字数の上限はないものの、デバイスに合わせて切り詰められると明記されています。またGoogleは、<title>、メイン見出し、og:title、アンカーテキストなどを使ってタイトルリンクを自動的に書き換えます。特にタイトルがない、重複している、役に立たない場合に起こります。重要な語を見せるには、およそ30〜60文字が実用的な目安ですが、これは慣例であり、Googleのルールではありません。

メタディスクリプション

Googleは、スニペットは「主にページのコンテンツ自体から作成される」と述べており、メタディスクリプションのほうが正確な要約になる場合にそれを使うことがあるとしています(スニペットを管理する)。長さの上限はなく、スニペットは必要に応じて切り詰められます。Googleが警告しているのは、多数のページで同一のディスクリプションを使うことと、キーワードの羅列でできたディスクリプションです。重要なテンプレートでディスクリプションの欠落と重複を監査し、それぞれに読みやすい要約を書きましょう。メタタグチェッカーでは、検索結果での見え方をプレビューできます。

構造化データ

Googleは、「サイトの構成が許せば」JSON-LDを使うことを推奨し、検証にはリッチリザルトテストを使うよう案内しています(構造化データの概要)。監査では、各テンプレートに必要なマークアップがあること(トップページにはOrganization、商品ページにはProduct、記事にはArticle、パンくずがある箇所にはBreadcrumbList)、それが有効であること、ページ上の表示内容と一致していることを確認します。2026年にどのタイプがリッチリザルトの対象になるか、どう記述するかは、スキーママークアップガイドで解説しています。スキーママークアップチェッカーは、ページが現在宣言している内容を一覧にします。

hreflang

言語版や国別版があるサイトでは、Googleのローカライズ版ガイドがルールを定めています。

• HTMLのlinkタグ、HTTPヘッダー、サイトマップのいずれかを使う。Googleはこれらを同等に扱います。
• 各バージョンは、自分自身と他のすべてのバージョンを列挙する。相互に参照されていないアノテーションは無視されることがあります。
• ISO 639-1の言語コードを使い、必要に応じてISO 3166-1 alpha-2の地域コードを続ける(en、en-GB、pt-BR)。国コードだけでは無効です。
• 絶対URLを使い、どのバージョンにも当てはまらない訪問者向けにx-defaultを任意で指定する。

Googleはページの言語を、hreflangやlang属性ではなく、独自のアルゴリズムでコンテンツから判定します。そのため、本文が英語のドイツ語URLは、依然として英語のページです。hreflangチェッカーは、これらのルールに照らしてコードを検証し、自己参照を確認し、x-defaultが設定されているかを知らせます。ただし読み取るのは1ページのみなので、他の言語版の戻りリンクも確認してください。

ステップ4:ページは訪問者にとって快適に動作するか?

HTTPSとmixed content

すべてのURLを有効な証明書でHTTPS配信し、HTTPは恒久リダイレクトしてください。Googleのページエクスペリエンスのガイダンスは「ページはセキュアな方法で配信されていますか?」と問いかけています。http://で読み込まれるスクリプトや画像などのmixed contentも確認しましょう。ブラウザはこれを部分的にブロックします。セキュリティヘッダーチェッカーは、証明書、HTTPSリダイレクト、HSTS、mixed contentをカバーしています。

モバイルファーストインデックス

モバイルファーストインデックスのベストプラクティスによれば、「Googleは、スマートフォン用エージェントでクロールしたサイトのモバイル版コンテンツを、インデックスとランキングに使用します」。監査で問うべきはパリティです。モバイル版にも、同じメインコンテンツ、同じ構造化データ、同じrobotsメタタグ、同等のタイトルとディスクリプションが必要です。Googlebotはクリック、スワイプ、入力をしないため、ユーザー操作をきっかけにメインコンテンツを遅延読み込みすることにも、Googleは注意を促しています。

なお、Googleは2023年12月1日にモバイルフレンドリーテストとSearch Consoleのモバイルユーザビリティレポートを廃止し、サイト所有者にLighthouseを案内しています(Google検索セントラルブログ)。当社のモバイルフレンドリーテストでは、viewportタグ、レスポンシブ画像、ファビコン、ページの言語といった基本を確認できます。

Core Web Vitals

Googleは「Core Web Vitalsはランキングシステムで使用されている」と述べる一方、良好なスコアが上位表示を保証するわけではなく、関連性が最優先だとも説明しています。web.devの目標値は、実際の訪問の75パーセンタイルで測定します。

INPは2024年にFirst Input DelayからCore Web Vitalsの指標を引き継ぎました。テクニカル監査では、基準を満たしていないテンプレートを記録して先に進みましょう。各指標の診断と改善はそれだけで1つのプロジェクトになるため、Core Web Vitalsガイドで手順を詳しく解説しています。Core Web Vitalsチェッカーは、サイトの実際のChromeユーザーデータを読み取ります。

ステップ5:AI検索への対応

AI overviewsとAIモードについて、Googleは、ページがインデックスされ、スニペットの対象になっていれば追加の要件はないと説明しています。また、CDNやホスティング側でもクロールを許可する必要があるとしています。他のアシスタントは独自のクローラーを使います。OpenAIは、ChatGPT検索にOAI-SearchBot、学習にGPTBotを使用しており、OAI-SearchBotをブロックしているサイトは「ChatGPT検索の回答に表示されません」。監査するのは3点です。AI検索のクローラーがrobots.txtとファイアウォールで許可されていること、主要なコンテンツがHTMLレスポンスに含まれていること、トップページがOrganizationマークアップで運営者を明示していること。AI検索対応チェッカーでこの3点すべてをテストでき、残りは生成エンジン最適化(GEO)のガイドで取り上げています。

「ページのインデックス登録」レポートの読み方

ページのインデックス登録レポートは、監査が現実と向き合う場所です。Google自身の見方はこうです。「サイト上のすべてのURLがインデックスされることを期待すべきではなく、インデックスされるのはcanonicalページだけです」。つまり、目的は「インデックス未登録」のリストを空にすることではありません。重要なcanonicalページがすべてインデックスされていて、除外がそれぞれ意図したものであることを確認することです。

すべての箇所で問題を修正したら、修正を検証をクリックします。Googleによると、1件でも残っていると検証は中止され、検証には「通常、約2週間かかります」。

単一ページのためのURL検査

URL検査ツールでは、インデックスされているバージョン(ライブではない)を確認できます。公開URLをテストを使えば、Googlebotが取得する現在のページについて、利用可否、クロールとインデックス登録の許可、ユーザーが宣言したcanonicalとGoogleが選択したcanonical、レンダリングされたスクリーンショット、生のHTML、HTTPヘッダー、読み込まれたリソースがわかります。修正のたびに、テンプレートごとに1つのURLで使いましょう。インデックス登録をリクエストは少数の重要ページに有効です。多数のページには、正確なlastmod値を含むサイトマップをGoogleは推奨しています。検査とインデックス登録リクエストには、プロパティごとに1日あたりの上限があります。

クロールバジェット:ごく大規模なサイトだけの話

クロールバジェットは、SEOの中でもっとも過剰に診断される問題です。Googleのクロールバジェットのガイドが対象とするのは、週単位で更新されるユニークなページがおよそ100万以上あるサイト、毎日更新されるページが1万以上あるサイト、そして「検出 - インデックス未登録」のURLが大きな割合を占めるサイトです。Googleはこれらを厳密なしきい値ではなくおおまかな目安としており、ページが公開当日にクロールされているなら、このガイドは不要だとも述べています。多くのサイトでは、最新のサイトマップと、ページのインデックス登録の定期的な確認で十分です。

トリアージの方法:影響度×工数

各指摘事項を、影響度(重要なページのうち何ページにどれだけ深刻に影響するか)と工数(修正の難しさ)で採点し、上から順に対応します。

ページ単位ではなく、テンプレート単位で修正しましょう。商品テンプレートのタイトル欠落であれば、修正は1回で済みます。

具体例(仮想)

以下は仮想の例であり、実際のデータではありません。商品ページとカテゴリページが合計約1,200ページある架空のアウトドア用品店、Northwind Outfittersが、リニューアル後に監査を実施します。Search Consoleでは、インデックス済みページがリニューアル前の1,050ページから640ページに減っています。

クローラーの指摘は312件。件数順に並べると、上位3つはalt属性の欠落(148件)、長いタイトル(61件)、メタディスクリプションの欠落(40件)です。このチェックリストの順番で並べ替えると、状況は変わります。

1. 到達: robots.txtは問題ありませんが、クロール中に38のURLが429を返しています。新しく導入したボット対策が、人間より速いアクセスをすべてレート制限しているためです。
2. インデックス: 絞り込み済みのカテゴリURL(?color=、?size=)がすべて自分自身をcanonicalにしており、400件のほぼ重複ページが生まれています。サイトマップには、現在はリダイレクトされる古いURLが90件残っています。http://www.の商品ページはすべて、https://www.、続いてhttps://へと2回リダイレクトされます。
3. 理解: 「長い」とされた61件のタイトルは、数文字超過している程度です。
4. 体験: ヒーロー画像が遅延読み込みされているため、カテゴリテンプレートでLCPが基準を満たしていません。

修正の順序は次のとおりです。ボット対策で検証済みクローラーを通す。絞り込み済みURLのcanonicalを絞り込みなしのカテゴリに向ける。canonical URLだけでサイトマップを再生成する。リダイレクトチェーンを1ホップにまとめる。カテゴリのヒーロー画像を即時読み込みにする。alt属性とタイトルの長さは、次のコンテンツスプリントに回します。6週間後にはインデックスの減少は回復し、残る「インデックス未登録」のURLは、意図どおり絞り込みページだけになりました。

監査の頻度

フル監査は四半期ごとに実施し、移行、リニューアル、URL変更の前後にも行います(ステージングは公開前に、本番は翌日にクロール)。さらに、ステータスコード、noindexやrobots.txtの変更、サイトマップのエラー、ページのインデックス登録の推移といった要点は、毎週自動でチェックしましょう。テクニカルSEOが徐々に劣化することはまれで、たいていはデプロイの日に壊れます。

1時間で始めるチェックリスト

1. 無料のウェブサイトSEOチェッカーを実行し、優先度の高い不合格項目を書き留める。
2. Search Consoleで、理由別のページのインデックス登録数を記録する。
3. URL検査で、テンプレートごとに1つのURLをライブテストし、生のHTMLとレンダリング後のHTMLを比較する。
4. robots.txt、4つのホストバージョン、リダイレクトチェーン1件を確認する。
5. サイトマップのURLを10件抜き取り確認する。いずれも200を返し、インデックス可能で、canonicalであること。
6. 指摘事項を影響度×工数の表にまとめ、上位3件を今週中に修正する。

SearviaでテクニカルSEO監査を行う方法

Searviaの無料ウェブサイトSEOチェッカーは、入力したページ(ドメインだけを入力した場合はトップページ)と、その周辺のサイトファイル(robots.txt、サイトマップ、llms.txt)、証明書、メールのDNSレコード、Chromeの実ユーザーの速度データを読み取ります。検索での見え方(9)、クロールとインデックス(6)、AI検索への対応(7)、速度(6)、モバイル(4)、セキュリティ(6)の6セクションで38項目のチェックを行い、A+からFまでの評価、優先順位つきの修正リスト、共有可能なレポートを提供します。同じエンジンを用途別に絞ったツールは、無料ツールのページで紹介しています。

サイト全体については、Searviaアカウントのサイト監査が、検索エンジンと同じようにページをクロールし、問題をエラー、警告、お知らせに分類します(壊れたページやリンク、サイトマップ内のリダイレクト、サイトマップ内のnoindexページ、別のページを指すcanonical、重複タイトル、孤立ページなど)。さらに毎週再実行されるため、修正できた点と新たに壊れた点がわかります。1回の監査で対象になるページ数はプランによって異なり、無料プランでは100ページです。Search Consoleを連携すれば、Googleの実際のインデックス登録とクリックを監査結果と並べて確認できます。またサイトの所有権を確認すると、監査のたびに新規ページや更新ページを、BingやYandexなどIndexNowに対応する検索エンジンへ送信できます。