SEO内部対策の完全ガイド｜6領域の施策とチェックリスト【2026年版】

SEO内部対策とは？ — 定義と外部対策との違い

SEO内部対策とは、Webサイトの内部要素（HTML構造、サイト設計、ページ速度など）を検索エンジンに最適化する取り組みの総称です。英語では「On-page SEO」あるいは「On-site SEO」と呼ばれ、検索エンジンがページの内容を正確に理解し、適切にインデックスできる状態をつくることが目的です。

一方、外部対策（Off-page SEO）は、他サイトからの被リンク獲得やサイテーション（言及）の増加など、自サイトの外部で行う施策を指します。外部対策は第三者の意思決定に依存するため、コントロールが難しく、効果が現れるまでに時間がかかる傾向があります。

なぜ内部対策を先に行うべきなのでしょうか。理由は単純です。いくら質の高い被リンクを獲得しても、クローラーがページを正しく巡回・理解できなければ、そのリンク価値は十分に活かされません。内部対策は、外部対策の効果を最大化するための土台でもあるのです。

Googleが公開しているSEOスターターガイドでも、まずサイトの技術的な基盤を整えることが推奨されています。以下の比較テーブルで、内部対策と外部対策の違いを整理しましょう。

SEO内部対策と外部対策の比較

比較項目	内部対策（On-page SEO）	外部対策（Off-page SEO）
コントロール性	自社で完全にコントロール可能	第三者に依存するため限定的
施策の主な対象	HTML構造、サイト設計、コンテンツ、ページ速度、モバイル対応	被リンク獲得、SNS拡散、ブランド言及（サイテーション）
効果の発現速度	クロール後すぐに反映されることが多い（数日〜数週間）	リンク構築に時間がかかり、数週間〜数ヶ月
費用	主に開発工数（内製可能）	PR活動・コンテンツマーケティング等のコスト
リスク	過度な最適化によるペナルティ（キーワードスタッフィング等）	不自然なリンク構築によるペナルティ
Googleの評価観点	クロール可能性、インデックス可能性、ユーザー体験	権威性（E-E-A-T）、信頼性のシグナル
代表的な施策	title最適化、内部リンク設計、構造化データ、CWV改善	ゲスト投稿、プレスリリース、インフルエンサー連携
優先度	最初に着手すべき（土台）	内部対策の土台ができた上で実施

このように、内部対策と外部対策は相互補完の関係にあります。しかし順序としては、まず内部対策で土台を固め、その上で外部対策に取り組むのが最も効率的です。テクニカルSEOとは何かを初心者向けに解説した記事でも触れていますが、技術基盤が整っていないサイトは、どれだけコンテンツが良くても検索エンジンに正しく評価されません。

SEO内部対策で取り組むべき6つの領域

SEO内部対策は範囲が広いため、闇雲に取り組むと優先順位を見失いがちです。ここでは内部対策を6つの領域に分類し、それぞれの概要・重要度・難易度を俯瞰します。この全体像を把握してから、各領域の詳細に進んでください。

SEO内部対策の6領域 — 全体俯瞰

領域	主な施策内容	SEOへの影響度	実装難易度	優先度
1. サイト構造	URL設計、ディレクトリ階層、パンくずリスト	★★★★★	中〜高	最優先
2. 内部リンク	リンク設計、アンカーテキスト、ピラー＆クラスター	★★★★★	中	最優先
3. メタタグ	title、meta description、canonical	★★★★☆	低	高
4. 構造化データ	JSON-LD実装、リッチリザルト対応	★★★☆☆	中	中
5. ページ速度・CWV	LCP/INP/CLS改善、画像最適化、JS削減	★★★★☆	高	高
6. モバイル・クロール	レスポンシブ対応、robots.txt、sitemap.xml	★★★★☆	低〜中	高

重要なのは、これらの領域が独立しているわけではなく、互いに影響し合っている点です。たとえばサイト構造が整理されていないと内部リンクの効果が薄れますし、構造化データを正しく実装してもページ速度が遅ければリッチリザルトの表示機会が減少します。以下では、各領域を順番に深掘りしていきます。テクニカルSEOの全体像をまとめた記事と合わせて読むと、より理解が深まるでしょう。

領域1. サイト構造の最適化

サイト構造の最適化は、SEO内部対策の中でも最も根本的な施策です。なぜなら、サイト構造はクローラーの巡回効率、リンク評価の伝達、ユーザーのナビゲーション体験のすべてに影響するからです。サイト構造が乱れた状態で他の内部対策を行っても、効果は限定的になります。

URL設計のベストプラクティス

URLは、検索エンジンとユーザーの両方にとってページ内容を推測する手がかりになります。Googleは公式に「URLにはコンテンツに関連する単語を使用することが推奨される」と述べており、意味のあるURL構造は間接的にSEOに貢献します。

では、具体的にどのようなURLが良いのでしょうか。以下のBefore/Afterを見てください。

Before（悪い例）:

# 問題のあるURL設計
https://example.com/page?id=12345&cat=3
https://example.com/2024/03/15/post-title-here-with-too-many-words-in-url
https://example.com/カテゴリ/記事タイトル
https://example.com/blog/Blog/SEO/seo-tips

After（改善例）:

# 最適化されたURL設計
https://example.com/seo-internal/
https://example.com/seo-coding/
https://example.com/seo-consulting/
https://example.com/category/seo/

改善のポイントは次の通りです。パラメータ付きURLはクローラーが同一コンテンツを複数URLとして認識するリスクがあるため、静的なURLに変換します。URLに日本語を含めるとエンコードされて可読性が下がるため、英語のスラッグを使います。階層は3〜4階層以内に抑え、URLを見ただけでサイト内の位置関係が分かる設計にします。

当サイト（scale-basics.com）は2026年7月にNext.js（SSG）で運用していた構成からWordPressへ移行しました。その際、記事URLを /blog/[slug]/ からフラットな /[slug]/ に変更し、旧URLはすべて301リダイレクトで新URLへ引き継いでいます。結果として、インデックスの欠落を起こすことなく移行を完了できました。URL変更を伴う移行では、301リダイレクトで評価を確実に引き継ぐことが重要です。リダイレクトの考え方は301・302リダイレクトの違いと設定方法の記事で詳しく解説しています。

カテゴリ構造とサイロ構造

サイロ構造とは、関連するコンテンツを同じカテゴリ（サイロ）内にまとめ、サイロ間のリンクを制限することでトピックの専門性を明確にする設計思想です。かつてはURLのディレクトリ階層（例: /category-name/article/）でサイロを表現する手法が主流でしたが、WordPressのようなCMSでは、URL自体はフラットに保ちながら、カテゴリタクソノミーでサイロを構成する方法もあります。

なぜサイロ構造が重要なのでしょうか。Googleはサイト全体のトピック的な関連性（Topical Authority）を評価の一つの観点としています。関連コンテンツが論理的にグルーピングされていると、そのトピックに対するサイトの専門性が高いと判断されやすくなります。

具体的な実装イメージを見てみましょう。以下は当サイトの実際のカテゴリ構造です。

scale-basics.com/                        # 全記事が /記事名/ 直下のフラットURL
├── カテゴリ: テクニカルSEO               # /category/technical-seo/
│   ├── /seo-internal/                    # SEO内部対策（本記事）
│   ├── /technical-seo/                   # テクニカルSEOの全体像
│   ├── /seo-internal-links/              # 内部リンク戦略
│   ├── /robots-txt/                      # robots.txt書き方
│   └── /what-is-technical-seo/           # テクニカルSEO入門
├── カテゴリ: Web制作・コーディング       # /category/web-development/
│   ├── /seo-coding/                      # SEOに強いコーディング
│   ├── /structured-data-markup/          # 構造化データ
│   └── /seo-html/                        # SEO HTMLタグ一覧
└── カテゴリ: コンテンツSEO / AI検索 / 広告・PPC / データ分析・計測 / 業界ニュース …

この構造では、URLはすべてフラットに /記事名/ という形式に統一されている一方、WordPressのカテゴリタクソノミーによってコンテンツがトピックごとにグルーピングされています。同じカテゴリ内の記事同士は積極的に内部リンクで結び、トピッククラスターを形成します。一方で、異なるカテゴリ間のリンクは、本当に関連性の高い場合のみに限定します。この「関連コンテンツをまとめ、専門性を明確にする」という考え方が、サイト全体のトピック評価を底上げする土台になります。

パンくずリストの実装

パンくずリスト（Breadcrumb）は、ユーザーにサイト内の現在位置を示すナビゲーション要素です。同時に、検索エンジンにサイトの階層構造を伝える役割も果たします。Googleはパンくずリストの構造化データをサポートしており、検索結果にパンくずが表示されると、ユーザーがページの文脈を把握しやすくなります。詳しい設置方法はパンくずリストの正しい設置方法と構造化データの記事にまとめています。

実装にあたっては、HTMLのマークアップとJSON-LDの構造化データを組み合わせるのが最善です。

Before（構造化データなし）:

<div class="breadcrumb">
  <a href="/">ホーム</a> >
  <a href="/category/technical-seo/">テクニカルSEO</a> >
  <span>SEO内部対策</span>
</div>

After（構造化データ付き）:

<nav aria-label="パンくずリスト">
  <ol class="breadcrumb" 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>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://scale-basics.com/" },
    { "@type": "ListItem", "position": 2, "name": "テクニカルSEO", "item": "https://scale-basics.com/category/technical-seo/" },
    { "@type": "ListItem", "position": 3, "name": "SEO内部対策" }
  ]
}
</script>

After版では、<nav> 要素に aria-label を付けてアクセシビリティを確保し、<ol> で順序付きリストとしてマークアップしています。さらにJSON-LDで構造化データを追加することで、Googleの検索結果にパンくずパスが表示される可能性が高まり、そのページがサイト内のどこに位置するのかが伝わりやすくなります。

領域2. 内部リンクの最適化

内部リンクは、SEO内部対策の中で最もコストパフォーマンスが高い施策の一つです。新しいコンテンツを作成する必要も、大きな技術的変更も不要で、既存ページにリンクを追加するだけで効果が得られます。にもかかわらず、多くのサイトで内部リンクは十分に最適化されていません。設計・運用の詳しいノウハウはSEO内部リンク戦略の設計と実装の記事で深掘りしています。

内部リンクの役割と設計思想

内部リンクには、3つの重要な役割があります。第一に、クローラーの巡回を助ける役割です。Googleのクローラー（Googlebot）はリンクをたどってページを発見します。内部リンクが不十分なページは、クローラーに発見されにくく、インデックスが遅れる原因になります。

第二に、リンク評価（PageRank）の分配です。あるページが外部から被リンクを獲得した場合、そのページから内部リンクで他のページに「リンクの価値」を伝達できます。重要なページに適切な内部リンクを集めることで、そのページの評価を押し上げる効果が期待できます。

第三に、ユーザー体験の向上です。適切な内部リンクは、ユーザーが関連コンテンツを自然に回遊する導線となり、サイト滞在の質を高めます。こうしたユーザー行動は、間接的にSEO評価にも影響します。

内部リンクの設計で最も重要な考え方は「ユーザーにとって本当に有益なリンクだけを設置する」ことです。検索エンジン対策のためだけに無関係なページへリンクを張ると、かえってユーザー体験を損ない、逆効果になります。

アンカーテキストの書き方

アンカーテキスト（リンクのクリック可能な文字列）は、リンク先ページの内容を検索エンジンに伝えるシグナルです。適切なアンカーテキストを使うことで、リンク先ページの評価を高める効果があります。

Before（悪い例）:

<!-- 「こちら」「ここ」などの曖昧なアンカーテキスト -->
<p>詳しくは<a href="/seo-coding/">こちら</a>をご覧ください。</p>

<!-- URLそのままのアンカーテキスト -->
<p>参考: <a href="/seo-coding/">https://example.com/seo-coding/</a></p>

<!-- 過度にキーワードを詰め込んだアンカーテキスト -->
<p><a href="/seo-coding/">SEOコーディング SEO対策 コーディング手法 SEOに強い HTML</a></p>

After（改善例）:

<!-- リンク先の内容を端的に表すアンカーテキスト -->
<p>HTMLの書き方については、<a href="/seo-coding/">SEOに強いコーディング実践ガイド</a>で詳しく解説しています。</p>

<!-- 文脈の中に自然に溶け込むアンカーテキスト -->
<p>メタタグの最適化だけでなく、<a href="/seo-html/">SEOに効果的なHTMLタグの使い方</a>を理解すると、より包括的な内部対策ができます。</p>

<!-- 関連するコンテキストを伴うアンカーテキスト -->
<p>構造化データの実装方法は<a href="/structured-data-markup/">構造化データマークアップの実装手順</a>にまとめています。</p>

改善のポイントは3つです。まず、リンク先ページの内容が推測できる具体的な文言にすること。次に、前後の文脈と自然につながるようにすること。そして、同じページへのリンクでも毎回まったく同じアンカーテキストを使わず、多少のバリエーションを持たせることです。

ただし、過度なキーワード最適化は逆効果です。Googleのジョン・ミューラー氏は「不自然なアンカーテキストの大量使用はスパムシグナルになり得る」と述べています。あくまで「ユーザーにとって分かりやすいテキスト」を基準にしましょう。

ピラー＆クラスターモデル

ピラー＆クラスターモデルとは、あるトピックに関する包括的な記事（ピラーコンテンツ）を中心に、より詳細な個別記事（クラスターコンテンツ）を周辺に配置し、相互にリンクで結ぶ構造のことです。実は、この記事自体がピラーコンテンツとして設計されています。

なぜこのモデルが有効なのでしょうか。Googleはトピック全体に対するサイトの網羅性・専門性を評価します。ピラー記事がトピックの全体像をカバーし、クラスター記事が各サブトピックを深掘りすることで、サイト全体としてそのトピックに対する高い専門性を示すことができます。

本記事（SEO内部対策）を中心としたピラー＆クラスターの具体例を示します。

【ピラーコンテンツ】
  SEO内部対策の完全ガイド（本記事）
    │
    ├── 【クラスター1】テクニカルSEOの全体像 → /technical-seo/
    │     内部対策の技術面を深掘り
    │
    ├── 【クラスター2】内部リンク戦略の詳細 → /seo-internal-links/
    │     リンク設計のノウハウを詳細解説
    │
    ├── 【クラスター3】robots.txtの書き方  → /robots-txt/
    │     クロール制御の具体的手法
    │
    ├── 【クラスター4】テクニカルSEO入門    → /what-is-technical-seo/
    │     初心者向けの導入記事
    │
    ├── 【関連記事】SEOに強いコーディング   → /seo-coding/
    ├── 【関連記事】構造化データマークアップ → /structured-data-markup/
    └── 【関連記事】SEO HTMLタグ一覧        → /seo-html/

ピラー記事からクラスター記事へは「詳しくは○○で解説」という形でリンクし、クラスター記事からピラー記事へは「SEO内部対策の全体像はこちら」という形で逆リンクを設置します。この双方向のリンク構造により、リンク評価が効率的に循環し、トピック全体の検索評価が向上しやすくなります。特にロングテールキーワードでは、クラスター記事群が個別の検索ニーズを受け止める受け皿として機能します。

領域3. メタタグの最適化

メタタグの最適化は、SEO内部対策の中で最も着手しやすい施策です。HTMLの <head> 内のタグを修正するだけで完了するため、開発リソースが限られている場合でも即座に実行できます。しかし、簡単だからこそ軽視されがちで、多くのサイトでメタタグが最適化されていないのが現実です。各タグの役割はSEO対策に必須のHTMLタグ一覧の記事でも解説しています。

titleタグ

titleタグは、SEOにおいて最も重要なHTMLタグの一つです。検索結果のタイトルリンクとして表示され、ユーザーのクリック意思決定に直接影響します。また、Googleはtitleタグの内容をページのテーマ理解に利用しています。順位が同じでも、titleの改善でクリック率が上がればトラフィックは増えるため、費用対効果の高い施策です。

Before（悪い例）:

<!-- キーワードが含まれていない -->
<title>社内マニュアル | 株式会社サンプル</title>

<!-- 長すぎる（全角35文字を大きく超える） -->
<title>SEO内部対策とは何かを初心者にもわかりやすく完全解説するための最新版総合マニュアルガイド2026年版</title>

<!-- キーワードの詰め込み -->
<title>SEO内部対策 SEO対策 内部対策 SEO内部 対策方法 SEO</title>

<!-- 全ページ同じtitle -->
<title>株式会社サンプル</title>

After（改善例）:

<!-- ターゲットKWを先頭に、全角30〜35文字前後で簡潔に -->
<title>SEO内部対策の完全ガイド｜6領域の施策とチェックリスト</title>

<!-- 別のパターン例 -->
<title>SEO内部対策とは？6領域別の施策と実装手順を解説</title>

titleタグ最適化の原則は5つあります。ターゲットキーワードをできるだけ先頭に配置すること。全角30〜35文字前後（半角60文字前後）に収めること。各ページで固有のtitleを設定すること。ユーザーの検索意図に合致する内容にすること。そしてクリックしたくなる要素（数字、具体性、ベネフィット）を含めることです。適切にtitleを設定していれば、多くの場合そのまま検索結果に使われます。

meta description

meta descriptionは、検索結果のスニペット（説明文）に使われることがあるメタタグです。直接的なランキング要因ではありませんが、クリック率に影響するため、間接的なSEO効果があります。Googleは状況に応じてmeta descriptionの内容を書き換えることがありますが、検索意図に合った説明文はそのまま採用されやすくなります。

<!-- Before: 抽象的で行動を促す要素がない -->
<meta name="description" content="SEO内部対策について解説します。" />

<!-- After: 具体的な内容と行動喚起を含む -->
<meta name="description" content="SEO内部対策を6領域に体系化して解説。サイト構造、内部リンク、メタタグ、構造化データ、ページ速度、モバイル対応まで網羅。Before/Afterのコード例とチェックリスト付きで、今日から実装できる実践マニュアルです。" />

meta descriptionの最適な文字数は、全角120〜160文字程度が目安です。モバイルでは全角70文字前後までしか表示されないため、重要な情報は前半に入れましょう。「チェックリスト付き」「コード例あり」などの具体的なベネフィットを含めると、クリック率が向上する傾向があります。

canonicalタグ

canonicalタグ（rel="canonical"）は、重複コンテンツの問題を解消するためのメタタグです。同一または類似のコンテンツが複数のURLに存在する場合に、「正規のURL」をGoogleに伝えます。設定の細かい注意点はcanonicalタグによるURL正規化の記事で詳しく解説しています。

なぜcanonicalが重要かというと、重複コンテンツが存在するとGoogleがどのURLをインデックスすべきか迷い、結果としてどのページも十分に評価されない「評価の分散」が起きるからです。ECサイトではパラメータ付きURLで同一商品が複数URLに存在することが多く、canonicalの設定は特に重要です。

<!-- 自己参照canonical（すべてのページに設定推奨） -->
<link rel="canonical" href="https://scale-basics.com/seo-internal/" />

<!-- パラメータ付きURLが存在する場合 -->
<!-- https://example.com/products/shoes?color=red -->
<!-- https://example.com/products/shoes?color=blue -->
<!-- ↓ 両方のページに以下を設定 -->
<link rel="canonical" href="https://example.com/products/shoes" />

canonicalタグの設定で注意すべき点があります。まず、canonicalは「ヒント」であり「命令」ではありません。Googleはcanonicalの指定を無視することがあります。そのため、canonicalだけに頼るのではなく、必要に応じて301リダイレクトと組み合わせるのが安全です。また、すべてのページに自己参照canonical（そのページ自身のURLを指すcanonical）を設定しておくと、パラメータが付与された場合でも正規URLが明確になります。

領域4. 構造化データの実装

構造化データとは、ページの内容を検索エンジンが機械的に理解できるようにするためのマークアップです。Schema.orgの語彙を使い、JSON-LD形式で記述するのがGoogleの推奨方式です。構造化データを正しく実装すると、検索結果にリッチリザルト（星評価、FAQ、パンくずリストなど）が表示される可能性があり、検索結果での占有面積が広がってクリックされやすくなります。

構造化データの詳細は構造化データマークアップの実装手順の記事で解説していますが、ここでは内部対策の観点から特に重要なスキーマタイプとコード例を紹介します。

主要スキーマタイプとJSON-LDコード例

まず、ほぼすべてのサイトで実装を検討したい基本的な構造化データを見ていきましょう。

1. Article（記事）スキーマ: ブログ記事やニュース記事に適用する最も基本的なスキーマです。検索結果で記事のサムネイル画像や公開日などが表示される可能性があります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO内部対策の完全ガイド｜6領域の施策とチェックリスト",
  "description": "SEO内部対策を体系的に解説。サイト構造、内部リンク、メタタグ、構造化データ、ページ速度、モバイル対応まで網羅。",
  "image": "https://scale-basics.com/images/seo-internal-og.png",
  "author": {
    "@type": "Organization",
    "name": "scale-basics.com",
    "url": "https://scale-basics.com"
  },
  "publisher": {
    "@type": "Organization",
    "name": "scale-basics.com",
    "logo": { "@type": "ImageObject", "url": "https://scale-basics.com/images/logo.png" }
  },
  "datePublished": "2026-07-23",
  "dateModified": "2026-07-23",
  "mainEntityOfPage": { "@type": "WebPage", "@id": "https://scale-basics.com/seo-internal/" }
}
</script>

2. FAQPage（よくある質問）スキーマ: FAQ形式のコンテンツに適用するスキーマです。検索結果でよくある質問がアコーディオン形式で表示されることがあります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "SEO内部対策とは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO内部対策とは、Webサイトの内部要素（HTML構造、サイト設計、ページ速度など）を検索エンジンに最適化する取り組みの総称です。外部対策（被リンク獲得等）とは異なり、自社だけで完結できる施策です。"
      }
    },
    {
      "@type": "Question",
      "name": "SEO内部対策で最も優先すべき施策は？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "サイト構造の最適化と内部リンクの設計が最優先です。これらは他のすべての施策の土台となるため、先に整備することで後続の施策効果が最大化されます。"
      }
    },
    {
      "@type": "Question",
      "name": "内部対策だけで検索順位は上がりますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "はい、内部対策だけでも検索順位は改善できます。クローラーがページを正しく巡回・理解できる状態をつくることで、既存コンテンツの評価が高まりやすくなります。"
      }
    }
  ]
}
</script>

3. WebSite（サイト内検索ボックス）スキーマ: サイトのトップページに設置することで、Google検索結果にサイト内検索ボックスが表示される可能性があります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "scale-basics.com",
  "url": "https://scale-basics.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://scale-basics.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

構造化データの実装後は、必ずGoogle Search Consoleの「拡張」レポートと、リッチリザルトテストツールでエラーがないか確認してください。エラーを修正したあとにSearch Consoleで再確認を依頼できる「修正を検証（Validate Fix）」機能もありますが、これは同種のエラーがサイト全体で発生している場合に使うものです。単一URLの修正確認にはURL検査ツールの方が適しています（参照: Validate Fixを使うべき場面をGoogleが解説したニュース）。構造化データにエラーがあるとリッチリザルトが表示されないため、公開後の検証は必ず行いましょう。

領域5. ページ速度とCore Web Vitals

ページ速度はGoogleの公式ランキング要因であり、2021年のPage Experience Updateで導入されたCore Web Vitals（CWV）は、2026年現在も重要な評価指標として機能しています。ページが遅いとユーザーが離脱するだけでなく、Googleのクロールバジェット（一定期間にクロールできるページ数）も効率的に使えなくなります。

Core Web Vitalsは以下の3つの指標で構成されています。

LCP（Largest Contentful Paint）: ページ内で最も大きなコンテンツ要素（通常はヒーロー画像や見出しテキストブロック）が表示されるまでの時間。良好な値は2.5秒以内です。

INP（Interaction to Next Paint）: ユーザーがページ上で行ったすべてのインタラクション（クリック、タップ、キー入力）のうち、最も応答が遅かったものの応答時間。2024年3月にFID（First Input Delay）から正式に置き換えられました。良好な値は200ミリ秒以内です。

CLS（Cumulative Layout Shift）: ページの読み込み中に予期しないレイアウトのずれが発生する度合い。広告やフォントの遅延読み込みによるコンテンツの「ガタつき」が主な原因です。良好な値は0.1以下です。

LCP/INP/CLSの改善テクニック

PageSpeed Insightsで現状のスコアを確認した上で、以下の改善テクニックを実装してください。

LCP改善 — 画像の最適化: LCPの遅延は、ヒーロー画像など大きな画像の読み込みが原因になりやすいため、画像最適化の効果が大きい領域です。

<!-- Before: 最適化されていない画像 -->
<img src="/images/hero-banner.png" alt="ヒーロー画像">

<!-- After: 最適化された画像（LCP要素） -->
<img
  src="/images/hero-banner.webp"
  alt="SEO内部対策の6つの領域を示す図解"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
  decoding="async"
>

<!-- ファーストビュー外の画像には遅延読み込みを適用 -->
<img
  src="/images/chart-example.webp"
  alt="内部対策の6領域を整理した図"
  width="800"
  height="450"
  loading="lazy"
  decoding="async"
>

改善ポイントを解説します。まず、画像フォーマットをPNG/JPEGからWebPやAVIFに変換します。これらの形式は、同等の画質を保ちながらファイルサイズを小さくできます。次に、width と height 属性を明示することで、ブラウザが画像のアスペクト比を事前に計算でき、CLS（レイアウトシフト）の防止にもつながります。LCP要素となる画像には fetchpriority="high" を設定して優先的に読み込ませ、ファーストビュー外の画像には loading="lazy" を設定して初期読み込みの負荷を軽減します。

INP改善 — JavaScriptの最適化: INPの悪化は、メインスレッドを長時間占有するJavaScript処理が原因であることがほとんどです。まず読み込み方法を見直します。

<!-- Before: レンダリングを妨げるJS -->
<script src="/js/analytics.js"></script>
<script src="/js/third-party-widget.js"></script>

<!-- After: 非同期読み込みに変更 -->
<script src="/js/analytics.js" defer></script>
<script src="/js/third-party-widget.js" async></script>

さらに、重要でないスクリプトはユーザーの初回操作後に読み込むことで、初期表示時のメインスレッド負荷を抑えられます。

// ユーザーが初めて操作した後にサードパーティスクリプトを読み込む
const loadDeferredScripts = () => {
  const script = document.createElement('script');
  script.src = '/js/third-party-widget.js';
  document.body.appendChild(script);
  ['click', 'scroll', 'keydown', 'touchstart'].forEach(event => {
    document.removeEventListener(event, loadDeferredScripts);
  });
};
['click', 'scroll', 'keydown', 'touchstart'].forEach(event => {
  document.addEventListener(event, loadDeferredScripts, { once: true });
});

また、長いタスクを分割して定期的にメインスレッドへ制御を戻す「タスクの細分化（Yielding）」も有効です。

// Before: 長いタスクがメインスレッドを占有する
function processLargeDataset(data) {
  data.forEach(item => {
    heavyComputation(item);
    updateDOM(item);
  });
}

// After: scheduler.yield() で定期的に制御を返す
async function processLargeDataset(data) {
  for (const item of data) {
    heavyComputation(item);
    updateDOM(item);
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield();
    }
  }
}

CLS改善 — レイアウトシフトの防止: CLSの主な原因は、サイズが指定されていない画像・動画、動的に挿入されるコンテンツ、Webフォントの読み込み遅延です。フォントと広告枠の扱いを見直しましょう。

<!-- フォントの事前読み込み -->
<link rel="preload" href="/fonts/NotoSansJP-Regular.woff2" as="font" type="font/woff2" crossorigin>

<style>
  @font-face {
    font-family: 'Noto Sans JP';
    src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
    font-display: optional; /* 即座に使えなければフォールバックを使い、シフトを防ぐ */
    font-weight: 400;
  }
  /* 広告やiframeのスペースを事前確保 */
  .ad-container {
    min-height: 250px;
    width: 100%;
    contain: layout;
  }
</style>

<div class="ad-container">
  <!-- 広告スクリプトがここに挿入される -->
</div>

当サイトの実測（2026年7月計測）では、クリティカルCSSのインライン化を中心とした改善で、LCPを3.2秒から1.8秒に短縮しました（旧構成時）。サーバー応答（TTFB）は平均0.19秒です。これらの計測条件や手法はSEOに強いコーディング実践ガイドに詳しく記載しています。パフォーマンス改善は、実装（コード）とインフラ（配信）の両面から取り組むのが効果的です。

領域6. モバイル対応とクロール最適化

2026年現在、Googleはモバイルファーストインデックス（MFI）を完全に適用しています。つまり、Googleはサイトのモバイル版をインデックスの基準として使用しています。モバイル対応が不十分なサイトは、デスクトップでの検索順位にも悪影響を受けます。

モバイル対応の基本は、レスポンシブWebデザインの採用です。Googleはレスポンシブデザインを公式に推奨しており、同一URLで同一HTMLを配信しつつ、CSSメディアクエリでレイアウトを調整する方式が最善です。

<!-- viewportメタタグ（必須） -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<style>
  /* ベース: モバイルファースト */
  .content { padding: 16px; font-size: 16px; line-height: 1.8; }

  /* タブレット以上 */
  @media (min-width: 768px) {
    .content { padding: 24px 32px; max-width: 720px; margin: 0 auto; }
  }

  /* デスクトップ */
  @media (min-width: 1024px) {
    .content { max-width: 960px; padding: 32px 48px; }
  }

  /* タップターゲットの最小サイズ（48x48px推奨） */
  .button, .nav-link { min-height: 48px; min-width: 48px; padding: 12px 16px; }
</style>

robots.txtとsitemap.xmlの設定

robots.txtは、検索エンジンのクローラーにサイトのクロール方法を指示するテキストファイルです。誤った設定をするとサイト全体がインデックスから除外されるリスクがあるため、Googleのrobots.txt仕様を確認した上で設定しましょう。書き方の詳細はrobots.txtの書き方完全ガイドにまとめています。

Before（問題のあるrobots.txt）:

# Before: 過度なブロックや設定ミス
User-agent: *
Disallow: /
# ↑ サイト全体をブロックしてしまっている

# または robots.txt ファイル自体が存在しない

After（最適化されたrobots.txt）:

# After: 適切に設定されたrobots.txt
User-agent: *
# 管理画面・内部ツールのクロールを禁止
Disallow: /admin/
Disallow: /api/
Disallow: /internal/

# 検索結果ページのクロールを禁止（重複コンテンツ防止）
Disallow: /search?
Disallow: /*?sort=
Disallow: /*?filter=

# CSSやJSはクロール許可（Googleがレンダリングするため必要）
Allow: /css/
Allow: /js/
Allow: /images/

# サイトマップの場所を明示
Sitemap: https://scale-basics.com/sitemap.xml

robots.txtで特に注意すべき点を補足します。第一に、CSSファイルとJavaScriptファイルをブロックしてはいけません。GoogleはJavaScriptを実行してページをレンダリングするため、これらのリソースへのアクセスをブロックすると、ページが正しくインデックスされない可能性があります。第二に、Disallow: / は絶対に本番環境で使わないでください。これはサイト全体のクロールをブロックする設定で、開発環境やステージング環境でのみ使うべきものです。

クロール効率を考えるうえで、Googlebotが1ページあたり取得するデータ量にも上限がある点は知っておくとよいでしょう。Googleの解説によると、GooglebotがHTMLを取得するのは先頭2MBまでとされています（参照: Googlebotのクロールと「2MBの壁」の解説）。重要なコンテンツや内部リンクはHTMLの早い位置に置き、ページを不必要に肥大化させないことが、クロールとレンダリングの両面で有利に働きます。

sitemap.xmlは、サイト内の重要なURLをリスト化したXMLファイルで、クローラーがページを効率的に発見するのを助けます。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://scale-basics.com/</loc>
    <lastmod>2026-07-23</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://scale-basics.com/seo-internal/</loc>
    <lastmod>2026-07-23</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

sitemap.xmlのベストプラクティスとして、インデックスさせたいURLだけを含めること、noindexのページやリダイレクト先のURLは含めないこと、URLの数が50,000件を超える場合はサイトマップインデックスファイルで分割することが挙げられます。lastmodには実際のコンテンツ更新日を正確に記載します。ただしGoogleのGary Illyes氏は、lastmodが不正確になるくらいなら省略した方がよいとの見解を示しています（参照: XMLサイトマップのlastmodは不正確なら省いてよいというGoogleの見解）。日付を機械的に埋めるのではなく、本当に更新したときだけ正しい日付を入れる運用にしましょう。sitemap.xmlの場所はrobots.txtに記載するとともに、Google Search Consoleからも送信してください。サイトマップの基礎はサイトマップとは何かを解説した記事で確認できます。

モバイル対応とクロール最適化は、SEO内部対策の中では「守りの施策」に位置づけられます。これらが正しく設定されていないと、他の施策の効果が大きく損なわれます。逆に言えば、ここをしっかり整備すれば、コンテンツやリンクの価値が最大限に活かされるということです。

SEO内部対策の総合チェックリスト

ここまで解説してきた6つの領域の施策を、実装チェックリストとしてまとめます。このチェックリストを使って、自サイトの内部対策の状況を棚卸ししてください。すべての項目に対応する必要はありませんが、優先度「高」の項目は最低限クリアすることを推奨します。

SEO内部対策 総合チェックリスト

領域	チェック項目	優先度	確認方法
1. サイト構造	URLに英語のスラッグを使用し、日本語URLを避けている	高	ブラウザのアドレスバーで確認
	URL階層が3〜4階層以内に収まっている	高	サイトマップまたはURL一覧で確認
	パラメータ付きURLを静的URLに変換している	高	Search Console「ページ」レポート
	サイロ構造（カテゴリ別の分類）が整理されている	中	カテゴリ構造を可視化して確認
	パンくずリストがすべてのページに実装されている	高	目視 + リッチリザルトテスト
	パンくずにBreadcrumbListの構造化データが含まれている	中	リッチリザルトテストツール
2. 内部リンク	重要なページが3クリック以内でトップページから到達できる	高	クロールツール（Screaming Frog等）
	孤立ページ（内部リンクが1本もないページ）が存在しない	高	Search Console「リンク」レポート
	アンカーテキストがリンク先の内容を適切に表している	高	目視でサンプリング確認
	「こちら」「ここ」などの曖昧なアンカーテキストを使っていない	中	サイト内で「こちら」を含むリンクを抽出
	リンク切れ（404リンク）が存在しない	高	Search Console「ページ」レポート
3. メタタグ	すべてのページに固有のtitleタグが設定されている	高	Search Console「検索パフォーマンス」
	titleタグが全角30〜35文字前後に収まっている	高	一括チェックツール
	titleタグの先頭にターゲットキーワードが含まれている	高	目視確認
	すべてのページに固有のmeta descriptionが設定されている	中	クロールツールで一括確認
	すべてのページに自己参照canonicalが設定されている	高	ソースコードまたはクロールツール
4. 構造化データ	記事ページにArticleスキーマが実装されている	中	リッチリザルトテストツール
	パンくずにBreadcrumbListスキーマが実装されている	中	リッチリザルトテストツール
	Search Consoleの「拡張」レポートでエラーがゼロになっている	高	Search Console
5. ページ速度・CWV	LCPが2.5秒以内（モバイル）	高	PageSpeed Insights
	INPが200ms以内	高	PageSpeed Insights / CrUX
	CLSが0.1以下	高	PageSpeed Insights
	画像がWebP/AVIF形式に変換されている	中	DevToolsの「Network」タブ
	レンダリングを妨げるJSにdefer/asyncが設定されている	高	PageSpeed Insightsの診断結果
6. モバイル・クロール	viewportメタタグが正しく設定されている	高	ソースコード確認
	robots.txtでCSS/JSファイルをブロックしていない	高	robots.txtテスター
	robots.txtにsitemap.xmlの場所が記載されている	中	robots.txtを直接確認
	sitemap.xmlにnoindexページやリダイレクトURLが含まれていない	高	Search Consoleのサイトマップレポート

このチェックリストのすべてを一度にクリアする必要はありません。まず優先度「高」の項目を上から順に対応し、次に「中」「低」の順で進めてください。特にサイト構造の整理と内部リンクの最適化は、他の施策の効果を左右する土台になるため、最初に着手する価値があります。また、チェックリストは一度対応して終わりではありません。コンテンツの追加や改修のたびに該当項目を再チェックし、月次で定期点検を行うルーティンを作りましょう。

内部対策の効果をどう測定するか

内部対策は「施策 → クロール → 再評価」という流れで反映されるため、変化が見えるまでに数日から数週間かかります。効果を正しく把握するには、次のデータを定点観測するのが基本です。

• 検索パフォーマンス: Google Search Consoleで、表示回数・クリック数・平均掲載順位・CTRの推移を対象ページ単位で追う
• インデックス状況: Search Consoleの「ページ」レポートで、登録済みページ数と除外理由（重複・クロール済み未登録など）を確認する
• Core Web Vitals: PageSpeed InsightsやCrUXのフィールドデータで、LCP・INP・CLSが「良好」域に入っているかを確認する

数値を評価するときは、施策を行った時期と観測された変化のタイムラグを意識してください。メタタグの最適化は比較的早く反映される一方、構造化データやCore Web Vitalsの改善は効果が現れるまで時間がかかる傾向があります。

技術面の実測例として、当サイトの計測（2026年7月）では、サーバー応答（TTFB）が平均0.19秒、クリティカルCSSのインライン化を中心とした改善でLCPを3.2秒から1.8秒に短縮しています（旧構成時）。計測条件と具体的な実装はSEOに強いコーディング実践ガイドにまとめています。自サイトでも、施策前後で同じ条件・同じツールで測り、変化を記録することが、次の打ち手を判断する材料になります。

まとめ

SEO内部対策は、サイト構造・内部リンク・メタタグ・構造化データ・ページ速度・モバイル対応の6つの領域で構成されています。本記事では各領域のBefore/Afterコード例を示しながら、実装の具体的な方法を解説しました。

内部対策の最大の利点は、自社だけで完結でき、施策の効果を直接計測できることです。まずは総合チェックリストの優先度「高」の項目から着手し、次の順序で進めるのがおすすめです。ステップ1でサイト構造の整理（URL設計・カテゴリ構造）、ステップ2でメタタグの最適化（title・meta description・canonical）、ステップ3で内部リンクの体系的な設計、ステップ4でCore Web Vitalsの改善、ステップ5で構造化データの実装、最後にステップ6でrobots.txtとsitemap.xmlの最適化を行います。

各領域のさらに詳しい実装方法は、以下の関連記事で解説しています。

• テクニカルSEO完全ガイド — 技術面からの内部対策を網羅的に解説
• SEO内部リンク戦略の設計と実装 — 内部リンクの設計・運用ノウハウを深掘り
• robots.txtの書き方完全ガイド — クロール制御の実践的なガイド
• テクニカルSEOとは？ — 基礎知識を初心者向けに解説
• SEOに強いコーディング実践ガイド — HTML/CSSのSEO最適化と実測データ
• 構造化データマークアップの実装手順 — JSON-LDの詳細な実装方法
• SEO対策に必須のHTMLタグ一覧 — SEOに関連するHTMLタグのリファレンス

SEO内部対策は一度実装して終わりではなく、サイトの成長に合わせて継続的に改善していくものです。月次でチェックリストを見直し、Google Search Consoleのデータをモニタリングしながら、改善のサイクルを回し続けてください。本記事が、あなたのサイトの内部対策の出発点となれば幸いです。

本記事は2026年7月時点のGoogle公式ドキュメントおよびサイト内で報じたニュース（生成AI検索の最適化ガイド、Googlebotのクロール仕様、XMLサイトマップのlastmod、GSCのValidate Fix）を基に、scale-basics.com編集部が作成しました。ページ速度に関する数値は、当サイトの実測（2026年7月計測。詳細は/seo-coding/に記載）に基づきます。CWVの基準値・INPの仕様などは各時点のGoogle公式情報に準拠しています。