github

プラットフォーム：GitHub

パラサイトSEO、GEO（AI 引用）、厳選リスト作成における GitHub の活用方法を解説します。GitHub は Tier 2 の技術的権威プラットフォームです。ドメイン権威が高く、インデックス登録が速く、AI に引用される可能性が非常に高いのが特徴です。リポジトリ、README、GitHub Pages、gist、Awesome 形式のナビゲーションリストに活用できます。

利用時：初回は、役立つ場合、まずこのスキルの対象範囲と重要性を1～2文で説明してから、主な出力を提示してください。2回目以降、またはユーザーから省略を求められた場合は、主な出力から始めてください。

SEO における GitHub の利点

要素	効果
ドメイン権威	DA が高く、リポジトリ、gist、Pages が上位表示されやすい
インデックス登録の速さ	検索エンジンが GitHub を頻繁にクロールする
AI による引用	ChatGPT、Perplexity は技術的なクエリで GitHub を引用します。GEO フレームワークでは Tier 2 に分類されます
技術的な専門性	専門性を示す強いシグナルとなり、構造化されたドキュメントは AI の参考資料になります
クロスプラットフォーム	Dev.to、Stack Overflow、フォーラムで共有でき、認知度が高まります

ユースケース

ユースケース	形式	目的
パラサイト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 行程度で アイデンティティ + ナビゲーション に最適化してください。公式セットアップ: プロフィール README の管理。

原則	やること	避けること
長さ	短くスキャンしやすいセクション。ファイルが本当に長くない限り 目次は省略	ここに「製品リポジトリで一般的な 500〜1,500 語」を当てはめること
見出し	ざっと見渡せる ### ブロック(例: What I do · Open source · Find me)	多数のネストした ## + 区切りのない長い叙述
リンク	主要な URL はそれぞれ Find me / Connect 行に 1 回だけ(またはバッジ もしくは スリムな表 — 同じ遷移先を 3 つすべてで繰り返さない)	サイト / LinkedIn / メールをバッジ・表・本文で重複させること
リポジトリブロック	リポジトリ名を太字 + 短い 2 行以内 + コピペ用コマンドは最大 1 つ(例: npx skills add …) — 人気プロフィールが「旗艦オープンソース」で使うのと同じスキャンパターンで、リポジトリの README 全文を複製しない	機能一覧表・変更履歴・インストールドキュメントをプロフィールファイルに貼り付けること
レイアウト	任意で 中央寄せ のヘッダー(<div align="center">)を 名前 + タグライン + バッジのみ に使用。本文は読みやすさのため左寄せ Markdown のまま	README 全体を中央寄せで包むこと
任意のウィジェット	コンパクトな Shields(flat スタイル)。任意で github-readme-stats / star-history — サードパーティ であり、コア SEO ではなく コンバージョン / ソーシャルプルーフ として扱う	同じ CTA をテキストで繰り返しているのに for-the-badge バッジを壁のように並べること

最小構成(典型的なプロフィール):

1. タイトル + 結論先出しのタグライン(+ スリムなバッジ行)。
2. ### What I do — アイデンティティ、証拠となるリンク。同じ URL を後で繰り返さない。
3. ### Open source — 太字のリポジトリリンク + ピッチ + 任意で 1 つのコードフェンス。
4. ### Find me — 重複を排除したリンクを 1 行で(サイト · プロフィール · 事例 · SNS · メール)。
5. ### Activity(任意) — 小さな github-readme-stats + star-history。<img> には alt テキスト を。

参考パターン(高シグナル・低ノイズ): alchaincyf のようなスキャン重視のプロフィール — 短い ### ブロック、太字の製品 / リポジトリ名、1 つの「find me」クラスタ。

エンティティハブパターン: その人に正規のサイトがある場合、冒頭行 でそれを先頭に持ってきて、同じ URL を Pinned / プロフィールの About(使用する場合)にも反映し、サイト ↔ GitHub オープンソース が エンティティ SEO のために揃うようにします。

プロフィール README チェックリスト(短縮版)

• H1 + 1 つ の結論先出しタグライン(キーワード: 役割、スタック、ドメイン)
• 正規の アウトバウンド リンク(サイト、SNS、メール)が 重複排除 されている
• Pinned リポジトリ(6 件以内)が README で語るストーリーと一致している
• 任意: Activity セクション — ウィジェットを散らばせるのではなく、グループ統計 / star-history を 1 つの見出しの下にまとめる
• 鮮度のための 最終更新 脚注(GEO シグナル)

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

領域	典型的な内容	SEO / 運用のメモ
メインカラム	ファイル一覧。その下にレンダリングされた ルート README	ファーストビューと H2/H3 が叙述の大部分を担う
About サイドバー	Description、Website、Topics、リリースへのショートカット、ライセンス、言語	Description と README の最初の段落を一致させる。Website は主要なアウトバウンド CTA と一致させる
その他のタブ	Issues、PRs、Actions など	エンゲージメントと鮮度のシグナル

Website フィールド: リポジトリの Settings / About 編集で管理します。README のリンクと揃えた 1 つの正規のドキュメントまたは製品 URL を推奨します。

サイト内での発見（概要）

項目	役割	注意点
トレンド	期間ごとの可視性	算出方法は非公開です。ランキングを約束しないでください
探索	コレクション、テーマ、プログラム	傾向や季節ごとのキャンペーンを把握するのに役立ちます
トピック	リポジトリのトピックに紐づくトピックページ	トピックのメタデータと連動します（下記の「トピック」セクションを参照）
検索	リポジトリやユーザーを横断した検索	README、概要、トピックが検索精度を左右します

UI と URL は変更されるため、github.com で確認してください。

flowchart LR
  discovery[Discovery or referral]
  home[Repository home]
  readme[README and About]
  outbound[Site or docs]

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

リポジトリ名、概要、README（SEO/GEO で優先）

ランキングへの影響度（GitHub + Google）：リポジトリ名と概要 ≈ 最も高い、トピック ≈ 高い、README ≈ 高い。

リポジトリ名

実践方法	ガイドライン
内容が伝わる名前	プロジェクトの機能がわかるようにします
キーワードを盛り込む	主要なキーワードを含めます（my-project ではなく markdown-editor）
ハイフンを使う	単語を区切ります（react-component-library）
簡潔にする	短いほど覚えやすく、共有しやすくなります

概要セクション（説明）

制限	ガイドライン
350 文字	厳密な上限です。GitHub によって適用されます
約 128 文字	簡潔さを重視する場合に最適で、全文が表示されることがよくあります
内容	主要なキーワードと自然な言い換えを含めます。機能と対象ユーザーを説明し、文字数に余裕があればウェブサイトやドキュメントへのリンクを追加します

例：「ライブプレビュー、構文ハイライト、PDF エクスポートに対応した、React 向けの高速で軽量な Markdown エディターです。TypeScript で構築されています。」

トピック

制限	ガイドライン
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 文の要約。最初の段落にキーワードを含めます	重要。最初の 100 語が重視されます
目次	H2/H3 へのリンク。長いリポジトリ README（多くの場合 500 語超）に使用します。プロフィール README では通常省略します	ナビゲーション、クロールのしやすさ
インストール／クイックスタート	前提条件、正確なコマンド、コピー＆ペーストですぐ使える内容	ユースケースの明確化
使用例	コードブロック、一般的なシナリオ	引用・抽出しやすい内容
スクリーンショット／GIF	デモ、出力。代替テキストが必要です	エンゲージメント、アクセシビリティ
バッジ	ビルド、バージョン、ライセンス	信頼性を示す情報
コントリビューション	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 チェックリスト — リポジトリ（デフォルト）

• キーワードを含むプロジェクトタイトル
• 最初の段落に簡潔な説明
• H2/H3 構成；画像の代替テキスト
• インストール方法＋使用例
• スクリーンショットまたはデモ
• バッジ；コントリビューション；ライセンス
• 関連ドキュメント／リポジトリへの内部リンク
• リポジトリに6～20個のトピック

（プロフィール username/username の場合は、Surfacesの下にある短い プロフィールREADMEチェックリスト を使用してください。上記のすべての項目が当てはまるわけではありません。）

GitHubでのパラサイトSEO

主なサーフェス

サーフェス	用途
README	リポジトリのランディングページ；キーワードを最適化した概要、見出し、リンク
GitHub Pages	静的サイト；ブログ、FAQ、ドキュメント；追加の検索順位向上の機会
Gist	マイクロコンテンツ；ロングテールキーワード；リポジトリまたは外部リソースへのリンク
Wiki	キーワードを豊富に含むドキュメント
Issue	Q&A、ディスカッション；インデックス登録可能

GitHub PagesとREADMEの比較

サーフェス	役割
README	第一印象；スター／フォーク；短い紹介と詳細リンク
Pages	複数ページの静的サイト：長いドキュメント、ブログ、変更履歴

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

制限：ビルドサイズ、帯域幅、ビルド頻度の上限は時間とともに変わります。このスキルで数値を固定して記載するのではなく、数値が必要な場合はGitHub Pagesの制限を参照してください。

最適化

要素	実践方法
リポジトリタイトル	主要キーワード；説明的な内容；ハイフンを使用
概要	最大350文字；キーワードを豊富に含める；主要キーワード＋自然な言い換え
説明	副次的なキーワード；ウェブサイトまたはリソースへのリンク
README	最初にキーワードを最適化した概要；見出し、箇条書き；スクリーンショット；ドキュメントやチュートリアルへのリンク
トピック／タグ	関連性の高いトピックを6～20個；各50文字
GitHub Pages	モバイル対応；メタデータ；追加キーワード用のブログ／FAQ

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

• 特定のロングテールキーワードをターゲットにする
• 大規模なリポジトリまたは外部リソースへリンクする
• コードスニペットや小規模なユーティリティを共有する

コミュニティへの参加

• 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 — あらゆる素晴らしいリストのハブ
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」）
説明	簡潔で、対象範囲が明確
セクション	カテゴリ別に分類する（例：チュートリアル、ツール、記事）
項目	ただ集めるのではなく、厳選する。おすすめするものだけを含める
項目の形式	- [Name](URL) - Brief description of why it's awesome
ライセンス	CC0 など
貢献方法	PR の手順を記載した contributing.md

掲載を依頼するか、作成するか

アクション	用途
既存のリストに申請する	awesome-* リポジトリに PR を送る。リストの形式に従い、メンテナーに連絡する
新しいリストを作成する	ニッチな分野にリストがない場合。awesome のガイドラインに従う
リスト同士をリンクする	より適切に対象を扱っている他の awesome リストにリンクする

見つけてもらう方法

• sindresorhus/awesome — awesome リストのマスターリスト
• AwesomeSearch — awesome リストを横断検索
• more-awesome — awesome リストのディレクトリ

よくある間違い

間違い	避ける方法
エンゲージメントを無視する	issue／PR に返信しないと、信頼が損なわれます
更新が不定期	古いリポジトリは、活動が止まっている印象を与えます
ドキュメントが不十分	明確な説明がないと、ユーザーを困惑させます
ありきたりなタイトル	キーワードがないと、見つけてもらいにくくなります
内容の薄い awesome リスト	質の低い項目や厳選されていない項目は、信頼性を損ないます
プロフィール README を製品 README と同じにする	username/username にインストール手順／貢献方法／スクリーンショットが多いテンプレートを貼り付けるのではなく、プロフィールのチェックリストを使用します
プロフィール上のリンクが散乱している	同じホームページ／ソーシャルメディア／メールアドレスがバッジ、表、長文に繰り返し掲載されている場合は、まとめます

出力形式

• ユースケース（寄生型 SEO / GEO / 厳選リスト）
• 対象範囲（プロフィールか特定のリポジトリか、README か Pages か）
• リポジトリ名、About、Topics（メタデータを最適化する場合）
• 掲載場所（README、Pages、gist、awesome リポジトリ）
• README の構成（セクション、語数、該当する場合は GEO の実践方法）— プロフィール README の場合は、上記の Profile README セクションに従って、簡潔な概要、重複を除いたリンク、任意のウィジェットを記載します
• 最適化（キーワード、構成、リンク）
• 該当する場合は、すぐに使える文章または構成

関連スキル

• parasite-seo：寄生型 SEO 戦略。GitHub を第 2 層の技術プラットフォームとして活用
• generative-engine-optimization：GEO 戦略。AI による引用のために GitHub を活用
• open-source-strategy：オープンソースの収益化。主要な配布先として GitHub を活用
• directory-submission：ディレクトリや厳選リストへの申請。awesome リストを厳選リストとして活用
• link-building：リンク獲得に GitHub を活用。リポジトリ、gist、awesome リスト
• entity-seo：エンティティシグナル（プロジェクト、著者）。Organization、Person