$npx -y skills add avalonreset/legends-github --skill github-seoKeyword research and SEO content optimization for GitHub repositories — descriptions, topics, README content, plus GEO/AI citability.
| 1 | # GitHub SEO -- Keyword Research and Content Optimization |
| 2 | |
| 3 | This is a **data-producing skill**. Its output is consumed by github-readme (for content |
| 4 | optimization) and github-meta (for description and topic selection). It can also run |
| 5 | standalone for SEO strategy analysis. |
| 6 | |
| 7 | ## Headless/API Contract |
| 8 | |
| 9 | For non-interactive systems, use: |
| 10 | |
| 11 | ```bash |
| 12 | python3 scripts/run_headless.py seo --path /path/to/repo |
| 13 | ``` |
| 14 | |
| 15 | That deterministic runner writes `.github-audit/seo-data.json` plus report |
| 16 | artifacts under `.github-audit/output/`. It is intentionally a fallback-grade |
| 17 | cache seeding path: no DataForSEO MCP calls, so keyword volume, difficulty, |
| 18 | intent, AI visibility, and SERP fields are marked unverified. Interactive |
| 19 | `github seo` runs are still the path for live DataForSEO research. |
| 20 | |
| 21 | ## The GitHub SEO Problem (Why This Isn't Normal SEO) |
| 22 | |
| 23 | GitHub repos are NOT traditional websites. You cannot: |
| 24 | - Build backlinks to a README |
| 25 | - Optimize page speed (GitHub controls rendering) |
| 26 | - Add meta tags or schema markup (GitHub generates these) |
| 27 | - Control URL structure (github.com/{owner}/{repo} is fixed) |
| 28 | |
| 29 | **What you CAN control:** |
| 30 | - README content (H1, headings, paragraphs, keywords) -- this IS the SEO page |
| 31 | - Repo description (350 chars, becomes OG description on social shares) |
| 32 | - Topics/tags (feed GitHub Explore and internal search) |
| 33 | - GitHub Pages site (if applicable -- full SEO control there) |
| 34 | |
| 35 | **What DataForSEO does here:** It answers the question "what should I write in my |
| 36 | README, description, and topics so that people find this repo when they Google?" |
| 37 | It does NOT scan the repo as a domain. It discovers keyword opportunities. |
| 38 | |
| 39 | ## The Keyword Opportunity Framework |
| 40 | |
| 41 | Not all keywords are worth targeting. A keyword is only valuable for GitHub if: |
| 42 | |
| 43 | 1. **People actually search for it** (volume > 0) |
| 44 | 2. **GitHub repos can rank for it** (GitHub appears in SERP results) |
| 45 | 3. **The competition is beatable** (difficulty is manageable) |
| 46 | 4. **The intent matches** (informational = good for READMEs) |
| 47 | |
| 48 | ### Opportunity Categories |
| 49 | |
| 50 | | Category | Volume | Difficulty | GitHub in SERP? | Action | |
| 51 | |----------|--------|------------|----------------|--------| |
| 52 | | **Sweet Spot** | 100-5,000/mo | Under 40 | Yes, repos in top 20 | TARGET THESE FIRST -- H1, description, first paragraph | |
| 53 | | **Worth It** | 1,000-10,000/mo | 40-60 | Yes, repos in top 20 | Target in H2 headings and body content | |
| 54 | | **Long Shot** | 10,000+/mo | 60+ | Sometimes | Use variations; may rank over time with stars | |
| 55 | | **Skip** | Any | Any | No GitHub repos rank | Don't waste effort -- Google doesn't serve repos for this | |
| 56 | | **Low Value** | Under 50/mo | Any | Any | Usually not enough traffic -- but see Niche Exception below | |
| 57 | |
| 58 | **Niche Exception:** For ultra-niche repos where the ENTIRE addressable search space |
| 59 | is low volume (e.g., "knife design software" at 40/mo for a parametric knife CAD tool), |
| 60 | a <50/mo keyword may be the BEST keyword available. In these cases, promote the most |
| 61 | relevant low-volume keyword to Sweet Spot if: |
| 62 | 1. It is a near-perfect semantic match for the project's core function |
| 63 | 2. Competition is LOW (difficulty under 20 or no established players) |
| 64 | 3. No higher-volume keywords exist that are equally specific |
| 65 | Mark it as "Sweet Spot (niche)" in the table. A perfectly targeted 40/mo keyword |
| 66 | beats a poorly targeted 390/mo keyword every time. |
| 67 | |
| 68 | **The Sweet Spot is the entire play.** Medium traffic, low competition, GitHub repos |
| 69 | already ranking = a well-optimized README can break into page 1. |
| 70 | |
| 71 | ### Opportunity Score Formula |
| 72 | |
| 73 | For each keyword candidate, calculate: |
| 74 | |
| 75 | ``` |
| 76 | Opportunity Score = Volume × GitHub Viability × Intent Multiplier × Ease Factor |
| 77 | ``` |
| 78 | |
| 79 | Where: |
| 80 | - **Volume**: monthly search volume (raw number) |
| 81 | - **GitHub Viability**: 1.0 if github.com appears in top 10, 0.5 if in top 20, 0.0 if absent |
| 82 | - **Intent Multiplier**: 1.0 for informational, 0.7 for commercial, 0.3 for navigational, 0.1 for transactional |
| 83 | - **Exception for free/open-source tools:** If the project IS the "product" people |
| 84 | are searching to download/use, transactional intent aligns with repo discovery. |
| 85 | Use 0.7 instead of 0.1 for transactional keywords that match the repo's core |
| 86 | function (e.g., "knife design software" for a knife CAD tool, "python linter" |
| 87 | for a linting library). The user searching transactionally WOULD land on GitHub. |
| 88 | - **Ease Factor**: (100 - difficulty) / 100 |
| 89 | |
| 90 | **Example:** |
| 91 | - "python web framework" → 5,400 × 1.0 × 1.0 × 0.28 = 1,512 |
| 92 | - "lightweight python microframework" → 390 × 1.0 × 1.0 × 0.72 = 281 |
| 93 | - "flask vs django" → 2,900 × 1.0 × 0.7 × 0.45 = 914 |
| 94 | - "buy python hosting" → 1,200 × 0.0 × 0.1 × 0.80 = 0 (no GitHub repos rank, transactional) |
| 95 | |
| 96 | Sort by score. The top keywords go into H1, description, and first paragraph. |
| 97 | |
| 98 | ## DataForSEO MCP Integration |
| 99 | |
| 100 | ### Which Tools Matter (and Which Don't) |
| 101 | |
| 102 | Out of 79 DataForSEO MCP tools, only 10 |