Le mardi 9 avril 2024, entre 8 heures et 11 heures UTC, WooCommerce.com a quitté le domaine Woo.com pour revenir à son adresse d’origine. Cent soixante et un jours plus tôt, l’éditeur de WooCommerce avait abandonné son domaine historique, puis constaté que ses utilisateurs le trouvaient moins bien dans Google. La sortie de sa propre version 8.8, prévue ce jour-là, avait été repoussée pour tester sereinement après la bascule.
Cet épisode rappelle qu’une migration ne se joue pas dans l’outil qui copie les fichiers. Elle se joue dans le calendrier : quand baisser la durée de vie des enregistrements DNS, quand geler les commandes, quand basculer, et comment revenir en arrière si quelque chose casse.
Ce guide est un mode opératoire complet, de sept jours avant la bascule à deux semaines après. Il distingue deux opérations qui n’ont rien à voir : changer d’hébergeur en gardant la même adresse, et changer de domaine. Toutes les commandes ont été vérifiées sur la documentation officielle, et les exemples utilisent les adresses réservées à la documentation, example.com et 203.0.113.10.
Ce que « sans interruption » veut dire vraiment
Les deux horloges : les caches DNS et les écritures
Une migration sans interruption doit surveiller deux horloges en même temps. La première est celle des caches DNS : pendant un moment, certains visiteurs arrivent encore sur l’ancien serveur, d’autres déjà sur le nouveau. La seconde est celle des écritures : une commande, un commentaire ou une inscription reçus sur l’ancien serveur après la copie finale de la base sont perdus, ou doivent être rattrapés à la main.
Le premier risque se gère en anticipant le DNS, le second en gelant les écritures pendant une fenêtre courte. Un plugin de migration ne règle ni l’un ni l’autre.
Changer d’hébergeur ou changer de domaine
Le cas le plus courant est un changement d’hébergeur à adresse identique. Il ne demande ni remplacement d’adresses dans la base, ni déclaration de changement d’adresse à Google : le risque se concentre sur le DNS, les écritures et la configuration du nouveau serveur.
Changer de domaine est une autre opération, avec un vrai risque pour le référencement : remplacement des adresses dans la base, redirections permanentes, déclaration dans la Search Console. Le cas réel de ce guide en est l’illustration. Chaque étape ci-dessous précise à quelle opération elle s’applique.
Étape 1 : l’inventaire, avant de toucher quoi que ce soit
Ce que WordPress sait déjà
L’écran Santé du site, onglet Informations, dans le menu Outils, rassemble l’essentiel : version de WordPress, adresses du site, taille de la base et des dossiers, plugins actifs et inactifs, version de PHP et limites du serveur, constantes de wp-config.php. Un bouton copie tout dans le presse-papiers : gardez ce relevé, il servira à comparer l’ancien et le nouveau serveur.
En ligne de commande, quelques commandes donnent le même état, comme le détaille notre sélection de commandes WP-CLI essentielles :
wp core version
wp plugin list
wp db size
wp option get home
wp option get siteurl
wp cron event listCe que WordPress ne voit pas
L’inventaire doit aussi couvrir ce qui vit autour de WordPress : toute la zone DNS, avec les enregistrements A, AAAA, MX et TXT pour l’authentification des e-mails, les enregistrements CAA qui limitent les autorités de certification, la signature DNSSEC si elle est active. Ajoutez les tâches planifiées du serveur, les règles du serveur web, les extensions de PHP, le cache d’objets, le CDN, le chemin des e-mails sortants et les listes d’adresses IP autorisées chez vos prestataires de paiement.
Un piège fréquent : si l’ancien serveur répond aussi en IPv6 et que seul l’enregistrement A est modifié, les visiteurs en IPv6 continuent d’arriver sur l’ancien serveur. Changez l’enregistrement AAAA en même temps, ou supprimez-le.
Étape 2 : baisser le TTL DNS une semaine avant
Ce que le TTL promet, et ce qu’il ne promet pas
Le TTL, ou durée de vie, indique combien de temps un serveur DNS intermédiaire peut garder une réponse en cache. La norme RFC 2181 le précise : c’est une durée maximale, pas obligatoire. Certains résolveurs imposent un minimum de quelques dizaines de secondes, d’autres plafonnent les durées longues : Google Public DNS limite en général les siennes à six heures.
La « propagation DNS de 24 à 48 heures » n’est donc pas une loi : un changement atteint les visiteurs à mesure que les caches expirent. Avec un TTL déjà bas, la plupart basculent en quelques minutes.
Combien de temps à l’avance
Baisser le TTL le jour de la bascule ne sert à rien : les caches gardent l’ancienne valeur, parfois de 24 heures, jusqu’à son expiration. Il faut le baisser au moins une durée d’ancien TTL avant la bascule. Google recommande, pour un changement d’hébergeur, de passer à une valeur de quelques heures au moins une semaine à l’avance. Une valeur de 300 secondes, posée sept jours avant, laisse une bonne marge.
Une fois la migration confirmée, remontez le TTL à une valeur normale. Si vous changez aussi de fournisseur DNS, ne supprimez pas l’ancienne zone et tenez-la à jour avec les nouvelles valeurs : la norme RFC 8767 autorise un résolveur à servir des réponses expirées, donc l’ancienne adresse, si le serveur faisant autorité ne répond plus, et suggère une limite de sept jours.
Changer de serveurs DNS : un autre calendrier
Si vous changez aussi de fournisseur DNS, la délégation vit dans la zone parente, avec son propre TTL. Une requête sur les serveurs du .com le montre :
dig +norec NS example.com @a.gtld-servers.netPour un .com, ce TTL est de deux jours, et le registre le fixe : vous ne pouvez pas le baisser. La documentation d’AWS recommande de baisser le TTL des enregistrements NS chez l’ancien et le nouveau fournisseur, puis d’attendre deux jours avant de changer les serveurs de noms.
Si DNSSEC est actif, retirez l’enregistrement DS au début de cette attente : selon AWS, la signature ne peut pas être active chez deux fournisseurs à la fois, et le DS d’un .com peut rester en cache un jour. Ne cumulez pas, si possible, un changement d’hébergeur et un changement de fournisseur DNS le même jour.
Derrière un CDN
Si votre domaine passe par un proxy comme celui de Cloudflare, les visiteurs reçoivent les adresses du CDN, pas celle de votre serveur. La bascule consiste alors à changer l’origine dans le CDN, et ne dépend plus des caches DNS des visiteurs : c’est la situation la plus confortable.
Étape 3 : copier les fichiers avec rsync, en deux passes
La première passe se fait quelques jours avant, sans urgence, pour copier l’essentiel du volume :
rsync -az --info=progress2 -e ssh /var/www/example.com/ deploy@203.0.113.10:/var/www/example.com/La barre oblique finale de la source compte : elle signifie « copier le contenu du dossier ». L’option -a préserve les droits, les dates et les liens, mais pas les listes de contrôle d’accès, les attributs étendus ni les liens physiques, qui demandent -A, -X et -H.
La seconde passe se fait pendant le gel, avec suppression des fichiers disparus à la source. La documentation de rsync prévient que --delete est dangereux mal employé : faites d’abord un essai à blanc qui liste les changements.
rsync -az --delete -n -i -e ssh /var/www/example.com/ deploy@203.0.113.10:/var/www/example.com/Relancez ensuite sans -n. Grâce à la comparaison rapide par taille et date, seuls les fichiers modifiés depuis la première passe sont copiés. Dès la première passe, excluez les dossiers de cache, les archives de sauvegarde et, si le nouveau serveur a ses propres identifiants, son wp-config.php, en ajoutant par exemple --exclude=wp-config.php --exclude=wp-content/cache/ aux deux commandes : une exclusion ajoutée seulement à la seconde passe arrive trop tard, et --delete ne supprime pas les fichiers exclus.
Étape 4 : exporter et importer la base avec WP-CLI
La commande d’export de WP-CLI s’appuie sur l’outil de sauvegarde de MySQL, ou de MariaDB, avec les identifiants de wp-config.php. Elle n’ajoute pas l’option qui garantit une copie cohérente des tables InnoDB : passez-la vous-même. Le tiret envoie le résultat sur la sortie standard :
wp db export - --single-transaction --quick | gzip > ~/site.sql.gzCopiez l’archive sur le nouveau serveur, hors de la racine du site, créez la base si nécessaire, puis importez depuis l’entrée standard. L’import ne supprime pas les tables absentes de la sauvegarde : partez d’une base vide.
gunzip < ~/site.sql.gz | wp db import -Gardez les mêmes valeurs DB_CHARSET et DB_COLLATE que sur l’ancien serveur : un jeu de caractères mal réglé suffit à afficher les apostrophes et les accents en signes illisibles. Pour une boutique WooCommerce, vérifiez après import l’état du stockage des commandes avec wp wc hpos status. La commande wp wc hpos verify_data compare les tables dédiées aux tables des articles : elle ne sert que si le mode de compatibilité est actif.
Étape 5 : remplacer les adresses, seulement si le domaine change
Si l’adresse du site change, il faut la remplacer partout dans la base, y compris dans les données sérialisées, où WordPress et les plugins stockent la longueur de chaque texte. Un simple rechercher-remplacer dans le fichier SQL casse ces longueurs : la commande de WP-CLI les gère correctement. Commencez toujours par un essai à blanc :
wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-onlyDeux options comptent. Par défaut, la commande ne traite que les tables déclarées à WordPress ; WooCommerce n’en déclare qu’une partie, si bien que les tables de commandes, celles du stockage haute performance comme celle des articles de commande, seraient oubliées sans --all-tables-with-prefix. Et la colonne guid ne doit jamais être modifiée : la documentation officielle prévient que les lecteurs de flux afficheraient alors d’anciens articles comme nouveaux.
Enfin, la version stable de WP-CLI ne reconnaît pas les adresses échappées dans du JSON, sous la forme https:\/\/old.example.com. Faites une seconde passe sur cette forme si vos plugins en stockent.
Étape 6 : tester le nouveau serveur avec le fichier hosts
Windows, macOS et Linux
Le fichier hosts permet à votre seul ordinateur de joindre le nouveau serveur avec la vraie adresse du site, sans rien changer au DNS public. Ajoutez une ligne avec l’adresse IP du nouveau serveur et les deux noms du site :
203.0.113.10 example.com www.example.comSous Windows, le fichier se trouve dans C:\Windows\System32\drivers\etc et sa modification demande des droits d’administrateur ; videz ensuite le cache avec ipconfig /flushdns. Sous Linux et macOS, il s’agit de /etc/hosts. N’oubliez pas de retirer la ligne après le test.
Sans toucher au fichier hosts
L’outil curl offre une alternative en ligne de commande, que sa documentation présente comme une sorte d’alternative au fichier /etc/hosts, en ligne de commande :
curl -I --resolve example.com:443:203.0.113.10 https://example.com/Google propose aussi de tester sur un nom temporaire, comme beta.example.com, exclu de l’indexation. Avec WordPress, cela suppose de changer l’adresse de la copie, donc un remplacement d’adresses : le fichier hosts évite cette étape.
Les pièges du test
Pendant le test, WordPress lance ses tâches planifiées en appelant sa propre adresse. Tant que le DNS public pointe vers l’ancien serveur, ces appels partent du nouveau serveur vers l’ancien : les tâches planifiées et certains tests de Santé du site ne sont pas significatifs avant la bascule.
Plus grave : deux copies avec la même adresse se croient toutes deux en production. WooCommerce Subscriptions prévient qu’une copie migrée avec le même domaine n’active pas son mode de préproduction, et peut donc prélever de vrais renouvellements. Désactivez sur la copie inactive le traitement des tâches en file d’attente, et bloquez ses e-mails.
Étape 7 : la fenêtre de gel des commandes et des commentaires
Prévenir, puis fermer
La veille, annoncez la fenêtre avec la notification de la boutique de WooCommerce, un bandeau réglable dans l’outil de personnalisation, accessible aussi aux thèmes de blocs. Au début de la fenêtre, fermez le panier et la commande : le mode « Bientôt disponible » de WooCommerce, appliqué aux seules pages de la boutique, remplace le panier, la commande et la page boutique par une page d’attente.
Ce mode remplace l’affichage des pages sans bloquer une commande déjà en cours de validation, et les administrateurs et gérants de la boutique le contournent : notez le numéro de la dernière commande au moment de l’export final, et vérifiez qu’aucune n’est arrivée ensuite sur l’ancien serveur.
Fermez aussi les commentaires avec un filtre, dans un petit fichier du dossier mu-plugins :
<?php
add_filter( 'comments_open', '__return_false' );Pourquoi le mode maintenance ne suffit pas
La commande wp maintenance-mode activate affiche une erreur 503 à tous les visiteurs, et WordPress ignore le fichier de maintenance au bout de dix minutes. C’est un outil pour une mise à jour éclair, pas pour une fenêtre de migration. Un gel ciblé sur les écritures laisse le reste du site lisible.
Le déroulé de la fenêtre
Pendant le gel : seconde passe de rsync, export final de la base, import sur le nouveau serveur, vérifications rapides avec le fichier hosts, puis bascule DNS. Rouvrez les commandes et les commentaires sur le nouveau serveur seulement. L’ancien reste fermé aux écritures jusqu’à son extinction.
Étape 8 : la bascule et le certificat SSL
Le certificat avant la bascule
Le certificat doit être valide sur le nouveau serveur avant que le premier visiteur n’y arrive. Si votre site envoie l’en-tête HSTS, un navigateur qui rencontre un certificat invalide ne propose même pas de continuer : le site est inaccessible.
HTTP-01 ou DNS-01
La validation HTTP-01 de Let’s Encrypt va chercher un fichier sur votre domaine, sur le port 80. Avant la bascule, elle atteint donc l’ancien serveur. Trois solutions : copier le certificat et la clé existants, valider par DNS-01 avec un enregistrement TXT, ou rediriger le chemin de validation de l’ancien serveur vers le nouveau. Vérifiez aussi l’enregistrement CAA si le nouvel hébergeur utilise une autre autorité de certification.
Le moment de la bascule
Changez les enregistrements A et AAAA, ou l’origine dans le CDN. Surveillez les journaux des deux serveurs : le trafic doit glisser de l’ancien vers le nouveau dans les minutes qui suivent, grâce au TTL baissé une semaine plus tôt.
Le cas réel : 161 jours sur Woo.com, puis le retour
L’histoire de WooCommerce.com entre 2023 et 2024 est un cas d’école. C’est une migration de domaine documentée par l’entreprise elle-même, avec une perte de visibilité reconnue, un retour en arrière public et une fenêtre de bascule minutée. Elle illustre presque toutes les étapes de ce guide.
Le départ
Le 31 octobre 2023, WooCommerce annonce que WooCommerce.com devient Woo.com. La migration couvre la plateforme, la place de marché, le programme d’agences et les partenariats ; les marchands n’ont rien à faire. WP Tavern relaie l’annonce le jour même, et The WP Minute rassemble deux jours plus tard les réactions de la communauté au changement de marque et au nouveau site.
Deux jours plus tard, le 2 novembre, Google lance une mise à jour majeure de son algorithme. Une autre suit le 5 mars 2024, déployée sur quarante-cinq jours, et Google prévient lui-même de fluctuations de classement.
La décision
Le 5 avril 2024, Kevin Bates, de l’équipe croissance, annonce le retour à WooCommerce.com. Sa justification tient en une phrase : « Le passage à Woo.com a compliqué la recherche de WooCommerce dans Google pour nos utilisateurs », situation aggravée par la mise à jour de mars. L’entreprise a réuni des experts en référencement, et demande à ses partenaires de mettre à jour leurs références à Woo.com.
Le même jour, l’équipe des développeurs repousse la sortie de WooCommerce 8.8 : la migration, qui inclut tous les sous-domaines, aura lieu le mardi 9 avril de 8 heures à 11 heures UTC, et la nouvelle version ne doit pas tomber le même jour, pour laisser place aux tests après la bascule. Dans les commentaires, un membre de l’équipe explique que le site était en passe de retrouver ses positions quand la mise à jour de Google l’a fait reculer.
La bascule
La veille, un lecteur signale que des images n’avaient jamais été redirigées vers le nouveau domaine ; l’équipe répond que cela fait partie du retour, et que certains éléments peuvent bouger un moment. Le 9 avril, la migration a lieu dans la fenêtre annoncée. Le blog des développeurs change lui aussi d’adresse, et l’entreprise écrit que le changement de domaine a contribué à la baisse du trafic naturel.
Aujourd’hui encore, woo.com renvoie une redirection permanente vers woocommerce.com. WooCommerce n’a publié aucun chiffre de trafic : la cause de la baisse est sa propre lecture, mêlée aux mises à jour de Google.
Ce que l’histoire enseigne
Un changement de domaine est un projet de référencement, pas une formalité d’hébergement. L’inventaire doit inclure chaque sous-domaine et chaque hôte de fichiers : la migration de retour couvrait tous les sous-domaines de WooCommerce, blog des développeurs compris. Le jour de la bascule, on ne livre rien d’autre : WooCommerce a déplacé sa propre version. La fenêtre est annoncée, courte et minutée. Et le retour en arrière est possible, mais c’est une migration à part entière, avec ses redirections inversées et ses partenaires à prévenir.
Étape 9 : le plan de retour arrière
Le plan de retour se décide avant la bascule, pas pendant la panne. Il tient en cinq éléments : la liste des déclencheurs, comme une commande impossible, des erreurs serveur ou des e-mails qui ne partent plus ; les valeurs DNS exactes à restaurer ; l’ancien serveur intact et fermé aux écritures ; la liste des commandes et commentaires reçus sur le nouveau serveur depuis la bascule, à reporter à la main ; et un délai au-delà duquel corriger vaut mieux que revenir.
Le document informatif RFC 9199 recommande de garder l’ancienne infrastructure au moins aussi longtemps que le plus long des TTL en jeu, y compris celui de la zone parente. Google conseille d’éteindre l’ancien hébergement seulement quand son trafic tombe à zéro. Pour les abonnements WooCommerce, un ancien serveur laissé actif continue de prélever de vrais renouvellements : désactivez son traitement des tâches avant de le laisser tourner.
Étape 10 : les vérifications après migration
Search Console
Pour un changement d’hébergeur à adresse identique, l’outil de changement d’adresse de la Search Console ne s’utilise pas. Gardez simplement le fichier ou la balise de validation, et attendez-vous à une baisse temporaire du rythme d’exploration de Googlebot juste après la bascule. Pour un changement de domaine, l’outil s’impose, avec des redirections permanentes conservées au moins un an selon Google.
Tâches planifiées
Vérifiez qu’aucune tâche n’est en retard avec wp cron event list, et recréez sur le nouveau serveur les tâches système si WP-Cron y était désactivé, comme l’explique notre guide sur WP-Cron et le cron système.
E-mails transactionnels
Par défaut, WordPress envoie ses e-mails avec la fonction mail() de PHP. Sur un serveur sans service de messagerie, rien ne part. Et depuis février 2024, Gmail exige de tous les expéditeurs une authentification SPF ou DKIM et un DNS inversé valide. Ajoutez la nouvelle adresse IP au SPF, ou faites passer les e-mails par un relais authentifié, puis testez une commande réelle de bout en bout.
Caches, permaliens et ancien serveur
La commande wp cache flush ne vide que le cache d’objets : purgez aussi le cache de pages et le CDN. Si des pages renvoient une erreur 404, régénérez les règles de réécriture. Vérifiez l’intégrité des fichiers du cœur avec wp core verify-checksums, et celle des plugins avec wp plugin verify-checksums --all, puis surveillez les journaux de l’ancien serveur jusqu’à ce que son trafic tombe à zéro.
Les plugins de migration et leurs limites
All-in-One WP Migration
Plus de 5 millions d’installations actives : il exporte tout le site dans une seule archive et gère les données sérialisées. Sa version gratuite limite l’import à la taille d’envoi autorisée par l’hébergeur ; le module Unlimited coûte 69 dollars par an pour cinquante sites, au moment où nous écrivons.
Duplicator
Plus d’un million d’installations : il produit une archive et un programme d’installation, avec un assistant de remplacement d’adresses. La version gratuite ne gère pas les réseaux multisites. Les archives et installateurs laissés sur un serveur sont des fichiers sensibles, à supprimer après usage.
Migrate Guru et WP Migrate
Migrate Guru, gratuit, plus de 200 000 installations, migre de serveur à serveur via ses propres serveurs, jusqu’à 200 Go, avec cinq migrations par mois et par utilisateur. WP Migrate, plus de 200 000 installations, excelle dans le remplacement d’adresses en base ; l’envoi et la récupération entre sites sont réservés à sa version payante.
Ce qu’aucun plugin ne contrôle
Certains de ces outils promettent une migration sans interruption. Aucun ne contrôle les caches DNS, le gel des écritures, le certificat du nouveau serveur, les tâches planifiées sur deux copies ni l’authentification des e-mails. L’interruption dépend du mode opératoire, pas de l’outil d’archive. Avant tout, gardez une sauvegarde indépendante, avec l’un des plugins de sauvegarde WordPress que nous avons comparés.
Tableau récapitulatif : le mode opératoire jour par jour
| Moment | Actions | Changement de domaine |
|---|---|---|
| J-7 | Inventaire, TTL à 300 secondes | Plan de redirection de chaque adresse |
| J-2 | Première passe rsync, répétition de l’import, test hosts, certificat | Essai à blanc du remplacement d’adresses |
| J-1 | Annonce par la notification de la boutique | Prévenir les partenaires |
| Jour J | Gel, seconde passe, base finale, bascule DNS, réouverture | Remplacement d’adresses, redirections 301 |
| Jour J, +1 h | Commande test, e-mails, tâches, caches | Outil de changement d’adresse |
| J+2 | TTL remonté | Suivi de l’indexation |
| J+7 à J+14 | Ancien serveur à zéro, puis extinction | Redirections gardées au moins un an |
Questions fréquentes
Combien de temps dure la propagation DNS ?
Le temps que les caches expirent, c’est-à-dire au plus l’ancien TTL. Avec un TTL baissé à 300 secondes une semaine avant, la plupart des visiteurs basculent en quelques minutes. Un changement de serveurs DNS dépend en plus du TTL de la zone parente, deux jours pour un .com.
Faut-il un plugin de migration ?
Non, si vous avez un accès SSH : rsync et WP-CLI font le travail, avec plus de contrôle. Un plugin aide sur un hébergement sans accès en ligne de commande, mais ne remplace pas le mode opératoire.
Faut-il déclarer le changement dans la Search Console ?
Seulement si le domaine ou le sous-domaine change. Pour un simple changement d’hébergeur à adresse identique, l’outil de changement d’adresse ne s’utilise pas.
Que faire si je suis bloqué hors de l’administration après la migration ?
Vérifiez les options home et siteurl. En dernier recours, les constantes WP_HOME et WP_SITEURL dans wp-config.php forcent les adresses. La constante RELOCATE existe aussi, mais la documentation prévient qu’il est dangereux de la laisser en place.
Comment éviter les doubles prélèvements des abonnements ?
En désactivant le traitement des tâches en file d’attente sur la copie qui ne doit pas prélever, ou en changeant son adresse pour déclencher le mode de préproduction de WooCommerce Subscriptions.
Quand éteindre l’ancien serveur ?
Quand son trafic tombe à zéro dans les journaux, comme le recommande Google, et au plus tôt après le plus long des TTL en jeu. En pratique, gardez-le une à deux semaines, fermé aux écritures.
Conclusion
Une migration sans interruption n’a rien de magique : un TTL baissé une semaine avant, deux passes de copie, une base exportée proprement, un test discret par le fichier hosts, un gel court des écritures, un certificat prêt avant la bascule, et un plan de retour décidé d’avance. Chaque étape est simple ; c’est leur ordre qui fait la différence.
Le retour de WooCommerce.com rappelle le reste : changer de domaine est un projet de référencement, un jour de bascule ne se partage avec rien d’autre, et revenir en arrière est toujours possible si on l’a prévu. Pour choisir la destination, notre comparatif des hébergements WordPress est un bon point de départ.
Sources
- WordPress Advanced Administration Handbook. Migrating WordPress
- WordPress Developer Resources. wp search-replace
- WordPress Developer Resources. wp db export
- WordPress Developer Resources. wp db import
- WordPress Developer Resources. wp_is_maintenance_mode()
- WordPress.org Documentation. Site Health Screen
- Google Search Central (décembre 2025). Changing your hosting
- Google Search Central (août 2026). Site moves with URL changes
- Google Search Console Help. Change of Address tool
- IETF (juillet 1997). RFC 2181, Clarifications to the DNS Specification
- IETF (mars 2022). RFC 9199, Considerations for Large Authoritative DNS Server Operators
- IETF (mars 2020). RFC 8767, Serving Stale Data to Improve DNS Resiliency
- Amazon Web Services. Making Route 53 the DNS service for a domain that’s in use
- Cloudflare Docs. Time to Live (TTL)
- Google Public DNS. Frequently Asked Questions
- Linux man-pages. rsync(1)
- Microsoft Support. How to reset the Hosts file back to the default
- Linux man-pages. hosts(5)
- curl. curl man page
- Let’s Encrypt (février 2026). Challenge Types
- MDN. Strict-Transport-Security
- WooCommerce. How Subscriptions Handles Staging Sites and Migrations
- WooCommerce. Coming soon mode
- WooCommerce Developer Docs. HPOS CLI tools
- WordPress Advanced Administration Handbook. Mail
- Google. Email sender guidelines
- WooCommerce, David Callaway (31 octobre 2023). Say hello to Woo.com
- WP Tavern, Sarah Gooding (31 octobre 2023). WooCommerce Rebrands as Woo
- WooCommerce, Kevin Bates (5 avril 2024). Woo.com migrating back to WooCommerce.com
- WooCommerce Developer Blog (5 avril 2024). WooCommerce 8.8 is Delayed
- WooCommerce Developer Blog (9 avril 2024). WooCommerce.com Domain Migration
- Google Search Central Blog (5 mars 2024). March 2024 core update and new spam policies
- WordPress.org (octobre 2026). All-in-One WP Migration and Backup
- ServMask (octobre 2026). Unlimited Plugin
- WordPress.org (octobre 2026). Duplicator
- WordPress.org (octobre 2026). Migrate Guru
- WordPress.org (octobre 2026). WP Migrate Lite
- Google Search Status Dashboard. Ranking incident history
- The WP Minute, Matt Medeiros (2 novembre 2023). Find WooCommerce inside Woo.com
- WooCommerce. WooCommerce Customizer
- WordPress Developer Resources. wp_maintenance()
- WordPress Developer Resources. comments_open hook
- WordPress Advanced Administration Handbook. Loopbacks
- Microsoft Learn. ipconfig
- Cloudflare Docs. Proxy status
LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.