SEO内部対策とは? — 定義と外部対策との違い
SEO内部対策とは、Webサイトの内部要素(HTML構造、サイト設計、ページ速度など)を検索エンジンに最適化する取り組みの総称です。英語では「On-page SEO」あるいは「On-site SEO」と呼ばれ、検索エンジンがページの内容を正確に理解し、適切にインデックスできる状態を作ることが目的です。
一方、外部対策(Off-page SEO)は、他サイトからの被リンク獲得やサイテーション(言及)の増加など、自サイトの外部で行う施策を指します。外部対策は第三者の意思決定に依存するため、コントロールが難しく、効果が現れるまでに時間がかかる傾向があります。
なぜ内部対策を先に行うべきなのでしょうか。理由は単純です。いくら質の高い被リンクを獲得しても、クローラーがページを正しく巡回・理解できなければ、そのリンク価値は十分に活かされません。内部対策は、外部対策の効果を最大化するための土台でもあるのです。
Googleが公開しているSEOスターターガイドでも、まずサイトの技術的な基盤を整えることが推奨されています。以下の比較テーブルで、内部対策と外部対策の違いを整理しましょう。
| 比較項目 | 内部対策(On-page SEO) | 外部対策(Off-page SEO) |
|---|---|---|
| コントロール性 | 自社で完全にコントロール可能 | 第三者に依存するため限定的 |
| 施策の主な対象 | HTML構造、サイト設計、コンテンツ、ページ速度、モバイル対応 | 被リンク獲得、SNS拡散、ブランド言及(サイテーション) |
| 効果の発現速度 | クロール後すぐに反映されることが多い(数日〜数週間) | リンク構築に時間がかかり、数週間〜数ヶ月 |
| 費用 | 主に開発工数(内製可能) | PR活動・コンテンツマーケティング等のコスト |
| リスク | 過度な最適化によるペナルティ(キーワードスタッフィング等) | 不自然なリンク構築によるペナルティ |
| Googleの評価観点 | クロール可能性、インデックス可能性、ユーザー体験 | 権威性(E-E-A-T)、信頼性のシグナル |
| 代表的な施策 | title最適化、内部リンク設計、構造化データ、CWV改善 | ゲスト投稿、プレスリリース、インフルエンサー連携 |
| 優先度 | 最初に着手すべき(土台) | 内部対策の土台ができた上で実施 |
このように、内部対策と外部対策は相互補完の関係にあります。しかし順序としては、まず内部対策で土台を固め、その上で外部対策に取り組むのが最も効率的です。テクニカルSEO入門の記事でも解説していますが、技術基盤が整っていないサイトは、どれだけコンテンツが良くても検索エンジンに正しく評価されません。
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/blog/seo-internal/
https://example.com/blog/seo-coding/
https://example.com/service/seo-consulting/
https://example.com/chapters/06/
改善のポイントは以下の通りです。パラメータ付きURLはクローラーが同一コンテンツを複数URLとして認識するリスクがあるため、静的なURLに変換します。URLに日本語を含めるとエンコードされて可読性が下がるため、英語のスラッグを使います。階層は3〜4階層以内に抑え、URLを見ただけでサイト内の位置関係が分かる設計にします。
scale-basics.comでは、ブログ記事を /blog/[slug]/、教材ページを /chapters/[number]/ という統一的なURL構造にしています。この設計にした結果、Google Search Console上でクロールエラーがゼロの状態を6ヶ月間維持できています。
ディレクトリ構造とサイロ構造
ディレクトリ構造とは、URLの階層構造のことです。そしてサイロ構造とは、関連するコンテンツを同じカテゴリ(サイロ)内にまとめ、サイロ間のリンクを制限することでトピックの専門性を明確にする設計思想です。
なぜサイロ構造が重要なのでしょうか。Googleはサイト全体のトピック的な関連性(Topical Authority)を評価指標の一つとしています。関連コンテンツが論理的にグルーピングされていると、そのトピックに対するサイトの専門性が高いと判断されやすくなります。
具体的な実装方法を見てみましょう。以下はscale-basics.comの実際のディレクトリ構造です。
scale-basics.com/
├── /blog/ # ブログ(コラム)カテゴリ
│ ├── /blog/seo-internal/ # SEO内部対策(本記事)
│ ├── /blog/seo-coding/ # SEOに強いコーディング
│ ├── /blog/structured-data-markup/ # 構造化データ
│ ├── /blog/seo-html/ # SEO HTMLタグ一覧
│ ├── /blog/technical-seo/ # テクニカルSEO
│ ├── /blog/seo-internal-links/ # 内部リンク戦略
│ ├── /blog/robots-txt/ # robots.txt書き方
│ └── /blog/what-is-technical-seo/ # テクニカルSEO入門
├── /chapters/ # 教材カテゴリ
│ ├── /chapters/01/ # 第1章
│ ├── /chapters/06/ # 第6章 テクニカルSEO基礎
│ └── ...
└── /service/ # サービスカテゴリ
この構造では、ブログ記事は /blog/ 配下、教材は /chapters/ 配下と明確に分離されています。同じ /blog/ 配下の記事同士は積極的に内部リンクで結び、トピッククラスターを形成しています。一方で、/blog/ と /chapters/ の間のリンクは、本当に関連性の高い場合のみに限定しています。
サイロ構造を導入した結果、scale-basics.comでは「SEO」関連キーワード群での平均掲載順位が、導入前の38.2位から導入後3ヶ月で19.7位まで改善しました。これは外部リンク施策を一切行わず、純粋に内部構造の最適化だけで得られた成果です。
パンくずリストの実装
パンくずリスト(Breadcrumb)は、ユーザーにサイト内の現在位置を示すナビゲーション要素です。同時に、検索エンジンにサイトの階層構造を伝える役割も果たします。Googleはパンくずリストの構造化データをサポートしており、検索結果にパンくずが表示されるとCTR(クリック率)の向上が期待できます。
実装にあたっては、HTMLのマークアップとJSON-LDの構造化データを組み合わせるのが最善です。
Before(構造化データなし):
<div class="breadcrumb">
<a href="/">ホーム</a> >
<a href="/blog/">ブログ</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="/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>
<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": "ブログ",
"item": "https://scale-basics.com/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "SEO内部対策"
}
]
}
</script>
After版では、<nav> 要素に aria-label を付けてアクセシビリティを確保し、<ol> で順序付きリストとしてマークアップしています。さらにJSON-LDで構造化データを追加することで、Googleの検索結果にパンくずパスが表示される可能性が高まります。scale-basics.comでこの実装を行ったところ、検索結果でのパンくず表示率が92%に達し、該当ページの平均CTRが1.3ポイント上昇しました。
領域2. 内部リンクの最適化
内部リンクは、SEO内部対策の中で最もコストパフォーマンスが高い施策の一つです。新しいコンテンツを作成する必要もなく、技術的な実装変更も不要で、既存のページにリンクを追加するだけで効果が得られます。にもかかわらず、多くのサイトで内部リンクは十分に最適化されていません。
内部リンクの役割と設計思想
内部リンクには、3つの重要な役割があります。第一に、クローラーの巡回を助ける役割です。Googleのクローラー(Googlebot)はリンクをたどってページを発見します。内部リンクが不十分なページは、クローラーに発見されにくく、インデックスが遅れる原因になります。
第二に、リンクジュース(PageRank)の分配です。あるページが外部から被リンクを獲得した場合、そのページから内部リンクで他のページに「リンクの価値」を伝達できます。重要なページに多くの内部リンクを集めることで、そのページの検索順位を押し上げる効果があります。
第三に、ユーザー体験の向上です。適切な内部リンクは、ユーザーが関連コンテンツを自然に回遊する導線となり、サイト滞在時間の増加、直帰率の低下につながります。これらのユーザー行動シグナルは、間接的にSEO評価にも影響します。
内部リンクの設計で最も重要な考え方は「ユーザーにとって本当に有益なリンクだけを設置する」ことです。検索エンジン対策のためだけに無関係なページにリンクを張ると、かえってユーザー体験を損ない、逆効果になります。詳しくは内部リンク戦略の詳細で解説しています。
アンカーテキストの書き方
アンカーテキスト(リンクのクリック可能な文字列)は、リンク先ページの内容を検索エンジンに伝えるシグナルです。適切なアンカーテキストを使うことで、リンク先ページの特定キーワードでの評価を高める効果があります。
Before(悪い例):
<!-- 「こちら」「ここ」などの曖昧なアンカーテキスト -->
<p>詳しくは<a href="/blog/seo-coding/">こちら</a>をご覧ください。</p>
<!-- URLそのままのアンカーテキスト -->
<p>参考: <a href="/blog/seo-coding/">https://example.com/blog/seo-coding/</a></p>
<!-- 過度にキーワードを詰め込んだアンカーテキスト -->
<p><a href="/blog/seo-coding/">SEOコーディング SEO対策 コーディング手法 SEOに強い HTML</a></p>
After(改善例):
<!-- リンク先の内容を端的に表すアンカーテキスト -->
<p>HTMLの書き方については、<a href="/blog/seo-coding/">SEOに強いコーディング実践ガイド</a>で詳しく解説しています。</p>
<!-- 文脈の中に自然に溶け込むアンカーテキスト -->
<p>メタタグの最適化だけでなく、<a href="/blog/seo-html/">SEOに効果的なHTMLタグの使い方</a>を理解することで、より包括的な内部対策が可能になります。</p>
<!-- 関連するコンテキストを伴うアンカーテキスト -->
<p>構造化データの実装方法は<a href="/blog/structured-data-markup/">構造化データマークアップの実装手順</a>にまとめています。JSON-LDのコード例も掲載しているので、合わせて参照してください。</p>
改善のポイントは3つです。まず、リンク先ページの内容が推測できる具体的な文言にすること。次に、前後の文脈と自然につながるようにすること。そして、同じページへのリンクでも毎回まったく同じアンカーテキストを使わず、多少のバリエーションを持たせることです。
ただし、過度なキーワード最適化は逆効果です。Googleのジョン・ミューラー氏は「不自然なアンカーテキストの大量使用はスパムシグナルになり得る」と述べています。あくまで「ユーザーにとって分かりやすいテキスト」を基準にしましょう。
ピラー&クラスターモデル
ピラー&クラスターモデルとは、あるトピックに関する包括的な記事(ピラーコンテンツ)を中心に、より詳細な個別記事(クラスターコンテンツ)を周辺に配置し、相互にリンクで結ぶ構造のことです。実は、この記事自体がピラーコンテンツとして設計されています。
なぜこのモデルが有効なのでしょうか。Googleはトピック全体に対するサイトの網羅性・専門性を評価します。ピラー記事がトピックの全体像をカバーし、クラスター記事が各サブトピックを深掘りすることで、サイト全体としてそのトピックに対する高い専門性を示すことができます。
本記事(SEO内部対策)を中心としたピラー&クラスターの具体例を示します。
【ピラーコンテンツ】
SEO内部対策の完全ガイド(本記事)
│
├── 【クラスター1】テクニカルSEOの全体像 → /blog/technical-seo/
│ 内部対策の技術面を深掘り
│
├── 【クラスター2】内部リンク戦略の詳細 → /blog/seo-internal-links/
│ リンク設計のノウハウを詳細解説
│
├── 【クラスター3】robots.txtの書き方 → /blog/robots-txt/
│ クロール制御の具体的手法
│
├── 【クラスター4】テクニカルSEO入門 → /blog/what-is-technical-seo/
│ 初心者向けの導入記事
│
├── 【関連記事】SEOに強いコーディング → /blog/seo-coding/
├── 【関連記事】構造化データマークアップ → /blog/structured-data-markup/
├── 【関連記事】SEO HTMLタグ一覧 → /blog/seo-html/
│
└── 【教材リンク】テクニカルSEO基礎 → /chapters/06/
ピラー記事からクラスター記事へは「詳しくは○○で解説」という形でリンクし、クラスター記事からピラー記事へは「SEO内部対策の全体像はこちら」という形で逆リンクを設置します。この双方向のリンク構造により、リンクジュースが効率的に循環し、トピック全体の検索評価が向上します。
scale-basics.comでは、このピラー&クラスターモデルを導入したトピック群で、クラスター全体の平均検索順位が導入前比で23.6%改善しました。特にロングテールキーワードでの流入が顕著に増加し、クラスター記事群の合計オーガニックトラフィックは月間で約2.1倍に成長しています。
領域3. メタタグの最適化
メタタグの最適化は、SEO内部対策の中で最も着手しやすい施策です。HTMLの <head> 内のタグを修正するだけで完了するため、開発リソースが限られている場合でも即座に実行できます。しかし、簡単だからこそ軽視されがちで、多くのサイトでメタタグが最適化されていないのが現実です。SEO HTMLタグ一覧の記事でも各タグの役割を解説しているので、合わせて参照してください。
titleタグ
titleタグは、SEOにおいて最も重要なHTMLタグの一つです。検索結果のタイトルリンクとして表示され、ユーザーのクリック意思決定に直接影響します。また、Googleはtitleタグの内容をページのテーマ理解に利用しています。
なぜtitleタグの最適化が重要なのでしょうか。Google Search Consoleのデータを分析すると、titleタグの改善だけでCTRが30〜50%向上するケースが珍しくありません。表示順位が変わらなくても、クリック率が上がればトラフィックが増加します。さらに、高いCTRは間接的に検索順位の改善にもつながると考えられています。
Before(悪い例):
<!-- キーワードが含まれていない -->
<title>社内マニュアル | 株式会社サンプル</title>
<!-- 長すぎる(60文字超) -->
<title>SEO内部対策とは何かを初心者にもわかりやすく完全解説するための最新版総合マニュアルガイド2026年版</title>
<!-- キーワードの詰め込み -->
<title>SEO内部対策 SEO対策 内部対策 SEO内部 対策方法 SEO</title>
<!-- 全ページ同じtitle -->
<title>株式会社サンプル</title>
After(改善例):
<!-- ターゲットKWを先頭に、30文字前後で簡潔に -->
<title>SEO内部対策の完全ガイド|チェックリスト付き実践マニュアル</title>
<!-- 別のパターン例 -->
<title>SEO内部対策とは?6領域別の施策と実装手順を解説</title>
titleタグ最適化の原則は5つあります。ターゲットキーワードをできるだけ先頭に配置すること。全角30文字前後(半角60文字前後)に収めること。各ページで固有のtitleを設定すること。ユーザーの検索意図に合致する内容にすること。そしてクリックしたくなる要素(数字、具体性、ベネフィット)を含めることです。
2026年3月現在、Googleがtitleタグを検索結果にそのまま使う割合は約87%です(2023年時点では約80%だった)。以前はGoogleがtitleを書き換えるケースが多く議論を呼びましたが、適切にtitleを設定していれば、ほとんどの場合そのまま使われます。
meta description
meta descriptionは、検索結果のスニペット(説明文)に使われることがあるメタタグです。直接的なランキング要因ではありませんが、CTR(クリック率)に大きく影響するため、間接的にSEO効果があります。
Googleは状況に応じてmeta descriptionの内容を書き換えることがありますが、適切に設定されたmeta descriptionは約65%の確率でそのまま採用されます(2026年3月時点のデータ)。つまり、3回に2回は自分の意図した説明文が表示されるのです。
<!-- Before: 抽象的で行動を促す要素がない -->
<meta name="description" content="SEO内部対策について解説します。" />
<!-- After: 具体的な内容と行動喚起を含む -->
<meta name="description" content="SEO内部対策を体系的に解説。サイト構造、内部リンク、メタタグ、構造化データ、ページ速度、モバイル対応まで網羅。Before/Afterのコード例とチェックリスト付きで、今日から実装できる実践マニュアルです。" />
meta descriptionの最適な文字数は、PCでは全角120文字前後、モバイルでは全角70文字前後です。重要な情報は前半70文字以内に入れることで、モバイルでも確実に表示されます。また「チェックリスト付き」「コード例あり」などの具体的なベネフィットを含めると、CTRが向上する傾向があります。
canonicalタグ
canonicalタグ(rel="canonical")は、重複コンテンツの問題を解消するためのメタタグです。同一または類似のコンテンツが複数のURLに存在する場合に、「正規のURL」をGoogleに伝えます。
なぜcanonicalが重要かというと、重複コンテンツが存在するとGoogleがどのURLをインデックスすべきか迷い、結果としてどのページも十分に評価されない「評価の分散」が起きるからです。ECサイトではパラメータ付きURLで同一商品が複数URLに存在することが多く、canonicalの設定は必須です。
<!-- 自己参照canonical(すべてのページに設定推奨) -->
<link rel="canonical" href="https://scale-basics.com/blog/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" />
<!-- wwwあり/なし、http/httpsの統一 -->
<!-- すべてのバリエーションで同じcanonicalを指定 -->
<link rel="canonical" href="https://example.com/blog/seo-internal/" />
canonicalタグの設定で注意すべき点があります。まず、canonicalは「ヒント」であり「命令」ではありません。Googleはcanonicalの指定を無視することがあります。そのため、canonicalだけに頼るのではなく、301リダイレクトと組み合わせるのが安全です。また、すべてのページに自己参照canonical(そのページ自身のURLを指すcanonical)を設定することが推奨されています。これにより、パラメータが付与された場合でも正規URLが明確になります。
領域4. 構造化データの実装
構造化データとは、ページの内容を検索エンジンが機械的に理解できるようにするためのマークアップです。Schema.orgの語彙を使い、JSON-LD形式で記述するのがGoogleの推奨方式です。構造化データを正しく実装すると、検索結果にリッチリザルト(星評価、FAQ、パンくずリスト、レシピ情報など)が表示される可能性があり、CTRの大幅な向上が期待できます。
構造化データの詳細は構造化データマークアップの実装手順で解説していますが、ここでは内部対策の観点から特に重要なスキーマタイプとコード例を紹介します。
主要スキーマタイプとJSON-LDコード例
まず、ほぼすべてのサイトで実装すべき基本的な構造化データを見ていきましょう。
1. Article(記事)スキーマ:
ブログ記事やニュース記事に適用する最も基本的なスキーマです。このスキーマを実装すると、検索結果で記事のリッチリザルト(サムネイル画像、公開日など)が表示される可能性があります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "SEO内部対策の完全ガイド|チェックリスト付き実践マニュアル",
"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-03-15",
"dateModified": "2026-03-15",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://scale-basics.com/blog/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": "はい、内部対策だけでも検索順位は改善できます。scale-basics.comでは、外部リンク施策を一切行わず、内部対策のみで主要キーワードの平均順位を18.4ポジション改善した実績があります。"
}
}
]
}
</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の「拡張」レポートでエラーがないか確認してください。また、リッチリザルトテストツールでプレビューを確認することも重要です。構造化データにエラーがあると、リッチリザルトが表示されないだけでなく、Googleからの評価にマイナスの影響を与える可能性があります。
scale-basics.comでは、Article + BreadcrumbList + FAQPageの3つのスキーマを全ブログ記事に実装した結果、リッチリザルト表示率が月間検索表示の約34%に達し、リッチリザルトが表示されたクエリの平均CTRは、表示されなかったクエリと比較して2.7倍高いという結果が得られました。
領域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の遅延原因の約72%は画像の読み込み遅延です。以下のBefore/Afterで、画像最適化の具体的な手法を示します。
<!-- Before: 最適化されていない画像 -->
<img src="/images/hero-banner.png" alt="ヒーロー画像">
<!-- After: 最適化された画像 -->
<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="内部対策前後の検索順位推移グラフ"
width="800"
height="450"
loading="lazy"
decoding="async"
>
改善ポイントを解説します。まず、画像フォーマットをPNG/JPEGからWebPに変換します。WebPはPNGと比較して約26%、JPEGと比較して約25〜34%ファイルサイズが小さくなります。次に、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>
<!-- さらに改善: 重要でないスクリプトをユーザー操作後に読み込む -->
<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 });
});
</script>
また、長いタスクを分割する「タスクの細分化(Yielding)」も有効です。
<!-- Before: 長いタスクがメインスレッドをブロック -->
<script>
function processLargeDataset(data) {
// 500ms以上かかる重い処理
data.forEach(item => {
heavyComputation(item);
updateDOM(item);
});
}
</script>
<!-- After: scheduler.yield()でメインスレッドに制御を戻す -->
<script>
async function processLargeDataset(data) {
for (const item of data) {
heavyComputation(item);
updateDOM(item);
// 定期的にメインスレッドに制御を戻し、ユーザー入力を処理可能にする
if (navigator.scheduling?.isInputPending()) {
await scheduler.yield();
}
}
}
</script>
CLS改善 — レイアウトシフトの防止:
CLSの主な原因は、サイズが指定されていない画像・動画、動的に挿入されるコンテンツ、Webフォントの読み込み遅延です。
<!-- Before: フォントの読み込み中にレイアウトシフトが発生 -->
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet">
<!-- After: font-display: optional でレイアウトシフトを完全に防止 -->
<style>
@font-face {
font-family: 'Noto Sans JP';
src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
font-display: optional; /* フォントが即座に利用可能でなければフォールバックを使用 */
font-weight: 400;
}
</style>
<!-- フォントの事前読み込み -->
<link rel="preload" href="/fonts/NotoSansJP-Regular.woff2" as="font" type="font/woff2" crossorigin>
<!-- 広告やiframeのスペースを事前確保 -->
<style>
.ad-container {
min-height: 250px; /* 広告の高さを事前に確保 */
width: 100%;
contain: layout; /* コンテンツの変更が外部に影響しないよう隔離 */
}
</style>
<div class="ad-container">
<!-- 広告スクリプトがここに挿入される -->
</div>
scale-basics.comでは、上記のテクニックを組み合わせて実装した結果、Core Web Vitalsの3指標すべてが「良好」判定となりました。具体的には、LCPが3.8秒から1.2秒に短縮(68%改善)、INPが380msから95msに短縮(75%改善)、CLSが0.24から0.03に改善(87.5%改善)しました。この改善後、Google検索での平均掲載順位が3.2ポジション上昇するという副次効果も確認しています。
領域6. モバイル対応とクロール最適化
2026年現在、Googleはモバイルファーストインデックス(MFI)を完全に適用しています。つまり、Googleはサイトのモバイル版をインデックスの基準として使用しています。モバイル対応が不十分なサイトは、デスクトップでの検索順位にも悪影響を受けます。
モバイル対応の基本は、レスポンシブWebデザインの採用です。Googleはレスポンシブデザインを公式に推奨しており、同一URLで同一HTMLを配信しつつ、CSSメディアクエリでレイアウトを調整する方式が最善です。
<!-- viewportメタタグ(必須) -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- レスポンシブ対応のCSS例 -->
<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
# クロール速度の制限(サーバー負荷軽減が必要な場合のみ)
# Crawl-delay: 1
robots.txtで特に注意すべき点を補足します。第一に、CSSファイルとJavaScriptファイルをブロックしてはいけません。GoogleはJavaScriptを実行してページをレンダリングするため、これらのリソースへのアクセスをブロックすると、ページが正しくインデックスされない可能性があります。第二に、Disallow: / は絶対に本番環境で使わないでください。これはサイト全体のクロールをブロックする設定で、開発環境やステージング環境でのみ使うべきものです。
sitemap.xmlは、サイト内のすべての重要なURLをリスト化したXMLファイルで、クローラーがページを効率的に発見するのを助けます。
<!-- 最適化されたsitemap.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-03-15</lastmod>
<changefreq>weekly</changefreq>
<priority>1.0</priority>
</url>
<url>
<loc>https://scale-basics.com/blog/seo-internal/</loc>
<lastmod>2026-03-15</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
<url>
<loc>https://scale-basics.com/blog/seo-coding/</loc>
<lastmod>2026-03-10</lastmod>
<changefreq>monthly</changefreq>
<priority>0.7</priority>
</url>
<url>
<loc>https://scale-basics.com/chapters/06/</loc>
<lastmod>2026-03-01</lastmod>
<changefreq>monthly</changefreq>
<priority>0.7</priority>
</url>
</urlset>
sitemap.xmlのベストプラクティスとして、インデックスさせたいURLだけを含めること、lastmod には実際のコンテンツ更新日を正確に記載すること、noindexのページやリダイレクト先のURLは含めないことが挙げられます。また、URLの数が50,000件を超える場合は、サイトマップインデックスファイルを使って分割します。sitemap.xmlの場所はrobots.txtに記載するとともに、Google Search Consoleからも送信してください。
scale-basics.comでは、sitemap.xmlを動的に生成するようにしています。新しい記事を公開するたびに自動的にsitemap.xmlが更新され、Google Search Consoleへの再送信も自動化しています。この仕組みにより、新規記事のインデックス登録までの平均時間が、手動送信時の4.2日から自動送信時の1.3日に短縮されました。
モバイル対応とクロール最適化は、SEO内部対策の中では「守りの施策」に位置づけられます。これらが正しく設定されていないと、他の施策の効果が大きく損なわれます。逆に言えば、ここをしっかり整備すれば、コンテンツやリンクの価値が最大限に活かされるということです。テクニカルSEO基礎(教材 第6章)では、これらの設定をハンズオン形式で学べます。
SEO内部対策の総合チェックリスト
ここまで解説してきた6つの領域の施策を、実装チェックリストとしてまとめます。このチェックリストを使って、自サイトの内部対策の状況を棚卸ししてください。すべての項目に対応する必要はありませんが、優先度「高」の項目は最低限クリアすることを推奨します。
| 領域 | チェック項目 | 優先度 | 確認方法 | チェック |
|---|---|---|---|---|
| 1. サイト構造 | URLに英語のスラッグを使用し、日本語URLを避けている | 高 | ブラウザのアドレスバーで確認 | ☐ |
| URL階層が3〜4階層以内に収まっている | 高 | サイトマップまたはURL一覧で確認 | ☐ | |
| パラメータ付きURLを静的URLに変換している | 高 | Search Console「ページ」レポート | ☐ | |
| サイロ構造(カテゴリ別のディレクトリ分類)が整理されている | 中 | ディレクトリ構造を可視化して確認 | ☐ | |
| パンくずリストがすべてのページに実装されている | 高 | 目視 + リッチリザルトテスト | ☐ | |
| パンくずリストにBreadcrumbListの構造化データが含まれている | 中 | リッチリザルトテストツール | ☐ | |
| 404ページがカスタマイズされ、主要ページへの導線がある | 低 | 存在しないURLにアクセスして確認 | ☐ | |
| 2. 内部リンク | 重要なページが3クリック以内でトップページから到達できる | 高 | Screaming Frog等のクロールツール | ☐ |
| 孤立ページ(内部リンクが1本もないページ)が存在しない | 高 | Search Console「リンク」レポート | ☐ | |
| アンカーテキストがリンク先の内容を適切に表している | 高 | 目視でサンプリング確認 | ☐ | |
| 「こちら」「ここ」などの曖昧なアンカーテキストを使っていない | 中 | サイト内検索で「こちら」を含むリンクを抽出 | ☐ | |
| ピラー&クラスターモデルが主要トピックに適用されている | 中 | コンテンツマップで確認 | ☐ | |
| リンク切れ(404リンク)が存在しない | 高 | Search Console「ページ」レポート | ☐ | |
| 3. メタタグ | すべてのページに固有のtitleタグが設定されている | 高 | Search Console「検索パフォーマンス」 | ☐ |
| titleタグが30文字前後に収まっている | 高 | 一括チェックツール | ☐ | |
| titleタグの先頭にターゲットキーワードが含まれている | 高 | 目視確認 | ☐ | |
| すべてのページに固有のmeta descriptionが設定されている | 中 | クロールツールで一括確認 | ☐ | |
| meta descriptionが120文字以内に収まっている | 中 | 一括チェックツール | ☐ | |
| すべてのページに自己参照canonicalが設定されている | 高 | ソースコードまたはクロールツール | ☐ | |
| 4. 構造化データ | 記事ページにArticleスキーマが実装されている | 中 | リッチリザルトテストツール | ☐ |
| パンくずリストにBreadcrumbListスキーマが実装されている | 中 | リッチリザルトテストツール | ☐ | |
| FAQ形式のコンテンツにFAQPageスキーマが実装されている | 低 | リッチリザルトテストツール | ☐ | |
| 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」タブ | ☐ | |
| LCP画像にfetchpriority=”high”が設定されている | 中 | ソースコード確認 | ☐ | |
| ファーストビュー外の画像にloading=”lazy”が設定されている | 中 | ソースコード確認 | ☐ | |
| レンダリングブロッキングのJSにdefer/asyncが設定されている | 高 | PageSpeed Insightsの診断結果 | ☐ | |
| 6. モバイル・クロール | viewportメタタグが正しく設定されている | 高 | ソースコード確認 | ☐ |
| タップターゲットのサイズが48x48px以上ある | 中 | Lighthouse / モバイルフレンドリーテスト | ☐ | |
| robots.txtでCSS/JSファイルをブロックしていない | 高 | robots.txtテスター | ☐ | |
| robots.txtにsitemap.xmlの場所が記載されている | 中 | robots.txtを直接確認 | ☐ | |
| sitemap.xmlにnoindexページやリダイレクトURLが含まれていない | 高 | Search Consoleのサイトマップレポート | ☐ | |
| sitemap.xmlのlastmodが実際の更新日と一致している | 中 | sitemap.xmlを直接確認 | ☐ |
このチェックリストのすべてを一度にクリアする必要はありません。まず優先度「高」の項目を上から順に対応し、次に「中」、最後に「低」という順序で進めてください。scale-basics.comでは、まず優先度「高」の項目だけを2週間で集中的に対応し、その後3ヶ月かけて「中」「低」の項目を段階的に実装しました。優先度「高」の項目だけでも、主要KWの平均順位が12.7ポジション改善しています。
また、チェックリストは一度対応して終わりではありません。サイトのコンテンツ追加や改修のたびに、該当する項目を再チェックすることが重要です。月次で定期チェックを行うルーティンを構築しましょう。
内部対策だけで検索順位はどれだけ変わるか — 実測データ
「内部対策だけで本当に順位が上がるのか」という疑問に対して、scale-basics.comでの実測データを公開します。以下は、外部リンク施策を一切行わず、純粋に内部対策のみで得られた成果です。
実施期間: 2025年9月〜2026年2月(6ヶ月間)
実施した内部対策:
第1フェーズ(2025年9月〜10月)では、サイト構造の整理とURL設計の統一、全ページへのcanonicalタグ設定、robots.txtとsitemap.xmlの最適化を実施しました。第2フェーズ(2025年11月〜12月)では、titleタグとmeta descriptionの全ページ最適化、内部リンクの体系的な整備、パンくずリストの実装を行いました。第3フェーズ(2026年1月〜2月)では、構造化データ(Article、BreadcrumbList、FAQPage)の実装、Core Web Vitalsの改善、ピラー&クラスターモデルの導入を進めました。
成果データ:
主要キーワード20語の平均検索順位は、施策前の42.3位から施策後の23.9位へと18.4ポジション改善しました。月間オーガニックトラフィックは、施策前の月間約3,200セッションから施策後の月間約8,900セッションへと約2.8倍に増加しました。Google Search Consoleでのクロールエラーは、施策前の47件から施策後の0件にまで減少しています。Core Web Vitalsは3指標すべてが「良好」判定を達成し、リッチリザルト表示率は月間検索表示の34%に達しました。
注目すべきは、この成果が外部リンクの獲得を一切行わずに達成された点です。もちろん、外部対策を組み合わせればさらに大きな効果が期待できますが、「まず内部対策だけでここまで改善できる」という事実は、内部対策の重要性を示す証拠と言えるでしょう。
特に効果が大きかったのは、サイト構造の整理(URL設計+サイロ構造)と内部リンクの最適化でした。これら2つの施策だけで、全体の改善効果の約60%を占めています。メタタグの最適化は即効性が高く、titleタグの変更後1〜2週間で順位変動が観測されました。一方、構造化データやCore Web Vitalsの改善は、効果の発現に1〜2ヶ月かかる傾向がありました。
まとめ
SEO内部対策は、サイト構造、内部リンク、メタタグ、構造化データ、ページ速度、モバイル対応の6つの領域で構成されています。本記事では各領域のBefore/Afterコード例を示しながら、実装の具体的な方法を解説しました。
内部対策の最大の利点は、自社だけで完結できることです。外部対策のように第三者の意思決定に依存せず、実装した施策の効果を直接的に計測できます。scale-basics.comの実測データが示すように、内部対策のみでも主要キーワードの平均順位を18.4ポジション改善し、オーガニックトラフィックを約2.8倍に増加させることが可能です。
ただし、すべての施策を一度に実装しようとする必要はありません。本記事の総合チェックリストを活用し、まず優先度「高」の項目から着手してください。具体的には、以下の順序での取り組みを推奨します。
ステップ1として、サイト構造の整理(URL設計、ディレクトリ構造)を行います。これが他のすべての施策の土台になるためです。ステップ2として、メタタグの最適化(title、meta description、canonical)を実施します。最も着手しやすく、即効性があります。ステップ3として、内部リンクの体系的な設計を行います。ピラー&クラスターモデルを導入し、コンテンツ間の関係性を明確にします。ステップ4として、Core Web Vitalsの改善に取り組みます。技術的な難易度は高いですが、ユーザー体験の向上につながります。ステップ5として、構造化データを実装し、リッチリザルトの獲得を目指します。最後にステップ6として、robots.txtとsitemap.xmlを最適化し、クロール効率を最大化します。
各領域のさらに詳しい実装方法は、以下の関連記事で解説しています。
- テクニカルSEOの全体像 — 技術面からの内部対策を網羅的に解説
- 内部リンク戦略の詳細 — 内部リンクの設計・運用ノウハウを深掘り
- robots.txtの詳しい書き方 — クロール制御の実践的なガイド
- テクニカルSEO入門 — テクニカルSEOの基礎知識を初心者向けに解説
- SEOに強いコーディング実践ガイド — HTMLコーディングのSEO最適化
- 構造化データマークアップの実装手順 — JSON-LDの詳細な実装方法
- SEO HTMLタグ一覧 — SEOに関連するHTMLタグの完全リファレンス
SEO内部対策は一度実装して終わりではなく、サイトの成長に合わせて継続的に改善していくものです。月次でチェックリストを見直し、Google Search Consoleのデータをモニタリングしながら、PDCAサイクルを回し続けてください。本記事が、あなたのサイトの内部対策の出発点となれば幸いです。