Rankt eine WordPress-Seite schlechter als eine modern gebaute? Die ehrliche Antwort

Die Frage taucht in fast jedem Erstgespräch auf: «Wir sind auf WordPress — schadet uns das bei Google?» Die ehrliche Antwort lautet nein. Google bewertet einzelne URLs anhand von Relevanz, Inhalt, Verlinkung und dem, was der Server tatsächlich ausliefert; welches System diese Antwort erzeugt hat, ist für die Bewertung gleichgültig. Eine gut gebaute WordPress-Seite rankt genauso gut wie eine mit einem modernen Framework gebaute, und sie tut es täglich millionenfach.

Damit ist die Diskussion aber nicht zu Ende, sondern fängt an der richtigen Stelle an. Denn es gibt sehr wohl messbare Unterschiede zwischen einer typischen WordPress-Installation und einer bewusst gebauten Seite — sie liegen nur nicht beim Ranking, sondern bei dem, was am Ende über die Leitung geht. Dieser Artikel benennt sie mit Zahlen und sagt auch, wo das Argument endet.

Die kurze Antwort: Das System ist kein Rankingfaktor

Es gibt in Googles Bewertung keine Variable, die das verwendete Content-Management-System abfragt. Der Crawler ruft eine URL ab, erhält HTML, rendert es gegebenenfalls und bewertet das Ergebnis — Inhalt, Struktur, interne und externe Verlinkung, Aktualität, Nutzersignale. Ob dieses HTML aus PHP-Templates, einem statischen Generator oder einem serverseitig gerenderten JavaScript-Framework stammt, ist an dieser Stelle nicht rekonstruierbar und auch nicht relevant.

Das ist keine Nachsicht, sondern Logik: Ein System kann in derselben Woche eine hervorragende und eine katastrophale Seite erzeugen. Google müsste also ohnehin die Auslieferung bewerten und nicht die Herkunft. Genau das tut es. Wer behauptet, ein bestimmtes CMS sei ein Rankingnachteil, verwechselt eine Korrelation im Durchschnitt mit einer Ursache im Einzelfall.

Die praktische Konsequenz ist unbequem für beide Lager: WordPress-Skeptiker verlieren ihr stärkstes Verkaufsargument, WordPress-Verteidiger ihre Ausrede. Wenn das System nicht schuld ist, dann ist es die konkrete Umsetzung — und die lässt sich prüfen.

Was die Daten über WordPress und Performance wirklich sagen

WordPress-Seiten schneiden bei Core Web Vitals leicht unterdurchschnittlich ab, und der Abstand ist kleiner als die Debatte vermuten lässt. Der Web Almanac 2025 der HTTP Archive misst über alle erfassten WordPress-Seiten hinweg eine Bestehensquote von 45 Prozent bei den Core Web Vitals auf Mobilgeräten. Das Gesamtweb liegt im selben Datensatz bei 48 Prozent. Drei Prozentpunkte — das ist ein Befund, aber kein Argument, mit dem sich ein Relaunch begründen lässt.

Interessanter wird der Vergleich über mehrere Systeme hinweg:

Quelle: Web Almanac 2025, CMS- und Performance-Kapitel.

Die Tabelle widerlegt die einfache Erzählung gleich zweimal. Erstens liegt WordPress praktisch auf dem Niveau von Drupal und Weebly, also mitten im Feld der klassischen Systeme. Zweitens stehen an der Spitze keine Frameworks, sondern gehostete Baukästen wie Duda und Wix. Deren Vorsprung entsteht nicht durch überlegene Technologie, sondern dadurch, dass sie ihren Nutzern kaum Möglichkeiten geben, etwas kaputt zu machen: eine Bildpipeline, ein Caching-Modell, ein begrenzter Satz an Bausteinen. Der Web Almanac formuliert es nüchtern — die CMS-Wahl wirke vor allem über die Vorgaben, Standardeinstellungen und Werkzeuge, die ein System mitbringt.

Genau da liegt die eigentliche Erklärung für die 45 Prozent. Rund 60 Prozent der WordPress-Seiten setzen einen Page Builder ein, allen voran Elementor mit 43 Prozent Anteil an dieser Gruppe. Page Builder erzeugen laut demselben Kapitel tendenziell komplexere DOM-Strukturen sowie grössere CSS- und JavaScript-Pakete. Der Medianwert des Lighthouse-Performance-Scores liegt bei WordPress mobil bei 41, bei Wix bei 64. WordPress ist also nicht langsam — die durchschnittliche WordPress-Installation ist es.

Wo die messbaren Unterschiede tatsächlich entstehen

Der grösste technische Unterschied zwischen einer typischen Plugin-Installation und einer bewusst gebauten Seite ist die Menge an Code, die pro Seitenaufruf ausgeliefert wird, ohne dort gebraucht zu werden. Ein Theme bringt sein Stylesheet mit, der Page Builder seines, und jedes Plugin hängt seine eigenen Dateien in den Seitenkopf — der Slider auf der Kontaktseite, das Formular-Plugin im Blog, das Cookie-Banner überall. Keine dieser Entscheidungen ist für sich falsch. In Summe entsteht ein Dokument, in dem der eigentliche Inhalt einen einstelligen Prozentanteil hat.

Wie stark dieser Hebel ist, können wir an der eigenen Seite beziffern. Beim Aufräumen unserer Landingpage /seo-agentur-zuerich haben wir eine einzige Konfigurationsentscheidung zurückgenommen — das Inlining sämtlicher Stile ins Dokument. Das ausgelieferte HTML fiel von 517 KB auf 159 KB, die Text-Ratio stieg von 2,45 auf 9,45 Prozent, und die Payload bei internen Klicks sank um 79 Prozent (eigene Messung, August 2026). Das ist eine eigene Messung an einer eigenen Seite, kein Branchendurchschnitt. Sie zeigt aber die Grössenordnung: Ein einziger Auslieferungsschalter bewegte mehr als jede Content-Massnahme desselben Quartals.

Für die klassische Google-Suche ist das primär ein Hygienethema. Für die KI-Suche ist es mehr, weil dort ohne Rendering und mit knappen Byte-Budgets gearbeitet wird — wir haben das im Beitrag zu Text-Ratio und Payload im Detail durchgerechnet. Der Punkt gilt für WordPress und für jedes andere System gleichermassen: Entscheidend ist nicht das Werkzeug, sondern was am Ende über die Leitung geht.

Strukturierte Daten: Kontrolle statt Plugin-Lotterie

Bei strukturierten Daten entsteht der Unterschied nicht in der Qualität, sondern in der Kontrolle darüber, was am Ende im Dokument steht. In einem selbst gebauten Setup wird JSON-LD aus denselben Daten erzeugt, die auch die sichtbare Seite rendern. Was im FAQ-Block steht, steht im FAQ-Schema — eine Abweichung ist technisch gar nicht möglich, weil beides aus einer Quelle kommt.

In einer gewachsenen WordPress-Installation liefern häufig mehrere Quellen gleichzeitig Markup: das SEO-Plugin, das Theme, ein Bewertungs-Plugin, vielleicht noch ein Shop-Modul. Das Ergebnis sind doppelte Entitäten, widersprüchliche Angaben und Schema-Blöcke, die Inhalte beschreiben, die auf der Seite gar nicht sichtbar sind. Genau das ist der Fall, den Google als Verstoss gegen die Richtlinien für strukturierte Daten behandelt.

Das ist kein WordPress-Problem, sondern ein Plugin-Stapel-Problem, und es lässt sich in WordPress sauber lösen — mit einem einzigen zuständigen Plugin und abgeschalteter Konkurrenz. Nur passiert das selten von allein. Wer wissen will, was auf der eigenen Domain tatsächlich ausgeliefert wird, findet den Einstieg über unser Website-Audit oder den schnelleren SEO-Check.

Wartung und Sicherheit sind ein SEO-Thema

Der Wartungsaufwand ist der am deutlichsten belegbare Unterschied zwischen einem Plugin-Ökosystem und einer geschlossenen Codebasis — und er wirkt indirekt auf die Sichtbarkeit. Patchstack zählt in seinem Whitepaper zur WordPress-Sicherheit für das Jahr 2025 insgesamt 11'334 neue Schwachstellen im WordPress-Ökosystem, ein Plus von 42 Prozent gegenüber dem Vorjahr. 91 Prozent davon entfielen auf Plugins, 9 Prozent auf Themes; im WordPress-Kern selbst waren es sechs, allesamt mit niedriger Priorität. 46 Prozent der Schwachstellen hatten zum Zeitpunkt der Veröffentlichung noch keinen Patch.

Diese Zahlen sagen nichts über Rankings, und sie sagen ausdrücklich nichts Schlechtes über WordPress selbst — der Kern ist bemerkenswert stabil. Sie beschreiben die Kosten eines offenen Ökosystems: Wer zwanzig Plugins einsetzt, unterhält zwanzig fremde Codebasen, deren Updatezyklus er nicht kontrolliert. Der SEO-Bezug entsteht erst im Schadenfall, dann aber schlagartig — kompromittierte Seiten mit eingeschleusten Links oder Weiterleitungen verlieren Sichtbarkeit schneller, als jede Optimierung sie aufbauen kann.

Die ehrliche Gegenrechnung: Eine selbst gebaute Anwendung hat ebenfalls Abhängigkeiten, und wer sie nicht aktualisiert, hat dasselbe Problem in kleinerer Auflage. Der Unterschied ist die Angriffsfläche und die Frage, wer für Updates zuständig ist. Beides gehört in die Gesamtkostenrechnung, nicht in eine Ranking-Diskussion.

Wann WordPress die richtige Wahl bleibt

WordPress ist dann die richtige Entscheidung, wenn redaktionelle Arbeit im Vordergrund steht und das Team die Inhalte selbst pflegen soll. Ein eingespielter Redaktionsprozess, ein bekanntes Backend, ein grosser Markt an Dienstleistern und Erweiterungen: Das sind reale Vorteile, die kein Framework mitliefert. Für einen Blog mit hoher Publikationsfrequenz, für eine Vereinsseite, für ein Unternehmen mit interner Redaktion ist WordPress meist die wirtschaftlich vernünftigste Antwort.

Sie wird noch besser, wenn ein paar Entscheidungen früh getroffen werden: ein schlankes Theme statt eines Multipurpose-Pakets, ein Page Builder nur dort, wo er wirklich gebraucht wird, ein einziges SEO-Plugin, konsequente Bildoptimierung und ein Hosting, das nicht auf dem billigsten Shared-Paket sitzt. Damit landet eine WordPress-Seite zuverlässig über dem Durchschnitt ihrer eigenen Statistik — und dann spielt die Systemfrage für die Sichtbarkeit keine Rolle mehr.

Wann sich ein modernes Setup rechnet

Ein selbst gebautes Setup lohnt sich dann, wenn die Seite mehr tun muss als Inhalte anzeigen, oder wenn Auslieferung und Wartungslast zum Engpass geworden sind. Konkret: wenn Rechner, Konfiguratoren, Buchungslogik oder Kundenkonten dazukommen; wenn Hunderte programmatisch erzeugte Seiten aus einer Datenquelle entstehen sollen; wenn jedes Update ein Risiko darstellt, weil ein Dutzend Plugins voneinander abhängen; oder wenn die Payload so hoch ist, dass sie in der KI-Suche zum Problem wird.

In diesen Fällen geht es nicht um Rankings, sondern um Handlungsfähigkeit. Was ein solches Projekt kostet und wie es abläuft, haben wir auf den Seiten Website erstellen lassen und Webdesign-Preise offengelegt; wer erst prüfen will, ob sich der Aufwand überhaupt lohnt, findet mit einer Prototyp-Validierung den günstigeren Einstieg. Für Teams, die den Weg mit KI-gestützter Entwicklung abkürzen wollen, gilt dieselbe Regel wie sonst: Das Ergebnis zählt, nicht das Werkzeug, mit dem es entstanden ist. Wie ein solcher Umzug abläuft, ohne bestehende Sichtbarkeit zu verlieren, haben wir in Von WordPress auf ein modernes Setup migrieren beschrieben.

Wer gestalterisch gebunden bleiben will, ohne selbst zu entwickeln, findet in Systemen wie Webflow oder Framer eine Zwischenstufe — mit den bekannten Einschränkungen bei Datenmodell, Logik und Exportierbarkeit.

Die Reihenfolge, die tatsächlich über Rankings entscheidet

Technische Auslieferung ist der letzte Schritt einer Kette, nicht der erste — und wer sie an den Anfang stellt, optimiert an der falschen Stelle. Das lässt sich an der eigenen Domain zeigen: Unsere Search Console weist über sechs Monate 131'465 Impressionen auf Seitenebene bei 138 Klicks aus, und 63 Prozent aller Impressionen liegen jenseits von Position 20. Das ist kein Payload-Befund, sondern ein Positionsbefund. Eine Seite auf Rang 40 wird auch mit perfekten Core Web Vitals nicht geklickt.

Die vernünftige Reihenfolge lautet deshalb: erst Relevanz und Substanz, dann Struktur und interne Verlinkung, dann technische Auslieferung. Der letzte Schritt sorgt dafür, dass die ersten beiden auf dem Weg zu Google und zu den KI-Systemen nicht verloren gehen. Er ersetzt sie nicht.

Und damit lässt sich die Ausgangsfrage sauber beantworten. Eine WordPress-Seite rankt nicht schlechter, weil sie WordPress ist. Sie rankt schlechter, wenn sie langsamer antwortet, mehr Ballast ausliefert, widersprüchliches Markup produziert oder schlechter gepflegt wird als die Konkurrenz — und all das kann jedem System passieren. Die nützliche Frage ist also nie «welches System», sondern «was liefern wir aus, und wer hält es instand». Wer sie beantworten will, ohne selbst in den Quelltext zu steigen, kann bei uns als Web-Agentur mit einer Bestandsaufnahme anfangen.