docs-seo

Docs SEO

ドキュメントサイトに取り組むテクニカル SEO の実務担当者です。一般的な SEO 監査では、次のような問題は見つかりません。

• 同じページがリリースごと、ロケールごとにそれぞれ存在している
• タイトルと canonical が、ライターではなくジェネレーターの設定から生成されている
• プレビュー用ブランチがインデックスに登録されている
• 自動生成された数千ものリファレンスページが、ドメイン内で最も内容が薄く、かつ検索意図が最も強いページになっている

サイトが公開する内容、つまり検索エンジンがクロールできるページ、重複ページのうち優先される URL、各ページのタイトルとスニペットの内容、ページ同士のリンク構造を改善します。ターゲットにする検索クエリの決定、コンテンツの作成、AI の回答に引用されることを狙う施策は担当しません。次の課題については、該当するスキルを利用してください。

• テクニカルな検索需要：samber/developer-relations-skills@developer-keyword-research
• ドキュメント群全体におけるページの網羅性と配置：samber/developer-relations-skills@developer-docs-structure-audit
• エラーおよびトラブルシューティングページのコンテンツ：samber/developer-relations-skills@developer-troubleshooting-docs
• コーディングエージェント向けの機械可読なサーフェス：samber/developer-relations-skills@coding-agent-docs-optimization
• devrel のすべてのサーフェスにわたるトラッキング計画：samber/developer-relations-skills@devrel-analytics

よくある依頼：

• 「ドキュメントサイトの SEO を監査してください」
• 「Google に v3 ではなく v1 のドキュメントが表示され続けています」
• 「リファレンスページの半分がインデックスに登録されていません」
• 「検索結果で、ドキュメントのタイトルがどれも同じように見えます」
• 「ステージング環境のドキュメントが Google に表示されています」
• 「ドキュメントを書き直したら、トラフィックが減りました」

インタビュー

一度に質問するのは1つだけにし、できるだけ選択式にして、ユーザーがすでに伝えた内容は聞かないでください。質問1〜4は作業を開始するための必須条件です。これらを確認しないと、重要でないページを監査したり、プラットフォームで実現できない方針を推奨したりすることになります。

メモリ：現在のタスクやプロジェクトの状況に関する情報をいくつか保存してください。メモリをファイルに保存する場合は、devrel-context.md を使ってください。別のメモリシステムを使っている場合は、そちらを利用してください。タスク情報はセクションを分けて記録してください。完了したタスクは削除してください。タスクには日付を付け、プロジェクト全般の状況には日付を付けないでください。タスクによって、インタビューの回答が異なる場合があります。

1. ドキュメントの URL は何ですか。また、そのサイトはプラットフォームのホスト（*.readthedocs.io、*.github.io、*.pages.dev）や別のドメインでも表示されますか？
2. どのジェネレーターとホスティングプラットフォームを使っていますか。また、その設定を編集してデプロイできますか？
3. ドキュメントはバージョン管理されていますか？されている場合、公開中のバージョン、現行バージョン、サポートが継続されているバージョンを教えてください。
4. 翻訳されていますか？どのロケールがあり、レビューなしで機械翻訳されているものはありますか？
5. このサイトの Search Console（または同等のサービス）と、ドキュメントのパスに関するアナリティクスを利用できますか？
6. 自動生成された API／CLI リファレンスのページツリーはありますか？ある場合、およそのページ数を教えてください。
7. 同じドメインまたは別のドメインに、重複するトピックを扱うブログやマーケティングサイトはありますか？
8. 今回のきっかけは何ですか？トラフィックの減少、移行、公開、それとも定期的なメンテナンスですか？
9. 公開ホスト名で表示されるプレビュー、ステージング環境、またはブランチごとのドキュメントデプロイはありますか？
10. 修正を実際に反映するのは誰ですか？ドキュメントの執筆者、プラットフォームの設定担当者、それともインフラチームですか？
11. 結果を反映する期限はいつですか？
12. 期限までに一度だけ成果を上げればよいですか？それとも、今後何年も維持する方針が必要ですか？
13. 作業量の上限はどのくらいですか？執筆者とプラットフォーム担当者が使える時間、チームが受け入れられる URL 変更の量を教えてください。

最後の3つの回答によってステップ3の優先順位が変わるため、監査を始める前に確認してください。

• 直近の厳しい期限がある場合は、午後のうちに実施できる唯一の方針である「最新版のみ」を優先します
• 効果を積み上げていく方針が求められる場合は、「安定した正規 URL」を優先します
• URL 変更を許容できない場合は、バージョンごとにインデックス登録可能にする方針を除外します
• チームが stable エイリアスを作成できない場合は、「安定した正規 URL」の方針を除外します

ユーザーがジェネレーター設定の変更やデプロイを行えない場合（質問2）は、そこで中止し、その旨を伝えてください。このスキルの修正のほとんどは、テンプレートまたは設定の変更が必要です。ページごとの回避策の一覧は、結局誰かが実施しなければならず、成果物としては適切ではありません。

ステップ1 - クロール対象を作成する

サイトマップから始めてください。サイトマップと実際の状況とのギャップ自体が、調査結果の1つです。

python3 scripts/docs-seo-crawl.py https://docs.example.com/sitemap.xml --out pages.csv --summary
python3 scripts/docs-seo-crawl.py https://docs.example.com/sitemap.xml --limit 300 --delay 0.5 --out sample.csv
python3 scripts/docs-seo-crawl.py --urls urls.txt --format json --out pages.json --summary

このスクリプトはサイトマップインデックスを1階層たどり、各ページを取得して、以下を記録します。

• ステータス、タイトル、メタディスクリプション、正規 URL
• robots ディレクティブ（メタタグおよび HTTP ヘッダー）
• 最初の h1、概算の単語数
• 外部リンクと内部リンクの被リンク数

--summary は、到達不能な URL、noindex ページ、タイトルの欠落と重複、正規 URL の欠落、別ページを指す正規 URL、内容の薄いページ、リンク切れの終点、孤立したページの件数を stderr に出力します。

自分が管理していないサイトでは、--delay をデフォルト以上に設定してください。大規模なリファレンスツリーを最初に調べる場合は、--limit を使うことをおすすめします。

スクリプトを実行できる環境がない場合は、手作業でサンプルを確認してください。サイトの入口、各セクションから10ページ、リファレンスツリーから20ページを対象にします。これらはこのスキル独自の目安であり、統計的な妥当性ではなく、1時間あたりの網羅性を重視して選んでいます。レポートには、インベントリをサンプリングしたことを明記してください。

次に、スクリプトでは確認できないものを調べます。

• robots.txt
• サイトマップファイル自体
• JavaScript を無効にして取得した1ページ

サイトマップは、掲載内容だけでなく形式も確認してください。sitemaps.org のプロトコルでは、1つのファイルにつき URL は最大50,000件、非圧縮サイズは最大50MBです。また、サイトマップインデックスは同じサイズ制限のもと、最大50,000件のサイトマップを格納できます。生成されたリファレンスツリーとバージョン、ロケールの組み合わせが、これらの数値に達するドキュメントの唯一のケースです。単一のフラットファイルを生成するジェネレーターは、インデックスに分割せず、気づかれないまま制限を超えてしまいます。

ステップ 2 - まず重大な問題を解消する

クロール → インデックス → レンダリング → シグナルの順に進めます。Google がクロールできないページのタイトルを書き換えても効果はありません。この順序にしておけば、ユーザーから最初に何をすべきか尋ねられたとき、修正リストの根拠を示せます。

次の順に確認します。

1. noindex も設定されているパスを robots.txt がブロックしていないか。ブロックされたページの noindex は読み取られないため、これは典型的な本末転倒の組み合わせです。
2. サイトマップに記載された URL が 200 以外のステータスコードを返していないか。
3. 検索結果に表示されるべきページに noindex が設定されていないか（多くの場合、テーマのデフォルト設定や、セクション内でコピーされたフロントマターのフラグが原因です）。
4. プレビュー環境、ステージング環境、ブランチごとのホストが、X-Robots-Tag: noindex なしで応答していないか。
5. JavaScript の実行後にしか表示されない本文、canonical、ナビゲーションリンクがないか。
6. robots.txt が CSS や JS をブロックしていないか。
7. エージェントごとのクローラー設定で、ユーザーの意図を超えてブロックしていないか。ドキュメントチームが選んでいないボット管理のデフォルト設定も含みます。

項目 1〜6 はすべて重大な問題です。修正リストの最上位に置き、残りの監査結果がどのようなスコアであっても優先します。./references/indexability-and-versioning.md には、ディレクティブの一覧表、ジェネレーターごとのサイトマップのソース、各確認項目を検証するコマンドが記載されています。

項目 7 はポリシー上の判断であり、問題ではありません。検索での発見、ユーザーの指示による取得、モデルのトレーニングは、それぞれ別のコストが伴う個別の設定です。「AI ボットを一律にブロックする」ルールを設定すると、会社が掲載を望んでいたアシスタントの回答からドキュメントが除外されてしまうことがよくあります。

ブロック設定は、robots.txt だけでなく、ドキュメントチームの誰も選んでいない CDN やボット管理のデフォルト設定に含まれている場合もあります。上記のリファレンスにあるカテゴリ別の表とエージェントごとの検証ルールを使って、各ルールの影響を報告してください。アクセスの確認までで止めてください。アシスタント向けに何を公開するか、引用を獲得する方法は、このスキルの対象ではありません。

ステップ 3 - バージョンと翻訳の方針を決める

一般的な SEO 監査では省略されるこのステップが、現在のリリースと 3 年前のリリースのどちらが検索クエリで優位に立つかを左右します。まず、宣言された方針（canonical タグが示す内容）と実際の状態（Google がインデックスする URL）を比較します。両者は一致しないことがよくあります。

方針は 3 種類あります。ここでは、ジェネレーターでどれが最も簡単に実装できるかではなく、労力あたりの価値が高い順に並べています。可逆性も労力の欄で考慮してください。このスキルの中で、すべての URL のインデックス登録状態を一度に変え、取り消せないリンクを蓄積する唯一の決定だからです。

方針	URL の形式と正規 URL	作業量（元に戻す場合を含む）	得られる価値
安定版を正規 URL にする	/en/stable/… と /en/v2.3/…。すべてのバージョンの正規 URL を stable エイリアスに設定します	プラットフォーム側で提供されていれば 1 時間（Read the Docs では READTHEDOCS_CANONICAL_URL を公開しています）、エイリアスを手動で作成する必要があれば 1 週間です。URL を移動しないため、正規 URL の参照先を 1 つ変更するだけで元に戻せます	最新リリースが検索クエリで優先され、サポート対象の各リリースの URL も引き続き有効です
最新版のみ	/docs/… を公開し、/v1/… はアーカイブして noindex にします	ほぼゼロです。アーカイブにディレクティブを 1 つ設定するだけで、削除すれば元に戻せます	最新リリースが検索クエリで確実に優先されます。旧リリースを使う人は自分のページを見つけられません
バージョンごとにインデックス可能	バージョンごとに自己参照型の正規 URL を持つページを用意し、バージョン切り替え機能を設けます	継続的な作業が必要です。リリースのたびにインデックス対象の範囲、サイトマップ、リンク網が増えます。元に戻すには、すでにインデックスされたすべてのバージョンに対してページ単位のリダイレクトマップが必要です	旧リリースを使う読者が、自分のリリース用のページにアクセスできます

どの方針も、仮説ではなく、すでにどこかで採用されています。

• Redocly のドキュメント SEO ガイドでは、ほとんどのドキュメントサイトで全バージョンの正規 URL を現在のリリースに設定することを推奨しています。これは安定版を正規 URL にする場合と同じ仕組みですが、別のエイリアスではなく「最新版」を対象にしています。

• Docusaurus は、非推奨バージョンが検索結果で最新のドキュメントより上位に表示されるようになった後、バージョンごとの noindex オプションを追加しました。実質的に最新版のみの方針です。

• Kubernetes は、直近の複数リリースを個別のホストで公開し続け、検索対象にしています。一方、robots.txt でブロックするのは最も古い 2 バージョンのみです。これは、無期限のアーカイブではなく、提供終了の期限を設けた「バージョンごとにインデックス可能」な方針です。

• 効率性：安定版を正規 URL にする ＞ 最新版のみ ＞ バージョンごとにインデックス可能

• 価値：安定版を正規 URL にする ＞ バージョンごとにインデックス可能 ＞ 最新版のみ（旧リリースが引き続きサポートされている場合）

• 作業量：バージョンごとにインデックス可能 ＞ 安定版を正規 URL にする ＞ 最新版のみ

可逆性を独立した項目にしないのは、ここでは作業量とまったく同じ順になるためです。構築に最も手間がかかる方針は、元に戻す際にも最も手間がかかります。同じ内容の項目をもう 1 つ追加しても、別の意見のように見えるだけです。

安定版を正規 URL にする方針をデフォルトとして推奨します。現行リリースのみがサポート対象で、期限まで数週間しかない場合は、最新版のみの方針に切り替えます。

この順序では、価値が高く作業量も最大の「バージョンごとにインデックス可能」な方針が毎回不利になり、選ばれません。それでも、サポート対象の LTS リリースに実際のトラフィックがある場合や、各リリース専用のページを提供するというサポート上の約束がある場合は、この方針を優先してください。

ユーザーの制約によって選択できない方針は、最下位に並べるのではなく削除し、どれを削除したかを明記してください。stable エイリアスを作成したりリダイレクトしたりできないチームには、安定版を正規 URL にする選択肢はありません。リリースが 1 つだけのチームには、方針の選択自体がありません。そのことを述べて先に進んでください。 すでに把握している状況に照らして優先順位を見直してください。単一の方針を機能として提供するプラットフォーム、CDN を管理するドキュメントチーム、何年も被リンクを集めてきた既存のバージョン別 URL セットなどがあれば、答えは変わります。この順位はデフォルトであり、絶対的なルールではありません。

次に、残りのシグナルを整合させます。

1. サイトマップ、canonical タグ、内部リンクがすべて同じターゲットを指すようにします。シグナルが競合すると、Google が独自に canonical を選ぶ原因になります。
2. 各ロケールに自己参照 canonical と完全な hreflang セットを設定します。翻訳ページの canonical を英語にすると、そのページは検索対象から除外されます。
3. サイトが複数のドメインで表示される場合は、プライマリドメインを 1 つ選び、残りをそこへ canonical 化するか、リダイレクトします。
4. 廃止するバージョンについては、ツリー全体をドキュメントのホームへ送るのではなく、ページごとにリダイレクト先を選びます。

canonical ルールを書く前に、方針についてユーザーの確認を求めてください。

Google のローカライズ版に関する公式ドキュメントでは、hreflang に関する 4 つの疑問が解決されています。最初の 3 つは必須要件として扱い、違反は提案ではなく不具合として報告してください。

• 各言語版には、自分自身と他のすべての言語版を記載します。一致するものがない場合に備えて x-default も含めてください。
• 参照リンクは双方向である必要があります。ページ X がページ Y を指していても、Y が X を指していなければ、アノテーションは無視される可能性があります。
• 値には ISO 639-1 言語コードを指定し、必要に応じて ISO 3166-1 Alpha 2 地域コードを続けます。地域コードだけでは無効です。
• HTML タグ、HTTP ヘッダー、サイトマップのエントリは、同等の提供方法です。Google は、大規模サイトかどうかにかかわらず、どれも優先していないと述べています。

運用面だけを理由に、サイトマップを推奨します。ロケール × バージョンのツリーでは、何百ものタグがすべての <head> に入るためです。ロケールを追加するときは、関連する一式を再生成してください。/fr/ の代替ページを再生成せずに /ja/ を追加すると、/ja/ には /fr/ からの戻りリンクがなくなります。検証チェックリストと無効なコードの一覧は、./references/indexability-and-versioning.md にあります。

ステップ 4 - テンプレートレベルでページシグナルを修正する

ドキュメントサイトではタイトル、説明、見出し構造が生成されるため、テンプレートを 1 か所編集すれば、すべてのページに反映できます。ページごとの書き換えはその次に行い、トラフィックのあるページに限ります。

• タイトルテンプレートを書き換えて、検索された用語を先頭に、ブランドを末尾に配置します。このスキルのデフォルト形式は {page} | {product} {section} です。必要に応じて調整しつつ、この順序を保ってください。
• クイックスタート、上位のハウツー、トラフィックが最も多いリファレンス項目の説明を作成します。残りは、埋め草の文章を生成するのではなく、フォールバックに任せます。
• 各ページには、内容を具体的に示す主要な見出しを 1 つ設け、レベルを飛ばさずに順に下げます。2 つ目の有効な h1 があるという理由だけでページを失格にしないでください。階層が明確かどうかで判断します。
• ビルド間で見出しの id アンカーを安定させ、長いリファレンスページがアンカー単位の検索結果を獲得できるようにし、プロダクトからページ内の該当箇所へ直接リンクできるようにします。
• HowTo と FAQPage の構造化データは使わないでください。Google は両方のリッチリザルトを終了しています（HowTo は 2023 年 8 月、FAQPage は 2026 年 5 月までに完全終了）。BreadcrumbList は引き続き表示され、ドキュメントには表現すべき実際の階層があります。

文字数はゲートではなく、あくまで lint として扱ってください。Google は <title> の長さに上限はないと述べています。タイトルリンクはデバイスの幅に合わせて切り詰められるため、50～60 文字というルールは重要な部分が残るかどうかを確認するにすぎません。

ドキュメントサイトに実際の損失をもたらすのは、書き換えです。Google がタイトルの問題を検出すると、ドキュメントサイトでは多くの場合、定型文やパンくずリストのようなタイトルが原因で、見出し、アンカーテキスト、og:title、その他のページ内テキストから独自のタイトルリンクを作成することがあります。テンプレートが役に立たなくなっている原因を修正してください。短くしても何も変わりません。

良い例と悪い例の比較、スニペットの制御方法、構造化データのステータス表は、./references/page-signals-and-snippets.md にあります。

ステップ 5 - 内部リンクを修復する

ドキュメントサイトにはナビゲーションリンクがあらゆる場所にありますが、文脈に沿ったリンクはほとんどないため、どのページが重要なのかが伝わりません。まず孤立ページを修正します（クロールスクリプトに一覧が表示されます）。次に行き止まりのページを修正し、最後に最もトラフィックの多いページから、文脈に沿った文章でリンクを追加します。クイックスタートと人気の高いハウツー記事は、リンクの評価を引き継がせる力があります。

異なる種類のコンテンツ間のリンクが、ドキュメントの価値を最も高めます。

• チュートリアル → 使用したシンボルのリファレンス
• リファレンス → 対応するタスクのハウツー
• トラブルシューティング → 問題が発生するガイド

説明的なアンカーテキストを使い、「こちら」や「続きを読む」は使わないでください。

同じ作業の中で、キーワードの競合も確認します。あるタスクを狙うブログのチュートリアルとドキュメントのハウツー記事があると、インプレッションが分散し、どちらも優位に立てません。どちらの掲載場所でその検索クエリを獲得するかを決め、もう一方から勝者にリンクします。

ステップ 6 - ページエクスペリエンス

ドキュメントサイトは通常は高速ですが、クライアントサイドの検索ウィジェット、埋め込み型 API エクスプローラー、最適化されていない図表群のいずれかを追加すると、速度が低下しがちです。ドメイン全体の平均ではなく、ドキュメントのパスを対象に Core Web Vitals を確認してください。

各指標の合格基準は Google が定めています。その基準を満たす必要があるドキュメント URL の割合は、ユーザーと相談して設定する目標です（このスキルの基準値は 90% です）。

環境でページ速度の監査を実行できる場合は、3 種類のページ、つまりドキュメントのホーム、長いガイド、リファレンスページで実行し、それぞれが合格するまで改善を繰り返します。実行できない場合は、Search Console のフィールドデータを使い、ラボデータがないことを明記してください。

Step 7 - 修正リストを提示し、しきい値を設定する

調査結果を羅列するのではなく、優先順位を付けた修正リストを提示します。レポートには、次の項目を順番に記載します。

• 判定の段落
• 検証できなかった内容を明記したカバレッジの説明
• ブロッカーとなる不具合
• バージョンと翻訳の方針
• ページのシグナル
• 内部リンク
• 優先順位付きの修正リストと合意したしきい値

各修正項目には、何を、どのファイルまたはシステムで変更するのか、そして担当者を記載します。担当者の列がない不具合リストは、次回の監査でも変更されないまま戻ってきます。修正の順序は「（影響を受けるページ数 × 重大度）÷ 作業量」で決めます。これはこのスキル独自の計算式であり、標準ではありません。作業量にかかわらず、ブロッカーとなる不具合を最上位にします。

その順序が比率に基づくものであり、重大度順ではないことが読み手に伝わるよう、レポート内で明言してください。この比率では、影響するページ数が少なく、完了まで1週間かかる修正は後回しになります。たとえば、クライアント側でレンダリングされるシェルのサーバーサイドレンダリングや、以下の「対象読者に関する注意」で触れるエンタープライズ向けページ群です。ページ数によるランキングでは、こうした修正は決して表面化しません。ビジネス上、特に重要なページに影響する場合は、手動で優先順位を上げてください。

修正作業を始める前に、完了基準となるしきい値をユーザーと合意してください。また、2種類の数値は区別し、変更可能なのはそのうち一方だけであることを明確にします。検索エンジンが適用するルールに反する状態は不具合であり、しきい値ではありません。

• robots.txt でクロールを拒否されたページでは、noindex も canonical も読み取られません
• 返信リンクのない hreflang の設定は、全体が無視される可能性があります
• 50,000 件を超える URL または非圧縮で 50MB を超えるサイトマップファイルは、仕様に準拠していません

これらはブロッカーとなる不具合のセクションに記載し、議論の対象にはしません。

しきい値の表には、このスキル独自の基準値のみを記載します。以下の値はここで設定したものであり、業界標準ではありません。

• canonical なドキュメント URL のうち、インデックス登録済みのものが ≥95%
• Google が別の canonical を選択したページが 0 件
• サイトマップ内に 200 以外の URL が 0 件
• タイトルが重複しているページが 0 件
• 孤立ページが 0 件
• インデックス登録されたプレビュー版または廃止バージョンの URL が 0 件
• Core Web Vitals に合格するドキュメント URL が ≥90%

これらは初期設定値であることを明記し、サイトに合わせて調整してください。ドキュメントが20ページのサイトなら、インデックス登録率は100%を目指すべきです。一方、ページ数が20,000件のリファレンスツリーでは、そうはいきません。

検索順位に関する結果は、保留中として報告してください。それが実情だからです。このセッションで検証できるのは設定と整合性までであり、再インデックス登録、再順位付け、検索結果のスニペットの再生成は、こちらではなく検索エンジンのスケジュールで行われます。検索順位要因の重みをでっち上げたり、トラフィック増加を予測したりすれば、技術的には正確な監査でも信頼性を失います。

修正が反映されたらクロールを再実行し、2回分の概要を比較します。その差分が作業完了の証拠です。最初の調査結果リストではありません。

レポートのテンプレート、記入例、Search Console のセグメンテーションルール、メンテナンスのトリガーについては、./references/audit-report-and-metrics.md を参照してください。

対象読者に関する注意

ドキュメントが、ツールを自力で導入する開発者向けであっても、企業として導入を評価するチーム向けであっても、仕組みは同じです。異なるのは、どのページが重要かという点です。セルフサービスでの導入では、クイックスタート、ハウツー、エラーページが重要です。

企業による導入評価では、制限事項、セキュリティ、コンプライアンス、セルフホスト、移行に関するページが重要です。通常、こうしたページはサイト内で最も情報が少なく、リンクが少なく、インデックス登録もされにくいページです。誰もドキュメントとして扱っていないためです。製品にエンタープライズ向けの販売戦略がある場合は、2つ目のページ群を明示的に確認してください。トラフィック順のページリストでは、決して表面化しません。

失敗パターン

失敗	状況	対処
ブロックされ、noindex になる	robots.txt が noindex を含むページへのパスを許可していない	ディレクティブを読み取れるようにブロックを解除するか、リダイレクトする
canonical の行き先がばらばら	サイトマップ、canonical タグ、ナビゲーションが、それぞれ異なるバージョンを指している	方針を一つに定め、3つのシグナルすべてに適用する
無関係なページへの canonical	古いページの canonical が、内容の異なる現行ページを指している	代わりに、最も近い同等ページへリダイレクトする
翻訳版が無効化される	/fr/ の canonical が /en/ を指している	ロケールごとに自身を canonical に設定し、hreflang セットを完全に指定する
一方向の hreflang	/en/ は /ja/ を指定しているが、/ja/ は何も指定していない	すべてのロケール間で相互リンクを含む完全なメッシュを生成し直す
サイトマップが上限超過	60,000ページのリファレンスツリーを1つのファイルにまとめている	サイトマップインデックスに分割し、各ファイルをURL 50,000件、50MB以下にする
タイトルを60文字に短縮	文字数ルールに合わせるため、400件のタイトルを短くしている	テンプレートの構成を修正する。タイトルの長さに上限はない
AI ボットを一律ブロック	すべてのアシスタントクローラーを対象に1つの Disallow を設定している	エージェントごとに判断する。検索、ユーザーによる取得、学習はそれぞれ別の用途です
ビルド時刻を lastmod に設定	すべてのページの lastmod が最終デプロイ時刻になっている	ソースファイルのコミット日時から算出するか、設定を削除する
プレビューがインデックスに登録される	PR またはステージング環境のホストが、robots ヘッダーなしで200を返す	CDN で X-Robots-Tag: noindex を設定し、curl -I で確認する
ページごとの場当たり対応	テンプレートを1つ変更する代わりに、タイトルを400件手書きしている	まずジェネレーターの設定を修正し、その後でページを修正する
前置きの定型文	すべてのページが「Acme は…を提供するプラットフォームです」で始まる	最初の画面内でクエリに回答する
非推奨のスキーマ	HowTo／FAQPage マークアップのプロジェクト	代わりにパンくずリストとタイトルを使う
リファレンス全体を noindex に設定	「内容が薄い」ことを避けるため、生成されたツリー全体を除外している	インデックス可能な状態を保つ。フィールドごとではなくリソースごとに分割する
ホームへのリダイレクト	廃止されたバージョンの URL がすべてドキュメントのインデックスを指している	ページごとに転送先を指定する。インデックスへの転送は最後の手段にする
しきい値のないスコア	「ドキュメント SEO の健全度：78/100」	修正に着手する前に、数値目標について合意する
推定クエリデータ	技術クエリに関するサードパーティの検索ボリューム数値	Search Console を使うか、「未検証」と明記する

参考資料

• samber/developer-platform-skills@api-reference-quality：このスキルでインデックス可能にした後の、API リファレンスツリーのコンテンツ品質について