Symptôme. Après la migration d’un site Elementor de l’ancien domaine ancien-site.fr vers nouveau-site.fr, plusieurs pages s’affichent avec une mise en page visiblement cassée : colonnes qui ne s’alignent plus, espacements incorrects, certaines images de fond absentes. Le contenu textuel est présent et correct, seul le rendu visuel est atteint, ce qui oriente immédiatement le diagnostic vers un problème de chargement CSS plutôt que de contenu.
Diagnostic : des URL absolues encore figées sur l’ancien domaine
Elementor génère, pour chaque page et chaque template, un fichier CSS statique stocké dans wp-content/uploads/elementor/css/, référencé dans le <head> de la page. Le problème vient souvent du contenu même de ce fichier CSS : les images de fond posées via l’onglet Style des widgets sont enregistrées avec leur URL absolue complète, incluant l’ancien nom de domaine.
Ouvrir les outils de développement du navigateur, onglet Réseau, filtré sur les images, révèle typiquement des requêtes en échec (404) vers ancien-site.fr/wp-content/uploads/... alors que le site tourne désormais sur nouveau-site.fr. Un second indice apparaît dans la console : des erreurs de contenu mixte si l’ancien domaine était resté en HTTP alors que le nouveau est en HTTPS.
Première correction : l’outil Replace URL
Elementor propose un outil dédié dans Elementor > Outils > Remplacer une URL, qui parcourt les données stockées dans la base pour remplacer l’ancien domaine par le nouveau dans les champs gérés par Elementor lui-même :
wp elementor replace_urls "https://ancien-site.fr" "https://nouveau-site.fr"
Cette commande, disponible aussi bien depuis l’interface que via WP-CLI, corrige les URL stockées dans les métadonnées Elementor des pages (le champ _elementor_data sérialisé qui contient toute la configuration des widgets). C’est une étape nécessaire, mais elle ne suffit pas toujours seule.
Pourquoi Replace URL seul ne résout pas tout
Le remplacement dans les métadonnées ne régénère pas automatiquement les fichiers CSS déjà écrits sur le disque. Tant que ces fichiers physiques ne sont pas recréés, ils continuent de contenir les anciennes URL, même si la configuration source dans la base de données a bien été corrigée. C’est l’erreur la plus fréquente : croire que l’exécution de Replace URL suffit, alors qu’il faut ensuite forcer la régénération des fichiers CSS statiques pour que la correction se propage réellement au rendu visible.
Correctif : régénérer les fichiers CSS
La régénération se déclenche depuis Elementor > Outils > Régénérer les fichiers CSS, ou via la commande WP-CLI équivalente qui vide le cache de fichiers CSS d’Elementor :
wp elementor flush_css
Après cette étape, chaque page reconsultée regénère son fichier CSS à la volée avec les URL désormais correctes. Sur un site avec plusieurs centaines de pages, cette régénération à la volée peut créer un léger pic de charge serveur au moment où les premiers visiteurs consultent chaque page après la migration : pré-générer les fichiers en parcourant les pages principales avec un script ou un outil de crawl limite ce risque.
Le CDN, dernier maillon souvent oublié
Si le site utilise un CDN devant les fichiers statiques, celui-ci peut continuer à servir une version en cache de l’ancien fichier CSS pendant plusieurs heures ou jours selon sa configuration d’expiration, même après régénération correcte côté serveur d’origine. Une purge manuelle du cache CDN pour les fichiers du dossier wp-content/uploads/elementor/ doit systématiquement suivre la régénération, sans quoi le correctif reste invisible pour une partie des visiteurs pendant toute la durée du cache.
Prévention pour la prochaine migration
- Exécuter Replace URL avant toute autre vérification, jamais après avoir commencé à corriger des pages à la main.
- Régénérer systématiquement les fichiers CSS juste après, sans attendre que les visiteurs déclenchent la régénération automatique.
- Purger explicitement le cache CDN et le cache de page, dans cet ordre précis, à chaque migration de domaine.
- Vérifier un échantillon de pages représentatif dans un navigateur en navigation privée, cache vidé, avant de considérer la migration terminée.
Prévention
Ce type d’incident se répète à chaque migration de domaine tant que la procédure n’est pas explicitement documentée et suivie dans l’ordre. La cause racine n’est jamais Elementor lui-même, mais l’oubli d’un des trois maillons de la chaîne : les données en base, les fichiers CSS générés sur le disque, et le cache en périphérie. Documenter cette check-list dans la procédure de migration du projet évite de redécouvrir le problème à chaque nouvelle bascule de domaine.
