Product-led SEO: How Zapier ranks for thousands of searches

The usual shape is a blog post that ranks, then asks the reader to go somewhere else to see the product. Product-led SEO removes the middle step: the page that ranks is the product, working, for the exact thing the person typed.

Done properly it is the most durable pattern in the Evaluate stage, because the pages keep earning long after you publish them. A post about a trend ages out; a page for connecting two specific tools stays useful as long as both tools exist. Done badly, it is the one PLG acquisition pattern that can cost you your entire search presence. Most of this page is about avoiding that.

How is product-led SEO different from programmatic SEO and content marketing?

Product-led SEO is a PLG acquisition pattern where product pages, rather than blog posts, rank for search queries and show their value on arrival. The pages are usually generated programmatically from data the product already holds: integrations, templates, use cases, or any other list it keeps. That makes it a form of programmatic SEO with one difference that decides everything: each page has a working product behind it, not a template with the keywords swapped. The term is Eli Schwartz’s, whose book of that title is the reference work on it.¹

Why a product page beats a blog post

Two mechanisms, and they compound.

The page collapses the funnel. A blog post ranking for “how to connect Slack and Google Sheets” has to persuade the reader to leave and go try something. A page that connects Slack and Google Sheets converts the intent in place. Every removed step removes the people who would have dropped at it, and search traffic is unusually impatient, because the searcher arrived with one specific task in mind.

The search itself tells you the context, so the page can be specific in a way a blog post can’t. Someone searching “[App A] + [App B] integration” has just told you what tools they run. A blog post can’t act on that. A generated page can.

That also connects this pattern to three others. Integration pages catch people already wiring tools together, which makes them a workflow embedding play. Free tools and templates reach individual employees before any buying committee exists, which is the entry point for bottom-up adoption. And with an API-first product, every endpoint is a rare, specific search that competitors rarely bother to index.

There’s a third effect, and it’s slower: people link to the page that solved their problem, not the essay about the problem. So these pages collect links for reasons a blog post rarely does.

Scaled content abuse: the policy that decides whether this works

Write-ups tend to warn vaguely about “thin content.” The actual constraint is more specific and more dangerous than that.

Google’s spam policies name scaled content abuse: “when many pages are generated for the primary purpose of manipulating search rankings and not helping users.”² The policy applies regardless of how the pages were produced, which means “we generated them from real database records” is not by itself a defense. This is an enforcement category, not advice. Pages that break it lose their rankings, and sometimes the whole site does.

Google draws the line at purpose, and it lands in almost exactly the same place as the line you care about commercially. A page for a real integration exists because someone needs that integration and can complete it there. A page that exists only because people search that phrase, with nothing working behind it, is exactly what Google is enforcing against.

This is already happening. Google ran spam updates in March and June 2026, and spam updates are one of the ways these policies get enforced.³ So if you are running a generated library today, the useful question is not whether enforcement is coming. It is whether your traffic already moved during one of those windows and you attributed it to something else.

This flips the usual order of work. Scale is the output of the pattern, not the input. Zapier has thousands of pages because it has thousands of integrations that actually run. Building the pages first and hoping the substance catches up later is how this fails.

What you can generate pages from

The format follows whatever structured data you actually own.

Three examples worth understanding, because each solves a different structural problem.

Zapier has the best math available. Its directory holds more than 9,000 apps,⁴ and the pairings people actually connect each get their own page, one per integration that genuinely runs. The library compounds without any additional content work, and every page survives scrutiny for the same reason: there is a working product behind it. The page’s job and the product’s job are identical, which is the strongest position you can be in.

HubSpot’s Website Grader targets a problem adjacent to what HubSpot sells. Someone grading their site isn’t shopping for a CRM. But they own a website and care how it performs, which is close enough to the buyer to be worth reaching.⁵

The part worth copying is that closeness. The tool has to solve a real problem completely, for someone who never buys anything.

Which leaves the question of how it earns anything, and the answer is a bridge rather than a gate: the tool’s output should end where the product begins. A checker that finds problems is one step from the product that fixes them, and a calculator that quantifies a gap is one step from the thing that closes it. That path converts because the user reached the conclusion themselves. Withholding half the result until somebody supplies an email is the alternative, and it is a worse trade than it looks: you collect email addresses, and the tool stops being the complete thing people linked to. A page that does not clear that bar reads as bait, and performs like it.

Canva maps its template library onto how people describe what they’re making rather than what the product is: “Instagram post maker,” “resume builder.”⁶ Far fewer people search for “graphic design platform” than for the thing they actually want to make. They search for the artifact they need by Friday. That reframe is worth stealing even without a template library, because your use cases are probably already the queries, phrased in your customers’ words instead of your category’s.

Does it apply to your product?

That demand row is the one people read wrongly, by checking it against a keyword tool. Eli Schwartz, who named this pattern, treats absent volume as encouraging, not disqualifying: finding none for a category “should not deter you but should rather excite your senses,” and he points at Zapier, where “before Zapier created pages for integrations between two disparate tools, there was no search demand for anything of the sort.”¹ A tool in 2012 would have reported nothing for those pairings, and the pages created the queries. What the row asks is not whether anything is measurable today, but whether the thing is something a person would ever go looking for. People were already wiring those tools together by hand. Nobody is ever going to search for a pairing that solves nothing.

Genuine difference per page is the whole game, and it is the same test Google is applying.

The measurement that doubles as a safety check

Your own analytics answer this in three queries, and the first doubles as the doorway-page test.

1. Do your programmatic pages convert better than your blog pages? They should, decisively, because the searcher lands on functionality instead of prose. If they convert at or below blog rates, you haven’t built product-led SEO. You’ve built a blog with worse writing, carrying policy risk your blog doesn’t.
2. Is conversion per page holding as the library grows? Track signups per page as you add pages. If traffic rises while signups per page fall, you are adding pages faster than you are adding value.
3. If you already have a library, check it against the update dates. Pull organic sessions per page group across the late-March and late-June 2026 spam updates. Check the May core update separately: a core update moving your pages is a quality signal, while a spam update moving them is an enforcement one, and they call for different responses. A sudden drop lining up with any of those windows is a different problem from a slow decline. Slow means your pages are aging. Sudden means they were reclassified.

Before you generate a thousand pages

1. Split your search traffic into branded and non-branded first. It is the one number here whose denominator you do not control, because Google decides what people typed. Branded traffic only grows as fast as your reputation does; non-branded is the part this pattern is supposed to move. Schwartz reports arriving at SurveyMonkey to find branded traffic near 90% of the total.¹ If you generate a thousand pages and the split does not move, the library is decorating a brand you already had.
2. Inventory your structured data before writing a single page. Integrations, templates, use cases, locations, or any other list the product already keeps. A short list means this isn’t your channel, and no amount of generation changes that.
3. Apply the keep-it-anyway test to the template, not the page. Would a page built from this template be worth having if it ranked for nothing? Answer that once, before you generate ten thousand of them.
4. Write the queries in your customers’ words, not your category’s. The gap between “design platform” and “Instagram post maker” is most of the opportunity.
5. Ship a first batch, not a first page. A single page proves nothing: it has no authority yet, the curve compounds over months, and there is nothing to compare it against. Schwartz is blunt that SEO rarely has the population for a clean test, and that what works on a templated library is changing a large random subset and reading it against the pages you left untouched.¹ Ship thirty of the thousand, hold the rest, and give it a quarter before deciding.
6. Instrument conversion per page from day one, and watch it as the library grows. That single series is both your performance metric and your early warning.

That is the third and last way the product carries itself outward under its own power: through the people it touches, through the marks it leaves behind, and through the pages it generates. None of the three asks your users to decide to help you.

The patterns that follow divide in two. The next pair run on what your users choose to make and say, which is slower to start and much harder for a competitor to copy, because you do not control the supply. After those come four that are less campaigns than facts about the product and how you sell it: what it is built on, how it is integrated, who it needs, and who is let in.

The first of them begins with a question every product with a creative surface eventually faces: what happens to the things your users make.

Updated August 2026