Comment faire un search and replace sur WordPress sans erreur ?

Pourquoi ça peut casser vite

Quand tu remplaces une URL dans une base WordPress, tu ne touches pas seulement à des liens dans des articles. Tu peux aussi toucher à des options, des métadonnées, des réglages de plugins, des contenus de builder, des chemins d’images ou des widgets. Et c’est là que le sujet devient plus sensible. La commande wp search-replace gère les données PHP sérialisées et évite de modifier les clés primaires, justement pour ne pas transformer une petite correction en chantier catastrophe. Better Search Replace annonce aussi clairement la mise à jour des URL et des textes dans la base avec prise en charge de ces cas.  

Autrement dit, si tu passes sur la base avec le mauvais outil, tu peux casser des morceaux du site sans le voir tout de suite. Et c’est souvent ce qu’il y a de plus pénible. Quand ça casse immédiatement, au moins, tu sais où regarder. Quand ça casse plus tard, tu passes surtout ton temps à remonter une piste qui aurait dû rester une simple formalité.

Le vrai danger n’est pas de remplacer une URL. Le vrai danger, c’est de le faire comme si WordPress stockait ça dans un bloc-notes.

Quand c’est vraiment utile

Le cas le plus fréquent, c’est le changement d’URL. Tu passes de http à https, tu remplaces une URL de staging par la vraie, tu changes de domaine, ou tu corriges un ancien chemin resté dans la base. Un search and replace sert à corriger les anciennes URL dans la base lors d’un passage en HTTPS ou à régler des problèmes de contenu mixte.  

Ça sert aussi quand tu veux :

• remplacer une ancienne URL restée dans des contenus ;
• corriger une adresse locale ou de préprod ;
• nettoyer un chemin d’image ;
• remettre au propre des valeurs répétées dans plusieurs contenus ;
• terminer correctement une migration.  

Là où il faut lever le pied, c’est quand tu n’es pas sûr de ce que tu remplaces. Si tu pars en mode “on va voir ce que ça change”, tu tiens déjà une très mauvaise idée. Un search and replace, ça marche bien quand tu sais exactement ce que tu cherches, où tu le cherches, et ce qui risque d’être touché au passage.

Ce qu’il faut faire avant

Avant de faire quoi que ce soit, il y a trois garde-fous qui évitent beaucoup de bêtises.

D’abord, la sauvegarde. Si ton hébergeur ne t’en crée pas une automatiquement, fais-la. C’est le genre de détail qu’on trouve très cool surtout après une erreur.  

Ensuite, le test à blanc. C’est probablement le meilleur réflexe de tout le sujet. wp search-replace propose –dry-run, donc tu peux lancer la recherche, voir le rapport, et ne rien écrire tant que tu n’es pas sûr de ton coup. 

Enfin, il faut viser juste. WP-CLI permet de cibler les tables, et c’est précieux. Parce qu’un remplacement lancé “partout” juste pour gagner 30 secondes finit souvent par te coûter beaucoup plus que ce qu’il t’a fait gagner.  

Un search and replace propre ne commence pas par “remplacer”. Il commence par “sauvegarder”, “tester”, puis “viser juste”.

Les outils à garder sous la main

Si tu veux rester dans l’admin WordPress, Better Search Replace reste une option solide. Il sert à mettre à jour les URL et les textes dans la base, et il fait partie des solutions les plus utilisées pour ce besoin.  

Si tu es à l’aise avec le terminal, WP-CLI search-replace est très propre. La commande gère les données sérialisées, peut cibler des tables, et propose le fameux –dry-run. C’est exactement le genre d’outil qui évite de bricoler à l’aveugle.  

Si ton hébergeur propose son propre outil,  ça peut aussi faire le travail sans plugin supplémentaire ni passage par la ligne de commande. Et franchement, moins tu touches directement à la base “en direct”, moins tu as de chances de te créer une enigme que tu devras ensuite résoudre toi-même.  

Les faux bons plans

Le SQL maison lancé directement dans la base, sans gestion de la sérialisation, c’est typiquement le genre d’idée qui paraît maligne pendant trois minutes. Après, c’est souvent moins drôle. WordPress mentionne bien un script tiers dans sa doc de migration, mais en réservant clairement ce type d’outil aux personnes vraiment à l’aise avec l’administration de base de données. Donc non, ce n’est pas le conseil à donner à quelqu’un qui veut juste remplacer une URL sans se fabriquer un nouveau problème.  

Autre erreur classique : remplacer tout le http par du https partout, puis croire que tout est réglé. Le search and replace aide beaucoup sur les ressources de ton propre domaine, mais certains scripts externes peuvent continuer à générer du contenu mixte.  

Et non, “je vais le faire vite fait en prod, ça ira” ne compte toujours pas comme une stratégie.

Le tuto propre

La version simple, saine, et franchement la plus reposante, c’est celle-ci :

• fais une sauvegarde de la base ;
• note exactement la valeur à chercher et celle à remplacer ;
• utilise un outil qui gère correctement la sérialisation ;
• limite l’opération aux tables utiles si possible ;
• lance un dry run ;
• vérifie le nombre d’occurrences touchées ;
• exécute le remplacement réel ;
• vide les caches si besoin ;
• contrôle le front, les images, les formulaires, les contenus sensibles et les liens principaux.  

Si ton cas concerne un passage en HTTPS ou un changement d’URL, pense aussi à vérifier après :

• les liens internes ;
• les images ;
• les messages de contenu mixte ;
• les redirections ;
• les réglages visibles dans WordPress.  

En conclusion

Faire un search and replace WordPress sans erreur, ce n’est pas une histoire de chance. C’est surtout une question de calme, de sauvegarde, et d’outil adapté.

Tu sauvegardes.
Tu testes.
Tu cibles.
Tu remplaces.
Tu contrôles.

Le vrai problème n’est pas le search and replace. Le vrai probléme, c’est de le traiter comme un banal remplacement de texte alors que WordPress stocke une partie de sa petite vie dans des formats un peu moins dociles.

Si tu gardes ça en tête, tu éviteras déjà une bonne partie des galères les plus classiques. Et franchement, éviter de flinguer une base juste parce qu’il fallait corriger une URL, c’est déjà une belle journée.