Playbook · Developer products
SEO & AI search playbook for developer tools
Developers find tools through problems. They hit an error, need to do something in a framework, or read a comparison while choosing between two libraries. Marketing pages rarely rank for those searches; working answers do.
Developers also check everything. A comparison page with a rigged benchmark gets called out in public, and a guide with broken code loses you the reader for good. The upside is that a good technical page keeps working for years.
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.
“[tool A] vs [tool B]”
Choosing between optionsAmong the most useful pages you can write, if it's fair. Say when the other tool is the better choice.
“how to [task] in [framework]”, “[tool] with [framework]”
ImplementationFramework-specific guides with working code. Each framework has different setup, which keeps pages distinct.
Exact error messages
DebuggingDevelopers paste errors into search. A page that explains the cause and the fix earns trust instantly.
“[incumbent] alternative”, “migrate from [incumbent]”
SwitchingMigration guides with a checklist and code diffs.
Page families that work
X vs Y comparisons
/compare/your-tool-vs-other
Feature table, API differences, reproducible benchmark (with the script), and when to pick the other one.
Framework guides
/guides/nextjs
Install, configure, deploy for each framework you support, tested on current versions.
Error reference
/errors/connection-reset
One error per page, with cause, fix and the versions affected.
Migration guides
/migrate/from-other-tool
Step-by-step with code diffs and a list of things that don't map one to one.
Risky page types
“[Tool] for [every framework]” with the same content
If the Vue page and the Svelte page are the same guide with a word swapped, developers notice and Google treats them as duplicates. Only publish frameworks you've actually tested.
Benchmarks nobody can reproduce
Publish the script and the hardware, or don't publish the numbers.
Technical pitfalls
The GitHub README outranks your site
That's fine for your brand name, but make the README link to your docs and guides, and set the “homepage” field in package manifests (for npm, package.json) to your site.
Docs on a separate hosted domain
Docs on a vendor subdomain or a GitHub Pages site split your links. Put docs under your own domain if you can, and keep URLs stable when you move them.
Code blocks as images or injected by scripts
Render code as text in <pre> blocks so crawlers and assistants can read and quote it.
How AI assistants answer questions in this category
Developers ask coding assistants how to use a tool, and assistants answer from training data when the tool is well known. For newer tools or recent versions, assistants with search or tool access fetch documentation directly. The llms.txt proposal describes exactly this: a coding agent fetching a library's docs to get an API call right. If your docs are clear, current and readable as text, you're far more likely to be used correctly and named.
What tends to earn a citation
- Up-to-date docs with version numbers on the page, so assistants don't mix up old and new APIs.
- Comparison pages with concrete API differences that can be quoted.
- A short llms.txt pointing to your most important docs pages. It's optional and cheap.
Check whether the AI crawlers you want can reach your site with our AI crawler checker.
Where links come from
Show HN
Hacker News says Show HN is for something people can try, not a blog post or sign-up page, and asks you not to get friends to upvote. Launch when there's something to run.
Curated lists
“Awesome” lists and similar take PRs. Follow each list's format. See developer tool directories.
Integrations with popular frameworks
Official plugins or examples in framework docs and starter templates are the strongest links in the category.
Directory lists that fit developer tools
- Developer tool directories
- Open-source directories
- Product launch platforms
- Where to submit: Developer tools
- Where to submit: AI coding tools
- Where to submit: Developer newsletters
- 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
Docs and manifests
- Move or proxy docs under your own domain if possible.
- Set homepage and repository fields in package manifests.
- Make sure code renders as text.
Days 31–60
Comparisons and guides
- Write two honest X vs Y pages with reproducible benchmarks.
- Publish guides for the frameworks your users run most.
- Add pages for the ten errors that come up most in issues.
Days 61–90
Launch and loop
- Do a Show HN when there's something runnable.
- Submit to relevant curated lists.
- Rewrite titles on guides 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 containing “vs”
- Shows which comparisons people run against you, including ones you haven't written.
- Error-page impressions
- Growth here means you're catching developers at the moment of need.
- Brand queries including “docs” or “example”
- A sign of active users. If these land on the README instead of your docs, fix the links.
Frequently asked questions
Should our docs be on a subdomain or a subfolder?
Both can rank. Choose one, keep URLs stable, and link heavily between docs and the main site.
Is writing “X vs Y” about competitors fair?
It's what developers search for. Keep it factual, date it, publish benchmark scripts, and say when the other tool fits better.
Does GitHub star count affect SEO?
There's no public evidence it does. Stars are social proof for people, not a search signal we can point to.
How do we get coding assistants to use our tool correctly?
Keep docs current and readable as text, put version numbers on pages, and publish working examples. An llms.txt can help tools that read it.
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.