Top 10 CMS-Plattformen für SaaS-Websites 2026: Der ultimative Leitfaden

Die Wahl des richtigen CMS für Ihr SaaS-Unternehmen im Jahr 2026 ist eine strategische Entscheidung, die über Jahre SEO, Entwicklungstempo, Skalierbarkeit und Gesamtbetriebskosten beeinflusst. Ein SaaS veröffentlicht nicht nur eine Marketing-Website: Dazu kommen Dokumentation, Release Notes, ein Help Center und manchmal mehrere Websites pro Produkt oder Markt. Das CMS muss all diese Oberflächen bedienen.

Mehr über professionelle WordPress-Entwicklung erfahren Sie bei WPPoland.

Dieser Leitfaden vergleicht 10 CMS-Plattformen für SaaS im Jahr 2026. Jede genannte Funktion stammt aus der Dokumentation des jeweiligen Anbieters, die im Text verlinkt ist. Preise nennen wir nicht: Tarife ändern sich häufig, deshalb beschreiben wir nur das Abrechnungsmodell. Die Reihenfolge der Liste ist kein gemessenes Ranking, sondern die Reihenfolge, in der wir die Optionen einem SaaS-Kunden üblicherweise vorstellen.

#1. WordPress für SaaS-Marketingwebsites

WordPress bleibt 2026 die vollständigste CMS-Option für SaaS-Marketingwebsites, weil es als klassisches CMS und als Headless-Backend funktioniert, ohne dass Sie die Plattform wechseln müssen.

Über die WordPress REST API können andere Anwendungen Daten der Website als JSON-Objekte lesen und schreiben, und sie ist die Grundlage des Block-Editors. Für GraphQL gibt es WPGraphQL, ein kostenloses Open-Source-Plugin, das ein erweiterbares GraphQL-Schema hinzufügt und gerade zum kanonischen Plugin auf WordPress.org wird.

Für ein SaaS zählt vor allem register_post_type(). Damit legen Sie eigene Inhaltstypen an (Dokumentation, Changelog, Integrationen), und die Funktionsreferenz erklärt, dass show_in_rest den Typ in der REST API verfügbar macht und has_archive die Archivseite sowie standardmäßig auch den Feed des Typs erzeugt.

Vorteile für SaaS:

• Volle Kontrolle über SEO, Performance und Anpassungen
• Funktioniert als klassisches oder Headless CMS (REST API + WPGraphQL)
• Ausgereiftes Ökosystem mit Integrationen für praktisch jedes Marketing-Tool
• Keine Lizenzkosten (Open Source)
• Große weltweite Community für Support und Personalsuche

Nachteile:

• Erfordert Wartung und Sicherheitsupdates
• Die Einarbeitung ist anfangs aufwendiger als bei SaaS-Baukästen
• Braucht Managed Hosting für optimale Performance

Abrechnungsmodell: freie Software ohne Lizenz; Sie zahlen für Hosting, Wartung und Entwicklung.

Geeignet für: SaaS jeder Größe, bei dem SEO, Flexibilität und Datenhoheit Vorrang haben. Besonders stark bei Websites mit viel Content (Blog, Dokumentation, Wissensdatenbank).

#2. Contentful für Multichannel-Enterprise-SaaS

Contentful ist ein reines Headless CMS, das die Inhaltsverwaltung vollständig von der Darstellung trennt. Die offizielle JavaScript-Bibliothek beschreibt es als Content-Infrastruktur für Websites, Apps und Geräte, mit einem zentralen Hub für strukturierte Inhalte und APIs für Verwaltung und Auslieferung.

Laut der Dokumentation für Agenten, die Contentful in seinem offiziellen Repository veröffentlicht, bietet die Plattform mehrere getrennte APIs: Content Delivery API (veröffentlichte Inhalte), Content Preview API (Entwürfe und Veröffentlichtes), Content Management API (Schreibzugriff) und GraphQL Content API. Inhalte liegen in Spaces, jeder Space hat Environments, und über Environment-Aliase legen Sie fest, welches Environment die Produktion ausliefert.

Vorteile:

• Getrennte REST- und GraphQL-APIs für Auslieferung, Vorschau und Verwaltung
• Strukturiertes Inhaltsmodell mit Typen, Referenzen und Locales
• Environments, um Modelländerungen vor der Produktion zu testen
• Verwaltete Plattform: kein eigener Server zu warten

Nachteile:

• Kein integriertes Frontend (separate Entwicklung nötig)
• Spürbare Einarbeitung für nicht technische Redakteure
• Die Inhalte liegen auf der Plattform des Anbieters und werden per API abgerufen

Abrechnungsmodell: SaaS-Abonnement nach Tarif.

Geeignet für: Enterprise-SaaS mit eigenen Entwicklungsteams und Multichannel-Anforderungen.

#3. Sanity als CMS für strukturierte Inhalte

Sanity speichert Inhalte als JSON-Dokumente in Datasets. Die Dataset-Dokumentation vergleicht sie mit einer Datenbank, in der Dokumenttypen die Rolle von Tabellen übernehmen, und nennt als Einsatzzweck die Trennung von Test-, Staging- und Produktionsumgebung.

Die Abfragesprache ist GROQ: Damit beschreibt die Anwendung genau, welche Felder sie braucht, und verknüpft Dokumente aus mehreren Mengen. Es gibt auch eine GraphQL-API, die mit sanity graphql deploy bereitgestellt wird. Sanity selbst empfiehlt GROQ: Die GraphQL-API unterstützt weder Mutationen noch Filter auf Array-Felder.

Rich Text wird in Portable Text gespeichert, einer offenen Spezifikation für blockbasierte Inhalte im JSON-Format. Für die Vorschau zeigt das Tool Presentation das Frontend direkt im Studio an; ein Klick auf einen Text führt zum Feld, in dem er gepflegt wird.

Vorteile:

• Inhaltsschema im Code definiert und zusammen mit dem übrigen Projekt versionierbar
• GROQ liefert genau die angefragten Felder
• Öffentliche oder private Datasets pro Projekt
• Portable Text als offene Spezifikation

Nachteile:

• Für die Einrichtung sind Entwicklerkenntnisse nötig
• GROQ will gelernt sein (weder Standard-REST noch GraphQL)
• Die GraphQL-API hat gegenüber GROQ Einschränkungen

Abrechnungsmodell: SaaS-Abonnement nach Tarif, zusätzliche Datasets als Add-on.

Geeignet für: Tech-Startups mit eigenen Entwicklern, die maximale Kontrolle über das Datenmodell wollen.

#4. Webflow für SaaS-Startups ohne Code

Webflow kombiniert einen visuellen Builder mit CMS und integriertem Hosting. Es ist die übliche Wahl von Marketingteams, die iterieren wollen, ohne auf Entwickler angewiesen zu sein.

Vorteile:

• Visueller Builder mit voller CSS-Kontrolle
• Integriertes CMS mit strukturierten Collections
• Hosting inklusive
• Animationen und Interaktionen ohne Code

Nachteile:

• Grenzen bei komplexer Geschäftslogik: Es wird kein serverseitiger Code ausgeführt
• Der Code-Export enthält die CMS-Inhalte nicht

Abrechnungsmodell: Site-Tarife für das Hosting und Workspace-Tarife für das Team.

Geeignet für: Startups in der Frühphase mit starken Designteams, die Landingpages und Marketingseiten schnell iterieren müssen.

#5. Framer für Landingpages von SaaS-Startups

Framer hat sich vom Prototyping-Tool zum vollständigen Website-Builder entwickelt. Sein CMS bietet Collections, Felder für Text, Bilder, Rich Text, Datum und Referenzen, integrierte Lokalisierung, CSV-Import, Synchronisierung mit Google Sheets und Airtable sowie die Möglichkeit, Inhalte vorzubereiten und vor der Veröffentlichung zu prüfen.

Vorteile:

• Sehr hohes Tempo bei Design und Veröffentlichung
• Lokalisierung direkt im CMS
• Vorbereitete Inhalte mit Vorschau vor der Veröffentlichung

Nachteile:

• CMS für Collections gedacht, nicht für umfangreiche Dokumentation
• Kleines Integrations-Ökosystem
• Kein eigener serverseitiger Code

Abrechnungsmodell: Tarife pro Website, zusätzliche Sprachen und Redakteure als Add-on.

Geeignet für: Startups vor dem Product-Market-Fit, die schnell Landingpages brauchen.

Was sich aus Framer und Webflow exportieren lässt, wie viele Weiterleitungen sie erlauben und wo eigener Code eingebunden werden kann, beschreiben wir mit Quellen in unserem Vergleich von Website-Buildern für SaaS. Hier konzentrieren wir uns auf CMS, die Dokumentation, Changelogs und Headless-Frontends versorgen.

#6. Strapi als Open-Source-Headless-CMS

Strapi ist ein Headless CMS, das Sie auf Ihrer eigenen Infrastruktur installieren. Für Version 5 hält die Dokumentation des GraphQL-Plugins fest, dass Strapi standardmäßig REST-Endpunkte für jeden Inhaltstyp anlegt und das Plugin einen GraphQL-Endpunkt zum Lesen und Ändern von Inhalten ergänzt.

Die Funktion Draft & Publish wird pro Inhaltstyp aktiviert und trennt Entwürfe von veröffentlichten Versionen; die APIs akzeptieren den Parameter status, um das eine oder das andere abzurufen. Webhooks melden Ereignisse wie entry.publish, entry.unpublish oder media.create.

Die Lizenz ist gemischt: Die Community Edition steht unter MIT, der Code in den Verzeichnissen ee/ (Enterprise Edition) hat eine eigene Lizenz.

Vorteile:

• Community Edition unter MIT-Lizenz
• Selbst gehostet (volle Kontrolle über die Daten)
• REST standardmäßig, GraphQL per Plugin
• Anpassbares Admin-Panel

Nachteile:

• Erfordert DevOps für Deployment und Wartung
• Kleineres Ökosystem als WordPress
• Einige Funktionen (Review-Workflows, Releases) hängen an kostenpflichtigen Tarifen

Abrechnungsmodell: selbst gehostet ohne Lizenzkosten in der Community Edition; Strapi Cloud und die Enterprise Edition sind kostenpflichtig.

Geeignet für: Tech-Startups, die ein Headless CMS ohne Vendor-Lock-in und mit voller Kontrolle wollen.

#7. Ghost für Newsletter und SaaS-Content-Marketing

Ghost ist ein Publishing-CMS mit Mitgliedschaften und Newslettern, geschrieben in Node.js und veröffentlicht unter MIT-Lizenz. Es ist die passende Option für SaaS, bei denen redaktioneller Content der Wachstumsmotor ist.

Laut der Newsletter-Dokumentation kann jeder Beitrag per E-Mail an kostenlose oder zahlende Mitglieder oder an ein Segment davon gehen, und eine Website kann mehrere Newsletter anbieten, zwischen denen die Leser wählen. Bei Ghost(Pro) ist der Versand enthalten; eine eigene Installation muss Mailgun einrichten, den einzigen unterstützten Anbieter für Massenversand. Die Content API ist schreibgeschützt, liefert JSON und stellt veröffentlichte Inhalte für jede beliebige Website oder App bereit.

Vorteile:

• Integrierte Newsletter und Mitgliedschaften
• Fokussierter Editor
• Schreibgeschützte Content API für ein eigenes Frontend

Nachteile:

• Auf Publishing und Mitgliedschaften beschränkt
• Kleines Ökosystem an Themes und Erweiterungen
• Nicht geeignet als allgemeines CMS für komplexe Marketingwebsites

Abrechnungsmodell: selbst gehostet ohne Lizenzkosten oder als verwalteter Dienst Ghost(Pro) im Abonnement.

Geeignet für: SaaS, die Content-Marketing und Newsletter als wichtigsten Akquisitionskanal nutzen.

#8. Astro mit Markdown für SaaS-Dokumentation

Astro ist selbst kein CMS, aber seine Content Collections machen aus einem Verzeichnis mit Markdown- oder MDX-Dateien typisierte Daten. Jede Collection kann ein Zod-Schema haben; erfüllt eine Datei es nicht, zeigt Astro einen Fehler an. Die Loader glob() und file() lesen lokale Dateien, und ein eigener Loader kann Daten aus einem CMS oder einer Datenbank holen, beim Build oder bei Bedarf zur Laufzeit.

Für Dokumentation gibt es Starlight, ein vollständiges Dokumentations-Theme auf Basis von Astro, mit eigenen Anleitungen zur Website-Suche und Internationalisierung.

Vorteile:

• Standardmäßig kein JavaScript im Browser
• Content Collections mit Schema-Validierung
• Mit jedem Headless CMS als Backend kombinierbar
• Sehr gut für technische Dokumentation

Nachteile:

• Erfordert Entwicklerkenntnisse
• Kein visuelles Admin-Panel (Bearbeitung in Dateien)
• Nicht geeignet für nicht technische Redakteure

Abrechnungsmodell: Open-Source-Framework; Sie zahlen nur das Hosting.

Geeignet für: Tech-SaaS mit umfangreicher Dokumentation und technischen Blogs, die von Entwicklern gepflegt werden.

#9. Directus als Headless CMS auf SQL-Basis

Directus beschreibt sich als Backend, das sich mit Ihrer Datenbank, Ihrem Dateispeicher und externen Diensten verbindet und darauf eine REST- und GraphQL-API, ein SDK, Echtzeit-Funktionen, Authentifizierung und Automatisierungen erzeugt (Directus-Überblick). Die Datenbankkonfiguration unterstützt PostgreSQL, MySQL, Oracle, Microsoft SQL Server, SQLite und CockroachDB.

Die Lizenz ist keine Open-Source-Lizenz im engeren Sinn: Directus nutzt die Monospace Sustainable Core License (MSCL), mit einer kostenlosen Stufe und kostenpflichtigen Lizenzen für höhere Limits und zusätzliche Funktionen.

Vorteile:

• Verbindet sich direkt mit bestehenden Datenbanken
• Automatisch generiertes Admin-Panel
• Automatische REST- und GraphQL-API
• Selbst hostbar

Nachteile:

• Erfordert Datenbankkenntnisse
• Weniger intuitiv für reine Content-Redakteure
• Bei der MSCL sollten Sie die Bedingungen vor einem größeren kommerziellen Einsatz prüfen

Abrechnungsmodell: kostenlose Stufe und kostenpflichtige Lizenzen nach MSCL.

Geeignet für: SaaS mit vorhandenen Daten in SQL-Datenbanken, die schnell ein Admin-Panel brauchen.

#10. Payload CMS für TypeScript-Teams

Payload versteht sich als Fullstack-Framework für Next.js: Es wird in eine neue oder bestehende Next.js-Anwendung eingebaut, der gesamte Code ist TypeScript, und es läuft mit MongoDB und Postgres (Was ist Payload). Das Repository steht unter MIT-Lizenz.

Aus der Konfiguration der Collections erzeugt Payload eine REST API unter /api/{collection}, und dieselbe Logik steht als Local API innerhalb des Servers zur Verfügung.

Vorteile:

• Durchgehend natives TypeScript
• Liegt im selben Repository wie die Next.js-Anwendung
• Admin-Panel über React-Komponenten anpassbar
• Offizielles Multi-Tenant-Plugin

Nachteile:

• Erfordert TypeScript-Entwickler
• An Next.js als Anwendungsschicht gebunden

Abrechnungsmodell: Open Source unter MIT; Sie zahlen das Hosting.

Geeignet für: Tech-Startups mit TypeScript-Teams, die ein modernes, vollständig anpassbares CMS wollen.

#CMS-Vergleich für SaaS nach APIs und Lizenzen

Für echtes Omnichannel-Publishing liegen Contentful und Sanity vorn, weil sie API-first konzipiert wurden. WordPress erreicht dasselbe Ergebnis im Headless-Modus, erfordert aber mehr Architekturarbeit.

#Welches CMS ist das beste für SaaS-Websites

Die Antwort hängt von Ihrer Phase, Ihrem Team und Ihrem Wachstumspfad ab:

• Pre-Seed bis Series A (Tempo zählt am meisten): Framer oder Webflow. Starten Sie schnell und iterieren Sie wöchentlich, aber führen Sie vom ersten Tag an eine Liste der veröffentlichten URLs, damit bei einer Migration keine verloren gehen.
• Series A bis B (SEO und wachsender Content): WordPress. Volle Datenhoheit, tiefe SEO-Kontrolle und vollständiger Export, während das Content-Volumen wächst.
• Series C+ Enterprise (strukturierte Inhalte, Omnichannel): Contentful oder Sanity. API-first-Architektur, um Inhalte auf Web, Mobile, Dokumentation und Partnerportale auszuspielen.
• Entwicklerorientiertes SaaS (DevTools, Open Source): Astro mit Starlight für die Dokumentation und Ghost für den Newsletter. Inhalte in Git und Entwickler-Workflows.

Kein CMS ist für sich genommen “das beste”. Das beste CMS ist das, das zur technischen Kapazität Ihres Teams, Ihrem Content-Volumen und Ihrem Wachstumsplan für die nächsten 24 Monate passt.

#Welches CMS für die Dokumentation eines SaaS-Produkts

Die Dokumentation eines SaaS hat andere Anforderungen als der Blog. Sie ändert sich mit jeder Version, wird vor allem von Ingenieuren geschrieben und von Nutzern gelesen, die eine konkrete Antwort suchen. Drei Muster sind üblich:

• Docs as Code. Die Markdown-Dateien liegen im Produkt-Repository und werden im selben Pull Request geprüft wie die Codeänderung. Starlight auf Astro oder Docusaurus folgen diesem Modell.
• Dokumentation in einem Headless CMS. Technische Redakteure arbeiten in Contentful, Sanity oder Strapi, ein statisches Frontend veröffentlicht die Inhalte. Das passt, wenn die Schreibenden nicht in Git arbeiten.
• Dokumentation in WordPress. Ein eigener Inhaltstyp, registriert mit show_in_rest, und eine Taxonomie pro Produktbereich. Das passt, wenn die Dokumentation dasselbe Redaktionsteam hat wie der Blog.

Die Versionierung verdient eine bewusste Entscheidung. Docusaurus löst sie mit dem Befehl docs:version, der den Ordner docs/ nach versioned_docs/ kopiert und die Version registriert. Die eigene Versionierungsanleitung rät davon ab, standardmäßig zu versionieren, weil das den Build verlängert: Sie empfiehlt Versionen nur, wenn sich die Dokumentation zwischen Releases wirklich unterscheidet, keine Versionen für Patches anzulegen und insgesamt weniger als etwa zehn zu pflegen.

Für die Suche erspart ein Dokumentations-Theme mit integrierter Suche (wie Starlight) in den ersten Monaten einen separaten Dienst. Wird die Dokumentation übersetzt, sollte das CMS oder Framework Sprachen pro Seite verwalten, mit einer eigenen URL für jede Sprache.

#Wie man ein SaaS-Produkt-Changelog aus dem CMS veröffentlicht

Ein Changelog ist die Seite, die Bestandskunden am häufigsten besuchen, und ein guter Kandidat für strukturierte Inhalte. Die Konvention Keep a Changelog definiert es als chronologische, kuratierte Liste relevanter Änderungen, geschrieben für Menschen und nicht für Maschinen. Die Regeln sind konkret: ein Eintrag pro Version, die neueste Version zuerst, sichtbares Datum, verlinkbare Abschnitte und Änderungen gruppiert in sechs Typen (Added, Changed, Deprecated, Removed, Fixed, Security).

Diese Regeln lassen sich gut auf ein CMS-Modell übertragen:

• Ein Inhaltstyp “Release” mit Versionsnummer, Datum und einem Feld pro Änderungstyp. In WordPress erhält ein eigener Typ mit has_archive ohne zusätzlichen Code eine Archivseite und einen Feed.
• Benachrichtigung beim Veröffentlichen. In Strapi kann das Ereignis entry.publish den Neuaufbau der statischen Website oder eine Slack-Nachricht auslösen. In Sanity leistet ein per GROQ gefilterter Webhook dasselbe, und die Dokumentation nennt als Beispiel einen Webhook für den Neuaufbau der Website.
• Versand per E-Mail. Mit Ghost lässt sich derselbe Eintrag als Newsletter nur an das interessierte Mitgliedersegment schicken.

Der Typ Security verdient besondere Aufmerksamkeit: Veröffentlicht das SaaS Sicherheitshinweise, sollte das Changelog mit einer stabilen URL darauf verlinken, die sich bei einer CMS-Migration nicht ändert.

#Multi-Tenant-CMS für mehrere Marketingwebsites

Viele SaaS-Unternehmen betreiben mehrere Websites: eine pro Produkt, pro Markt oder pro übernommener Marke. Jedes CMS löst das mit einem anderen Konzept:

• WordPress Multisite. Eine Installation mit mehreren Websites. Laut der Multisite-Dokumentation können die Websites Theme und Plugins teilen, während jede ihre eigenen Inhaltstabellen hat; nur die Benutzertabelle ist gemeinsam. Das Netzwerk kann Unterverzeichnisse oder Domains und Subdomains nutzen.
• Contentful Spaces und Environments. Ein Space pro Website oder Region, mit Environments zum Testen von Modelländerungen und Aliasen, die festlegen, welches Environment die Produktion ausliefert.
• Sanity Datasets. Mehrere Datasets pro Projekt, öffentlich oder privat; die Dokumentation nennt ihren Einsatz für Lokalisierung und Segmentierung von Inhalten.
• Payload Multi-Tenant. Das offizielle Plugin ergänzt die gewählten Collections um ein Feld tenant, fügt im Panel eine Tenant-Auswahl hinzu und lehnt Schreibzugriffe auf Tenants ab, zu denen der Benutzer nicht gehört.

Die praktische Frage lautet: Was wird geteilt? Teilen die Websites Design und Benutzer, aber keine Inhalte, passt Multisite. Teilen sie das Inhaltsmodell, aber nicht die Redakteure, sind getrennte Spaces oder Datasets sauberer. Ist die Isolation zwischen Kunden eine Sicherheitsanforderung, macht die Zugriffskontrolle pro Tenant in Payload sie im Code explizit.

#Wie funktioniert die Entwurfsvorschau in einem Headless CMS

Auf einer Headless-Website sieht der Redakteur die Seite beim Speichern nicht mehr. Die Vorschau muss gebaut werden, und jede Plattform liefert dafür einen anderen Baustein:

• Contentful trennt die Content Preview API, die Entwürfe und veröffentlichte Inhalte zurückgibt, von der Content Delivery API, die nur Veröffentlichtes liefert. Das Frontend nutzt für jede ein eigenes Token.
• Sanity bietet das Tool Presentation, das das Frontend im Studio anzeigt, mit Bearbeitung per Klick dank Content Source Maps.
• Strapi liefert Entwürfe oder veröffentlichte Inhalte je nach API-Parameter status, sobald Draft & Publish für den Inhaltstyp aktiviert ist.
• Astro kann jede dieser APIs mit einem eigenen Loader lesen und die Vorschauseiten bei Bedarf ausliefern, statt sie vorab zu bauen.

Veröffentlicht das Marketingteam täglich, ist die Vorschau kein Detail: Sie entscheidet darüber, ob das Headless CMS genutzt wird oder ob die Redakteure Änderungen wieder bei den Entwicklern anfragen.

#Sicherheit und Governance bei der CMS-Wahl für SaaS

Die Sicherheitsfragen für ein SaaS sind dieselben wie für jede Unternehmenswebsite: Single Sign-on (SSO/SAML), rollenbasierte Berechtigungen, Audit-Log, Versionshistorie und Verschlüsselung. Wir behandeln sie ausführlich in unserem CMS-Vergleich für große Unternehmenswebsites. Für ein SaaS kommen zwei Punkte hinzu: Die Tokens der Vorschau-APIs geben Zugriff auf Entwürfe und gehören ausschließlich auf den Server, und private Datasets oder Inhaltstypen sollten auf eine nicht authentifizierte Anfrage ein leeres Ergebnis liefern, wie Sanity es für seine privaten Datasets dokumentiert.

#Wann ist WordPress das beste CMS für ein SaaS

Für die meisten SaaS-Unternehmen bleibt WordPress 2026 eine sehr solide Wahl, dank seiner Vielseitigkeit, seines ausgereiften Ökosystems, der SEO-Kontrolle und des fehlenden Vendor-Lock-ins. Kombiniert mit einem modernen Frontend wie Astro gewinnt es an Geschwindigkeit, ohne dass Sie die Hoheit über Ihre Inhalte verlieren.

Wenn Sie CMS-Optionen für Ihr SaaS prüfen, hilft Ihnen das Team von WPPoland, die richtige Entscheidung zu treffen und die gewählte Lösung umzusetzen. Wir bieten WordPress-Entwicklung, Headless-CMS-Entwicklung, Migration zwischen Frameworks und Performance-Optimierung.

#Weiterführende Ressourcen

• Professionelle WordPress-Entwicklung - Individuelle Umsetzung für SaaS
• Migration zu Astro oder Next.js - Moderne Frontends
• Geschwindigkeitsoptimierung - Core Web Vitals
• SEO, GEO und AEO - Sichtbarkeit in Suchmaschinen und KI-Suche