technical-seo-audit

技術的な SEO 監査

確認済みの不具合、製品の確認事項、外部測定値、分析者の判断を切り分けて、モジュール式の技術的な SEO 監査を実施します。メタディスクリプションの欠落と、重要なページへの誤った noindex 設定は同等ではありません。

ルールの根拠

• Semrush が裏付けるガイダンス： クロール可能性、インデックス可能性、サイトアーキテクチャ、HTTPS、リダイレクト、モバイル版との同等性、パフォーマンス、正規化、メタデータ、構造化データ、レンダリングされたコンテンツは、技術的な SEO の主要な課題です。
• MCP の契約要件： プロジェクトに基づく調査結果は、公式 Semrush MCP が公開するレポートとフィールドに基づきます。テスト済みの契約は課題ベースであり、名前付きの製品 UI テーマ別レポートは公開しません。
• 現行プラットフォーム標準： サイトマップの上限、Core Web Vitals のしきい値、モバイルファーストの要件、クローラー制御、構造化データの適格性は、該当するプラットフォームの一次資料に基づきます。
• 業界のヒューリスティック： ビジネス上の優先度、期待される影響、修正の順序は、ファーストパーティデータに裏付けられていない限り、判断に基づくものです。
• ユーザーが設定可能なデフォルト： URL のサンプル数、ページネーションの上限、モジュールの深さは、スコープと利用可能な根拠によって異なります。サイト規模やトラフィックに固定のしきい値を設けないでください。

入力

次の情報を一度に尋ねます。

• ルートドメイン、正確な URL、または URL のセット。
• サイト全体、テンプレート、ページ単位のいずれを対象とするか。
• 重要なページタイプと、既知の移行、レンダリング、インデックス登録に関するインシデント。
• 既存の Semrush Site Audit プロジェクトへのアクセス権。
• 提供された Search Console、Analytics、CMS、クローラー、パフォーマンス、またはサーバーログの根拠。

Semrush API キーを尋ねないでください。公式 MCP は Semrush の認証を使用します。

公式 Semrush MCP のワークフロー

1. projects を呼び出し、list_projects を検出して、そのスキーマを取得し、実行します。
2. 該当するドメインを照合し、siteaudit が有効であることを確認します。
3. site_audit を呼び出し、続いて snapshots を検出してプロジェクトのスナップショットを取得します。
4. 完了済みの最新スナップショットを選択し、その ID と完了日時を保持します。
5. クロールのステータス、クロール済みページ数、上限、課題の合計、不具合、リダイレクト、ブロック／破損の件数、マークアップの合計、深さの分布について、info を実行します。
6. 現在の課題カタログを取得するため、meta_issues を実行します。定義は現在の発生状況を示すものではありません。
7. info.defects と meta_issues を結合します。現在の件数がある関連課題についてのみ、プロジェクト ID、スナップショット ID、課題 ID、制御された上限を使って issue_details を実行します。
8. 正確な URL を調査する場合は、page_list を使ってクロール済みページ ID を取得し、page_info でそのページの課題行を取得します。

プロジェクトへのアクセスは読み取り専用です。プロジェクトの作成、クロール設定の変更、連携機能の接続、クロールの開始を約束しないでください。課題 ID は変更される可能性があるため、永続的なリストにハードコードせず、再度検出してください。

根拠とアクセスに関するガードレール

• Semrush へのクエリで API ユニットが消費される場合があることをユーザーに伝えてください。まず少量の診断バッチを使用し、詳細な網羅性が求められる場合はページネーションを行ってください。
• クロールに設定された対象範囲を明示してください。「完全な監査」とは、設定と上限の範囲内で完了したクロールを意味し、稼働中またはインデックス登録済みのすべての URL が網羅されたことの証明ではありません。
• 課題が返されないレスポンスは、その課題とスナップショットについて該当する発生状況が返されなかったことを示す、有効な根拠です。
• Semrush の Error／Warning／Notice ラベルを、Google のペナルティやランキングの保証として言い換えないでください。
• Semrush のクロールデータ、Search Console の根拠、パフォーマンス測定値、直接の HTTP／ブラウザー観察、モデルの推論は、互いに分けてください。
• Search Console のパフォーマンスには「最終更新日」ディメンションはありません。公開日と更新日は、CMS、サイトマップ、ページメタデータ、またはその他の提供された情報源から取得してください。
• site: クエリは大まかな観察にすぎず、権威あるインデックス数ではありません。

フォールバックの優先順位

1. 既存の Semrush プロジェクトと完了済みの Site Audit スナップショット。
2. ユーザーから提供された Semrush Site Audit のエクスポート。
3. 提供されたクローラーのエクスポートと、Search Console、パフォーマンス、CMS、またはログのデータ。
4. 代表的な URL セットを対象とした、直接の HTTP およびレンダリング済みブラウザーでの確認。
5. ユーザーから提供された URL と証拠。

提供されたデータセットによって全範囲が網羅されていると確認できない限り、レベル 3～5 はサンプル調査として明記してください。

監査モジュール

まずクロール可能性とインデックス登録可能性を確認します。次に、ユーザーの対象範囲に必要な他のモジュールを実行し、結果を統合します。

1. クロール可能性とインデックス登録可能性

以下を確認します。

• 重要な URL の HTTP ステータスとリダイレクトの挙動。
• 重要なページやリソースに影響する robots.txt の構文とルール。
• XML サイトマップの利用可否、解析結果、正規 URL の形式、および掲載 URL がインデックス登録を意図したものかどうか。
• robots meta と X-Robots-Tag ディレクティブ。
• canonical の指定先と競合。
• 提供されている場合は、Search Console のインデックス登録に関する証拠。
• Site Audit が報告した、ブロック、未クロール、4xx、5xx、サイトマップ、canonical、重複コンテンツの問題。

robots.txt によるブロックはクロールを防ぎますが、インデックスからの削除を保証するものではありません。robots.txt ファイルがないことだけで、SEO 上の問題とは限りません。robots.txt にサイトマップの参照を記載することは有用ですが、サイトマップが機能するための必須条件ではありません。

Google の XML サイトマップの上限は、1 ファイルあたり 50,000 URL または圧縮前の 50 MB です。これらはプラットフォームの上限として扱い、Semrush のヒューリスティックとして扱わないでください。

2. HTTP、HTTPS、リダイレクト

以下を確認します。

• 証明書の有効性とホスト名の一致。
• HTTPS およびホストの優先バージョンに一貫性があること。
• 内部リンクやリソースにおける混在コンテンツ。
• 4xx／5xx の発生状況と、それらを露呈させる参照元 URL。
• リダイレクトチェーン、ループ、回避可能な内部リダイレクト。
• 永続的なリダイレクトと一時的なリダイレクトの意図。

実際に永続的な移転には 301／308 を、一時的な移転には 302／307 を使用します。一時的なリダイレクトはリンクエクイティを引き継げないと断定しないでください。コンテンツを意図的に削除した場合、404 が適切なこともあります。ナビゲーション、ビジネス上の重要性、被リンク、または代替コンテンツの意図を踏まえて修正が妥当な場合に、対応すべき問題となります。

3. Core Web Vitals とパフォーマンス

利用できる場合は、最新の Chrome UX Report のフィールドデータ／PageSpeed のフィールドデータを使用し、Lighthouse のラボデータと区別します。Google の現在の「良好」「改善が必要」「不良」の基準を 75 パーセンタイルで適用します。

指標	良好	改善が必要	不良
LCP	≤ 2.5 s	> 2.5 s to 4.0 s	> 4.0 s
INP	≤ 200 ms	> 200 ms to 500 ms	> 500 ms
CLS	≤ 0.1	> 0.1 to 0.25	> 0.25

指標だけを根拠に原因を推測しないでください。画像、JavaScript、フォント、キャッシュ、レイアウトの修正を提案する前に、診断結果または実装の証拠を確認します。フィールドデータを利用できない場合は、ラボの結果を合成データかつページ固有のものとして明記してください。

4. モバイルとの同等性とレンダリング

Google はモバイルファーストインデックスを使用するため、モバイルとデスクトップの以下の項目を比較します。

• 主要なコンテンツ。
• タイトルと meta description。
• robots ディレクティブと canonical タグ。
• 内部リンク。
• 画像と alt テキスト。
• 構造化データ。
• レンダリング可能なリソースとインタラクションに依存するコンテンツ。

JavaScript が重要なコンテンツやリンクを提供する場合は、未加工の HTML とレンダリング後の DOM を比較します。デスクトップのスクリーンショットだけから同等性を推測しないでください。ビューポート、ブロックされたリソース、JavaScript／CSS、モバイルユーザビリティに関する所見は、調査の根拠として扱い、自動的にランキングペナルティを意味するものとして扱わないでください。

5. タイトル、説明、見出し、canonical

現在の Site Audit の問題行とページ単位の確認を使用します。

• タイトルタグ： Semrush は、簡潔で説明的かつ検索意図に沿ったタイトルを推奨しています。目安は約 550 ピクセル以下、通常は 50～60 文字です。ただし、検索システムや AI システムに最大文字数の制限はないとも述べています。これは表示上の指針として扱い、ランキングを保証するものや自動的な不合格条件とはみなさないでください。
• メタディスクリプション： Semrush の現在の編集上の推奨では、表示時に省略されるリスクを抑えるため、最大約 135 文字を目安にします。メタディスクリプションは直接的なランキング要因ではなく、書き換えられる場合もあります。長さだけでなく、正確さと有用性に基づいて評価してください。
• H1／見出し： 明確なメイン見出しを 1 つ設け、H1／H2／H3 の階層を論理的に構成するよう推奨します。H1 を 1 つにすることは編集上の慣例であり、普遍的なランキング要件ではありません。タイトルと H1 は、完全に一致させる必要はありませんが、ページの目的に沿うようにしてください。
• canonical： 構文、参照先のステータス、インデックス登録の可否、ホスト／プロトコルの一貫性、重複を意図しているかどうか、リダイレクト、サイトマップ、hreflang、内部リンクとの競合を確認します。canonical はシグナルであり、命令ではありません。
• 画像： 情報を伝える画像には有用な alt テキストを設定し、装飾用の画像には空の alt テキストを設定してください。alt が空のものをすべてエラーとして指摘しないでください。

重複や長さに関するメタデータの問題は確認が必要ですが、それだけでキーワードのカニバリゼーション、ペナルティ、トラフィックの減少が証明されるわけではありません。

6. 構造化データ

Site Audit のマークアップ件数と、現在発生している構造化データの問題をスクリーニングの根拠として使用します。静的 HTML だけでは、JavaScript によって挿入されたマークアップを見落とすことがあります。

エンティティの選定、レンダリング後のマークアップの確認、JSON-LD の作成、検証は schema-markup スキルに委任します。この監査には、確認済みの問題の概要と優先度のみを記載してください。有効なマークアップがリッチリザルトを保証するわけではなく、無効または不一致のマークアップが自動的にランキングペナルティにつながるわけでもありません。

7. アーキテクチャと内部リンク

クロール深度の分布と、孤立ページ、内部リンク切れ、リダイレクト、アンカーテキストの欠落／説明不足、内部リンクの nofollow、内部リンクが少ないページに関する現在の問題を使用します。

詳細な改善計画は internal-link-audit に委任します。Semrush Site Audit では、クリック数が 3 回を超える URL が問題として検出されることがありますが、この製品のチェック項目は普遍的なランキング上の法則ではありません。アーキテクチャの変更は、固定のキーワード検索ボリュームやトラフィックのしきい値ではなく、ページの重要性、ユーザーの導線、クロールの根拠、提供されたファーストパーティのパフォーマンスデータに基づいて優先順位を付けてください。

8. AI クローラーのアクセス

現在の robots.txt のルールと、主要クローラーのドキュメントを確認します。

• OAI-SearchBot は、ChatGPT の検索結果に含めるための自動クロールを制御します。
• GPTBot は、コンテンツを OpenAI の生成 AI 基盤モデルのトレーニングに使用できるかどうかを制御します。
• ChatGPT-User はユーザー起点のクローラーであり、検索結果への掲載を制御するものではありません。
• Google-Extended は、指定された Gemini のトレーニングおよびグラウンディングでの利用を制御します。Google 検索への掲載やランキングには影響しません。

各ユーザーエージェントを、サイト運営者の目標に照らして評価してください。トレーニング用クローラーのブロックを技術的な SEO 上の欠陥と位置付けないでください。その他の AI クローラーについて主張する場合は、最新のファーストパーティドキュメントを確認してください。

優先順位付け

根拠に基づいて、以下の順に優先順位を付けます。

1. 重要な URL に影響する、アクセス、インデックス登録の可否、セキュリティ、リダイレクトループ、サーバー障害について確認済みの問題。
2. ユーザーまたは検索に明確な影響がある、テンプレート全体に及ぶことを確認済みの問題。
3. フィールドパフォーマンスの問題と、モバイル表示／レンダリングの不一致。
4. メタデータ、構造化データ、内部リンクの改善。
5. 検証が必要な、サンプル調査または推定に基づく所見。

ユーザー提供のファーストパーティの基準値と明示的なモデルがない限り、トラフィック、収益、回復までの時間、ランキングへの影響を推定しないでください。

出力

カバレッジから始めます。

エビデンスの分類	情報源	対象範囲	スナップショット／日付	制限事項

続けて、修正対応の表を1つ提示します。

優先度	モジュール	該当する URL またはパターン	取得したエビデンス	解釈	対応	確信度

各行について、以下の点を守ります。

• 正確な返却値、問題 ID、または観察された挙動を報告します。
• 確認済みの不具合、Semrush の製品チェック、プラットフォーム標準の障害、アナリストの判断を区別します。
• 推測できる場合は、修正担当（エンジニアリング、SEO、コンテンツ、デザイン、インフラストラクチャ）を明記します。
• データソースとテスト対象範囲によって裏付けられていない限り、「合格」としません。

最後に、以下を記載します。

1. すぐに修正： 確信度の高いブロッカーと動作不良。
2. 次に修正： 検証済みのテンプレートまたはユーザー体験の改善。
3. 委任： Schema Markup または Internal Link Audit のフォローアップ。
4. 検証： サンプリングに基づく情報、推定情報、または不足している一次エビデンス。
5. 利用不可： テストしていないモジュールまたはフィールド。

情報源

Semrush の方法論：

• テクニカル SEO
• テクニカル SEO 監査
• テクニカル SEO チェックリスト
• コアウェブバイタル
• タイトルタグ
• メタディスクリプション
• 正規 URL
• Robots.txt

プラットフォームの一次資料：

• Google 検索セントラル
• Web Vitals
• OpenAI クローラー
• Google クローラーの制御