テクニカルSEOとは

テクニカルSEOとは、検索エンジンがウェブサイトを効率的にクロールインデックスし、適切に評価できるよう技術的な基盤を最適化する取り組みです。どれだけ優れたコンテンツを作成しても、技術的な問題があれば検索エンジンに正しく認識されず、SERPに表示されません。

テクニカルSEOは「サイトの土台」です。コンテンツSEOが「家の内装」だとすれば、テクニカルSEOは「基礎工事」に相当します。基礎がしっかりしていなければ、どれだけ内装に力を入れても意味がありません。

京谷商会では18のポータルサイトを運営しており、すべてのポータルでテクニカルSEOの基盤整備を最優先事項として取り組んでいます。その結果、全ポータルでPageSpeed Insightsの全項目100点を達成しました。

テクニカルSEOが重要な理由

  • クロール効率の向上: Googlebotのクロールバジェットは有限であり、無駄なクロールを減らすことで重要なページの発見速度が上がる
  • インデックス精度の向上: 正しいページが正しい形でインデックスされることで、検索結果での表示品質が向上する
  • ユーザー体験の改善: 表示速度やモバイル対応はユーザー満足度に直結し、間接的にランキングにも影響する
  • 競合優位性の確保: コンテンツ品質が同程度の場合、技術的に優れたサイトが上位に表示される傾向がある
  • AI Overview時代への対応: Googleの検索結果にAIによる要約が表示される時代、構造化データの正確な実装がAI要約への引用に直結する

クロール最適化

robots.txtの適切な設定

robots.txtはサイトのルートディレクトリに配置するテキストファイルで、クローラーのアクセスを制御します。

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /tmp/

Sitemap: https://example.com/sitemap.xml

重要なポイントは以下の通りです。

  • Disallowはクロールを制御するもので、インデックスを制御するものではない: robots.txtでブロックしたページも、外部リンクがあればインデックスされる場合がある。これはGoogleのrobots.txt仕様書にも明記されている
  • 重要なリソースをブロックしない: CSS、JavaScript、画像などのリソースをブロックすると、Googlebotがページを正しくレンダリングできなくなる
  • サイトマップのURLを記載する: robots.txtにサイトマップの場所を明記することで、クローラーの発見効率が上がる
  • クロールディレイの検討: 小規模サーバーではCrawl-delayディレクティブでクロール頻度を制限することも有効だが、Googlebotはこのディレクティブを無視する点に注意

XMLサイトマップの最適化

XMLサイトマップは、サイト上の重要なページをクローラーに伝えるファイルです。

<?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-04-01</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
</urlset>

効果的なサイトマップの条件は次の通りです。

  • URLは50,000件以下、ファイルサイズは50MB以下に収める
  • 200ステータスを返すURLのみを含める(リダイレクトやエラーページは除外)
  • lastmodは実際にコンテンツが更新された日付を正確に記載する(Googleのサイトマップ作成ガイドラインでは、lastmodの不正確な値はサイトマップの信頼性を損なうと警告している)
  • 大規模サイトではサイトマップインデックスを使って分割する

クロールバジェットの管理

クロールバジェットとは、Googlebotが一定期間内にサイトをクロールする回数の上限です。大規模サイト(数万ページ以上)では特に意識する必要があります。

クロールバジェットを効率的に使うためのポイントは以下の通りです。

  • 重複コンテンツの排除: canonicalタグやリダイレクトで重複を解消する
  • パラメータ付きURLの制御: 不要なパラメータバリエーションをrobots.txtでブロックする
  • 404エラーの削減: リンク切れを定期的にチェックし、適切にリダイレクトする。詳しい手順はSearch Consoleインデックス問題の完全対処ガイドを参照
  • サーバーレスポンスの高速化: レスポンスが遅いとクロール頻度が低下する

サーバーログ分析によるクロール把握

Google Search Consoleのクロール統計レポートに加え、サーバーのアクセスログを直接分析することで、Googlebotの実際の挙動をより詳細に把握できます。

  • クロール頻度の把握: どのディレクトリが頻繁にクロールされ、どこが放置されているかをログから確認する
  • ステータスコード別の分析: 5xxエラーや3xxリダイレクトの発生頻度を特定し、クロールバジェットの浪費箇所を発見する
  • レンダリングリクエストの確認: GooglebotがCSS・JS・画像などのリソースをどの程度取得しているかで、レンダリングの完全性を推測する

京谷商会ではCloudflare Workersのログを活用し、Googlebotのクロールパターンを月次で分析しています。この分析から、新規公開記事が平均3〜5日以内にクロールされていることを確認しており、サイトマップの即時更新がクロール速度に寄与していることがデータで裏付けられています。

インデックス制御

canonicalタグの正しい使い方

canonicalタグは、重複コンテンツの「正規版」を検索エンジンに伝えるためのHTMLタグです。GoogleのURL正規化に関する公式ドキュメントで詳しく解説されています。

<link rel="canonical" href="https://example.com/page/" />

よくある誤りとして、以下に注意が必要です。

  • 自己参照canonicalを設定する: 全ページに自身のURLをcanonicalとして指定する(これは推奨される正しい運用)
  • 相対URLではなく絶対URLを使う: パスの解釈ミスを防ぐため
  • canonicalとnoindexを併用しない: 矛盾するシグナルを送ることになる
  • リダイレクト先のURLを指定する: リダイレクトチェーンを避ける
  • HTTPとHTTPSの混在に注意: canonicalは必ずHTTPS版のURLを指定する

noindex/nofollowの適切な運用

metaロボットタグを使って、ページ単位でインデックスやリンクの追跡を制御できます。

<meta name="robots" content="noindex, follow" />

noindexを使うべき場面は次の通りです。

  • 検索結果に表示する価値のない管理画面やサンクスページ
  • 重複コンテンツでcanonicalでは対応しきれないケース
  • テスト環境や開発中のページ
  • 薄いタグページやパラメータ付きの絞り込みページ

なお、noindexの設定状況はGoogle Search Consoleの「ページ」レポートで確認できます。意図せずnoindexが設定されているケースは意外と多く、定期監査で発見しやすい問題です。対処方法はSearch Consoleインデックス問題の完全対処ガイドで詳しくまとめています。

hreflangタグ(多言語対応)

多言語サイトや多地域サイトでは、hreflangタグで言語・地域ごとの対応ページを明示します。

<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

hreflangの実装で陥りがちなミスとして、双方向の指定漏れがあります。日本語ページから英語ページへのhreflangを指定したら、英語ページからも日本語ページへ指定する必要があります。片方だけの指定ではGoogleに無視される可能性があります。

Core Web Vitals

Core Web Vitalsは、Googleが定めるユーザー体験の主要指標です。2026年現在、以下の3指標が評価対象です。Googleのページエクスペリエンスに関する公式ドキュメントで、これらがランキングシグナルとしてどのように使われるかが説明されています。

LCP(Largest Contentful Paint)

ページのメインコンテンツが表示されるまでの時間を測定します。目標値は2.5秒以内です。

改善策としては、画像の最適化(WebP/AVIF形式への変換、適切なサイズ指定)、サーバーレスポンスの高速化(CDN導入、キャッシュ最適化)、レンダリングブロックリソースの排除(CSS/JSの遅延読み込み)が有効です。

特に効果が大きいのは画像のプリロードです。LCPの対象がヒーロー画像である場合、<link rel="preload" as="image" href="hero.webp">をhead内に追加することで、画像の取得開始が早まりLCPが大幅に改善されるケースがあります。

INP(Interaction to Next Paint)

ユーザーの操作からブラウザの応答(次の描画)までの時間を測定します。目標値は200ミリ秒以内です。

INPは2024年3月にFID(First Input Delay)に代わって導入された指標です。FIDが「最初の操作の遅延」だけを測定していたのに対し、INPはページ上のすべてのインタラクションを対象にし、最も遅い応答を代表値とします。そのため、FID時代に「良好」と評価されていたサイトでも、INPでは基準を満たさないケースが少なくありません。

改善策としては以下が有効です。

  • 長時間実行されるJavaScriptの分割: 50ミリ秒を超えるタスクをrequestIdleCallbackscheduler.yield()で分割する
  • メインスレッドのブロック回避: 重い計算処理はWeb Workerに移譲する
  • イベントハンドラの最適化: 不要なリフローやリペイントを引き起こすDOM操作を最小限にする
  • サードパーティスクリプトの遅延読み込み: 広告やアナリティクスのスクリプトはページの操作可能状態に影響しやすい

web.devのINP最適化ガイドに、具体的な改善手法とデバッグ方法が詳しく掲載されています。

CLS(Cumulative Layout Shift)

ページ読み込み中に発生するレイアウトのずれを測定します。目標値は0.1以下です。

改善策としては、画像や動画にwidth/height属性を明示する、Webフォントの読み込み中にフォールバックフォントを表示する(font-display: swap)、動的コンテンツの挿入位置を事前に確保するなどが効果的です。

2026年のトレンドとして、CSS content-visibility: auto の活用があります。ビューポート外のコンテンツのレンダリングを遅延させることで、初期レイアウトの安定性とページのレンダリング速度を同時に改善できます。ただし、遅延レンダリングされる要素の高さをcontain-intrinsic-sizeで事前に指定しないと、逆にCLSが悪化するため注意が必要です。

京谷商会では全ポータルでCore Web Vitalsの3指標すべてを「良好」にしています。具体的な改善プロセスはPageSpeed Insights全項目100点を達成した方法で実践レポートとして公開しています。自サイトの現在のスコアを把握するには、PageSpeed診断ツールでURLを入力して確認するところから始めましょう。

構造化データの実装

構造化データ(Schema.org)は、ページの内容を検索エンジンに機械可読な形式で伝える仕組みです。リッチリザルト(リッチスニペット)の表示に繋がり、クリック率の向上が期待できます。構造化データの詳細な実装方法は構造化データ(Schema Markup)実装ガイドも参照してください。

JSON-LD形式での実装

Googleが推奨するのはJSON-LD形式です。Googleの構造化データの概要では、JSON-LDをHTMLのhead内に配置する方法が推奨されています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "テクニカルSEO完全入門ガイド",
  "author": {
    "@type": "Organization",
    "name": "京谷商会"
  },
  "datePublished": "2026-03-17",
  "dateModified": "2026-04-01"
}
</script>

パンくずリスト(BreadcrumbList)の実装

パンくずリストの構造化データは、検索結果にサイト階層を表示させる効果があり、実装が比較的容易でありながらSEO効果が高いため、最初に取り組むべき構造化データの一つです。

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

主要な構造化データタイプ

| タイプ | 用途 | リッチリザルト | |--||-| | Article | 記事・ブログ | 記事カルーセル | | FAQPage | よくある質問 | FAQ表示 | | HowTo | 手順解説 | ステップ表示 | | LocalBusiness | 店舗・事業所 | ナレッジパネル | | Product | 商品 | 価格・レビュー表示 | | BreadcrumbList | パンくずリスト | パンくず表示 |

商品ページの構造化データについては商品構造化データの実装ガイドで、JSON-LDの具体的な書き方からリッチリザルト獲得までの手順を解説しています。

構造化データの実装後は、Googleのリッチリザルトテストで検証することを推奨します。

HTTPS対応

2026年現在、HTTPSはSEOの必須要件です。HTTPのままのサイトはChromeで「保護されていない通信」と警告が表示され、ユーザーの離脱率が大幅に上昇します。

HTTPS対応のポイントは以下の通りです。

  • HTTPからHTTPSへの301リダイレクト: 全HTTPリクエストをHTTPSにリダイレクトする
  • 混在コンテンツの排除: HTTPS内のHTTPリソース読み込みを全て修正する
  • HSTSヘッダーの設定: Strict-Transport-SecurityヘッダーでHTTPS接続を強制する。HSTSプリロードリストへの登録も検討する
  • 証明書の自動更新: Let's EncryptやCloudflareの自動SSL証明書を活用する

京谷商会ではCloudflareの自動SSL/TLS証明書を全ポータルに適用し、HTTPSの管理コストをゼロにしています。HSTSヘッダーもCloudflare Workers経由で一括設定しており、セキュリティヘッダーの具体的な設定方法はSECポータルの記事を参照してください。

サイトアーキテクチャ

サイトアーキテクチャは、ページ間の階層構造とリンク構造を指します。適切なアーキテクチャは、クローラーの効率的な巡回とユーザーのスムーズな回遊を両立させます。トピッククラスター戦略と組み合わせることで、SEO効果を最大化できます。

フラットなURL構造

理想的なURL構造は、トップページから3クリック以内で全ページに到達できるフラットな構造です。

example.com/
├── /category-a/
│   ├── /category-a/article-1/
│   └── /category-a/article-2/
├── /category-b/
│   ├── /category-b/article-3/
│   └── /category-b/article-4/
└── /about/

URLの設計では、キーワードを含めつつ簡潔に保つことが重要です。日本語URLよりも英語のスラッグを推奨します。理由は、SNSやメールでの共有時にURLエンコードされて長大になることを避けるためです。

内部リンクの最適化

内部リンクは、サイト内のページ間でリンクジュース(PageRank)を分配する重要な手段です。詳しい設計手法は内部リンク設計の教科書を参照してください。

  • パンくずリストの実装: 階層構造を明示し、上位ページへのリンクを提供する
  • 関連記事リンクの設置: コンテンツの関連性に基づいたリンクで回遊率を向上させる
  • アンカーテキストの最適化: リンク先の内容を端的に表すテキストを使用する。「こちら」「詳細はこちら」のような汎用的なアンカーテキストは避ける
  • 孤立ページの排除: どこからもリンクされていないページがないか定期的にチェックする
  • ピラーコンテンツへの集約: トピッククラスター構造で、ピラーページとクラスター記事間の相互リンクを設計する

モバイルファーストインデックス

Googleはモバイルファーストインデックスを完全適用しており、モバイル版のページをインデックスの主軸としています。モバイル対応はもはや選択肢ではなく必須です。

  • レスポンシブデザインの採用: 1つのURLで全デバイスに対応するのがGoogleの推奨
  • タップターゲットのサイズ確保: ボタンやリンクは最低48px以上の領域を確保する
  • ビューポートメタタグの設定: <meta name="viewport" content="width=device-width, initial-scale=1">を必ず記載する
  • モバイルでのコンテンツ一致: デスクトップとモバイルで同じコンテンツを提供する
  • Lazy Loadingの適切な使用: ファーストビュー外の画像にloading="lazy"を設定する。ただしLCPの対象となる画像にはLazy Loadingを設定しないこと

テクニカルSEO監査チェックリスト

定期的に以下の項目を監査することで、技術的な問題を早期に発見・修正できます。Google Search Consoleの使い方と合わせて活用してください。

クロール関連

  • robots.txtが正しく設定されているか
  • XMLサイトマップが最新の状態か
  • クロールエラーがGoogle Search Consoleで発生していないか
  • リダイレクトチェーン(3回以上の連続リダイレクト)がないか

インデックス関連

  • 全ページにcanonicalタグが設定されているか
  • 不要なページにnoindexが設定されているか
  • インデックス数が想定通りか(site:検索で確認)
  • 重複コンテンツが発生していないか

パフォーマンス関連

  • Core Web Vitalsが全て「良好」の範囲か
  • HTTPS対応が完了しているか
  • 混在コンテンツがないか
  • サーバーエラー(5xx)が発生していないか

構造関連

  • 構造化データにエラーがないか
  • パンくずリストが正しく実装されているか
  • モバイルフレンドリーテストに合格しているか
  • 404ページがカスタマイズされているか

テクニカルSEOは一度設定すれば終わりではなく、サイトの成長とともに継続的に監査・改善を行うべき領域です。月に1回程度の定期監査を推奨します。京谷商会では、定期監査の結果をもとにSEO戦略レポートを更新し、改善の進捗を可視化しています。

参考資料

テクニカルSEOの公式リファレンスとして、以下のドキュメントが参考になります。