Static Publisher + WordPress
WordPress zum Bearbeiten behalten, ohne WordPress öffentlich erreichbar zu machen
Redakteure können WordPress, Gutenberg, Vorschauen und den Veröffentlichungsablauf behalten, während öffentliche Besucher gerenderte Dateien aus S3 und CloudFront statt einer öffentlich erreichbaren WordPress-/PHP-Laufzeit erhalten.
Kurz gesagt Nutzen Sie WordPress als private Redaktionsschicht, rendern Sie die Website mit Static Publisher und liefern Sie die öffentliche Ausgabe aus S3 und CloudFront aus. WordPress bleibt das CMS, muss sich aber nicht mehr im öffentlichen Anfragepfad befinden.
Das Problem der Produktionsgrenze
Teams möchten häufig WordPress zur Bearbeitung, aber nicht zur öffentlichen Seitenauslieferung nutzen
CMS und öffentliche Laufzeit müssen nicht dasselbe System sein. Ihre Trennung verändert, welche Komponenten bei einer normalen Besucheranfrage erreichbar sein müssen.
Exposition
Die öffentliche Website übernimmt die Angriffs- und Betriebsfläche der WordPress-Laufzeit
Wenn jeder Seitenaufruf WordPress erreicht, umfasst der öffentliche Auslieferungspfad auch PHP, Datenbank, wp-login, Plugin-Code und die betrieblichen Abhängigkeiten dieses Stacks.
Datenverkehr
Anonymer Datenverkehr hängt weiterhin von der Kapazität des Ursprungs ab
Caching hilft, doch eine traditionelle Einrichtung benötigt weiterhin einen WordPress-Ursprung, der als Teil der öffentlichen Auslieferungsarchitektur ausgelegt und betrieben wird.
Migrationsrisiko
Der Abschied von WordPress bedeutet oft einen Neuaufbau des Redaktionsablaufs
Ein Headless-Neuaufbau kann WordPress aus der Seitenauslieferung entfernen, aber zugleich eine neue Frontend-Anwendung, ein neues Vorschaumodell und einen neuen Inhaltsablauf einführen, den die Redakteure nicht ersetzen wollten.
Entscheidung über die Grenze Behalten Sie WordPress dort, wo es besonders stark ist – bei Inhaltserstellung und Content-Management – und verlagern Sie die öffentliche Seitenauslieferung nur, wenn diese Trennung einen konkreten betrieblichen Nutzen schafft.
Veröffentlichungspfad
Private WordPress-Redaktion, gerendertes Artefakt, öffentliche statische Auslieferung
Static Publisher behandelt WordPress als Quelle und die gerenderte Website als bereitstellbares Artefakt. Ausgewählte dynamische Funktionen können als getrennte Interaktionen vom Browser zu APIs bestehen bleiben.
Privates / Staging-WordPress
|
v
Redakteure nutzen Gutenberg und normale WordPress-Abläufe
|
v
Externer Static-Publisher-Runner
| Crawling / Rendering / Umschreiben / Prüfen
v
S3-Ursprung + CloudFront-Verteilung
|
v
Öffentlicher Besucher erhält statisches HTML und Assets
|
+--> optionale Identität mit Gatey
+--> optionale Interaktionen mit Flow
+--> optionale Suche / KI mit AI-Kit
+--> konfigurierte APIs
Funktionsgrenze Statische Veröffentlichung entfernt WordPress aus dem öffentlichen Seiten-Rendering. Formulare, Authentifizierung, Kommentare, Workflows, Suche oder KI werden dadurch nicht automatisch ersetzt; verwendet die Website solche Funktionen, benötigen sie einen ausdrücklich definierten Laufzeitpfad.
Implementierung
Verlagern Sie die Seitenauslieferung, ohne das CMS neu aufzubauen
Beginnen Sie mit der öffentlichen Auslieferungsgrenze und ergänzen Sie anschließend nur die Laufzeitdienste, die die statische Website tatsächlich benötigt.
- Behalten Sie WordPress als Redaktionsursprung — Nutzen Sie das bestehende WordPress-Inhaltsmodell, Gutenberg-Blöcke, Vorschauen und den redaktionellen Ablauf als Quelle der öffentlichen Website.
- Konfigurieren Sie Static Publisher — Richten Sie Ursprung, öffentliches Ziel, URL-Umschreibungen, S3-Bucket, CloudFront-Verteilung und Bereitstellungsprofil für die Umgebung ein.
- Rendern und prüfen Sie das öffentliche Artefakt — Führen Sie zuerst eine vollständige Veröffentlichung aus, prüfen Sie die erzeugte Website sowie interne Links und Assets und verifizieren Sie das öffentliche Ziel, bevor Sie inkrementelle oder Content-Sync-Abläufe verwenden.
- Ergänzen Sie dynamische Funktionen separat — Nutzen Sie Gatey, Flow, AI-Kit oder andere APIs nur für Funktionen, die nach der Umstellung auf eine statische Website weiterhin Laufzeitstatus oder authentifizierte Aktionen benötigen.
Wann privates WordPress mit öffentlicher statischer Auslieferung geeignet ist
Gut geeignet
Nutzen Sie dieses Modell, wenn WordPress als CMS wertvoll ist, aber nicht als öffentliche Laufzeit
- Die meisten öffentlichen Seitenaufrufe sind anonym und cachefähig, etwa bei Marketing-, Dokumentations-, redaktionellen oder Agentur-Websites.
- Redakteure sollen WordPress behalten, während die öffentliche Abhängigkeit vom Seiten-Rendering mit PHP und MySQL sinkt.
- Das Projekt kann verbleibende dynamische Funktionen in browserseitige Identität, APIs, Workflows oder KI-Dienste trennen.
Dynamisches WordPress beibehalten
Eine normale WordPress-Laufzeit kann einfacher sein, wenn
- Die meisten öffentlichen Seiten bei jeder Anfrage serverseitige Personalisierung oder Datenbankstatus benötigen.
- Die Website stark von Laufzeitfunktionen abhängt, die nicht sauber von der WordPress-Anfrageverarbeitung getrennt werden können.
- Das Team keinen Ablauf für statische Veröffentlichung und Bereitstellung betreiben möchte.
Fragen von Käufern
FAQ zu privatem WordPress und statischer Auslieferung
Wie kann ich WordPress nutzen, ohne es öffentlich erreichbar zu machen?
Behalten Sie WordPress zur Bearbeitung auf einem privaten oder Staging-Ursprung und veröffentlichen Sie anschließend die gerenderte Ausgabe in S3 und CloudFront. Öffentliche Besucher erhalten die statische Website, statt sich mit der WordPress-Laufzeit zu verbinden.
Kann WordPress privat bleiben, während die Website öffentlich ist?
Ja. WordPress kann CMS und Redaktionsumgebung bleiben, während die öffentliche Website als separat bereitgestelltes statisches Artefakt betrieben wird.
Verlieren statische WordPress-Websites alle dynamischen Funktionen?
Nein. Statische Seitenauslieferung und dynamische Funktionen sind getrennte Entscheidungen. Anmeldung, Formulare, Workflows, Suche und KI können bei Bedarf browserseitige Komponenten und konfigurierte APIs verwenden.
Ist das dasselbe wie Headless WordPress?
Nein. Eine Headless-Einrichtung führt üblicherweise eine separate Frontend-Anwendung ein. Static Publisher rendert das bestehende WordPress-Frontend, sodass Vorlagen, Blöcke und redaktionelle Abläufe von WordPress erhalten bleiben können.
WP Suite Static Publisher
Behalten Sie WordPress als CMS, nicht als öffentlichen Anfragepfad
Veröffentlichen Sie die gerenderte Website in S3 und CloudFront, während Redakteure weiterhin in WordPress arbeiten.