テクニカルSEO

TL;DR — テクニカルSEOとは、検索エンジンがあなたのページを 見つけ、読み、理解できるようにするための舞台裏の作業です。ランキングを上げるための トリックではなく、コンテンツとリンクがその役割を果たせるようにする土台です。 技術面が壊れていれば、優れたページでも表示されません。すべては 一文に集約されます：Googleがインデックスしないページはランク付けできません。 このガイドでは、 何に注意すべきか、自分のサイトをどう確認するか、そして安全に無視できるものを説明します。

テクニカルSEOとは実際には何か

SEOを学び始めたばかりの人は、コンテンツ（良いページを書くこと）と リンク（他のサイトに自分のサイトへリンクしてもらうこと）の2つを考えます。テクニカルSEOは 3つ目の柱であり、他の2つが重要になる前に来るものです。検索エンジンがあなたのページに 到達でき、正しく読み取り、インデックスに保存できるかどうかを決定するすべてのことが含まれます。

私のテクニカルSEOの初心者向けガイド では、 長年にわたり、検索エンジンがあなたのページを見つけ、クロールし、 理解し、インデックスできるようにする実践であると説明してきました。それが4つの動詞での仕事のすべてです。 含まれていないものに注目してください：素晴らしいコピーを書くこと、キーワードを選ぶこと、リンクを獲得すること。これらは 現実的で重要ですが、テクニカルSEOではありません。

私がいつも思い浮かべる例えは家です。コンテンツは家具とペンキです。 リンクはその場所を勧める隣人です。テクニカルSEOは配管と 配線です—目に見えず、地味で、壊れるとすべてを台無しにするものです。 誰も配管を褒めません。しかし、動かなくなったら確かに気づくものです。

すべてが動くパイプライン

Google検索はこのプロセスを3つの段階で説明しています。そのドキュメントは率直です： “Google Search works in three stages, and not all pages make it through each stage.” (翻訳) 「Google検索は3つの段階で機能し、すべてのページが各段階を通過するわけではありません。」 Evidence for this claim Google Search describes crawling, indexing, and serving as three stages; discovery is part of the crawling stage, and not every page advances through each stage. Scope: Google Search documentation; conceptual explanation, not a promise of ranking outcomes. Confidence: high · Verified: 2026-07-14 Google: How Search Works

1. クロール — ボット（Googleの場合はGooglebot、Bingの場合はBingbot）があなたのURLを発見し、 ページをダウンロードします。
2. インデックス — エンジンがページの内容を把握し、表示する可能性のあるすべてのものを 巨大なデータベースに保存します。
3. 配信（ランク付け） — 誰かが検索すると、エンジンはそのデータベースから最適な一致を 引き出し、順序を付けます。

その条項—すべてのページが各段階を通過するわけではない—がテクニカルSEOが存在する まさにその理由です。ページはクロールされてもインデックスされない場合や、インデックスされても クエリに対して表示されない場合があります。ほとんどのテクニカルSEOは、ページがこれらのゲートを 通過するのを妨げているものを取り除くことだけです。

なぜトリックではなく土台なのか

ここが人々を驚かせる部分です：テクニカルSEOは通常、ページのランキングを上げるものではありません。 「テクニカルSEOアルゴリズム」を攻略するものはありません。それが行うのは、障害物を取り除き、 あなたの良いコンテンツとリンクが実際に効果を発揮できるようにすることです。壊れた 正規化タグや遅いサーバーを修正してもポイントが加算されるわけではなく、失うのを防ぐだけです。

私は時々こう言います：テクニカルSEOは、そうでなくなるまでSEOの最も重要な部分です。 あなたのページがクロールされインデックスできるようになった瞬間、レバレッジはコンテンツとリンクに移り、 それらはほとんどの技術プロジェクトがこれまでに動かすよりもはるかにランキングを動かします。 ですから、目標は技術的な完璧さではなく、ゲートを通過させて、その後は自分の邪魔をしないことです。

すべてのサイトが必要とする基盤

驚くほど多くのテクニカルSEOを無視できます。しかし、すべてのサイトが 正しく行うべき短いリストがあります：

• クロールアクセス。 見つけてもらいたいページを誤ってブロックしていないか確認しましょう。 robots.txt ファイルは、ボットがリクエストできるURLを制御します。初心者がよく犯す 間違いは、それを使ってページを隠そうとすることです — それは本来の用途ではありません（詳細は神話のセクションで）。 Evidence for this claim A robots.txt rule controls crawling rather than guaranteeing removal from Google Search; a URL can still appear when Google cannot crawl it. Scope: Google Search crawler behavior. Other crawlers can interpret robots.txt differently. Confidence: high · Verified: 2026-07-14 Google: Introduction to robots.txt
• サイトマップ。 XMLサイトマップは、重要なURLのリストを検索エンジンに直接渡すものです。 Google Search Console と Bing Webmaster Tools で提出してください。大規模なサイトや新しいサイトで最も重要です。
• 各ページの明確なバージョン。 同じコンテンツが複数のURL（www の有無、http と https、トラッキングパラメータ）に存在する場合、検索エンジンにどれが正規（本当のもの）かを rel="canonical" タグで伝えます。これは正規化と呼ばれ、重複コンテンツについて初心者が知っておくべきことのほとんどです。
• HTTPS。 サイトを安全な接続で配信しましょう。これは小さなランキングシグナルであり、信頼の基本的な前提条件です。
• 適切な速度とモバイルフレンドリーなレイアウト。 Google はサイトのモバイル版をインデックスするため、スマートフォンで動作する必要があります。速度スコアにこだわりすぎないでください（神話を参照）— ただ、耐えられないほど遅くしないでください。

通常のサイトでは、これで本当にほとんどすべてです。クロール可能で、サイトマップがあり、ページごとに正規バージョンが1つあり、HTTPSで、モバイルで動作し、耐えられないほど遅くない。

自分のテクニカルSEOを確認する方法

高価なツールは必要ありません。検索エンジンが提供する無料のツールが真実の情報源です：

• Google Search Console → ページのインデックス登録レポート。 これにより、どのページがインデックス登録されているか、そして他のページがなぜされていないかがわかります。これはテクニカルSEOで最も有用な画面です。重要なページがインデックス登録されていない場合、ここで見つけることができます。
• URL検査ツール（Search Console にもあります）。任意のURLを貼り付けると、Google がそのページをどのようにクロール、レンダリング、インデックス登録したかを正確に教えてくれ、インデックス登録をリクエストすることもできます。
• Bing Webmaster Tools。 Bing の同等ツールで、設定する価値があります — そのインデックスは現在多くのAI回答に供給されているため、検索市場シェアが示す以上に重要です。

そこから始めましょう。重要なページがインデックス登録され、ページのインデックス登録レポートに驚きがなければ、テクニカルSEOはおそらく問題ありません。

テクニカルSEOがではないもの

多くの混乱は、すべてを「テクニカルSEO」に分類することから生じます。それは次のものではありません：

• コンテンツの品質やキーワード調査 — それはオンページSEOとコンテンツ戦略です。
• リンク構築 — それはオフページSEOです。
• タイトルタグとメタディスクリプションの作成 — それはオンページですが、境界線上にあります。

境界は実際に曖昧になることがあります — スキーママークアップ、内部リンク、ページ速度はすべてテクニカルとオンページの両方にまたがります。どのカテゴリに入るかを心配する必要はありません。ラベルは作業を完了することほど重要ではありません。

無視すべき一般的な神話

テクニカルSEOに熟達することの半分は、重要でないことに時間を浪費しないことです。主なものは次のとおりです：

• “Blocking a page in robots.txt removes it from Google.” (翻訳) 「robots.txt でページをブロックすると、Google から削除される。」 そんなことはありません。Google は、robots.txt は “is not a mechanism for keeping a web page out of Google.” (翻訳) 「Google からウェブページを除外する仕組みではない」と明確に述べています。ブロックされたページでも、他のサイトがリンクしていれば表示される可能性があります — Google はそのページの内容を見ることができないだけです。実際にページを削除するには、クロールを許可し、noindex タグを追加してください。
• “I need to worry about crawl budget.” (翻訳) 「クロール予算を気にする必要がある。」 ほぼ間違いなく、その必要はありません。ほとんどのサイトでは考える必要はなく、非常に大規模または急速に変化するサイトにのみ関係します。 Evidence for this claim Google says crawl-budget guidance is mainly relevant to very large sites, including sites with over one million unique pages or over ten thousand rapidly changing pages. Scope: Google Search guidance; the page-count examples are diagnostic starting points, not hard eligibility thresholds. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide
• “Core Web Vitals are a huge ranking factor.” (翻訳) 「Core Web Vitals は大きなランキング要因である。」 実際には、重要ではあるものの、マイナーなシグナルです。サイトが極端に遅い場合を除き、ランキングのためにこれらを優先することは通常ありません。想像上のランキング向上のためではなく、ユーザーのために改善してください。 Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience
• “You need a perfect 100 PageSpeed score.” (翻訳) 「PageSpeed スコアで完璧な 100 が必要だ。」 いいえ。そういったラボのスコアは Google のランキング基準ではありません — Google は実際のフィールドデータを使用します。100 を追い求めるのは無駄です。
• “Duplicate content is a penalty.” (翻訳) 「重複コンテンツはペナルティである。」 違います。Google は一部の重複を “normal.” (翻訳) 「正常」と呼んでいます。これは正規化の問題であり、危険ではありません。
• “IndexNow tells Google about my pages.” (翻訳) 「IndexNow は Google に自分のページを知らせる。」 そんなことはありません — Google は IndexNow を使用していません。これは Bing などのためのものです。

AI 検索時代のテクニカル SEO

AI 検索 — Google の AI Overviews、ChatGPT、Perplexity — は同じ基盤で動作しています。これらのシステムは、あなたのページを引用する前に、クロール、読み取り、理解する必要があり、ウェブを取得する新しい AI クローラー（GPTBot、ClaudeBot、PerplexityBot）の波もあります。したがって、このガイドの基礎は AI 時代になってもなくなりません — むしろ、技術的にクリーンであることが、AI の回答で引用される資格を得るための条件になるのです。

次に進む場所

実践者向けバージョン — パイプラインの詳細、クロール予算のしきい値、レンダリングの判断、正規化の多くのシグナル、テクニカル SEO を継続的なシステムとして運用する方法 — が必要な場合は、Advanced Guide タブに切り替えてください。

そして、このページはテクニカル SEO 全体のハブです。詳細な解説は、検索の仕組み（クロール、発見、インデックス、レンダリング）、サイト移転、オンページのメタタグ、検索エンジンツール（Search Console と Bing Webmaster Tools）、JavaScript SEO に分かれており、すべてサイドバーにあります。

TL;DR — テクニカル SEO は、すべてのサイトで同じクロール → レンダリング → インデックス → 配信のパイプラインです — 独立した「テクニカル SEO アルゴリズム」は存在せず、それはランキング要因そのものではなく、基盤です。パイプラインを一連のゲートとして扱い、何かを変更する前にページがどの段階で停滞しているかを診断してください。レバレッジは主にネガティブ（獲得したものを失わないこと）なので、退屈な構造作業 — 正規化、リダイレクト、内部リンク — が最も効果的で、規模に応じて複利で効きます。ほとんどのサイトではクロール予算を管理する必要はなく、レンダリングは遅延する可能性のある別のステップであり、Core Web Vitals は 3 つの異なる問題であり、マイナーなランキングレバーです。正規化は約 40 のシグナルにわたる重み付けされた判断であり、2025 年以降、AI 検索はランキングや引用の前に、クリーンな技術シグナルに資格を依存させています。ここで最も重要なスキルは優先順位付け — 何を無視するかを知ることです。

テクニカル SEO は順位ではなく、資格を決定する

テクニカル SEO は、その効果がほぼ完全にネガティブである SEO の唯一の部分です：その役割は、ランキングを獲得することではなく、失わないようにすることです。Google はクリーンな構造に対して順位を与えるわけではありません。同じクロール、インデックス、ランキングシステムは、サイトが完璧でも壊れていても動作します — その背後に独立した「テクニカル SEO アルゴリズム」は存在しません。テクニカル SEO が実際に決定するのは、あなたのページがそれらのシステムに入ることができるかどうか、そして、入った後にエンジンがそれらを正しく理解するかどうかです。

つまり、正しい考え方は「技術的SEOをして順位を上げる」ではなく、「技術的SEOをして、コンテンツとリンクが順位付けされることを許可されるようにする」なのです。この逆転こそが、地味な作業（正規化、リダイレクト、内部リンク）が最も価値の高い作業である理由であり、この分野で最も有用なスキルが優先順位付け（何を修正すべきか、そして同じくらい頻繁に、何を放置すべきかを知ること）である理由なのです。

パイプラインをゲートとして捉える

すべてはひとつのパイプラインに掛かっており、Googleの重要な文言は*「すべてのページが各ステージを通過するわけではない」*です。 Evidence for this claim Google Search describes crawling, indexing, and serving as three stages; discovery is part of the crawling stage, and not every page advances through each stage. Scope: Google Search documentation; conceptual explanation, not a promise of ranking outcomes. Confidence: high · Verified: 2026-07-14 Google: How Search Works すべてのページをゴールまで運ぶベルトコンベアを想像しないでください。それぞれに合否がある一連のゲートを想像してください：

• クロール — 発見（リンク＋サイトマップ＋プッシュプロトコル）とフェッチ。リンクが何もないページや、robots.txtで許可されていないページは、到達しないかもしれません。
• レンダリング — Googleは、ページを完全に理解する前に、最近のヘッドレスChrome（Web Rendering Service）でJavaScriptを実行します。これはフェッチとは別のステップであり、ステートレスで、遅延する可能性があります。
• インデックス — エンジンはページを処理し、重複の中から正規URLを選択し、保存するかどうかを決定します。クロールとレンダリングが成功しても、「インデックス登録は保証されていません」。
• 配信 — クエリ理解、その後の多くの自動システムにわたるランキング、そしてその上に重ねられる検索機能。

クロール ≠ レンダリング ≠ インデックス ≠ ランキングを頭の中で分けておけば、技術的SEOのほとんどは謎ではなくなります。ページのパフォーマンスが低い場合、推測したり10個のことを変更したりするのではなく、どのゲートで失敗したかを見つけて、そのステージを修正するのです。

パイプラインの説明を（私のものも含めて）絶対的な真実として扱う前に、正直な注意点がひとつあります。それはモデルであり、ソースコードではないということです。How Search Worksは、私がカンファレンスで行う講演で、このパイプライン全体を説明するものです（SlideShareのスライド）。そして、私はこの講演を、ここでも繰り返す警告で始めます：「これは私のシステムに対する理解であり…100%完全または正確であるとは言えません。」 これを緩やかに捉え、問題を推論するために使用してください。

実際にクロールを行うのは誰か

「Googlebot」はひとつのプログラムのように聞こえますが、実際はファミリーです。デスクトップ、モバイル（モバイルファーストインデックスなので、これが重要です）、画像、ニュース、動画、広告クローラーがあり、すべて同じクロールバジェットプールから引き出されます。そのため、画像やパラメータのクロールが暴走すると、実際のコンテンツのクロールが枯渇する可能性があります。

そして、もはや検索エンジンだけの話ではありません。私がCloudflare Radarのクロールデータを分析した とき（新しいボットの波について私が書いたAhrefsの記事）、検索エンジンのクローラーが依然として最も多くクロールしていましたが、AIボットは確実に2位に位置し、追い越す勢いでした。ログを読めば、登場人物は変わっています。そして、それを管理すること（どのAIクローラーを許可するか、そして自分にアクセスしているものが主張どおりのものかを確認すること）は、今や仕事の一部です。

クロールバジェット：重要になる場合と、そうでない場合

Googleはクロールバジェットを*“the set of URLs that Google can and wants to crawl,”* (翻訳) 「Googleがクロールできる、かつクロールしたいURLの集合」と定義しており、クロール容量（サーバーの健全性）とクロール需要（人気と鮮度）によって設定されます。実効バジェットを増やす方法は2つあります。ボットにより多くの容量を与えるか、あるいは—はるかに一般的ですが—それを無駄に使うのをやめることです。重複を統合し、価値の低いスペースをブロックし、完全に削除されたページには404/410を返し、ソフト404を修正し、正確なlastmodでサイトマップを最新に保ち、長いリダイレクトチェーンを避けてください。

安心できる点として、繰り返し言いますが、ほとんどのサイトはクロール予算を気にする必要はありません。 Google自身も、ページが公開された当日にクロールされるのであれば、“you don’t need to read this guide.” (翻訳) 「このガイドを読む必要はありません」と述べています。問題になり始めるのは、1M+ページ、または急速に変化する10k+ページの規模です。それ以下であれば、他のことに労力を使いましょう。 Evidence for this claim Google says crawl-budget guidance is mainly relevant to very large sites, including sites with over one million unique pages or over ten thousand rapidly changing pages. Scope: Google Search guidance; the page-count examples are diagnostic starting points, not hard eligibility thresholds. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide BingのFabrice Canel氏も同じ考えをより率直に表現しています。少ない方が良い——クロールするURLが少ないほどSEOに良い、と。

robots.txt：クロール制御であり、インデックス制御ではない

このファイル全体で最も重要な区別は、robots.txtはクロールを制御し、インデックスは制御しないということです。URLをDisallowにするとボットがそれを取得しなくなりますが、インデックスから除外されるわけではありません。Disallowされたページは、他のページがリンクしていれば（コンテンツなしのURLのみで）インデックスされる可能性があり、さらに悪いことに、ページをDisallowすると、Googleがそのページのnoindexタグを永遠に見ることができなくなります。

つまり、ルールは次のとおりです。

• 検索からページを消したいですか？ クロールを許可し、noindexを追加してください。インデックス削除にrobots.txtを使うのは絶対にやめてください。
• 低価値のURL領域（内部検索、無限のファセット組み合わせ）をボットにスキップさせたいが、インデックスは気にしない場合？ robots.txtのDisallowが正解です。
• AIクローラーを管理していますか？ ここでGPTBot、ClaudeBot、PerplexityBot、CCBotなどを許可またはブロックします。これは戦略的な決定であり、デフォルトではありません。

正規化：コマンドではなく、重み付けされた決定

正規化は高度なテクニカルSEOの多くが存在する領域であり、広く誤解されています。rel="canonical"はヒントであり、指示ではありません。 Googleは代表URLを選ぶ際に、リダイレクト、内部リンク、サイトマップへの掲載、HTTPS、URL構造など、他の多くのシグナルと比較検討します。私の正規化に関する詳細な解説 では、正規化の選択に影響するシグナルは約40個としています。そのため、Search Consoleで*「重複、Googleがユーザーとは異なる正規URLを選択」*と表示されることがあります。あなたのタグは多数決で負けたのです。

実際的な影響は次のとおりです。

• 矛盾するシグナルを送らないでください。 私はエンタープライズサイトで長年働き（IBMで社内テクニカルSEOを担当）、Enterprise SEO Chaos という講演では、*「あるバージョンにリダイレクトし、別のバージョンにcanonicalを指定し、さらに別のバージョンに内部リンクしている」*実際のページを紹介しています。1つのURLを選び、すべてのシグナルを一致させてください。
• シグナルの強さのおおよその順序: リダイレクト > rel="canonical" > 内部リンク > サイトマップ。301はcanonicalタグよりもはるかに強い主張です。
• 重複コンテンツはペナルティではありません。 GoogleのGary Illyes氏は、ウェブの約60%は重複コンテンツであり、Googleはその一部を通常のものとして扱う——スパム違反ではない と述べています。コストはシグナルの分散とクロールの無駄であり、罰則ではありません。解決策は統合であり、パニックではありません。

そしてJavaScriptに関する注意点：私はかつてテストを行いました——HTMLにrel="canonical"がないページにJavaScriptでそれを注入したところ、Googleは公にそれをしないと述べていたにもかかわらず、それを尊重しました。それが明らかになった後、GoogleはJavaScript SEOドキュメントを更新しました。教訓は「JS canonicalを使う」ではなく、これらのことはテスト可能であり、ドキュメントが常に最終的な判断ではないということです。

レンダリングの決定

レンダリングは、ほとんどの概要で省略されるステップであり、JavaScriptサイトが問題に陥る場所です。「クロール中、Googleはページをレンダリングし、見つけたJavaScriptを最近のバージョンのChromeで実行します。」 Evidence for this claim Google processes JavaScript pages in crawling, rendering, and indexing phases and uses a recent version of Chrome for rendering. Scope: Google Search JavaScript processing; rendering and indexing remain subject to technical and quality constraints. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics これは独立したステートレスなサービスであり、リソースを数週間キャッシュでき、最初のフェッチより遅れる可能性があります。そのため、JavaScriptに依存する変更が反映されるまでに時間がかかることがあります。

JavaScriptはここでの敵ではありません。私がJavaScript SEOガイド で述べたように、JavaScriptはSEOに悪いわけでも、邪悪なわけでもありません。多くのSEO担当者が慣れ親しんでいるものとはただ異なるだけです。 本当の決断はどのようにレンダリングするかです：

• サーバーサイドレンダリング（SSR） — SEOに最も安全。HTMLが完全な状態で届きます。
• 静的生成（SSG/プリレンダリング） — リクエストごとに変わらないコンテンツにとっては、両方の利点を兼ね備えています。
• クライアントサイドレンダリング（CSR） — リスクが最も高い。コンテンツはJSが実行された後にしか存在しないため、レンダリングステップに賭けることになります。
• 動的レンダリング — Googleはこれを回避策と呼び、推奨はしていません。Bingはより好意的です。これを目的地ではなく橋渡しとして扱ってください。

知っておくべき2つの罠があります。まず、遅延読み込み：Googlebotはスクロールもクリックもしないため、操作時にのみ読み込まれるコンテンツは見えないままになる可能性があります。ビューポート内にあるときに読み込まれるようにしてください。次に、リンク：Googleは実際の<a href>要素であるリンクしかたどれません。routerLinkやhrefのないクリックハンドラはクロール可能なリンクではありません。ギャップが疑われる場合は、URL Inspectionツールでレンダリングされた出力を生のHTMLと照合してください。

サイトアーキテクチャと内部リンク

内部リンクは同時に3つの役割を果たします：ボットがページを発見するのを助け、PageRankを分配し、アンカーテキストを通じてトピックの文脈を伝えます。John Muellerは内部リンクを*「SEOにとって非常に重要」*であり、自社サイトで持つ最大のレバーの1つと呼んでいます — 私も同意します。これは直接コントロールできる最もROIの高いものの1つです。

システムレベルのポイントをいくつか：

• オーファンページ — どこからもリンクされていないページ — が最初に探すべきものです。リンクされていなければ、ほとんど発見されず、ほぼ評価を得られません。
• アーキテクチャはクロールファネルの管理です。 重要なページはホームページの近くに置くべきです。深く、クリック距離が遠いページはクロールが少なく、ランキングも悪くなります。
• nofollowによるPageRankの彫刻は死んでいます（2009年以降）。内部リンクにnofollowを付けると、その評価は再分配されるのではなく蒸発します。nofollowのトリックではなく、実際のアーキテクチャでフローを管理してください。

Core Web Vitals：1つの問題ではなく3つの問題

ページエクスペリエンスに関する実務者の最大の誤りは、それを単一の「サイトを速くする」問題として扱うことです。Core Web Vitalsは3つの異なる問題であり、それぞれ根本原因と修正方法が異なります：

• LCP（Largest Contentful Paint） — 読み込み。サーバーの応答時間、レンダリングをブロックするリソース、メインコンテンツのアセットがどれだけ速く読み込まれるかによって決まります。目標は2,5秒未満。
• INP（Interaction to Next Paint） — インタラクティブ性。メインスレッドをブロックするJavaScriptの実行によって決まります。目標は200ミリ秒未満。（INPは2024年にFIDを置き換えました — どこかでまだFIDを見かけたら、そのアドバイスは古いものです。）
• CLS（Cumulative Layout Shift） — 視覚的な安定性。寸法のない画像、遅れて読み込まれるフォント、挿入されるコンテンツによって決まります。目標は0,1未満。

定義以外に重要なことが2つあります。ラボデータではなくフィールドデータ： GoogleはLighthouseスコアではなく、実際のユーザーのCrUXデータでランキングを決定します。そのため、フィールドデータが良好なLighthouse 65は、フィールドデータが悪いLighthouse 100に勝ります。そして割合： 正直に言うと、Core Web VitalsがSEOに大きな影響を与えるとは思いません。サイトが極端に遅い場合を除き、ランキングのためにそれらを修正することを一般的には優先しません。ユーザーとコンバージョンのために作業を行ってください。ただ、ランキングのレバーとして過大評価しないでください。

構造化データ：検索とAIへのシグナル

構造化データ（JSON-LD を使用）はランキングを直接上げるわけではありませんが、ページをリッチリザルトの対象にし、AI システムがコンテンツを解析して引用しやすくします。実際に有用ですが、ランキングシグナルとしては過大評価されています。私の正直な見解は、SEO の大部分は基本をきちんと行うことであり、コンテンツとリンクはスキーマよりも効果があるということです。リッチリザルトを有効にしたり、エンティティを明確にしたりする場合に実装しましょう。単独でランキングを上げるとは期待しないでください。（なお、スキーママークアップの URL はクロール可能な内部リンクではありません — Mueller もこれを確認しています。）

国際展開について簡単に

複数の言語や地域に対応する場合は、バージョンごとに異なる URL を使用し、hreflang アノテーションでそれらを関連付けます。また、URL パラメータよりも ccTLD やサブディレクトリを優先します。IP による自動リダイレクトは行わないでください — Google は明示的に警告しており、クロールを妨げます。国際 SEO はそれ自体が深い分野であり、独立した柱となるほどです。ここでは技術的な連携の部分だけを説明します。

技術的 SEO は一度きりの監査ではなく、継続的なシステムです

競合他社のガイドが間違っている点は、技術的 SEO を一度完了すれば終わりのチェックリストとして扱っていることです。サイトは常に変化します — デプロイで canonical タグが壊れたり、リリースで noindex がテンプレートに紛れ込んだり、新しい広告スクリプトが INP を悪化させたり、リダイレクトチェーンが蓄積したりします。成熟した実践は監視と回帰検出です：

• GSC のページインデックス登録で、インデックス登録数と除外ステータスの急激な変化を監視します。
• クロール統計とログで、レスポンスコードの急増やクロールパターンの変化を監視します。
• 大規模なデプロイのたびに、クロール、レンダリング、リダイレクトを再検証します。

ログファイルについて具体的に言うと、以前は数年に一度のトラブルシューティングツールとして扱っていました。それは変わりました。ログは、どのAI クローラーが実際にサイトにアクセスしているか、その頻度を確認できる最も明確な場所です — 他のツールではこれほど直接的に確認できません — そのため、AI 検索に関心がある人にとって、ログは以前よりもはるかに有用になっています。

サイト移転：最もリスクの高いイベント

移転（新しいドメイン、HTTP から HTTPS への移行、プラットフォームの変更、URL 構造の変更）は、すべての URL に同時に影響するため、技術的に最もリスクの高いイベントです。旧 URL から新 URL への1:1 のマッピングを行い、301/308 の恒久リダイレクトを使用し、無期限に維持します（私はすぐに削除しようとは思いません — リダイレクトが数回ある程度は心配する必要はありません）。該当する場合は GSC のアドレス変更ツールを使用します。移転は複雑で多くの人が関わることがありますが、パニックにならないでください — 問題が発生してもほとんどは修正できます。この柱の下に完全なサイト移転クラスターがあります。

AI 検索のための技術的 SEO

現代の変化であり、「技術的 SEO は死んだ」という安易な見解に反するものです：2025 年以降、AI 検索システムはランキングや引用を行う前に対象性を決定します。AI の回答で引用されるには、ページは一般的に、正しく canonical 化され、十分に高速で、特別な処理なしでレンダリング可能で、確実に解析できる構造である必要があります。乱雑なシグナルはランキングを下げるだけでなく、回答から完全に除外される可能性もあります。Bing のインデックスが多くの LLM の回答に供給されているため、Bing Webmaster Tools と IndexNow は、Bing の検索シェアが示す以上に重要です。技術的な衛生状態は、AI 時代においてより重要であり、軽視されるべきではありません。

レバレッジが実際にある場所

このガイドから一つだけ学ぶなら、優先順位付けです。インデックス登録、canonical 化、内部リンク、クリーンな移転に時間を費やしてください — これらはページが検索に存在するかどうか、そしてその評価を統合するかを決定する作業です。クロールバジェット、Core Web Vitals、重複コンテンツ、短いリダイレクトチェーンについては、具体的な診断済みの問題がない限り、心配する必要はありません。完璧を追い求めないでください — 技術的に完璧な主要サイトは存在しないと思いますし、もしあったとしても、重要でないことにリソースを浪費しているのではないかと心配になります。

このハブはピラーの残りをマッピングします: 検索の仕組み、サイト移転、 オンページ、検索エンジンツール、JavaScript SEO。サイトが壊れている場所から始めてください — パイプラインが最初に確認すべきゲートを教えてくれます。

AIまとめ

アドバンストガイドの要約版:

• 別のアルゴリズムはない。 すべてのサイトで同じクロール → レンダリング → インデックス → 配信のパイプラインが機能します。 テクニカルSEOは、ページがシステムに入り、理解されるかどうかを決定します — それは基盤であり、ランキングのトリックではありません。レバレッジは主にネガティブです: コンテンツとリンクが獲得したものを失わないこと。
• パイプラインをゲートとして扱う。 「すべてのページが各ステージを通過するわけではない。」 何かを変更する前に、ページがどのゲート（クロール、レンダリング、インデックス、配信）で失敗したかを診断してください。
• 一言で言えば: Googleがインデックスしないページはランク付けできません — だから退屈な構造作業（正規化、リダイレクト、内部リンク）が最も効果的で、規模に応じて複利で効きます。
• クロール予算: 容量 + 需要。ほとんどのサイトはそれを管理する必要はありません（約1M+ページ、または急速に変化する10k+ページで重要）。Bing: 少ないほど良い。
• robots.txtはクロールを制御し、インデックスは制御しません。 ページを削除するには: クロールを許可 + noindex。AIクローラーを許可/ブロックする場所でもあります。
• 正規化は重み付きの決定です 約40のシグナルに基づく; rel=canonicalはヒントであり、コマンドではありません。矛盾するシグナルを送らないでください; 重複コンテンツはペナルティではありません。
• レンダリングは別であり、遅れることがあります。 JSは悪ではありません、ただ異なるだけです。SSR / 静的 / CSR / 動的を意図的に選択してください; 遅延ロードと<a href>リンクの罠に注意してください。
• 内部リンクは「超重要」です（Mueller）。 孤立ページを探してください; アーキテクチャはクロールファネルの管理です; nofollowスカルプティングは死んでいます。
• Core Web Vitals = 3つの問題（LCP/INP/CLS）、Lighthouseではなくフィールドデータで判断され、マイナーなランキングレバーです（Patrickはランキングのためにそれらを優先しません）。
• 一度きりの監査ではなく、モニタリング。 ページインデックス、クロール統計、ログを監視してください; デプロイ後に再検証してください。ログはAIクローラーを検出するために新たに有用です。
• 移転は最もリスクの高いイベントです — 1:1でマッピングし、301、リダイレクトを維持してください。
• AI検索は、ランキング/引用の前にクリーンなテクニカルシグナルで適格性をゲートします; BingのインデックスはLLMに供給されるため、Bing Webmaster Tools + IndexNowはそのシェアよりも重要です。

公式ドキュメント

テクニカルSEOピラー全体を支える一次ソースのドキュメント。

Google

• In-Depth Guide to How Google Search Works — クロール → インデックス → 配信のパイプライン、URL発見、レンダリング、インデックス、配信。テクニカルSEOで最も重要なページ。
• SEO Starter Guide — Google自身の初心者向けオリエンテーションとSearch Essentialsのベースライン。
• Crawling and Indexing — robots.txt、サイトマップ、正規化、クロール制御のハブ。
• Optimize your crawl budget — クロール容量 + 需要、そして実際に気にする必要がある人。
• JavaScript SEO basics — インデックスの一部としてのレンダリングと、JSコンテンツをインデックス可能に保つ方法。
• Core Web Vitals & Page Experience — ページエクスペリエンスシグナルが何であり、どのように使用されるか。
• URL変更を伴うサイト移転 — Googleの移転プレイブック: リダイレクト、アドレス変更、監視すべきもの。
• Inside Googlebot (March 2026) — 現在のクロール経済とバイト制限。

Bing / Microsoft

• How Bing delivers search results — Bingのクロール→インデックス→ランキングのパイプラインと、その名前付きランキング要因。
• bingbot Series: Maximizing Crawl Efficiency — Bingのクロールの定義と、その「クロール効率のノーススター」。
• IndexNow / indexnow.org — 変更されたURLを即座に通知するプッシュプロトコル。サイトマップと組み合わせて使用。

ソースからの引用

GoogleとBingからの公式声明で、テクニカルSEOの柱を支えるものです。 各リンクはディープリンクで、ソースページの引用箇所にジャンプします。

Google — パイプライン

• “Google Search works in three stages, and not all pages make it through each stage.” (翻訳) 「Google検索は3つの段階で機能し、すべてのページが各段階を通過するわけではありません。」 引用にジャンプ
• “Googlebot uses an algorithmic process to determine which sites to crawl, how often, and how many pages to fetch from each site.” (翻訳) 「Googlebotはアルゴリズムによるプロセスを使用して、どのサイトをクロールするか、どのくらいの頻度で、各サイトから何ページ取得するかを決定します。」 引用にジャンプ
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (翻訳) 「クロール中、Googleはページをレンダリングし、見つけたJavaScriptを最新バージョンのChromeを使用して実行します。」 引用にジャンプ
• “Indexing isn’t guaranteed; not every page that Google processes will be indexed.” (翻訳) 「インデックス登録は保証されていません。Googleが処理するすべてのページがインデックス登録されるわけではありません。」 引用にジャンプ

Google — クロールバジェットとrobots.txt

• “Taking crawl capacity and crawl demand together, Google defines a site’s crawl budget as the set of URLs that Google can and wants to crawl.” (翻訳) 「クロール容量とクロール需要を合わせて、Googleはサイトのクロールバジェットを、Googleがクロールでき、かつクロールしたいURLの集合として定義します。」 引用にジャンプ
• “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.” (翻訳) 「サイトに急速に変化するページが多数ない場合、またはページが公開された当日にクロールされているように見える場合は、このガイドを読む必要はありません。」 引用にジャンプ
• “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site.” (翻訳) 「robots.txtファイルは、検索エンジンのクローラーに、サイト上のどのURLにアクセスできるかを伝えます。」 引用にジャンプ

Bing — Fabrice Canel, Microsoft

• “Crawling is the process by which bingbot discovers new and updated documents or content to be added to Bing’s searchable index.” (翻訳) 「クロールとは、bingbotがBingの検索可能なインデックスに追加する新しいドキュメントやコンテンツ、または更新されたドキュメントやコンテンツを発見するプロセスです。」 引用にジャンプ
• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (翻訳) 「SEOには少ない方が良い。それを決して忘れないでください。クロールするURLが少ないほど、SEOに良いのです。」 インタビューを読む

Google担当者、公式見解 (業界報道を通じて再掲)

• John Mueller: “Technical SEO is not going away, it continues to be the foundation of everything built on the open web.” (翻訳) 「テクニカルSEOはなくなることはなく、オープンウェブ上に構築されるすべての基盤であり続けます。」 カバレッジ（Search Engine Journal）
• Gary Illyes、クロール予算について: “the vast majority of the people don’t have to care about it.” (翻訳) 「大多数の人はそれを気にする必要はありません。」 カバレッジ（Search Engine Journal）
• John Mueller、内部リンクについて: “internal linking is super critical for SEO… one of the biggest things that you can do on a website.” (翻訳) 「内部リンクはSEOにとって非常に重要です…ウェブサイトでできる最も大きなことの一つです。」 カバレッジ（Search Engine Journal）
• John Mueller、Core Web Vitalsについて: “it’s more than a tie-breaker, but it also doesn’t replace relevance.” (翻訳) 「それはタイブレーカー以上のものですが、関連性を置き換えるものでもありません。」 カバレッジ（Search Engine Journal）
• Gary Illyes、Core Web Vitalsの優先順位について: “If you don’t have anything better to do on your site, go do Core Web Vitals.” (翻訳) 「サイトで他にやるべきことがなければ、Core Web Vitalsに取り組んでください。」（Pubcon AMA） カバレッジ（Search Engine Land）
• Martin Splitt、レンダリングについて: “two-wave indexing… plays less and less of a role.” (翻訳) 「二波インデックス…その役割はますます小さくなっています。」 カバレッジ（Onely）

Patrick Stox (私自身の仕事)

• “This is my understanding of systems and is based on a lot of public statements from Google and my own knowledge. Warning: It’s not going to be 100% complete or accurate.” (翻訳) 「これは私のシステムの理解であり、Googleからの多くの公開声明と私自身の知識に基づいています。警告: 100%完全または正確ではありません。」 — 私のHow Search Worksデッキのスライド3。 スライドを見る

メンタルモデル

1. テクニカルSEOのアルゴリズムは存在しない。 同じクロール → インデックス → 配信のパイプライン、同じランキングシステムが、すべてのサイトで機能します。テクニカルSEOは、あなたのページがシステムに入り、理解されるかどうかを決定します — ランキングポイントを与えるものではありません。「テクニカルなトリック」を探す前に、どの通常の段階が失敗しているかを尋ねてください。

2. 要素ではなく、基盤。 テクニカルSEOのレバレッジは主にネガティブです: コンテンツとリンクが獲得したものを失わないようにするものです。Googleがインデックスしないページをランク付けすることはできません — したがって、仕事のほとんどは障害を取り除くことであり、シグナルを追加することではありません。

3. ベルトコンベアではなく、4つのゲート。 クロール → レンダリング → インデックス → 配信。それぞれがフィルターであり、「すべてのページが各段階を通過するわけではありません」。ページのパフォーマンスが低い場合、何かを変更する前に、どのゲートで失敗したかを特定してください。

4. 4つの「等しくない」。

• クロール ≠ インデックス（ブロックされたページでもインデックスされる可能性があります。クロールが成功してもインデックスは保証されません）。
• クロール ≠ ランキング（クロールレートはランキングシグナルではありません）。
• クロール ≠ レンダリング（JavaScriptは遅延する可能性のある別のステップで実行されます）。
• インデックス ≠ ランキング（インデックスにあることはクエリで勝つことを意味しません）。

5. スケールでのレバレッジのルール。 大規模サイトではすべてがテンプレートレベルであるため、影響は倍増します。1つのエラーで何百万ものページがインデックスから除外される可能性があります。1つの正規化修正で大きな損失を回復できます。退屈な構造作業は、派手なものよりも優れています。

6. 優先順位付けが本当のスキル。 テクニカルSEOで最も難しく価値のあることは、何を無視するかを知ることです。インデックス、正規化、内部リンク、移行を修正してください。診断された問題なしに、クロール予算、Core Web Vitals、重複コンテンツを気にする必要はありません。

7. AIはハードルを上げるのであって、下げるものではない。 AI検索は、ランク付けや引用を行う前に適格性（クリーンな正規化、スキーマ、高速レンダリング可能なページ）を判断します。技術的なシグナルが乱れていると、回答から完全に除外される可能性があります。

技術的SEOの基礎チェックリスト

検索エンジンがサイトを発見、読み取り、理解できることを確認するための最初のパス：

• クロール可能。 重要なページはクロール可能な場所からリンクされている（孤立ページがない）。robots.txt はインデックスしたいものをブロックしていない。
• 発見可能。 XMLサイトマップが Google Search Console および Bing Webmaster Tools に提出され、正確な lastmod を持つ正規のインデックス可能なURLのみがリストされている。
• レンダリング可能。 JS依存のコンテンツは、クリックのみのナビゲーションではなく、実際の <a href> リンク経由で到達可能。重要なコンテンツが遅いレンダリングに依存していない。
• インデックス可能。 見つけたいページに不要な noindex がない。GSCのページインデックス登録レポートで除外ステータスを確認する。
• 正規化。 コンテンツごとに正規URLが1つ。重複はそれを指す。正規チェーンやホームページを指す正規タグがない。シグナルが一致している（リダイレクト、正規タグ、内部リンク、サイトマップがすべて同じ方向を指す）。
• サーバーの健全性。 高速で安定した応答 — 5xx/タイムアウトを最小限に（サーバーが不安定だとボットは遅くなる）。
• クリーンなリダイレクト。 長いリダイレクトチェーンやループがない。恒久的な移動には 301/308 を使用。削除されたページは 404/410 を返す。
• URLの無駄がない。 パラメータ、ファセットナビゲーション、セッションIDが無限または重複したURL空間（スパイダートラップ）を生成していない。
• オンページメタ。 一意で正確なタイトルタグとメタディスクリプション。正しいメタロボットディレクティブ。
• 移行に安全。 何かを移動する場合（ドメイン、HTTPS、プラットフォーム、URL）、旧→新の1:1リダイレクトをマッピングし、該当する場合はGSCのアドレス変更ツールを使用する。
• AI適格。 有効なスキーマ、一貫したエンティティシグナル、AIクローラーのアクセスを意図的に決定し、AI検索が解析して引用できるように高速でレンダリング可能なページ。

実際にどれだけ気にするべきか？

技術SEO担当者に渡せる最も有用なものはチェックリストではなく、バランス感覚です。「ベストプラクティス」の多くは、その価値以上に注目されています。ここに、レバレッジがかかる場所とかからない場所についての私の正直なランキングを示します。

パターンは次の通りです。インデックス、統合、クリーンな移行に時間を使い、クロールバジェット、Core Web Vitals、重複コンテンツについては、具体的な診断済みの問題がない限り心配しないこと。また、技術的な完璧さを追い求めないでください。技術的に完璧な主要ウェブサイトは存在しないと思いますし、もしあったとしても、重要でないことにリソースを浪費していると心配するでしょう。

各コントロールの役割

もう一つ、人々が常に混同していることですが、これらは4つの異なる役割を持つ4つの別々のツールです。

よくある間違いは、robots.txtを使ってインデックスから除外することです。クロールをブロックすると、Googleはnoindexタグを確認できず、他のサイトからのリンクを通じてページを検索結果に残す可能性があります。ページを削除したいですか？クロールを許可してnoindexを追加してください。

技術的SEOのためのツール

• Google Search Console — Google がサイトをどう扱っているかの信頼できる情報源: ページのインデックス登録レポート、クロール統計、URL 検査ツール(単一 URL のクロール/レンダリング/インデックス状態)、移行用のアドレス変更ツール。
• Bing Webmaster Tools — クロール情報、Crawl Control、Site Scan、IndexNow — そして、Bing のインデックスが多くの LLM の回答に供給されているため、そのシェアが示す以上に重要です。
• サイトクローラー / 監査 — Ahrefs Site Audit と Screaming Frog SEO Spider はクロールをシミュレートし、リダイレクトチェーン、重複 URL、ブロックされたページ、壊れた正規化、トラップのようなパターンを大規模に表面化します。
• サーバーログファイル分析 — ボットが正確に何をクロールし、どこで予算を無駄にしたかを確認できる唯一の場所 — そして、どの AI クローラー(GPTBot、ClaudeBot、PerplexityBot)がサイトにアクセスしているかを確認する最も明確な方法でもあります。Screaming Frog Log File Analyser を使用するか、ログを BigQuery / ログプラットフォームにパイプします。
• Ahrefs Webmaster Tools — 検証済みサイト向けの無料のクロール + 監査。
• PageSpeed Insights / Lighthouse — ページエクスペリエンスとレンダリングのチェック。フィールド(CrUX)データと組み合わせて、実際のユーザーとレンダラーがページをどのように体験しているかを確認します。
• IndexNow — 変更された URL を再クロールを待たずに Bing(およびその他)へリアルタイムでプッシュします。

持続可能な技術的 SEO 指標

意図したインデックスカバレッジの傾向

• 測定内容: 検索エンジンに配信してもらいたい正規化されたインデックス可能な URL が、時間の経過とともに実際にインデックスに反映されているかどうか。
• 取得方法: XML サイトマップまたは承認済みのインデックス可能な URL インベントリを Search Console のページインデックス登録データと比較し、テンプレートごとに除外理由を調査します。
• 頻度: 重要なリリース後、およびサイトの公開頻度とクロールレートに適した定期的なスケジュールで確認します。
• 健全な方向性: 意図したインデックス登録済み URL が安定しているか、承認済みコンテンツとともに増加し、説明のつかない除外や重複する正規化の競合が減少している。
• トリガーされる判断: 同じ影響を受ける領域にさらにコンテンツを投資する前に、テンプレートレベルのクロール、正規化、レンダリング、重複、または noindex の問題を調査します。

テンプレート別の Core Web Vitals フィールド合格率

• 測定内容: フィールドの Core Web Vitals に合格した実ユーザーのページグループの割合。サイト全体で平均化するのではなく、テンプレートとデバイスごとに分けています。
• 取得方法: Search Console の Core Web Vitals と CrUX/PageSpeed Insights のフィールドデータを使用し、影響を受ける URL グループを責任のあるテンプレートまたはコンポーネントにマッピングします。
• 頻度: フィールドデータの期間を通じて追跡し、主要なパフォーマンスリリースの前後を比較します。
• 健全な方向性: より重要なテンプレートが合格グループに移行し、別のデバイス、地域、またはページタイプにリグレッションが移行しない。
• トリガーされる判断: 不合格のグループが意味のあるトラフィックやユーザーエクスペリエンスに影響を与える場合は、共有テンプレートまたはコンポーネントの修正を優先します。ランキングのトリックとして小さなラボ専用の変更を追いかけないでください。

クロールの信頼性とレスポンスの構成

• 測定内容: 検索エンジンのクロールが、エラー、チェーン、トラップ、または価値の低い URL スペースに容量を費やすのではなく、有用な URL に確実に到達しているかどうか。
• 取得方法: Search Console のクロール統計をサーバーログとクローラーレポートと組み合わせ、ステータス、ホスト、ディレクトリ/テンプレート、ボットごとにセグメント化します。
• 頻度: インシデントを継続的に監視し、プラットフォーム、CDN、リダイレクト、ファセット、または移行の変更後に傾向を確認します。
• 健全な方向性: 重要な URL に対する安定した成功レスポンス、5xx エラーとリダイレクトチェーンの減少、サイト自身のベースラインと比較した既知のトラップスペースの繰り返しクロールの減少。
• トリガーされる判断: まず可用性またはルーティングを修正します。その後、永続的な無駄に対して内部ディスカバリ、パラメータ処理、またはクロール制御を調整します。

時間をかける価値のあるリソース

私の技術SEO記事 (Ahrefs)

• 技術SEOの初心者ガイド — 完全なフレームワーク：発見、クロール、理解、インデックス。
• エンタープライズ技術SEO — 大規模な技術SEOの実際（そして完璧さが間違った目標である理由）。
• クロール予算：知っておくべきすべて — それが重要になる場合と、重要でない（多くの）場合。
• JavaScript SEO：問題とベストプラクティス — 「JavaScriptはSEOに悪いわけではない…ただ違うだけだ。」
• 正規化：初心者ガイド — Googleが考慮する約40のシグナルと、ほとんどの重複が悪意のあるものではない理由。
• SEOのためのリダイレクト — 11のタイプと、それらをどのくらいの期間保持するか（思っているより長く）。
• ウェブサイト移転：完全ガイド — 「ほとんどすべての問題は修正できます。」
• Core Web VitalsとPageSpeed — 私がランキングのためにCWVを優先しない理由。

私の講演

• 検索の仕組み (SlideShare) — クロール、レンダリング、インデックス、ランキングの完全な解説。
• エンタープライズSEOの混乱 (SMX) — IBM規模の事例：24のURLバリエーション、14ホップのリダイレクトチェーン、そしてすべてが異なる方向を指すシグナル。

業界からの情報

• web.dev — Core Web Vitals — LCP、INP、CLSに関するGoogleのウェブプラットフォームドキュメント：それぞれが何を測定し、検索とは別にどう修正するか。
• Onelyブログ — レンダリングとインデックスに関する深い調査で知られる技術SEOエージェンシー（彼らのインデックスの2つの波 の記事は良い例）。
• Search Engine Roundtable — Barry Schwartzによる、GoogleとBingの担当者が実際に言ったことのほぼ毎日の記録。発言の変化を追跡する最速の方法。
• Search Engine Journal — 技術SEO — 継続的な報道と解説、および上記で引用されたいくつかの担当者発言の出典。
• Search Engine Land — SEO — 業界ニュースとカンファレンスの報道（GoogleチームとのPubcon/SMX AMA）。
• Googleのクロール12月 シリーズ — 公式のクロール解説を集中的にまとめた最良の資料です。
• r/TechSEO — クロール/インデックス/レンダリングのデバッグのためのコミュニティ。

ポッドキャスト

• Search Off the Record（Google検索リレーションズ）— Gary IllyesとMartin SplittがGooglebotのクロール、レンダリング、インデックスの仕組みについて語る。パイプラインに関する公式解説に最も近いもの。聴く
• Voices of Search — 優先順位付けのSEO努力、優先順位付けが仕事で最も難しい部分である理由と、影響が大きく/労力が少ない作業をどうトリアージするかについての私の対談。聴く
• TheeDigital — SEO神話の誤りを暴く — 消えない技術的な神話（重複コンテンツのペナルティ、キーワード密度、サブドメインとサブフォルダ）についての私の話。聴く

動画

• Google Search Central (YouTube) — Google検索の仕組みシリーズと、Martin Splittによるクロール/レンダリングとJavaScript SEOの解説。チャンネル

引用に値する統計

私自身の調査と第三者（Google、Microsoft、Cloudflare）のデータの混合：

• リッチリザルトはCTRを向上させることができます。 Googleが公開したケーススタディでは、Rotten TomatoesのマークアップされたページでCTRが**25%向上し、Food Networkでは訪問数が35%増加し、Nestléのリッチリザルトページでは非リッチページと比較してCTRが82%**向上したと報告されています。Google — 構造化データの紹介
• レンダリングはクロールの約20倍のコストがかかります。 私のJavaScript SEO講演より: Ahrefsは1日あたり約70億ページをクロールしましたが、約600台のサーバーを使用して約8000万のJavaScriptページをレンダリングしました。これは、レンダリングが制限され、遅延が生じる理由を理解するのに役立ちます。デッキ
• ウェブの約60%は重複コンテンツです — Gary Illyes (Google) — だからこそ、ある程度の重複は*“正常”*であり、パニックではなく正規化が正しい対応なのです。Google — 重複URLの統合
• Bingは毎日数百億の新しいURLを発見しています — Fabrice Canel (Microsoft) — 「少ないほど多い」という背後にある発見とフィルタリングの問題の規模を示しています。カバレッジ (Search Engine Roundtable)
• AIボットは明確な2位であり、検索エンジンボットに迫っています — Cloudflare Radarのクロールデータより(私の分析): 検索ボットが依然として最も多くクロールしていますが、AIクローラーは数年以内に追い越すペースです。ソース
• 95,2%のサイトに3XXリダイレクトがあり、72,9%がメタディスクリプションを欠いています (私の調査) — Ahrefs Site Auditの1M+ドメインにわたる調査です。ただし、メタディスクリプションの数値に過剰反応しないでください: Googleは約**62,78%**の確率でそれらを書き換え、ランキング要因ではありません。ソース

自分で試す: テクニカルSEO

テクニカルSEOとは何か、そしてクロール → インデックス → 配信のパイプラインに関する5つの簡単な質問です。各質問に回答を選び、その後で確認してください。

変更履歴