自分が作ったサイトでコンテンツが人々に届くことは重要である。とくに検索エンジン最適化が重要だ。ネイバーブログやネイバーカフェはネイバーの囲い込みであるため、グローバルな到達と検索で問題になる。 良いコンテンツはより多くバイラルされることが重要である。それこそがGoogleのような検索エンジンが求めることだ。 vibequant.ccの検索エンジン最適化を進めながら、次の手順を整理した。

項目 内容
対象 vibequant.cc およびサブドメイン（docs / tech / play / cti）
インフラ前提 Cloudflare DNS + Cloudflare Pages系の静的ホスティング、複数サブドメイン、韓/英/中/日の多言語アーカイブ
基準時点 2026年7月
根拠 Google Search Central公式ドキュメント・ブログ、ネイバー サーチアドバイザー、IndexNow仕様、Cloudflare公式ドキュメント
目標 検索エンジンとAI検索・エージェントが同一の基盤で正しく読むサイトを作る実務手順の確立

序論：三行要約

  1. AI検索のための別インデックスや別提出手順は存在しない。 Googleは、AI機能に露出するにはまず通常検索にインデックスされ、スニペット表示の資格が必要だと明示している。したがってSEOとAI可読性は別作業ではなく、同じ作業の二つの側面である。
  2. 作業順序を間違えるとコストが大きくなる。 登録・提出より先にインフラ点検が来る。誤った状態でインデックスされると、戻すのに数週間かかる。
  3. 韓国語コンテンツのサイトがGoogleだけを最適化するのは半分を捨てる選択である。 Naver・BingチャネルとIndexNowは、Cloudflare環境ではほぼ無料で確保できる。

1. 全体手順の概要

Phase 目的 所要 成果物
1 インフラ整合性の点検 1〜2日 正規化・レスポンスコード・プレビュードメイン整理の完了
2 プロパティ登録と所有権確認 1日 GSCドメインプロパティ + ホスト別URLプレフィックスプロパティ
3 クロール・インデックスパイプラインの構築 2〜3日 robots.txt、サイトマップインデックス、提出完了
4 オンページ最適化 1〜2週 Title/Meta/canonical/構造化データ/hreflang
5 AI可読構造の確立 1〜2週 セマンティック構造、エンティティ宣言、AI露出ポリシー
6 国内・その他検索チャネルの拡張 2〜3日 Naver・Bing登録、IndexNow自動化
7 測定体系の構築 継続 週次・月次点検ルーチン、データバックアップ自動化

Phase 1を飛ばして2に進んではいけない。 これが今回の作業でいちばん高くついて学んだ点である。プレビュードメインがインデックスされたまま、あるいはSPAフォールバックが200を返す状態でサイトマップを提出すると、Googleはその状態を学習したうえで訂正に数週間を使う。

2. Phase 1 — インフラ整合性の点検（Cloudflare静的ホスティング）

静的ホスティングにおけるインデックス問題の大半は、コンテンツではなくデプロイ設定から生じる。登録前に以下を全件確認する。

点検項目 確認方法 放置時の症状
プレビューデプロイドメイン（*.pages.dev）のインデックス site:pages.dev検索、該当URLのレスポンスヘッダー確認 本番と同一コンテンツの重複インデックス。正規URL判定の混乱
trailing slashの一貫性 /pathと/path/の双方アクセス 同一コンテンツが2つのURLに。シグナル分散
wwwの扱い www.vibequant.ccへのアクセス 未処理だと重複ホスト
404レスポンスコード 存在しないURLのHTTPステータス SPAフォールバックが200を返すとsoft 404が大量発生
_headersファイル リポジトリを直接確認 ステージング用X-Robots-Tag: noindexが本番に残ると全面インデックス遮断事故
Bot Fight Mode / WAFルール Cloudflare Security設定 過剰なボット遮断が正常クローラーを妨げる
SSL/TLSモード Cloudflare SSL/TLS設定 Flexibleはリダイレクトループ・混合コンテンツの原因。Full (strict) を推奨

対応指針

  • プレビューデプロイにはX-Robots-Tag: noindexヘッダーを適用するか、Cloudflare Accessでアクセスを制限する。
  • URL形態（trailing slash、www）は一つに決め、残りは301で統一したうえで、全ページに自己参照canonicalを明示する。
  • Always Use HTTPSとAutomatic HTTPS Rewritesをオンにする。HSTSは方針が確定してから適用する。戻しにくい。
  • _headersによる全面noindexは、戻したあともインデックス回復に数週間かかる。デプロイ前の確認項目として固定する。

3. Phase 2 — プロパティ登録と所有権確認

3.1 プロパティの種類

種類 対象範囲 所有権確認手段 判断
ドメインプロパティ（vibequant.cc） 全サブドメイン + http/https + www有無の全体 DNS TXT のみ 必須
URLプレフィックスプロパティ（https://docs.vibequant.cc/） そのプレフィックス配下のみ HTMLファイル、メタタグ、GA、GTM、DNS 併用推奨

両タイプを登録するのが実務上有利である。 ドメインプロパティは全体を一度に掴めるが、その代償としてサブドメインの成果が一つのグラフに合算される。docs・tech・play・ctiがそれぞれ異なるコンテンツ性格を持つ状況では、ホスト別プレフィックスプロパティを併せて個別追跡する方が判断材料としてずっと有用である。

3.2 Cloudflare DNSでの所有権確認

  1. GSCでドメインプロパティを追加 → 提示されたTXT値をコピー
  2. Cloudflare Dashboard → 該当ゾーン → DNS → Records → Add record
    • Type TXT / Name @ / Content google-site-verification=...
  3. GSCで確認をクリック（Cloudflare DNSの伝播は通常数分）

TXTレコードを削除すると所有権が解除される。認証後も永続保存する。

4. Phase 3 — クロール・インデックスパイプライン

4.1 robots.txt

ホストごとにそれぞれ必要である。静的サイトなら各プロジェクトのpublic/robots.txtに配置する。

User-agent: *
Allow: /

Sitemap: https://docs.vibequant.cc/sitemap.xml

Sitemap:指示子はGoogle・Bing・Naverが共通で読む標準チャネルである。GSC提出とは別に必ず入れておく。

4.2 サイトマップ構造（サブドメイン複数運用）

サイトマップは原則として、自身が置かれているホストのURLのみを含むべきである。したがって次の構造が安全である。

https://vibequant.cc/sitemap.xml          <- サイトマップインデックス
  ├─ https://vibequant.cc/sitemap-main.xml
  ├─ https://docs.vibequant.cc/sitemap.xml
  ├─ https://tech.vibequant.cc/sitemap.xml
  ├─ https://play.vibequant.cc/sitemap.xml
  └─ https://cti.vibequant.cc/sitemap.xml
  • インデックスが他ホストのサイトマップを参照するクロス提出は、参照先ホストの所有権が確認されているときに有効である。3.1のとおりドメインプロパティを登録しておけばサブドメイン全体の所有権が確保されるため、この構造が成立する。
  • 各ホストのrobots.txtには自ホストのサイトマップを明示する。
  • <lastmod>には実際のコンテンツ更新時刻のみを書く。ビルドのたびに全体を現在時刻で更新すると、シグナル自体が無視される。静的サイトジェネレータの既定動作がこのミスを招きやすいので必ず確認する。
  • サイトマップには最終URLだけを入れる。リダイレクト対象が混ざると、インデックスレポートに「ページにリダイレクトあり」が溜まる。
  • 単一サイトマップの上限はURL 50,000件 / 非圧縮50MB。CTIアーカイブ増加時の分割基準として覚えておく。

4.3 URL検査とインデックス登録リクエスト

  • URL検査でインデックス状態、正規URL判定、クロール時点、構造化データの認識有無を個別確認する。
  • インデックス登録リクエストには日次割り当てがあり、リクエストがインデックスや順位を保証するわけではない。新規公開時に1件ずつ使うツールである。
  • 大量URLの発見はサイトマップと内部リンクが担う。この原則をひっくり返してはいけない。

4.4 使ってはいけないチャネル二つ

チャネル 現在の状態 対応
サイトマップping（google.com/ping?sitemap=） 2023年6月に廃止予告、2024年1月から404 CI/CD・デプロイスクリプトから削除。robots.txt + GSCで十分
Google Indexing API 廃止ではないがJobPostingとBroadcastEvent専用 一般文書・コラムには使用不可。このAPIでブログをインデックスさせるというガイドは根拠がない

5. Phase 4 — オンページ最適化

5.1 サイト構造と内部リンク

サブドメインはクローラーから見るとそれぞれ別サイトに近い。 ドメインプロパティでまとめても、この事実は変わらない。

  • ルート（vibequant.cc）をハブにし、4つのサブドメインの代表セクションへ明示的なリンクを張る。
  • 各サブドメインからルートへ戻るグローバルナビゲーションを共通配置する。
  • コンテンツ間の相互引用（CTIレポート → 関連技術文書、コラム → 根拠データ）を本文リンクでつなぐ。新規ページ発見経路として最もよく機能する。
  • 主要セクション（/essays、/lab、/research、/about）はルートから2クリック以内で到達可能であるべきだ。

5.2 Title / Meta / Canonical

要素 基準
Title おおよそ60文字（日本語では30文字前後を目安）。ページ固有の主題 + サイト名。ファイル名ベースの自動生成タイトルが残っていないか全件点検
Meta Description 順位要因ではないがCTRに直接作用する。ページごとに固有に書く
H1 ページあたり1つ。Titleと完全一致である必要はない
Canonical 自己参照canonicalを全ページに明示。静的ビルドで抜けやすい
OG / Twitter Card 順位要因ではないが、SNSが主流入経路なら優先度が高い

5.3 構造化データ

  • ArticleまたはTechArticle：headline、datePublished、dateModified、author
  • Organization：ルートページに1回。sameAsにGitHub・ORCID・ETNews寄稿者ページ・SSRN著者ページを明示
  • Person：著者プロフィールにORCIDをidentifierとして含める
  • BreadcrumbList：サブドメインの階層構造を伝える

リッチリザルトテストで検証したうえで、GSCの構造化データレポートで認識有無を再確認する。

5.4 パフォーマンス

モバイルファーストインデックスが適用されているため点検の必要性は残るが、点検ツールは変わった。 GSCのモバイルユーザビリティレポートとモバイルフレンドリーテストツール・APIは2023年12月1日に終了した。

ツール 性格
PageSpeed Insights 実測（CrUX）+ ラボ（Lighthouse）を同時確認
Chrome DevTools Lighthouse ローカルラボ計測、アクセシビリティ・SEO監査を含む
GSC Core Web Vitals 実ユーザーデータに基づくサイト全体のトレンド

静的ホスティングなら概ね良好だが、playサブドメインのようにスクリプトが重い箇所はINPを別途確認する。

5.5 多言語（hreflang）

hreflangは言語別URLが分離されているときだけ意味がある。1ページに韓国語と英語が混在している状態では適用対象外である。言語別URL体系の整理が前提条件だ。

<link rel="alternate" hreflang="ko" href="https://cti.vibequant.cc/ko/report-001" />
<link rel="alternate" hreflang="en" href="https://cti.vibequant.cc/en/report-001" />
<link rel="alternate" hreflang="ja" href="https://cti.vibequant.cc/ja/report-001" />
<link rel="alternate" hreflang="zh" href="https://cti.vibequant.cc/zh/report-001" />
<link rel="alternate" hreflang="x-default" href="https://cti.vibequant.cc/en/report-001" />
  • 相互参照が必須。 AがBを指せばBもAを指し、自分自身も含める。
  • x-defaultを必ず指定する。
  • 4言語でCTIレポートを発行する構造なら実益が大きい。

6. Phase 5 — AIが正しく読むウェブサイトを作る

6.1 出発点：AI露出に別インデックスはない

Google公式ドキュメントの核心的な陳述は次のとおりである。

  • AI OverviewsとAI Modeは通常の検索インデックスを使う。Googlebotがクロールした内容が源泉である。
  • ページがAI機能に現れるには、まずインデックスされていてスニペット表示の資格がなければならない。
  • 別のAIインデックスも、別の提出手順もない。 AI機能露出のための追加要件は存在しない。
  • 新しい機械可読ファイル、AI専用マークアップ、Markdown版、コンテンツチャンキング、AI専用リライトはいずれも不要である。

したがって「AI最適化」という別作業ラインを作る必要はない。Phase 1〜4がすなわちAI最適化である。その上に載せるのは技法ではなく文書構造の規律である。

6.2 文書構造の規律八つ

AIがコンテンツを引用するには、事実単位を抽出できなければならない。実際に効果があったのは、次のような平凡な項目である。

# 規律 理由
1 サーバーで完成したHTMLを提供する クライアントJSレンダリングに依存すると、クローラー・エージェントごとに読める度合いが変わる。静的生成が最善
2 見出し階層を意味どおりに使う h1は1つ、h2・h3が実際の論理構造と一致。スタイル目的の見出しタグ使用は禁止
3 1主題1URL 1ページに複数主題を詰め込むと、どのクエリにも正確に対応できない
4 結論を前に置く 文書冒頭2〜3文の要約が引用単位としてそのまま使われる。序論を長く書く学術慣習はここでは不利に働く
5 表と定義リストを使う 比較・数値・分類は散文より表の方が正確に抽出される。表にはキャプションや先行文で文脈を付ける
6 すべてのセクションにアンカーIDを付与する 引用時にページ単位ではなくセクション単位で参照される
7 日付・著者・出典を本文に明示する datePublished/dateModifiedと本文表記を一致させる。CTIレポートのTLP等級・信頼度評価はそれ自体が強い信頼シグナルである
8 画像内の情報をテキストでも重複提供する チャートだけあって数値がテキストになければ、そのデータは読まれない。altとキャプション、または本文の表で併記する

加えて、PDFよりHTMLを一次形式にする。 論文・レポートをPDFだけで配布すると、インデックス品質と引用可能性がともに下がる。HTML本文を正本とし、PDFを付加ダウンロードとして提供する方がよい。

6.3 エンティティを明示的に宣言する

AI回答は個別ページではなく主体（エンティティ）単位で信頼を蓄積する。同名組織・パッケージが存在する状況ではとくに重要である（第9章参照）。

  • Organization・PersonスキーマのsameAsにGitHub、ORCID、SSRN著者ページ、ETNews寄稿者ページをすべてつなぐ。
  • /aboutページに経歴・専門分野・発行チャネルを散文で明示する。スキーマだけでは足りない。
  • 著者表記を全チャネルで同一文字列に統一する。表記が分かれるとエンティティが分裂する。

6.4 AI露出の制御手段三つ — 混同に注意

この三つはよく混ざって説明されるが、まったく別のものを制御する。

手段 制御対象 通常検索への影響 AI Overviews / AI Mode露出への影響
GSC設定 → Search generative AIトグル 生成AI機能での露出と根拠活用 なし（Googleが順位シグナルに使わないと明示） オプトアウト時は露出・トラフィック0
robots.txt Google-Extended Gemini系モデルの学習およびGeminiアプリのグラウンディング なし なし。 AI Overviewsは通常検索インデックスを使うため、遮断しても露出は維持される
nosnippet / max-snippet / data-nosnippet スニペットとして示せるテキスト範囲 あり。 通常検索スニペットも一緒に消える AI機能露出の抑制に作用する
（noindex） インデックスそのもの 検索から完全除去 当然除去

もっとも多い誤りは、Google-Extendedを遮断すればAI Overviewsから外れると信じることである。 そうではない。学習とリアルタイムグラウンディングは別問題である。

方針決定時の留意点：原文閲覧を重視してnosnippetを使うと、通常検索のCTRも一緒に崩れる。TLP:GREEN・CC BY-NC-SAで配布するアーカイブなら、拡散優先か原文閲覧優先かを先に決め、露出データを数週間観察してから調整するのが合理的である。

6.5 llms.txtの実際の位置づけ

目的を分けて判断すべきである。

目的 有効性
Google Search / AI Overviewsの順位・可視性 無効。 Googleが2026年6月の公式ドキュメントで使用せず、順位に正負の影響もないと明示
Claude、Perplexityなど一部AI検索の文書探索 有効だという観測が存在する
コーディングエージェント（Cursor、Copilotなど）の文書参照 実質的に有効。Stripe・Cloudflare・Anthropicなどがこの目的で発行

結論：docs.vibequant.ccのようにツール・APIドキュメントを提供するサブドメインには発行価値があり、コラム・CTIアーカイブにSEO目的で発行する理由はない。 ある2026年調査では、30万ドメイン中の採用率が約10%、発行されたファイルの大多数が実際に閲覧されていないと報告された。発行するなら、エージェント用ドキュメントインデックスとして実際の有用性を備えるよう書くべきである。

6.6 CloudflareのAIクローラーポリシー — 2026年9月15日のデフォルト変更

Cloudflare利用者はこの日程を知っておくべきである。

事項 内容
変更時点 2026年9月15日
内容 検索・エージェント・学習用途を分けない「混用（mixed-use）」クローラーを、広告のあるページでデフォルト遮断
適用対象 新規顧客、既存顧客の新規サイト、既存無料プラン顧客全体
課金モデル Pay Per Crawl → Pay Per Useへ移行。クロール時点ではなく、AI回答に実際に使われたときに支払い

vibequant.ccは広告を掲載していないため、デフォルト遮断の対象条件には該当しない可能性が高い。ただし無料プランのデフォルト転換対象には含まれるため、9月15日より前に現状設定を確認しておく方が安全である。

あわせてAI Crawl Control（旧AI Audit）を確認する。全プランで設定なしに動作し、どのAIサービスがどの頻度でアクセスしているか、robots.txt指示を実際に遵守しているかをダッシュボードで見られる。AI経由露出を管理する立場では、遮断ツールである前に観測ツールとしての価値が大きい。

注意：AIクローラーを広範に遮断すると、AI検索経由の引用と流入も一緒に消える。クロール対リファラル比率が悪いのは事実だが、引用露出そのものに価値を置くアーカイブなら、全面遮断は自らの目的に反する。

7. Phase 6 — 国内およびその他の検索チャネル

7.1 ネイバー サーチアドバイザー

  1. searchadvisor.naver.com → ウェブマスターツール
  2. サイト登録（ホストごとにそれぞれ。 Naverにはドメインプロパティの概念がない）
  3. 所有確認：HTMLファイルアップロードまたはメタタグ。HTMLタグ方式は再認証が必要になることがあるため有効期限を確認する
  4. リクエスト → サイトマップ提出およびRSS提出。RSSがあると収集速度が有意に速くなる
  5. 検証 → ウェブページ最適化、robots.txt診断を活用

wwwとnon-wwwを同時に登録してはいけない。Naverは別サイトとして扱い、シグナルが分散する。登録後、実際の露出まで通常1〜4週かかる。

7.2 Bingウェブマスターツール

GSCからプロパティインポートが可能なため、設定負担はほぼない。一部のAI検索がBingインデックスを参照する構造であるため、規模に対して優先度が高い。

7.3 IndexNow

項目 内容
対応 Bing、Naver（2023年7月から）、Yandex、Seznam、Yepなど
非対応 Google
効果 クローラー訪問を待たず変更を即時通知。一か所に知らせると参加エンジンに共有される

Cloudflare利用者にとって最も安価な経路はCrawler Hintsである。 Cloudflareは2021年からCrawler HintsでIndexNowをネイティブ対応しており、ダッシュボードでオンにすればキャッシュされたコンテンツ変更時にCDNレイヤーで自動通知する。コード作業はない。

前提条件：当該ドメインがCloudflareプロキシ（オレンジクラウド）経由であること。DNS-only状態だとCloudflareがトラフィックを見られないため動作しない。この場合、デプロイ後にサイトマップを読んでIndexNowエンドポイントへPOSTするWorkerが代替手段である。

7.4 Daum（Kakao）

Daum検索登録とウェブマスターツールは別手順であり、robots.txtの修正が求められる。トラフィック寄与を踏まえ、優先度は最後に置く。

8. Phase 7 — 測定体系

8.1 パフォーマンス（Performance）レポート

機能 用途
クエリグループ（Query Groups） 類似検索語をまとめて主題単位の成果を把握。ロングテールが散らばる技術文書サイトに効果的
ブランド / 非ブランドフィルター ブランド検索と主題検索を分離。第9章の診断に必須
24時間（時間別）ビュー 新規公開直後の流入確認、SNS共有効果の測定
Recommendations GSCの自動提案。参考用であり優先度は自ら判断する

8.2 ページのインデックス登録（Page indexing）レポート

確認順序と解釈：

  1. インデックス登録済みページ数がサイトマップ提出URL数とどれだけ乖離しているか
  2. インデックス未登録の理由別の読み取り
    • クロール済み - 現在インデックス未登録：品質・重複判定。コンテンツ問題であり、技術的修正では解決しない
    • 代替ページ（適切な正規タグあり）：正常。変形URLが整理されているシグナル
    • ページにリダイレクトあり：サイトマップにリダイレクト対象が入った場合
  3. サイトマップレポートで各サブドメインサイトマップの読み取り成功可否

8.3 生成AIパフォーマンスレポート

2026年6月3日に導入された。AI Overviews、AI Mode、Discoverの生成AI領域で自社URLが露出した回数を別ビューで提供する。

事項 内容
提供指標 露出回数のみ。 クリック・CTR・クエリなし
分割基準 ページ / 国 / デバイス / 日付（時間〜月単位）
データ開始 2026年5月18日頃。遡及履歴なし
ロールアウト 英国の一部サイトから開始 → 順次拡大（6月23日拡大）。国内アカウントではまだ見えない場合がある
合計への影響 なし。 既存パフォーマンスレポートに含まれていたデータを分離表示するもの

クリックデータがないため、「露出は増えたがクリックが停滞」区間の原因をこのレポートだけでは断定できない。 露出トレンドと実流入を並行して見つつ、因果判断は保留するのが正しい。

8.4 その他のレポート

  • Core Web Vitals：実ユーザー（CrUX）ベースのトレンド
  • HTTPS：混合コンテンツ・非HTTPSページの検出（2022年9月から提供される常時レポート）
  • robots.txtレポート：ホスト別の認識状態とエラー
  • 構造化データ / リッチリザルト：5.3節適用後の検証
  • クロール統計（設定配下）：応答時間、ステータスコード分布。Phase 1のあとWAF過遮断の有無をここで確認

8.5 データ保存とバックアップ

  • パフォーマンスレポートの保存期間は16か月である。それ以上は照会できない。
  • 長期追跡が必要ならBigQuery一括データエクスポートまたはSearch Console APIで定期バックアップする。後者はGitHub Actionsのスケジュールジョブで低コスト実装が可能である。
  • プライバシー保護のしきい値未満のクエリは表示されないため、クエリ合計と総計の不一致は正常である。

8.6 Cloudflare指標との交差検証

GSCは検索露出・クリックを、Cloudflare Web Analyticsは実際の到着トラフィックを見る。二つの数値の乖離そのものが情報である。

パターン 解釈
GSCクリック ≫ CFセッション 計測スクリプト欠落、または即離脱
GSC露出増・クリック停滞 Title・Descriptionの問題、またはAI要約がクリックを吸収
CFトラフィックあり・GSCデータなし 検索外流入（SNS、直接、GitHubリファラー）が主経路

三つ目のパターンが初期状態である可能性が高い。そうであればSEOは既存流入を改善する作業ではなく新しいチャネルを開く作業であり、成果判断の時点をそれだけ後ろにずらすべきである。

9. 進行中に確認したブランドエンティティ問題

vibequantキーワード検索結果の上位は次が占めている。

競合対象 性格
vibequant.com 音楽産業データサイエンスコンサルティング企業（同名、.com保有）
vibequant（PyPI / GitHub） 金融データ分析用Pythonパッケージ
github.com/vibequant 同名GitHub組織

同じ検索でvibequant.cc自体は現れなかった。インデックスがまだ形成されていない状態に見え、Phase 1〜3が最優先課題である根拠となる。

戦略的含意：

  1. ブランド単独キーワードをKPIにしない。 .com同名企業が席を占め、パッケージ名が開発者検索の意図を吸収する。
  2. エンティティを構造的に分離する。 6.3節のsameAs接続がここで直接効果を出す。
  3. 主題ロングテールが実質的な流入経路である。 「トークンアンロック72時間ショック」「Kimsuky APT43」「MCPセキュリティ構造」「CEX HFTインフラ限界」のような具体主題語には競合者がいない。Title・H1・内部リンクをこちらに集中する。
  4. 非ブランド露出の増加だけを進捗指標にする。 ブランドフィルターで二つの流れを分離測定する。

10. よくある誤解

作業中に確認した結果、国内外のガイドでいまも繰り返される誤情報である。

通説 実際
GSCでモバイルユーザビリティを点検せよ モバイルユーザビリティレポート・モバイルフレンドリーテストツール・APIは2023年12月1日終了。 Lighthouse / PageSpeed Insightsで代替
「インデックス（Coverage）」レポートを確認せよ 現在の名称はページのインデックス登録（Page indexing）
HTTPSレポートは最近新設された 2022年9月リリース。2023年のPage Experienceレポート整理後、Core Web Vitalsとともに個別維持されたもの
サイトマップ一つに全サブドメインURLを入れてよい 原則として同一ホストのみ。クロス提出は所有権確認が前提
サイトマップpingで即時通知できる 404。 2024年1月から動作しない
Indexing APIで新しい記事を早くインデックスさせられる JobPosting・BroadcastEvent専用。一般文書には使用不可
Google-Extendedを遮断すればAI Overviewsから外れる 外れない。 学習・グラウンディング制御トークンであり、検索インデックスとは無関係
llms.txtがAI検索順位に役立つ Google Searchは使用せず順位に無影響。エージェント・一部AI検索目的は別議論
AI検索用の別マークアップ・Markdown版が必要 不要。Googleは追加要件がないと明示
SEO適用後10〜14日で結果が見える インデックス反映確認にのみ有効な窓。順位形成は通常4〜12週

11. 実行チェックリスト

P0 — 基盤とインデックス形成（1〜2週）

# 作業 完了
1 第2章インフラ点検表の全項目確認（プレビュードメイン、soft 404、_headers、trailing slash、WAF） [ ]
2 GSCドメインプロパティ登録 + Cloudflare DNS TXT所有権確認 [ ]
3 サブドメイン別URLプレフィックスプロパティの併用登録 [ ]
4 ホスト別robots.txt作成およびSitemap:指示子の明示 [ ]
5 ホスト別サイトマップ + ルートサイトマップインデックス構成、lastmod正確性の確認 [ ]
6 GSCサイトマップ提出および読み取り成功の確認 [ ]
7 主要ページ10〜20件のURL検査 + インデックスリクエスト [ ]
8 デプロイスクリプトから廃止済みサイトマップping呼び出しの削除 [ ]

P1 — チャネル拡張（2〜3週）

# 作業 完了
9 ネイバー サーチアドバイザーへのホスト別登録 + サイトマップ/RSS提出 [ ]
10 BingウェブマスターツールへのGSCインポート [ ]
11 Cloudflare Crawler Hints（IndexNow）有効化およびプロキシ状態の確認 [ ]
12 Cloudflare AI Crawl Controlダッシュボード確認、9月15日デフォルト変更に備えた設定点検 [ ]

P2 — オンページとAI可読構造（4〜6週）

# 作業 完了
13 全ページTitle / Meta Description / canonicalの全件点検 [ ]
14 Article・Organization（sameAs含む）・Person（ORCID）・BreadcrumbListスキーマの適用 [ ]
15 6.2節文書構造規律8項をテンプレート水準に反映（見出し階層、要約先行、アンカーID、表キャプション） [ ]
16 チャート・画像内の数値をテキストで併記 [ ]
17 PDF専用配布文書をHTML正本 + PDF付加構造へ転換 [ ]
18 サブドメイン間の相互内部リンク構造の整備 [ ]
19 PageSpeed Insights計測およびCore Web Vitals改善 [ ]
20 言語別URLが分離されたコンテンツにhreflang適用（相互参照 + x-default） [ ]

P3 — 運用（継続）

# 作業 完了
21 パフォーマンスレポート週次点検（ブランド/非ブランド分離、クエリグループ） [ ]
22 ページのインデックス登録レポート月次点検および除外理由の処理 [ ]
23 生成AIパフォーマンスレポートへのアクセス可否確認およびAI露出ポリシー決定 [ ]
24 Search Console APIまたはBigQueryで16か月以前データのバックアップ自動化 [ ]
25 docsサブドメイン向けllms.txt発行の検討（エージェント目的に限定） [ ]

12. 期待タイムライン

時点 観察可能な変化
1〜3日 所有権確認完了、サイトマップ読み取り成功、GSCデータ収集開始
1〜2週 インデックス登録済みページ数の増加開始。インデックスリクエストした個別URLの反映
2〜4週 Naver露出開始。ブランド検索結果への登場
4〜8週 非ブランドロングテール露出の形成。最初の有意なクエリデータ確保
8〜12週 順位安定化の開始。この時点のデータでコンテンツ戦略調整を判断

8週より前のデータで戦略をひっくり返してはいけない。 標本が足りない区間の順位変動はほとんどがノイズである。

13. 出典

  • Google Search Central, "AI Features and Your Website" — AI機能露出要件、別インデックス・提出手順なし、制御手段（nosnippet / Google-Extended）の区分
  • Google Search Central, AI最適化ガイド "Mythbusting generative AI search" 節（2026-06更新） — llms.txtおよびAI専用マークアップ不要の明示
  • Google Search Central Blog, "Introducing Search Generative AI performance reports in Search Console" (2026-06-03) — https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports
  • Google Search Central Blog, "The role of page experience in creating helpful content" (2023-04) — モバイルユーザビリティレポート・モバイルフレンドリーテスト終了、Core Web Vitals / HTTPSレポート維持 — https://developers.google.com/search/blog/2023/04/page-experience-in-search
  • Google Search Central Blog, "Sitemaps ping endpoint is going away" (2023-06) — https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping
  • Search Engine Land, "The SEO's guide to Google Search Console" — GSC機能沿革（HTTPSレポート 2022-09、Recommendations 2024-08、Query Groups 2025-10、ブランドフィルター 2025-11）
  • Search Engine Land, "Google officially drops Mobile Usability report..." (2023-12-04)
  • Cloudflare Blog, "Your site, your rules: new AI traffic options for all customers" (2026-07) — 混用クローラーのデフォルト遮断、Pay Per Use移行
  • Cloudflare Docs, AI Crawl Control概要 — https://developers.cloudflare.com/ai-crawl-control/
  • Bing Webmaster Blog, "Cloudflare Supports IndexNow via one-click Integration" (2021-11)
  • IndexNow.org FAQ — 参加検索エンジン一覧およびエンドポイント仕様
  • ネイバーウェブマスター公式告知 — IndexNow対応開始（2023-07）
  • ネイバー サーチアドバイザー登録手順および露出所要期間に関する実務文書（2026）