Cloner un site WordPress - Guide complet sans stress

Ce qu’il faut vraiment copier dans un site WordPress

Quand on parle de duplication, je distingue toujours deux réalités. D’un côté, il y a la copie du contenu: articles, pages, catégories, commentaires et parfois champs personnalisés. De l’autre, il y a la copie fidèle de l’installation: fichiers, base de données, médias, réglages, extensions et thème actif.

Le cœur du sujet, c’est que WordPress ne stocke pas tout au même endroit. La base de données rassemble le contenu et une grande partie des réglages dynamiques, tandis que le dossier wp-content contient ce que vous avez vraiment personnalisé: thèmes, extensions, images envoyées, cache généré par certains plugins et parfois des fichiers de configuration annexes. Les fichiers du noyau WordPress, eux, peuvent souvent être réinstallés proprement sur la cible si besoin.

Pour un simple transfert d’articles vers un autre site, l’export natif peut suffire. Pour un clone de travail, une copie de préproduction ou une migration vers un nouvel hébergeur, ce n’est généralement pas assez. Une copie sérieuse doit aussi préserver les médias, les réglages du thème, les widgets, les formulaires et les données stockées par les extensions.

Cette différence paraît évidente, mais elle évite beaucoup d’erreurs. Une fois le périmètre défini, on peut choisir la méthode la plus adaptée au cas d’usage réel.

Choisir la bonne méthode selon votre objectif

Avant de lancer l’opération, je regarde toujours le résultat attendu. On ne choisit pas la même méthode pour copier seulement le contenu d’un blog, pour créer un site de test ou pour migrer une boutique complète.

Si votre besoin se limite au contenu éditorial, l’outil natif reste le plus simple. Dès qu’il faut un clone fidèle, je privilégie un plugin ou une migration manuelle, parce que la structure du site compte autant que les pages visibles.

Dupliquer un site avec un plugin sans perdre de temps

Pour la plupart des sites, je trouve qu’un plugin de migration est le meilleur compromis entre simplicité et fiabilité. Des outils comme Duplicator permettent de regrouper le site dans un paquet de migration, souvent sous la forme de deux fichiers à récupérer: un fichier d’archive et un installateur. C’est ce qui rend la remise en ligne beaucoup plus fluide qu’une opération faite à la main.

Le principe est simple. On crée un paquet depuis le site source, on le récupère, puis on le déploie sur la cible. Selon l’outil choisi, il peut recréer la base de données, réécrire certaines URL et remettre le site en état sans exiger une installation WordPress déjà prête sur le serveur de destination. Pour un site de test ou une copie locale, c’est souvent la méthode la plus confortable.

Je recommande cette approche dans trois cas: quand le site doit bouger vers un autre hébergeur, quand on veut créer un environnement de staging qui ressemble au site en production, ou quand on a besoin d’une copie rapide pour travailler sur un thème, une extension ou une refonte.

Ses limites sont connues. Les gros sites peuvent atteindre les plafonds de mémoire, de temps d’exécution ou de taille d’envoi du serveur. Les multisites et certaines configurations très spécifiques demandent aussi de vérifier la compatibilité avant de se lancer. En pratique, plus l’installation est lourde, plus il faut préparer l’opération avec soin.

Quand je veux éviter les surprises, je fais toujours un test sur une petite copie ou sur un environnement isolé avant de déplacer le site principal. C’est ce passage qui montre si la méthode choisie tient vraiment la route.

Faire une copie manuelle quand on veut garder la main

La copie manuelle reste la solution la plus robuste pour quelqu’un qui sait ce qu’il fait. Elle repose sur deux blocs: les fichiers récupérés via FTP ou SFTP, et la base de données exportée puis réimportée via phpMyAdmin ou un outil équivalent. C’est plus long, mais cela donne un contrôle total sur chaque étape.

1. Je commence par une sauvegarde complète du site source, avant toute manipulation.
2. Je récupère les fichiers du site, surtout wp-content, et selon le contexte les fichiers de configuration.
3. J’exporte la base de données dans un fichier SQL.
4. Je crée une base vide sur l’hébergement cible et j’y importe le SQL.
5. Je mets à jour les identifiants de base dans wp-config.php.
6. Si le domaine change, je remplace les anciennes URL par les nouvelles avec un outil compatible avec les données sérialisées.
7. Je teste le site et je corrige les permaliens si nécessaire.

Le point le plus fragile, c’est la recherche et remplacement d’URL. Certaines options sont enregistrées sous forme sérialisée, c’est-à-dire encodées avec leur longueur interne. Un remplacement brut dans un éditeur ou un SQL mal pensé peut casser la structure et provoquer des comportements étranges. C’est pour cela que je préfère un outil qui sait manipuler correctement ces données, plutôt qu’une modification approximative.

Cette méthode est très utile si l’on travaille sur une architecture complexe, si l’on veut éviter un plugin tiers ou si l’on doit intervenir sur un site ancien dont la configuration n’est pas propre. Mais elle laisse moins de place à l’improvisation, surtout quand le site doit rester disponible sans interruption.

Une fois les fichiers et la base en place, il reste une étape que beaucoup négligent: la remise à plat des réglages côté front et côté référencement.

Les réglages qui évitent un site cassé après la copie

Une migration peut sembler réussie alors que quelques détails suffisent à casser l’expérience utilisateur. Je vérifie toujours la copie avec la même logique: ce qui est visible, ce qui circule en arrière-plan, et ce qui peut bloquer silencieusement le site.

• Les permaliens : je réenregistre la structure des URL depuis l’administration pour forcer WordPress à recalculer les règles de réécriture.
• Les URL internes : je m’assure que le domaine, le sous-domaine ou le chemin de base ont bien été remplacés partout.
• Le cache : je vide le cache du site, du plugin et, si besoin, celui du serveur ou du CDN.
• Le SSL : je contrôle l’absence de contenu mixte, notamment si le site passe en HTTPS sur une nouvelle plateforme.
• L’indexation : sur une copie de test, je bloque l’indexation pour éviter qu’un environnement de staging ne pollue le référencement.
• Les formulaires et les emails : je teste l’envoi de messages, car une migration casse souvent les réglages SMTP ou les clés d’API.
• Les licences : je vérifie les extensions premium qui lient parfois leur activation au domaine.

Sur les sites orientés acquisition, je fais aussi attention aux pages de conversion, aux pixels de suivi et aux balises analytiques. Une copie techniquement fonctionnelle peut quand même fausser les données marketing si les scripts n’ont pas été ajustés correctement. Ce contrôle final fait souvent la différence entre une migration propre et une migration pénible.

Il reste toutefois des cas où une méthode standard ne suffit pas, surtout quand le site est vivant, volumineux ou monétisé.

Quand une copie simple ne suffit pas

Pour un site vitrine classique, une migration propre se règle souvent en une seule passe. Mais dès qu’on touche à WooCommerce, à un multisite ou à une base très volumineuse, j’adapte la méthode. La raison est simple: plus le site dépend d’échanges en temps réel, plus la copie doit être préparée.

Les boutiques WooCommerce

Une boutique en ligne ajoute des commandes, des clients, des coupons, des stocks et parfois des webhooks liés à des services externes. Copier uniquement les pages produit ne suffit pas. Si la boutique continue de recevoir des commandes pendant la migration, je préfère prévoir une fenêtre de gel ou une synchronisation contrôlée, selon le niveau de trafic.

Les installations multisites

Un multisite regroupe plusieurs sites sous une même installation WordPress. La structure est plus complexe, parce qu’elle implique des tables supplémentaires, des sous-sites et parfois des règles de domaine spécifiques. Ici, la compatibilité de l’outil compte autant que sa facilité d’usage.

Lire aussi : Changelog WordPress - Le lire pour des mises à jour sans stress

Les sites lourds ou très personnalisés

Quand la bibliothèque média est très grande ou que la pile technique comporte beaucoup d’extensions, les limites de l’hébergement peuvent ralentir la migration. Dans ce cas, je préfère fractionner l’opération, travailler en SSH si l’accès existe, ou passer par une assistance de l’hébergeur si elle est réellement fiable. Les migrations “en un clic” ne sont pas toujours la meilleure option sur les gros volumes.

Autrement dit, plus le site a de dépendances, plus il faut penser la copie comme un petit projet technique, pas comme une simple sauvegarde restaurée à la va-vite.

La méthode que je retiens selon le contexte du site

Si je devais résumer ma façon de faire, je la ramènerais à quatre scénarios.

• Pour transférer des articles ou du contenu éditorial, j’utilise l’export natif.
• Pour cloner un site entier vers un autre serveur, je choisis en priorité un plugin de migration.
• Pour un site complexe ou une configuration atypique, je préfère la copie manuelle.
• Pour un hébergement managé qui propose une vraie migration assistée, je m’appuie volontiers sur l’outil du fournisseur.

Le bon réflexe n’est pas de chercher la solution la plus “technique”, mais celle qui correspond au niveau de fidélité attendu. Copier seulement le contenu, créer un environnement de test ou déplacer un site complet ne demandent pas le même outillage. C’est cette distinction qui évite les pertes de données, les URL cassées et les mauvaises surprises après mise en ligne.

Si je devais donner une seule règle de travail, ce serait celle-ci: cloner un site WordPress sans stress commence avant la migration, pas après. Plus le périmètre est clair au départ, plus la remise en route est simple, propre et prévisible.