Programmatic SEO for a Developer Tool: What I'd Do Again

Programmatic SEO has a bad reputation, mostly deserved, because most of it is garbage. Generate ten thousand near-identical pages, one per city or one per keyword permutation, and hope Google rewards the volume. It used to work. It mostly doesn't anymore, and it leaves you with a site full of thin pages you're now embarrassed by.

But there's a version that works for developer tools specifically, and I've been doing it for QueryBear. The difference between the version that works and the spam is entirely about whether each page answers a real question someone is actually typing.

The pattern that works: tool × tool × task

Developers search in a very specific shape when they're stuck. They search "connect [their tool] to [other tool]" or "[their database] [their client] setup." It's a templated intent, and that's the opening.

For me the template is roughly: [database] MCP server for [AI client]. Postgres for Cursor. MySQL for Claude Code. SQLite for Windsurf. Each combination is a real page because each is a real, distinct thing someone is mid-task trying to do. The person searching "mysql mcp server cursor" has a specific problem and wants a specific answer, and a page that gives them exactly that is genuinely useful, not spam.

The combinatorial part is what makes it "programmatic" — three databases times seven clients is twenty-one pages from one template. But the reason it works is that each cell of that grid is a question with real search demand and a real answer, not a keyword you mashed together to fill a URL.

The line between useful and spam

Here's the test I use, and it's the whole game: if I removed the templating and a human had to write this page by hand, would it still deserve to exist?

For "Postgres MCP server for Claude Code," yes. The setup steps genuinely differ from Cursor's. The config file is in a different place. The screenshots are different. A real person with that exact problem gets real help. The template is just saving me from writing the same scaffolding twenty-one times, not manufacturing pages that shouldn't exist.

For "Postgres database in [city name]," no. There's no real per-city difference. The page only exists to catch a search, and Google can tell, and increasingly so can readers. That's the spam version, and it's the version that gives the whole tactic its bad name.

If each page would embarrass you as a standalone article, you're doing the bad kind. If each page would stand on its own as a useful answer, the templating is just efficient writing.

What I underestimated

Two things surprised me.

First, the per-combination pages convert better than my general posts, even though they get less traffic each. Someone searching "sqlite mcp server for codex" is deep in a task, has high intent, and is exactly the person who might use my product five minutes later. A broad post like "the future of databases" gets more visits and converts worse, because the reader is browsing, not solving. Intent beats volume for a tool, every time.

Second, the maintenance is real. Twenty-one pages built from a template all break the same way when the thing they describe changes. When an AI client updates its config format, every page referencing it is now subtly wrong at once. Programmatic creation means programmatic staleness. Budget for the upkeep, or the pages that ranked become the pages that mislead.

What I'd do again, and what I wouldn't

I'd do the tool-combination pages again without hesitation. They're the clearest example of programmatic SEO that's actually a service to the reader, and they bring in the right people.

What I'd avoid is the temptation to expand the grid past where real differences exist, just because the template makes it cheap. The moment I'm generating a page for a combination that isn't meaningfully different from its neighbors, I've crossed from "efficient" to "thin," and the only one fooled is me.

The honest summary: programmatic SEO isn't a cheat code, it's a writing tool. It lets you efficiently produce pages for a set of real questions that share a structure. If the questions are real, it's great. If you're inventing the questions to justify the pages, you're building debt that looks like traffic. For a dev tool, the real questions are usually some flavor of "how do I connect X to Y," and there are more of those than you'd think. That's the seam worth mining. The rest is spam with a content calendar.