The gap: discovery pages did not answer enough buying questions
ShowMeYourSaaS already had product profiles, categories, and founder articles. Those formats helped people discover software and learn about building a SaaS. We wanted dedicated answers for three different decisions: what could replace a named product, how two candidates differ, and which tools fit a particular audience.
Programmatic SEO means publishing a family of pages from structured information and reusable templates. In this rollout, the program supplied consistent routes and presentation; editorial work supplied the actual selection, reasons, and limitations. A product name swapped into generic prose would not explain which choice fits a reader’s task.
The launch scope: 16 decision pages and three collection hubs
We started with six researched tools in two groups: Plausible, PostHog, and Mixpanel for analytics; Lovable, Bolt, and Replit for AI-assisted web app building. Within each group we selected all three distinct pairs once. We also wrote four audience shortlists. The scope was deliberately bounded by the research we could support.
At the release snapshot on October 26, the sitemap grew from 217 to 236 URLs. The site had 96 public product listings and 94 non-demo articles at that point. Those are historical launch counts; later editorial additions, including this case study, change the live totals. The 19 new URLs include the hubs, rather than representing 19 individual comparisons.
| Family | Count | Example route |
|---|---|---|
| Product alternatives | 6 | /alternatives/lovable/ |
| Direct comparisons | 6 | /compare/lovable-vs-bolt/ |
| Category and audience shortlists | 4 | /best/analytics-tools/solopreneurs/ |
| Collection hubs | 3 | /alternatives/, /compare/, /best/ |
| Total new URLs | 19 | 16 decision pages + 3 hubs |
Separate researched facts from editorial selection
The research records store each tool’s group, focus, workflow, pricing model description, official sources, and a fixed check date. We used October 26, 2026 for this release. We kept that research separate from maker-submitted directory descriptions, so a listing alone would not become independent evidence for a comparison claim.
A second layer describes each page: why someone might keep the original tool, reasons to consider alternatives, the decision brief for a pair, audience-specific priorities, and checks to perform in a trial. These are editorial judgments based on documentation. We did not conduct firsthand performance benchmarks, and the pages say so. Source links let readers verify changing terms before committing.
Use a shared layout with a different decision on every page
The Lovable versus Bolt page begins with a decision brief, compares working details, and asks the reader to evaluate a complete feature and a follow-up change. An analytics shortlist instead starts from the audience’s reporting job and implementation constraints. The shared design keeps those answers readable without making the actual selection identical.
An alternatives page also explains when keeping the named product may make sense. A shortlist explains how we selected candidates. Those details are useful even when a reader decides not to switch. Our comparison-page guide covers the underlying editorial structure; the screenshot shows the version published in this rollout.
Generate only supported routes and make them discoverable
The Next.js site exports static HTML from explicit guide records. We did not generate every product against every audience or create both orders of a comparison. For example, the selected route is posthog-vs-mixpanel; the reversed mixpanel-vs-posthog route is unsupported and returns 404. Unknown tools and unsupported category/audience combinations also return 404.
Every supported page has a self-referencing canonical, one primary heading, breadcrumbs, and structured data appropriate to its collection content. The new URLs appear in the sitemap and link from relevant hubs, categories, product profiles, and builder resources. Preview builds remain noindex; the public production build allows indexing. These checks establish eligibility and navigation, not a guarantee of Google indexing.
Verify the release on the actual production domain
Our saved release record reports type checking, 77 passing unit tests, 38 passing preview browser checks with four skipped production-funnel checks, and 12 passing production-build browser checks. Preview and production SEO checks and the Cloudflare Functions compilation also passed. These are our own engineering checks, not an independent SEO audit.
After publication, we fetched all 19 URLs on showmeyoursaas.com and checked HTTP 200, the expected canonical, index/follow metadata, and sitemap inclusion. We also verified three unsupported routes returned 404. Preserving the previous sitemap URLs mattered: a successful upload alone would not prove that the active deployment included both the old content and the new guides. The downloadable public record lists the paths, check time, and supported results.
What this launch proves, and what we still need to measure
We established that a bounded set of researched guides could be generated, linked, exported, and delivered with the intended technical metadata. We have not measured Google Search Console indexing, impressions, rankings, clicks, or conversions for this rollout. A crawlable page and a sitemap entry do not establish any of those outcomes, and we cannot attribute traffic growth to the launch without later data.
The next measurement step is to record the 19 launch URLs as a fixed cohort, inspect discovery and indexing in Search Console, and compare impressions, queries, and clicks over stated windows. Then look at useful onward actions, such as opening a relevant product profile. Report the observation period and other changes made during it. Our Search Console guide explains the basic reports; expansion should follow useful coverage and evidence, rather than a page-count target.
What another small directory can reuse
Start with one decision family and enough verified information to answer it. Keep the facts, editorial reasoning, template, and eligible route list explicit. Check the rendered result and the destination links, then review sources when pricing or product behavior changes. Expand when a new page answers a distinct question that the existing collection cannot resolve.
Google’s spam policies identify scaled content created primarily to manipulate rankings without helping users as abuse, regardless of how it is produced. Automation makes publishing repeatable; it does not supply the missing evidence or usefulness. For us, the transferable result is the research-and-verification process. Any search performance result remains future work.