Why Zapier Refuses to Publish Most of Its Pages

Every guide to programmatic SEO cites the same example, and cites it for the wrong reason.

"Zapier built 50,000 integration pages" is the line, repeated as permission to generate. The pages do work: the best-attributed estimate puts them at 5.8 million monthly organic visits (Ahrefs, via GrackerAI), though public figures disagree by roughly three times and we re-verified none of them.

What nobody has counted is the machine underneath. On 18 August 2026 we fetched every shard of Zapier's sitemaps and found 140,000 app-pair pages — nearly three times the count everyone repeats.

That is still the least interesting number here. Zapier has about 9,600 apps, and any two of them could have a page — 45.7 million in all, of which Zapier publishes 0.3%.

Below: what we counted, what it costs to copy, and what we could not measure.

Results at a glance

One note on the traffic figures, because we are not going to pretend they are settled. The commonly cited numbers disagree with each other by roughly three times: 5.8 million monthly visits for the integration pages (GrackerAI, citing Ahrefs), 9 million domain-wide (Salt Agency, ViewEngine), and 16 million in 2026 roundups for which we found no primary source.

We re-verified none of them and we have no traffic data of our own. Everything we state as ours is a count we made on 18 August 2026.

What Zapier actually sells

Zapier connects apps. If you want Google Sheets to talk to Slack, Zapier is the wire.

That makes its integration pages an unusual kind of programmatic content. A page about connecting two tools is not marketing written about the product — it is the product's own catalogue, rendered.

Which is why the template works here and fails for the sites copying it. The template is trivial. The directory of working integrations behind it is not.

Why one app adds thousands

Here is the mechanic, and it is the reason this case study exists. A directory of apps grows one row at a time. A directory of app pairs grows as the square of itself.

Zapier's newest app did not add one possible page. It added roughly 9,600 — one against every app already there. The tenth app added nine.

So a combinatorial catalogue does not have a content problem. It has a selection problem. The pages can always be generated, so the only real decision is which fraction deserves to exist.

Your version: if your programmatic layer is a join between two tables, write down the size of the full cross product before you build anything. That number is not your opportunity. It is the thing you now have to say no to.

The myth everyone repeats

Every write-up says "50,000+ integration pages". We counted about 140,000 pair pages and 9,600 app pages.

The drift is explainable. Ahrefs measured roughly 63,000 templated pages in 2023, and the catalogue has about doubled since. The industry's shorthand never updated.

It matters because the quoted figure is the one people benchmark against. Aim to "match Zapier" at 50,000 pages and you are aiming at a target that moved years ago.

Your version: when a competitor's page count is load-bearing in your plan, count it yourself. It takes twenty minutes, and the public number is routinely years stale.

Publishing almost nothing, on purpose

This is the finding. Every app in the directory has a page, and every pair of apps could have one. Almost none does.

Some of those pairings are meaningless, and that is the point rather than a flaw in the arithmetic. Nobody needs a page connecting two obscure tools that share no users.

Knowing that is cheap. Acting on it — leaving 45.6 million pages unbuilt when your CMS would happily render them — is the expensive part, and the part nobody copies.

Your version: the constraint that makes a programmatic layer survive is not how well you generate. It is how confidently you decline. Decide the rule that says no before you build the thing that says yes.

Not one duplicate anywhere

We checked every sitemap shard for pairs submitted in both directions. There are none.

That is stricter than it sounds. The reverse URL works: swap the two app names and the page still loads. Zapier could list both and double the catalogue tomorrow, and plenty of sites would.

Instead both directions declare the same canonical, and only one is ever submitted. The reverse stays reachable for anyone who lands on it, and invisible to the index.

One thing we could not work out: the direction Zapier picks is not alphabetical. There is a rule, probably which app carries more demand, and the sitemap alone does not reveal it. We are not going to guess in public.

Your version: in any catalogue built from a join, decide the canonical direction once, in code, and submit only that. Every symmetric pair you ship both ways doubles your index footprint and adds nothing a reader wanted.

How a new product launches

Zapier Agents, the AI product, has its own sitemap of 102 URLs.

That is the pattern still being applied in 2026, and applied the same cautious way. A company that has proven it can generate six figures of pages launched a new surface with a hundred.

Your version: new page types start small even at companies that are extremely good at this. If your first version of a template ships 50,000 URLs, you skipped the step where you find out whether anyone wants ten.

What you can copy

• Compute the full cross product first, then treat it as the thing you must decline, not the thing you must build.
• Pick one canonical direction for every symmetric pair and submit only that one.
• Count a competitor's pages yourself. The public figure for Zapier is off by roughly three times.
• Launch new page types small. A hundred URLs is a real number for a real product.
• Audit for relational failures — canonicals, hreflang, internal links — before adding a zero.

What you cannot copy

You probably do not have 9,600 integrations. The catalogue is the output of years of partner and engineering work. The pages render that asset; they do not substitute for it.

The query and the product are the same thing. Someone searching how to connect two tools wants exactly what Zapier sells. That is a business model, not a content decision.

What we could not measure, stated plainly. We have no traffic, revenue or conversion data of our own for Zapier, and the third-party figures disagree by about three times.

We did not measure rankings or backlinks. We have no site audit either: we pointed our own crawler at zapier.com twice and both runs were still crawling when they timed out, so rather than publish a half-finished panel we cut the section.

Sitemap URLs are not indexed pages, indexed pages are not visits, and visits are not revenue. We also do not know the rule that decides which direction of a pair gets published.

And the 45.7 million figure assumes any two apps could pair. Many pairings are meaningless — which is the argument for restraint, not a defect in the count.

Run this census yourself

1. Read /robots.txt and follow every Sitemap: line. Zapier declares eleven. The one named after a thing you did not know they built is the interesting one.
2. Count occurrences, not lines. Sitemap files are often a single line, so grep -c returns 1 and you will conclude a 57-shard index has one shard. Use grep -o '<loc>' | wc -l.
3. Fetch every shard when the number matters. Shard sizes are not uniform — one Zapier feed holds a few hundred URLs in its first shard and tens of thousands in its last. Sampling would have been wrong by an order of magnitude.
4. Work out the cross product. If the pages are built from a join, count the entities on each side and multiply. Compare that with what is published.
5. Check for duplicates. Reverse the pair, strip the query string, and count how many URLs restate another. This is where a big number becomes an honest one.
6. Audit one page and read which group loses points, not the score.

Still clean at enormous scale

We put zapier.com through our own Website Audit to see what all that restraint costs technically.

One critical issue, one warning, four notices, and 116 checks passed. That is a cleaner result than most brochure sites manage with fifty pages.

Which is the whole argument in a different form. A catalogue you refuse to inflate is a catalogue you can keep tidy — and the 45.6 million pages Zapier declined to publish are 45.6 million pages it never has to keep tidy either.

Frequently asked questions

Decide your stopping rule

Zapier's catalogue is not impressive because it is large. It is impressive because it is a fraction of a percent of what it could be, and someone decided that on purpose, repeatedly, while owning a system that would render the other 45.6 million pages on request.

So the question to ask about your own programmatic plan is not how many pages you can produce. Everyone can produce all of them. It is which rule tells you to stop — and whether you would still trust that rule on a quarter when traffic is flat.

Start where we started — audit one page free — and you will know in ninety seconds whether your architecture can carry what you are planning to put on it.

Measured on 18 August 2026 against zapier.com by fetching every shard of its app and app-pair sitemaps and counting <loc> occurrences, plus canonical tags read from live pages. Exact counts were 9,566 apps and 140,173 pair pages; rounded figures are used in the body for readability. Sitemap URLs are not indexed pages and not traffic.

Third-party traffic figures are credited to GrackerAI/Ahrefs, Salt Agency and ViewEngine, disagree with one another by roughly three times, and were not independently re-verified. No traffic or revenue data for Zapier was available to us, and no site audit completed. Third-party metrics change; re-run anything here before you rely on it.