Playbook · Developer products
SEO & AI search playbook for open-source companies
Open-source companies have a head start most startups don't: people search for “open source [category]” and “self-hosted [incumbent] alternative” on their own. The repo often ranks before the website does.
The work is to turn that interest into a path: from repo to docs to deployment to, eventually, the hosted or paid version. It also means being clear about licensing and what's free, because that's the first thing people check.
Updated By the LaunchRanked team5 sources checked
Searches to plan around
Query patterns and the intent behind them. We don’t quote search volumes: check your own Search Console for the ones you already appear for.
“open source [category]”, “self-hosted [incumbent] alternative”
DiscoveryYour core discovery query. A page per incumbent you really replace, with an honest feature comparison.
“[project] docker compose”, “deploy [project] on [platform]”
DeploymentOne guide per platform you support and test.
“[project] vs [project]”
Choosing a projectOften compared with other open-source projects, not just commercial ones.
“[project] license”, “[project] cloud pricing”
Commercial checkPut licence and hosted pricing on your site in plain words.
Page families that work
Alternative-to pages
/alternatives/[incumbent]
Feature table, what's missing, and migration steps. Only for products you really replace.
Deployment guides
/docs/deploy/kubernetes
Each platform has different steps, resources and gotchas.
Open source vs cloud page
/pricing/self-hosted-vs-cloud
What each includes, who should choose which. Readers look for this before committing.
Plugin or integration directory
/integrations/…
Community plugins with their own descriptions and maintainers.
Risky page types
“Open-source alternative to X” for every SaaS
If you aren't really an alternative, the page misleads readers and adds nothing. Stick to products you replace.
Docs mirrored on several hosts
The same docs on your site, a docs host and a mirror split signals. Pick one canonical home.
Technical pitfalls
README and site saying different things
Keep the install steps in one place and link to it from the README, so the version people find is the current one.
Missing homepage fields
Package registries show the homepage and repository you set. For npm that's package.json; set them to your site and repo.
Versioned docs competing
Old versions rank for the same queries as new ones. Canonicalise where content is the same and mark old versions clearly.
How AI assistants answer questions in this category
“What's a good open-source alternative to X?” is a common assistant question. Answers draw on curated lists, alternative-listing sites, comparison articles and repos. Assistants often mention licence and self-hosting difficulty when they can find them, so state both plainly on your site.
What tends to earn a citation
- A clear licence name and what's free versus paid, in text on your site.
- Self-hosting requirements (resources, dependencies) that answer “how hard is it to run?”.
- Presence on the curated lists that assistants retrieve for “open source alternative” questions.
Check whether the AI crawlers you want can reach your site with our AI crawler checker.
Where links come from
Curated lists
Awesome lists and similar take pull requests. Read each list's rules. See open-source directories.
Show HN and community launches
Open-source projects are welcome on Show HN when people can try them.
Package registries and integrations
Every package, plugin and integration listing that links to your site counts. So do mentions in other projects' docs.
Directory lists that fit open-source companies
- Open-source directories
- Developer tool directories
- Product launch platforms
- Where to submit: Open-source projects
- Where to submit: Self-hosted software
- All directories
Each directory is checked on its own site: price, link type and review process. We never sell links.
A 90-day plan
Days 1–30
Clarity
- Publish a clear licence and self-hosted vs cloud page.
- Align the README and docs install steps.
- Set homepage fields on every package.
Days 31–60
Alternatives and deployment
- Write alternative pages for the two or three incumbents you replace.
- Publish deployment guides for the platforms you test.
- Submit to relevant curated lists.
Days 61–90
Community and loop
- Launch on Show HN or a similar community when there's a release worth trying.
- Canonicalise old doc versions.
- Rewrite titles on alternative pages at positions 5–20.
What to watch in Search Console
The Performance report gives clicks, impressions, CTR and average position by query, page, country, device and date. Traffic from Google's AI features is counted there too, under the Web search type (Google).
- Queries with “open source” or “self-hosted”
- Your core discovery demand. Track impressions and which pages get them.
- Traffic to self-hosted vs cloud page
- Shows how many readers are weighing the paid option.
- Links from repos and lists
- Search Console's Links report shows which lists and projects link to you.
Frequently asked questions
Is it a problem that our GitHub repo outranks our site?
Not for your brand name. Make sure the repo links to your docs and site so people can move on from it.
Should we write alternative pages for commercial tools?
For those you really replace. Include what you're missing; readers check.
Do awesome lists still matter?
They're read by developers and retrieved for alternative questions. Follow each list's contribution rules.
How do we avoid duplicate docs across versions?
Canonicalise overlapping versions to the current one and label old versions clearly.
Sources
Checked on September 23, 2026. Search patterns and page advice are our own judgement from running this playbook; we don’t quote search volumes or third-party statistics.