Comment reconstruire un site WordPress supprimé sans sauvegarde ?

Je l’ai déjà fait. Une fois. Et j’espère franchement ne jamais avoir à recommencer.

Le site n’avait aucune sauvegarde exploitable. Je suis passé par la Wayback Machine, j’ai repris les pages une à une, remis le contenu à la main, cherché les images qui existaient encore et remplacé celles qui avaient disparu. Certains textes ressortaient mal. Certaines mises en page étaient cassées. Ce n’était pas le moment le plus sympa de ma vie.

Depuis, je fais hyper attention à mes sauvegardes. Pas parce qu’un article m’a expliqué qu’elles étaient importantes. Parce que je sais exactement combien d’heures on peut perdre quand elles n’existent pas.

Quelle différence entre restaurer et reconstruire un site WordPress ?

Une restauration remet en place un état connu. Il faut, au minimum, les fichiers du site et sa base de données. C’est exactement ce que rappelle la documentation officielle de WordPress sur les sauvegardes : les deux parties sont nécessaires pour retrouver l’ensemble du site.

Sans elles, vous changez de métier. Vous ne restaurez plus. Vous faites de l’archéologie numérique.

Vous pouvez retrouver une vitrine, des textes, une partie des médias et parfois la structure des URL. Vous ne récupérez pas magiquement les comptes utilisateurs, les réglages, les commandes WooCommerce, les formulaires reçus ou les brouillons qui n’ont jamais été publics.

Ce que vous avez	Ce que vous pouvez espérer
Fichiers et base de données cohérents	Une vraie restauration, avec vérification technique
Base de données seule	Les contenus et réglages, mais pas forcément le thème, les extensions ni les médias
Fichiers seuls	Le code et les médias présents, sans les contenus stockés en base
Archives publiques seulement	Une reconstruction éditoriale partielle, page après page
Rien de public ni de local	Très peu de choses, hors traces chez l’hébergeur ou des tiers

Que reste-t-il de 20 anciennes pages WPFormation dans Wayback ?

Je ne voulais pas vous répondre avec un simple "ça dépend". J’ai donc pris un échantillon reproductible de 20 anciennes URL de WPFormation capturées par la Wayback Machine entre 2014 et 2016, puis j’ai vérifié ce qui était encore récupérable le 5 septembre 2026.

Le tirage a été effectué avec la graine 20260814 parmi 100 URL éditoriales candidates, celles que l’index CDX de l’Internet Archive connaît avec au moins une capture HTML en 200 sur cette période, hors pages techniques et variantes AMP. Pour chaque page, j’ai pris la capture en 200 la plus proche du 1er juillet 2015. J’ai séparé le contenu HTML des images hébergées sur WPFormation, y compris celles que le CDN de l’époque servait à sa propre adresse. Les images externes ne sont pas incluses dans le ratio, et les refus temporaires de la Wayback Machine ont été retentés avant de déclarer une ressource absente.

Mesure	Résultat
Pages testées	20
Corps d’article récupérables après nouvelles tentatives	20 sur 20
Mots récupérés	29 327
Images WPFormation référencées dans ces pages	274
Images encore archivées	154, soit 56,2 %
Images manquantes	120, soit 43,8 %
Pages avec au moins une image manquante	12 sur 20
Images du CDN retrouvées à leur adresse d’origine sur le domaine	75 sur 100, soit 83,6 % d’images au total

Le résultat est à la fois rassurant et brutal. Le texte public résiste plutôt bien. Les images, beaucoup moins. Et le détail dit quelque chose que je n’attendais pas : les images servies depuis le domaine ont survécu à 153 sur 173, alors que celles que le CDN de l’époque servait à sa propre adresse ont disparu presque en bloc, 1 sur 101. En cherchant ces fichiers à leur adresse d’origine sur le domaine, j’en ai retrouvé 75. Un CDN abandonné efface ses traces publiques ; le domaine, lui, reste dans l’archive. Et même avec 20 corps d’articles retrouvés sur 20, je n’ai récupéré ni la base MySQL, ni les utilisateurs, ni les réglages du serveur, ni la logique WordPress qui existait derrière ces pages.

Comment retrouver les anciennes URL avec l’index CDX ?

L’index CDX permet d’obtenir une liste de captures sans ouvrir le calendrier Wayback page par page. Il ne garantit pas que chaque ressource soit encore lisible, mais il donne un inventaire daté des URL connues, de leur type et de leur code HTTP. C’est le meilleur point de départ pour éviter une reconstruction au hasard.

La documentation officielle du serveur CDX décrit les paramètres utiles : une URL ou un domaine, un format de sortie, les champs à retourner, des filtres et une règle pour regrouper les doublons. Pour un premier inventaire, remplacez simplement exemple.fr dans cette requête :

https://web.archive.org/cdx/search/cdx?url=exemple.fr/*&output=json&fl=timestamp,original,statuscode,mimetype&filter=statuscode:200&filter=mimetype:text/html&collapse=urlkey

Le joker /* demande les captures sous le domaine. output=json produit un tableau exploitable. fl limite la réponse à quatre colonnes utiles. Les deux filtres gardent les pages HTML servies en 200. Enfin, collapse=urlkey évite d’obtenir cent fois la même URL. Pour une reconstruction, je garde aussi une requête non regroupée sur les pages prioritaires afin de comparer plusieurs dates.

1. Exportez le résultat brut et ne travaillez jamais sur sa seule copie.
2. Normalisez les variantes avec ou sans www, HTTP et HTTPS, puis retirez les URL purement techniques.
3. Classez les pages par valeur : accueil, pages commerciales, contenus qui recevaient des liens, mentions et formulaires.
4. Pour chaque URL, choisissez une capture cohérente plutôt que la plus récente par réflexe. La dernière peut déjà montrer une panne.
5. Notez la date de capture, la source du texte, le nombre d’images retrouvées et les éléments manquants.

Le service peut limiter ou refuser temporairement certaines requêtes. Travaillez par lots raisonnables et conservez les réponses obtenues. Une absence dans CDX signifie qu’aucune capture publique n’est retournée pour cette requête, pas qu’aucune autre trace n’existe chez un hébergeur, un CDN ou un ancien prestataire.

Je lance ensuite un inventaire séparé des médias. Une page HTML peut être présente alors que son image principale, son PDF ou sa feuille de style ne l’est plus. Je relève chaque URL de fichier, son type, la capture qui la référence et le résultat du téléchargement. Cela évite de déclarer une page "récupérée" alors qu’elle a perdu la moitié de son sens. Pour une photographie irremplaçable, je cherche aussi dans les newsletters, les réseaux sociaux, les ordinateurs des rédacteurs et les anciens dossiers de l’agence.

Que peut vraiment sauver la Wayback Machine ?

La Wayback Machine enregistre des instantanés du Web. Quand une page a été visitée et archivée correctement, on peut souvent retrouver son titre, ses paragraphes, ses liens, quelques feuilles de style et une partie de ses images.

Dans un sauvetage réel, cela permet de reconstituer :

• les pages et articles qui ont eu une URL publique
• le texte qui était rendu dans le navigateur
• une partie des images et documents accessibles sans connexion
• l’arborescence visible à travers les menus et les liens internes
• les anciennes URL utiles pour préparer les redirections
• des éléments de design suffisants pour comprendre l’intention d’origine

La documentation de l’Internet Archive prévient elle-même que des graphiques peuvent manquer et que certains sites ne sont pas archivés. La fonction Save Page Now enregistre une page donnée, pas une sauvegarde complète du site.

Qu’est-ce qu’une archive publique ne peut pas récupérer ?

Une archive voit ce qu’un visiteur anonyme pouvait voir. Elle n’a aucun accès à l’intérieur de WordPress. La frontière est simple, même si elle fait mal.

Élément	Récupération depuis une archive Web
Articles et pages publics	Souvent possible, avec nettoyage manuel
Images publiques	Partiel et très variable
Commentaires affichés publiquement	Parfois visibles, mais pas restaurés comme données structurées
Utilisateurs et mots de passe	Impossible
Commandes et clients WooCommerce	Impossible
Leads reçus par formulaire	Impossible
Réglages du thème et des extensions	Impossible
Clés API, tâches cron et configuration serveur	Impossible
Brouillons, révisions privées et contenus protégés	Impossible
Historique SEO interne, statistiques et journaux	Impossible sans une autre source

C’est la raison pour laquelle je refuse de présenter Wayback comme un plan de sauvegarde. C’est une bouée. Une bonne bouée, parfois. Mais vous êtes déjà dans l’eau.

Dans quel ordre récupérer le site sans aggraver la panne ?

Quand tout a disparu, la précipitation coûte cher. Voici l’ordre que j’appliquerais aujourd’hui.

1. Geler l’existant. Ne réinstallez rien sur l’hébergement touché avant d’avoir demandé une copie brute des fichiers, bases et journaux encore présents.
2. Inventorier les traces. Vérifiez les ordinateurs des rédacteurs, anciens exports, dossiers de médias, caches CDN, pièces jointes, dépôts Git, boîtes mail et comptes de stockage.
3. Lister les URL. Utilisez le sitemap encore indexé, Google Search Console, Bing Webmaster Tools, les résultats de recherche et les archives CDX de l’Internet Archive.
4. Créer un WordPress propre ailleurs. Travaillez sur un environnement séparé, jamais directement sur le domaine en production.
5. Rétablir d’abord les URL, les titres et les textes. Le design vient après. Une page sobre mais complète vaut mieux qu’une belle coquille vide.
6. Télécharger les médias encore archivés, puis identifier clairement ceux qui doivent être recréés, remplacés ou abandonnés.
7. Contrôler les liens, les formulaires, les redirections, les données structurées et l’indexation avant de reconnecter le domaine.
8. Mettre enfin une vraie stratégie de sauvegarde en place et tester une restauration complète.

Le travail doit être documenté au fil de l’eau. Notez la source de chaque page, la date de capture choisie et ce qui manque encore. Sinon, au bout de cinquante URL, vous ne saurez plus ce qui a été vérifié.

Transformer une capture archivée en page WordPress propre

Je ne copie jamais tout le HTML archivé dans WordPress. Il contient des chemins cassés, des scripts inutiles et la mise en page d’une époque donnée. Je récupère le contenu dont je possède les droits, je le nettoie, puis je reconstruis la page avec des blocs natifs. L’archive reste une source, pas le nouveau site.

1. Conservez l’ancienne URL et le titre avant de toucher au texte.
2. Copiez les paragraphes, listes et tableaux en retirant les barres de navigation, scripts, pixels de suivi et liens de l’archive.
3. Téléchargez les médias encore disponibles, contrôlez leur licence et téléversez-les dans votre propre médiathèque. Ne laissez pas la page dépendre de web.archive.org.
4. Recréez la structure avec des blocs WordPress simples. Une mise en page plus sobre est préférable à une imitation fragile de l’ancien thème.
5. Repérez les formulaires, boutons d’achat et espaces membres. Une capture ne prouve pas qu’ils fonctionnent et ne permet pas de recréer leurs données.
6. Relisez les faits, les prix, les contacts et les obligations juridiques. Un texte récupéré peut être devenu faux.
7. Testez les liens, les images, les métadonnées, le responsive et la future redirection avant toute remise en ligne.

Si vous devez repartir de zéro, commencez par mon guide pour créer un site WordPress, puis appliquez les premières actions après l’installation. Si l’ancien écran affichait une erreur de connexion à la base de données, ne concluez pas trop vite à une suppression : la base ou ses identifiants peuvent encore être récupérables.

Champ du journal de reprise	Exemple de valeur
URL d’origine	/ancienne-page/
Capture retenue	Date et URL Wayback complètes
Texte	Récupéré, incomplet ou absent
Médias	3 retrouvés sur 5
Action	Recréer, fusionner, rediriger ou abandonner
Contrôle	Nom et date de la relecture

Les autres endroits où chercher avant de déclarer le site mort

Wayback n’est qu’une source parmi d’autres. Un ancien rédacteur peut avoir des brouillons dans Word. Le développeur peut posséder un dépôt du thème. Une agence a parfois gardé un export de migration. Un CDN peut encore servir des images. Une newsletter contient des versions complètes de textes qui n’existent plus ailleurs.

Regardez aussi les appareils qui ont administré le site. Les navigateurs gardent parfois des téléchargements, les logiciels FTP une copie locale, les outils de synchronisation des dossiers anciens. Sur un site professionnel, demandez également au comptable, au prestataire de paiement et aux équipes marketing quels exports ils détiennent.

Il faut être méthodique, mais aussi réaliste. Une trace n’est pas toujours une sauvegarde exploitable. Elle peut cependant éviter de réécrire une page entière ou permettre de prouver qu’une information existait.

Cas critique : ventes, membres et données sensibles

Si le site n’était qu’une vitrine, reconstruire le public peut suffire à redémarrer. S’il contenait des commandes, des abonnements, des dossiers clients, des espaces membres ou des données personnelles, le problème change totalement.

Ne recréez jamais de fausses commandes à partir d’emails incomplets pour faire "comme avant". Ne réinjectez pas une liste de contacts dont l’origine et le consentement sont incertains. Et ne considérez pas une page archivée comme une preuve comptable.

Wayback Machine ne remplace pas une sauvegarde testée

Le vrai enseignement de mon expérience n’est pas "pensez à archiver vos pages". C’est beaucoup plus simple : une sauvegarde que personne n’a restaurée reste une promesse.

Votre dispositif doit contenir la base de données et les fichiers, conserver plusieurs versions, stocker au moins une copie hors de l’hébergement principal et produire une alerte quand il échoue. Surtout, vous devez avoir déjà testé le retour sur un autre environnement. Un plan de maintenance WordPress permet de dater ces contrôles au lieu de compter sur la mémoire.

J’ai détaillé cette partie dans mon guide sur les sauvegardes WordPress. Je ne la recopie pas ici, justement pour ne pas mélanger prévention et reconstruction de dernier recours.

Si personne dans l’équipe ne peut piloter cette reprise, faites cadrer le sauvetage avant de multiplier les manipulations. Un prestataire de maintenance WordPress doit commencer par l’inventaire et la copie des traces, pas par une réinstallation précipitée.

Mon verdict : oui pour la vitrine, non pour le site complet

Peut-on reconstruire un site WordPress supprimé sans aucune sauvegarde ? Oui, si le site a laissé suffisamment de traces publiques et si vous acceptez un travail manuel parfois énorme.

Peut-on retrouver le WordPress d’origine, avec ses comptes, ses réglages, ses données privées et son historique ? Non. Une archive Web ne remplace pas une base de données.

Dans mon test, 20 corps d’articles sur 20 étaient encore là. Plus de quatre images sur dix ne l’étaient plus à l’adresse citée, et une sur six manquait encore après avoir cherché à l’adresse d’origine. C’est exactement le genre de chiffre qui remet les idées en place. La Wayback Machine m’a déjà sauvé. Elle m’a aussi appris à ne plus jamais compter sur elle.

Questions fréquentes

Google conserve-t-il encore une copie d’un site supprimé ?

Les moteurs peuvent garder des extraits et des résultats pendant un temps, mais ils ne fournissent pas une sauvegarde complète et durable. Utilisez-les surtout pour retrouver les anciennes URL, les titres et quelques fragments.

Peut-on récupérer les images originales avec la Wayback Machine ?

Parfois. Dans mon échantillon WPFormation, 154 images sur 274 étaient encore disponibles à l’adresse citée, 229 en cherchant aussi les fichiers du CDN à leur adresse d’origine. La qualité et le fichier original dépendent de ce qui a réellement été archivé.

Peut-on restaurer les commandes WooCommerce depuis une page archivée ?

Non. Une archive publique ne contient pas la base de commandes, les comptes clients, les paiements ni les statuts internes. Il faut retrouver la base MySQL, un export ou des traces chez les prestataires concernés.

Faut-il encore posséder le nom de domaine pour reconstruire le site ?

Non pour consulter des archives publiques. Oui pour remettre le site en ligne à son ancienne adresse et conserver ses URL, ses liens et une partie de son référencement.

Article original sur WPFormation