Next.js SaaS Landing Page: Was jeder Abschnitt beweisen muss

Eine Next.js SaaS Landing Page ist die eine Seite, die jedes Produkt braucht und die niemand von Grund auf gestalten will. Du suchst nach einem nextjs saas landing page template oder einer SaaS Landing Page Vorlage und bekommst eine lange Liste (geprüft am 16. Oktober 2026): Open-Source-Starter wie Saas UI (opens in a new tab), bezahlte Kits wie das SaaS-Template von Magic UI (opens in a new tab) mit 14 Abschnitten (Teil von Magic UI Pro (opens in a new tab), $199 einmalig) und Galerien wie shadcnblocks (opens in a new tab), die 292 Hero-Blöcke und 96 Pricing-Blöcke auflistet. Was diese Seiten selten sagen: was jeder Abschnitt einem Besucher beweisen muss, welche du weglässt und was mit dem Layout auf einem 390px-Smartphone passiert.

Dieses Tutorial baut die Startseite Abschnitt für Abschnitt, in Next.js mit Tailwind CSS v4, mit der Vorlage Landing Page von Wingo UI, der Bibliothek, die wir bauen. Wir sind also nicht neutral. Die Vorlage funktioniert auch als shadcn landing page: Jeder Abschnitt ist eine Quelldatei in deinem Repo, mit derselben Art von Tokens gestylt, und du änderst ihn wie jede shadcn-Komponente. Jeder Abschnitt bekommt hier seine Aufgabe, die Props, die zählen, und sein Verhalten auf dem Smartphone.

Welche Abschnitte braucht eine SaaS Landing Page?

Bei der Reihenfolge sind sich die meisten Guides einig: Hero, Proof, Features, Preise, FAQ, abschließender Call to Action. Der Guide von 21st.dev zu Landing-Page-Abschnitten (opens in a new tab) hält etwas fest, das du dir merken solltest: Die Abschnitte sind ein Menü, aus dem du wählst, und eine Seite mit drei ehrlichen Blöcken schlägt eine mit neun halb gefüllten.

Bleib auf der ganzen Seite bei einer einzigen Hauptaktion. Wenn der Hero „Kostenlos starten“ sagt, sagen der hervorgehobene Plan und das Schlussband dasselbe und führen zur selben Route.

Wie richte ich die Landing Page im App Router ein?

Falls du nach einem Starter für nextjs landing page tailwind gesucht hast, ist das hier das ganze Setup. Es setzt ein Next.js-Projekt mit App Router, Tailwind CSS v4 und initialisiertem Wingo UI voraus (npx wingo-ui@latest init). Installier die Vorlage. Sie holt jeden Abschnitt, aus dem sie besteht (Header, Hero, Logos, Features, Tour, Zahlen, Zitate, FAQ, CTA, Footer), als Quelldateien, die dir gehören:

npx wingo-ui@latest add landing-page

Die Abschnitte sind Client-Komponenten, weil das Menü, der Pricing-Umschalter und das FAQ-Accordion auf Taps reagieren. Der Export metadata funktioniert nur in einer Server Component, also teilst du die Route in zwei Dateien: eine Server-page.tsx, der die Metadaten gehören, und eine Client-Komponente, die die Seite rendert.

// app/(marketing)/page.tsx
import type { Metadata } from "next";
import { Home } from "./home";

export const metadata: Metadata = {
  title: "Acme: planen, schreiben und ausliefern in einem Workspace",
  description: "Roadmaps, Docs und Automationen für kleine Teams. Kostenlos für bis zu fünf Personen.",
};

export default function Page() {
  return <Home />;
}

// app/(marketing)/home.tsx
"use client";

import Link from "next/link";
import { LandingPage } from "@/components/templates/landing-page";
import { faq, features, plans } from "./home-content";

export function Home() {
  return (
    <LandingPage
      linkComponent={Link}
      ctaTone="brand"
      heroLayout="split"
      labels={{
        heroAnnouncement: "Timelines sind live",
        heroTitle: "Roadmaps ausliefern statt Status-Meetings abhalten",
        heroDescription: "Acme hält Pläne, Docs und Automationen an einem Ort, damit ein Team aus fünf Leuten so viel schafft wie eins aus zehn.",
        heroPrimary: "Kostenlos starten",
        heroSecondary: "Demo buchen",
        ctaPrimary: "Kostenlos starten",
      }}
      heroProps={{ hrefs: { primary: "/sign-up", secondary: "/demo" }, socialProof: false }}
      showAnnouncement={false}
      showLogos={false}
      showStats={false}
      showTestimonials={false}
      features={features}
      plans={plans}
      faq={faq}
      faqProps={{ jsonLd: true }}
      onSubscribe={async (email) => {
        const response = await fetch("/api/newsletter", {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify({ email }),
        });
        if (!response.ok) throw new Error("Anmeldung fehlgeschlagen");
      }}
    />
  );
}

Der Server rendert trotzdem die ganze Seite als HTML, also lesen Suchmaschinen und KI-Assistenten jede Überschrift und jede Antwort, ohne JavaScript auszuführen. linkComponent={Link} schickt jeden Link der Seite (Header, Hero, Feature-Karten, Pläne, Footer) durch next/link. onSubscribe ist wichtiger, als es aussieht: Ohne diesen Prop wartet der Newsletter im Footer 900 ms und zeigt trotzdem seine Bestätigung. Eine Launch-Seite kann so null E-Mails sammeln und dabei völlig normal aussehen. Wenn die Seite in deinem eigenen Site-Layout sitzt, ergänze header={false} und footer={false}.

Was muss der Hero beweisen?

Eine Sache: was der Leser bekommt. Der Titel nennt das Ergebnis, die Beschreibung sagt, wie, und der Hauptbutton ist der günstigste nächste Schritt (ein kostenloser Start schlägt „Zugang anfragen“). Die Hero Section rendert den Titel standardmäßig als h1 der Seite (headingAs="h1") und setzt die Announcement-Pille, beide Aktionen und eine Reihe Social Proof drumherum.

Zwei Details zählen für die Geschwindigkeit. Das Standard-Produktbild ist mit Tokens im DOM gezeichnet, folgt also Light und Dark Mode, und vor dem ersten Paint steht kein Bild-Request. Und die Einblend-Animation läuft nie während der Hydration: Das Server-HTML ist das fertige Layout, und nur ein Hero, der später durch eine Client-Navigation eingehängt wird, gleitet animiert herein. web.dev wertet einen Largest Contentful Paint (opens in a new tab) von 2,5 Sekunden oder weniger beim 75. Perzentil als gut, und eine Hero-Überschrift, die auf ein Fade-in wartet, arbeitet gegen diesen Wert.

Auf dem Smartphone stapeln sich die beiden Buttons in voller Breite, und das Layout split schiebt das Bild unter den Text. Das Mockup passt seine eigene Sidebar, seine Spalten und sein Diagramm an seine Breite an, also passt es ohne seitliches Scrollen auf einen 360px-Screen.

Wenn du stattdessen einen echten Screenshot zeigst, gib ihn über die Vorlage als heroProps={{ media: <Image src="/product.png" alt="Das Acme-Board" width={1440} height={900} fetchPriority="high" /> }} weiter. Die expliziten Werte für width und height reservieren den Platz, damit nichts verrutscht, und fetchPriority="high" zieht das Bild in der Warteschlange nach vorn, denn es wird zum LCP-Element, sobald das gezeichnete Mockup weg ist. Lass priority weg: Next.js 16 hat es zugunsten von preload als veraltet markiert, und die Image-Doku empfiehlt in den meisten Fällen fetchPriority oder loading="eager". media: null blendet das Bild ganz aus.

Wohin gehört Social Proof, und was, wenn du noch keinen hast?

Direkt unter den Hero, vor die Features. Genau dort fragt sich der Besucher, wer das sonst noch nutzt. Die Vorlage liefert Beispieldaten als Social Proof für eine fiktive Firma Acme an mehr Stellen als den offensichtlichen: die Logo-Reihe („Trusted by 12,000 teams“), das Zahlenband („38% faster delivery“, „99.99% uptime“), die Zitate und auch die Reihe unter den Hero-Buttons, die fünf Avatare, „Loved by 12,000 teams“ und „4.9/5 from 2,300 reviews“ zeigt. Ersetz jede davon durch deine eigenen Daten oder schalte sie ab. Deshalb setzt das Beispiel oben showLogos, showStats und showTestimonials auf false und gibt dem Hero socialProof: false mit. Erfundene Logos und Zahlen sind der schnellste Weg, einen skeptischen Entwickler zu verlieren, und eine Seite ohne Proof-Abschnitt wirkt wie ein frühes Produkt, und das ist ehrlich.

Wenn die Logos echt sind, gib sie als logos mit name, icon und optional href weiter. Das Marquee pausiert bei Hover und bei Tastaturfokus, und bei reduzierter Bewegung wird es zu einer stehenden, umbrochenen Reihe.

Wie sollte der Feature-Abschnitt auf dem Smartphone wirken?

Jedes Feature beantwortet, wie das Produkt das Versprechen des Heros hält. Drei bis sechs reichen; darüber hinaus überfliegen Leser die Titel und überspringen den Rest. Die Vorlage rendert sie mit dem Feature Grid im Layout bento: zwei breite Zellen und eine hohe Zelle mit kleinen gezeichneten Visuals ("chart", "tasks", "flow") neben drei kleinen. Ein Feature mit href macht seine ganze Karte zu einem Link. Auf dem Smartphone ist das eine große Tap-Fläche statt eines kleinen „Mehr erfahren“.

// app/(marketing)/home-content.tsx
import { BarChart3, ListChecks, Plug, Search, ShieldCheck, Workflow } from "lucide-react";
import type { FaqItem } from "@/components/blocks/faq-section";
import type { FeatureGridItem } from "@/components/blocks/feature-grid";
import type { LandingPlan } from "@/components/templates/landing-page-data";

// Bento-Reihenfolge: breit mit Diagramm, hoch mit Aufgaben, drei kleine, breit mit Flow
export const features: FeatureGridItem[] = [
  { icon: <BarChart3 />, title: "Sieh, wo die Woche geblieben ist", description: "Durchlaufzeit und Auslastung aktualisieren sich, wenn Aufgaben weiterwandern.", href: "/product/insights", visual: "chart" },
  { icon: <ListChecks />, title: "Ein Plan fürs ganze Team", description: "Verantwortliche und Fälligkeiten in einer Liste, vom Kickoff bis zum Launch.", href: "/product/planning", visual: "tasks" },
  { icon: <Search />, title: "Alles finden", description: "Spring per Tastatur zu jeder Aufgabe, jedem Doc und jeder Person im Team." },
  { icon: <ShieldCheck />, title: "SSO in bezahlten Plänen", description: "SAML-Login und Audit-Logs für dein Security-Review." },
  { icon: <Workflow />, title: "Automationen", description: "Karte verschieben, in Slack posten, Issue schließen." },
  { icon: <Plug />, title: "Passt zu deinen Tools", description: "Updates aus Slack und GitHub fließen in beide Richtungen.", href: "/integrations", visual: "flow" },
];

Jedes Layout klappt auf dem Smartphone auf eine Spalte zusammen, also schreib Titel, die auch ohne das Visual daneben Sinn ergeben. Wenn sich sechs Zellen schwer anfühlen, gib featuresProps={{ layout: "list" }} für kompakte Zeilen weiter, oder layout: "numbered" für einen redaktionellen Look.

Gehören die Preise auf die Landing Page?

Ein Teaser, ja. Wer bis hierher gescrollt hat, will wissen, ob es $0, $10 oder „sprich mit dem Vertrieb“ kostet. Das Pricing-Band der Vorlage legt ab 768px drei Pläne in eine Reihe, mit einem Umschalter Monthly / Yearly darüber (beim Laden auf Yearly, gesteuert über defaultPeriod) und darunter einem Link „Compare all plans“ auf /pricing. Jeder Plan-Button verlinkt auf sein eigenes href.

// app/(marketing)/home-content.tsx (Fortsetzung)
// yearly ist hier der Monatspreis bei jährlicher Abrechnung
export const plans: LandingPlan[] = [
  { id: "free", name: "Free", description: "Für kleine Teams, die Acme ausprobieren.", price: { monthly: 0, yearly: 0 }, priceNote: "Bis zu 5 Personen", features: ["Unbegrenzte Aufgaben", "3 Projekte"], cta: "Kostenlos starten", href: "/sign-up" },
  { id: "pro", name: "Pro", description: "Für Teams, die jede Woche ausliefern.", price: { monthly: 12, yearly: 10 }, priceNote: "pro Person / Monat", features: ["Unbegrenzte Projekte", "Automationen"], cta: "14 Tage testen", href: "/sign-up?plan=pro", featured: true, badge: "Am beliebtesten" },
  { id: "business", name: "Business", description: "Für Security-Reviews und SLAs.", price: { monthly: 24, yearly: 20 }, priceNote: "pro Person / Monat", features: ["SSO und Audit-Logs", "Priorisierter Support"], cta: "14 Tage testen", href: "/sign-up?plan=business" },
];

Der volle Vergleich gehört auf /pricing, gebaut mit der Pricing Table. Achte auf einen Unterschied, wenn du Pläne zwischen beiden kopierst: yearly im Teaser ist der monatliche Gegenwert ($10), während yearly in der Pricing Table der Jahresbetrag ist ($120), aus dem sie den Monatswert und das Ersparnis-Badge selbst berechnet. Das Ersparnis-Badge im Teaser ist ein Label, das du setzt (labels.yearlySavings), also pass es an, wenn sich die Preise ändern.

// app/(marketing)/pricing/page.tsx
import type { Metadata } from "next";
import { PricingTable, type PricingPlan } from "@/components/ui/pricing-table";

export const metadata: Metadata = { title: "Preise: Acme" };

const plans: PricingPlan[] = [
  { id: "free", name: "Free", price: 0, features: ["Bis zu 5 Personen", "3 Projekte"], cta: { label: "Kostenlos starten", href: "/sign-up" } },
  { id: "pro", name: "Pro", price: { monthly: 12, yearly: 120 }, priceSuffix: "/Person/Monat", featured: true, features: ["Unbegrenzte Projekte", "Automationen"], cta: { label: "14 Tage testen", href: "/sign-up?plan=pro" }, note: "14 Tage kostenlos, ohne Karte" },
  { id: "business", name: "Business", price: { monthly: 24, yearly: 240 }, priceSuffix: "/Person/Monat", features: ["SSO und Audit-Logs", "Priorisierter Support"], cta: { label: "14 Tage testen", href: "/sign-up?plan=business" } },
];

export default function PricingPage() {
  return <PricingTable plans={plans} defaultPeriod="yearly" currency="USD" />;
}

Diese Route braucht keinen Client-Wrapper. Die Datei pricing-table.tsx bringt ihr eigenes "use client" mit, und die Pläne sind einfache Strings und Zahlen, also kann eine Server Component sie direkt weitergeben. Sobald du einem cta eines Plans ein onClick gibst, stimmt das nicht mehr: Funktionen können die Grenze zwischen Server und Client nicht überqueren, also wandert diese Planliste in eine Client-Datei.

Wenn ihr Container schmaler als 768px ist, macht die Pricing Table aus den Plänen wischbare Karten, die beim hervorgehobenen Plan starten, und der Vergleich wird zu einer Plan-Auswahl über einer Spalte mit Zeilen. Unser Tutorial zur shadcn pricing page behandelt die Vergleichstabelle und die Jahresrechnung im Detail.

Was gehört ins FAQ der Landing Page?

Die Einwände, die die Abschnitte darüber nicht beantwortet haben: Ist der kostenlose Plan wirklich kostenlos, wie funktionieren Preise pro Person, wie importiere ich aus einem anderen Tool, wo liegen die Daten, wie kündige ich. Fünf kurze Fragen lesen sich am besten. Die Vorlage rendert sie mit der FAQ Section im Layout split, immer nur eine Antwort offen.

// app/(marketing)/home-content.tsx (Fortsetzung)
export const faq: FaqItem[] = [
  { question: "Ist der kostenlose Plan wirklich kostenlos?", answer: "Ja, für bis zu fünf Personen mit unbegrenzten Aufgaben. Wechsle in einen bezahlten Plan, wenn du mehr Projekte brauchst." },
  { question: "Können wir aus Jira oder Trello importieren?", answer: "Ja. Projekte, Aufgaben und Kommentare kommen mit einem einzigen Import rüber." },
  { question: "Können wir jederzeit kündigen?", answer: "Ja. Monatliche Pläne laufen bis zum Ende des Zeitraums, und du kannst vorher alles exportieren." },
];

Auf dem Desktop bleiben die Überschrift und eine Karte „Still have questions?“ sichtbar, während die Fragen scrollen. Diese Karte verspricht standardmäßig „Our support team replies within one business day“. Mach das also wahr oder ändere es mit faqProps={{ labels: { contactDescription: "..." } }}. Unter 1024px stapeln sich beide über der Liste, also beschränk die Beschreibung für das Smartphone auf einen Satz, oder gib faqProps={{ contact: false }} weiter, damit die erste Frage nach oben rückt.

jsonLd: true ergänzt strukturierte Daten vom Typ FAQPage mit dem reinen Text jeder Antwort. Bau das nicht wegen Google-Snippets ein. Google hat FAQ-Rich-Results im August 2023 auf bekannte Websites von Behörden und aus dem Gesundheitsbereich (opens in a new tab) beschränkt, und laut dem Changelog von Search Central (opens in a new tab) erscheint die Funktion seit dem 7. Mai 2026 nicht mehr in der Suche. Das Markup ist ein kleiner Script-Tag, aber die eigentliche Arbeit machen die sichtbaren Antworten im Server-HTML.

Wie prüfe ich die Landing Page vor dem Launch auf dem Smartphone?

Wenn du nur ein Desktop-Fenster verkleinerst, verpasst du Touch, die Bildschirmtastatur und die Leisten des Browsers. Öffne die Seite auf einem echten Smartphone oder in einem 390px-Geräterahmen und geh diese Liste durch:

1. Der Hero-Titel passt in drei oder vier Zeilen, und der Hauptbutton ist ohne Scrollen sichtbar.
2. Das Menü öffnet sich als Vollbild-Sheet, mit Sign in und Get started als Buttons in voller Breite, und eine Wischgeste zurück zum Rand schließt es.
3. Kein Abschnitt scrollt seitlich, auch nicht die Feature-Visuals und das Pricing-Band.
4. Mit reduzierter Bewegung stehen die Marquees still, und nichts gleitet animiert herein.
5. Light und Dark Mode haben beide gut lesbare graue Bänder; die Vorlage wechselt sie selbst ab (alternate).
6. Der Newsletter im Footer zeigt seinen Fehler, wenn dein onSubscribe fehlschlägt, und im Footer steht nicht mehr Acme: Setz logo, columns, socials und labels über footerProps, und gib status: false weiter, bis hinter „All systems operational“ eine echte Statusseite steht.

Unser Guide zu Mobile-first React Components erklärt die Regeln hinter dieser Liste: 44px Touch-Targets, Safe Areas und Sheets statt Popovers.

Was ist der nächste Schritt?

Installier die Vorlage mit npx wingo-ui@latest add landing-page, ersetz die Beispielinhalte durch deine eigenen und schalte jeden Abschnitt ab, den du nicht ehrlich füllen kannst. Landing Page, Hero Section, Feature Grid und Pricing Table gehören zu Wingo UI Pro; FAQ Section, CTA Section, Logo Cloud, Marketing Header und Marketing Footer sind kostenlos. Für den Rest des Produkts baut das Tutorial zum Next.js Admin Dashboard die Screens hinter dem Sign-up-Button, und die Kategorie Build it hat die anderen Seiten, die ein SaaS braucht.

Häufige Fragen

Welche Abschnitte braucht eine SaaS Landing Page?

Einen Header, einen Hero mit einer Hauptaktion, Social Proof, Features, einen Pricing-Teaser, ein FAQ, einen abschließenden Call to Action und einen Footer. Eine Produkttour oder ein Zahlenband ergänzt du, wenn du etwas Echtes zu zeigen hast, und jeden Abschnitt, den du mit Platzhaltern füllen müsstest, streichst du.

Gibt es eine kostenlose Next.js SaaS Landing Page Vorlage?

Ja. Stand Oktober 2026 sind Saas UI (Open Source) und Finwise kostenlose Vorlagen mit Next.js und Tailwind, und bezahlte Kits wie das SaaS-Template von Magic UI Pro bringen mehr Abschnitte und einen MDX-Blog mit. Bei Wingo UI gehört die komplette Vorlage Landing Page zu Pro, während FAQ Section, CTA Section, Logo Cloud, Marketing Header und Marketing Footer kostenlos sind.

Hat shadcn/ui Blöcke für Landing Pages?

Stand 16. Oktober 2026 nicht. Die offizielle Blocks-Seite von shadcn/ui zeigt die Blöcke Featured, Sidebar, Login und Signup. Hero-, Feature- und Pricing-Abschnitte kommen also aus Galerien von Drittanbietern, oder du setzt sie selbst aus Card, Button und Accordion zusammen.

Kann eine Next.js Landing Page eine Server Component sein, wenn die Abschnitte Client-Komponenten sind?

Ja. Lass app/page.tsx eine Server Component, die metadata exportiert und eine einzige Client-Komponente mit den Abschnitten rendert. Der Server rendert trotzdem das komplette HTML, also bekommen Crawler und KI-Leser jede Überschrift und jede Antwort, ohne JavaScript auszuführen.

Gehören die vollen Preise auf die Landing Page?

Setz einen Teaser mit drei Plänen und einem Umschalter Monthly / Yearly auf die Startseite und verlinke ihn auf eine Route /pricing mit der kompletten Vergleichstabelle. Der Teaser beantwortet, was es kostet; der Vergleich ist für die Besucher, die schon zwischen Plänen abwägen.