Kurz gesagt
Eine statische Website eignet sich für Firmenwebsites, deren Inhalte sich selten ändern: Der Server liefert fertige Dateien ohne Datenbank aus, das verkürzt die Antwortzeit und verkleinert die Angriffsfläche. WordPress eignet sich, wenn Ihr Team oft selbst veröffentlicht oder fertige Funktionen wie einen Shop braucht. Entscheidend ist, wer Inhalte und Updates übernimmt.
Das Wichtigste in Kürze
- Auf dem Smartphone bestanden im September 2026 weltweit 48 % der WordPress-Websites alle drei Core Web Vitals, bei Astro 71 %, bei Hugo 78 %.
- Den Abstand macht vor allem die Antwortzeit des Servers: Weltweit hatten nur 23 % der WordPress-Websites eine gute Time to First Byte, bei Astro 63 %.
- Statisch heißt nicht automatisch schnell: Websites mit Gatsby übertrugen im Median 1,02 MB JavaScript und bestanden nur zu 44 %.
- 2025 meldete ein Anbieter von Sicherheitsdiensten 11.334 neue Lücken rund um WordPress, 91 % davon in Plugins und sechs im Kern.
- WordPress ist die bessere Wahl, wenn mehrere Personen ohne Entwickler veröffentlichen oder Sie Funktionen wie einen Shop fertig einbauen wollen.
Was unterscheidet eine statische Website von WordPress?
Eine statische Website besteht aus fertigen HTML-Dateien, die der Server bei jedem Aufruf unverändert ausliefert. Erzeugt werden sie vorab, etwa mit einem Static Site Generator. WordPress setzt eine Seite dagegen erst beim Aufruf mit PHP aus Vorlagen und Datenbank zusammen. Dafür ändern Sie Inhalte direkt in einem Editor.
Ein Static Site Generator ist ein Programm, das Texte, etwa im Format Markdown, in fertige Dateien aus HTML, CSS und JavaScript übersetzt. Eine solche Website hat keine Logik auf dem Server: Unter jeder Adresse erhalten alle Besucher denselben Inhalt (MDN-Glossar). Bei einer dynamischen Website fügt Programmcode auf dem Server die Daten aus einer Datenbank erst bei Bedarf in Vorlagen ein (MDN, Einführung in die Serverseite). WordPress braucht dafür einen Server mit PHP und der Datenbank MariaDB oder MySQL (WordPress.org, Anforderungen).
Der Begriff Jamstack für diese Bauweise entstand beim Unternehmen Netlify. Die Seiten werden dabei vorab gebaut und über ein Content Delivery Network (CDN) ausgeliefert, ein Netz von Servern an vielen Orten (MDN-Glossar, CDN). Zusatzfunktionen werden über Schnittstellen angebunden (Jamstack.org).
WordPress ist das mit Abstand verbreitetste Redaktionssystem. Es läuft auf 39,4 % aller Websites, das sind 58,1 % der Websites, deren System W3Techs erkennt. Astro kommt auf 0,2 % aller Websites, Hugo auf 0,1 % (W3Techs, 08.11.2026).
Ganz scharf ist die Grenze nicht. WordPress kann mit einem Caching-Plugin gespeicherte Seiten als fertige Dateien ausliefern (WordPress-Handbuch, Cache). Astro baut Seiten standardmäßig vorab, kann einzelne Seiten aber auch erst beim Aufruf auf dem Server erzeugen (Astro-Dokumentation, On-demand Rendering). Wie Suchmaschinen Seiten abrufen und was technisch sonst dazugehört, erklärt unser Leitfaden technisches SEO.
| Kriterium | Statische Website | WordPress | Quellen |
|---|---|---|---|
| Ladezeit bei echten Besuchen | alle drei Core Web Vitals gut auf dem Smartphone, weltweit: Astro 71 %, Hugo 78 %, Jekyll 78 %, Gatsby 44 % | 48 %; der Schwachpunkt ist die Antwortzeit des Servers | 8 |
| Was der Server je Aufruf tut | liefert eine fertige Datei aus | erzeugt die Seite mit PHP und Datenbank, außer ein Cache liefert eine gespeicherte Fassung | 2, 3, 6 |
| Sicherheit | auf dem Webserver weder Anmeldung noch Datenbank noch Programmcode; Angriffsziele bleiben Zugänge und die Pakete beim Bau | Sicherheitsteam für den Kern; 2025 laut einem Anbieter von Sicherheitsdiensten 11.334 neue Lücken, 91 % davon in Plugins | 16, 17, 18, 21 |
| Wartung | auf dem Server nichts zu aktualisieren; Generator, Node.js und Pakete vor dem nächsten Bau aktualisieren | Kern, Plugins, Themes und PHP laufend; von Dezember 2025 bis Oktober 2026 erschienen 15 Versionen der jeweils neuesten Reihe | 22, 23, 24, 25, 26 |
| Kosten über die Laufzeit | Software frei; Hosting für Dateien; Änderungen kosten Arbeitszeit von Fachleuten, außer ein Redaktionssystem ist angebunden | Software frei; Hosting mit PHP und Datenbank, Lizenzen für kostenpflichtige Erweiterungen, laufende Wartung | 3, 16, 27, 28; Einschätzung Datafalke |
| Redaktion ohne Entwickler | nur mit angebundenem Redaktionssystem (Headless-CMS), sonst Textdateien ändern und neu bauen | Blockeditor, sechs Rollen, Versionsverlauf | 1, 29, 30, 31, 34 |
| Erweiterbarkeit | Formular, Suche, Login oder Shop über externe Dienste oder eigene Serverfunktionen | über 78.000 kostenlose Plugins im offiziellen Verzeichnis | 4, 7, 32 |
| Hosting | jeder Webserver, auch über ein CDN | empfohlen: Server mit PHP ab 8.3, MariaDB ab 10.11 oder MySQL ab 8.0 und HTTPS | 1, 3 |
| Google und KI-Crawler | Inhalt steht fertig im HTML | Inhalt steht ebenfalls im HTML, das der Server erzeugt; was erst JavaScript im Browser nachlädt, sehen viele KI-Crawler nicht | 2, 37, 38 |
Die Zahlen in der Spalte „Quellen“ sind die Nummern der Quellenliste am Ende des Beitrags. Datafalke baut selbst statische Websites. Deshalb stützt sich der Vergleich auf öffentliche Daten Dritter; unsere eigene Website steht nur im Abschnitt „Aus der Praxis“.
Wann ist WordPress die bessere Wahl?
WordPress ist die bessere Wahl, wenn mehrere Personen ohne Entwickler regelmäßig veröffentlichen. Das gilt auch, wenn Sie Funktionen wie einen Shop aus fertigen Erweiterungen zusammenstellen wollen oder Ihr Team WordPress schon beherrscht. Dafür müssen Sie die Updates von Kern, Plugins, Themes und PHP fest einplanen.
Stärken: Seit WordPress 5.0 vom Dezember 2018 ist der Blockeditor Standard. Mit ihm bauen Sie Seiten und Beiträge aus Blöcken zusammen (WordPress-Dokumentation, Blockeditor). Sechs vordefinierte Rollen legen fest, wer schreiben, veröffentlichen oder die Website verwalten darf (Rollen und Rechte). Jede gespeicherte Fassung bleibt im Versionsverlauf und lässt sich wiederherstellen (Revisionen). Viele Funktionen kommen als Erweiterung: Das offizielle Verzeichnis führt über 78.000 kostenlose Plugins (Plugin-Verzeichnis), und 19,7 % der WordPress-Websites nutzen laut W3Techs die Shop-Erweiterung WooCommerce (W3Techs, WordPress). Kleinere Updates des Kerns spielt WordPress auf den meisten Websites automatisch ein (WordPress-Handbuch, Updates).
Grenzen: Wie schnell eine WordPress-Website lädt und wie viel Aufwand ihr Betrieb macht, hängt laut Web Almanac stark davon ab, wie sie umgesetzt ist. Page-Builder, mit denen Sie Layouts ohne Code zusammenstellen, erzeugen dem Bericht zufolge oft komplexeres HTML und größere CSS- und JavaScript-Dateien (Web Almanac 2025, CMS). Auch Sicherheitslücken stecken vor allem in Plugins und Themes (Patchstack, 25.02.2026).
Einsatzfall: Blogs und Magazine mit mehreren Autorinnen und Autoren, Vereine mit wechselnden Beitragenden und Shops mit eigenem Team. Dazu Websites, auf denen das Marketing regelmäßig selbst neue Seiten anlegt. Kennt Ihr Team WordPress und übernimmt ein Dienstleister die Wartung, spricht aus unserer Sicht wenig für einen Wechsel.
Wann ist eine statische Website die bessere Wahl?
Eine statische Website ist die bessere Wahl, wenn sich Ihre Inhalte selten ändern und ein Dienstleister oder eine technisch versierte Person sie pflegt. Ihre Stärken zählen, wenn Ladezeit, geringe Angriffsfläche und wenig laufende Wartung Vorrang haben. Typisch sind Firmenwebsites, Landingpages, Blogs und Dokumentationen.
Stärken: Weil der Server nichts mehr berechnen muss, antwortet er gleichmäßig schnell. Die fertigen Dateien lassen sich über mehrere CDNs verteilen (web.dev, Rendering on the Web). Bei echten Besuchen liegen solche Websites vorn: Im September 2026 bestanden auf dem Smartphone 71–78 % der Websites mit Astro, Hugo oder Jekyll alle drei Core Web Vitals, bei WordPress 48 % (HTTP Archive). Auf dem Webserver gibt es weder Anmeldung noch Datenbank, und dort fallen für Sie keine Updates an.
Grenzen: Jede Änderung heißt: Datei ändern, Website neu bauen, hochladen. Eine Oberfläche zum Bearbeiten gibt es nur mit einem angebundenen Redaktionssystem, etwa einem Headless-CMS, das Inhalte verwaltet, aber selbst keine Seiten ausliefert (Astro-Dokumentation, CMS). Suche, Login oder Bezahlung kommen über externe Dienste, die eine statische Website beim Bau oder direkt im Browser per JavaScript anspricht (Jamstack.org). Und statisch heißt nicht automatisch schnell: Websites mit dem Generator Gatsby luden viel JavaScript und bestanden die Core Web Vitals seltener als WordPress-Websites.
Einsatzfall: Websites von Dienstleistern, Kanzleien, Praxen und Handwerksbetrieben, deren Seiten sich einige Male im Jahr ändern. Dazu Landingpages für Kampagnen und technische Dokumentationen. Legen Sie vorher fest, ob ein Dienstleister die Änderungen übernimmt oder ob Ihr Team ein angebundenes Redaktionssystem nutzt.
Laden statische Websites schneller als WordPress?
Bei echten Besuchen meistens ja. Im September 2026 bestanden auf dem Smartphone weltweit 48 % der WordPress-Websites alle drei Core Web Vitals. Bei Websites mit den Generatoren Astro, Hugo und Jekyll waren es 71–78 %. Der Generator allein entscheidet aber nicht: Websites mit Gatsby kamen nur auf 44 %.
Die Zahlen stammen aus dem Core Web Vitals Technology Report des HTTP Archive. Er verbindet Messwerte echter Besuche in Chrome aus dem Chrome UX Report (CrUX) mit der Technik, die das HTTP Archive bei seinem monatlichen Abruf erkennt. Eine Website gilt als gut, wenn sie am 75. Perzentil der Seitenaufrufe alle drei Grenzen einhält: LCP (Ladezeit des größten Elements) bis 2,5 Sekunden, INP (Reaktion auf Eingaben) bis 200 Millisekunden und CLS (Verschieben des Layouts) bis 0,1. Fehlen INP-Daten, zählen LCP und CLS (HTTP Archive, Datenstand September 2026). Was die drei Werte im Einzelnen bedeuten, erklärt unser Beitrag Core Web Vitals.
| Kennzahl | WordPress | Astro | Hugo | Jekyll | Gatsby | alle Websites |
|---|---|---|---|---|---|---|
| Websites mit Messwerten, weltweit | 2.658.175 | 47.277 | 6.043 | 1.894 | 9.278 | 8.569.446 |
| alle drei Core Web Vitals gut, weltweit | 48,3 % | 71,1 % | 78,2 % | 77,8 % | 43,7 % | 52,8 % |
| LCP gut, weltweit | 55,4 % | 81,1 % | 87,6 % | 87,3 % | 64,4 % | 65,6 % |
| INP gut, weltweit | 90,3 % | 85,0 % | 89,6 % | 85,7 % | 76,0 % | 79,4 % |
| CLS gut, weltweit | 87,3 % | 93,6 % | 92,4 % | 94,1 % | 71,4 % | 83,4 % |
| Antwortzeit des Servers (TTFB) gut, weltweit | 22,9 % | 63,1 % | 65,5 % | 70,2 % | 52,7 % | 45,9 % |
| alle drei Core Web Vitals gut, Aufrufe aus Deutschland | 63,1 % | 82,7 % | 89,6 % | 89,2 % | 54,3 % | 69,2 % |
| Websites mit Messwerten, Deutschland | 172.438 | 3.276 | 490 | 93 | 676 | 586.975 |
Quelle: HTTP Archive, Core Web Vitals Technology Report (externe Website), · Datenstand September 2026, Smartphone
Für Deutschland zählt CrUX die Besuche von Nutzern, deren IP-Adresse in Deutschland liegt (CrUX-Methodik, Länder). Die Auswertung enthält also auch ausländische Websites. Bei Aufrufen aus Deutschland liegen alle Anteile höher, die Reihenfolge bleibt gleich (HTTP Archive, Filter Deutschland).
Der Anteil guter WordPress-Websites steigt: Ein Jahr zuvor, im September 2025, bestanden weltweit erst 45,0 % alle drei Werte, bei Aufrufen aus Deutschland 59,9 %. Websites mit Astro und Hugo legten im selben Jahr aber stärker zu, von 61,6 % auf 71,1 % und von 70,2 % auf 78,2 %. Weltweit wuchs der Abstand deshalb sogar (HTTP Archive).
Woran liegt der Abstand bei der Ladezeit?
Der Abstand entsteht vor allem, bevor die Seite lädt: Weltweit hatten nur 22,9 % der WordPress-Websites eine gute Antwortzeit des Servers, bei Astro 63,1 %. Eine vorab gebaute Datei ist sofort lieferbar, eine WordPress-Seite muss der Server oft erst erzeugen. Bei der Reaktion auf Eingaben liegt WordPress dagegen vorn.
Antwortzeit: Die Time to First Byte (TTFB) misst die Zeit bis zum ersten Byte der Antwort. Gut sind laut web.dev bis zu 0,8 Sekunden. Die TTFB zählt nicht zu den Core Web Vitals, sie geht aber den Ladewerten FCP und LCP voraus (web.dev, TTFB). Statisches Rendering erreicht laut web.dev durchgehend eine schnelle TTFB, weil der Server das HTML nicht erst erzeugen muss. Beim Rendern auf dem Server kostet genau das Zeit (web.dev, Rendering on the Web).
Cache: Laut WordPress-Handbuch ist Caching der schnellste Weg zu mehr Leistung. Caching-Plugins speichern Beiträge und Seiten als statische Dateien und liefern diese aus. Bei Seiten, die sich kaum ändern, kann das die Leistung um das Mehrhundertfache steigern (WordPress-Handbuch, Stand 14.10.2026). Wie viele WordPress-Websites einen solchen Cache nutzen, zeigen die Daten nicht.
JavaScript: Bei der Reaktion auf Eingaben hatten 90,3 % der WordPress-Websites gute Werte, bei Astro 85,0 % und bei Gatsby 76,0 %. Vorab gebaute Seiten reagieren laut web.dev nur dann schneller, wenn sie wenig JavaScript im Browser ausführen. Im Median übertrugen Websites mit Gatsby auf dem Smartphone 1,02 MB JavaScript, Websites mit WordPress 0,68 MB. Bei Astro waren es 0,41 MB, bei Hugo 0,31 MB und bei Jekyll 0,18 MB (HTTP Archive, Seitengewicht).
Was die Daten nicht zeigen: Es sind Anteile sehr unterschiedlich großer Gruppen: 2,7 Mio. WordPress-Websites gegen 47.277 mit Astro. Ob ein Wechsel eine bestimmte Website schneller macht, zeigen sie nicht. Die Technik erkennt das HTTP Archive automatisch mit dem Werkzeug Wappalyzer, seine Adressen stammen aus CrUX (HTTP Archive, FAQ). Ob eine Astro-Website ihre Seiten vorab oder beim Aufruf baut, trennt der Bericht nicht. CrUX enthält zudem nur Websites mit genug Besuchen in Chrome (CrUX-Methodik).
Ist eine statische Website sicherer als WordPress?
Eine statische Website bietet weniger Angriffsfläche, weil auf dem Webserver weder eine Anmeldung noch eine Datenbank noch Programmcode läuft. Sicher ist sie damit nicht von selbst: Zugänge und die Pakete beim Bau bleiben Ziele. Bei WordPress stecken die meisten Lücken in Plugins und Themes, kaum welche im Kern.
Zur Angriffsfläche einer Anwendung zählen laut OWASP alle Wege, auf denen Daten oder Befehle hinein- und hinausgelangen, samt dem Code, der diese Wege schützt (OWASP, Angriffsflächenanalyse). Eine statische Website ohne Formular hat davon wenige: Der Server liefert Dateien aus und nimmt keine Eingaben an. WordPress hat Benutzerkonten für die Redaktion und erzeugt Seiten mit PHP. Plugins und Themes bringen eigenen Code mit.
Wie sich das auswirkt, zeigen Zahlen von Patchstack, einem Anbieter, der Schutz für WordPress-Websites verkauft. 2025 wurden 11.334 neue Lücken rund um WordPress bekannt, 42 % mehr als 2024. 91 % steckten in Plugins und 9 % in Themes, im Kern fanden sich sechs Lücken mit geringer Priorität. Für 46 % gab es bei der Veröffentlichung noch kein Update vom Hersteller. Die am stärksten angegriffenen Lücken wurden im gewichteten Median fünf Stunden nach Bekanntwerden zum ersten Mal ausgenutzt.
Quelle: Patchstack (externe Website), · Anbieterstudie
Den Kern betreut ein Sicherheitsteam mit mehr als 50 Fachleuten. Offiziell unterstützt wird nur die neueste Version, Korrekturen bringt das Team aber auch in ältere Versionen (WordPress.org, Sicherheit). Plugins und Themes aktualisiert WordPress von selbst nur in Sonderfällen, die das Sicherheitsteam bestimmt (WordPress-Handbuch, Updates). Seit Version 5.5 können Sie automatische Updates je Erweiterung einschalten (Automatische Updates für Plugins und Themes).
Eine statische Website verschiebt die Risiken auf Zugänge und Werkzeuge. Im September 2025 befiel der Wurm „Shai-Hulud“ laut der US-Behörde für Cybersicherheit CISA über 500 Pakete im Register npm. Die Schadsoftware suchte nach Zugangsdaten, etwa für GitHub und Cloud-Dienste (CISA, 23.09.2025). Aus diesem Register laden Generatoren wie Astro ihre Bausteine (Astro-Dokumentation, Installation). Sobald ein Formular Daten annimmt, läuft auch bei einer statischen Website wieder Code auf einem Server.
Wie viel Wartung braucht welche Lösung?
WordPress braucht laufende Wartung auf dem Server: Kern, Plugins, Themes und PHP müssen aktuell bleiben, auch wenn sich am Inhalt nichts ändert. Eine statische Website hat auf dem Server nichts zu aktualisieren. Gepflegt werden der Generator und seine Pakete, spätestens vor der nächsten Änderung.
WordPress: Von Dezember 2025 bis Oktober 2026 erschienen 15 Versionen der jeweils neuesten Reihe, darunter die Hauptversionen 6.9, 7.0 und 7.1. Als sicher und aktiv gepflegt bezeichnet WordPress nur die neueste Fassung der Reihe 7.1 (WordPress.org, Versionsarchiv).
Dazu kommt PHP, die Programmiersprache, auf der WordPress beruht. Von den Installationen, die WordPress.org erfasst, liefen am 08.11.2026 mehr als 30 % mit PHP 8.1 oder älter (WordPress.org, Statistik). Für diese Versionen gibt es keine Sicherheitsupdates mehr. Für PHP 8.2, auf dem weitere 22,6 % laufen, enden sie am 31.12.2026 (php.net, unterstützte Versionen). WordPress empfiehlt PHP ab Version 8.3 (WordPress.org, Anforderungen).
Erweiterungen: Für fast die Hälfte der 2025 bekannt gewordenen Lücken gab es bei der Veröffentlichung noch kein Update (Patchstack, 25.02.2026). Legen Sie vor jedem Update eine Sicherung an, wie es auch das WordPress-Handbuch rät, und prüfen Sie danach die wichtigsten Seiten.
Statische Website: Auf dem Server läuft keine eigene Software, die veralten kann. Gepflegt wird die Werkzeugkette, mit der die Seiten entstehen. Astro etwa setzt Node.js ab Version 22.23.4 voraus (Astro-Dokumentation). Versionen von Node.js mit Langzeitunterstützung erhalten laut Projekt in der Regel 30 Monate lang Korrekturen kritischer Fehler (Node.js, Versionen). Liegen zwischen zwei Änderungen Jahre, steht vor der Änderung oft ein Wechsel auf neue Hauptversionen an.
Was kostet welche Lösung über die Laufzeit?
Die Software kostet in beiden Fällen nichts: WordPress steht unter der GPL, Astro unter der MIT-Lizenz. Kosten entstehen bei Hosting, Wartung, kostenpflichtigen Erweiterungen und Änderungen. Bei WordPress fallen sie eher laufend für die Pflege an, bei einer statischen Website eher als Arbeitszeit für jede Änderung.
Rechnen Sie beide Wege über denselben Zeitraum, etwa fünf Jahre, mit diesen Posten:
- einmalige Kosten für Erstellung oder Relaunch
- Hosting je Monat mal Laufzeit
- Wartung je Monat mal Laufzeit, bei WordPress einschließlich kostenpflichtiger Plugins und Themes
- Änderungen im Jahr mal Stunden je Änderung mal Stundensatz mal Jahre
- Dienste für Formular, Suche oder Redaktionssystem, falls Ihre statische Website sie braucht
| Posten | Statische Website | WordPress | Quellen |
|---|---|---|---|
| Software | frei, etwa Astro unter der MIT-Lizenz | frei unter der GPLv2 oder später | 27, 28 |
| Hosting | Webspace oder CDN für Dateien | Webspace mit PHP und Datenbank | 1, 3 |
| Erweiterungen | Dienste für Formular, Suche oder Redaktionssystem, falls nötig | kostenpflichtige Plugins und Themes, falls nötig | 4, 16; Einschätzung Datafalke |
| Wartung | Werkzeuge vor einer Änderung aktualisieren | Kern, Plugins, Themes und PHP laufend aktualisieren, Sicherungen anlegen | 23, 25, 26 |
| Inhalte ändern | Arbeitszeit von Fachleuten, außer mit Redaktionssystem | eigene Arbeitszeit im Blockeditor | 29, 34; Einschätzung Datafalke |
| Späterer Wechsel | neuer Generator oder neues Redaktionssystem bedeutet Umbau | ältere Page-Builder erschweren laut Web Almanac Wartung und Wechsel | 15; Einschätzung Datafalke |
Marktpreise in Euro für Hosting, Wartungsverträge und Änderungen nennt unser Kostenratgeber im Abschnitt Was kostet eine Website im laufenden Betrieb?
Ist eine statische Website besser für Google und KI-Suche?
Nicht von selbst. Suchmaschinen und KI-Crawler lesen Inhalte am verlässlichsten, wenn sie schon im HTML stehen, und das liefern WordPress und statische Generatoren gleichermaßen. Die Ladezeit kann helfen, denn Google nutzt die Core Web Vitals in seinen Rankingsystemen. Den relevantesten Inhalt zeigt Google laut eigener Aussage aber auch bei schwächerer Nutzererfahrung.
Beide Bauweisen liefern fertiges HTML: Die statische Website hat es vorab gebaut, WordPress erzeugt es auf dem Server. Schwierig wird es, wenn Inhalte erst durch JavaScript im Browser entstehen. Google hält Rendering auf dem Server oder vorab deshalb weiter für eine gute Idee: Es macht Websites schneller, und nicht alle Bots führen JavaScript aus (Google Search Central, JavaScript). In einer Messung, die der Cloud-Anbieter Vercel 2024 veröffentlichte, führte keiner der großen KI-Crawler JavaScript aus, auch nicht die von OpenAI, Anthropic und Perplexity (Vercel, 17.12.2024).
Gute Core Web Vitals garantieren keine Spitzenplätze (Google Search Central, Nutzererfahrung). Wie Sie prüfen, ob Ihre Inhalte im HTML stehen, zeigt unser Leitfaden im Abschnitt Sieht Google Inhalte, die erst JavaScript erzeugt? Welche KI-Crawler es gibt und was eine Sperre bewirkt, erklärt unser Beitrag KI-Crawler und robots.txt. Wie Sie das an Ihrer eigenen Website prüfen, zeigt unsere Prüfanleitung JavaScript und KI-Crawler.
Gibt es einen Mittelweg zwischen statischer Website und WordPress?
Ja. WordPress kann fertige Seiten aus einem Cache ausliefern oder als reines Redaktionssystem hinter einer statischen Website dienen. Umgekehrt lässt sich an eine statische Website ein Headless-CMS anbinden, in dem Ihr Team Texte bearbeitet. Diese Mischformen verbinden Vorteile beider Wege, haben aber mehr Teile, die gepflegt werden müssen.
WordPress mit Cache: Ein Caching-Plugin speichert Seiten als Dateien und liefert sie aus, ohne sie neu zu erzeugen (WordPress-Handbuch, Stand 14.10.2026). Redaktion und Plugins bleiben, die Wartung auch.
WordPress als Redaktionssystem im Hintergrund: Über seine Programmierschnittstelle, die REST-API, gibt WordPress Inhalte an andere Anwendungen weiter (WordPress REST API Handbook). Ein Generator kann daraus vorab fertige Seiten bauen. Ihre Besucher rufen dann die fertigen Dateien ab, WordPress braucht im Hintergrund aber weiter Updates. Fachleute nennen das „headless“.
Statische Website mit Headless-CMS: Das Redaktionssystem verwaltet Texte und Bilder, liefert selbst aber keine Seiten aus; der Generator holt die Inhalte ab. Die meisten solcher Systeme bieten einen visuellen Editor und Zusammenarbeit im Team (Astro-Dokumentation). Nach jeder Änderung wird die Website neu gebaut.
Suchen Sie eine Website ohne WordPress und ohne eigenen Code, kommt auch ein Baukasten infrage. Was er kostet und für wen er reicht, zeigt unser Kostenratgeber im Abschnitt Baukasten oder Webdesigner: Was ist günstiger?
Wie entscheiden Sie zwischen statischer Website und WordPress?
Entscheiden Sie anhand Ihres Alltags: Wer pflegt die Inhalte, wie oft, und wer übernimmt die Updates? Die sieben Fragen unten ordnen Ihren Fall ein. Sprechen die meisten Antworten für WordPress, ist es für Sie die bessere Wahl. Sprechen sie für eine statische Website, sparen Sie laufende Wartung und verkleinern die Angriffsfläche.
- Wer ändert die Inhalte? Mehrere Personen ohne technische Kenntnisse sprechen für WordPress. Ein Dienstleister oder eine Person, die mit Textdateien arbeitet, spricht für eine statische Website.
- Wie oft ändern Sie etwas? Mehrmals in der Woche, etwa für Beiträge oder Aktionen, spricht für WordPress. Einige Male im Jahr spricht für eine statische Website.
- Welche Funktionen brauchen Sie? Shop, Mitgliederbereich oder Buchung mit Nutzerkonten sprechen für WordPress oder eigene Software. Kontaktformular und Suche sind mit beiden Wegen möglich.
- Wer spielt Updates ein? Ist niemand fest zuständig, spricht das für eine statische Website. Mit einem Wartungsvertrag oder einer zuständigen Person passen beide.
- Wie wichtig sind Ladezeit und Angriffsfläche? Sind sie sehr wichtig, spricht das für eine statische Website. Bei WordPress helfen ein Cache, ein schlankes Theme und wenige Plugins.
- Was kann Ihr Team schon? Wer WordPress gut beherrscht, braucht einen guten Grund für den Wechsel. Ein Wechsel ist ein Relaunch, oft mit neuen Adressen.
- Was kostet es über fünf Jahre? Rechnen Sie beide Wege mit Hosting, Wartung und Änderungen über denselben Zeitraum.
Planen Sie einen Wechsel, legen Sie für jede alte Adresse eine Weiterleitung fest. Was dabei sonst zählt, zeigt unsere Checkliste für den Website-Relaunch. Die Fragen und ihre Gewichtung sind unsere Einschätzung; als Ganzes getestet hat sie niemand.
Aus der Praxis: Was die statische Bauweise für datafalke.de bedeutet
datafalke.de ist eine statische Website. Astro 7.4.4 baut die Seiten aus Markdown-Dateien, ein CDN liefert sie aus (Technik im Kolophon). Bei einer Prüfung am 09.11.2026 lud keine der 98 Seiten, die in unseren Sitemaps standen, JavaScript; das einzige Script-Element jeder Seite enthielt strukturierte Daten im Format JSON-LD. Die Sicherheitsrichtlinie, die unser Server mit jeder Seite schickt, verbietet Skripte ganz: script-src 'none'. Sie können das in den Entwicklertools Ihres Browsers nachsehen. Wie unser Kontaktformular ohne JavaScript und ohne Dienste anderer Anbieter arbeitet, zeigt unser Ratgeber Kontaktformular ohne Tracking.
Im Labor haben wir am 07.11.2026, kurz nach dem Start, sieben Seiten der ersten Fassung mit je einem Lauf gemessen. Einzelne Läufe streuen; unser Messprotokoll wird regelmäßige Werte als Median aus fünf Läufen ausweisen.
| Kennzahl | Wert auf den sieben Seiten |
|---|---|
| Lighthouse-Wert Leistung | 99–100 |
| Lighthouse-Werte Barrierefreiheit, Best Practices und SEO | je 100 |
| LCP im Labor | 1,1–1,7 s |
| CLS | 0–0,017 |
| Total Blocking Time | 0 ms |
| Anfragen je Seite | 7–8, alle an datafalke.de |
| übertragene Daten je Seite | 99–133 kB, davon 69–87 kB Schriften |
| geladene Skripte | 0 |
Messung vom · Lighthouse 12.6.1 in Chrome 156, mobil, simulierte Drosselung, je ein Lauf auf sieben Seiten
Die Bauweise hat ihren Preis. Jede Änderung, auch ein Tippfehler, heißt bei uns: Datei ändern, neu bauen, hochladen. Eine Oberfläche zum Bearbeiten haben wir nicht. Für das Kontaktformular läuft ein kleines Programm auf den Servern unseres Hosters, das die Anfrage annimmt (Kolophon). Die Werkzeuge zum Bauen halten wir selbst aktuell.
Felddaten gibt es für datafalke.de noch nicht. Die Website ist seit dem 07.11.2026 online. Der Chrome UX Report nimmt Websites erst ab einer Zahl von Besuchen auf, die Google nicht nennt (CrUX-Methodik). Dass die Bauweise uns Besuche oder Anfragen bringt, behaupten wir hier nicht; ob sie das tut, zeigt erst das Messprotokoll.
So messen Sie nach: Geben Sie eine unserer Adressen bei PageSpeed Insights ein oder starten Sie Lighthouse in den Entwicklertools von Chrome. Ihre Zeiten weichen ab, weil Gerät, Netz und Version andere sind. Zahl und Größe der Anfragen sollten nur wenig abweichen, solange wir die Seiten nicht ändern. Wie Sie eigene Lighthouse-Läufe vor und nach einer Änderung vergleichbar machen, zeigt unser Ratgeber Ladezeit messen.