Static Publisher pour WordPress
Conservez WordPress pour la rédaction. Confiez la diffusion publique à AWS.
Publiez votre site WordPress sur Amazon S3 et CloudFront dans votre propre compte AWS. Après la livraison, des tâches content-sync planifiées actualisent les contenus du site en ligne plus rapidement qu’un nouvel export complet. Conservez votre éditeur habituel, avec la connexion, les formulaires et l’IA reliés à leurs propres services.
De WordPress au réseau de diffusion
Une chaîne de publication complète, au-delà du fichier d’export
Gérez les contenus et les paramètres de publication dans WordPress. Un moteur de publication externe effectue le rendu des pages, collecte leurs ressources, réécrit les URL, déploie le résultat et actualise le cache.
Des pages statiques avec des fonctionnalités actives
Static Publisher génère les pages. La connexion, les formulaires, l’IA, les chemins protégés et les API applicatives restent des services distincts lorsque le site en a besoin.
Pourquoi Static Publisher
Séparez le système éditorial de la diffusion publique
Continuez à rédiger dans WordPress et publiez les changements selon une procédure reproductible. Les visiteurs reçoivent les pages depuis S3 et CloudFront, tandis que les fonctionnalités interactives communiquent avec leurs propres services.
01
Publication à partir du rendu
Capturez l’interface telle que le navigateur l’utilise, y compris les ressources adaptatives et demandées dynamiquement qui sont nécessaires à son affichage.
02
Diffusion par S3 et CloudFront
Déployez le résultat généré vers le stockage AWS et le réseau de diffusion contrôlés par le client, sans solliciter le WordPress d’origine pour les consultations publiques.
03
Publication incrémentale et synchronisation planifiée des contenus
Une fois le site publié et livré, le mode content-sync peut s’exécuter en tâche planifiée pour publier les modifications de contenus ultérieures. Il s’appuie sur la version de référence vérifiée et les changements enregistrés pour actualiser les pages, listes, archives et plans de site concernés. Cette approche est plus rapide qu’un nouvel export complet à chaque modification de contenu ; elle est disponible avec les offres Professional et Agency.
04
Un environnement de rédaction privé
Conservez le WordPress source dans un environnement privé, de préproduction ou interne, et n’exposez publiquement que l’interface générée.
Fonctionnalités
Publiez le site entier ou actualisez ce qui a changé
Exploration et publication du site entier
Produisez une version statique complète à partir du rendu de l’interface WordPress et déployez-la sans remplacer Gutenberg, Elementor, les médias ni le travail éditorial habituel.
Réécriture selon la destination
Réécrivez les URL source pour la destination publique choisie, afin que les références à la préproduction ou à une origine privée n’apparaissent pas dans la navigation et les ressources de production.
Profils de déploiement et suivi
Séparez les paramètres propres à chaque destination et conservez les résultats des tâches pour des procédures d’agence et d’exploitation reproductibles.
Conservez la connexion, les formulaires et l’IA
Associez les pages statiques à Gatey, Flow, AI-Kit, Static Site Guardian ou à des API personnalisées lorsque l’identité, les formulaires, l’IA ou les ressources protégées doivent rester actifs.
Parcours de publication
De l’éditeur WordPress au réseau de diffusion AWS
Le CMS source, le moteur de publication, la diffusion publique et les services dynamiques facultatifs conservent des responsabilités distinctes.
WordPress privé / de préproduction
→ Static Publisher
├→ rendu + découverte des ressources
├→ réécriture des URL de destination
├→ création d’une version complète / incrémentale
└→ déploiement + invalidation du cache
↓
Amazon S3 → CloudFront
├→ pages statiques publiques
└→ chemins statiques protégés facultatifs
Besoins dynamiques
→ Gatey / Flow / AI-Kit / API protégées
WordPress reste la source éditoriale. L’environnement public S3/CloudFront et les services d’exécution facultatifs relèvent du compte AWS du client et de l’architecture applicative choisis.
Traitement Lambda facultatif
Déléguer le travail de publication plutôt que dimensionner un seul serveur pour le pic
L’exporteur externe peut rester le coordinateur tandis que le rendu des pages, le téléchargement des ressources, la réécriture HTML et le déploiement s’exécutent en lots Lambda bornés. La charge de publication reste ainsi hors de WordPress/PHP et les traitements lourds ne dépendent pas d’un seul serveur permanent.
WordPress source
→ coordination de l’exporteur
├→ lots de pages → Lambda + Chromium
├→ lots de ressources → Lambda
├→ lots de réécriture → Lambda
└→ lots de déploiement → Lambda
↓
espace S3 → S3 cible → CloudFrontLimite de capacité Le rendu dépend toujours de la vitesse à laquelle l’origine WordPress peut servir les pages demandées. Le coordinateur conserve la file, les décisions de sécurité et incrémentales, les reprises, les journaux, l’invalidation et l’état final. En délégation complète, HTML et ressources restent dans l’espace S3 pour la réécriture puis un déploiement direct S3→S3. Voir l’architecture Lambda.
Adéquation à votre projet
Comparez le modèle de publication, au-delà du bouton d’export
| Fonctionnalité | Static Publisher | WP2Static | Simply Static / Pro |
|---|---|---|---|
| Positionnement principal | Publication statique WordPress native pour AWS | Exportateur HTML statique classique | Générateur WordPress statique établi |
| Rôle de WordPress | Éditeur et environnement source | Source du résultat statique | Source du résultat statique |
| Environnement d’exécution cible | AWS appartenant au client | Hébergements statiques | Plusieurs hébergeurs ou Studio géré |
| Publication sur AWS S3 / CloudFront | Modèle de diffusion central | Disponible par configuration / modules complémentaires | Disponible avec Pro |
| Découverte des ressources * | Capture les ressources nécessaires au rendu de la page, dont les variantes srcset, les solutions de repli picture et les ressources dynamiques | Principalement fondée sur l’export et l’exploration | Génération statique + optimisation Pro |
| Réécriture des URL | Réécriture selon l’origine cible et le profil | Fonction centrale de l’export | Fonctions de réécriture et de masquage de WordPress |
| Automatisation portable | Moteur de publication organisé autour des files de tâches et de leur exécution | Usage orienté développeurs possible | WP-CLI et processus automatisés avec Pro |
| Publication incrémentale et ciblée | Professional/Agency : publication incrémentale, tâches content-sync planifiées pour les changements d’un site déjà en ligne et transfert limité aux fichiers modifiés | Selon la configuration / la version | Changes Only, Single Push et Builds avec Pro |
| Plusieurs profils de déploiement | Pro : une exploration, plusieurs destinations | Ce n’est pas le positionnement principal | Plusieurs destinations prises en charge |
| Routes statiques protégées | Gatey + Static Guardian sur le compte AWS du client | Hors fonctions centrales | Ce n’est pas le modèle principal |
| Processus backend | Flow + backends sans serveur AWS | Hors périmètre | Intégrations de formulaires / recherche / commentaires |
| Cas d’usage privilégié | Agences standardisant les livraisons WordPress + AWS | Développeurs ayant besoin d’un export statique | Équipes recherchant un déploiement WordPress statique polyvalent |
* Exportez ce que la page utilise réellement
De nombreuses procédures d’export statique commencent par analyser les fichiers et suivre leurs références. Cela peut suffire pour des sites simples, mais les pages WordPress modernes utilisent souvent des images adaptatives, des variantes srcset, des solutions de repli picture, des scripts de constructeurs de pages, des ressources chargées à la demande et des comportements qui ne se révèlent qu’après le rendu.
Static Publisher suit le rendu de la page. Il capture les ressources dont le navigateur a réellement besoin pour l’afficher correctement, tout en conservant les liens et les références nécessaires à la navigation et à la diffusion statique.
Pour une comparaison ciblée des outils d’export, consultez Static Publisher face à Simply Static. Si le choix architectural porte sur une diffusion statique ou une interface développée séparément, consultez WordPress statique ou WordPress découplé.
Questions fréquentes
Utiliser Static Publisher dans votre projet
Comment conserver WordPress pour la rédaction sans l’exposer publiquement ?
Consultez le guide de WordPress privé avec diffusion statique publique. Static Publisher assure la publication entre l’environnement éditorial d’origine et la diffusion publique.
Un WordPress statique peut-il conserver la connexion, les formulaires et l’IA ?
Oui, lorsque ces fonctionnalités communiquent directement entre le navigateur et leurs services. Le guide de WordPress statique avec fonctions dynamiques associe la connexion, les formulaires, les discussions et l’IA aux services qui continuent à fonctionner après la publication.
Cette approche peut-elle aider à absorber les pics de trafic ?
La diffusion statique soustrait les requêtes publiques de pages pouvant être mises en cache au traitement PHP/MySQL en direct. Consultez le guide de diffusion lors des pics de trafic pour comprendre le problème ; la capacité dépend toujours de l’architecture complète.
Comment protéger certains chemins statiques ?
Utilisez Gatey pour l’identité gérée par Cognito et Static Site Guardian pour les chemins protégés dont CloudFront contrôle l’accès. Le guide de WordPress statique sécurisé décrit le périmètre de connexion, et l’architecture des cookies signés explique le contrôle de la diffusion.
Rédaction WordPress. Diffusion AWS.
Publiez dans votre propre compte AWS
Conservez WordPress comme source de contenus, publiez le site sur S3 et CloudFront, puis planifiez des tâches content-sync pour les modifications régulières de contenus. Ajoutez Gatey, Flow, AI-Kit et Static Site Guardian lorsque votre site nécessite une connexion, des formulaires, de l’IA ou des pages protégées.