Static Publisher pour WordPress
Gardez WordPress pour l’édition. Déplacez la livraison publique vers AWS.
Rendez le frontend WordPress approuvé, déployez-le vers Amazon S3 et CloudFront et gardez les capacités dynamiques sur des chemins navigateur ou services AWS explicites au lieu d’exposer le CMS pour chaque requête de page publique.
De WordPress à l’edge
Un pipeline de publication, pas seulement un fichier exporté
WordPress reste la source et la control plane. Un publishing engine externe gère rendu, asset discovery, réécriture des URLs, deployment et refresh du cache.
Frontière runtime
Static Publisher génère la couche de pages. Login, forms, AI, routes protégées et APIs applicatives restent des services séparés lorsque le site en a besoin.
Pourquoi Static Publisher
Séparez le système éditorial du chemin de livraison public
Un site production statique a besoin d’un mécanisme de release répétable et d’une réponse claire sur ce qui reste dans WordPress et ce qui s’exécute ailleurs.
01
Publication render-aware
Capturez le frontend comme le navigateur l’utilise, y compris les assets responsive et demandés dynamiquement nécessaires à l’expérience rendue.
02
Livraison S3 et CloudFront
Déployez le output généré vers du stockage AWS contrôlé par le client et l’edge delivery, sans exiger l’origin WordPress pour les pages publiques.
03
Releases incrémentales et ciblées
Les workflows Professional et Agency peuvent utiliser une baseline vérifiée et les changements éditoriaux journaled pour mettre à jour pages, listings, archives et sitemaps affectés.
04
Origin d’édition privé
Gardez la source WordPress privée, staging ou interne, et exposez uniquement le frontend généré.
Capacités
Exploitez WordPress statique comme un pipeline de releases
Crawl complet et publication
Construisez un artifact statique complet depuis le frontend WordPress rendu et déployez-le sans remplacer Gutenberg, Elementor, médias ou travail éditorial normal.
Réécriture consciente de la cible
Réécrivez les URLs source pour la cible publique sélectionnée afin que les références staging ou private origin ne fuient pas vers navigation et assets production.
Deployment profiles et visibilité
Gardez séparés les paramètres propres à chaque cible et conservez le feedback des jobs pour des workflows agence et opérationnels répétables.
Les fonctions dynamiques restent explicites
Associez la couche de pages statiques à Gatey, Flow, AI-Kit, Static Site Guardian ou des APIs custom lorsque identité, forms, AI ou ressources protégées doivent rester live.
Parcours de publication
De l’éditeur WordPress à l’edge AWS
Le CMS source, le publishing engine, la couche de livraison publique et les services dynamiques optionnels restent des responsabilités séparées.
WordPress privé / staging
→ Static Publisher
├→ rendu + asset discovery
├→ réécriture des URLs cible
├→ build full / incremental release
└→ deploy + invalidation
↓
Amazon S3 → CloudFront
├→ pages statiques publiques
└→ routes statiques protégées optionnelles
Besoins dynamiques
→ Gatey / Flow / AI-Kit / APIs protégées
WordPress reste la source éditoriale. L’environnement public S3/CloudFront et les runtime services optionnels appartiennent à l’architecture AWS et applicative choisie par le client.
Adéquation
Comparez le modèle de publication, pas seulement le bouton d’export
| Capacité | Static Publisher | WP2Static | Simply Static / Pro |
|---|---|---|---|
| Positionnement principal | Publication statique AWS-native pour WordPress | Exporteur HTML statique classique | Générateur WordPress statique mature |
| Rôle de WordPress | Environnement d’édition et source | Source du output statique | Source du output statique |
| Runtime cible | AWS appartenant au client | Cibles d’hébergement statique | Plusieurs hosts ou Studio géré |
| Parcours AWS S3 / CloudFront | Modèle central de delivery | Disponible via setup/add-ons | Disponible en Pro |
| Asset discovery * | Capture les assets nécessaires à la page rendue, y compris srcset, picture fallbacks et assets dynamiques | Principalement basé sur export/crawler | Génération statique + optimisation Pro |
| Réécriture des URLs | Rewrites target-origin et par profile | Besoin central de l’export | Fonctions de rewrite et hide-WP |
| Automatisation portable | Publishing engine orienté queue/runtime | Usage orienté développeurs disponible | WP-CLI et workflows en Pro |
| Publication incrémentale et ciblée | Professional/Agency : jobs incrémentaux, content sync journal-driven ciblé et deploy diff | Dépend du setup/version | Changes Only, Single Push et Builds en Pro |
| Plusieurs deployment profiles | Pro : un crawl, plusieurs targets | Pas le positionnement principal | Plusieurs targets pris en charge |
| Routes statiques protégées | Gatey + Static Guardian dans AWS client | Pas core | Pas le modèle principal |
| Workflows backend | Flow + backends serverless AWS | Hors scope | Intégrations forms/search/comments |
| Meilleure adéquation | Agences standardisant delivery WP + AWS | Développeurs ayant besoin d’un export statique | Équipes voulant un large deployment WordPress statique |
* Exportez ce que la page utilise réellement
De nombreux workflows d’export statique commencent par scanner des fichiers et suivre des références. Cela peut fonctionner pour des sites simples, mais les pages WordPress modernes dépendent souvent d’images responsive, variantes srcset, picture fallbacks, scripts de page builders, assets lazy-loaded et comportements frontend visibles seulement après le rendu.
Static Publisher suit plutôt la page rendue. Il capture les assets dont le navigateur a réellement besoin pour afficher correctement l’expérience, tout en préservant les liens et références nécessaires à la navigation et à la delivery statique.
Pour une comparaison ciblée des exporters, consultez Static Publisher vs Simply Static. Si le choix architectural oppose livraison statique et frontend construit séparément, consultez Static WordPress vs Headless WordPress.
Questions d’évaluation
Commencez par le problème de delivery
Comment garder WordPress pour l’édition sans l’exposer publiquement ?
Utilisez un modèle avec origin WordPress privé et livraison statique publique. Static Publisher est le mécanisme de release derrière cette séparation.
WordPress statique peut-il garder login, formulaires et AI ?
Oui, si ces fonctions utilisent leurs propres chemins browser-to-service. Login, forms, discussions et AI peuvent continuer sur des runtimes séparés après publication.
Cela aide-t-il lors des pics de trafic ?
La livraison statique retire les requêtes publiques cacheables du chemin live PHP/MySQL. La capacité réelle dépend toujours de l’architecture complète.
Comment protéger certaines routes statiques ?
Gatey peut fournir l’identité Cognito et Static Site Guardian peut appliquer des routes protégées CloudFront via signed cookies.
Commencez par la frontière de delivery
Gardez le CMS pour l’édition et retirez-le de la livraison publique des pages
Utilisez le guide du problème WordPress statique pour la séparation globale, puis l’architecture runtime lorsque le site publié a aussi besoin d’identité, forms ou AI live.