Keyword Research for Indie Developers: Picking Topics from Plausible and Bannerbear

For indie developers doing keyword research, the hardest part is often not finding keywords but knowing which ones to abandon. When I read Plausible's early growth retrospective and browsed Bannerbear's free tools page, I paid more attention to how they connected search demand back to the product. If I could only build three pages, how would I evaluate search intent, product fit, and maintenance cost? This article breaks down the trade-offs behind those choices using concrete topic examples and page briefs.

Indie Developer SEO Playbook · Second Article. Compiled from public case studies, facts verified as of September 2026.

Plausible's "Small Goal" — Don't Just Copy the First Half

In Plausible's 2021 retrospective, they mentioned that when Marko Saric joined, daily visits from Google were under ten. His initial goal was to stabilize above ten; about nine months later, trial signups from more than ten search sources per day were no longer uncommon.

The team was simultaneously working on content, documentation, product pages, and community engagement. Marko also explicitly wrote that he'd been全职投入 nine months into brand, content, and social work. Plausible's Early Growth Retrospective

I read these two passages together. "Content-driven growth for small teams" is easy to interpret as casually writing a few articles after work, but this case involved sustained investment, plus product, positioning, and distribution evolving together — you can't attribute revenue growth solely to SEO.

What's more worth learning is how the goal shifted: initially validating whether there was a stable search entry point, later questioning whether that entry point could bring trials.

If a new product already has traffic but no real usage, setting a goal like "write ten more articles next month" may be avoiding the most important question.

Derive Search from Product Positioning, Not the Other Way Around

Keyword tools tell me what expressions exist in the market, but they don't answer: why should this searcher become my user?

I start by writing two sentences:

What method are these people currently using to complete this task?
Under what conditions would they be willing to switch to a different approach?

Taking the lightweight web analytics market as an example, tasks worth researching include: finding alternatives to existing analytics tools, reducing setup complexity, migrating historical data, and understanding metric definitions. They don't necessarily have the same search volume, but they have different product proximity.

"What is data analytics" might also have substantial demand, but readers could be choosing a major, preparing for interviews, or doing homework — far from installing a web analytics product.

So I wouldn't simply treat related keywords as "containing the same industry term." More useful relevance is: after solving this problem, is using the product a reasonable next step?

This is my topic selection criteria, not an inference about Plausible's specific keyword performance.

Why Bannerbear's Free Certificate Page Is More Specific Than Just "Build Free Tools"

Bannerbear's online certificate tool lets users choose a template, enter information, then download a PDF or JPG without registration; the page also links to batch generation API and automation capabilities. Bannerbear Online Certificate Tool

On its own, it's a small tool. But within the product, the connection feels natural: someone making one certificate today might not pay, but someone needing to repeatedly generate certificates for a cohort of learners might soon need automation.

The page publicly shows this connection method without disclosing the tool's acquisition cost or paid conversion rate. I won't claim "free tools definitely outperform articles" based on this.

What it启发我 is that topic selection should not only find entry points but also locate where demand upgrading happens: from one-time to batch, from manual to automated, from individual temporary use to team recurring use.

If I Could Only Build Three Pages, How Would I Choose

Below I use the public "certificate generation" market for a demo. Candidate keywords are just expressions to validate, not rankings or search volumes from a keyword tool.

My three selected candidate tasks aren't three synonyms — they're three usage stages. The tool page solves one-off operation, the batch tutorial validates workflow, and the API page helps developers integrate. They can link naturally without needing each page to contain the same product pitch.

But "priority validate" doesn't mean "write immediately." There's still a search results check to do.

How I'd Actually Check Search Intent

First lock in target country and language, search the candidate expression, record the date. Use target market settings or ranking tools to view results, and remember personal search results may still have location and personalization differences.

I'll open the top results ahead, not just copy titles. For each page, note three things:

Is it an article, tool, documentation, or product page? What can users do after arriving? What can they get that I temporarily can't provide?

If search results are mostly instantly usable tools, and I'm preparing to deliver "ten benefits of using this tool," the format is likely misaligned. Conversely, when users are looking up API errors, a product page full of promotions and signup buttons won't cut it.

Search results aren't unchallengeable rules, but they reveal what content currently serves this task. Challenging them requires clear reasons — like existing tools lacking batch functionality, templates not exportable, or tutorials depending on deprecated versions.

I won't use "my article is longer" as differentiation. Word count is production cost, not user benefit.

Writing a Page Brief Is More Useful Than a Keyword List

Taking "batch generate certificates from spreadsheet" as an example, I'd first write this page brief:

Reader:
Course operators who already have a student list and need to batch-produce certificates.

Promise:
A runnable workflow from spreadsheet to certificates.

Must deliver:
A downloadable sample spreadsheet;
Mapping of column names, required fields, and template variables;
Three example rows;
Success results and error row handling;
How to check for duplicate names, missing fields, and re-running.

Where the product appears:
At steps requiring automated generation and repeated execution.

Not promising:
Unverified time costs, unlimited free usage, or direct compatibility with any spreadsheet.

After writing this, I can already judge half the article's value. If I can't provide examples and results, only explain that "automation improves efficiency" — even if the title places keywords perfectly, I haven't really completed the task.

The easiest thing to copy from public cases is the page name; the hardest to replicate is the delivery capability behind the page.

Content Gaps Might Also Reveal Product Capability Gaps

Suppose three competitors all have batch export pages, and I don't.

One approach is to immediately fill the Content Gap with a "Complete Guide to Batch Export." Another is to first ask: can the product actually do batch export?

If not, it's not a missing article — it's a missing capability. If it can only be barely achieved through scripts, I should clarify the limitation rather than promising unimplemented features on search pages.

I'll split competitor pages into three categories: what I can already deliver, what needs a bit of capability to add, and what I'm not planning to support for now. The third category gets removed from near-term topics. A competitor having a page doesn't constitute reason for me to have it.

Comparison pages work similarly. When users are making choices, the page should explain who fits what, what the limitations are, and what migration costs. If every comparison ends with "we win on everything," it reads more like promotional material than reliable selection help.

Programmatic SEO — First Verify That "Difference" Translates to Delivery

Batch generation pages are tempting for developers. But "graduation certificate templates," "training certificate templates," "employee appreciation templates" — are these three tasks, or the same image with three titles?

I'll randomly sample two pages, cover the title and URL, and see if I can distinguish them. If the fields, outputs, steps, and usage limits are all the same, it's hard to explain why so many entry points are needed.

My approach would be to first complete a small batch of manually verifiable pages, then record which ones people actually search for, use, and save. Scaling should amplify page models that have already proven valid, not use quantity to mask unverified models.

This also aligns with Google's boundary for scaled content abuse: the focus is on whether mass pages primarily manipulate rankings and lack user value, not whether they're manually or automatically produced. Google's Spam Policies

How I'd Plan the First Month

Week one's output isn't thirty titles, but three tasks verified through search results checks, plus a page brief for each task.

Week two: build the page most able to deliver value first. Before publishing, connect the key interactions: does the tool successfully generate, does the tutorial reach the running step, does the API page lead people into the integration flow? Downloading sample files is just an intermediate signal, not directly an activation.

Week three: place the page where this problem is actually discussed, answer questions by referencing the corresponding steps, respect community rules and your own interests. Without feedback, don't manufacture presence by repeatedly posting links.

Week four: check three things: can search engines discover it, do related queries appear, and do arrivals complete the task? A new site without search results in four weeks doesn't mean the strategy failed, but if real users can't even understand what the page promises, don't wait three months to fix it.

I'll keep "defer" and "abandon" in my worksheet. A keyword unrelated to the product, expensive to maintain, and unable to deliver differentiation — deleting it usually saves more time than writing it 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 prepared to provide a good enough entry point for? Once selected, pages, features, documentation, and distribution gain a shared direction.

Previous: Technical SEO: First Identify the Problem, Then Decide Whether to Change Code

Next: How to Build Backlinks: Why Others Are Willing to Link from Ahrefs's Experiments