オンページSEO：定義、チェックリスト、検証

オンページSEOとは？

オンページSEOは、個々のウェブページのコンテンツ、HTML、ユーザー体験を最適化し、それが明確でインデックス可能かつ特定の クエリ。ページ上の可視テキストや画像、メタ要素、構造化データ、カノニカル、内部リンク、そしてページのパフォーマンスなど、これらは 検索エンジン とユーザーがページをどう認識するかに影響します。

オンページSEOがSEOにとって重要な理由

オンページSEOは、検索エンジンがページが関連性がありインデックスすべきか判断する際のシグナルを形成します。クエリの関連性を高め、rich results、snippets、AI Overviews といった構造化機能が主要な事実を認識するのを助け、ユーザーの摩擦を減らします。クロール、インデックス、ランキングの違いに注意してください：オンページの作業はクロール性とインデックス可能性に直接影響しますが、ランキングはオンページの関連性とサイトの権威など複数のシグナルが組み合わさった結果です。

オンページSEOの仕組み

検索エンジンはまずクロールでページを発見し、次にインデックスで保存の可否や方法を決め、最後にランキングで結果の順序を決定します。オンページSEOは各段階にそれぞれ異なる方法で影響します：

• Crawling: clear internal links, sitemaps and reachable HTML help crawlers fetch the page. Since July 2024 Googlebot Smartphone is the default crawler, so the mobile-rendered HTML is the primary basis for クロールとインデックス。

• Indexing: meta robots, canonical tags and the rendered content determine whether and how a page is stored. An indexable page with useful structured data is more likely to be eligible for SERP features.

• Ranking: on-page relevance signals (content quality, headings, query intent match) combine with off-page signals (backlinks, site authority) and user-experience metrics (Core Web Vitals) によって順位に影響します。オンページの修正は関連性とリッチ表示の対象資格を高めますが、それだけで順位上昇を保証するものではありません—ランキングは多くのシグナルで決まります。

オンページSEOの種類

コンテンツとインテント

コンテンツはユーザーのインテントに合わせ、よくある質問に答え、明確な見出しを使い、独自で有益な情報を盛り込みましょう。シグナルにはトピックの深さ、セマンティックな網羅性、必要に応じた新鮮さなどが含まれます。

HTML とメタデータ

タイトルタグ、meta descriptions、H1/H2 構造、canonical リンク、hreflang（多言語対応）がインデックス化と表示を導きます。Example canonical syntax: <link rel="canonical" href="https://example.com/page">.

構造化データと rich results

Schema.org のマークアップは、検索エンジンがリッチリザルトやAI Overviews用の事実を抽出するのを助けます。Rich Results Test と Schema Markup バリデータで有効性を確認してください。構造化データはリッチリザルトを保証するものではありませんが、該当する機能の対象になる資格を与えます。

パフォーマンスと UX

Core Web Vitals (LCP, INP, CLS) と一般的な page speed は使いやすさやエクスペリエンスに関連するランキング調整の対象資格に影響します。Lighthouse、PageSpeed Insights、Chrome DevTools を使ってラボ指標とフィールド値を計測してください。

オンページSEOの始め方

まずは優先度の高い少数のページから始め、再現可能なチェックリストに従いましょう：ユーザーインテントをマップし、既存コンテンツを監査し、メタデータを標準化してインデックス可能性を確認します。既にトラフィックを集めているページやコアビジネスに関するページを優先しましょう。

モバイルコンテンツの提供方法（いずれかを選び、内容の整合性を保つ）:

• Responsive design — 同じHTMLでCSSが適応する方式。一般的に保守が最も簡単です。利点: 単一のURLと一貫したHTML。欠点: CSS/JSのパフォーマンス調整を慎重に行う必要があります。

• Dynamic serving — サーバーがデバイスごとに異なるHTML/CSSを返す方式。利点: デバイスに合わせたマークアップ。欠点: 保守負荷が高く、クローラーとユーザーに異なるコンテンツを出す（クロークのリスク）ことを避けなければいけません。

• Separate mobile URLs (m.example.com) — 利点: デバイスごとに完全な制御が可能。欠点: canonical/hreflang の複雑さが増し、整合性の誤りが起きやすくなります。

検証とトラブルシューティング：ツールと手順

URLとインデックスのチェック（自分が管理するページ）

使用してください Google Search Console の URL Inspection を使って、管理するページのインデックス状況とカバレッジデータを確認してください。URL Inspection はクロールやインデックス、手動対策のメモを表示し、あなたのプロパティに対して権威ある情報を提供します。パフォーマンス指標は Search Console の Core Web Vitals レポートや PageSpeed Insights（ラボデータ）を使用してください。

レンダリングされたHTMLとデバイス表示

ページをChromeで開き、DevTools > Elements でレンダリング済みのDOMを確認し、DevTools > Network でリソースのタイミングを見る。サーバーの生の応答を取得するには curl を使います（例: curl -L -A "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/" https://example.com/page） — HTML本文が必要なら -I を省略し、ヘッダーのみなら -I を使用してください。クローラーを偽装して別コンテンツを出す理由付けにテストを使うことは避けてください。クロークしないこと。

構造化データと rich results

JSON-LD や Microdata は Rich Results Test と Schema Markup Validator (schema.org) で検証してください。これらのツールはパースエラーやページが対象になる結果タイプを報告します。検証に合格することで対象資格は高まりますが、リッチスニペットを保証するものではありません。

外部サイトのページの外部検証

外部のパブリッシャーがページをどのように表示しているかを確認する必要がある場合（埋め込みの言及や内部リンクのチェックなど）、パブリッシャーのURLで curl や view-source を使い、ブラウザでレンダリングされたDOMを確認してください。site: 演算子は Google がページを認識している公的な指標として使えますが、インデックスの確証ではなく不完全なシグナルと見なしてください。ドメイン全体のクロールカバレッジに関する指標は、Bing Webmaster Tools Site Explorer はドメインの外部可視性に関する追加データを提供します。

実用的なチェックリスト

Mobile rendering parity（モバイルレンダリングの整合性） — 検証場所: Chrome DevTools と curl -A "(mobile UA)" — 合格条件: モバイルでレンダリングされたHTMLがデスクトップと同じ重要コンテンツと構造化データを含むこと。

Canonical の正当性 — 検証場所: view-source とヘッダーチェック（curl -I） — 合格条件: 単一の canonical が存在し、意図した正規URLにリダイレクトループなしで解決されること。

メタと見出し — 検証場所: ページソースとレンダリング済みDOM — 合格条件: title、meta description、H1/H2 構造がページの意図を反映し、重要ページ間でユニークであること。

構造化データの有効性 — 検証場所: Rich Results Test と Schema Markup Validator — 合格条件: 重大なエラーがなく、想定する結果タイプが対象として報告されること。

Core Web Vitals — 検証場所: PageSpeed Insights と Search Console の Core Web Vitals — 合格条件: フィールドとラボの指標が LCP、INP、CLS の推奨閾値を満たすこと。

インデックス可能性 — 検証場所: Google Search Console の URL Inspection（自社ページ）および curl + site: チェック（サードパーティ） — 合格条件: URL がクロール可能で robots によってブロックされておらず、権威あるインスペクションでインデックス済みとして表示されること。

Technical SEO ガイドを読む

よくあるオンページSEOのミス

• Content dilution（コンテンツ希薄化）: 多数のページにわたる薄いまたは重複したコンテンツは関連性を低下させます。低価値な重複は統合するか canonical 指定してください。

• モバイル・デスクトップの整合性エラー: Google がモバイルレンダリングを主要なインデックス基準として使う場合に、モバイルで重要なコンテンツを隠すとシグナルが欠落する可能性があります。

• 不適切な canonical や meta robots により、意図せずインデックスをブロックしたり誤ったバージョンを指してしまうこと。

• 構造化データの破損や、マークアップだけに頼って情報を露出させようとすること。構造化データはページの内容を正確に反映している必要があります。

• ユーザー向けに明確な回答を提供する代わりに、ボット向けのキーワード詰めや不自然なコンテンツを優先すること。これはUXと長期的な関連性の両方を損ないます。

よくある質問

Q: オンページSEOは順位を直接変えますか？ A: オンページの対策は関連性、インデックス可能性、SERP機能の対象資格を改善します。ランキングの結果はオンページシグナルとオフページの権威など他の要因を組み合わせたもので、変更が即座に順位向上をもたらすとは限りません。

Q: どのようにmobile-first indexingがオンページSEOに影響しますか？ A: Google はモバイル版をクロールとインデックスの主要な基準として使用するため、モバイルでレンダリングされたHTMLがデスクトップと同等の重要コンテンツと構造化データを含んでいることを確認してください。

Q: 構造化データはリッチリザルトを保証しますか？ A: いいえ。構造化データは特定のリッチ機能の対象資格を与えますが、表示するかどうかはGoogleがアルゴリズムで決定します。

Q: 自分のページについてGoogleが何をインデックスしているかはどう確認しますか？ A: 自分で所有するページについては Google Search Console の URL Inspection を使ってクロールとインデックスの詳細を確認してください。外部ページについては curl/view-source や site: のような公開シグナルを参考指標として使ってください。

Technical SEO はオーガニック成長の一部です。トピックに関するオーソリティを構築するには、関連する backlinks や編集的言及も必要です。掲載のオプションを探せる場所をお探しなら、高品質な backlinks でオーソリティを築く