As marketers, we often dream of users having an ideal website experience: They arrive on the home page, and after admiring the headline’s messaging, they easily navigate to the place with the exact answer to their question.
The real world is a bit messier, isn’t it? For one, many queries are sought with offsite searches, such as Google or ChatGPT. Users may not even click through to your website at all.
But when a developer already knows about your company and makes the effort to visit your online presence, there’s a good chance they’ll find the answers they’re looking for — assuming you’ve thought to put that content somewhere on your site.
Whether your brand gets a handful of clicks or robust activity, there’s always room for improvement. By looking at how developers search for well-known technical companies, we can see the types of information they want from you. Even better, we can create a clearer picture of their problems.
To prepare this post on the pages that developers search, we looked deep into keywords where ten top technical companies rank: DigitalOcean, GitHub, GitLab, Heroku, MongoDB, Netlify, Okta, Postman, Twilio, and Vercel. Then, we removed terms irrelevant to developers, like stocks and CEOs (sorry, finance people).
We found five areas that developers want to explore:
- Developer experience resources
- Complementary tools
- The competition
- Use cases and tutorials
- Pricing
Keywords related to these categories appeared in at least five of the ten companies, often more. So let’s discover the keywords developers use, why we think these areas are important, and how you can include the lessons in your work with developers.
Developer Experience Resources: Show Me the Docs
When developers are your product’s primary audience, developer experience (DX) is something everyone should care about. Marketers, product managers, and developer relations teams obsess over every developer interaction with their products. Top of that list is documentation, but as you’ll see, that’s not the complete story.
Developer experience keywords
| {company} keyword | Appearances (out of 10) |
| {company} api | 10 |
| {company} documentation | 10 |
| {company} down | 10 |
| {company} status | 10 |
| {company} cli | 9 |
| {company} wiki | 9 |
| {company} docs | 8 |
| {company} download | 8 |
| {company} issues | 8 |
| {company} security | 8 |
| {company} status page | 8 |
| {company} authentication | 7 |
| {company} logs | 6 |
| {company} rest api | 6 |
| {company} api documentation | 5 |
| {company} down detector | 5 |
Dev tool performance is a frequent search topic. All the companies we reviewed had some kind of status page with up/downtime, but what matters to developers is that these pages aren’t buried four clicks deep. A prominent footer link across the website, dashboard, and docs is a trust signal that you value uptime for your dev tool.
What could be more important than uptime? According to the 2024 Stack Overflow survey, an API is the top factor for whether developers will endorse your tool. That may explain why developers also want to find your API. Of the companies we reviewed, only Twilio has an API as the primary product. And yet, all ten have devs looking for their APIs.
Naturally, devs also want to find your API documentation and the docs for your entire product. Like status, they might search for these because sometimes it’s difficult to discover the docs or at least the right documentation (since these companies often have multiple products).
Finally, developers will search for concepts (authentication, security, logs) and additional interfaces to your product (CLI, download). While we’ve considered these as elements of DX, there’s an entire ecosystem around dev tools. You want to ensure your product plays nicely within that ecosystem. You can tap into this interest with content that discusses how other tools integrate with your own.
Complementary Tools: Help Me Fit You in My Workflow
When we help clients attract more developers to their dev tool, one of the first places we look is the other products their audience uses.
Let’s say your product analyzes new code checked into repositories. That means engineers who use your product also have a source control system. They likely also run a continuous integration tool.
Every dev tool will have this cluster of complementary products. We discovered some common categories in our review of these search terms.
Complementary tool keywords
| {company} keyword | Appearances (out of 10) |
| {company} ai | 10 |
| {company} aws | 9 |
| {company} docker | 8 |
| {company} python | 8 |
| {company} terraform | 8 |
| {company} webhooks | 8 |
| {company} github | 7 |
| {company} database | 6 |
| {company} datadog | 6 |
| {company} integrations | 6 |
| {company} nodejs | 6 |
| {company} slack integration | 6 |
| {company} wordpress | 6 |
| {company} cloudflare | 5 |
| {company} elasticsearch | 5 |
| {company} fastapi | 5 |
| {company} functions | 5 |
| {company} go | 5 |
| {company} golang | 5 |
| {company} kubernetes | 5 |
| {company} laravel | 5 |
| {company} mongodb | 5 |
| {company} mysql | 5 |
| {company} postgres | 5 |
| {company} supabase | 5 |
First, artificial intelligence cannot be ignored, as developers search for AI alongside all ten popular products we reviewed. There’s a lot of noise around the topic, but it’s also become part of the developer workflow. We’ve discussed how AI has yet to replace human innovation when it comes to technical content. But these search results show devs want to know its impact, so it’s a good idea to share a story about how they can use AI with your product.
The other terms broadly fall into these categories:
- Databases
- Programming languages
- Cloud infrastructure
Every application needs to store data, so it’s unsurprising that databases show up here. What’s notable is the mix of generic (database, MySQL, PostgreSQL) and specific (Supabase, MongoDB, Elasticsearch) tools.
Programming languages are among our favorite angles for content that attracts a specific developer. If you have a story about how your product integrates with Python, Node.js, or Go, you can reach out to more of those developers and help solve their problems. You’ll also provide a great experience along the way if you have SDKs or other language-specific support.
In addition to programming languages, consider leveling up your product with framework support. Laravel has gained tremendous popularity in the last few years. While it’s the only framework in the search data, other products have succeeded too, especially when we look into more specific tools developers use. Stormpath’s story with frameworks figures prominently in Technical Content Strategy Decoded and is credited with finding a new trajectory for the company eventually acquired by Okta.
Docker, Terraform, and Kubernetes are all ways to provision and run cloud infrastructure. Like frameworks, when you target these open-source tools, you’ll enable developers to use your product within their existing ecosystem. Looking at the keywords, you’ll also find commercial terms, like AWS and Cloudflare; this shows that developers want your product framed around the way they run their applications.
The largest category we found involves complementary tools. And there’s some bias here to the type of dev tools we selected to review. You’ll find these and more when you understand the dev workflow of your product’s potential audience. But let’s not forget the other companies and products that compete for the same developer attention.
The Competition: How Does Your Product Compare?
As much as every marketer wants to present the one and only solution to a developer’s problem, the reality is that options abound. Your job is to understand the pros and cons of available choices and position your product in the best possible light. You can even reach developers while they’re “shopping” with answers to their questions about your competitors.
Competitive product keywords
| {company} keyword | Appearances (out of 10) |
| {company} alternatives | 10 |
| {company} competitors | 10 |
| {company} vs | 9 |
| {company} firebase vs | 5 |
| {company} open source | 5 |
| {company} vs aws | 5 |
| {company} vs azure | 5 |
| {company} vs firebase | 5 |
The competitor comparison with a features chart is a product marketing classic. Developers will likely seek out unbiased versions, but perhaps they’ll give yours a skim. Maybe you can show up as they look for your direct competitors, as well.
There’s also an opportunity for longer versions of these comparisons. Perhaps a roundup of solutions to specific use cases or a deep dive featuring comparisons with developer quotes.
Just know they’ll take your words with a healthy dose of skepticism. See what you can do to provide something that comes across as more objective and build developer trust through less promotional marketing.
You can also expand your definition of “competitor.” The biggest competition for dev tools might be a developer building something themselves. That’s one reason we see “open source” among this list of common keywords.
Developers often look for open-source tools to solve their problems. Provide a reasonable review of open-source alternatives, explain the trade-offs, and highlight when it makes sense to use your product instead. Many will still go the open-source route, but some are sure to give you a try.
Finally, note the infrastructure brands we found in these developer search terms. Since several of the reviewed companies are cloud hosts, it makes sense that AWS and Azure would show up here. These complement many dev tools but appear as competitors here because of the “vs” modifier. Similarly, the flexible Firebase product tends to be compared to cloud tools because of their datastore options. As with complementary keywords, consider your competitive landscape and include the big players in your content.
Use Cases and Tutorials: Share Your Best Practices
Developers love to say: “Just show me the docs.” The problem is docs aren’t enough to communicate why your product matters. And not just that: To whatever extent, everyone wants to be inspired when they’re looking for solutions. A glimpse at the keywords in this section shows how devs might not mind a little guidance.
Use case keywords
| {company} keyword | Appearances (out of 10) |
| what is {company} | 10 |
| {company} how does work | 8 |
| {company} how to use | 8 |
| {company} tutorial | 7 |
| {company} certification | 6 |
| {company} cheat sheet | 6 |
| {company} install | 6 |
| {company} commands | 5 |
| {company} delete account | 5 |
| {company} oauth | 5 |
Not every one of these searches may be from developer fingers. It’s tough to picture devs asking: “What is GitHub?” But we shouldn’t go the opposite direction, assuming they’re already familiar with our dev tools. There’s way too much for developers to know, and they can’t be experts at everything. In fact, that’s the very reason knowledge sharing is such an important part of the developer experience.
Sometimes, a tutorial is the perfect answer to a developer’s problem. It doesn’t always need to be a video, either. Videos are hard to skim — and skeptical devs won’t be certain your solution will fix their problem until their cursory glance.
Think beyond documentation for use cases and tutorials, and you’ll open up more options to inspire developers with what’s possible. Lean on interactive architecture diagrams, one-pager cheat sheets, and even deep education programs that might lead to certification. Use multiple formats and approaches as you get familiar with the problems your audience wants to solve.
Though the keywords in this post all mention brands, you can attract even more of the right developers when you present use cases before you mention the product. Yes, help them solve their problems once they’ve found you, but also help them better understand the problems, too. And don’t ever let the problem be: “Where the heck do I find out what this costs?”
Pricing: Can I Afford You?
When we looked at the top dev-focused home pages, we learned that more than 83% include a pricing page. It’s not simply to show how the companies make money. It’s because developers want to know if their organization can afford it.
In fact, the pricing page is one of the most visited in every SaaS analytics we’ve ever seen. How developers search for it provides insight into how they think about dev tools and what it takes for them to champion a new one in their organization.
Pricing keywords
| {company} keyword | Appearances (out of 10) |
| {company} pricing | 10 |
| {company} is free | 10 |
| {company} cost | 10 |
| {company} free | 9 |
| {company} price | 9 |
| {company} free tier | 9 |
| {company} plans | 8 |
| {company} enterprise pricing | 7 |
| {company} costs | 7 |
| {company} enterprise | 6 |
| {company} is open source | 5 |
| {company} free hosting | 5 |
Normally, I’d grimace at targeting keyword phrases that include “free,” and you’ll see several on this list. There’s a myth that developers won’t buy anything, so you could easily take that lesson here. However, the story may be this: Developers don’t want to pay for your tool until they see that it can help them.
Pricing may seem like a business decision, but it’s so much more than that when it comes to dev tools. It’s a trust builder, but it can also be a trust buster. What developers want is a free trial (or tier) that’s self-serve and clearly explains costs should they want to keep using it. These are numbers 3-5 on our 13 components of great DX.
Ask any developer about their biggest challenge on costing dev tools, and you’ll have a unanimous answer — getting enterprise pricing without an intensive sales call. The searches here confirm it. Seven of the ten companies we looked at rank for the “enterprise pricing” search, showing how devs are looking for the actual cost of any technical product. They’re browsing forums, asking colleagues, and doing anything to answer that question without talking to someone at your company.
They’re also hedging their bets. The open-source search might seem strange in the pricing section, but we included it here because developers want alternative solutions. Even before they integrate with your product, they think about how hard it would be to leave. Open source could give them an exit.
Build Trust with Every Search Result
Chances are you don’t work at one of the ten dev tool brands we reviewed in this post. But you have a marketing role for a technical product. You don’t just want developers to find it. You want them to try it — and hopefully use it and love it, too!
One good way to make the most of this post is to review each section with your team. Take notes about what you could do better to help developers find the content, context, and other resources they need.
An even better way is to get an external, objective eye to review each section with you. Choose someone who understands the developer audience and can help you see how you can build even more trust with it. You want a technical content partner, so be sure to read this before you hire a technical content agency.
Whether or not the search terms mention your company, you want the results to connect with developers authentically. Make sure you understand their mindset and work toward pages that show you’re there to support them.