Creating Competitor Comparison Pages Programmatically for SEO/AEO

One of the founders in our mastermind had written three competitor comparison pages by hand. Us versus competitor A, us versus competitor B, that kind of thing. Each one took him a long time, partly because the research is genuinely slow and partly because, as he admitted himself, perfectionism kept getting in the way. He wanted to keep going, maybe get to ten or fifteen competitors, but the math on that was ugly.

• Three pages down, a long way to go. He'd handled the most obvious competitors but wanted ten to fifteen total.
• Perfectionism was the real bottleneck. Not the research itself, but the instinct to keep polishing before moving to the next page.
• The math doesn't scale. If page three took days, page fifteen wasn't happening this quarter, let alone the rest of the list.

That's a familiar wall. The content works, or at least everyone believes it works, for search and for the newer discipline of answer engine optimization, getting cited inside AI chat answers instead of just ranking in a list of blue links. But writing it one page at a time by a founder with a dozen other things to do is not a system. It's a hobby that happens to be strategically important.

• Nobody in the room questioned the value. Everyone agreed comparison pages are worth doing for both SEO and answer engine optimization.
• The disagreement was never about the goal. It was about how you actually produce a hundred of these pages instead of three.
• A founder writing pages solo isn't a system. It's a valuable habit that happens to not scale past a handful of competitors.

Two Very Different Ways to Point AI at Your Competitors

One member described a lighter-weight version of this that his marketing lead had already built: an agent that scrapes a list of named competitors and keeps a running file updated on their features and positioning. Originally this wasn't even built for SEO. It was built for sales enablement, feeding what the team calls battle cards, the internal cheat sheets a rep pulls up mid-call when a prospect says "we're also looking at X."

• Built for sales, not SEO. The original use case was arming reps with current competitor intel mid-call, not content marketing.
• Replaced a full-time watcher. A junior marketing person used to spend real hours reading competitor press releases and feature pages just to keep the cards current.
• Now a human just approves updates. The agent does the watching and drafting; a person reviews before anything goes live.

A different founder took it further. Instead of scraping marketing pages from the outside, he created accounts, paid for a few of the higher tiers, and let a coding agent with browser access actually use each competitor's product. It logged in, clicked around, took screenshots, and built out pros-and-cons lists and feature inventories from what it found inside the app, not just what the competitor's own homepage claimed about itself.

• Grounded in the product, not the marketing page. Comparisons built from what the competitor's app actually does, not what its homepage claims.
• A two-step pipeline. One AI pass researched inside each competitor's product; a second pass turned those reports into finished comparison pages.
• Not for everyone. Logging into a direct competitor's paid tiers raises its own comfort questions, but it's worth knowing the ceiling is that high if you want it.

The Permutation Math Nobody Does By Hand

Here's where this stops being a writing problem and becomes a systems problem. Say you have ten real competitors. The naive approach is ten pages: us versus each of them. But the actual content opportunity is much bigger than that, because searchers and AI answer engines query this stuff in a lot of different shapes.

• Direct comparisons. Your product versus each named competitor, one page per pair.
• Alternatives pages. "Alternatives to competitor A," written for searchers who haven't decided you're even in the conversation yet.
• Standalone reviews. A review of a single competitor, useful for AEO because it's the kind of neutral-sounding page an AI answer engine likes to cite.
• Cross-competitor comparisons. Competitor A versus competitor B, or even three-way match-ups, where you're not a party to the page at all but you still own the real estate.

Multiply that out across ten competitors plus your own product and the page count isn't ten, it's in the hundreds. One founder in a related mastermind built an AI agent product with roughly a thousand integrations, and he ran every possible permutation of that list through his own tool. That's somewhere in the ten to twenty thousand page range, a number that was never going to happen with a writer typing pages one at a time.

• Claude wrote every page. A human writer was never going to touch ten to twenty thousand pages one at a time.
• The pages doubled as product demos. Because his product is itself an AI agent, he had it mock up realistic in-app conversations about each integration pair.
• Every page linked to every other permutation. Closed out with FAQs, exactly the format that tends to get pulled into AI-generated answers.

Where the Human Still Belongs

The instinct once you see numbers like that is to ask who's going to quality-check two hundred pages, and whether you need to hire a writer to review what the AI produces before it goes live. My honest answer is that the QA step matters less for lead generation than people assume. Whether a page is at ninety-five percent polish or ninety-nine percent polish is not going to move how many leads it generates. What QA actually buys you is a reduction in legal exposure, catching a missing checkbox in a feature comparison or a claim about a competitor that's gone stale.

• Polish doesn't move lead volume much. The gap between 95% and 99% polish isn't what determines how many leads a page generates.
• QA's real value is legal, not conversion. Catching a missing checkbox or a stale claim about a competitor before it goes live.
• So get to 90% with 5% of the effort first. Let the AI do essentially everything, then decide separately whether a human pass is worth adding.

If you do want a person reviewing pages, a reasonable reviewer can get through twenty to thirty pages a day, which means two hundred pages is roughly two weeks of review work, not two quarters. On model choice, I'd just use whatever the best available model is for the whole workflow instead of overthinking which tier to save money on.

• Review speed: 20-30 pages a day. Two hundred pages is roughly two weeks of review work, not two quarters.
• Use the best model, don't ration. I wrote a two-hundred-thousand-word book with Claude Fable without coming close to using up a $200-a-month subscription.
• Cost stays small at this scale. Two hundred web pages is a fraction of that word count, so running it all through the best model is genuinely just a few hundred dollars.

The Legal Question Everyone Asks and Rarely Answers

This is the part that stops most founders before they start, and it's worth being direct about it. Publishing comparison pages about named competitors is not illegal in the United States as long as the information in them is accurate.

• Accuracy is the whole legal test. Not whether you named a competitor, but whether what you said about them is true.
• The real-world consequence of getting it wrong is small. A correction letter is far more common than a lawsuit.

One member in the group has lived this on both sides. His company competes against a platform many times its size, and for two years they've had a page up making a specific, quantified claim about how quickly customers of that larger competitor end up handing control back to IT after buying in expecting a business-led rollout. The information came straight from the competitor's own public materials and screenshots, so it's defensible by construction.

• The claim is pulled from the competitor's own materials. Screenshots and public documentation, defensible by construction rather than by opinion.
• The attorney's playbook is correction, not confrontation. If the competitor disputes the number, ask what the accurate figure is and update the page.
• A correction can become its own content. "We updated this number because the vendor reached out" is a genuinely good follow-up article.
• Two years in, nobody has come knocking. The page keeps doing its job precisely because it stayed accurate.

The same member has watched this from the other direction too. A competitor once published an article comparing itself to his company that was technically accurate but framed in a way that badly underrated his product's strengths.

• The lawyer's advice was blunt. Unless you can prove what they published is factually wrong, fighting it just burns money and gets you nowhere.
• The better move is your own accurate version. Publish your side of the story rather than trying to suppress theirs.
• Accuracy is the whole game either direction. If you get something wrong, the fix is a correction, not a courtroom, and that's true whether you're the publisher or the subject.

There are two closing details worth doing once the pages exist, and people skip both constantly.

• Interlink everything from a footer hub page. So crawlers and AI indexing agents can find the full set instead of stumbling on one page at random.
• Submit your sitemap to Google and Bing/Microsoft Search Console. So new pages get indexed faster instead of waiting for an organic crawl to find them.

Neither takes more than a few minutes, and both are the difference between a few hundred pages sitting quietly on your server and a few hundred pages actually showing up when someone searches. None of this requires a large team or a big budget. It requires a list of every competitor you have, a willingness to let an agent do the first ninety percent of the writing, and someone accurate enough to check the details before they go live. The founders furthest ahead on this aren't the ones with the biggest content teams. They're the ones who treated this as a data and automation problem instead of a writing problem, and let the machine handle the part that used to eat their whole week.