Eine Landingpage hat eine Aufgabe: konvertieren. Kommt der Traffic aus bezahlten Kampagnen, ist die Suchmaschine irrelevant, und ein No-Code-Builder ist eine völlig vernünftige Entscheidung: Sie veröffentlichen an einem Nachmittag, iterieren ohne Abhängigkeiten und messen.
Das Problem entsteht, wenn jemand beschließt, dieselben Landingpages sollten organischen Traffic bringen. Dann beginnt die Frustration: Die Texte werden optimiert, die Keywords eingebaut — und die Seite taucht weiterhin nicht auf.
Es ist kein Inhaltsproblem. Es ist ein Auslieferungsproblem.
Was Google tun muss, um Ihre Seite zu lesen
Wenn der Crawler auf eine URL trifft, gibt es zwei sehr unterschiedliche Szenarien.
Serverseitig gerenderte Seite. Die HTTP-Antwort enthält bereits das HTML mit dem Inhalt. Google liest es im ersten Durchlauf und gibt es zur Indexierung weiter. Fertig.
Client-seitig gerenderte Seite. Die Antwort bringt ein fast leeres HTML-Gerüst und ein JavaScript-Bundle. Um den Inhalt zu sehen, muss Google dieses JavaScript ausführen — das geschieht in einer zweiten Rendering-Phase, die eingereiht wird und dauern kann. Google macht das, wir sind nicht mehr im Jahr 2015, aber es ist ein zusätzlicher Schritt mit eigener Warteschlange und eigenem Ressourcenbudget.
Für eine Website mit etablierter Autorität ist dieser Unterschied verkraftbar. Für eine neue Landingpage im Wettbewerb um eine kommerzielle Suchanfrage ist es ein Nachteil, den Sie der Konkurrenz nicht schenken müssen.
Die vier Stellen, an denen es verloren geht
Das JavaScript, das Sie nicht entfernen können
Ein Builder muss generisch sein: Er muss jeden Block unterstützen, den irgendein Kunde hineinziehen könnte. Das bedeutet, die Editor-Laufzeit, das Animationssystem, den Formular-Handler und die Hilfsfunktionen aller Blocktypen zu laden — ob Sie zwei nutzen oder zwanzig.
Das Ergebnis sind Hunderte Kilobyte JavaScript, die Ihre konkrete Landingpage nicht braucht und die Sie nicht entfernen können, weil Ihnen der Build nicht gehört.
Core Web Vitals
Dieses Gewicht schlägt direkt auf die Kennzahlen durch, die Google als Signal nutzt:
| Kennzahl | Was sie im Builder verschlechtert |
|---|---|
| LCP | Das Hauptelement wartet darauf, dass JS es zeichnet |
| INP | Der Haupt-Thread ist mit der Laufzeit beschäftigt |
| CLS | Blöcke, die sich beim Hydrieren verschieben |
Die Core Web Vitals sind nicht der stärkste Rankingfaktor — Inhalt und Links wiegen mehr —, aber sie sind ein echtes Stichkriterium. Und auf einer Landingpage wirken sie viel unmittelbarer: Jede Sekunde Ladezeit frisst Conversion, ob Google etwas damit zu tun hat oder nicht.
Die URL, die Ihnen nicht gehört
Hier kommen die meisten Builder an ihre Grenzen:
- Subdomains des Anbieters statt Ihrer eigenen Domain, sodass gewonnene Autorität sich nicht auf Ihrer Website ansammelt
- Vorgegebene Pfade wie
/p/12345statt/nextjs-agentur-berlin - Uneinheitliche abschließende Slashes, die Duplikate erzeugen
- Canonicals, die Sie nicht anpassen können, wenn Sie Varianten derselben Landingpage für verschiedene Kampagnen haben
Der letzte Punkt richtet den leisesten Schaden an: Drei Varianten einer Landingpage ohne sauber gesetztes Canonical konkurrieren miteinander, und keine gewinnt.
Strukturierte Daten und hreflang
Wer in mehreren Ländern verkauft, braucht korrektes und wechselseitiges hreflang. Wer mit Rich Results erscheinen will, braucht fallspezifisches JSON-LD. Die meisten Builder bieten entweder ein generisches Feld oder gar nichts, und das manuelle Einschleusen über Custom-Code bricht typischerweise beim nächsten Plattform-Update.
Was sie wirklich lösen
Es wäre unredlich, alles schwarz zu malen. Ein Builder löst drei Dinge tatsächlich:
- Geschwindigkeit beim Launch. Von der Idee zur veröffentlichten Seite in Stunden, ohne Entwicklungswarteschlange.
- Autonomie im Marketing. Wer die Hypothese hat, kann sie testen, ohne ein Ticket zu öffnen.
- Günstige Iteration. Eine Überschrift zu ändern kostet kein Deployment.
Dieser Wert ist real, und nicht jede Alternative liefert ihn. Die richtige Frage lautet nicht „Builder ja oder nein”, sondern welche Aufgabe diese Landingpage erfüllen soll.
Das Kriterium als Tabelle
| Wenn die Landingpage… | Dann |
|---|---|
| Traffic aus bezahlten Kampagnen erhält | Ein Builder passt. SEO ist nicht ihre Aufgabe |
| Ein Test ist, der in drei Wochen sterben kann | Builder. Investieren Sie nichts in Wegwerfbares |
| Für eine kommerzielle Suchanfrage ranken soll | Serverseitiges Rendering, eigene URL, technische Kontrolle |
| Mehrsprachig und für mehrere Länder ist | Serverseitiges Rendering: Sie brauchen echtes hreflang |
| Die Haupteingangstür Ihres Geschäfts ist | Serverseitiges Rendering, ohne Diskussion |
Die meisten Unternehmen brauchen beides gleichzeitig, und genau da schadet das falsche Dilemma: Es zwingt zur Wahl zwischen schnellem Veröffentlichen und Ranken, obwohl das eigentliche Problem darin besteht, dass beide Fähigkeiten in unvereinbaren Werkzeugen stecken.
Unser Ansatz
Genau diese Lücke schließt unser Landing Builder: ein visueller Block-Editor, damit Marketing ohne Entwicklung veröffentlicht, aber mit echter SEO darunter — serverseitiges Rendering, saubere Slugs auf Ihrer eigenen Domain, Meta-Tags und strukturierte Daten pro Seite — dazu Formulare mit Tracking und Kampagnen-Analytics.
Wenn Sie zugleich den Stack für die Website wählen, haben wir den Vergleich zwischen Next.js und Astro für 2026.