# Mise en production d’un site Elementor : la checklist du jour J

> La bascule d'un site Elementor dans l'ordre : TTL, gel, migration, URL, HTTPS, indexation, CSS, caches, formulaires, redirections et retour arrière.

- Auteur : WordPress Développement
- Publié le : 2026-10-19
- Mis à jour le : 2026-10-09
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/mise-en-production-site-elementor-checklist-jour-j/

## L’essentiel

- Abaissez le TTL DNS au moins un TTL complet avant la bascule
- Réactivez l'indexation et régénérez le CSS Elementor avant de purger les caches
- Fixez à l'avance le critère qui déclenche le retour arrière

Le jour J d'une mise en production commence en réalité deux jours plus tôt, au moment où vous abaissez la durée de vie des enregistrements DNS. Tout ce qui suit dépend de ce geste discret, qu'on oublie une fois sur deux. Ce septième épisode de la série « Livrer un site Elementor en agence » traite uniquement de la bascule : la recette est terminée et validée, la préproduction (troisième épisode) est à jour, il reste à faire passer le site en ligne sans casse et avec une porte de sortie.

## Avant le jour J : DNS, gel et plan de retour arrière

Trois préparations conditionnent la sérénité de la bascule.

1. **Abaisser le TTL.** Les résolveurs gardent l'ancienne adresse en mémoire pendant la durée de vie annoncée au moment où ils l'ont interrogée. Si l'enregistrement est à 86 400 secondes (un jour), abaissez-le à 300 secondes au moins un jour avant la bascule, idéalement deux. Sans cela, une partie des visiteurs continue d'arriver sur l'ancien serveur pendant des heures, et un éventuel retour arrière prend autant de temps.
2. **Annoncer le gel des contenus.** Fixez par écrit l'heure à partir de laquelle plus personne ne modifie ni l'ancien site ni la préproduction : ni le client, ni le rédacteur, ni l'agence. Tout contenu ajouté après le gel est perdu ou doit être ressaisi.
3. **Écrire le plan de retour arrière.** Conservez l'ancien hébergement intact et payé au moins deux semaines, notez les valeurs DNS d'origine, et décidez à l'avance du critère d'abandon : par exemple, un formulaire qui n'achemine pas ses e-mails une heure après la bascule. Un retour arrière décidé dans l'urgence se discute ; un retour arrière prévu s'exécute.

Vérifiez aussi que vous disposez des accès au registraire ou au gestionnaire DNS du client avant le jour J, et pas seulement de ceux de l'hébergement.

## Migration, URL et HTTPS sur le serveur de production

> L'essentiel à retenir : Abaissez le TTL DNS au moins un TTL complet avant la bascule ; Réactivez l'indexation et régénérez le CSS Elementor avant de purger les caches ; Fixez à l'avance le critère qui déclenche le retour arrière

Le jour J, l'ordre compte. Si le site en ligne est déjà un site Elementor qui change de serveur ou de version, passez-le d'abord en mode maintenance ; s'il s'agit d'un ancien site d'une autre technologie, utilisez son propre mécanisme d'indisponibilité. Le mode Maintenance d'Elementor (outils d'Elementor, onglet Maintenance Mode) renvoie un code HTTP 503, qui indique aux moteurs de recherche une indisponibilité temporaire ; le mode Coming Soon renvoie un code 200 et convient à un site jamais lancé, pas à une coupure de quelques heures. Par défaut, tout utilisateur connecté voit le site normal, abonnés compris : vérifiez le réglage *Who Can Access* et testez dans une fenêtre de navigation privée.

Exportez ensuite la base de la préproduction, importez-la avec les fichiers sur le serveur de production, puis remplacez les URL. Lancez toujours une simulation d'abord :

```
wp db export avant-bascule.sql
wp search-replace 'https://preprod.exemple.fr' 'https://www.exemple.fr' --skip-columns=guid --dry-run
wp search-replace 'https://preprod.exemple.fr' 'https://www.exemple.fr' --skip-columns=guid
wp elementor replace-urls https://preprod.exemple.fr https://www.exemple.fr
```

`wp search-replace` traite correctement les données PHP sérialisées ; la commande d'Elementor complète le remplacement dans les données de ses pages. Le détail de cette étape, avec ses pièges, a été traité au troisième épisode : ici, on l'exécute, on ne la redécouvre pas.

Pour HTTPS, le certificat doit être prêt au moment où le DNS bascule. Si votre hébergeur ne peut émettre un certificat gratuit qu'une fois le domaine pointé vers lui, prévoyez ces quelques minutes dans le déroulé et gardez le mode maintenance actif jusque-là. Vérifiez que les réglages d'adresse de WordPress commencent par `https://` et qu'aucune ressource n'est encore appelée en `http://`.

Avant de toucher au DNS, testez le site de production en forçant la résolution du domaine vers le nouveau serveur dans le fichier `hosts` de votre poste : c'est la dernière occasion de voir le vrai site sans exposer d'erreur au public.

## La checklist ordonnée du jour J

Voici l'ordre que nous suivons, une fois la migration faite et le site testé via le fichier `hosts`.

1. **Basculer le DNS** vers le nouveau serveur, enregistrement par enregistrement, sans toucher aux enregistrements de messagerie (MX, SPF, DKIM) sauf si c'est prévu.
2. **Réactiver l'indexation.** Décochez « Demander aux moteurs de recherche de ne pas indexer ce site » dans les réglages de lecture, ou exécutez `wp option update blog_public 1`. Tant que cette case est cochée, WordPress demande aux moteurs de ne pas indexer le site et désactive aussi son plan de site natif `/wp-sitemap.xml`.
3. **Régénérer le CSS Elementor** avec `wp elementor flush-css --regenerate`, ou par le bouton Clear Files & Data des outils d'Elementor. Les fichiers générés en préproduction peuvent contenir des URL absolues, notamment pour les images de fond.
4. **Purger tous les caches**, dans l'ordre : cache objet (`wp cache flush`), cache de page de l'extension ou du serveur, réseau de diffusion s'il y en a un. Purger avant d'avoir régénéré le CSS, c'est remettre en cache des pages qui appellent des fichiers absents.
5. **Désactiver le mode maintenance** et contrôler l'accueil et trois pages types en navigation privée, déconnecté.
6. **Tester chaque formulaire et chaque e-mail** avec une vraie adresse : notification interne, accusé de réception au visiteur, pièce jointe. Vérifiez l'arrivée dans la boîte du client, pas seulement le message de succès à l'écran.
7. **Activer les redirections** depuis les anciennes adresses, à partir du tableau de correspondance établi pendant le projet.
8. **Déclarer le plan de site** dans la Search Console et vérifier la propriété ; en cas de changement de domaine, utilisez aussi son outil de changement d'adresse.
9. **Surveiller et décider** : à J+1 heure, appliquez votre critère d'abandon ; à J+1 et J+7, consultez les erreurs 404 et les pages exclues de l'indexation.

> Une mise en production réussie est une procédure ennuyeuse : chaque étape a été écrite avant d'être exécutée.

## Redirections et contrôles en ligne de commande

Sur un serveur Apache, les redirections permanentes d'anciennes adresses peuvent se placer dans le fichier `.htaccess`, au-dessus de la ligne `# BEGIN WordPress`, car WordPress réécrit tout ce qui se trouve entre ses propres marqueurs :

```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^nos-services\.html$ https://www.exemple.fr/services/ [R=301,L]
RewriteRule ^contact\.php$ https://www.exemple.fr/contact/ [R=301,L]
</IfModule>
```

Restez sur des règles de réécriture plutôt que de mélanger directives `Redirect` et `RewriteRule` dans le même fichier : l'ordre de traitement des deux modules surprend souvent.

Sur Nginx, la syntaxe est différente et la configuration passe en général par l'hébergeur. Au-delà d'une cinquantaine de règles ou si le client doit pouvoir les modifier, une gestion des redirections dans WordPress est plus maintenable.

Quelques contrôles rapides confirment que la bascule est complète :

```
wp option get blog_public
curl -sI https://www.exemple.fr/wp-sitemap.xml | head -n 1
curl -sI http://www.exemple.fr/ | grep -i '^location'
curl -sI https://www.exemple.fr/nos-services.html | grep -i '^location'
```

La première commande doit renvoyer `1`, la deuxième un code 200 (sauf si une extension SEO remplace le plan de site natif), la troisième une redirection vers HTTPS, la quatrième l'adresse cible de la redirection.

## Quand ne pas suivre cette checklist telle quelle

Pour une boutique en ligne avec des commandes en continu, le gel des contenus ne suffit pas : les commandes passées sur l'ancien site pendant la bascule doivent être reportées, et la fenêtre doit être choisie au creux du trafic. Pour un site de moins de dix pages créé sur un domaine neuf, la moitié des étapes disparaît : pas de redirections, pas de mode maintenance, pas de TTL à anticiper si le domaine n'a jamais servi. Et si l'hébergement propose une fonction de mise en ligne de la préproduction en un clic, utilisez-la, mais gardez les étapes 2 à 9, que cette fonction ne fait pas à votre place.

Les détails du mode maintenance figurent dans la [documentation d'Elementor sur Maintenance Mode](https://elementor.com/help/maintenance-mode/), et les options de remplacement dans la [référence de wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/).

## Conclusion

La bascule d'un site Elementor tient en une séquence courte mais stricte : TTL abaissé en amont, gel annoncé, migration et remplacement d'URL, HTTPS prêt, indexation réactivée, CSS régénéré, caches purgés dans le bon ordre, formulaires testés jusqu'à la boîte du client, redirections actives, plan de site déclaré. Le retour arrière n'est pas un échec mais une étape prévue, avec son critère écrit. Les sauvegardes et leur restauration, qui sécurisent la suite, font l'objet du neuvième épisode.