Le WordPress d'aujourd'hui, décodé pour les développeurs

SEO & GEO

Douze vérifications SQL avant de migrer les permaliens d’un catalogue volumineux

Changer la structure des permaliens sur plusieurs dizaines de milliers de fiches sans plan de vérification en base de données expose à des doublons et des liens cassés durables.

Par WordPress Développement • 7 août 2024 • 4 min de lecture • Aucun commentaire
Douze vérifications SQL avant de migrer les permaliens d'un catalogue volumineux

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

  1. 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;
  2. Exporter la correspondance actuelle entre identifiant et slug, dans un fichier hors production : SELECT ID, post_name FROM wp_posts WHERE post_status = 'publish';
  3. Vérifier qu’aucun post_name n’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';
  4. Repérer les doublons de post_name existants 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

  1. 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;
  2. Ajouter une colonne pour le nouveau slug calculé et vérifier qu’aucune collision n’apparaît entre deux identifiants différents.
  3. 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.
L'essentiel à retenir : Les anciens slugs doivent être conservés avant toute écrasement ; Les doublons de slug apparaissent souvent après une génération automatique ; Une vérification par échantillon ne suffit jamais sur un gros catalogue

Autour des tables annexes, souvent oubliées

  1. Vérifier que la table wp_postmeta ne 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;
  2. Contrôler la table wp_term_relationships et wp_terms si 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.
  3. 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

  1. 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.
  2. Comparer le nombre distinct de post_name avant 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi