Keyword research for developer tools means chasing 20-search queries, not 5,000-search ones. Where to find them and how to build a cluster that converts.
A keyword tool will tell you "docker build cache invalidation" gets 20 searches a month and "docker tutorial" gets 8,100. Every instinct built on a decade of SEO advice says write the second one. For a developer tool, that instinct is usually wrong, and the reason is worth spending a whole post on before you write a single line of content.
This is the layer upstream of most keyword advice: not how to build a cluster once you have a list (our topic cluster strategy guide covers that sequencing), but how to find and prioritize the right queries for a technical audience in the first place, where the tools you'd normally trust quietly undercount your actual buyers.
A high-volume keyword tells you a lot of people are curious about a topic. It tells you almost nothing about whether any of them are your buyer, mid-task, ready to adopt a tool that fixes their specific problem.
"docker tutorial" pulls in beginners, students, people evaluating whether to learn Docker at all, and a handful of engineers who already know Docker and are searching out of habit. "docker build cache invalidation" pulls in exactly one kind of person: someone who has Docker running in production, hit a caching bug, and needs the fix right now. The second query has a fraction of the volume and nearly all of the intent.
This is also why word count is the wrong proxy to filter on. Ahrefs' own definition is explicit: "it is not the length of a keyword that makes it a long-tail. It's the search volume of that keyword" (Ahrefs, "Long-tail keywords"). A two-word technical term with real specificity, a library name plus an error code, a config flag plus a framework version, can be just as long-tail, and just as valuable, as a six-word question. Ahrefs' own US database backs up how much of the keyword landscape lives down there: keywords with fewer than 10 monthly searches make up almost 93% of it, roughly 2.3 billion keywords, against fewer than 18,000 keywords that clear 100,000 searches a month (Ahrefs). Almost the entire keyword graph is low-volume. Chasing only the head terms means ignoring where nearly everything actually lives.
The relationship between query length and buying intent isn't a hunch, it shows up directly in conversion data. An NP Digital study of paid-search performance across 40 companies, excluding branded terms, found conversion rate climbing steadily with query length: one-word queries converted at 0.17%, three-word queries at 1.02%, and six-word queries peaked at 1.94% (NP Digital, May 2025). That's roughly an 11x gap between the shortest and longest query bucket. A six-word technical query with a handful of monthly searches isn't a rounding error, it's the highest-converting segment in the whole dataset.
Stack a few of these low-volume, high-specificity posts against one high-volume, low-specificity post and the math tips further. Ten posts each pulling 20 highly qualified searches a month is 200 monthly visits from people who already know what they're trying to do. One post pulling 5,000 loosely-qualified visits from people comparing tutorials converts at a fraction of that rate. Volume is the vanity number. Specificity is the one that shows up in your signup funnel.
Here's the honest answer: it's not that keyword tools are broken, it's that the sample they're built on doesn't represent developers well, so their volume numbers for technical terms are directionally unreliable in a way they usually aren't for consumer terms.
Keyword research tools estimate search volume from clickstream panels, samples of real user behavior collected through browser extensions and toolbars, then extrapolate to the whole search population. That works reasonably well when your audience looks like the panel. It works poorly when your audience is a small, technical slice that installs fewer extensions, uses more privacy tooling, and searches from IDEs, terminals, and AI assistants that never touch a browser search bar at all.
Nate Matherson, co-founder and CEO of Positional, names the gap directly: "Engineers are notoriously underrepresented in clickstream datasets" (Positional). That one sentence explains most of the weirdness you'll see in a keyword tool once you start researching developer topics: plausible, specific, clearly-searched-for terms sitting at zero.
A zero-volume label means the sample didn't catch enough instances of that query to estimate a number, not that nobody searches it. Matherson's own advice to customers who see this mismatch: "trust your gut" when a keyword shows zero but you're hearing the phrase from actual users, in sales calls, in support tickets, in your own inbox (Positional). If real people are asking the question in every channel except the keyword tool, the tool is the outlier, not the demand.
There's a second, larger reason the volume number is trending toward unreliable everywhere, and it compounds the developer-specific gap. About 15% of Google searches on any given day have never been searched before, a figure Google first stated in 2013 and reaffirmed as recently as 2025 at Search Central Live NYC (Search Engine Land). A tool can't estimate volume for a query it has never seen. New, specific, technical phrasing is exactly the kind of query that falls into that 15%, which means the newest and most precise developer queries are also the ones least likely to show any volume at all.
If the volume number can't be trusted for this audience, the fix is sourcing queries from where developers actually write, not from a tool that samples where they click.
GitHub issues are close to a raw feed of search queries before they become search queries. A developer hits a bug, writes it up as a literal problem statement, an exact error message, a missing feature, a specific library-and-version combination, then later, if the issue doesn't resolve it, pastes that same phrase into Google or an AI chatbot. Monthly issue creation across GitHub rose 11.3% year over year to 17.5 million during the September 2024 to August 2025 Octoverse period (GitHub Octoverse). That's 17.5 million monthly instances of developers describing a problem in their own words, most of them more precise and more current than anything a keyword tool has indexed.
Pull the open and closed issues on your own repo, your closest competitors' repos, and the core libraries your tool integrates with. Filter for titles phrased as errors or "how do I" questions rather than feature discussions. Each one is a candidate query, and the exact phrasing in the issue title is usually close to what someone would type into a search bar or an AI assistant.
Stack Overflow tag pages are a pre-built taxonomy of exactly how developers phrase problems in your category, and the question titles on those pages are close to verbatim search queries. But treat this source as a snapshot of phrasing, not a live pulse of current volume: the platform's public Q&A activity has fallen sharply. Monthly question submissions dropped from over 200,000 at their 2014 peak to under 50,000 by late 2025 (ppc.land), as more developers ask an AI assistant directly instead of posting publicly. Stack Overflow still matters as a phrasing reference, 82% of developers visit at least a few times a month even as new-question volume declines, per the 2025 Stack Overflow Developer Survey (Stack Overflow), but the newest queries are increasingly happening somewhere you can't browse.
This is the source most teams already have and never look at. Your docs site's internal search bar logs every query a visitor typed, and the zero-result queries are pure gold: a developer typed exactly what they wanted to know, in their own words, and your docs failed to answer it. That's simultaneously a content gap and a validated, real query with guaranteed intent, since the person searching it is already on your site. We cover the docs side of this in more depth in docs SEO for API documentation: the same zero-result queries that should shape a new docs page are just as often the seed of a blog post that ranks for a term no keyword tool would have surfaced.
If your product has a support bot, an in-app assistant, or any logged AI chat surface, those transcripts are the newest and most direct version of this same signal. As CustomGPT puts it, "keyword tools show search volume, customer questions show buying intent" (CustomGPT). A prospect typing "does this handle rate limiting for burst traffic" into a chat widget is not curious, they're evaluating, and that phrase is a better keyword candidate than almost anything a volume tool would suggest for the same topic. Export the logs weekly, cluster the recurring phrasings, and flag the ones your current content answers weakly or not at all.
A list of real queries is only useful once it's organized around what the reader is actually trying to accomplish, not around the surface words they happened to type.
Two queries that look completely different in a spreadsheet, "docker build cache invalidation" and "why does my docker build re-download dependencies every time", are often the same job-to-be-done wearing different words. Cluster your query list by the underlying task or failure a developer is trying to resolve, not by shared vocabulary. One cluster might cover everything under "my Docker build is slower than it should be," pulling together a dozen surface phrasings that all resolve to the same root cause and the same page.
This is the same discipline our topic cluster strategy guide argues for at the planning layer: one buyer, one job, one cluster, deep rather than scattered across a dozen shallow pillars that never compound.
Once queries are grouped by job-to-be-done, assign each group to exactly one page before you write anything. This is the step teams skip, and it's the direct cause of the problem our keyword cannibalization guide covers in full: two pages built independently, months apart, both answering the same underlying question with slightly different words, now competing with each other instead of one page owning the spot outright. A query map built at the research stage, before the first draft, is the cheapest place to prevent that. Fixing it after publication means merging or redirecting; preventing it up front means one line in a spreadsheet.
Not every job-to-be-done cluster deserves the same publishing order. Sequence by how close the query sits to an actual buying decision, not by which one has the (slightly) higher volume estimate. A query that shows up verbatim in your support bot transcripts, tied to a prospect actively evaluating your product, should ship before a broader "how X works" explainer that pulls in more traffic but less intent. Write the posts a developer would find while already deciding whether to use your tool first, then widen out to the posts that build general topical authority around the cluster.
This is also where an AI chat log or a docs zero-result query earns its place at the front of the queue: it's not a hypothetical keyword, it's proof someone hit that exact wall while evaluating a product like yours. If your team is stretched thin trying to research, write, and ship that queue fast enough, an AI blog writer built for developers can carry the drafting load once the query map is set, in your own repo, in your own voice, and early access is open while we build in the open. And the same underlying behavior, developers typing specific questions into a chat interface before they ever reach your site, is what makes this worth pairing with an AI citation strategy: the query someone asks ChatGPT today is the query it might cite you for tomorrow, if you've already written the answer.
Lyra dedupes every new topic against what you already publish and writes toward the specific queries your buyers actually search, not the head terms a generic keyword tool ranks highest.
FAQ
It's the same process, weighted differently. General keyword research favors high-volume head terms because the volume number is trustworthy for a consumer audience. Developer keyword research has to discount that number, because clickstream-based tools structurally undercount technical searchers, and instead prioritize specific, low-volume queries sourced from GitHub issues, docs search logs, and support chats, where developers actually describe what they're stuck on.
Keyword tools estimate volume from clickstream samples of browser and search-engine users, and engineers are a small, technical slice of that panel. A zero or near-zero label usually means under-sampling, not zero real demand. Positional's Nate Matherson puts it plainly: engineers are notoriously underrepresented in clickstream datasets, so a real, recurring developer query can show as zero volume for months before a tool catches up to it.
Four sources beat a keyword tool for this audience: GitHub issues and discussions (literal error strings and feature requests), Stack Overflow tag pages and question phrasing, your own docs search logs and zero-result queries, and AI chat or support-bot transcripts. All four capture the exact words a developer types when they're stuck, which is closer to a keyword tool's raw click data than its smoothed volume estimate.
Yes, if it maps to a real job-to-be-done and a specific buyer intent. Conversion rate rises with query length and specificity: three-word queries convert at roughly six times the rate of one-word queries, and six-word queries higher still, per NP Digital's 2025 paid-search study. A 20-search query that matches exactly what a developer is trying to do will out-convert a 5,000-search query that only matches their curiosity.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Tell us about your blog and the founder will walk through it with you.
Keep reading
SEO for open source projects means optimizing for GitHub stars and installs, not signups or demos. Here's the content and funnel that convert traffic.
Tutorial content decay means code examples silently break as APIs change. Learn to spot outdated code examples and keep documentation examples current.
A HubSpot blog migration playbook: why SaaS teams outgrow HubSpot's cost tiers, the redirect checklist that protects rankings, and what changes on git.