技術的SEO（テクニカルSEO）とは、検索エンジンがウェブページを見つけ、内容を読み取り、適切なURLを検索結果の候補として扱えるように、サイトの構造や配信方法を整える施策です。
表示速度、モバイル対応、HTTPS、URL設計などを改善するため、利用者にとっての使いやすさとも深く関係します。
技術的SEOだけで検索順位が決まるわけではありません。
ページがクロールやインデックスの対象になれなければ、内容を評価してもらう前の段階で機会を失うため、コンテンツ施策の土台として整える必要があります。
この記事では、初心者にも判断しやすいように、14の施策を「何を確認するか」「なぜ必要か」「どう直すか」の順で整理します。
最初に知っておきたい4つの用語
技術的SEOでは、似た言葉の役割を区別すると設定ミスを減らせます。
| 用語 | 意味 | 確認したいこと |
|---|---|---|
| クロール | 検索エンジンのクローラーがURLへアクセスし、ページを読み取ること | 重要なページへの到達を妨げていないか |
| インデックス | 読み取ったページが検索用のデータに登録されること | 検索結果に出したいページが登録可能か |
| 正規URL | 同じ内容へ複数のURLから到達できる場合に、代表として扱ってほしいURL | 内部リンク、サイトマップ、canonicalの指定が一致しているか |
| 構造化データ | ページに書かれた情報の種類や関係を、決められた形式で検索エンジンへ伝える記述 | 画面に見える内容と記述が一致しているか |
クロールとインデックスを整える
検索結果に出したいページは、まずクローラーがアクセスでき、インデックスを妨げる設定がなく、代表URLが明確である必要があります。
この領域では、XMLサイトマップ、robots.txt、noindex、canonical、404の役割を混同しないことが出発点です。
1. XMLサイトマップを作成して送信する
XMLサイトマップは、検索対象にしたいURLを検索エンジンへ知らせるためのファイルです。
WordPressなどのCMSやSEOプラグインで生成し、Google Search Consoleから送信すると、読み取り状況や処理エラーを確認できます。
サイトマップの送信は、掲載したURLのクロールやインデックスを保証するものではありません。
公開中の正規URLだけを載せ、削除済みURL、リダイレクト元、noindexを指定したページが混在していないかを定期的に点検します。
2. robots.txtとnoindexを使い分ける
robots.txtは、クローラーがどのURLへアクセスできるかを制御するファイルです。
一方、noindexは、アクセスできたページを検索結果に表示しないよう伝える指示です。
この二つは代替関係ではありません。
robots.txtでアクセスを止めると、クローラーがページ内のnoindexを確認できないため、検索結果から確実に外す目的では使えません。
- クロール量を調整したいURLは、robots.txtの対象を慎重に検討する。
- 公開はするが検索結果には出したくないHTMLページは、noindexを検討する。
- 管理画面や機密情報は、クロール設定ではなく認証で保護する。
3. canonicalで代表URLをそろえる
並び順や絞り込み条件などによって、ほぼ同じ内容のURLが複数できることがあります。
そのままにすると、検索エンジンと運営者が想定する代表URLが一致しない場合があります。
rel="canonical"では、重複またはよく似たページ群から代表として扱ってほしいURLを指定します。
内部リンクとXMLサイトマップも同じURLへそろえ、移転後に旧URLを残す必要がない場合はリダイレクトを使います。
4. 404ページを正しく返す
存在しないURLには、見た目だけでなくHTTPステータスでも404を返します。
案内ページには、トップページ、主要カテゴリ、サイト内検索など、利用者が次の行動を選べるリンクを置きます。
削除したページと内容が同等の移転先がある場合は、そのURLへリダイレクトします。
関連性のないページへ一律に転送すると利用者を迷わせるため、代替ページがない場合は404のまま案内を整えるほうが明確です。
サイト構造とURLをわかりやすくする
5. ページ階層と内部リンクを整える
検索エンジンと利用者は、ナビゲーションや本文中のリンクをたどって関連ページを見つけます。
重要なページが孤立していないか、カテゴリ分けが重複していないか、リンクの文言だけで移動先を予測できるかを確認します。
パンくずリストは、「ホーム > 商品カテゴリ > 商品名」のように現在地を示す案内です。
階層を視覚的に示すだけでなく、上位ページへ戻る経路としても役立ちます。
6. URLを短く安定させる
URLは、ページの内容を推測できる簡潔な語で組み立てます。
例えば、ランニングシューズの選び方ならexample.com/running-shoes-guideのように、意味のある文字列を使えます。
パラメータが付くURLをすべて避ける必要はありません。
同じ内容のURLを無制限に増やさないこと、公開後にURLを頻繁に変えないこと、変更時に旧URLから適切に転送することが実務上の要点です。
表示速度、モバイル対応、HTTPSを点検する
7. モバイル版の内容をそろえる
モバイルファーストインデックスでは、Googleは主にモバイル版の内容をクロールし、インデックスとランキングに利用します。
画面が小さいという理由で、主要本文、見出し、画像の代替テキスト、構造化データなどをモバイル版から省かないようにします。
同じURLとHTMLを使い、画面幅に応じてレイアウトを変えるレスポンシブデザインは、モバイル対応を管理しやすい方法です。
文字の読みやすさや操作部品の押しやすさまで含めた設計は、モバイルアクセシビリティとレスポンシブ設計の実践方法で詳しく確認できます。
8. 画像と配信方法を軽くする
ページの読み込みが遅いと、内容を読む前に離脱される原因になります。
まず大きすぎる画像を表示寸法に合わせて圧縮し、必要に応じてWebPやAVIFなどの形式を検討します。
CSS、JavaScript、画像などの静的ファイルには、更新頻度に合ったブラウザキャッシュを設定します。
利用者が広い地域に分散しているサイトでは、CDNによって利用者に近い配信拠点からファイルを届ける方法もあります。
計測結果は、数値だけを上げる目的ではなく、どの処理が表示を遅らせているかを特定するために使います。
指標の読み方と改善箇所は、Core Web Vitalsの実践ガイドも参考になります。
9. HTTPSへ統一する
HTTPSは、利用者とサイトの間で送受信する内容を保護するための仕組みです。
有効な証明書を設定し、HTTPのURLは対応するHTTPSのURLへ転送します。
内部リンク、canonical、XMLサイトマップもHTTPSへ統一します。
HTMLだけでなく、画像やJavaScriptなどの読み込み先もHTTPSになっているかを確認します。
検索エンジンにページの意味を伝える
10. 構造化データを内容に合わせる
構造化データは、商品、レビュー、イベントなど、ページ上の情報が何を表すかを決められた形式で記述する仕組みです。
Google向けの実装ではJSON-LDを選ぶと、画面表示のHTMLと分けて管理しやすくなります。
記述する内容は、利用者がページ上で確認できる情報と一致させます。
実在しない評価や、本文にない価格を追加してはいけません。
正しく実装しても、検索結果に特別な表示が出るとは限りません。
公開前に検証ツールで文法と必須項目を確認し、公開後はSearch Consoleでエラーを監視します。
画像、動画、アクセシビリティを整える
11. 画像と動画の役割を伝える
内容を伝える画像には、その画像が担う情報や目的を簡潔な代替テキストで示します。
装飾だけの画像は空のalt属性にし、画像の近くに同じ説明がある場合は読み上げの重複を避けます。
動画には字幕を付け、音声だけで伝えている情報がある場合はテキストでも確認できるようにします。
ファイル容量の圧縮とあわせて、情報へ到達できる手段も整える必要があります。
12. 見出しと文章構造を論理的にする
ページの主題はH1、主要な区分はH2、その内訳はH3という順序で整理します。
文字を大きくする目的だけで見出し要素を使わず、見出しだけを読んでもページの構成がわかる名称を付けます。
13. キーボード操作と視認性を確保する
メニュー、ボタン、ダイアログなどは、マウスを使わなくてもキーボードで操作できるようにします。
現在選択している場所がわかるフォーカス表示も消さないようにします。
文字と背景には読み取れるコントラストを確保し、色だけで状態やエラーを伝えない設計にします。
Webアクセシビリティの対象と改善手順は、Webアクセシビリティの基本と実務ポイントで詳しく整理しています。
14. 自動検査と人による確認を組み合わせる
検査ツールは、代替テキストの欠落やコントラストなど、一部の問題を効率よく見つけられます。
ただし、代替テキストが画像の目的を正しく伝えているか、操作順が理解しやすいかまでは、自動検査だけでは判断できません。
実際のキーボード操作、画面拡大、読み上げなども確認し、公開後も新しいページや機能を追加するたびに点検します。
外部サービスを使って調査と改善を進める場合は、UUU ウェブアクセシビリティも選択肢の一つです。
アクセシビリティは検索順位を上げるためだけの施策ではありません。
障害のある人を含め、より多くの利用者が情報を理解し、操作できる状態を作ることが目的です。
実施順を決めるためのチェック表
すべてを同時に直すのではなく、検索結果への到達を妨げる問題から順に確認します。
| 症状 | 最初の確認項目 | 主な対応 |
|---|---|---|
| ページが検索結果に出ない | ステータスコード、robots.txt、noindex、canonical、サイトマップ | クロールとインデックスを妨げる設定を切り分ける |
| 同じ内容のURLが複数ある | 内部リンク、パラメータ、canonical | 代表URLを決め、各設定を一致させる |
| モバイルで内容が不足する | 本文、見出し、画像、構造化データ | 主要情報をデスクトップ版とそろえる |
| 表示が遅い | 画像容量、静的ファイル、キャッシュ | 遅い処理を計測して影響の大きい箇所から直す |
| 特別な検索表示が出ない | 構造化データの文法と本文との一致 | 必須項目とガイドラインを確認する |
| 操作しにくい | キーボード、フォーカス、見出し、代替テキスト、字幕 | 自動検査と実際の操作確認を組み合わせる |
技術的SEOを継続的に改善する
技術的SEOは、一度設定して終わる作業ではありません。
ページの追加、URL変更、テーマ更新、プラグイン導入などによって、クロールや表示速度の状態は変わります。
まずインデックスを妨げる問題を直し、次に代表URLと内部リンクをそろえ、モバイル表示、速度、構造化データ、アクセシビリティを順に点検します。
Search Consoleのエラーと利用者の操作上の問題を定期的に見直すことで、検索エンジンにも利用者にも理解しやすい状態を保てます。