Menu
Menu
Mit viel digitaler Liebe erstellt von Starsmedia.com
Eine datenbasierte Analyse für Unternehmer, die vor der Technologie-Entscheidung stehen. Wer 2026 eine neue Webplattform aufbaut, steht früher oder später vor der Frage: WordPress oder ein modernes Framework wie Next.js? Die SEO-Implikationen dieser Entscheidung werden dabei oft überschätzt — oder an der falschen Stelle gesucht. Die kurze Antwort: Google indexiert korrekt implementierte Next.js-Seiten genauso zuverlässig wie WordPress-Seiten. Der Unterschied liegt nicht in der Indexierung selbst, sondern in drei Nebeneffekten — Rendering-Geschwindigkeit, Core Web Vitals und langfristigem Wartungsaufwand. Dieser Artikel zeigt, was die Daten tatsächlich sagen.
Google verarbeitet jede Webseite in drei aufeinanderfolgenden Schritten. Im ersten Schritt — dem Crawling — ruft Googlebot die Seite ab und liest das initiale HTML. Im zweiten Schritt — dem Rendering — führt Googles Web Rendering Service (WRS) JavaScript aus und erzeugt das finale DOM. Im dritten Schritt — der Indexierung — analysiert Google den gerenderten Inhalt und entscheidet, ob die Seite in den Suchindex aufgenommen wird. Der entscheidende Punkt: Bei WordPress entfällt der zweite Schritt vollständig. Der Server liefert fertiges HTML, es gibt kein JavaScript zum Rendern. Bei Next.js mit Server-Side Rendering (SSR) oder Incremental Static Regeneration (ISR) ist die Situation identisch — der Server generiert ebenfalls vollständiges HTML, bevor es an den Browser oder den Crawler geschickt wird.
Alle drei Rendering-Strategien von Next.js — SSR, SSG und ISR — liefern vollständig gerendertes HTML, sodass Suchmaschinen den Inhalt crawlen können, ohne JavaScript auszuführen. Das bestätigt die offizielle Next.js-Dokumentation unmissverständlich: Das Wichtigste für SEO ist, dass Seitendaten und Metadaten beim Laden der Seite ohne JavaScript verfügbar sind. Das Problem betrifft ausschließlich Client-Side Rendering (CSR), also reine React-Apps ohne serverseitige Vorverarbeitung. Dort sehen Suchmaschinen-Crawler tatsächlich nur eine leere Seite oder eine Loading-Nachricht im initialen HTML. Für Next.js mit SSR ist das irrelevant.
Im April 2024 hat Vercel eine umfangreiche Studie auf nextjs.org durchgeführt. Über einen Monat wurden mehr als 100.000 Googlebot-Anfragen analysiert. Das Setup: Eine eigens entwickelte Edge Middleware fing Googlebot-Requests ab und injizierte ein leichtgewichtiges JavaScript-Beacon, das den genauen Zeitpunkt des abgeschlossenen Renderings zurückmeldete. Die Ergebnisse waren eindeutig: Sämtliche 100.000 Googlebot-Fetches auf nextjs.org wurden vollständig gerendert — einschließlich Seiten mit komplexen JavaScript-Interaktionen und asynchron geladenen Inhalten. Kein einziger Crawl schlug fehl.
Zum Rendering-Delay lieferte die Studie über 37.000 gematchte Server-Beacon-Paare und zeigte, dass das 25. Perzentil der Seiten innerhalb von 4 Sekunden nach dem initialen Crawl gerendert wurde. Das widerlegt die in der SEO-Community verbreitete Annahme einer langen Rendering-Queue. Am 99. Perzentil betrug der Delay bis zu 18 Stunden — aber das waren statistische Ausreißer, nicht die Norm. Besonders aufschlussreich: Die Studie fand keinen signifikanten Zusammenhang zwischen der Komplexität des JavaScript-Codes und der Rendering-Verzögerung. Allerdings räumte Vercel ein, dass bei deutlich größeren Websites komplexeres JavaScript die Crawl-Effizienz potenziell beeinträchtigen kann.
Eine häufig zitierte Studie von SearchPilot aus dem Jahr 2024 kam zu dem Ergebnis, dass Seiten, die ausschließlich auf JavaScript basieren, 31% länger für die Indexierung benötigten als statische Seiten. Diese Zahl ist korrekt, aber der Kontext wird oft unterschlagen. Die Studie bezieht sich auf reines Client-Side Rendering — also Seiten, bei denen das HTML erst im Browser zusammengebaut wird. Next.js mit SSR oder ISR fällt nicht in diese Kategorie, weil der Server bereits fertiges HTML ausliefert. Die 31% Verzögerung sind für eine korrekt konfigurierte Next.js-Anwendung schlicht nicht zutreffend.
Hier wird es relevant. Google nutzt Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) — als Ranking-Signal. Vercel-CTO Malte Ubl, der als Director of Google Search für das Page-Experience-Ranking verantwortlich war, stellt klar: "Google berücksichtigt ausschließlich die Core Web Vitals Felddaten beim Ranking". Der Lighthouse-Score wird in keiner Weise für das Suchranking herangezogen.
Das bedeutet: Nicht der simulierte Lighthouse-Test zählt, sondern die reale Performance, die echte Chrome-Nutzer über 28 Tage hinweg erleben. Gleichzeitig relativiert er: Relevanz der Suchanfrage und Qualität des Inhalts sind wesentlich wichtigere Faktoren als die Page Experience. Aber bei gleichwertiger Relevanz kann Page Experience den Ausschlag geben. Und genau hier zeigt sich der strukturelle Unterschied zwischen WordPress und Next.js.
Ein konkreter Vergleich von Digital Polygon zeigt das Ausmaß: Die WordPress-Seite erreichte auf dem Desktop einen Lighthouse-Score von 97%, litt aber auf Mobile mit nur 51%. Die Hauptprobleme: Bildoptimierung, ungenutztes JavaScript und CSS. Die Next.js-Version derselben Seite erzielte 100% auf Desktop und 86% auf Mobile — eine Verbesserung von über 50% gegenüber der WordPress-Variante. Andere Benchmarks bestätigen den Trend: Next.js ist oft bis zu 10x schneller als WordPress, besonders auf Mobile. Das klingt dramatisch, gilt aber primär für WordPress-Seiten mit Page Buildern wie Elementor oder Divi und umfangreichem Plugin-Overhead.
Eine gut optimierte WordPress-Seite mit Server-Caching, einem CDN, Bildoptimierung und disziplinierter Plugin-Auswahl kann durchaus starke Core Web Vitals erzielen. Das ist machbar — erfordert aber bewussten, laufenden Optimierungsaufwand. Der Unterschied: Bei Next.js ist Performance der Default. Bei WordPress ist Performance das Ergebnis aktiver Wartung.
Die Geschichte der JavaScript-Indexierung bei Google ist eine Geschichte der kontinuierlichen Verbesserung. Noch 2018 war das Rendering von JavaScript-Seiten inkonsistent und konnte Wochen dauern. 2019 stellte Google auf Evergreen Chromium um, was die JavaScript-Unterstützung massiv verbesserte. Martin Splitt, Developer Advocate bei Google, beschrieb die Entwicklung auf einer Konferenz: Im letzten Jahr haben Tom und ich noch gesagt, es kann bis zu einer Woche dauern. Vergessen Sie das. Die neuen Zahlen sehen viel besser aus. Im Median liegt die Zeit zwischen Crawling und fertigem Rendering bei fünf Sekunden.
Allerdings zeigen unabhängige Untersuchungen von Onely, dass die Realität differenzierter ist. Obwohl der Median bei wenigen Sekunden liegt, bleiben je nach Stichprobe 5 bis 50 Prozent der neu hinzugefügten Seiten auch nach zwei Wochen in Teilen unindexiert, wenn JavaScript-Elemente betroffen sind. Für Next.js SSR/ISR ist das erneut irrelevant — dort gibt es keine JavaScript-Elemente, die auf Rendering warten müssen. Der HTML-Output ist beim ersten Crawl bereits komplett.
Ein Aspekt, der 2026 zunehmend relevant wird: die meisten LLM-Crawler und KI-gestützten Suchwerkzeuge führen kein JavaScript aus. Sie konsumieren ausschließlich das rohe HTML einer Seite. Wer in KI-generierten Antworten — sei es bei Perplexity, ChatGPT Search oder Googles AI Overviews — auftauchen will, muss sicherstellen, dass der relevante Content im initialen HTML steht.
Das gilt für WordPress automatisch. Für Next.js mit SSR/ISR ebenfalls. Für reine Client-Side-Rendered React-Apps ist es ein ernsthaftes Problem.
Der Vorteil von WordPress liegt nicht bei der Indexierung, sondern bei der operativen SEO-Arbeit. Das technische SEO-Ökosystem von WordPress ist ausgereift. Plugins wie Rank Math, Yoast SEO und All in One SEO handhaben Meta-Tags, Schema-Markup, XML-Sitemaps, Canonical URLs, robots.txt-Management und OpenGraph-Tags über grafische Oberflächen, die kein Coding erfordern. Ein Redakteur kann SEO-relevante Einstellungen ändern, ohne einen Entwickler einzubeziehen. Dazu kommt die Content Velocity: Redakteure können Inhalte veröffentlichen, aktualisieren und verwalten, ohne ein Entwickler-Ticket zu öffnen oder eine Zeile Code anzufassen. Bei Next.js muss dieses Tooling entweder manuell implementiert oder über ein Headless CMS wie Sanity, Contentful oder Strapi abgebildet werden. Das funktioniert zuverlässig, erfordert aber initiale Konfiguration und einen technisch versierten Setup-Prozess.
WordPress-Seiten haben eine strukturelle Schwäche, die nichts mit dem CMS selbst zu tun hat, sondern mit dem Ökosystem: Plugin-Bloat. Jedes Plugin fügt JavaScript, CSS und Datenbankabfragen hinzu. Viele WordPress-Seiten in der freien Wildbahn — insbesondere solche mit Page Buildern — liefern erhebliche JavaScript-Payloads und Render-blockierende Ressourcen aus, die Core Web Vitals Compliance erschweren. Dazu kommt das Sicherheitsrisiko. Kompromittierte WordPress-Seiten werden von Google auf eine Blacklist gesetzt — ein sofortiger Ranking-Verlust, dessen Erholung Monate dauern kann. 2025 wurden kritische Sicherheitslücken in weit verbreiteten Plugins wie Elementor und WPForms entdeckt, die zusammen auf zig Millionen Seiten installiert sind. Next.js-Seiten mit statischem Output haben praktisch keine Angriffsfläche — es gibt kein exponiertes Admin-Panel, keine Datenbank zum Kompromittieren und keine Login-Seite für Brute-Force-Angriffe.
Und ein oft übersehener Aspekt: Next.js erlaubt es, hunderte zielgerichtete Landing Pages aus einem einzigen Template zu generieren, gespeist aus strukturierten Daten. WordPress kann das technisch über Advanced Custom Fields und Custom Post Types nachbilden, aber jede zusätzliche Seite erhöht die Datenbanklast, jede dynamische Abfrage verlangsamt den Server. Für Plattformen, die auf Long-Tail-Keywords skalieren wollen, ist dieser Architekturunterschied oft der entscheidende Faktor bei der Wahl des Tech-Stacks.
Die Indexierbarkeit ist bei beiden Systemen identisch — WordPress liefert statisches HTML, Next.js SSR ebenfalls. Der Rendering-Delay liegt bei beiden bei null, weil kein clientseitiges JavaScript-Rendering nötig ist. Bei den Core Web Vitals auf Mobile zeigt sich der Unterschied: WordPress-Seiten mit Plugins erreichen typischerweise 40 bis 60 Prozent im Lighthouse-Score, Next.js-Seiten liegen typischerweise bei 80 bis 95 Prozent. Das SEO-Tooling ist bei WordPress über Yoast und RankMath out-of-the-box verfügbar, bei Next.js muss es manuell oder über ein Headless CMS eingerichtet werden. Die Kompatibilität mit LLM-Crawlern ist bei beiden vollständig gegeben. Der Wartungsaufwand für Performance ist bei WordPress hoch — Plugin-Updates, Caching-Konfiguration und CDN-Setup sind Dauerthemen. Bei Next.js ist Performance der Default und erfordert weniger laufende Intervention.
Wenn der primäre Zweck einer Website die Veröffentlichung von Inhalten durch nicht-technische Redakteure ist und SEO-Tooling ohne Entwickler-Beteiligung funktionieren muss, bleibt WordPress die pragmatische Wahl. Wenn die Website gleichzeitig eine Plattform ist — mit Nutzer-Interaktion, Messaging, dynamischen Feeds, Login-Bereichen und langfristiger Skalierung — dann löst Next.js das SEO-Problem ebenso zuverlässig und bietet darüber hinaus die Architektur für alles, was WordPress nicht nativ kann.
Die Entscheidung ist keine SEO-Entscheidung. Es ist eine Produktentscheidung.
Guntram Bechtold, StarsMedia — April 2026
