Migrer un site WebDev vers WordPress

C'est la trajectoire de sortie la plus naturelle pour les sites construits avec WebDev : vitrines, catalogues, portails de contenu avec quelques formulaires. WordPress en couvre le périmètre avec un écosystème sans équivalent, et l'enjeu du chantier n'est pas technique : il est SEO. La refonte de sites avec préservation du référencement est le métier historique de Smartshift ; voici comment nous la menons depuis un existant WebDev.

Pourquoi WordPress pour un site issu de WebDev

Un site WebDev dépend d'un serveur d'application propriétaire pour s'exécuter et d'un développeur WLangage pour évoluer. Le même site sous WordPress tourne sur n'importe quel hébergement mutualisé ou infogéré, et n'importe quelle agence ou webmaster peut le faire vivre. Pour un site dont la vocation est de publier du contenu et de générer des contacts, cette banalisation est exactement ce que l'on recherche : moins de dépendance, moins de coûts fixes, plus d'autonomie éditoriale.

• Édition de contenu par vos équipes, sans développeur, avec validation et brouillons.
• Écosystème SEO mature : gestion fine des balises, sitemaps, données structurées.
• Formulaires, prise de rendez-vous, newsletter : l'outillage marketing standard s'installe au lieu de se développer.
• Hébergement libre : du mutualisé au dédié infogéré, sans serveur d'application propriétaire.

Reprise des contenus et de la structure

La reprise commence par un inventaire exhaustif : crawl du site existant, export des contenus depuis la base (souvent HFSQL), recensement des gabarits de pages réels. Chaque type de contenu WebDev trouve sa forme WordPress : pages, articles, types de contenus personnalisés pour les catalogues ou les fiches. Les contenus se migrent par import automatisé puis relecture, jamais par copier-coller manuel qui perd les liens internes et les images.

Erreurs fréquentes lors de la reprise de contenu

• Migrer les textes sans les images ni leurs attributs alternatifs, ce qui casse à la fois l'expérience utilisateur et le référencement acquis sur ces visuels.
• Recréer les gabarits de pages en s'appuyant uniquement sur le rendu visuel actuel, sans vérifier la hiérarchie de titres (H1, H2) qui portait le référencement.
• Oublier les pages orphelines : celles qui ne sont plus accessibles depuis le menu mais qui reçoivent encore du trafic ou des liens externes.
• Reformuler les contenus existants au moment de la migration : mélanger changement de plateforme et refonte éditoriale complique la recette et brouille l'analyse d'un éventuel écart de trafic après bascule.

Plan de redirections 301 : le point critique

C'est ici que les migrations ratées perdent leur trafic. Les URLs générées par WebDev (pages dynamiques, paramètres, extensions) ne ressembleront pas aux URLs propres du nouveau site : chaque ancienne URL indexée doit rediriger en 301 vers sa correspondante exacte, définie dans un tableau de mapping écrit AVANT la mise en ligne. Nous croisons trois sources pour ne rien oublier : le crawl du site, les pages indexées par Google, et les URLs qui reçoivent réellement du trafic ou des backlinks.

La recette SEO fait partie du projet au même titre que la recette fonctionnelle : vérification des redirections une à une, des balises, du maillage interne, puis surveillance de l'indexation dans les semaines qui suivent la bascule.

Formulaires, espaces clients et connexions au SI

Un site WebDev embarque parfois plus qu'un site : formulaires alimentant la gestion interne, espace client, consultation de données métier. Chaque usage se traite explicitement : les formulaires simples se refont nativement, les échanges avec le SI passent par des connecteurs ou une petite API dédiée, et un véritable espace client applicatif peut justifier de séparer le site (WordPress) de l'application (stack web métier), chacun faisant ce qu'il fait le mieux.

Points de vigilance à l'audit d'un site WebDev

Avant de chiffrer une migration, l'audit d'un site WebDev vérifie systématiquement quatre points. Le volume réel de pages indexées par les moteurs de recherche, souvent différent du nombre de pages visibles dans le menu. La présence de contenus générés dynamiquement (recherche interne, filtres, pages calculées) qui n'ont pas d'équivalent direct en page WordPress statique. Les dépendances techniques du site vers d'autres briques du SI, qui doivent être identifiées avant de fixer un périmètre de migration. Et l'état réel du référencement existant (positions, trafic organique, backlinks reçus) qui sert de ligne de base pour mesurer la réussite de la bascule.

Ce diagnostic initial conditionne le calendrier et le périmètre du projet plus que la seule taille du site. Un site de cinquante pages avec des dépendances techniques nombreuses peut demander plus de travail de reprise qu'un site de deux cents pages purement éditoriales. C'est pour cela que le chiffrage se fait après l'audit, jamais avant.

Autonomie des équipes après bascule

La migration se termine par un transfert réel : formation des équipes éditoriales, documentation des gabarits, et un site que vous pouvez faire évoluer sans nous. C'est un engagement de méthode : la sortie d'une dépendance (serveur WebDev, développeur unique) ne doit pas en créer une nouvelle envers votre prestataire de migration.

Cas client

Nous détaillons une bascule complète de site WebDev vers WordPress, avec sa méthode de reprise et son plan de redirections, dans nos études de cas de migration : le parcours type, les pièges rencontrés et les invariants qui font réussir ce chantier.