Your README Is a Landing Page Now

Developers spend their careers making things rank and then ship repositories with a two-line README and no topics. The audience they're not optimizing for is no longer just human.

Say "SEO" to a developer and they picture content marketing — blog posts, keyword reports, the stuff that happens to other people. Say "repo SEO" and they'll assume it's a metaphor. It isn't. GitHub is a search engine with an index, a query language, ranking signals, and a results page. And as of this year, it has something better: it is becoming the retrieval layer that AI coding assistants read when they decide which library to use.

One skill in our directory takes this seriously. agentic-seo-skill by Bhanunamikaze scores 7.8 overall — mid-table, not top-tier — but it contains 16 sub-skills, 89 scripts, and one of those sub-skills runs a full SEO audit of a GitHub repository: README structure, topics, the social preview card. Out of 765 skills, it is the only one that treats a repo as a ranking surface.

What the audit actually checks

The mechanics are concrete, which is why I think this sub-skill deserves more attention than its parent's 7.8 suggests:

• README structure. Does the first screen answer install, minimal usage, and license? Repo search and code search both surface the README, and an evaluator — human or machine — reads the first screen or leaves.
• Topics. The repo's topic tags are the only keyword surface GitHub gives you. They feed repo search ranking and the related-repo graph. Most repos leave them half-empty, which is the equivalent of publishing a page without a title tag.
• Social preview card. The OG image on the repo settings — the card that renders every time the repo link is unfurled in Slack, X, or Reddit. Default card: a screenshot of your file list. It is the difference between a link that looks maintained and a link that looks abandoned, distributed across thousands of impressions you will never see.

The 7.8 itself is instructive: 89 scripts spread across 16 sub-skills is a breadth-over-depth architecture, and our engineering dimension scores exactly that tradeoff. Compare the single-purpose SEO specialists — technical-seo-checker at 9.3, ai-seo at 9.2 — and you can watch the generalist discount in the scores. But the sub-skill is a genuinely original observation, and it's the reason the repo exists in the directory at all.

Why this stopped being optional

Here is the part that changed. When a developer used to pick a library, they searched GitHub, skimmed three READMEs, and chose. That flow still exists. But now there's a second flow: a developer asks their coding assistant which library to use, and the assistant's answer is constrained by what it can retrieve and summarize from the repo — name, description, topics, README.

A repo whose README doesn't state clearly what the library does gets summarized badly, and a badly summarized library loses the recommendation. The assistant isn't being unfair; it's doing exactly what a search engine does with an ambiguous page. The optimization surface is identical: a crawlable, well-structured document that answers the query in the first pass.

This is why I say the README is a landing page now, in the literal sense: it is the page a machine reader lands on when deciding whether to send a human — or an agent — to you.

Repo SEO is developer relations for the agent era

The old DevRel model was a human maintaining a presence — conference talks, issue triage, a charming mascot account. The new one is a repo that a non-human reader can parse correctly. The overlap with classic SEO is almost embarrassing: structured front matter, clear H1-equivalent statement of purpose, complete metadata, an accurate card for social distribution. The agentic-seo-skill audit reads like an on-page checklist from 2014 applied to a different document type, because it is.

The audience is just starting to matter. Most repo traffic is still human, most assistants still hedge on library choice, and a two-line README still converts fine if you're already famous. But the direction is set: agent-mediated library selection is growing, and the repos it will select are the ones legible to it.

Developers already know how to do this work — it's the same discipline they apply to APIs and CLIs, applied to a document. The 7.8-scored skill that pointed it out may not be the last word on the practice. But it's the first one in the directory to say the quiet part out loud: the search engine you never optimized for is now reading your repo, and it's taking notes.