Case study · 2024 → 2026 · programmatic SEO, and the decision to undo it
We deleted 100,000 pages
We built pages at scale, and then deleted about a hundred thousand of them. The decision was easy once we measured each page by the signups it produced, and that is the whole argument of this page.
What programmatic SEO built
A template plus a data source makes pages faster than any team can read them. For a cross-browser testing product the combinations are close to infinite: browser, version, operating system, framework, language, error message. It worked for years, because search rewarded coverage and each page could plausibly claim to answer one narrow question.
Why it stopped working
Two things happened at once, and only one of them was in our control.
The category changed. AI answers took the top of the funnel for definitional queries — exactly the intent a generated page is built to catch. A reader who would once have clicked a result now reads the answer in place. That happened to everyone publishing informational content at scale.
Google's quality signals caught up with the template. Google's November 2024 core update was the first big one since its helpful-content signals were folded into core ranking, and another followed weeks later. We read them as a quality verdict on the generated pages, and a fair one: a large share existed because a template could produce them, not because they answered a question better than the results page above them.
The call: cut fast, rather than defend
We did not wait for a second opinion. We started removing thin, unhelpful content across the whole site, and roughly a hundred thousand pages came out. The real question was whether to keep a library Google had just flagged as dragging the rest of the site down.
What made it a clear decision rather than a brave one: those pages were not where signups came from. A page that ranks for a definition and sends a reader who never opens an account is a cost with a traffic number attached to it. Once you segment by what a page-class actually produces rather than what it attracts, most of the library defends itself and a long tail cannot.
What happened
Signups kept growing year on year through 2025, the year the cut went through, which is the scoreboard the decision was judged on. In January 2026 we moved every URL to a new domain as part of the rebrand; the rebrand page has the migration mechanics.
How to know what to cut, before you cut it
Segment by intent and by template, not by URL. Measure conversion per page-class, not traffic per page. Keep anything that answers something the results page above it does not. Redirect only where a real equivalent exists, and return a clean gone status for the rest rather than pointing thousands of dead URLs at a category page. Then judge the cut by conversion rate, since a prune is designed to lose visits that were never going to become accounts.
What I would do differently
Instrument for conversion at the first template, not at the hundred-thousandth page. A template that can produce a page nobody should read will produce a hundred thousand of them, and every one of them will look fine in a traffic report.
Proof
- PUBLIC Page counts are public. The current sitemap index declares about 8,250 URLs across five files — product, blog, dynamic, video and support — which anyone can count today.
- THIRD-PARTY The before figure is checkable the same way: archived copies of the old sitemaps in the Wayback Machine show the footprint when it was at its largest.
- STATED The approximate number of pages removed, and signups through the period. Internal; walkthrough on request.
Every figure on this page carries a proof badge. PUBLIC links open for anyone; THIRD-PARTY corroborates direction from an independent source; STATED is internal analytics, quoted with its date, with a walkthrough available in conversation.
← The inbound engine, 2018 → 2026 · Rebrand: LambdaTest → TestMu AI →