技術 SEO の確認順序：クロール、索引、表示、サイト構造

赤い警告が何百件も並ぶ SEO レポートを受け取ったとき、難しいのは用語の理解より、何を先に直すかの判断です。トップページが開かないこと、画像の説明が一つ欠けていること、速度テストの点数が少し低いことは、読者とサイトへの影響が同じではありません。

技術 SEO は、コンテンツが検索の流れに入る前の基礎確認と考えられます。URL を見つけられるか、正しい応答が返るか、主な内容を読めるか、異なる版が適切な場所を指すかを調べます。この記事では、各問題に範囲、根拠、完了条件を付け、保守担当者に渡せる監査手順にまとめます。

最初にサイトの範囲と代表ページを決める

ベーキングスタジオのサイトを改修した例では、トップページ、講座一覧、各講座、記事、問い合わせページ、会員エリアがあるかもしれません。検索に公開したいページと、ログインした受講者だけに見せるページを先に区別します。会員エリアが索引に登録されていないのは設計どおりかもしれず、未登録の URL をすべてエラーとは扱えません。

ページのテンプレートごとに代表 URL を選び、最近追加・移動したページや以前に問題があったページも含めます。講座のテンプレートなら募集中と終了済みの講座を一つずつ、記事なら図表付きとテキストのみのものを一つずつ選びます。抽出の目的は共通テンプレートの問題を見つけることであり、一ページが正常だから全サイトも正常と推測することではありません。

作業表には少なくとも URL、ページの種類、公開目的、確認日時、見つかった問題、影響範囲を記録します。今回の改修でテーマ、プラグイン、ドメイン、パスのどこが変わったかも残してください。後で異常が出たとき、あらゆる原因を一から推測する代わりに、変更箇所と照らし合わせられます。

第一段階：正しい内容を取得できるか

Google の基本的な技術要件には、クローラーを妨げないこと、ページが成功応答を返すこと、索引登録できる内容があることが含まれます。要件を満たしても登録は保証されません。ただし公開予定の講座ページがエラーを返したりログインを要求したりするなら、まずその入口の障害を解消します。検索結果での見え方より、内容を使える状態に戻すことが先です。

ログアウト状態のウィンドウで代表 URL を開き、正しいページが表示されるか確認します。保守担当者には HTTP ステータス、リダイレクト、ファイアウォールの応答も確認してもらいます。画面に講座名が見えるだけでは、サーバーの応答が正しいとは限りません。逆に成功応答でも、空白ページや認証画面しか出ないなら、実際の閲覧には使えません。

サイト全体、特定のテンプレート、個別ページの問題を分けます。全講座ページがログイン画面に送られるなら共通の権限設定を、古い講座だけが失敗するならパスの対応を調べます。元の URL と最終到達先を保存し、一つのリダイレクトを直した結果、別のループへ誘導してしまうのを防ぎます。

第二段階：索引指示と版の選択を確認する

ページの robots メタタグ、関連する応答ヘッダー、robots.txt を調べ、公開目的と一致するか確認します。テストサイトには索引登録を禁止する設定がよくあり、公開前に再確認しないと本番の記事まで除外されるおそれがあります。管理画面の設定がオフになったと信じるだけでなく、実際の出力を確認してください。

同じ内容を示す複数の URL について、canonical 指定、Sitemap、内部リンク、リダイレクトが整合しているか確認します。Google はこれらを強さの異なる正規化シグナルとして扱い、サイト側の指定を絶対命令とは見なしません。Sitemap には一つの版を載せながらページでは別の版を指定したり、異なる講座をすべてトップページへ向けたりしないでください。

Search Console で索引登録済みの版に関する正規 URL 情報を見てから、ライブテストで現在のページを確認します。二つは異なる時点の問題に答えます。公式説明によると、ライブテストで Google が最終的に選ぶ正規版を予測することはできません。完了判定では、現在の出力が修正されたか、索引データが更新されたかを別々に記録します。

第三段階：実際の表示とサイト内の経路を見る

主な内容を JavaScript で読み込む場合は、レンダリング後の HTML、画面、読み込みに失敗したリソースを確認します。Google は JavaScript を実行できますが、遮断されたリソースやプログラムのエラーには影響を受けます。他のツールが同じ能力を持つとも限りません。以前そのページを読み込んだ自分の端末で表示できたからといって、初めて来るすべての人にも同じ内容が見えるとは言えません。

ベーキング講座のページでは、名称、日時、場所、材料の説明、申込口を一つずつ確認します。講座情報をすべて操作後にだけ現れる画面へ移す前に、確認ツールが取得する版を調べます。元の応答に外枠しかない場合は、開発者に表示方法を見直してもらい、サーバー側での表示や事前生成が適切か評価します。

トップページ、講座の分類、個別講座、関連記事の順にたどり、重要ページにクローラーがたどれるリンクの入口があるか確認します。メニューの階層数だけを数えるのではなく、孤立したページ、誤ったリンク先、過度なリダイレクトを記録します。クローラーが URL を見つけられるかとともに、読者が次にどこへ進むか理解できるかも完了判定に含めます。

第四段階：体験と検索上の表示を計画的に改善する

基本機能が使えるようになったら、モバイル版の読み込み、操作応答、レイアウトの安定性を確認します。Core Web Vitals は現在、これらの側面に対応する LCP、INP、CLS を含みます。講座画像が申込ボタンを押し下げる、クリックしても反応しないといった実際の問題を先に探し、ツールのデータで原因を絞ります。一度の速度テストの点数を利用者体験の代わりにしないでください。

構造化データを使うサイトでは、マークアップがページで見える内容とその種類の公式要件に合うか確認します。検索で特別な表示を得るために、架空の評価や表示していない情報を入力してはいけません。リッチリザルトテストは技術的な問題の発見に役立ちますが、合格しても対応する表示が検索結果に必ず出るわけではありません。

改善は、講座画像の表示領域を先に確保する、共通データ項目を一つ直す、重すぎるリソースを調整するなど、小さな作業に分けます。それぞれ変更前後の例を残し、申込みと閲覧が壊れていないか確認します。費用を計画しやすくなり、期待と異なる結果が出たときにも原因となった変更を探しやすくなります。

完了できる作業として監査報告を書く

問題は「重要な内容を読めなくする」「一部の入口や情報に影響する」「品質や保守を改善する」などで優先度を付け、影響ページ数と修正リスクも別に示します。これは管理のための分類で、Google が公表するスコアではありません。同程度に重大な二件なら、主要サービスに影響し、原因が明確なものから対応します。

各作業票には再現手順、期待する結果、現在の結果、影響する URL、完了条件を書きます。たとえば「ログアウト中の訪問者が講座ページで正しい日時を確認でき、成功応答が返り、意図しない noindex がない」は、「SEO を改善する」より確認しやすい条件です。共通テンプレートを直した後は、以前から正常だった他のページも抽出して再確認します。

報告の最後には、修正済み、索引更新待ち、成果の観察待ちを分けて列挙します。サイト設定が検査を通れば技術作業は完了できます。検索データがまだ更新されていない場合は追跡日を残し、待っている間に順位が上がったと表現しないでください。次の改修時にも同じ代表ページを完了判定の基準にできます。

1. 公開範囲と種類ごとの代表 URL を決め、改修内容を記録する。
2. アクセス、索引、表示、リンク、体験の順に根拠を集める。
3. 各問題の影響、担当者、再現可能な完了条件を示す。
4. 修正後に影響するテンプレートを再確認し、索引と検索データは別に追跡する。

クロール効率とサイトのログを詳しく調べる

改修前にサイトをバックアップする

• チュートリアル
• アプリ・ソフト
• マーケティング・SEO
• SEO