github

平台：GitHub

介绍如何利用 GitHub 开展寄生 SEO、GEO（AI 引用）和精选列表创建。GitHub 是 Tier 2 技术权威平台，拥有较高的域名权威度、快速的索引速度和很高的 AI 引用概率。适用于代码库、README、GitHub Pages、gists 和 Awesome 风格的导航列表。

调用时：首次使用时，如果有帮助，可以先用 1–2 句话介绍此技能涵盖的内容及其重要性，然后提供主要输出。后续使用时，或用户要求跳过时，直接提供主要输出。

为什么用 GitHub 做 SEO

因素	影响
域名权威度	DA 较高；代码库、gists 和 Pages 排名良好
快速索引	搜索引擎会频繁抓取 GitHub
AI 引用	ChatGPT、Perplexity 会在技术查询中引用 GitHub；在 GEO 框架中属于 Tier 2
技术专业度	专业度信号强；结构化文档会成为 AI 参考资料
跨平台传播	在 Dev.to、Stack Overflow、论坛等平台分享；扩大曝光度

使用场景

使用场景	格式	目的
寄生 SEO	代码库、README、Pages、gists	借助 GitHub 的权威度提升排名并获取反向链接
GEO	文档、教程、精选列表	AI 工具会在技术问题的回答中引用 GitHub
精选列表 / 导航列表	Awesome 风格的代码库	创建特定主题的资源目录；获取反向链接并提高发现度

展示位置：个人资料与代码库

展示位置	内容	优化重点
个人资料 README	与用户名同名的公开代码库；根目录下的 README.md 会显示在个人资料中	个人品牌、核心链接、社会认同
置顶项目	个人资料中最多可置顶 6 个代码库或 gists	展示重点项目；与实体信号（entity-seo）保持一致
单个代码库 README	每个代码库 Code 标签页中的根目录 README.md	产品落地页；安装说明、证明材料、行动号召

更改普通代码库的 README 不会更改个人资料横幅，除非该内容属于个人资料 README代码库，或从中链接到该内容。

个人资料 README（username/username）

它与产品仓库的 README 不同。 除非用户明确需要长篇简历，否则应将渲染后的内容控制在约 15–40 行，重点突出身份信息和导航。官方设置说明：管理个人资料 README。

原则	建议	避免
长度	使用简短、便于浏览的章节；除非文件确实很长，否则省略目录	将“产品仓库通常为 500–1,500 字”套用到这里
标题	使用 ### 分块（例如 我做什么 · 开源 · 联系我），便于快速浏览	使用大量嵌套的 ##，并在没有分段的情况下写长篇叙述
链接	每个主要 URL 只出现一次，放在“联系我 / 联系方式”一行中（或使用徽章，或使用简洁的表格；不要三者都重复相同的目标地址）	在徽章、表格和正文中重复网站、LinkedIn 和电子邮箱
仓库区块	加粗仓库名称 + 不超过 2 行的简短介绍 + 至多一条可复制粘贴的命令（例如 npx skills add …）——采用热门个人资料介绍“旗舰开源项目”时常见的浏览方式，无需复制整个仓库 README	将完整的功能矩阵、变更日志或安装文档粘贴到个人资料文件中
布局	可选用居中的页眉（<div align="center">），仅包含姓名 + 标语 + 徽章；正文使用左对齐 Markdown，方便阅读	将整个 README 都居中
可选组件	使用紧凑的 Shields（扁平样式）；可选添加 github-readme-stats / star-history——它们是第三方组件，应视为转化 / 社会认同工具，而非核心 SEO 内容	当正文中已重复相同的行动号召时，还堆满 for-the-badge 徽章

精简大纲（典型个人资料）：

1. 标题 + 先给出答案的标语（+ 精简的徽章行）。
2. ### 我做什么——介绍身份和证明链接，后文不再重复相同 URL。
3. ### 开源——加粗的仓库链接 + 简介 + 可选的一个代码块。
4. ### 联系我——一行去重后的链接（网站 · 简介 · 案例 · 社交账号 · 电子邮箱）。
5. ### 活动（可选）——精简展示 github-readme-stats + star-history；为 <img> 添加替代文本。

参考样式（高信号、低噪声）：浏览 alchaincyf 等个人资料——使用简短的 ### 分块、加粗的产品 / 仓库名称，以及一个“联系我”链接集合。

实体中心模式： 当个人有规范网站时，应在开篇行首先介绍该网站，并在 Pinned / 个人资料简介（如有使用）中使用相同 URL，确保网站 ↔ GitHub 开源项目保持一致，服务于 实体 SEO。

个人资料 README 检查清单（简短版）

• H1 + 一条先给出答案的标语（关键词：职位、技术栈、领域）
• 规范的出站链接（网站、社交账号、电子邮箱）已去重
• 置顶仓库（≤6 个）与 README 所讲述的内容一致
• 可选：活动章节——将统计信息 / star-history 放在同一个标题下，而不是分散展示各类组件
• 添加最后更新脚注，体现内容新鲜度（GEO 信号）

仓库主页：布局图

区域	典型内容	SEO / 运维说明
主栏	文件列表；下方显示渲染后的根目录 README	首屏和 H2 / H3 承载大部分叙述内容
About 侧栏	简介、网站、主题、发布版本快捷入口、许可证、语言	保持简介与 README 首段一致；网站应与主要出站行动号召一致
其他标签页	Issues、PR、Actions 等	互动度和内容新鲜度信号

网站字段：通过仓库的 Settings / About 编辑进行维护；建议使用一个与 README 链接一致的规范文档或产品 URL。

站内发现（概述）

入口	作用	注意事项
Trending	按时间窗口展示曝光度	公式不公开；切勿承诺排名
Explore	集合、主题、计划	适用于了解规律和季节性活动
Topics	与仓库 Topics 关联的主题页面	与 Topics 元数据一致（见下文 Topics 部分）
Search	搜索仓库和用户	README、About 和 Topics 决定匹配质量

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

仓库名称、About 和 README（SEO/GEO 优先级）

排名权重（GitHub + Google）：仓库名称和 About ≈ 最高；Topics ≈ 高；README ≈ 高。

仓库名称

做法	指南
描述性	提示项目的功能
包含丰富关键词	加入主要关键词（markdown-editor，而不是 my-project）
使用连字符	用连字符分隔单词（react-component-library）
简洁	越短越容易记住和分享

About 部分（描述）

限制	指南
350 个字符	硬性限制；由 GitHub 强制执行
约 128 个字符	简洁表达的理想长度；通常可完整显示
内容	主要关键词 + 自然变体；说明项目的功能和目标用户；如有空间，附上网站或文档链接

示例：“一款快速、轻量的 React Markdown 编辑器，支持实时预览、语法高亮和导出为 PDF。使用 TypeScript 构建。”

Topics

限制	指南
6–20 个 Topics	最多 20 个；建议使用 6–10 个
每个约 50 个字符	单个 Topic 的长度
格式	仅使用小写字母、连字符和数字
组合	技术（react、python）、用途（cli、library）、类别（seo、ai-tools）、社区（hacktoberfest）

Topics 的利用率偏低，但对提升可发现性和 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 下方一句有力的标语
段落简短	最多 2–3 句；清晰易提取
问题式标题	在适用时使用问题形式的 H2/H3（仓库 README）；对于个人资料 README，可选——章节清晰度比问题式表述更重要
加入数据	统计数据、数字；被引用的内容包含数据的可能性约高 40%
保持内容新鲜	定期更新；约 76% 的被引用内容在 30 天内更新过

实体信号：项目名称、作者和维护者信息清晰；身份保持一致。参见 entity-seo。

README 检查清单——仓库（默认）

• 包含关键词的项目标题
• 在第一段中简洁描述
• 使用 H2/H3 结构；为图片添加替代文本
• 安装和使用示例
• 截图或演示
• 徽章；贡献指南；许可证
• 链接到相关文档/仓库
• 仓库包含 6–20 个主题

（对于个人资料 username/username，请使用“页面类型”下较短的个人资料 README 检查清单——上述条目并非全部适用。）

GitHub 上的寄生式 SEO

关键页面类型

页面类型	用途
README	仓库的落地页；经过关键词优化的摘要、标题和链接
GitHub Pages	静态网站；博客、常见问题、文档；额外的排名机会
Gist	微型内容；长尾关键词；链接到仓库或外部资源
Wiki	包含丰富关键词的文档
Issues	问答、讨论；可被索引

GitHub Pages 与 README

页面类型	作用
README	第一印象；Stars/复刻数；简短介绍和深层链接
Pages	多页面静态网站：长篇文档、博客、更新日志

默认 URL 格式：用户或组织网站通常使用 username.github.io 仓库，并通过 https://username.github.io 提供服务。项目网站从指定仓库发布，通常显示在 https://username.github.io/repository/（路径可能因设置而异）。请参阅 关于 GitHub Pages。

限制：构建大小、带宽和构建频率上限会随时间变化——用户需要具体数值时，请引用 GitHub Pages 限制，不要在此技能中硬编码数值。

优化

元素	做法
仓库标题	使用主要关键词；描述清晰；用连字符分隔
About	最多 350 个字符；包含丰富关键词；主要关键词 + 自然变体
描述	加入次要关键词；链接到网站或资源
README	开头放置经过关键词优化的摘要；使用标题、项目符号；添加截图；链接到文档、教程
主题/标签	6–20 个相关主题；每个不超过 50 个字符
GitHub Pages	适配移动设备；添加元数据；通过博客/常见问题增加关键词

用 Gist 发布微型内容

• 针对特定长尾关键词
• 链接回更大的仓库或外部资源
• 分享代码片段、小型实用工具

社区参与

• 回复 Issues 和 PR；建立信任
• 为热门项目做贡献；获得反向链接和曝光
• 保持仓库更新；过时会降低可信度

GitHub 上的 GEO

因素	做法
README 清晰度	段落清晰、可引用；直接回答问题
文档	结构清晰；便于 AI 工具解析
实体信号	明确项目和作者身份；参阅 entity-seo
一致性	持续维护；积极参与（Stars、复刻数、关注者）

仓库类型

类型	目标	首屏重点
产品/库	可安装的软件、SDK、CLI、服务	安装、快速入门、可信证明（CI、许可证）、支持渠道
精选/资源	Awesome 风格的列表、索引	范围、筛选标准、贡献规则
个人资料中心	个人资料中的公开 username/username README	身份 + 规范链接 + 置顶的旗舰仓库；不重复完整的产品 README

根据类型匹配指标：精选列表应以信任度和反向链接为优化目标；产品仓库应以采用率和 Issues 质量为优化目标。

精选/导航列表（Awesome 风格）

Awesome 列表 = GitHub 上按主题整理的精选资源列表。它们发挥导航目录的作用，带来大量流量、反向链接和发现机会。sindresorhus/awesome 是主列表（441K+ Stars）；各主题中已有 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”）
描述	简洁；明确说明范围
章节	按类别划分（例如，教程、工具、文章）
条目	精选，而非收集；只收录你推荐的内容
条目格式	- [Name](URL) - Brief description of why it's awesome
许可证	CC0 或类似许可证
贡献	使用 contributing.md 说明 PR 流程

收录到现有列表还是创建新列表

操作	用途
提交到现有列表	向 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，请按照上文的个人资料 README章节，列出简短大纲、去重后的链接和可选小组件
• 优化（关键词、结构、链接）
• 适用时提供可直接使用的文案或结构

相关技能

• parasite-seo：寄生式 SEO 策略；将 GitHub 作为 Tier 2 技术平台
• generative-engine-optimization：GEO 策略；利用 GitHub 获取 AI 引用
• open-source-strategy：开源商业化；将 GitHub 作为主要分发渠道
• directory-submission：目录提交和策展列表提交；将 awesome 列表作为策展列表
• link-building：利用 GitHub 获取链接；仓库、gist、awesome 列表
• entity-seo：实体信号（项目、作者）；Organization、Person