SEO監査

技術的な SEO 監査チェックリスト: チェックする内容とその理由

アクセス、レンダリング、インデックス作成シグナル、および内部リンクを明確な検証手順と結びつける、技術的な SEO 監査チェックリストを使用します。

7 分で読めます
技術専門家がウェブサイトのアーキテクチャとクロール パスをチェックします。

技術的な SEO 監査では、重要なページが意図どおりに検出、取得、レンダリング、解釈できるかどうかをチェックします。最も役立つチェックリストは、各チェックと理由および検証方法を組み合わせたものです。これにより、一連の警告が開発者が完了できる作業に変わります。

ビジネスをサポートするページと、それらを生成するテンプレートから始めます。クロール範囲とアクセス制限の記録を保持します。技術的にきちんとしたサンプルだけでは、大規模な Web サイトが健全であると宣言するには十分ではありません。

代表的なクロールを確立する

ホームページ、重要なカテゴリまたはサービス、個別の詳細ページ、およびサポート ガイドをリストします。クローラーの開始点でスコープ全体を定義するのではなく、関連するサブドメインと URL バリアントを意図的に含めます。

検出されたページを、存在すると予想される URL と比較します。ページ数が少ない場合は、ナビゲーションの制限、アクセス制限、JavaScript のみのリンク、またはクロール制限があることを示している可能性があります。クロールが完了したものとして扱う前に、ギャップを調査してください。

の SEO監査ガイド スコープ設定、優先順位付け、引き継ぎの広範なプロセスについて説明します。このチェックリストは、そのプロセス内の技術的証拠に焦点を当てています。

応答とリダイレクト先を確認する

重要な公開ページは、適切な応答と有用なコンテンツを返す必要があります。エラー、繰り返されるリダイレクト、およびエラー メッセージが表示されながら成功ステータスを返すページを調査します。リダイレクトが存在するかどうかだけでなく、最終的な宛先を検査します。

リダイレクトは賢明なユーザー ジャーニーを維持する必要があります。削除されたすべてのページをホームページに送信すると、訪問者を混乱させながら目に見えるエラーを 1 つ取り除くことができます。古い URL を、代替の URL が実際に存在する関連する宛先にマップします。

ソース URL、応答、宛先、および意図された動作の表を保持します。変更後、古いアドレスと宛先の両方を再テストします。リダイレクトによって別の不要なホップが導入されないことを確認します。

ロボットとインデックス作成命令を確認する

robots.txt とページレベルの命令を適切な役割で検査します。クロール制限とインデックス作成ディレクティブは互換性がありません。重要なページを取得できるかどうか、またそのページに表示されているディレクティブが意図したインデックス作成ポリシーと一致するかどうかを確認してください。

テンプレート、ステージング関連の設定、または新しく起動されたセクションに関する noindex の指示を確認してください。ツールが報告するという理由だけで、プライベート ページ、重複ページ、またはユーティリティ ページから意図的な除外を削除しないでください。

インデックス診断には Google のソース ツールを使用します。クローラーはディレクティブを識別できますが、ページを読み取るだけでは、すべての URL に対する Google の現在のインデックス付けの決定を最終的に報告することはできません。

正規関係を確認する

正規の参照が意図的で有効であり、ページの目的と一致していることを確認してください。間違ったサービス、ロケール、またはホスト名を指している正規は調査に値します。自己参照は、すべての重複コンテンツの問題を解決できるわけではありません。

内部リンク、リダイレクト、サイトマップ エントリ、ページ バリアントなど、関係全体を見てください。矛盾したシグナルがあると、意図した構造が不明確になる可能性があります。どの URL がコンテンツを表す必要があるのか​​、およびその理由を文書化します。

説明的な例: 製品テンプレートが誤ってすべての製品のカテゴリ URL を正規として出力してしまいます。修正はテンプレートに含まれており、その後、いくつかの製品で検証し、目的の URL 構造を確認します。

JavaScript のレンダリングとパブリック アクセスを検証する

最初の HTML と、ページの読み込み後に通常の訪問者が受け取るコンテンツを比較します。重要なテキストとクロール可能なリンクが、関連するクローラーが処理できる形式に存在するかどうかを確認します。空のアプリケーション コンテナを空のビジネス Web サイトと混同しないでください。

Googleの JavaScript SEO ガイダンス クロール、レンダリング、インデックス作成を関連する段階として説明します。監査のために、ツールがレンダリングされたコンテンツを検査したかどうか、およびスクリプトまたは必要なリソースが失敗したかどうかを記録します。

同意画面、年齢ゲート、認証についても確認してください。クローラーのセッションはブラウザーのセッションとは別のものです。監査中に使用される許可されたアクセスの処理を文書化します。未解決のゲートの背後にあるコンテンツが完全にチェックされているとは記述しません。

訪問者がメイン ナビゲーションから重要なページまでたどることができるパスに従います。壊れたリンク、無関係なリンク先、サイトマップまたは直接 URL 経由でのみ見つけられるページがないか確認します。ページは、サイトに意味のある接続がなくても存在できます。

訪問者が目的地を理解しやすくなる場合は、説明的なリンク テキストを使用します。内部リンクを、固定数の完全一致アンカーを必要とする式として扱うことは避けてください。有益な質問は、次の関連ページが簡単に見つかるかどうかです。

孤児候補者が発見された場合、それを公開し最新のものにする必要があるかどうかを確認します。古いキャンペーン ページ、一時 URL、および意図的に廃止されたコンテンツは、新しいナビゲーション リンクではなく、削除またはリダイレクトが必要な場合があります。

サイトマップの品質を確認する

サイトマップには、一貫したナビゲーションの代わりとして機能するのではなく、検索エンジンが検出する URL を記述する必要があります。それが実際に期待された形式の XML であることを確認してください。一部のアプリケーションは、sitemap.xml などの不明なパスごとに同じ HTML シェルを返します。

リストされた URL のサンプルを検査して、応答ステータス、正規の一貫性、および意図されたインデックス可能性を確認します。サイトマップ インデックスと子ファイルが存在する場合はそれを確認します。サイトマップが存在するということは、リストされているすべてのページがインデックス付けされることを意味するとは考えないでください。

URL の移行後、サイトマップと新しい構造を比較し、サイトの意図されたポリシーに従って古いエントリを削除します。検証日を監査記録に記録します。

モバイル体験とパフォーマンスの証拠を確認する

代表的なページを狭いビューポートでテストします。クリップされたコントロール、アクセスできないナビゲーション、読めない表、オーバーレイによって隠されている重要なコンテンツを探します。テスト環境または承認された検証に必要な範囲で、一次問い合わせまたは購入手続きを完了します。

コンテキストなしでスコアを追うのではなく、パフォーマンス測定を使用して特定のボトルネックを特定します。臨床検査と現場観察を区別し、装置と条件を記録します。 1 回の高速テストでは、すべての訪問者が高速なエクスペリエンスを体験できるとは限りません。

重要なタスクを妨げる問題を優先します。サービス問い合わせへのアクセスを遅らせる装飾効果は、使用に影響を与えない小さな視覚的な違いよりも重要な場合があります。

構造化データと国際シグナルを確認する

構造化データが表示されているページを正確に記述し、適切なタイプを使用していることを確認してください。無効な値または誤解を招く値を修正しますが、検証に合格したからといって特別な検索結果が表示されることを約束するものではありません。

多言語サイトまたは地域サイトの場合は、言語と国のバージョン間の意図された関係を検査します。訪問者が正しいバージョンにアクセスできること、およびシグナルが無関係なページを指していないことを確認します。本当に必要がない限り、単一市場サイトに国際的な注釈を追加しないでください。

これらのチェックは、AI の可視性に関するサポートされていない主張とは別にしてください。有効なマークアップでコンテンツを説明できます。システムがそのページを引用することを保証するものではありません。

チェックリストを検証台帳に変える

チェックリストを検証台帳に変える
見つけるオーナーのタスク検証
リダイレクト先が間違っていますマッピングを修正する古い URL が関連する最終ページに到達する
レンダリングされたナビゲーションが見つからない修復リンク出力公開レンダリングされたページは使用可能なリンクを公開します
意図しない noindexテンプレート設定を修正するライブ ディレクティブが意図したポリシーと一致する
無効なサイトマップ応答正しい XML を提供するパーサーは意図した URL を正常に読み取ります
壊れたモバイルアクションコントロールまたはレイアウトを修復する代表訪問者がアクションを完了できます

根本原因とビジネスへの影響別に調査結果をグループ化します。テンプレートの問題は、影響を受ける URL が多数ある 1 つの実装タスクに値する場合があります。テスト用に詳細を保存しますが、何百もの同一の命令でバックログが膨らむことは避けてください。

UpStrait’s 監査機能 このワークフローをサポートするために、キャンペーンの調査結果と影響を受けるページの詳細を提供します。証拠をタスクと一緒に保管し、 SEOスコアの説明 関係者とサマリー番号について話し合うとき。

よくある質問

すべての技術的な警告を修正する必要がありますか?

いいえ。まず、それがページの意図された目的にとって実際の問題であることを確認してください。一部の除外やリダイレクトは意図的に行われます。重要なページや訪問者のタスクに影響を及ぼす確認済みの問題を優先します。

技術監査に合格したということは、内容が良好であることを意味しますか?

いいえ、技術的なアクセスとページの有用性は別の問題です。技術的にアクセス可能なページであっても、あいまいであったり、不正確であったり、検索意図との一致が不十分であったりする可能性があります。別途コンテンツレビューを含めます。

修正が完了したことを確認するにはどうすればよいですか?

代表的なページで実際の動作を確認し、同等の範囲で関連するチェックを再実行します。証拠と日付を保管してください。コードの変更やクローズされたチケットだけでは、意図した運用動作が行われていることを証明することはできません。