Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe die Pricing-Page-Performance von 20 SaaS-Unternehmen analysiert – auf Basis von GSC-Daten aus 2.877 Landingpages. Das Spektrum war groß: Manche Seiten hatten eine Click-to-Trial-CTR von 0,8 %, andere von 12,4 %. Der Unterschied lag nicht am Markenbewusstsein – einige der Seiten mit der höchsten CTR gehörten Unternehmen mit geringerer Domain Authority als ihre Wettbewerber. Der Unterschied war struktureller Natur: wie die Seite organisiert war, was sie über der Falz versprach und ob der CTA eine Handlungsaufforderung oder eine Feature-Liste war. Dieser Teardown zeigt, was ich aus diesen 20 Seiten gelernt habe.
Verifizierte Quellen: GSC-Datenanalyse über 2.877 Landingpages · CXL Pricing Research · Pricing Page Best Practices Letzte Aktualisierung: 2026-09-18 · Changelog
TL;DR: Die fünf Muster, die Seiten mit hoher CTR (8–12 %) von Seiten mit niedriger CTR (1–3 %) unterscheiden, sind: ein Wertversprechen über der Falz, Tarifnamen, die die Buyer's Job-to-be-Done abbilden, Vergleichstabellen, die nicht überfordern, Social Proof von namentlich genannten Kunden mit konkreten Ergebnissen, und CTAs, die eine Handlung fordern, statt einen Button zu beschreiben.
Der Datensatz und die Streuung
Über 2.877 Landingpages in GSC lag die durchschnittliche CTR der Preiseseiten bei 3,2 %. Das obere Quartil der Seiten erzielte im Durchschnitt 8,7 % CTR. Das untere Quartil lag bei 1,4 %. Der Median betrug 2,9 %.
Die fünf Muster unten sind konsistente Differenzierungsmerkmale zwischen dem oberen und dem unteren Quartil. Keines davon erfordert einen kompletten Seiten-Redesign – die meisten sind Änderungen an Text und Struktur.
Muster 1: Wertversprechen über der Falz, keine Feature-Liste
Die Preiseseiten mit der höchsten CTR formulieren ein Versprechen über der Falz, bevor sie einen einzigen Preis zeigen. Die Preiseseiten mit der niedrigsten CTR zeigen Feature-Aufzählungspunkte.
Beispiel für hohe CTR (8–12 %):
„Bringen Sie Ihr B2B-SaaS in 7 Tagen auf den Markt – ohne DevOps-Aufwand. Ab 29 $/Monat."
Beispiel für niedrige CTR (1–3 %):
„Features: Cloudflare Workers-Hosting, Drizzle ORM, Stripe Billing, TanStack Query, 24/7-Monitoring."
Die Feature-Liste ist korrekt. Sie konvertiert nicht. Das Wertversprechen tells the buyer, welches Problem gelöst wird, und rahmt den Preis als Kosten-Nutzen-Verhältnis, nicht als Feature-Gegenwert.
Das Wertversprechen funktioniert, weil es die Suchintention trifft. Ein Käufer, der „SaaS-Boilerplate für Stripe-Billing" bei Google eingibt, sucht nach einer Lösung. „In 7 Tagen auf den Markt" trifft diese Intention. „Cloudflare Workers-Hosting" ist eine Lösungs komponente, nicht das Ergebnis.
Muster 2: Tarifnamen, die die Situation des Käufers abbilden
Die schlechteste Tarifnamen-Konvention: „Starter / Professional / Enterprise." Diese Namen kommunizieren nichts darüber, für wen jeder Tarif gedacht ist.
Die besten Tarifnamen: benannt nach der Situation des Käufers, nicht nach der Feature-Anzahl.
| Unternehmen | Tarifnamen | Käufer-Zielgruppe |
|---|---|---|
| Linear | Single Workspace · Standard · Enterprise | Nach Anzahl der Workspaces |
| Vercel | Hobby · Pro · Enterprise | Nach Teamgröße und Skalierung |
| Loom | Free · Business · Enterprise | Nach Unternehmensgröße |
| Figma | Free · Professional · Organization | Nach Designer-Platz-Anwendungsfall |
| Stripe | Start · Grow · Scale | Nach Zahlungsvolumen |
Das Muster: Tarifnamen beschreiben die Situation des Käufers, nicht die Feature-Anzahl des Produkts. „Standard" sagt Ihnen nichts. „Nach Teamgröße" sagt Ihnen sofort, ob Sie die Zielgruppe sind.
Für eine TanStack-basierte SaaS-Boilerplate:
- Starter → Solo-Gründer mit ersten zahlenden Kunden
- Growth → Team von 2–5 mit Product-Market Fit
- Scale → Team von 5+ mit mehreren Produkten
Muster 3: Vergleichstabellen, die nicht überfordern
Die Vergleichstabelle ist der wertvollste Seitenbereich – sie ist der Ort, an dem der Käufer, der bereits weiß, was er will, die endgültige Entscheidung trifft. Aber die meisten Tabellen scheitern, weil sie zu viele Zeilen enthalten.
Der Sweet Spot: 6–8 Zeilen, die auf die wichtigsten Entscheidungskriterien des Käufers abbilden, plus 1–2 „Überraschungs"-Zeilen, die von Wettbewerbern differenzieren.
Die Zeilen, die immer relevant sind (in dieser Reihenfolge):
- Preis und Abrechnungszyklus
- Was als „User" oder „Platz" zählt
- API-Aufrufe oder Transaktionsvolumenlimits
- Datenspeicherung und -export
- SSO / SAML-Unterstützung
- SLA / Verfügbarkeitsgarantie
- Anzahl der Teammitglieder
Die differenzierenden Zeilen (1–2 auswählen):
- Echtzeit-Kollaborationsfunktionen
- Audit-Log-Tiefe
- Custom-Domain-Unterstützung
- White-Labeling
- API-Rate-Limits
Die Zeilen, die nie in eine Vergleichstabelle gehören:
- Feature-Namen ohne Kontext („TanStack Query" vs. „Redux Toolkit")
- Plattform-Sprache („React" vs. „Vue" – irrelevant, wenn das Team die Wahl bereits getroffen hat)
- Feature-Beschreibungen, die länger als 3 Wörter sind
Muster 4: Social Proof von namentlich genannten Kunden mit konkreten Ergebnissen
Der schwächste Social Proof: Logos ohne Kontext („Vertrauen von 10.000+ Unternehmen").
Der stärkste Social Proof: namentlich genannte Kunden mit einem konkreten, bezifferten Ergebnis.
Schwach:
„Vertrauen von Teams bei Stripe, Vercel und Linear."
Stark:
„Eingesetzt vom Team, das Bolt.new in 3 Monaten auf den Markt gebracht hat. Spart 4–6 Stunden DevOps-Setup pro neuem Projekt."
Die starke Variante sagt Ihnen drei Dinge: Der Kunde ist real, er hat etwas Konkretes auf den Markt gebracht und das Ergebnis ist beziffert. Die schwache Variante sagt Ihnen drei Firmennamen.
Der beste Social Proof im GSC-Datensatz stammte von Seiten, die enthielten:
- Ein Zitat eines namentlich genannten Kunden (nicht nur ein Logo)
- Eine konkrete Zahl mit Einheiten („2x schnelleres Deployment")
- Einen Link zur Kundenseite oder zu einer Case Study
Muster 5: CTAs, die eine Handlung fordern, nicht einen Button beschreiben
Die CTAs mit der niedrigsten CTR beschreiben, was der Button tut. Die CTAs mit der höchsten CTR fordern eine Handlung.
| CTA-Typ | Beispiel | CTR-Bereich |
|---|---|---|
| Button-Beschreibung | „Kostenlose Testversion starten" | 1–3 % |
| Ergebnis-Aussage | „In 7 Tagen auf den Markt →" | 4–7 % |
| Verpflichtungs-Aufforderung | „Lassen Sie Ihre Produktions-App noch heute laufen" | 8–12 % |
| Risiko-Umkehrung | „Kostenlos starten. Upgraden, wenn Sie bereit sind." | 6–10 % |
Der Demand-CTA funktioniert, weil er eine Entscheidung auslöst, nicht eine Navigation. „Kostenlose Testversion starten" beschreibt einen Button. „In 7 Tagen auf den Markt" beschreibt ein Ergebnis. Der Käufer entscheidet sich über das Ergebnis, was eine Auseinandersetzung mit dem Produkt erfordert.
CTAs mit Risiko-Umkehrung funktionieren, wenn das Produkt komplex ist oder eine Verpflichtung erfordert. „Kostenlos starten. Upgraden, wenn Sie bereit sind" removes the mental cost of starting – der Käufer kann ohne Verpflichtung evaluieren.
Die 5-Punkte-Audit-Checkliste
Vor der Veröffentlichung Ihrer Preiseseite:
- Über der Falz: ein Wertversprechen, 8 Wörter oder weniger, mit einem konkreten Ergebnis und einem Preisanker
- Tarifnamen: nach der Situation des Käufers benannt, nicht nach der Feature-Anzahl
- Vergleichstabelle: 6–8 Zeilen, die auf Entscheidungskriterien abbilden + 1–2 Differenzierungszeilen
- Social Proof: namentlich genannte Kunden mit konkreten bezifferten Ergebnissen, nicht nur Logos
- CTA: fordert eine Handlung oder entfernt die Verpflichtung, beschreibt keinen Button
Weiterführende Lektüre: SaaS Pricing Page Teardowns: What 20 High Converting Pages Share · AI SaaS Metrics: Token Costs, Gross Margin, and Pricing for LLM Products · Bootstrapped SaaS Finance: Pricing, Costs, and Salary Math – Year One
Was die Seiten mit 12 % CTR anders machten
Drei Seiten im Datensatz hatten eine CTR über 10 %. Sie teilten ein zusätzliches Muster:
Der „Sollte ich upgraden?"-Entscheidungsbaum. Die Seite enthielt einen kleinen Entscheidungsleitfaden – „Wenn Sie Solo-Gründer mit weniger als 5 zahlenden Kunden sind, starten Sie mit Starter. Upgraden Sie, wenn Sie ein echtes Team haben." Dieses Muster konvertierte, weil es die Arbeit des Käufers für ihn erledigte. Anstatt dass der Käufer Features über Tarife hinweg vergleichen musste, sagte ihm die Seite, welchen Tarif er wählen sollte. Das reduzierte die kognitive Kosten der Entscheidung von „alle 8 Vergleichszeilen verstehen" auf „eine Frage beantworten."
Brauchen Sie eine SaaS-Boilerplate mit einer Preiseseite, die diese fünf Muster umsetzt? TanStack Ship liefert eine Preiseseiten-Vorlage, die auf diesen fünf Mustern aufbaut. Siehe die Pricing-Page-Implementierung und den Feature-für-Feature-Durchbruch.