Independent developer keyword research is rarely hardest because you can't find keywords. The hard part is knowing which ones to drop. I read Plausible's early growth retrospective and then Bannerbear's free-tool page, paying closer attention to how each connects search demand back to the product. If I could build only three pages, how would I judge search intent, product fit, and upkeep cost? This post uses concrete topic candidates and page briefs to break down the trade-offs behind those choices.
SEO in Practice for Indie Developers · Part Two. Compiled from public case studies; sources checked in September 2026.
Plausible's “Small Goal” Is Only Half the Story
Plausible's 2021 retrospective says that when Marko Saric joined, the site was getting fewer than ten daily visits from Google. His initial goal was to exceed ten consistently. About nine months later, search-driven trial signups were routinely exceeding ten a day.
The team was also working on content, documentation, product pages, and community engagement at the same time. Marko explicitly wrote that he had been working full-time on branding, content, and social media for nine months. Plausible's early growth retrospective
I read those passages together. It's easy to hear “small teams grow through content” and picture a few posts written after work. But this case involved sustained effort and changes to the product, its positioning, and its distribution. Revenue growth can't be attributed to SEO alone.
The more useful lesson is the change in the goal: first, validate whether there's a reliable source of search traffic; later, determine whether that traffic can produce trials.
If a new product already has traffic but still no real usage, continuing to set a goal like “write ten more posts next month” can sidestep the most important question.
Work Backward from Product Positioning to Search, Not the Other Way Around
Keyword tools tell me which expressions exist in the market, but they don't answer why this searcher should become my user.
I'd start with two questions:
How do people like these complete the task today?
Under what conditions would they be willing to switch to a different approach?
Take the market for a lightweight web analytics product. The tasks worth researching include finding alternatives to existing analytics tools, reducing setup complexity, migrating historical data, and understanding how metrics are defined. They may not have the same search volume, but each sits at a different distance from the product.
“What is data analysis” may also have substantial demand, but readers might be choosing a major, preparing for an interview, or doing homework. That's a long way from installing a web analytics product.
So I don't define relevance simply as “contains the same industry term.” A more useful question is: after this problem is solved, would using the product be a reasonable next step?
This is my criterion for choosing topics, not an inference about how a particular Plausible keyword performed.
Why Bannerbear's Free Certificate Page Is More Concrete Than “Build a Free Tool”
Bannerbear's online certificate tool lets users choose a template, enter their information, and download a PDF or JPG without registering. The page also links to Bannerbear's bulk-generation API and automation capabilities. Bannerbear's online certificate tool
Taken on its own, it's a small tool. In the context of the product, however, the progression is natural: someone who needs one certificate today may not be willing to pay, while someone who repeatedly generates certificates for a group of learners may start to need automation.
The page makes that progression visible, but it doesn't disclose the tool's customer acquisition cost or paid conversion rate. I wouldn't conclude from this that “a free tool will always make more money than an article.”
The lesson is that, alongside finding an entry point, topic selection should also find where a need scales up: from one-off to bulk, from manual to automated, and from an individual's one-time use to a team's repeated use.
If I Could Only Build Three Pages, Here's How I'd Choose
Below, I'll use the public market for “certificate generation” as an example. The candidate queries are expressions to validate, not rankings or search-volume figures exported from a keyword tool.
| Candidate need | What the user wants to do | Page to consider | My tradeoff |
|---|---|---|---|
| online certificate maker | Create a certificate right away | A tool page users can use immediately | Test first; the initial task is clear |
| generate certificates from spreadsheet | Generate in bulk from a list | A tutorial or workflow page with a sample spreadsheet | Test first; closely aligned with the automation product |
| certificate generation API | Integrate with an existing system | An API capability page and a minimal example | Test first, assuming we actually have this capability |
| what is a certificate | Learn the concept | An explainer article | Defer; broad intent and unclear product fit |
| free certificate templates | Download editable templates | A template library | Only build it if we have real templates and the resources to maintain them |
The three tasks I chose aren't three synonyms; they're three stages of use. The tool page handles a one-off operation, the bulk tutorial validates a workflow, and the API page helps developers integrate. They can link naturally to one another without every page repeating the same long product pitch.
But “test first” doesn't mean “start writing immediately.” Next comes a search-results check.
How I'd Actually Check Search Intent
First, set the target country and language, search the candidate expressions, and record the date. View the results with target-market settings or a ranking tool, and remember that personalized results can still vary by location and user profile.
I'd open the top results from earlier, not merely note their titles. For each page, I'd write down three things:
Is it an article, tool, documentation page, or product page? What can the user do after arriving? What does it offer that I can't provide yet?
If the results are mostly tools people can use immediately, but I plan to deliver “ten benefits of using tools,” the page type is probably mismatched. Conversely, when someone is searching for an API error, a product page full of promotional copy and signup buttons isn't enough.
Search results aren't rules you can never challenge, but they reveal what content currently does the job. To challenge them, I need a clear reason—for example, existing tools lack bulk functionality, templates can't be exported, or a tutorial depends on a version that no longer works.
I wouldn't use “my article is longer” as a differentiator. Word count is a production cost, not a user benefit.
Writing a Page Brief Is More Useful Than Writing a Keyword List
Take “generating certificates in bulk from a spreadsheet” as an example. I'd start with this page brief:
With the brief in place, I can already tell whether the article is worth writing, at least in part. If I can't produce the sample and the resulting output, all I can do is explain that automation improves efficiency. Even if the title nails the keyword, the task still hasn't been completed.
The easiest thing to copy from a public example is the page name. What's hardest to replicate is the ability to deliver everything the page promises.
Content Gap Can Also Be a Product Capability Gap
Suppose all three competitors have a bulk-export page and we don't.
One option is to publish a complete bulk-export guide right away and close the Content Gap. The other is to ask whether the product can export in bulk at all.
If it can't, we're missing a capability, not an article. If bulk export can only be achieved through a makeshift script, make the limitation clear. Don't promise functionality on a search landing page that the product hasn't implemented.
I'd break competitor pages into three groups: pages whose promise we can already fulfill, pages that need a little more capability, and pages we don't plan to support for now. I'd remove the third group from the near-term topic list. A competitor having a page isn't a reason we need one too.
Comparison pages work the same way. The user is making a choice, so the page should explain who it's right for, what the limitations are, and what migration will cost. If every comparison ends with us winning, it reads as marketing collateral rather than a reliable guide to choosing.
Programmatic SEO: Verify That the Difference Is Actually Delivered
Bulk-generation pages can be very appealing to developers. But are “graduation certificate templates,” “training certificate templates,” and “employee recognition templates” three distinct tasks, or just the same image with three different titles?
I'd pick two pages at random, hide the titles and URLs, and see whether I can still tell them apart. If the fields, output, steps, and usage limits are all the same, it's hard to justify so many entry points.
My approach would be to build a small batch that can be reviewed manually, then track which pages people actually search for, use, and save. Scaling should amplify a page model that already works, not use volume to conceal a model that hasn't been validated.
This also matches Google's limits on scaled content abuse: the issue is whether large numbers of pages mainly manipulate rankings or lack user value, not whether production is manual or automated. Google's spam content policies
How I'd Plan the First Month
The first week's deliverable isn't thirty titles. It's three tasks checked against the search results, plus a page brief for each task.
In the second week, build the page that can deliver the most value. Before publishing, instrument the key events: did the tool generate successfully, does the tutorial get the user to a working step, and does the API page move the developer into the integration flow? A sample-file download is only an intermediate signal, not an activation event.
In the third week, put the page where the issue is actually being discussed. Answer questions, reference the corresponding steps, respect the community's rules, and disclose any personal interest you have in the product. If there's no feedback, don't manufacture a presence by posting the same link repeatedly.
In the fourth week, check three things: whether search engines can discover it, whether it appears for related queries, and whether visitors complete the task. Four weeks without search results on a new site doesn't mean the approach has failed. But if real users can't even understand the page's promise, there's no point waiting three months before changing it.
I'll keep “Deferred” and “Dropped” lists in my spreadsheet. A keyword that's unrelated to the product, expensive to maintain, and unable to deliver a meaningful difference usually takes less time to remove than to turn into an article.
After reading these cases, I'm more inclined to treat the first batch of keywords as product decisions: Which specific tasks am I ready to offer a genuinely good entry point for? Once those are chosen, pages, features, documentation, and distribution will all have a shared direction.
Previous: Technical SEO: Define the Problem Before Deciding Whether to Change Code
Next: Link Building: What Ahrefs' Experiment Shows About Why Others Cite You