テクニカルSEO完全ガイド｜チェックリスト60項目【2026年最新】

テクニカルSEOとは？ — コンテンツSEO・外部SEOとの違い

SEO対策は大きく3つの領域に分けられます。テクニカルSEO、コンテンツSEO、外部SEO（オフページSEO）です。それぞれの役割と対象範囲を整理しましょう。

SEO3領域の比較

項目	テクニカルSEO	コンテンツSEO	外部SEO
目的	検索エンジンがサイトを正しく理解・評価できるようにする	ユーザーの検索意図に応える高品質なコンテンツを提供する	外部からの信頼性シグナル（被リンク等）を獲得する
主な施策	クロール最適化、インデックス制御、サイト速度改善、構造化データ実装	キーワード調査、記事作成、E-E-A-T強化、コンテンツリライト	被リンク獲得、サイテーション構築、SNS拡散、PR活動
対象	サイトのインフラ・コード・設定ファイル	ページ上のテキスト・画像・動画	外部サイト・メディア・SNS
担当者	エンジニア・Web制作者・SEO担当者	ライター・編集者・マーケター	PR担当・マーケター・広報
効果の特性	土台整備。直接的な順位上昇よりも「マイナス要因の排除」が中心	検索意図への合致度が高ければ直接的に順位向上	ドメインオーソリティの向上で間接的に順位向上
比喩	建物の基礎工事	建物の内装・設備	建物の評判・口コミ

テクニカルSEOは「建物の基礎工事」にあたります。基礎が傾いていれば、どんなに美しい内装（コンテンツ）を施しても建物は長持ちしません。同様に、テクニカルSEOの不備があると、コンテンツの質が高くても検索エンジンからの評価を十分に得られないのです。

テクニカルSEOはSEO内部対策の一部でもあります。内部対策の全体像から押さえたい方は「SEO内部対策の完全ガイド」も合わせてご覧ください。本記事ではこの先、実務で手を動かすための具体策をカテゴリごとに深掘りしていきます。

テクニカルSEOが重要な理由 — 土台がなければコンテンツも活きない

テクニカルSEOが重要である理由は、以下の4点に集約されます。

1. クロールされなければ検索結果に表示されない

Googleのクローラー（Googlebot）がページを発見し、コンテンツを読み取れなければ、そのページはインデックスされず、検索結果に一切表示されません。robots.txtの誤設定やサーバーエラーが原因で、せっかく作ったページがクロールすらされていないケースは実務で頻繁に見られます。

2. インデックス品質が検索順位に直結する

重複コンテンツやcanonicalタグの誤設定があると、Googleはどのページを正規ページとして扱うべきか混乱します。その結果、本来評価されるべきページの順位が下がったり、クロールバジェットが無駄に消費されたりします。

3. ページエクスペリエンスがランキング要因になっている

2021年のページエクスペリエンスアップデートに始まり、GoogleはCore Web Vitals（LCP・INP・CLS）をランキングシグナルとして使用しています。2024年3月にはFID（First Input Delay）が現行指標のINP（Interaction to Next Paint）へ正式に置き換えられ、2026年現在もこの3指標がユーザー体験評価の中核を担っています。ページの表示速度やインタラクティブ性の改善は、テクニカルSEOの重要な領域です。

4. AI検索の時代にも技術基盤は前提になる

2025年以降、Google検索ではAI Overviews（AIによる概要）やAI Modeが広く展開され、AIが生成する要約が検索結果の上部に表示される場面が増えました。AIに引用・参照されるためには、まずGooglebotがコンテンツを正確にクロール・インデックスしていることが大前提です。構造化データによる意味づけも、AIによる情報抽出の精度を高めます。特別なAI向けの小細工よりも、確実にクロール・インデックスされる技術基盤の整備こそが土台であり続けています。

テクニカルSEOの6大カテゴリ（全体俯瞰）

テクニカル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

それでは、各カテゴリの具体的な施策をコード例を交えながら見ていきましょう。

カテゴリ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を一覧として伝えるファイルです。特に大規模サイトや新規サイトでは、内部リンクだけではクローラーが全ページを発見できない場合があるため、サイトマップの役割は大きくなります。サイトマップの種類や役割を基礎から確認したい場合は「サイトマップとは？XMLとHTMLの違い・作成方法」も参考にしてください。

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>
  </url>
  <url>
    <loc>https://example.com/service/</loc>
    <lastmod>2026-02-20</lastmod>
  </url>
  <url>
    <loc>https://example.com/technical-seo/</loc>
    <lastmod>2026-03-15</lastmod>
  </url>
</urlset>

サイトマップ作成のルールは次のとおりです。

• 200ステータスを返すページのみ掲載する（404、301、noindexページは含めない）
• canonicalタグで指定した正規URLのみ掲載する
• lastmodは実際にコンテンツが更新された日付を正確に記載する（正確に運用できないなら省く）
• 1つのサイトマップファイルに含めるURLは50,000件以下、ファイルサイズは50MB以下にする
• 大規模サイトではサイトマップインデックスファイルを使って分割する
• Google Search Consoleからサイトマップを送信し、処理状況を確認する

lastmodの扱いには注意が必要です。GoogleのGary Illyes氏は2026年7月、lastmod（最終更新日）が不正確なくらいなら「いっそ書かない方がよい」との見解を示しました。lastmodは順位を動かすボタンではなく、あくまでクロールの効率化を助ける手がかりです。CMSの都合で全ページのlastmodが毎日「今日」に書き換わるような運用は、かえってGoogleに信頼されず、シグナルとしての価値を下げます。詳しくは「XMLサイトマップのlastmodは不正確なら省いてよい」で解説しています。上のAfter例で意図的にchangefreqとpriorityを外しているのも、Googleがこれらをほとんど参照しないためです。

クロールバジェットの最適化

クロールバジェットとは、Googlebotが一定期間内にサイトに対して行うクロールの上限のことです。小規模サイト（数百ページ程度）ではあまり意識する必要はありませんが、数万〜数百万ページ規模のサイトではクロールバジェットの最適化が重要になります。

クロールバジェットを無駄にしないための施策は以下のとおりです。

• 不要なURLを排除する: パラメータ違いの重複ページ、検索結果ページの無限ページネーション、セッションID付きURLなどをrobots.txtでブロックするかcanonicalで正規化する
• サーバー応答速度を改善する: サーバーレスポンスが遅いとクローラーは控えめにクロールする。応答速度の指標であるTTFB（Time To First Byte）は0.8秒以内が目安とされる
• ソフト404を修正する: 存在しないページで200ステータスを返す「ソフト404」はクロールバジェットの浪費につながる。適切に404または410ステータスを返す
• リダイレクトチェーンを短縮する: リダイレクトが3回以上連鎖している場合、最終URLへの直接リダイレクトに修正する
• 不要なリソースのクロールを制限する: CSSやJSファイルなどレンダリングに必要なリソースはブロックしないが、トラッキングスクリプトなどは必要に応じて制限する

サーバー応答速度は実際に効きます。当サイトの実測（2026年7月計測）では、WordPress移行後のTTFBは平均0.19秒でした（curlによる3回計測）。目安の0.8秒を十分に下回っており、この水準ならクロール頻度が応答速度で頭打ちになることはありません。計測の手順と結果は「SEOに強いコーディングの実測レポート」で公開しています。Google Search Consoleの「クロールの統計情報」レポートでも、クロール頻度やクロール時のエラーを定期的に確認しましょう。

Googlebotの挙動を理解する — 2MBの取得上限とクローラー検証

クロールを設計するうえで、Googlebotがページの何バイトまでを処理するのかを知っておくと役立ちます。Googleは2026年3月、Googlebotのクロールと取得（フェッチ）の仕組みを公式ブログで解説し、HTMLの取得上限がHTTPヘッダー込みで2MBであることを明らかにしました。2MBを超えた部分はインデックス処理やレンダリングに渡されず、Googleからは見えなくなります。

実務上の対策は明快です。title・meta・canonical・構造化データといった重要なタグはHTMLの上部に置き、重いCSSやJavaScriptは外部ファイルに切り出して生HTMLを軽く保ちます。ページビルダーや過剰なインラインコードで生HTMLが肥大化していないかを確認しましょう。発表内容の全体は「Googlebotの「2MBの壁」を解説したニュース」にまとめています。

もう一点、クローラーの正規性検証に関わる変更もありました。Googleは2026年3月、クローラーのIPレンジを記載したJSONファイルの公開先を /search/apis/ipranges/ から /crawling/ipranges/ へ移設しています。旧パスは当面併存しますが6か月以内に廃止・リダイレクトされる予定です。アクセス制御やボット検知でこのファイルを自動参照している場合は参照先の更新が必要です。詳細は「GoogleクローラーのIPレンジ一覧が新URLへ移動」を参照してください。

カテゴリ2. インデクサビリティ

インデクサビリティとは、クロールされたページが正しくGoogleのインデックスに登録される度合いのことです。クローラビリティが「ページを見つけてもらう」段階だとすれば、インデクサビリティは「正しく登録してもらう」段階です。

canonicalタグ

canonicalタグ（rel=”canonical”）は、同一コンテンツまたは非常に類似したコンテンツを持つ複数のURLが存在する場合に、どのURLを正規版として扱うべきかを検索エンジンに伝えるためのHTMLタグです。設定パターンの判断基準は「canonicalタグとは？URL正規化の正しい設定方法」で詳しく扱っています。

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を設置する（正規ページ自身にも設定する）
• canonicalのURLは絶対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として存在する
• ページネーション: /category/technical-seo/page/2/ と /category/technical-seo/ の関係が整理されていない
• 印刷用ページ: /article と /article/print が同じ内容

対策としては、以下を組み合わせます。

1. 301リダイレクトで正規URLに統一する（www有無、http/https、末尾スラッシュ）。301と302の使い分けは「リダイレクトとは？301・302の違いから設定方法」で確認できます
2. canonicalタグで正規URLを明示する
3. 不要なパラメータ付きURLをrobots.txtでブロックする
4. ページネーションは各ページを自己参照canonicalにし、無理に1ページ目へ集約しない

URL移行時の重複対策は、当サイト自身の移行で検証済みです。scale-basics.comは2026年7月にNext.js（SSG）からWordPressへ基盤を移行し、記事URLを旧構成の「/blog/記事名/」から「/記事名/」へ変更しました。このとき全記事に301リダイレクトを設定し、canonicalを新URLへ統一した結果、インデックス上の問題は発生していません。URL構造を変える場面では、301リダイレクトとcanonicalを併用して「正規のURLはどれか」を一貫して伝えることが実務上の要点です。移行の詳細は「SEOに強いコーディング」に記録しています。

「クロール済み-未インデックス」を品質のサインとして読む

Search Consoleの「ページのインデックス登録」レポートで、「クロール済み – 現在インデックス未登録」というステータスが多発することがあります。GoogleのJohn Mueller氏は2026年7月、このステータスが「時として」サイト品質の問題のサインになり得ると説明しました。Googleが全体的な品質に強い懸念を持つと、そのサイトに割く時間を減らし、クロールもインデックスも絞る挙動をとるためです。

ここで重要なのは、これを個々のURLの技術的不具合として直そうとしないことです。robots.txtやサイトマップといった技術要因がないことを確認したうえで、多くのページで発生しているなら、一歩下がってサイト全体の価値・独自性を見直す合図と捉えます。AI生成コンテンツについてもMueller氏は「使ったこと自体が問題なのではなく、独自性や価値がなく誰でも書けるような内容が問題になる」と述べています。技術で解けるのはあくまで技術要因であり、その先はコンテンツの品質の話になる——この切り分けは実務で役立ちます。背景は「クロール済み-未インデックスとサイト品質・AI生成コンテンツの関係」で整理しています。

カテゴリ3. サイトアーキテクチャ

サイトアーキテクチャとは、サイト全体のURL構造、ページ間のリンク関係、ナビゲーション設計などを指します。適切なアーキテクチャは、ユーザーの回遊性を高めるだけでなく、クローラーの効率的な巡回とリンクジュース（ページランク）の適切な分配にも貢献します。

URL設計

SEOに適したURL設計の原則を、Before/Afterで確認しましょう。

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/DETAIL

After（推奨されるURL設計）

https://example.com/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階層以内が理想（トップ → カテゴリ → 詳細）

URL設計を含めたコーディング全般の考え方は「SEOに強いコーディング」で実測データとともに深掘りしています。

内部リンク設計

内部リンクはSEOにおいて極めて重要な要素です。適切な内部リンク設計により、クローラーのページ発見を促進し、ページ間の関連性をGoogleに伝え、リンクジュースを戦略的に分配できます。

内部リンク設計の基本ルールは以下のとおりです。

• トピッククラスター構造を意識する: ピラーページ（まとめ記事）からクラスター記事（個別記事）へ相互にリンクする
• アンカーテキストを最適化する: 「こちら」「詳しくはこちら」ではなく、リンク先の内容がわかるキーワードを含むアンカーテキストにする
• 重要なページへのリンク数を増やす: コンバージョンに直結するページや上位表示させたいページへの内部リンクを意図的に増やす
• 孤立ページを作らない: どこからもリンクされていないページ（オーファンページ）はクローラーに発見されにくい
• リンク切れを定期的にチェックする: 404を返す内部リンクはクロールバジェットの浪費とユーザー体験の悪化を招く

内部リンク戦略の詳細は「SEO内部リンク戦略の設計と実装」を参照してください。

パンくずリスト

パンくずリスト（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="/category/technical-seo/">
        <span itemprop="name">テクニカルSEO</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）へ正式に置き換えられ、現在FIDは評価に使われていません。2026年現在の3つの指標は以下のとおりです。

Core Web Vitals 2026年版指標一覧

指標	正式名称	測定対象	良好	改善が必要	不良
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">

LCPの改善は体感だけでなく数字にも表れます。当サイトでは旧構成時に、クリティカルCSSのインライン化などの施策でLCPを3.2秒から1.8秒へ短縮した実績があります（当サイトの実測、2026年7月計測）。HTMLとリソース読み込みを整理するだけでも指標は大きく動きます。改善手順の詳細は前掲の「SEOに強いコーディング」にまとめています。

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/technical-seo/"
  }
}
</script>

構造化データ実装時の注意点は以下です。

• JSON-LD形式を使用する（Microdataよりも推奨）
• ページに実際に表示されている情報のみをマークアップする（隠しコンテンツのマークアップはスパム扱いされる可能性がある）
• Googleのリッチリザルトテストで実装を検証する
• Search Consoleの「拡張」レポートでエラーや警告を監視する

構造化データの詳しい実装方法は「構造化データマークアップ完全ガイド」も参考にしてください。

カテゴリ6. 国際化・多言語対応

複数の言語・地域に向けてコンテンツを提供しているサイトでは、hreflangタグを使って言語・地域ごとのページの対応関係をGoogleに伝える必要があります。

hreflangタグの実装例

<!-- 各ページのhead内に、対応するすべての言語版を列挙する -->
<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と併用すると効率的です。

テクニカルSEOチェックリスト60項目

No.	カテゴリ	チェック項目	優先度
1	クローラビリティ	robots.txtが正しく設定され、重要なページをブロックしていない	高
2	クローラビリティ	robots.txtにSitemapディレクティブが記述されている	高
3	クローラビリティ	XMLサイトマップが作成され、Search Consoleに送信されている	高
4	クローラビリティ	サイトマップに200ステータスのページのみが含まれている	高
5	クローラビリティ	サイトマップのlastmodが正確な更新日を反映している（不正確なら省く）	中
6	クローラビリティ	大規模サイトの場合、サイトマップインデックスで分割している	中
7	クローラビリティ	ソフト404エラーが発生していない	高
8	クローラビリティ	リダイレクトチェーンが3回以上連鎖していない	中
9	クローラビリティ	リダイレクトループが存在しない	高
10	クローラビリティ	サーバーの応答速度（TTFB）が0.8秒以下である	高
11	クローラビリティ	5xx系サーバーエラーが発生していない	高
12	クローラビリティ	生HTMLが肥大化しておらず、重要タグが2MBの取得上限より前にある	中
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週間）

1. Google Search Consoleに登録し、「ページのインデックス登録」レポートでインデックスの問題を確認する
2. Screaming Frogでサイト全体をクロールし、エラー・警告を一覧化する
3. PageSpeed Insightsで主要ページのCore Web Vitalsを測定する
4. 上記チェックリスト60項目で現状をスコアリングする

ステップ2: クリティカルな問題を修正する（2〜4週間）

まずは検索パフォーマンスに致命的な影響を与える問題から対処します。

1. robots.txtの誤設定修正 — 重要なページがブロックされていないか確認・修正
2. noindexの誤設定修正 — インデックスされるべきページにnoindexが付いていないか確認
3. 5xx/4xxエラーの修正 — サーバーエラーやリンク切れを修正
4. HTTPS化 — まだHTTPのページがあれば対応
5. 重複コンテンツの正規化 — canonicalタグと301リダイレクトの設定

ステップ3: 基盤を整備する（1〜2か月）

1. XMLサイトマップの整備とSearch Consoleへの送信
2. URL構造の見直し（必要であれば301リダイレクト付きでURL変更）
3. 内部リンク構造の最適化
4. パンくずリストの実装
5. viewportメタタグの確認

ステップ4: パフォーマンスを最適化する（2〜3か月）

1. Core Web Vitalsの改善（LCP → INP → CLSの優先順で対応）
2. 画像の最適化（WebP/AVIF変換、srcset対応、lazy load制御）
3. CSS/JavaScriptの最適化（不要コードの削除、非同期読み込み）
4. サーバーサイドの最適化（キャッシュ、CDN導入）

ステップ5: 付加価値を追加する（継続的）

1. 構造化データの実装（Article、BreadcrumbList、FAQPageなど）
2. 多言語対応が必要な場合はhreflangタグの設定
3. 新機能やGoogleの仕様変更への対応
4. 定期的な技術監査（月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大カテゴリを改めて整理します。

1. クローラビリティ: robots.txt、XMLサイトマップ、クロールバジェットの最適化で、検索エンジンがページを確実に発見・取得できるようにする
2. インデクサビリティ: canonicalタグ、noindex/nofollow、重複コンテンツ対策で、正しいページが正しくインデックスされるようにする
3. サイトアーキテクチャ: URL設計、内部リンク、パンくずリストでサイト構造を論理的に整理し、リンクジュースを適切に配分する
4. ページエクスペリエンス: Core Web Vitals（LCP・INP・CLS）、HTTPS、モバイル対応でユーザーに快適な体験を提供する
5. 構造化データ: JSON-LDでページの意味を明示し、リッチリザルト獲得の可能性を高める
6. 国際化・多言語対応: hreflangタグで言語・地域ごとに適切なページを配信する

テクニカルSEOは一度設定すれば終わりではなく、サイトの成長やGoogleのアルゴリズム更新に合わせて継続的に監視・改善していく必要があります。2026年はGooglebotの取得上限（2MB）やlastmodの扱いなど、クロールの仕組みに関する公式解説が相次ぎました。「クロール済み-未インデックス」が品質のサインになり得るという整理も含め、技術で解ける部分と、コンテンツの品質で解くべき部分を切り分ける視点が実務では欠かせません。

まずは本記事のチェックリスト60項目で自社サイトの現状を把握し、優先度の高い項目から順に対策を進めていきましょう。基礎工事がしっかりしていれば、コンテンツSEOや外部SEOの効果も最大限に発揮されます。テクニカルSEOの全体像をGoogleの公式視点から確認するには、Google検索セントラルのSEOスターターガイドが最良のリファレンスです。

執筆根拠: 本記事は2026年7月時点の情報に基づき、Google検索セントラルの公式ドキュメント・公式ブログ（SEOスターターガイド、Googlebotのクロール仕様、クローラーIPレンジの移設告知）、Google関係者の公開発言（サイトマップlastmod、クロール済み-未インデックスとサイト品質）、およびGoogleが公式に定義するCore Web Vitalsの指標値をもとに執筆しています。当サイトの実測データ（2026年7月計測。TTFB平均0.19秒、LCP 3.2秒→1.8秒、Next.js→WordPress移行時の301リダイレクト運用。詳細はSEOに強いコーディングの実測レポート参照）を併記しています。数値は上記の出典に基づくもののみを記載し、出典不明の効果指標は使用していません。