How I Indexed 2,000 Claude Code Skills (And What the Install Data Says About AI Coding in 2026) The article describes how the author built a ranked, filterable index of nearly 2,000 public Claude Code skills at orangebot.ai/skills, addressing the lack of a searchable, install-weighted directory in the official registry. The author explains their deliberately simple technical stack—a single JSON file updated by a daily cron job and served by a Next.js page—to minimize operational overhead and avoid database complexity. The post also details an SEO crisis where Google was indexing the page but showing a low 0.12% click-through rate due to missing metadata and empty client-side rendering, which the author diagnosed and began fixing. The problem: 2,000 skills, no map Claude Code skills exploded across 2025 and into 2026. The official registry at skills.sh https://skills.sh and the parallel ecosystem on GitHub now expose well over 2,000 public skills — covering everything from frontend-design patterns to azure-deploy to nano-banana-pro image generation. The format won. Every serious AI coding agent — Claude Code, Cursor, OpenSeek, Codex — now ships some flavor of "loadable context package". But there is no ranked, install-weighted, searchable index. The registry lists skills alphabetically, paginates them across dozens of pages, and doesn't surface install volume in a way you can sort. You discover a useful skill one of three ways: someone tweets it, you scroll forever, or you already know the author/repo combo. None of those scale past a few hundred skills. So I built one. orangebot.ai/skills https://orangebot.ai/skills is a ranked, filterable index of 1,998 public Claude Code skills sorted by weekly install volume, tagged by domain, with individual detail pages for the top 50 highest-installed entries. It is the page I wanted six months ago and didn't have. This post is the build log. Three parts: the stack boring on purpose , the SEO crisis I walked into and the fix that shipped today, and what the install data actually says about where AI coding tools are headed in 2026. Source registry: skills.sh https://skills.sh . The catalog: orangebot.ai/skills https://orangebot.ai/skills . The stack zero infrastructure surprises I picked the most boring stack I could justify, on purpose. The catalog is not where I want to spend operational attention — the data pipeline and the SEO are. - Next.js 16 App Router . Server Components by default so Google sees real HTML, not a JS shell. Routing is filesystem-based, the metadata API is built in. - Firebase App Hosting . git push deploys. No manual ops, no Docker, no Kubernetes. Free tier so far. - Cron on a Linux box at home . A Python scraper runs daily on lich-ubuntu , normalizes install counts and author attribution, and writes a single ~2.5MB skills index.json to the repo's public/data/ directory. When the file changes, the next deploy picks it up. - No database at request time . The Next.js page reads the JSON at revalidate time every 6 hours . Firebase serves the rendered HTML. No Postgres, no Redis, no Firestore call on the hot path. That's the whole architecture. One JSON file, one Next.js page, one daily cron. The catalog routes in the repo: src/app/skills/page.js SSR catalog server component src/app/skills/SkillsClient.js interactive island search/filter/sort src/app/skills/ category /page.js domain filter pages src/app/s/ id /page.js individual skill detail page top 50 public/data/skills index.json 1,998 entries, ~2.5MB Honest disclosure on the data freshness: skills index.json is regenerated weekly-ish during active development as I iterate on the parser. The production cron — separate Python service on lich-ubuntu — is what stabilizes it to daily; that part is still rolling out. So treat the snapshot as recent, not "fresh this morning". The decision I keep being asked about is "why not a database". Two reasons. First, the catalog is read-mostly and changes once a day — that is the canonical shape of a static JSON file, not a row store. Second, every database I'd add is a thing that can break at 2am while I'm asleep. A JSON file in public/ cannot break. It can be wrong, but it cannot be down. The pillar guide that links into the catalog lives at orangebot.ai/blog/claude-code-skills-guide https://orangebot.ai/blog/claude-code-skills-guide . It's the long-form companion — what skills are, how to install them, when to pick a skill vs an MCP server. The SEO crisis I didn't see coming Six months after the catalog went live, I finally opened Google Search Console. The numbers were ugly. 21 of 186 known URLs indexed. 11.3%. - 151 URLs sitting in "Discovered – currently not indexed". last crawled timestamps were the 1969-12-31 Unix epoch — Google had registered the URLs from my sitemap and then never bothered to fetch them. - The /skills page alone was getting 5,651 impressions per week but a 0.12% CTR . People were seeing the page in search results, then bouncing past it. That is the failure mode for a content site. I had built the catalog, written the pillar guide, submitted the sitemap, and Google's verdict was a polite "no thanks". The 5,651 impressions were good news in disguise — the demand was real; the page just couldn't convert it because the SERP snippet was the generic brand tagline no generateMetadata and the rendered HTML was an empty client shell. I spent a day diagnosing it instead of pushing more content. Three root causes: Root cause 1 — the catalog page was a client component. The top of src/app/skills/page.js had 'use client' . The server-rendered HTML was an empty