Combien de types de contenu différents une plateforme événementielle tierce héberge-t-elle réellement sous une seule structure d’URL plate ? Sur le cas traité ici, la réponse est cinq : les pages d’événements individuels, les profils d’intervenants, les lieux, les partenaires et les articles de blog, tous mélangés sous un même préfixe générique du type /page/identifiant, sans distinction structurelle.
Cette checklist ne traite pas le design de la migration ni le choix du thème, mais uniquement les points de vigilance liés à la structure d’URL héritée, qui conditionnent directement la préservation du référencement acquis sur la plateforme d’origine.
Identifier chaque type de contenu avant de migrer quoi que ce soit
La première tâche consiste à extraire, pour chacun des cinq types de contenu repérés, la liste complète des URL existantes avec leur volume de trafic organique respectif. Un événement passé depuis plusieurs années conserve parfois un trafic résiduel non négligeable, notamment lorsque son nom continue d’être recherché par des participants souhaitant retrouver des informations ou des photos de l’édition concernée.
- Extraire la liste des URL d’événements passés et à venir, avec leur date et leur statut.
- Extraire séparément les profils d’intervenants, souvent réutilisés d’une édition à l’autre.
- Faire de même pour les lieux, les partenaires et les articles de blog, chacun sur sa propre liste.
Choisir une structure de types de contenu personnalisés adaptée
WordPress permet de recréer cette diversité proprement grâce aux types de contenu personnalisés : un type evenement, un type intervenant, un type lieu, chacun avec sa propre structure de permalien définie via l’argument rewrite lors de l’enregistrement du type de contenu. Cette organisation, absente de la plateforme d’origine, clarifie à la fois la navigation pour les visiteurs et la lecture du site pour les robots d’exploration.
Construire le plan de redirection type par type
Chaque liste d’URL extraite à l’étape précédente donne lieu à son propre tableau de correspondance vers la nouvelle URL WordPress. Un événement passé sous l’ancienne URL /page/1247 doit rediriger vers une URL du type /evenements/nom-de-l-edition/, et non vers une page générique de liste d’événements qui ferait perdre toute pertinence à la redirection.
Le cas des profils d’intervenants récurrents
Un même intervenant, présent sur plusieurs éditions successives, disposait parfois de plusieurs profils distincts sur la plateforme d’origine, un par édition. La migration est l’occasion de fusionner ces profils en une seule fiche WordPress par intervenant, avec toutes les anciennes URL de ses différents profils redirigées vers cette fiche unique.
Vérifier le sitemap avant l’ouverture au public
Une fois les cinq types de contenu personnalisés en place, le sitemap natif de WordPress génère automatiquement une entrée distincte par type, consultable à des adresses comme /wp-sitemap-posts-evenement-1.xml. Cette séparation par type permet de vérifier visuellement, avant l’ouverture, que chaque catégorie de contenu est bien représentée dans le volume attendu, sans type de contenu oublié ou mal configuré.
Derniers points à cocher avant la bascule
- Tester un échantillon de redirections pour chacun des cinq types de contenu, pas seulement pour les événements les plus visibles.
- Vérifier que les anciennes pages de recherche interne de la plateforme d’origine, souvent bien indexées, redirigent vers l’équivalent le plus proche côté WordPress plutôt que vers une erreur 404.
- Confirmer que le fichier
robots.txtdu nouveau site n’exclut aucun des nouveaux types de contenu par erreur, un oubli fréquent lors de la configuration initiale d’un type de contenu personnalisé.
En résumé
Une plateforme événementielle tierce dissimule souvent, sous une structure d’URL plate et peu lisible, une diversité réelle de types de contenu que WordPress permet de restituer bien plus clairement. Cette clarification structurelle profite au référencement à condition que chaque type soit cartographié, redirigé et vérifié séparément avant la mise en ligne, plutôt que traité comme un bloc unique et indifférencié.
