テクニカルSEOとは：実践ガイド

定義：テクニカルSEOをわかりやすく

テクニカルSEO は、サイトレベルおよびページレベルの設定群で、検索エンジン が確実にページを検出、取得、レンダリング、インデックスできるようにするものです。コンテンツSEOが関連性やオンページのシグナルを重視し、オフページSEOがオーソリティに焦点を当てるのに対し、テクニカルSEOはアクセシビリティ、明確さ、パフォーマンスに注力します。適切なテクニカルSEOは摩擦を減らし、検索エンジンがコンテンツやオーソリティのシグナルを正しく評価できるようにします。

検索エンジンがページを処理する流れ：クロール、インデックス、レンダリング、ランク付け

混乱を避けるために処理を3つの段階に分けます：crawling（URLの発見と取得）、indexing（何を保存しどの版を保持するかの決定）、そしてranking（検索結果を並べること）:クエリ）。テクニカルSEOは各段階に影響を与えますが、直接的にランキングを“設定”するわけではありません。適切なコンテンツがインデックスに到達し、ランキングシステムが評価できる状態にすることが目的です。

モバイルファーストのインデックスとレンダリング

Googleはモバイル版を主な基準としてクロールとインデックス。2024年7月以降、GoogleはデフォルトでSearchをクロールする際にGooglebot Smartphoneを使用します。デスクトップとモバイルで意味のあるコンテンツや構造化データが同等であること（コンテンツパリティ）を確認し、モバイル版がインデックス可能なコンテンツを提供するようにしてください。

レンダリングと動的コンテンツ

レンダリングは取得したHTML、CSS、そしてJavaScript を最終的なDOMに変換します。重要なコンテンツやリンクがクライアントサイドのJavaScript実行後にのみ追加される場合、レンダリング後のDOMにそのコンテンツが含まれていることを確認してください。ブラウザのDevToolsやヘッドレスレンダリングによる検証を使って、検索エンジンが何を見るかをチェックしましょう。

確認すべき主要なテクニカル領域

以下はテクニカルSEOの効果が出やすい実務領域です。各項目について、仕組みと簡単な検証手順を次のセクションで説明します。

• クロール可否とrobotsコントロール（robots.txt, robotsメタ、x-robots-tag）
• インデックス化とカノニカル処理（rel="canonical"、canonical HTTPヘッダ、パラメータ処理）
• サイトアーキテクチャと内部リンク（論理的階層、クロール深度、リンクエクイティの流れ）
• パフォーマンスとページエクスペリエンス（Core Web Vitals: LCP、INP/FID、CLSおよび関連するランタイム指標）
• 構造化データとリッチリザルト（schema.orgマークアップ、Rich Results Test）
• HTTPステータス、リダイレクト、カノニカルヘッダ（正しい2xxレスポンス、3xxチェーン、一貫したホスト／カノニカルターゲット）

仕組みと検証：今すぐ実行できる実践的チェック

クロール可否チェック（外部優先）

サイトを所有していない場合（例：出版社やリンク掲載を評価する場合）、以下の公開チェックを利用してください：

• curlで生のHTMLを取得して、リンクや要素がサーバーのレスポンスに存在するか確認します：curl https://example.com/page（これはボディを取得します）。
• ヘッダのみを確認するにはcurl -I https://example.com/page を使ってステータス、x-robots-tag、キャッシュヘッダを確認します。
• ブラウザでレンダリングされたDOMを確認：DevTools → Elementsを開き、JavaScriptで追加されたコンテンツが存在し表示されているか（クリックハンドラや認証で隠れていないか）を確認します。
• Google検索結果やsite:演算子を、ページがGoogleに認識されている公開シグナルとして利用します。site:は示唆的なシグナルであり、インデックス化の確定的な証拠ではない点に注意してください。

サイトを所有している場合の検証

所有するページについては、権威あるアクセス権を持つツールを使用してください：

• Google Search Console — URL Inspectionでクロール、インデックス、ページフェッチの詳細を確認；レンダリングされたHTMLや報告されたインデックスの問題をチェックしてください。
• Rich Results TestとSchema Markup Validatorで構造化データを検証します。
• Chrome DevToolsのPerformanceとLighthouseでCore Web Vitalsを計測し、レンダリングに影響する長いタスクやレイアウトシフトを観察します。

よくある問題、重要な理由、対処法

ブロックされたリソースやクロール禁止パス

問題：CSSやJS、またはサイトの一部がrobots.txtやx-robots-tagでブロックされ、レンダリングが不正確になったりインデックスにコンテンツが入らない。対処：重要なレンダリングに影響するリソースを許可するか、インデックス不要なアセットにはx-robots-tagを慎重に使う。

重複コンテンツと誤ったカノニカル

問題：複数のURLが類似コンテンツを提供し、明確なシグナルがないためインデックスの注意が分散する。対処：優先URLを指すrel="canonical"を実装し、内部リンクを一貫させ、長いリダイレクトチェーンを避ける。

ページの遅さと低いCore Web Vitals

問題：LCPが遅い、またはメインスレッドの長いタスクにより、ユーザーやレンダリングタイミングに依存するクローラにページが迅速に表示されない。対処：サーバー応答時間を最適化し、重要でないJSを遅延させ、画像を適切なサイズで配信する。

リンク、外部掲載、ポリシーの考慮点

テクニカルSEOとbacklinkは、出版社のインデックス可能性やリンク属性が掲載が発見・評価されるかを決める点で交差します。Googleがインデックスしないページ上のリンクは、インデックスされたクロール可能なページ上のリンクよりも一般的にSEO上の関連性が低くなります。コントロールできない第三者の掲載では、200ステータスを返し、クロールを許可し、レンダリングされたHTMLでリンクが露出しているページを優先してください。

リンク属性のHTML例：

特別なrelがない標準的なリンク：例

有料掲載の場合はrel="sponsored"を使用：例

ユーザー生成コンテンツにはrel="ugc"を使用：例

Googleのリンクスパムに関するガイダンスと有料リンク

Googleの公開ガイダンスでは、ランキング操作を主目的としたリンクはリンクスパムとして扱われる可能性があるとしています。有料やスポンサー付きの掲載にはrel="sponsored"またはrel="nofollow"を使用すべきです。Googleはこうしたヒントを無視したり、アルゴリズムによる調整を行ったり、稀に人間のレビュアーがポリシー違反と判断した場合は手動対応を行うことがあります。有料掲載を評価する際、技術的シグナル（インデックス可能性、クロール可能性、ページの編集コンテキスト）はサードパーティのオーソリティスコアと同等以上に重要です。

リンクマーケットプレイスと連携する場合、インデックス可能性のチェックを出版社のデューデリジェンスに組み込んでください。BlogDripは、広告主と多数の認証済み出版社をつなぐlink-building マーケットプレイスとして、掲載の評価時にインデックス可能性と編集コンテキストが重要であることを強調しています。

実践的トラブルシューティングチェックリスト

1. ページが200 OKを返すことを確認（リダイレクトが意図されている場合は正しい3xx）：curl -I https://example.com/page
2. パスに影響するdisallowを確認するためrobots.txtをチェック（取得：https://example.com/robots.txt）およびcurl -Iでx-robots-tagヘッダを確認してください。
3. Chrome DevToolsでページのレンダリングを表示し、最終的なDOMを確認するとともに隠れた、または遅れて挿入されるコンテンツを見つけてください。
4. Rich Results TestとSchema Markup Validator (schema.org)を使って構造化データを検証してください。
5. Core Web Vitalsをフィールドデータ（Chrome User Experience Report）とラボテスト（Lighthouse）で測定します。大きなレイアウトシフト、長い入力遅延、長いLCPの修正を優先してください。

デバッグコマンドの正しい使い方

一般的なcurlパターンとその用途

ヘッダのみ確認する：curl -I https://example.com/page はレスポンスヘッダのみを返します（ステータス、server、x-robots-tag、リダイレクト先のlocationなど）。

HTMLを確認するためにボディを取得：curl https://example.com/page（これはレスポンスボディを返します）。特定のUser-AgentでHTMLを取得するには：curl -A "YourUserAgentString" https://example.com/page.

事例：簡単なシナリオと対処法

シナリオ：長時間実行するスクリプト後にのみ表示されるコンテンツ

症状：クローラはHTMLを取得するが、有用なコンテンツが遅れて注入されるかユーザー操作後にのみ表示される。対処：重要なコンテンツをサーバーサイドレンダリングするかハイブリッドレンダリングを導入し、重要なコンテンツと構造化データが初期HTMLまたは早いレンダリング段階で出現するようにする。

シナリオ：URLパラメータによる多数の近似重複ページ

症状：インデックスの膨張とシグナルの分散。対処：優先URLにカノニカル化し、内部リンクを一貫させ、アナリティクスやSearch Consoleのパラメータ処理を検討する。

エスカレーションの判断：手動措置、アルゴリズム問題、レポーティング

トラフィックの若干の減少は、通常レビュワーによる手動措置ではなくアルゴリズムの調整を反映しています。手動措置はGoogle Search Consoleで確認でき、submit-and-verifyのワークフローが必要です。問題が手動措置かどうかはSearch Consoleで確認し、そうでなければ技術的な修正とコンテンツや編集上のレビューを組み合わせてアルゴリズム変更から回復を図ってください。

リソースと次のステップ

より包括的な運用チェックリストが必要な場合は、親ガイドを読み、詳細な手順、ツール、優先度の高い修正を確認してください。Technical SEOガイドを読む

作業が出版社の掲載に関わる場合、マーケットプレイスを評価して出版社のインデックス可能性や編集上の適合性を確認することもできます。バックリンク用の出版社を閲覧する

FAQ