言語

技術的SEOチェックリスト

クロール可能性、インデックス、Core Web Vitals、構造化データ、サイトマップ、robots.txt、正規化、HTTPS、モバイルSEOを網羅した包括的な技術的SEOチェックリスト。優先度とサイトタイプ別に整理されています。

初回公開：2026年6月27日 · 最終更新：2026年8月20日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

技術的SEOチェックリストは、検索エンジンとAI回答エンジンがページをクロール、レンダリング、インデックス、配信するためにサイトが満たすべき技術的条件を確認します。Googleの4つの重要な条件は、クロール可能、インデックス可能、理解可能、レンダリング可能です。これは技術的な部分のみに焦点を当てたもので、サイト全体の完全版はSEO監査チェックリストにあります。優先順位（クロール可能性、インデックス、HTTPS、モバイル同等性、サイトマップ、構造化データ、Core Web Vitals）に従って進め、サイトタイプごとにセクション全体をゲートします。ほとんどの小規模サイトはクロール予算の設計を完全にスキップできます。これはGoogleのドキュメントでも確認されています。すぐに否定すべき2つの誤解：robots.txtはページをインデックスから削除しない、構造化データはランキング要因ではない。チェックリストを満たすことは必要ですが十分ではありません。Googleはインデックスがまだ保証されていないと述べています。

TL;DR — 技術的SEOは上限ではなく下限です。ページは、コンテンツ作業が実を結ぶ前に、クロール可能 → インデックス可能 → 理解可能 → レンダリング可能である必要があります。チェックリストを優先順位に従って実行し、サイトタイプごとにセクションをゲートしてください。ほとんどの小規模サイトは、クロールバジェット、ファセットナビゲーション制御、ログ分析、JSレンダリングエンジニアリングをスキップできます。これはGoogle自身のクロールバジェットに関するドキュメントで確認されています。2つの誤解はすぐに打ち破りましょう：robots.txt はインデックスを削除せず、構造化データはランキング要因ではありません。Core Web Vitalsは合格/不合格のゲートではなく、目標として扱ってください。それがGoogle自身の「目指す」という表現です。そして、すべての項目を満たしても、インデックスが保証されるわけではありません。

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: Google Search Essentials: Technical requirements

メンタルモデル：4つの条件

Googleは技術的SEO全体を、ページがクロール可能、インデックス可能、理解可能、レンダリング可能であるという4つの負荷条件を中心に構成しています。Search Essentialsの技術要件では、これを3つの最小要件にまとめています：“Googlebot isn’t blocked,” (日本語訳) 「Googlebotがブロックされていない」、“The page works” (日本語訳) 「ページが機能する」（HTTP 200ステータスで配信される）、そして*“The page has indexable content.”* (日本語訳) 「ページにインデックス可能なコンテンツがある」。このチェックリストのすべては、実際にはこれらに奉仕するものです。

同じドキュメントからの重要な注意点：“Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” (日本語訳) 「ページがこれらの要件を満たしているからといって、ページがインデックスされるとは限りません。インデックスは保証されていません。」 技術的SEOは通過しなければならないゲートであり、結果を保証するレバーではありません。これが、私が常に技術的チェックリストは下限であると主張してきた理由です。コンテンツとリンクがその役割を果たせるようにクリアするものであり、それらの代わりになるものではありません。

始める前に：どのセクションがあなたに該当しますか？

競合するすべてのチェックリストはトピックごとに整理され、すべてのサイトで全体を実行します。それは間違ったデフォルトです。より良い整理軸はサイトタイプです。なぜなら、Google自身が最も高度なガイダンスをサイト規模で制限しているからです。大規模サイトのクロール予算ガイドより：“If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (日本語訳) 「サイトに急速に変化するページが多数ない場合、またはページが公開された当日にクロールされているように見える場合は、このガイドを読む必要はありません。」

クロール予算が重要になり始めるGoogle自身の（意図的に大まかな）閾値：

  • 大規模サイト — 百万以上のユニークページがあり、コンテンツが約毎週変化する。
  • 中規模以上のサイト — 10 000以上のユニークページがあり、非常に急速に変化する（毎日の）コンテンツがある。
  • Search Consoleの*「発見済み - 現在インデックスされていません」*状態に多くのURLが滞留しているサイト。

そこで、私が実際に実行する分割は次のとおりです：

スタータートラック — 小規模 / パンフレット / ローカルビジネスサイト（< ~10K URLs）： クロール可能性の健全性チェック、インデックス可能性/正規化の健全性チェック、HTTPS、モバイル同等性、1つのXMLサイトマップ、1回のCore Web Vitals、リッチリザルトを得られる場所での有効な構造化データ。クロール予算、ファセットナビゲーション制御、ログファイル分析、JSレンダリングエンジニアリングは完全にスキップします。

アドバンストラック — 大規模 / Eコマース / JS多用 / エンタープライズサイト： スタータートラックのすべてに加えて、クロール予算管理、ファセットナビゲーション制御、JavaScriptレンダリング監査、サーバーログ分析、および（国際的な場合）hreflang。

1. クロール可能性

  • robots.txtの正確性。 インデックスしたいものをブロックしていないことを確認します。Google：“A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” (日本語訳) 「robots.txtファイルは、検索エンジンのクローラーにサイト上のどのURLにアクセスできるかを伝えます。これは主にサイトへのリクエスト過多を避けるために使用され、ウェブページをGoogleから除外するためのメカニズムではありません。」 ボットを低価値の領域（内部検索、無限のパラメータ組み合わせ）から遠ざけるために使用し、非インデックス化ツールとしては使用しないでください。これはrobots.txtの詳細ガイドが完全にカバーしている領域と同じです。
  • robots.txt + noindexの矛盾トラップ。 robots.txtでURLをブロックし、かつそのURLのnoindexに依存するのはやめてください。Google：“While Google won’t crawl or index the content blocked by a robots.txt file, we might still find and index a disallowed URL if it is linked from other places on the web.” (日本語訳) 「Googleはrobots.txtファイルでブロックされたコンテンツをクロールまたはインデックスしませんが、ウェブ上の他の場所からリンクされている場合、許可されていないURLを発見してインデックスする可能性があります。」 ボットはページをクロールできないため、noindexを認識できず、URLは結果に裸のまま表示される可能性があります。ページを削除するには：クロールを許可 + noindex、またはパスワードで保護します。
  • クロールエラー。 予期しない4xxおよび5xxを修正します。Googleは200で配信されるページのみをインデックスし、“Client and server error pages aren’t indexed.” (日本語訳) 「クライアントおよびサーバーエラーページはインデックスされません。」
  • リダイレクトチェーンとループ。 A→B→C→DをA→Dに短縮します。チェーンはクロールを浪費し、各ホップで少しリークします。クローリングとリダイレクトの資料はここでより深く掘り下げられます。
Evidence for this claim A robots.txt disallow controls crawling but is not a reliable mechanism for keeping a linked URL out of Google’s index. Scope: production output verified at URL, template and representative-sample level Confidence: high · Verified: Introduction to robots.txt

2. インデックス可能性

  • インデックスカバレッジ。 Search Consoleのページインデックスレポートで、インデックスさせたいページと実際にインデックスされているページを照合します。「検出済み - 現在インデックスされていない」の大きなバケットを調査します。
  • 正規化。 重複およびほぼ重複したURLを、優先する1つのバージョンにまとめます。Googleはrel="canonical"を*“a strong signal that the specified URL should become canonical”* (日本語訳) 「指定されたURLが正規になるべきであるという強いシグナル」と呼んでいます — これはシグナルであり、従わなければならない指示ではありません。そして重要なことに：“Don’t use the robots.txt file for canonicalization purposes.” (日本語訳) 「正規化の目的でrobots.txtファイルを使用しないでください。」 HTMLタグ、HTTPヘッダー、サイトマップ間で競合する正規化シグナルを送信していないか確認してください — 正規化の詳細ガイドでは、それらの統合方法を説明しています。
  • 重複コンテンツ。 パラメータ、印刷用バージョン、ステージング環境の漏洩、http/httpsおよびwww/非wwwの分割はすべて重複を生み出します。1つを選択し、残りを正規化またはリダイレクトします。

3. HTTPS

基本であり、オプションではありません。サイト全体をHTTPSで配信し、httpをhttpsにリダイレクトし、混合コンテンツ（セキュアなページが非セキュアな画像、スクリプト、またはスタイルシートを読み込むこと）を探し出します。Chris GreenのSEO in 2026の現実チェックでは、HTTPSの採用率は*“91%+”* (日本語訳) 「91%以上」とされています — あなたは残りの9%に含まれたくはないはずです。

4. モバイルSEO

Googleはモバイルファーストインデックスを使用しています：“Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” (日本語訳) 「Googleは、スマートフォンエージェントでクロールされたサイトのモバイル版をインデックスとランキングに使用します。」 パリティチェックリストは、Googleのモバイルファーストに関するドキュメントから直接引用しています：

  • “Make sure that your mobile site contains the same content as your desktop site.” (日本語訳) 「モバイルサイトにデスクトップサイトと同じコンテンツが含まれていることを確認してください。」
  • “Make sure that the title element and the meta description are equivalent across both versions of your site.” (日本語訳) 「タイトル要素とメタディスクリプションがサイトの両バージョンで同等であることを確認してください。」
  • “Make sure that your mobile and desktop sites have the same structured data.” (日本語訳) 「モバイルサイトとデスクトップサイトが同じ構造化データを持つことを確認してください。」
  • “Use the same robots meta tags on the mobile and desktop site.” (日本語訳) 「モバイルサイトとデスクトップサイトで同じrobotsメタタグを使用してください。」
  • “Don’t lazy-load primary content upon user interaction.” (日本語訳) 「ユーザーの操作時にプライマリコンテンツを遅延読み込みしないでください。」
  • “Make sure that the mobile site has the same alt text for images as the desktop site.” (日本語訳) 「モバイルサイトがデスクトップサイトと同じ画像のaltテキストを持つことを確認してください。」

最も一般的な失敗は、デスクトップに存在するコンテンツ、リンク、または構造化データを静かに削除する簡素化されたモバイルテンプレートです — Googleはより薄いバージョンをインデックスします。

5. サイトマップとディスカバリ

  • XMLサイトマップの衛生管理。 絶対URLと正規URLを使用し、ファイルごとの50 MB / 50 000 URLの制限内に収め、インデックス可能で正規のURLのみをリストし、lastmodを正確に保ちます。robots.txtでそれを参照し（Sitemap: https://example.com/sitemap.xml）、エンジンが自動的に発見できるようにします。詳細な説明はXMLサイトマップの資料にあります。
  • Bingも依然として重要です。 Bingの2025年7月のガイダンスから：“Sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site,” (日本語訳) 「サイトマップは、サイト全体の包括的なURLカバレッジを確保するための基礎的なシグナルであり続けます。」、“XML remains the preferred format for sitemaps,” (日本語訳) 「XMLはサイトマップの推奨形式であり続けます。」、そして*“The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.”* (日本語訳) 「サイトマップのlastmodフィールドは主要なシグナルであり続け、Bingが再クロールするURLを優先するのに役立ちます。」
  • IndexNow。 ほとんどのGoogle中心のチェックリストでは省略されていますが、これはライブで無料の一行の勝利です：Bingのアドバイスは、コンテンツが変更されたときに*“Use IndexNow for real-time URL submission, instantly notifying Bing and participating search engines”* (日本語訳) 「リアルタイムのURL送信にIndexNowを使用し、Bingと参加している検索エンジンに即座に通知する」ことです。これはサイトマップを置き換えるのではなく補完します。（注：Googleは一般的なページにIndexNowを使用していません。）

6. 構造化データ

  • 機能: リッチリザルトの対象資格を獲得し、機械（およびLLM）がページを理解するのを助けます。“Adding structured data can enable search results that are more engaging to users… which are called rich results.” (日本語訳) 「構造化データを追加すると、ユーザーにとってより魅力的な検索結果を表示できるようになります…これらはリッチリザルトと呼ばれます。」
  • 機能しないこと: ランキングを向上させること。Googleのドキュメントでは、スキーマは厳密にリッチリザルトの対象資格と機械の理解のためのものとして位置づけられており、ランキングシグナルではありません。ランキング対策として販売したり、予算を組んだりしないでください。
  • 形式: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” (日本語訳) 「一般的に、Googleはサイトの設定が許せば、構造化データにJSON-LDを使用することを推奨しています。これはウェブサイト運営者が大規模に実装・維持するのに最も簡単なソリューションだからです。」 リッチリザルトテストで検証してください。構造化データの資料では、実装する価値のある具体的なタイプを扱っています。

7. コアウェブバイタルとページエクスペリエンス

目標であり、ゲートではない — Googleの実際の表現は*“strive to,”* (日本語訳) 「目指す」であり、ほとんどのチェックリストはこれを厳格な合格/不合格の基準として誇張しています:

  • LCP — “strive to have LCP occur within the first 2.5 seconds of the page starting to load.” (日本語訳) 「ページの読み込み開始から最初の2.5秒以内にLCPが発生することを目指す。」
  • INP — “strive to have an INP of less than 200 milliseconds.” (日本語訳) 「INPが200ミリ秒未満であることを目指す。」
  • CLS — “strive to have a CLS score of less than 0.1.” (日本語訳) 「CLSスコアが0.1未満であることを目指す。」

そして、人々が過大評価しているランキングとの関係: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (日本語訳) 「Google検索は、ページエクスペリエンスが標準以下であっても、常に最も関連性の高いコンテンツを表示しようとします。」 優れたコアウェブバイタルは、関連性のある結果間のタイブレーカーであり、関連性を覆すものではありません。ラボのスコアだけでなく、実際のユーザーデータ（CrUX/フィールドデータ）で測定してください。

8. 高度な追加（大規模サイト / Eコマース / JS多用サイトのみ）

  • クロール予算。 上記のGoogleのしきい値をクリアした場合のみ。容量と需要。予算を増やすには、Googleに「もっと」クロールさせようとするよりも、無駄を排除する（パラメータの爆発、ファセットナビゲーションの組み合わせ、スパイダートラップ、重複URL）ことの方がはるかに効果的です。クロール予算の詳細を参照してください。
  • JavaScriptレンダリング。 重要なコンテンツとリンクがレンダリングされたHTMLに存在し、クリックのみのナビゲーションではなく、実際の<a href>リンクを介して到達可能であることを確認してください。これはJavaScript SEOの領域です。
  • ファセットナビゲーションの制御。 どのフィルター/並べ替えの組み合わせをクロール可能/インデックス可能にするかを決定し、残りを制御します。
  • ログファイル分析。 ボットが実際に何を、どのくらいの頻度で取得し、どのステータスコードに遭遇するかについての真実の情報源。
  • hreflang — 本当に多地域/多言語の場合のみ。これは十分に大きなトピックであり、独自の国際SEO資料で扱うべきです。中途半端に付け加えないでください。

9. AI / LLMクローラーアクセス（短く、範囲を限定）

2026年の必須項目は2つだけです。それ以上はありません。深いGEO/AEOの作業はAI検索の資料にあり、ここではありません:

  • robots.txtでAIクローラーのアクセスを決定する。 関心のあるAIユーザーエージェント（トレーニング用、AI検索用、ユーザー起動型フェッチャーは異なるボットです）を明示的に許可または拒否します。クリス・グリーンのフレーミング: “Robots.txt is no longer just crawl housekeeping. It’s becoming a policy surface.” (日本語訳) 「Robots.txtはもはや単なるクロールのハウスキーピングではありません。ポリシーサーフェスになりつつあります。」
  • 構造化データはLLMの機械コンテキストを兼ねる — スキーマを有効にするための追加の理由であり、新しいワークストリームではありません。

10. 見つけたものの優先順位付け方法

ここでほとんどのチェックリストは失敗します: 重み付けなしで90項目を渡すだけです。すべてを修正しないでください — 効果のあるものを修正してください。私の友人のパトリックがクライアント監査についてアドバイスしてくれたことで、私が何度も思い返すこと: “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” (日本語訳) 「クライアントが監査を求めて来るなら、彼らはすでに悩みを抱えています。彼らと話してください。その1つを解決すれば、彼らは監査に満足するでしょう。」 同じSEO監査テンプレートでは、“sweating the small stuff rarely does much for your rankings” (日本語訳) 「小さなことにこだわってもランキングにはほとんど効果がない」と述べられており、“80% of your time fixing the 20% of things that matter.” (日本語訳) 「重要度の高い20%の修正に時間の80%を費やす」方が良いとされています。

そして、全体の演習を俯瞰してください: チェックリストはまあまあの状態に到達させます。Googleのジョン・ミューラーは、基本だけでは良いが素晴らしいとは言えない結果しか得られないと繰り返し指摘しています。本当の優位性は、トピックの深さと権威から生まれます。技術的なチェックボックスをすべてチェックすることからではありません。チェックリストは床を掃除し、コンテンツとリンクが家を建てます。

全サイト版をご希望ですか？

このページは意図的に技術面のみに特化しています。より広範な監査（技術面プラス オンページ、コンテンツ、オフページ）をご希望の場合は、SEO監査チェックリストという別の、より広範なものをご覧ください。この1ページに両方の役割を持たせようとしないでください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.