Static Publisher für WordPress
Behalten Sie WordPress für die Redaktion. Verlagern Sie die öffentliche Auslieferung zu AWS.
Veröffentlichen Sie Ihre WordPress-Website auf Amazon S3 und CloudFront in Ihrem eigenen AWS-Konto. Nach der Übergabe halten geplante content-sync-Aufgaben die Live-Website bei Inhaltsänderungen aktuell – schneller als ein erneuter Export der gesamten Website. Behalten Sie die vertraute Bearbeitung bei; Anmeldung, Formulare und KI bleiben mit ihren eigenen Diensten verbunden.
Von WordPress an den Netzwerkrand
Ein Veröffentlichungsprozess, der über eine Exportdatei hinausgeht
Verwalten Sie Inhalte und Veröffentlichungseinstellungen in WordPress. Eine externe Veröffentlichungssoftware rendert Seiten, sammelt ihre Ressourcen, schreibt URLs um, stellt das Ergebnis bereit und aktualisiert den Cache.
Statische Seiten mit aktiven Funktionen
Static Publisher erzeugt die Seitenebene. Anmeldung, Formulare, KI, geschützte Pfade und Anwendungs-APIs bleiben eigenständige Dienste, wenn die Website sie benötigt.
Warum Static Publisher?
Trennen Sie das Redaktionssystem von der öffentlichen Auslieferung
Bearbeiten Sie Inhalte weiterhin in WordPress und veröffentlichen Sie Änderungen in einem wiederholbaren Prozess. Besucher erhalten Seiten von S3 und CloudFront; interaktive Funktionen verbinden sich mit ihren eigenen Diensten.
01
Veröffentlichung auf Basis gerenderter Seiten
Erfassen Sie das Frontend so, wie der Browser es nutzt, einschließlich responsiver und dynamisch angeforderter Ressourcen, die für die gerenderte Darstellung benötigt werden.
02
Auslieferung über S3 und CloudFront
Stellen Sie das erzeugte Ergebnis über AWS-Speicher und Edge-Auslieferung unter Kundenkontrolle bereit. Öffentliche Seitenaufrufe benötigen den WordPress-Ursprung dadurch nicht.
03
Inkrementelle Veröffentlichung und geplante Inhaltssynchronisierung
Nach Veröffentlichung und Übergabe der Website kann der Modus content-sync als geplante Aufgabe spätere Inhaltsänderungen veröffentlichen. Er nutzt den geprüften Ausgangsstand und protokollierte Änderungen, um betroffene Seiten, Übersichten, Archive und Sitemaps zu aktualisieren. Das ist schneller, als für jede Inhaltsänderung die gesamte Website erneut zu exportieren, und steht für Professional- und Agenturabläufe zur Verfügung.
04
Privates Redaktionssystem
Betreiben Sie die WordPress-Quelle privat, als Staging-System oder intern. Öffentlich zugänglich ist nur das erzeugte Frontend.
Funktionen
Veröffentlichen Sie die gesamte Website oder aktualisieren Sie gezielt Änderungen
Vollständiger Website-Crawl und Veröffentlichung
Erstellen Sie aus dem gerenderten WordPress-Frontend ein vollständiges statisches Ergebnis und stellen Sie es bereit, ohne Gutenberg, Elementor, Medienverwaltung oder gewohnte Redaktionsarbeit zu ersetzen.
Zielabhängige URL-Anpassung
Schreiben Sie Quell-URLs für das gewählte öffentliche Ziel um, damit Verweise auf Staging-Systeme oder private Ursprünge nicht in Navigation und Ressourcen der Produktionswebsite gelangen.
Bereitstellungsprofile und Nachvollziehbarkeit
Verwalten Sie Einstellungen getrennt nach Ziel und behalten Sie Rückmeldungen zu Aufträgen für wiederholbare Agentur- und Betriebsabläufe.
Anmeldung, Formulare und KI weiter nutzen
Kombinieren Sie die statische Seitenebene mit Gatey, Flow, AI-Kit, Static Site Guardian oder eigenen APIs, wenn Identität, Formulare, KI oder geschützte Ressourcen aktiv bleiben müssen.
Veröffentlichungsweg
Vom WordPress-Editor zur AWS-Edge-Auslieferung
Quell-CMS, Veröffentlichungssoftware, öffentliche Auslieferung und optionale dynamische Dienste bleiben getrennte Zuständigkeiten.
Privates / Staging-WordPress
→ Static Publisher
├→ rendern + Ressourcen ermitteln
├→ Ziel-URLs umschreiben
├→ vollständige / inkrementelle Veröffentlichung erstellen
└→ bereitstellen + Cache invalidieren
↓
Amazon S3 → CloudFront
├→ öffentliche statische Seiten
└→ optionale geschützte statische Pfade
Dynamische Anforderungen
→ Gatey / Flow / AI-Kit / geschützte APIs
WordPress bleibt die redaktionelle Quelle. Die öffentliche S3-/CloudFront-Umgebung und optionale Laufzeitdienste gehören zur gewählten AWS- und Anwendungsarchitektur des Kunden.
Optionale Lambda-Verarbeitung
Veröffentlichungsarbeit delegieren, statt einen Exporter-Server für Spitzenlast zu dimensionieren
Der externe Exporter kann die Koordination übernehmen, während Seitenrendering, Asset-Abruf, HTML-Umschreibung und Deployment in begrenzten Lambda-Stapeln laufen. Dadurch bleibt die Veröffentlichungsarbeit außerhalb von WordPress/PHP und rechenintensive Exporter-Schritte müssen nicht auf einem einzigen dauerhaft laufenden Server stattfinden.
WordPress-Quelle
→ Exporter-Koordination
├→ Render-Stapel → Lambda + Chromium
├→ Asset-Stapel → Lambda
├→ Rewrite-Stapel → Lambda
└→ Deployment-Stapel → Lambda
↓
S3-Arbeitsbereich → Ziel-S3 → CloudFrontKapazitätsgrenze Das Seitenrendering hängt weiterhin davon ab, wie schnell die WordPress-Quelle die angeforderten Seiten liefern kann. Die Koordination verwaltet Warteschlange, Sicherheits- und inkrementelle Entscheidungen, Wiederholungen, Protokolle, Invalidierung und Endstatus. Bei vollständiger Delegation bleiben HTML und Assets im S3-Arbeitsbereich und werden nach der Umschreibung direkt S3-zu-S3 bereitgestellt. Lambda-Worker-Architektur ansehen.
Eignung
Vergleichen Sie das Veröffentlichungsmodell einschließlich der Abläufe nach dem Export
| Funktion | Static Publisher | WP2Static | Simply Static / Pro |
|---|---|---|---|
| Schwerpunkt | AWS-native statische Veröffentlichung für WordPress | Klassischer Export statischer HTML-Dateien | Ausgereifter Generator für statisches WordPress |
| Rolle von WordPress | Redaktions- und Quellumgebung | Quelle für statische Ausgabe | Quelle für statische Ausgabe |
| Ziellaufzeit | AWS im Besitz des Kunden | Statische Hostingziele | Mehrere Hostingdienste oder verwaltetes Studio |
| AWS-S3-/CloudFront-Anbindung | Zentrales Auslieferungsmodell | Über Einrichtung / Erweiterungen verfügbar | In Pro verfügbar |
| Ermittlung von Ressourcen * | Erfasst die von der gerenderten Seite benötigten Ressourcen, einschließlich srcset, picture-Ausweichvarianten und dynamischer Ressourcen | Überwiegend export- / crawlerbasiert | Statische Generierung + Pro-Optimierung |
| URL-Umschreibung | Anpassungen für Zielursprung und Bereitstellungsprofil | Zentrale Exportfunktion | Umschreibungs- und WordPress-Verbergungsfunktionen |
| Portierbare Automatisierung | Veröffentlichungssoftware mit Warteschlangen- und Laufzeitausrichtung | Entwicklerorientierte Nutzung möglich | WP-CLI und Arbeitsabläufe in Pro |
| Inkrementelle und gezielte Veröffentlichung | Professional / Agentur: inkrementelle Veröffentlichung, geplante content-sync-Aufgaben für Änderungen an einer bestehenden Live-Website und Uploads nur geänderter Dateien | Abhängig von Einrichtung / Version | Changes Only, Single Push und Builds in Pro |
| Mehrere Bereitstellungsprofile | Pro: ein Crawl, mehrere Ziele | Kein zentraler Schwerpunkt | Mehrere Ziele unterstützt |
| Geschützte statische Routen | Gatey + Static Guardian im AWS-Konto des Kunden | Keine Kernfunktion | Nicht das zentrale Modell |
| Backend-Arbeitsabläufe | Flow + serverlose AWS-Backends | Außerhalb des Funktionsumfangs | Integrationen für Formulare / Suche / Kommentare |
| Besonders geeignet für | Agenturen, die WordPress- und AWS-Auslieferung standardisieren | Entwickler mit Bedarf an statischem Export | Teams mit Bedarf an vielseitiger statischer WordPress-Bereitstellung |
* Exportieren, was die Seite tatsächlich nutzt
Viele statische Exportabläufe beginnen damit, Dateien zu durchsuchen und Verweisen zu folgen. Für einfache Websites kann das ausreichen. Moderne WordPress-Seiten nutzen jedoch häufig responsive Bilder, srcset-Varianten, picture-Ausweichvarianten, Seitenerstellungs-Skripte, verzögert geladene Ressourcen und Frontend-Verhalten, das erst nach dem Rendern sichtbar wird.
Static Publisher orientiert sich an der gerenderten Seite. Es erfasst die Ressourcen, die der Browser tatsächlich für die korrekte Darstellung benötigt, und erhält zugleich die für Navigation und statische Auslieferung erforderlichen Links und Verweise.
Einen gezielten Exportervergleich finden Sie unter Static Publisher im Vergleich zu Simply Static. Wenn Sie zwischen statischer Auslieferung und einem separat entwickelten Frontend entscheiden, lesen Sie Statisches WordPress im Vergleich zu Headless WordPress.
Häufige Fragen
Static Publisher in Ihrem Projekt einsetzen
Wie behalte ich WordPress für die Redaktion, ohne es öffentlich zugänglich zu machen?
Nutzen Sie den Leitfaden zu privatem WordPress mit öffentlicher statischer Auslieferung. Static Publisher übernimmt die Veröffentlichung zwischen redaktioneller Quelle und öffentlicher Auslieferung.
Kann statisches WordPress Anmeldung, Formulare und KI beibehalten?
Ja, wenn diese Funktionen eigene Verbindungen vom Browser zu ihren Diensten nutzen. Der Leitfaden zu statischem WordPress mit dynamischen Funktionen ordnet Anmeldung, Formulare, Diskussionen und KI den Laufzeiten zu, die nach der Veröffentlichung weiterarbeiten.
Hilft dies bei Lastspitzen?
Statische Auslieferung entlastet den laufenden PHP-/MySQL-Pfad von cachefähigen öffentlichen Seitenanfragen. Der Leitfaden zur Auslieferung bei Lastspitzen erläutert das Problem. Die Kapazität hängt weiterhin von der gesamten Architektur ab.
Wie schütze ich ausgewählte statische Pfade?
Nutzen Sie Gatey für Cognito-gestützte Identität und Static Site Guardian für durch CloudFront geschützte Pfade. Der Leitfaden zu sicherem statischem WordPress beschreibt die Anmeldung; die Architektur mit signierten Cookies erläutert die Durchsetzung bei der Auslieferung.
In WordPress bearbeiten. Über AWS ausliefern.
Veröffentlichen Sie in Ihrem eigenen AWS-Konto
Behalten Sie WordPress als Inhaltsquelle, veröffentlichen Sie die Website auf S3 und CloudFront und planen Sie anschließend content-sync-Aufgaben für laufende Inhaltsänderungen. Ergänzen Sie Gatey, Flow, AI-Kit und Static Site Guardian, wenn Ihre Website Anmeldung, Formulare, KI oder geschützte Seiten benötigt.