Douze requêtes SQL, exécutées avant toute modification de structure de permaliens, suffisent à écarter la plupart des incidents observés sur des migrations de catalogues volumineux. Cette liste n’a rien de théorique : chaque point provient d’un problème concret rencontré sur des changements de structure d’URL touchant plusieurs dizaines de milliers de fiches produit ou d’articles.
Avant toute modification : capturer l’état actuel
- Compter le nombre total de contenus publiés par type :
SELECT post_type, COUNT(*) FROM wp_posts WHERE post_status = 'publish' GROUP BY post_type; - Exporter la correspondance actuelle entre identifiant et slug, dans un fichier hors production :
SELECT ID, post_name FROM wp_posts WHERE post_status = 'publish'; - Vérifier qu’aucun
post_namen’est vide, ce qui indiquerait déjà un problème antérieur non traité :SELECT ID FROM wp_posts WHERE post_name = '' AND post_status = 'publish'; - Repérer les doublons de
post_nameexistants avant même la migration, un cas plus fréquent qu’attendu sur les imports automatisés :SELECT post_name, COUNT(*) FROM wp_posts GROUP BY post_name HAVING COUNT(*) > 1;
Pendant la préparation : simuler sans écrire
- Générer les futurs slugs dans une table temporaire, jamais directement dans
wp_posts, pour pouvoir comparer avant validation :CREATE TABLE wp_migration_slugs AS SELECT ID, post_name AS ancien_slug FROM wp_posts; - Ajouter une colonne pour le nouveau slug calculé et vérifier qu’aucune collision n’apparaît entre deux identifiants différents.
- Confirmer qu’aucun nouveau slug ne dépasse la longueur maximale acceptée par la colonne
post_name, fixée à 200 caractères dans le schéma natif de WordPress.

Autour des tables annexes, souvent oubliées
- Vérifier que la table
wp_postmetane contient pas de références codées en dur vers l’ancienne URL complète, un cas classique quand un import a stocké un lien absolu plutôt qu’un identifiant :SELECT * FROM wp_postmeta WHERE meta_value LIKE '%/ancien-prefixe/%' LIMIT 50; - Contrôler la table
wp_term_relationshipsetwp_termssi la nouvelle structure de permaliens inclut une taxonomie dans le chemin, pour s’assurer qu’aucun terme ne contient de caractères qui casseraient l’URL générée. - Rechercher les shortcodes ou blocs Gutenberg stockant une URL complète en dur dans
post_content, plutôt qu’une référence par identifiant, avec une recherche du domaine suivi de l’ancien schéma de chemin.
Après le changement : contrôler la cohérence
- Recompter les contenus publiés par type après la migration, pour confirmer qu’aucune ligne n’a disparu par erreur d’une jointure mal filtrée : le total doit être strictement identique au comptage initial.
- Comparer le nombre distinct de
post_nameavant et après : une différence indique soit des doublons créés par la migration, soit une écriture partielle interrompue en cours de route.
-- Comparaison finale, à exécuter après migration
SELECT
(SELECT COUNT(DISTINCT post_name) FROM wp_posts WHERE post_status = 'publish') AS distincts_apres,
(SELECT COUNT(*) FROM wp_migration_slugs) AS total_avant;
Le piège de la vérification par échantillon
Sur un catalogue de cette taille, contrôler manuellement une centaine de fiches choisies au hasard donne un faux sentiment de sécurité : un problème touchant 0,3 % des lignes, soit plusieurs centaines de fiches sur un total de plusieurs dizaines de milliers, passera presque toujours inaperçu dans un échantillon aussi restreint. Seules des requêtes d’agrégation portant sur la totalité de la table permettent de détecter ce type d’anomalie diffuse.
Une migration de permaliens réussie ne se juge jamais sur les fiches qu’on a pensé à vérifier, mais sur celles qu’on n’a pas pensé à chercher. D’où l’intérêt de comptages globaux plutôt que de contrôles ciblés.
En résumé
Cette liste de douze vérifications ne remplace pas la mise en place de redirections applicatives, un sujet à part entière, mais elle sécurise la phase la plus souvent négligée d’une migration de permaliens : la cohérence des données en base avant même que la première redirection ne soit écrite. Sur un catalogue volumineux, le temps passé à exécuter ces requêtes en amont reste toujours inférieur au temps nécessaire pour réparer des doublons de slug découverts plusieurs semaines après la mise en production, une fois que les moteurs de recherche ont déjà commencé à explorer les nouvelles URL.