Plattform-SEO

TL;DR — Die Plattform, auf der du deine Website erstellst, prägt deine SEO-Möglichkeiten, bevor du ein einziges Wort schreibst. Manche Plattformen erledigen viel automatisch; andere geben dir volle Kontrolle, überlassen dir aber mehr Konfiguration. Der Unterschied ist besonders beim technischen SEO wichtig — bei Titeln, Canonicals, Sitemaps, strukturierten Daten, robots.txt und Rendering.

Warum die Plattformwahl das SEO beeinflusst

Die meisten SEO-Ratschläge behandeln eine Website wie eine leere Leinwand. In Wirklichkeit hat dein CMS oder Website-Baukasten bereits Dutzende SEO-Entscheidungen getroffen — die URL-Struktur, die Sitemap-Erstellung, ob du robots.txt bearbeiten kannst, den Umgang mit Metadaten und welche strukturierten Daten automatisch eingefügt werden.

Die gute Nachricht: Die meisten großen Plattformen decken die Grundlagen gut ab. Die Unterschiede zeigen sich, wenn du etwas Nichtstandardmäßiges tun, ein bestimmtes technisches Problem beheben oder auf Zehntausende Seiten skalieren musst.

Die fünf Kategorien

Traditionelle CMS-Plattformen (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco, Sitecore) werden auf deinem eigenen Server (oder bei einem Managed Host) installiert und geben dir umfassende Kontrolle über jede Einstellung des technischen SEO. WordPress hat insbesondere ein umfangreiches Plugin-Ökosystem — Yoast, Rank Math und andere übernehmen nach der Konfiguration den größten Teil des technischen SEO automatisch.

Visuelle und SaaS-Website-Baukästen (Wix, Squarespace, Webflow, Framer und andere) hosten deine Website und verwalten die Infrastruktur. Sie übernehmen HTTPS, CDN, Sitemaps und grundlegende Metadaten automatisch, beschränken aber meist die serverseitige Konfiguration und die URL-Struktur. Der Zugriff auf robots.txt variiert je nach Baukasten — Wix und Squarespace schränken ihn ein, während Webflow ihn direkt unter Settings → SEO bereitstellt. Für die meisten Websites sind sie großartig, bei Sonderfällen aber einschränkend.

Headless-CMS (Contentful, Strapi, Sanity, Storyblok, Ghost) trennen den Ort, an dem du Inhalte schreibst, von der Art, wie sie gerendert werden. Das SEO wird vollständig durch den von dir gewählten Frontend-Renderer bestimmt — SSG und SSR sind zuverlässig, CSR erfordert Sorgfalt. Alles, was WordPress-Plugins automatisch erledigen (Metadaten, Sitemaps, Canonicals), musst du nun ausdrücklich selbst bauen.

JavaScript-Frameworks (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte) sind Frontend-Rendering-Umgebungen, keine Content-Management-Systeme. Jedes hat eigene SEO-Auswirkungen, abhängig davon, wie Seiten gerendert werden — serverseitig, statisch beim Build oder im Browser. Next.js und Nuxt (Meta-Frameworks) bieten die meiste integrierte SEO-Unterstützung.

E-Commerce-Plattformen (Shopify, WooCommerce, Magento, BigCommerce) legen e-Commerce-spezifische SEO-Themen darüber: strukturierte Produktdaten, Facettennavigation, Paginierung, doppelte URLs durch Varianten und Kollektionen sowie plattformseitig festgelegte URL-Strukturen.

So verwendest du diesen Abschnitt

Beginne mit dem Hub für deine Plattformkategorie und vertiefe dich dann in den Artikel zur konkreten Plattform. Jeder Beitrag behandelt, was die Plattform automatisch erledigt, was sie einschränkt und welche plattformspezifischen Eigenheiten die meisten Probleme verursachen.

TL;DR — Bei Plattform-SEO geht es im Kern um Einschränkungen und Voreinstellungen: Was entscheidet deine Plattform, bevor du sie anfasst, und welche dieser Entscheidungen kannst du überschreiben? Wichtig sind die Lücken bei der Rendering-Architektur (CSR vs. SSR vs. SSG), der Bearbeitbarkeit von robots.txt, der Einbindung strukturierter Daten, der Flexibilität der URL-Struktur und der Sitemap-Abdeckung. Der Rest lässt sich meist mit dem richtigen Plugin oder Build-Setup konfigurieren.

Plattformen auf SEO-Tauglichkeit prüfen

Bei der Bewertung einer Plattform für SEO sind im Maßstab vor allem diese Fragen wichtig:

Rendering-Architektur — Liefert die Plattform vorgerendertes HTML aus, oder baut der Browser die Seite mit JavaScript auf? Statisches HTML ist die sichere Voreinstellung. CSR führt zu Verzögerungen beim Rendering und kann dazu führen, dass Googlebot Inhalte übersieht, wenn die Ausführung von Skripten fehlschlägt. SSR und ISR (inkrementelle statische Regenerierung) liegen dazwischen — SSR ist zuverlässig crawlbar; ISR kann Crawlern veraltete Versionen ausliefern, wenn das Revalidierungsfenster zu lang ist.

Metadatenkontrolle — Kannst du pro Seite programmatisch eindeutige <title>-, <meta description>-, Open-Graph- und Canonical-Tags setzen? Die meisten modernen Plattformen können das. Die Einschränkung zeigt sich meist bei großen Katalogen: Kannst du Metadaten im großen Maßstab ohne individuelle Entwicklung templatisieren?

Strukturierte Daten — Fügt die Plattform Schema automatisch ein, oder ist Handarbeit nötig? Das Produktschema von Shopify hängt vom Theme ab. WordPress braucht ein Plugin. Bei Headless-Setups ist eine ausdrückliche Implementierung erforderlich.

robots.txt und Crawl-Steuerung — Kannst du robots.txt direkt bearbeiten? Bei den meisten Plattformen ist das möglich: Shopify unterstützt die Anpassung in jedem Tarif über ein robots.txt.liquid-Theme-Template, und Webflow stellt die Funktion nativ unter Settings → SEO bereit. Wix und Squarespace sind die stärker eingeschränkte Ausnahme. Für die meisten Websites ist das unwichtig; bei komplexen Websites ist weiterhin relevant, wie viel du überschreiben kannst.

URL-Struktur — Kannst du den Pfad anpassen, oder wird er von der Plattform vorgegeben? Das Präfix /products/ von Shopify ist fest. Die meisten traditionellen CMS-Plattformen geben dir vollständige Kontrolle.

Sitemap — Wird sie automatisch erstellt, manuell gepflegt oder über ein Plugin erzeugt? Was wird aufgenommen — kannst du bestimmte Seiten oder Beitragstypen ausschließen?

Migrationsrisiko — Ein Plattformwechsel während des laufenden Betriebs bedeutet URL-Änderungen und das Risiko fehlerhafter Weiterleitungen. Plane unabhängig von der Plattform eine Weiterleitungskarte und einen vollständigen Crawl nach der Migration ein.

Plattform-SEO-Vergleich nach Einschränkung

| Thema | Traditionelles CMS | SaaS-Baukasten | Headless | JS-Framework | E-Commerce |\n|---|---|---|---|---|---|\n| Rendering | PHP/serverseitig | Gehostet, statisch/SSR | Hängt vom Frontend ab | Hängt vom Framework ab | Gehostet, meist SSR |\n| robots.txt | Vollständige Kontrolle | Variiert (Webflow: vollständig bearbeitbar; Wix/Squarespace: eingeschränkt) | Vollständige Kontrolle | Vollständige Kontrolle | Über Template anpassbar (Shopify: jeder Tarif über Liquid); sonst unterschiedlich |\n| URL-Struktur | Flexibel | Teilweise flexibel | Vollständige Kontrolle | Vollständige Kontrolle | Oft festgelegt |\n| Strukturierte Daten | Plugin oder manuell | Grundlegend, automatisch | Manuell | Manuell | Automatisch (themeabhängig) |\n| Sitemap | Plugin oder automatisch | Automatisch | Manuell oder Plugin | Manuell | Automatisch |\n| Metadaten im großen Maßstab | Plugin-gesteuert | Eingeschränkt | Vollständige Kontrolle | Vollständige Kontrolle | Themeabhängig |

Bei Plattform-SEO geht es darum zu verstehen, was dein CMS oder Website-Baukasten automatisch für dich erledigt und was du manuell konfigurieren musst. Jede Plattform trifft technische SEO-Entscheidungen, bevor du sie anfasst — Rendering-Methode, URL-Struktur, Sitemap-Erstellung, Umgang mit Metadaten und robots.txt-Steuerung.

Traditionelle CMS (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco, Sitecore): vollständige Kontrolle über alle SEO-Einstellungen. WordPress hat das umfangreichste Plugin-Ökosystem für SEO-Automatisierung. Aufwendiger zu pflegen, aber am flexibelsten.

SaaS-Website-Baukästen (Wix, Squarespace, Webflow, Framer, Weebly, Duda): übernehmen HTTPS, CDN, grundlegende Sitemaps und Metadaten automatisch. Die meisten schränken URL-Struktur und Serverkonfiguration ein; der Zugriff auf robots.txt variiert (Webflow: vollständig bearbeitbar; Wix/Squarespace: eingeschränkt). Für die meisten Websites geeignet.

Headless-CMS (Contentful, Strapi, Sanity, Storyblok, Ghost): Das SEO hängt vollständig vom gewählten Frontend-Framework ab. Verwende SSG oder SSR; vermeide CSR. Alles, was Plugins beim SEO erledigen (Sitemaps, Canonicals, Metadaten), muss ausdrücklich gebaut werden.

JavaScript-Frameworks (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte): Das SEO variiert je nach Rendering-Modus. Next.js und Nuxt bieten starke integrierte SSR-/SSG-Unterstützung. Reines React/Vue im CSR-Modus benötigt Prerendering oder SSR für eine zuverlässige Indexierung.

E-Commerce-Plattformen (Shopify, WooCommerce, Magento, BigCommerce): bringen e-Commerce-spezifische Themen hinzu — Produktschema, Facettennavigation, doppelte URLs durch Kollektionen und Varianten, Paginierung und plattformseitig festgelegte URL-Strukturen.

Entscheidungsrahmen für die Plattformwahl im SEO

Schritt 1 — Identifiziere deine Rendering-Einschränkung\n- Inhalte, die ranken müssen → benötigen SSR oder SSG (statisches HTML wird an Crawler ausgeliefert)\n- Nur CSR → kritische Seiten vorab rendern oder zu SSR/SSG wechseln\n- ISR → kurze Revalidierungsfenster für Inhalte festlegen, die sich häufig ändern

Schritt 2 — Prüfe die Voreinstellungen der Plattform\n- Was erzeugt die Plattform automatisch? (Sitemap, Canonicals, strukturierte Daten)\n- Was ist gesperrt/nicht konfigurierbar? (robots.txt, URL-Struktur, <head>-Zugriff)\n- Was erfordert ein Plugin oder eigenen Code?

Schritt 3 — Ordne deine SEO-Anforderungen den Plattformfunktionen zu\n- Metadaten-Templating im großen Maßstab?\n- Benutzerdefinierte strukturierte Datentypen?\n- Facettennavigation / Umgang mit Parametern?\n- Hreflang für internationale Websites?\n- Zugriff auf Logdateien für die Crawl-Analyse?

Schritt 4 — Bewerte die Migrationskosten\n- Aktuelle URL-Struktur → kannst du sie beibehalten oder brauchst du Weiterleitungen?\n- Weiterleitungsinfrastruktur auf der neuen Plattform?\n- Monitoringplan nach der Migration?

Checkliste für eine Plattformmigration

• Alle aktuellen URLs exportieren (Crawl oder Sitemap)\n- [ ] Alte → neue URLs zuordnen; alle Änderungen markieren\n- [ ] Für jede geänderte URL eine 301-Weiterleitung implementieren\n- [ ] Canonical-Tags vor dem Launch setzen\n- [ ] Neue Sitemap in der Search Console einreichen\n- [ ] Staging crawlen, um Rendering, Titel, Meta-Daten und Canonicals zu prüfen\n- [ ] Crawl-Fehler und Indexabdeckung 4–6 Wochen nach dem Launch überwachen\n- [ ] Core Web Vitals auf der neuen Plattform prüfen (CDN und Bildverarbeitung unterscheiden sich oft)

Vertiefende Beiträge zu einzelnen Plattformen

• WordPress-SEO\n- Shopify-SEO\n- Webflow-SEO\n- Headless-CMS-SEO\n- Next.js-SEO

Änderungsprotokoll