テクニカルSEOとは？ — コンテンツSEO・外部SEOとの違い
SEO対策は大きく3つの領域に分けられます。テクニカルSEO、コンテンツSEO、外部SEO（オフページSEO）です。それぞれの役割と対象範囲を整理しましょう。
| 項目 | テクニカルSEO | コンテンツSEO | 外部SEO |
|---|---|---|---|
| 目的 | 検索エンジンがサイトを正しく理解・評価できるようにする | ユーザーの検索意図に応える高品質なコンテンツを提供する | 外部からの信頼性シグナル（被リンク等）を獲得する |
| 主な施策 | クロール最適化、インデックス制御、サイト速度改善、構造化データ実装 | キーワード調査、記事作成、E-E-A-T強化、コンテンツリライト | 被リンク獲得、サイテーション構築、SNS拡散、PR活動 |
| 対象 | サイトのインフラ・コード・設定ファイル | ページ上のテキスト・画像・動画 | 外部サイト・メディア・SNS |
| 担当者 | エンジニア・Web制作者・SEO担当者 | ライター・編集者・マーケター | PR担当・マーケター・広報 |
| 効果の特性 | 土台整備。直接的な順位上昇よりも「マイナス要因の排除」が中心 | 検索意図への合致度が高ければ直接的に順位向上 | ドメインオーソリティの向上で間接的に順位向上 |
| 比喩 | 建物の基礎工事 | 建物の内装・設備 | 建物の評判・口コミ |
テクニカルSEOは「建物の基礎工事」にあたります。基礎が傾いていれば、どんなに美しい内装（コンテンツ）を施しても建物は長持ちしません。同様に、テクニカルSEOの不備があると、コンテンツの質が高くても検索エンジンからの評価を十分に得られないのです。
詳しくは「テクニカルSEOとは」の記事でも基本概念を解説しています。また、テクニカルSEOはSEO内部対策の一部でもあるため、「SEO内部対策」と合わせて理解を深めるのがおすすめです。
テクニカルSEOが重要な理由 — 土台がなければコンテンツも活きない
テクニカルSEOが重要である理由は、以下の4点に集約されます。
1. クロールされなければ検索結果に表示されない
Googleのクローラー（Googlebot）がページを発見し、コンテンツを読み取れなければ、そのページはインデックスされず、検索結果に一切表示されません。robots.txtの誤設定やサーバーエラーが原因で、せっかく作ったページがクロールすらされていないケースは実務で頻繁に見られます。
2. インデックス品質が検索順位に直結する
重複コンテンツやcanonicalタグの誤設定があると、Googleはどのページを正規ページとして扱うべきか混乱します。その結果、本来評価されるべきページの順位が下がったり、クロールバジェットが無駄に消費されたりします。
3. ページエクスペリエンスがランキング要因になっている
2021年のPage Experience Updateに始まり、GoogleはCore Web Vitals（LCP・INP・CLS）をランキングシグナルとして使用しています。2024年3月にはFIDがINP（Interaction to Next Paint）に正式置換され、2026年現在もこの指標がユーザー体験評価の中核を担っています。ページの表示速度やインタラクティブ性の改善は、テクニカルSEOの重要な領域です。
4. AI Overview時代にも技術基盤は不可欠
2025年以降、Google検索結果ではAI Overview（旧SGE）が広く展開され、AIが生成する概要文が検索結果上部に表示される場面が増えました。AI Overviewに引用されるためには、まずGooglebotがコンテンツを正確にクロール・インデックスしていることが前提です。構造化データによるコンテンツの意味づけも、AIによる情報抽出の精度を高めます。テクニカルSEOはAI時代においてもSEOの土台であり続けています。
テクニカルSEOの6大カテゴリ（全体俯瞰）
テクニカルSEOの施策は多岐にわたりますが、大きく6つのカテゴリに分類できます。以下のテーブルで全体像を把握しましょう。
| カテゴリ | 主な目的 | 代表的な施策 | 主要ツール |
|---|---|---|---|
| 1. クローラビリティ | 検索エンジンがページを発見・取得できるようにする | robots.txt最適化、XMLサイトマップ、クロールバジェット管理 | Google Search Console、Screaming Frog |
| 2. インデクサビリティ | 正しいページが正しくインデックスされるようにする | canonical設定、noindex/nofollow制御、重複排除 | Google Search Console、Ahrefs Site Audit |
| 3. サイトアーキテクチャ | サイト構造を論理的に整理し、リンクジュースを適切に配分する | URL設計、内部リンク設計、パンくずリスト、ディレクトリ構造 | Screaming Frog、Ahrefs |
| 4. ページエクスペリエンス | ユーザーに快適なページ体験を提供する | Core Web Vitals改善、HTTPS化、モバイル対応、セーフブラウジング | PageSpeed Insights、Lighthouse、Chrome DevTools |
| 5. 構造化データ | ページの意味を検索エンジンに明示し、リッチリザルトを獲得する | JSON-LD実装、Schema.orgマークアップ、リッチリザルトテスト | リッチリザルトテスト、Schema Markup Validator |
| 6. 国際化・多言語対応 | 言語・地域別に適切なページを配信する | hreflangタグ、言語別URL設計、ccTLD/サブディレクトリ戦略 | Google Search Console、hreflang Tags Testing Tool |
それでは、各カテゴリの具体的な施策をコード例を交えながら見ていきましょう。テクニカルSEOを体系的に学びたい方は、教材 第6章や第7章も参考にしてください。
カテゴリ1. クローラビリティ
クローラビリティとは、検索エンジンのクローラーがサイト内のページを発見・取得できる度合いのことです。クローラビリティが低いと、いくら質の高いコンテンツを作っても検索結果に表示されません。
robots.txtの設定
robots.txtはサイトのルートディレクトリに配置し、クローラーのアクセスを制御するファイルです。正しく設定しないと、重要なページがクロールされなかったり、逆にクロールしてほしくないページにクロールバジェットが浪費されたりします。
詳しい書き方は「robots.txtの書き方」で解説していますが、ここでは基本的な設定例を示します。
Before（よくある誤設定）
# 全クローラーをブロックしてしまっている例
User-agent: *
Disallow: /
# サイトマップの記述がない上記の設定では、すべてのクローラーに対してサイト全体のクロールを禁止しています。開発環境からの設定がそのまま本番に残っているケースで頻繁に見られるミスです。
After（推奨設定）
# 全クローラーに対する基本設定
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /tmp/
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?session_id=
# AdsBot-Googleには個別指定が必要（デフォルトでDisallowを無視する）
User-agent: AdsBot-Google
Disallow: /admin/
# サイトマップの場所を指定
Sitemap: https://example.com/sitemap.xmlポイントは以下のとおりです。
- Allow: / を明示し、基本的にすべてのページをクロール許可する
- 管理画面やAPI、一時ファイルなどクロール不要なパスをDisallowで指定する
- ソートやフィルターのパラメータ付きURLをDisallowし、重複クロールを防ぐ
- Sitemapディレクティブでサイトマップの場所をクローラーに通知する
- robots.txtの変更後はGoogle Search Consoleの「robots.txtテスター」で検証する
XMLサイトマップの作成
XMLサイトマップは、クローラーにサイト内の重要なURLを一覧として伝えるファイルです。特に大規模サイトや新規サイトでは、内部リンクだけではクローラーが全ページを発見できない場合があるため、サイトマップの役割は大きくなります。
Before（問題のあるサイトマップ）
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<!-- noindexページや404ページが混在 -->
<url>
<loc>https://example.com/old-page-404</loc>
</url>
<url>
<loc>https://example.com/noindex-page</loc>
</url>
<!-- lastmodが全ページ同じ日付 -->
<url>
<loc>https://example.com/page1</loc>
<lastmod>2024-01-01</lastmod>
</url>
</urlset>After（推奨されるサイトマップ）
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<!-- インデックスさせたいページだけを掲載 -->
<url>
<loc>https://example.com/</loc>
<lastmod>2026-03-10</lastmod>
<changefreq>weekly</changefreq>
<priority>1.0</priority>
</url>
<url>
<loc>https://example.com/service/</loc>
<lastmod>2026-02-20</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
<url>
<loc>https://example.com/blog/technical-seo/</loc>
<lastmod>2026-03-15</lastmod>
<changefreq>monthly</changefreq>
<priority>0.7</priority>
</url>
</urlset>サイトマップ作成のルールは次のとおりです。
- 200ステータスを返すページのみ掲載する（404、301、noindexページは含めない）
- canonicalタグで指定した正規URLのみ掲載する
- lastmodは実際にコンテンツが更新された日付を正確に記載する
- 1つのサイトマップファイルに含めるURLは50,000件以下、ファイルサイズは50MB以下にする
- 大規模サイトではサイトマップインデックスファイルを使って分割する
- Google Search Consoleからサイトマップを送信し、処理状況を確認する
クロールバジェットの最適化
クロールバジェットとは、Googlebotが一定期間内にサイトに対して行うクロールの上限のことです。小規模サイト（数百ページ程度）ではあまり意識する必要はありませんが、数万〜数百万ページ規模のサイトではクロールバジェットの最適化が重要になります。
クロールバジェットを無駄にしないための施策は以下のとおりです。
- 不要なURLを排除する: パラメータ違いの重複ページ、検索結果ページの無限ページネーション、セッションID付きURLなどをrobots.txtでブロックするかcanonicalで正規化する
- サーバー応答速度を改善する: サーバーレスポンスが遅いとクローラーは控えめにクロールする。TTFB（Time To First Byte）を200ms以下に抑えることを目標にする
- ソフト404を修正する: 存在しないページで200ステータスを返す「ソフト404」はクロールバジェットの浪費につながる。適切に404または410ステータスを返す
- リダイレクトチェーンを短縮する: リダイレクトが3回以上連鎖している場合、最終URLへの直接リダイレクトに修正する
- 不要なリソースのクロールを制限する: CSSやJSファイルなど、レンダリングに必要なリソースはブロックしないが、トラッキングスクリプトなどは必要に応じて制限する
Google Search Consoleの「クロールの統計情報」レポートで、クロール頻度やクロール時のエラーを定期的に確認しましょう。
カテゴリ2. インデクサビリティ
インデクサビリティとは、クロールされたページが正しくGoogleのインデックスに登録される度合いのことです。クローラビリティが「ページを見つけてもらう」段階だとすれば、インデクサビリティは「正しく登録してもらう」段階です。
canonicalタグ
canonicalタグ（rel=”canonical”）は、同一コンテンツまたは非常に類似したコンテンツを持つ複数のURLが存在する場合に、どのURLを正規版として扱うべきかを検索エンジンに伝えるためのHTMLタグです。
Before（canonicalタグの誤使用）
<!-- ページA: https://example.com/products?color=red -->
<head>
<!-- canonicalが設定されていない -->
<title>商品一覧 - 赤</title>
</head>
<!-- ページB: https://example.com/products?color=blue -->
<head>
<!-- canonicalが自分自身を指している（重複が解消されない） -->
<link rel="canonical" href="https://example.com/products?color=blue" />
<title>商品一覧 - 青</title>
</head>After（canonicalタグの正しい設定）
<!-- ページA: https://example.com/products?color=red -->
<head>
<link rel="canonical" href="https://example.com/products" />
<title>商品一覧 - 赤</title>
</head>
<!-- ページB: https://example.com/products?color=blue -->
<head>
<link rel="canonical" href="https://example.com/products" />
<title>商品一覧 - 青</title>
</head>
<!-- 正規ページ: https://example.com/products -->
<head>
<link rel="canonical" href="https://example.com/products" />
<title>商品一覧</title>
</head>canonicalタグを設定する際の注意点は次のとおりです。
- すべてのページに自己参照canonicalを設置する（正規ページ自身にも設定する）
- canonicalURLは絶対URLで記述する（相対URLは避ける）
- HTTPSのURLを正規URLとして指定する
- canonicalとnoindexを同時に使わない（矛盾するシグナルになる）
- サイトマップに掲載するURLとcanonicalで指定するURLを一致させる
- canonicalタグはあくまで「ヒント」であり、Googleが必ず従うわけではない点を理解する
noindex/nofollowの使い分け
meta robotsタグのnoindexとnofollowは、用途が異なるにもかかわらず混同されがちなディレクティブです。
- noindex: そのページをインデックスから除外する。検索結果に表示させたくないページ（管理画面、サンキューページ、テストページなど）に使用する
- nofollow: そのページ上のリンクをたどらないようクローラーに指示する。ページ単位のmeta robotsタグで指定する場合と、個別リンクのrel属性で指定する場合がある
<!-- noindex: このページを検索結果に表示しない -->
<meta name="robots" content="noindex, follow">
<!-- nofollow: このページのリンクをたどらない -->
<meta name="robots" content="index, nofollow">
<!-- noindexかつnofollow -->
<meta name="robots" content="noindex, nofollow">
<!-- 個別リンクへのnofollow -->
<a href="https://example.com/ad" rel="nofollow">広告リンク</a>
<!-- UGCリンク（2019年以降の推奨） -->
<a href="https://user-site.com" rel="ugc">ユーザーのサイト</a>
<!-- スポンサーリンク -->
<a href="https://sponsor.com" rel="sponsored">スポンサー</a>重要なのは、「noindex, follow」と設定しても、長期間noindexのままだとGoogleは最終的にリンクもたどらなくなる可能性がある点です。noindexを設定するページは、本当にインデックス不要なページに限定しましょう。
重複コンテンツ対策
重複コンテンツは、テクニカルSEOにおいて最も多い問題の一つです。意図せず重複が発生するケースには以下があります。
- www有無・http/https: https://example.com と https://www.example.com が別URLとして存在する
- 末尾スラッシュ: /page と /page/ の両方がアクセス可能
- パラメータ違い: ?utm_source=… 等のトラッキングパラメータ付きURL
- 大文字小文字: /Page と /page が別URLとして存在する
- ページネーション: /blog/page/1/ と /blog/ が同じコンテンツ
- 印刷用ページ: /article と /article/print が同じ内容
対策としては、以下を組み合わせます。
- 301リダイレクトで正規URLに統一する（www有無、http/https、末尾スラッシュ）
- canonicalタグで正規URLを明示する
- 不要なパラメータ付きURLをrobots.txtでブロックする
- Google Search ConsoleのURLパラメータツールでパラメータの処理方法を指定する
カテゴリ3. サイトアーキテクチャ
サイトアーキテクチャとは、サイト全体のURL構造、ページ間のリンク関係、ナビゲーション設計などを指します。適切なアーキテクチャは、ユーザーの回遊性を高めるだけでなく、クローラーの効率的な巡回とリンクジュース（ページランク）の適切な分配にも貢献します。
URL設計
SEOに適したURL設計の原則は次のとおりです。
Before（問題のあるURL設計）
https://example.com/page?id=12345&cat=3
https://example.com/2024/01/15/post-title-very-long-url-with-many-words
https://example.com/カテゴリ/記事名
https://example.com/Page/SubPage/DETAILAfter（推奨されるURL設計）
https://example.com/blog/technical-seo/
https://example.com/service/web-consulting/
https://example.com/case-study/company-a/
https://example.com/products/seo-tool/URL設計のベストプラクティスは以下です。
- 英数字の小文字とハイフン（-）で構成する（アンダースコアは非推奨）
- ディレクトリ構造でカテゴリ階層を表現する
- 短く、ページ内容が推測できるURLにする
- 日本語URLは避ける（エンコード時に長くなりシェアしにくい）
- パラメータではなくパス形式のURLを使う（動的URLよりも静的URLが望ましい）
- 階層は3階層以内が理想（トップ → カテゴリ → 詳細）
SEOに強いコーディングの観点からURL設計を深掘りしたい方は「SEOに強いコーディング」もご覧ください。
内部リンク設計
内部リンクはSEOにおいて極めて重要な要素です。適切な内部リンク設計により、クローラーのページ発見を促進し、ページ間の関連性をGoogleに伝え、リンクジュースを戦略的に分配できます。
内部リンク設計の基本ルールは以下のとおりです。
- トピッククラスター構造を意識する: ピラーページ（まとめ記事）からクラスター記事（個別記事）へ相互にリンクする
- アンカーテキストを最適化する: 「こちら」「詳しくはこちら」ではなく、リンク先の内容がわかるキーワードを含むアンカーテキストにする
- 重要なページへのリンク数を増やす: コンバージョンに直結するページや上位表示させたいページへの内部リンクを意図的に増やす
- 孤立ページを作らない: どこからもリンクされていないページ（オーファンページ）はクローラーに発見されにくい
- リンク切れを定期的にチェックする: 404を返す内部リンクはクロールバジェットの浪費とユーザー体験の悪化を招く
内部リンク戦略の詳細は「内部リンク戦略」を参照してください。
パンくずリスト
パンくずリスト（Breadcrumb）は、ユーザーに現在地を示すナビゲーション要素であると同時に、サイト構造をGoogleに伝える重要なテクニカルSEO要素です。
パンくずリストのHTML + 構造化データ実装例
<nav aria-label="パンくずリスト">
<ol itemscope itemtype="https://schema.org/BreadcrumbList">
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/">
<span itemprop="name">ホーム</span>
</a>
<meta itemprop="position" content="1" />
</li>
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/blog/">
<span itemprop="name">ブログ</span>
</a>
<meta itemprop="position" content="2" />
</li>
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<span itemprop="name">テクニカルSEO完全ガイド</span>
<meta itemprop="position" content="3" />
</li>
</ol>
</nav>パンくずリストは構造化データ（BreadcrumbList）を合わせて実装することで、検索結果にパンくずが表示される可能性が高まります。
カテゴリ4. ページエクスペリエンス
ページエクスペリエンスは、ユーザーがページを利用する際の快適さを評価する指標群です。Googleはランキングシグナルとしてページエクスペリエンスを考慮しており、特にCore Web Vitalsが重要な役割を果たしています。
Core Web Vitals（LCP / INP / CLS）
Core Web Vitalsは、Googleが定義するページ体験の中核指標です。2024年3月にFID（First Input Delay）がINP（Interaction to Next Paint）に正式に置き換えられました。2026年現在の3つの指標は以下のとおりです。
| 指標 | 正式名称 | 測定対象 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大コンテンツ要素の描画時間 | 2.5秒以下 | 2.5〜4.0秒 | 4.0秒超 |
| INP | Interaction to Next Paint | ユーザー操作から次の描画までの応答時間 | 200ms以下 | 200〜500ms | 500ms超 |
| CLS | Cumulative Layout Shift | 視覚的な安定性（レイアウトのずれ） | 0.1以下 | 0.1〜0.25 | 0.25超 |
各指標の改善方法を具体的に見ていきましょう。
LCPの改善
LCPが遅い主な原因と対策は以下のとおりです。
- サーバー応答時間の短縮: CDNの導入、サーバーサイドキャッシュの活用、TTFBの改善
- 画像の最適化: 次世代フォーマット（WebP、AVIF）の使用、適切なサイズへのリサイズ、lazy loadの制御
- レンダリングブロックリソースの排除: クリティカルCSSのインライン化、非同期JSの読み込み
Before（LCPが遅い画像実装）
<!-- ファーストビューの画像にlazy loadを設定してしまっている -->
<img src="hero-image.jpg" loading="lazy" alt="ヒーロー画像">
<!-- 画像サイズが未指定 -->
<img src="large-photo.png" alt="写真">After（LCP最適化された画像実装）
<!-- ファーストビューの画像はeagerロード + fetchpriority="high" -->
<img src="hero-image.webp"
srcset="hero-image-480.webp 480w,
hero-image-800.webp 800w,
hero-image-1200.webp 1200w"
sizes="(max-width: 600px) 480px,
(max-width: 1024px) 800px,
1200px"
width="1200" height="630"
alt="テクニカルSEOの全体像"
loading="eager"
fetchpriority="high"
decoding="async">
<!-- ファーストビュー外の画像はlazy load -->
<img src="content-image.webp"
width="800" height="450"
alt="コンテンツ画像"
loading="lazy"
decoding="async">INPの改善
INPはユーザーのインタラクション（クリック、タップ、キーボード操作）に対するページの応答速度を測定します。改善のポイントは以下です。
- メインスレッドをブロックする長時間タスク（Long Tasks）を分割する
- 不要なJavaScriptを削除または遅延読み込みにする
- イベントハンドラの処理を軽量化する
- Web Workerを活用して重い処理をオフロードする
- requestAnimationFrameやrequestIdleCallbackで処理タイミングを最適化する
CLSの改善
CLSはページの視覚的安定性を測る指標です。ユーザーが操作しようとした瞬間に広告やバナーが挿入されてレイアウトがずれる、といった体験を防ぐことが目的です。
- 画像・動画・iframe要素には必ずwidth/height属性を指定する
- Webフォントの読み込みにはfont-display: swapまたはfont-display: optionalを使用する
- 動的に挿入されるコンテンツ（広告、バナー、通知バー）のスペースを事前に確保する
- CSS aspect-ratioプロパティを活用してアスペクト比を維持する
Core Web Vitalsの詳細な測定と改善方法については、web.devの公式ドキュメントやPageSpeed Insightsを活用してください。
HTTPS対応
HTTPS（SSL/TLS暗号化通信）は、2014年からGoogleのランキングシグナルとして使用されています。2026年現在、HTTPSは「あれば有利」ではなく「なければ不利」な必須要件です。
HTTPS対応のチェックポイントは以下です。
- すべてのページがHTTPSで配信されていること
- HTTPからHTTPSへの301リダイレクトが設定されていること
- SSL証明書が有効期限内であること（自動更新のLet’s Encryptが推奨）
- Mixed Content（HTTPSページ内のHTTPリソース読み込み）がないこと
- HSTS（HTTP Strict Transport Security）ヘッダーが設定されていること
- TLS 1.2以上を使用していること（TLS 1.0/1.1は非推奨）
HSTSヘッダーの設定例（Nginx）
# nginx.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;モバイルフレンドリー
Googleは2021年にモバイルファーストインデックス（MFI）への完全移行を完了しました。つまり、Googlebotは基本的にモバイル版のページを見てインデックスと評価を行います。
モバイルフレンドリーのチェックポイントは以下です。
- レスポンシブWebデザインを採用する（Google推奨）
- viewport meta タグを正しく設定する
- タッチターゲット（ボタンやリンク）のサイズは48px以上にする
- テキストサイズはピンチズームなしで読めるサイズ（最低16px）にする
- モバイル版とデスクトップ版でコンテンツに差異がないこと
- インタースティシャル広告でコンテンツを覆わないこと
viewport meta タグの正しい設定
<meta name="viewport" content="width=device-width, initial-scale=1">カテゴリ5. 構造化データ
構造化データとは、ページのコンテンツの意味を検索エンジンに明示的に伝えるためのマークアップです。Schema.orgの語彙を使い、JSON-LD形式で記述するのがGoogleの推奨方式です。
構造化データを正しく実装することで、検索結果にリッチリザルト（リッチスニペット）が表示される可能性が高まり、クリック率の向上が期待できます。
主要な構造化データタイプ
- Article: ブログ記事、ニュース記事
- BreadcrumbList: パンくずリスト
- FAQPage: よくある質問
- HowTo: 手順ガイド
- LocalBusiness: 地域ビジネス情報
- Product: 商品情報（価格、レビュー等）
- Organization: 組織情報
- VideoObject: 動画コンテンツ
- WebSite: サイトリンク検索ボックス
Before（構造化データなし）
<article>
<h1>テクニカルSEO完全ガイド</h1>
<p>投稿日: 2026年3月15日</p>
<p>著者: SEO太郎</p>
<div>本文...</div>
</article>After（JSON-LDで構造化データを実装）
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "テクニカルSEO完全ガイド｜チェックリスト60項目付き",
"description": "テクニカルSEOの全体像をチェックリスト60項目付きで解説。",
"image": "https://example.com/images/technical-seo-guide.webp",
"author": {
"@type": "Person",
"name": "SEO太郎",
"url": "https://example.com/author/seo-taro/"
},
"publisher": {
"@type": "Organization",
"name": "Example Inc.",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"datePublished": "2026-03-15",
"dateModified": "2026-03-15",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/blog/technical-seo/"
}
}
</script>構造化データ実装時の注意点は以下です。
- JSON-LD形式を使用する（Microdataよりも推奨）
- ページに実際に表示されている情報のみをマークアップする（隠しコンテンツのマークアップはスパム扱いされる可能性がある）
- Googleのリッチリザルトテストで実装を検証する
- Search Consoleの「拡張」レポートでエラーや警告を監視する
構造化データの詳しい実装方法は「構造化データマークアップ」も参考にしてください。
カテゴリ6. 国際化・多言語対応
複数の言語・地域に向けてコンテンツを提供しているサイトでは、hreflangタグを使って言語・地域ごとのページの対応関係をGoogleに伝える必要があります。
hreflangタグの実装例
<!-- 日本語ページ -->
<link rel="alternate" hreflang="ja" href="https://example.com/ja/technical-seo/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/technical-seo/" />
<link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh/technical-seo/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/technical-seo/" />国際化SEOのポイントは以下です。
- hreflangは双方向で設定する（日本語ページから英語ページへ、英語ページから日本語ページへの両方）
- x-defaultで言語が一致しない場合のデフォルトページを指定する
- URL構造は、サブディレクトリ（/ja/、/en/）方式がGoogle推奨
- 自動翻訳のみのページは品質が低いと見なされる可能性があるため、ネイティブチェックを行う
- 各言語ページにcanonicalタグを自己参照で設定する
- hreflangタグはHTMLのheadセクション、HTTPヘッダー、またはサイトマップのいずれかで指定できる
日本語サイトのみを運営している場合はhreflangの設定は不要ですが、将来的な多言語展開を見据えてURL設計の段階で/ja/などの言語プレフィックスを検討しておくと、後の移行がスムーズになります。
テクニカルSEOチェックリスト60項目
ここまで解説した6大カテゴリの内容を、実務で使えるチェックリスト形式にまとめました。サイトの技術的な健全性を評価する際に活用してください。Screaming FrogやAhrefs Site Auditと併用すると効率的です。
| No. | カテゴリ | チェック項目 | 優先度 |
|---|---|---|---|
| 1 | クローラビリティ | robots.txtが正しく設定され、重要なページをブロックしていない | 高 |
| 2 | クローラビリティ | robots.txtにSitemapディレクティブが記述されている | 高 |
| 3 | クローラビリティ | XMLサイトマップが作成され、Search Consoleに送信されている | 高 |
| 4 | クローラビリティ | サイトマップに200ステータスのページのみが含まれている | 高 |
| 5 | クローラビリティ | サイトマップのlastmodが正確な更新日を反映している | 中 |
| 6 | クローラビリティ | 大規模サイトの場合、サイトマップインデックスで分割している | 中 |
| 7 | クローラビリティ | ソフト404エラーが発生していない | 高 |
| 8 | クローラビリティ | リダイレクトチェーンが3回以上連鎖していない | 中 |
| 9 | クローラビリティ | リダイレクトループが存在しない | 高 |
| 10 | クローラビリティ | サーバーの応答速度（TTFB）が200ms以下である | 高 |
| 11 | クローラビリティ | 5xx系サーバーエラーが発生していない | 高 |
| 12 | クローラビリティ | Search Consoleの「クロールの統計情報」でエラーが出ていない | 中 |
| 13 | インデクサビリティ | すべてのインデックス対象ページにcanonicalタグが設定されている | 高 |
| 14 | インデクサビリティ | canonicalタグのURLが絶対パスで記述されている | 高 |
| 15 | インデクサビリティ | canonicalタグとサイトマップのURLが一致している | 高 |
| 16 | インデクサビリティ | canonicalタグとnoindexが同一ページで併用されていない | 高 |
| 17 | インデクサビリティ | noindexが必要なページに正しく設定されている | 高 |
| 18 | インデクサビリティ | 重要なページにnoindexが誤って設定されていない | 高 |
| 19 | インデクサビリティ | www有無・http/httpsの正規化が301リダイレクトで行われている | 高 |
| 20 | インデクサビリティ | 末尾スラッシュの有無が統一されている | 中 |
| 21 | インデクサビリティ | パラメータ付きURLの重複対策がされている | 中 |
| 22 | インデクサビリティ | ページネーションが適切に処理されている | 中 |
| 23 | インデクサビリティ | Search Consoleの「ページのインデックス登録」で除外理由を確認している | 高 |
| 24 | インデクサビリティ | meta robotsタグとX-Robots-Tagヘッダーが矛盾していない | 中 |
| 25 | サイト構造 | URLが英数字小文字・ハイフンで構成されている | 中 |
| 26 | サイト構造 | URL階層が3階層以内に収まっている | 中 |
| 27 | サイト構造 | URLからページ内容が推測できる命名になっている | 低 |
| 28 | サイト構造 | トップページから3クリック以内で全ページに到達できる | 中 |
| 29 | サイト構造 | 孤立ページ（オーファンページ）が存在しない | 高 |
| 30 | サイト構造 | 内部リンク切れ（404リンク）がない | 高 |
| 31 | サイト構造 | アンカーテキストがリンク先の内容を適切に説明している | 中 |
| 32 | サイト構造 | パンくずリストが全ページに実装されている | 中 |
| 33 | サイト構造 | パンくずリストに構造化データ（BreadcrumbList）が実装されている | 中 |
| 34 | サイト構造 | HTMLサイトマップ（ユーザー向け）が用意されている | 低 |
| 35 | サイト構造 | グローバルナビゲーションが全ページで一貫している | 中 |
| 36 | サイト構造 | 重要ページへの内部リンク数が十分に確保されている | 高 |
| 37 | ページエクスペリエンス | LCPが2.5秒以下である（モバイル・デスクトップ両方） | 高 |
| 38 | ページエクスペリエンス | INPが200ms以下である | 高 |
| 39 | ページエクスペリエンス | CLSが0.1以下である | 高 |
| 40 | ページエクスペリエンス | 画像にwidth/height属性が指定されている | 高 |
| 41 | ページエクスペリエンス | ファーストビューの画像にloading=”lazy”を使っていない | 高 |
| 42 | ページエクスペリエンス | 画像が次世代フォーマット（WebP/AVIF）で配信されている | 中 |
| 43 | ページエクスペリエンス | CSSのクリティカルパスが最適化されている | 中 |
| 44 | ページエクスペリエンス | JavaScriptがレンダリングをブロックしていない | 高 |
| 45 | ページエクスペリエンス | 全ページがHTTPSで配信されている | 高 |
| 46 | ページエクスペリエンス | HTTPからHTTPSへの301リダイレクトが設定されている | 高 |
| 47 | ページエクスペリエンス | SSL証明書が有効期限内である | 高 |
| 48 | ページエクスペリエンス | Mixed Contentが存在しない | 高 |
| 49 | ページエクスペリエンス | HSTSヘッダーが設定されている | 中 |
| 50 | ページエクスペリエンス | viewportメタタグが正しく設定されている | 高 |
| 51 | ページエクスペリエンス | タッチターゲットが48px以上のサイズである | 中 |
| 52 | ページエクスペリエンス | テキストサイズが16px以上で読みやすい | 中 |
| 53 | ページエクスペリエンス | 煩わしいインタースティシャル広告がない | 中 |
| 54 | 構造化データ | 主要ページにJSON-LD形式の構造化データが実装されている | 中 |
| 55 | 構造化データ | リッチリザルトテストでエラーが出ていない | 高 |
| 56 | 構造化データ | 構造化データの内容がページの実際のコンテンツと一致している | 高 |
| 57 | 構造化データ | Search Consoleの「拡張」レポートでエラーがない | 中 |
| 58 | 国際化 | 多言語サイトの場合、hreflangタグが双方向で設定されている | 高 |
| 59 | 国際化 | x-defaultが設定されている | 中 |
| 60 | 国際化 | 言語別ページのcanonicalタグが自己参照になっている | 高 |
このチェックリストは定期的（月1回程度）に確認することをおすすめします。サイトの更新やリニューアルのタイミングでは必ず全項目を見直しましょう。
テクニカルSEOの実施手順 — 何から始めるか
テクニカルSEOの施策は多岐にわたるため、「何から手をつければいいかわからない」という声をよく聞きます。ここでは、優先度に基づいた実施手順を示します。
ステップ1: 現状の技術的課題を把握する（1〜2週間）
- Google Search Consoleに登録し、「ページのインデックス登録」レポートでインデックスの問題を確認する
- Screaming Frogでサイト全体をクロールし、エラー・警告を一覧化する
- PageSpeed Insightsで主要ページのCore Web Vitalsを測定する
- 上記チェックリスト60項目で現状をスコアリングする
ステップ2: クリティカルな問題を修正する（2〜4週間）
まずは検索パフォーマンスに致命的な影響を与える問題から対処します。
- robots.txtの誤設定修正 — 重要なページがブロックされていないか確認・修正
- noindexの誤設定修正 — インデックスされるべきページにnoindexが付いていないか確認
- 5xx/4xxエラーの修正 — サーバーエラーやリンク切れを修正
- HTTPS化 — まだHTTPのページがあれば対応
- 重複コンテンツの正規化 — canonicalタグと301リダイレクトの設定
ステップ3: 基盤を整備する（1〜2か月）
- XMLサイトマップの整備とSearch Consoleへの送信
- URL構造の見直し（必要であれば301リダイレクト付きでURL変更）
- 内部リンク構造の最適化
- パンくずリストの実装
- viewportメタタグの確認
ステップ4: パフォーマンスを最適化する（2〜3か月）
- Core Web Vitalsの改善（LCP → INP → CLSの優先順で対応）
- 画像の最適化（WebP/AVIF変換、srcset対応、lazy load制御）
- CSS/JavaScriptの最適化（不要コードの削除、非同期読み込み）
- サーバーサイドの最適化（キャッシュ、CDN導入）
ステップ5: 付加価値を追加する（継続的）
- 構造化データの実装（Article、BreadcrumbList、FAQPageなど）
- 多言語対応が必要な場合はhreflangタグの設定
- 新機能やGoogleの仕様変更への対応
- 定期的な技術監査（月1回のチェックリスト確認）
テクニカルSEOに使える主要ツール
効率的にテクニカルSEOを進めるために、以下のツールを活用しましょう。
- Google Search Console — インデックス状況、クロールエラー、Core Web Vitalsの確認。無料で最も重要なツール
- PageSpeed Insights — ページ速度とCore Web Vitalsの測定・改善提案
- Screaming Frog SEO Spider — サイト全体のクロールと技術的問題の一括検出。500URLまで無料
- Ahrefs Site Audit — 大規模サイトの技術監査。クロールとレポート生成の自動化が強み
- Chrome DevTools / Lighthouse — ブラウザ上でのリアルタイムデバッグとパフォーマンス計測
これらのツールを定期的に使い、PDCAサイクルを回すことがテクニカルSEOの継続的な改善には欠かせません。
まとめ
テクニカルSEOは、検索エンジン最適化の「土台」となる技術的な取り組みです。本記事で解説した6大カテゴリを改めて整理します。
- クローラビリティ: robots.txt、XMLサイトマップ、クロールバジェットの最適化で、検索エンジンがページを確実に発見・取得できるようにする
- インデクサビリティ: canonicalタグ、noindex/nofollow、重複コンテンツ対策で、正しいページが正しくインデックスされるようにする
- サイトアーキテクチャ: URL設計、内部リンク、パンくずリストでサイト構造を論理的に整理し、リンクジュースを適切に配分する
- ページエクスペリエンス: Core Web Vitals（LCP・INP・CLS）、HTTPS、モバイル対応でユーザーに快適な体験を提供する
- 構造化データ: JSON-LDでページの意味を明示し、リッチリザルト獲得の可能性を高める
- 国際化・多言語対応: hreflangタグで言語・地域ごとに適切なページを配信する
テクニカルSEOは一度設定すれば終わりではなく、サイトの成長やGoogleのアルゴリズム更新に合わせて継続的に監視・改善していく必要があります。特に2025年以降はAI Overviewの普及により、構造化データの重要性がさらに増しています。
まずは本記事のチェックリスト60項目で自社サイトの現状を把握し、優先度の高い項目から順に対策を進めていきましょう。基礎工事がしっかりしていれば、コンテンツSEOや外部SEOの効果も最大限に発揮されます。
テクニカルSEOの基本をさらに深く学びたい方は、教材 第6章（内部対策の基礎）と第7章（テクニカルSEO実践）もあわせてご活用ください。また、テクニカルSEOの全体像をGoogleの公式視点から確認するには、Google検索セントラルのSEOスターターガイドが最良のリファレンスです。
