プラットフォーム: GitHub

parasite SEO、GEO（AI引用）、キュレーションリスト作成向けの GitHub ガイドです。GitHub は Tier 2 テクニカルオーソリティプラットフォームで、高いドメインオーソリティ、高速インデックス、AI引用確度が非常に高いです。リポジトリ、README、GitHub Pages、gist、Awesome スタイルのナビゲーションリストに使用できます。

呼び出し時: 初回使用時 は必要に応じて、このスキルが何をカバーしており、なぜ重要なのかを 1～2 文で開き、その後メインの出力を提供します。その後の使用時 またはユーザーがスキップを要求した場合は、直接メイン出力に進みます。

SEO に GitHub を使う理由

要因	効果
ドメインオーソリティ	高い DA; リポジトリ、gist、Pages はよくランキングされる
高速インデックス	検索エンジンは GitHub を頻繁にクロール
AI 引用	ChatGPT、Perplexity は技術的クエリで GitHub を引用; GEO フレームワークで Tier 2
技術的専門性	強い専門性シグナル; 構造化されたドキュメントが AI リファレンス資料になる
クロスプラットフォーム	Dev.to、Stack Overflow、フォーラムで共有可能; 可視性を増幅

ユースケース

ユースケース	フォーマット	目的
Parasite SEO	リポジトリ、README、Pages、gist	GitHub オーソリティを活用してランキングとバックリンクを獲得
GEO	ドキュメント、チュートリアル、キュレーションリスト	AI ツールが技術的な答えについて GitHub を引用
キュレーション/ナビゲーションリスト	Awesome スタイルのリポジトリ	トピック固有のリソースディレクトリ; バックリンク、発見

サーフェス: プロフィールとリポジトリ

サーフェス	説明	最適化フォーカス
プロフィール README	ユーザー名と同じ名前のパブリックリポジトリ; ルートの README.md がプロフィール上にレンダリング	個人ブランド、主要リンク、ソーシャルプルーフ
ピン留め	プロフィール上の最大 6 個のリポジトリまたは gist	トッププロジェクトをショーケース; エンティティシグナル（entity-seo）に合わせる
リポジトリ別 README	各リポジトリの Code タブのルート README.md	製品ランディング; インストール、プルーフ、CTA

通常のリポジトリ README を変更しても、そのコンテンツが プロフィール README リポジトリであるか、そこからリンクされていない限り、プロフィールバナーは変わりません。

プロフィール README（username/username）

製品リポジトリ README とは異なります。 約 15～40 行のレンダリングされたコンテンツで アイデンティティ + ナビゲーション に最適化してください。ただし、ユーザーが明確に長形式の CV を望む場合は除きます。公式セットアップ: Managing your profile README

原則	してください	避けてください
長さ	スキャン可能なセクション; ファイルが本当に長い場合を除き ToC を省略	ここに「500～1,500 字は製品リポジトリの標準」を適用
見出し	### ブロック（例: 何をしているか·オープンソース·接続先）で目で確認できるように	多くのネストされた ## + 改行なしの長いナレーション
リンク	各主要 URL を 1 回のみ Find me/Connect 行（または バッジ または スリムテーブル—同じ宛先を 3 つすべてで繰り返さない）に記載	バッジ、テーブル、本文で同じサイト/LinkedIn/メールを複製
リポジトリブロック	太字のリポジトリ名 + ≤2 短行 + 最大 1 コピペコマンド（例: npx skills add …）—「フラグシップ OSS」用に人気のあるプロフィールで使用される同じスキャンパターン; リポジトリの完全な README をクローンしない	フル機能マトリックス、changelog、またはインストールドキュメントをプロフィールファイルに貼り付け
レイアウト	名前 + タグライン + バッジのみ に対してオプションの 中央配置 ヘッダー（<div align="center"）; 本文は読みやすさのため左配置 markdown に	全 README を中央ラップ
オプションウィジェット	コンパクトな Shields（フラットスタイル）; オプションの github-readme-stats / star-history — サードパーティ、コンバージョン/ソーシャルプルーフ として扱い、コア SEO ではない	同じ CTA がテキストで繰り返されている場合の for-the-badge バッジの壁

最小限のアウトライン（標準的なプロフィール）:

1. タイトル + 回答ファースト型タグライン（+ スリムなバッジ行）
2. ### 何をしているか — アイデンティティ、プルーフリンク、後で同じ URL を繰り返さない
3. ### オープンソース — 太字のリポジトリリンク + ピッチ + オプションで 1 つのコードフェンス
4. ### 接続先 — デフリンク済みリンクの単一行（サイト·バイオ·ケース·ソーシャル·メール）
5. ### アクティビティ（オプション）— 小さな github-readme-stats + star-history; <img> に alt テキスト

参照パターン（高シグナル、低ノイズ）: alchaincyf などのスキャンファーストプロフィール — 短い ### ブロック、太字の製品/リポジトリ名、1 つの「接続先」クラスター

エンティティハブパターン: 人物が正規サイトを持っている場合、冒頭行 でそれをリードし、同じ URL を Pinned / プロフィール About（使用する場合）に反映して、サイト ↔ GitHub OSS が entity-seo で揃ったままになるようにします。

プロフィール README チェックリスト（短版）

• H1 + 1 回答ファースト型タグライン（キーワード: ロール、スタック、ドメイン）
• 正規 アウトバウンド リンク（サイト、ソーシャル、メール）重複排除済み
• ピン留め リポジトリ（≤6）が README で語られるストーリーと一致
• オプション: アクティビティ セクション — 統計情報/star-history を 1 つの見出しでグループ化；ウィジェットを散らさない
• 最終更新日 脚注で鮮度（GEO シグナル）を確認

リポジトリホーム: レイアウトマップ

エリア	一般的な内容	SEO/運用メモ
メインカラム	ファイルリスト; レンダリングされた ルート README 下	最初の画面と H2/H3 がほとんどのナレーションを運ぶ
About サイドバー	説明、ウェブサイト、トピック、リリースショートカット、ライセンス、言語	Description と README の第 1 段落を一致させてください; ウェブサイト は主要なアウトバウンド CTA と一致する必要があります
その他のタブ	Issues、PR、Actions など	エンゲージメント＆鮮度シグナル

ウェブサイトフィールド: リポジトリ Settings / About 編集経由で保持; README リンクと一致する 1 つの正規ドキュメントまたは製品 URL を優先

サイト内ディスカバリー（高レベル）

エントリ	役割	注意点
Trending	時間的なウィンドウ可視性	公式が明かされていません; ランキングを約束しない
Explore	コレクション、テーマ、プログラム	パターンと季節的キャンペーンに有用
Topics	リポジトリトピックに関連するトピックページ	Topics メタデータと一致（下の Topics セクション参照）
Search	リポジトリとユーザー全体でクエリ	README + About + topics がマッチ品質を駆動

UI と URL は進化します; github.com で確認してください。

flowchart LR
  discovery[ディスカバリーまたは紹介]
  home[リポジトリホーム]
  readme[README と About]
  outbound[サイトまたはドキュメント]

  discovery --> home
  home --> readme
  readme --> outbound

リポジトリ名、About、README（SEO/GEO 優先度）

ランキング重量（GitHub + Google）: リポジトリ名 & About ≈ 最高; Topics ≈ 高; README ≈ 高

リポジトリ名

実践	ガイドライン
説明的	プロジェクトの内容をヒント
キーワード豊富	主要キーワードを含める（my-project ではなく markdown-editor）
ハイフン	単語を分ける（react-component-library）
簡潔	短い = 覚えやすく、共有可能

About セクション（説明）

制限	ガイドライン
350 文字	ハード制限; GitHub が実装
約 128 文字	簡潔さに最適; 完全に表示されることが多い
コンテンツ	主要キーワード + 自然な変動; 何をするか、誰のためか; スペースがあればウェブサイトまたはドキュメントへのリンク

例: 「TypeScript で構築された、ライブプレビュー、構文強調表示、PDF へのエクスポート機能を備えた React 用の高速で軽量なマークダウンエディタ。」

トピック

制限	ガイドライン
6～20 トピック	最大 20; 6～10 を推奨
各約 50 文字	トピックごと
フォーマット	小文字、ハイフン、数字のみ
ミックス	技術（react、python）、目的（cli、library）、カテゴリ（seo、ai-tools）、コミュニティ（hacktoberfest）

過少利用 ですが、発見と GEO に非常に効果的です。

README 構造 & コンポーネント

特に記載がない限り、リポジトリ（プロジェクト）README をターゲットにしています。プロフィール README オーバーライド: より短く、セクション数が少ない — 上の プロフィール README（username/username） を参照してください。

セクション	目的	SEO/GEO
タイトル + タグライン	H1 + 1～2 文のサマリー; 第 1 段落のキーワード	重要; 最初の 100 語は重み付け
目次	H2/H3 へのリンク; 長いリポジトリ README 向け（多くの場合 >500 字）。プロフィール README では通常スキップ	ナビゲーション; クロール性
インストール/クイックスタート	前提条件; 正確なコマンド; コピペ対応	ユースケースの明確性
使用例	コードブロック; 一般的なシナリオ	引用可能; 抽出可能
スクリーンショット/GIF	デモ、出力; alt テキスト必須	エンゲージメント; アクセシビリティ
バッジ	ビルド、バージョン、ライセンス	信頼シグナル
Contributing	CONTRIBUTING.md へのリンク	コミュニティシグナル
ライセンス	LICENSE へのリンク	完全性

字数: ハード制限なし; 500～1,500 字 は 製品/ライブラリ リポジトリで標準的です。価値でリードし、後で展開。プロフィール README: 密で簡潔 を優先—長形式は正規サイトまたはピン留めリポジトリ独自の README に属します。

README GEO/AI 引用

実践	ガイドライン
回答ファースト	最初の 1～2 文で直接回答（40～60 字）; プロフィール README は H1 下の 1 つのパンチの効いたタグライン に圧縮できます（残りはアウトバウンドリンクが実行）
短い段落	最大 2～3 文; 抽出可能な明確性
質問形式の見出し	関連がある場合、H2/H3 を質問として（リポジトリ README）; プロフィール README では任意 — セクション の明確性が質問フレージングより重要
データ含有	統計情報、数字; 引用されたコンテンツは約 40% データを含む可能性が高い
鮮度	定期的に更新; 引用されたコンテンツの約 76% は 30 日以内に更新

エンティティシグナル: 明確なプロジェクト名、著者、メンテナー; 一貫したアイデンティティ。entity-seo を参照してください。

README チェックリスト — リポジトリ（デフォルト）

• キーワード付きプロジェクトタイトル
• 第 1 段落の簡潔な説明
• H2/H3 構造; 画像用の alt テキスト
• インストール + 使用例
• スクリーンショットまたはデモ
• バッジ; Contributing; ライセンス
• 関連ドキュメント/リポジトリへの内部リンク
• リポジトリ上の 6～20 トピック

（プロフィール username/username の場合、上記のすべての行が適用されるわけではなく、Surfaces の下の短版 プロフィール README チェックリスト を使用してください。）

GitHub での Parasite SEO

主要サーフェス

サーフェス	使用
README	リポジトリのランディングページ; キーワード最適化サマリー、見出し、リンク
GitHub Pages	スタティックサイト; ブログ、FAQ、ドキュメント; 追加のランキング機会
Gists	マイクロコンテンツ; ロングテールキーワード; リポジトリまたは外部リソースへのリンク
Wiki	キーワード豊富なドキュメント
Issues	Q&A、ディスカッション; インデックス可能

GitHub Pages と README

サーフェス	役割
README	最初の印象; スター/フォーク; 短いピッチと深いリンク
Pages	マルチページ スタティック サイト: 長いドキュメント、ブログ、changelog

デフォルト URL パターン: ユーザーまたは組織サイト は多くの場合 username.github.io リポジトリを使用して https://username.github.io で配信されます。プロジェクトサイト は指定されたリポジトリから公開され、通常 https://username.github.io/repository/（パスは設定によって異なる可能性があります）に表示されます。About GitHub Pages を参照してください。

制限: ビルドサイズ、帯域幅、ビルド頻度の上限は時間とともに変わります—ユーザーが数字を必要とする場合、このスキルのハード配置済み図ではなく GitHub Pages limits を引用してください。

最適化

要素	実践
リポジトリタイトル	主要キーワード; 説明的; ハイフン
About	350 字 max; キーワード豊富; 主要キーワード + 自然な変動
説明	セカンダリキーワード; ウェブサイトまたはリソースへのリンク
README	キーワード最適化サマリーを最初に; 見出し、箇条書き; スクリーンショット; ドキュメント、チュートリアルへのリンク
Topics/タグ	6～20 の関連トピック; 各 50 文字
GitHub Pages	モバイルフレンドリー; メタデータ; ブログ/FAQ で余分なキーワード

マイクロコンテンツ用の Gists

• 特定のロングテールキーワードをターゲット
• より大きなリポジトリまたは外部リソースにリンク
• コードスニペット、小さなユーティリティを共有

コミュニティエンゲージメント

• Issue と PR に応答; 信頼を構築
• 人気プロジェクトに貢献; バックリンク、可視性
• リポジトリを最新に保つ; 古い = 低い信頼性

GitHub での GEO

要因	実践
README 明確性	明確で引用可能な段落; 直接的な回答
ドキュメント	構造化; AI ツールはよくパースする
エンティティシグナル	明確なプロジェクト、著者アイデンティティ; entity-seo を参照
一貫性	アクティブなメンテナンス; エンゲージメント（スター、フォーク、ウォッチャー）

リポジトリアーキタイプ

アーキタイプ	意図	最初の画面エンファシス
製品/ライブラリ	インストール可能なソフトウェア、SDK、CLI、サービス	インストール、クイックスタート、プルーフ（CI、ライセンス）、サポートパス
キュレーション/リソース	Awesome スタイルのリスト、インデックス	スコープ、キュレーション基準、コントリビューション規則
個人プロフィールハブ	パブリック username/username プロフィール上の README	アイデンティティ + 正規リンク + ピン留め フラグシップリポジトリ; 製品 README の完全なコピーなし

メトリクスをタイプに合わせます: キュレーションリストは信頼とバックリンクに最適化; 製品リポジトリは採用と issue 品質に最適化。

キュレーション/ナビゲーションリスト（Awesome スタイル）

Awesome リスト = GitHub 上のキュレーション、トピック固有のリソースリスト。ナビゲーションディレクトリのように機能; トラフィック、バックリンク、発見が高い。sindresorhus/awesome（441K+ スター）はマスターリスト; 6,500+ 個のキュレーションリストがトピック全体に存在します。

カテゴリ別の例

カテゴリ	例
マスターリスト	sindresorhus/awesome — すべての awesome リストのハブ
SEO/マーケティング	awesome-seo、awesome-ai-seo、bmpi-dev/awesome-seo
AI/ML	awesome-ai-tools、AITreasureBox、awesome-ai
開発ツール	awesome-tools、awesome-cli、awesome-nodejs
言語	awesome-python、awesome-javascript、awesome-go
フロントエンド/バックエンド	awesome-react、awesome-vue、awesome-django
その他	awesome-security、awesome-gaming、awesome-databases

作成時期

• ニッチなキュレーション対象の多くの質の高いリソースがある
• 既存のリストがあなたのトピックをカバーしていない
• バックリンク資産とトピック権威が必要

リスト構造（sindresorhus/awesome ガイドライン）

要素	実践
タイトル	明確で焦点を絞った（例: 「Awesome SEO」、「Awesome AI Tools」）
説明	簡潔; スコープが明確
セクション	カテゴリ化（例: チュートリアル、ツール、記事）
アイテム	キュレーション、非収集; 推奨するものだけを含める
アイテムフォーマット	- [名前](URL) - なぜ awesome なのかの簡単な説明
ライセンス	CC0 または同等
Contributing	PR プロセス用の contributing.md

リストに記載 vs. 作成

アクション	使用
既存リストに送信	PR を awesome-* リポジトリに; リスト形式に従う; メンテナーに連絡
新しいリスト作成	あなたのニッチのリストが存在しない場合; awesome ガイドラインに従う
リスト間リンク	主題をより良くカバーする他の awesome リストにリンク

ディスカバリー

• sindresorhus/awesome — Awesome リストのマスターリスト
• AwesomeSearch — Awesome リスト全体で検索
• more-awesome — Awesome リストのディレクトリ

一般的なミス

ミス	避けてください
エンゲージメント無視	Issue/PR に応答しないと信頼が低下
不規則な更新	古いリポジトリは非活動をシグナル
不完全なドキュメント	明確な説明がないとユーザーを混乱させる
ジェネリックタイトル	キーワードがないと発見性が低下
薄い awesome リスト	低品質またはキュレーション不足のアイテムは信頼性を損なう
プロフィール README = 製品 README	インストール/Contributing/スクリーンショット多数のテンプレートを username/username に貼り付け — プロフィール チェックリストを使用
プロフィール上のリンク散乱	同じホームページ/ソーシャル/メールをバッジ、テーブル、長いコピーで繰り返す — 統合

出力フォーマット

• ユースケース（parasite SEO/GEO/キュレーションリスト）
• サーフェススコープ（プロフィール vs. 特定リポジトリ; README vs. Pages）
• リポジトリ名、About、Topics（メタデータを最適化する場合）
• サーフェス（README、Pages、gist、awesome リポジトリ）
• README 構造（セクション、字数、該当する場合は GEO 実践）— プロフィール README の場合、上記 プロフィール README セクションに従って 短い アウトライン + デフリンク済みリンク + オプションウィジェットを引用
• 最適化（キーワード、構造、リンク）
• すぐに使える コピーまたは構造（該当する場合）

関連スキル

• parasite-seo: Parasite SEO 戦略; GitHub を Tier 2 技術プラットフォームとして
• generative-engine-optimization: GEO 戦略; AI 引用用 GitHub
• open-source-strategy: オープンソース商品化; GitHub を主要配布として
• directory-submission: ディレクトリと キュレーションリスト送信; awesome リストをキュレーションリストとして
• link-building: GitHub をリンク取得として; リポジトリ、gist、awesome リスト
• entity-seo: エンティティシグナル（プロジェクト、著者）; Organization、Person