La migration d'URL fait partie de ces chantiers qui empêchent de dormir. Des centaines de sous-pages, des redirections, le hreflang, les sitemaps, le risque de perdre ses positions dans Google - dans le modèle classique, c'est un projet qui se compte en semaines et un budget d'agence conséquent.

Nous venons de faire passer deux marques à une structure /pl + /en propre d'un coup (plusieurs centaines d'URL), en un seul après-midi, sans interruption et sans un seul lien cassé. Ces marques sont VineyardElf et WineryElf - des plateformes technologiques pour vignobles et chais issues de notre écurie, qui tournent sur le moteur même qui propulse le nouveau Siteor. Et c'est ce moteur - un CMS bâti autour d'une API - associé à l'IA qui a transformé la partie fastidieuse et risquée du travail en non-sujet.

Voici comment cela se passe en pratique et pourquoi cette combinaison change les règles du jeu.

Pourquoi /pl et /en (et non des domaines séparés)

Pour une marque unique avec plusieurs langues, la meilleure structure, ce sont les sous-répertoires : votredomaine.com/pl/... et votredomaine.com/en/.... C'est ainsi que procèdent Stripe, Apple ou IKEA. La raison est simple : toute l'autorité SEO reste sur un seul domaine, et Google reçoit un signal clair sur la langue de chaque contenu. Les alternatives (domaines ou sous-domaines séparés) diluent la force du domaine et coûtent plus cher à entretenir.

Le hic, c'est que passer à une telle structure touche littéralement chaque sous-page. Et c'est là que le vrai travail commence.

Ce qu'il faut gérer (et ce qui déraille d'habitude)

Une migration bien faite, ce n'est pas seulement changer des adresses. C'est un ensemble d'éléments liés, dont chacun peut se casser en silence :

1. Changer les chemins de toutes les sous-pages en /pl/... et /en/...
2. Des redirections 301 des anciennes adresses vers les nouvelles - sans chaînes (une ancienne adresse ne doit pas rebondir par trois étapes)
3. Le hreflang et le canonical pointant vers les nouvelles adresses correctes - et non celles d'avant la migration
4. Un sitemap avec l'ensemble complet des nouvelles URL et sa soumission à Google Search Console
5. La redirection de la page d'accueil vers /pl ou /en selon la langue du navigateur
6. Un sélecteur de langue qui mène vers la page équivalente, et non vers l'accueil
7. Les liens à l'intérieur du contenu - ceux intégrés dans les articles et les sous-pages doivent aussi être mis à jour
8. L'analytique - vérifier que Google Tag Manager n'a pas de règles épinglées aux anciens chemins

Faites l'un de ces points à la main sur plusieurs centaines de pages et vous avez la garantie d'une coquille, d'un lien oublié ou d'un canonical pointant vers une adresse qui n'existe plus. Et chacune de ces erreurs est une perte bien réelle dans Google.

Comment Siteor s'y prend avec l'IA

Le secret, c'est que Siteor est API-first : chaque page, chaque gabarit, chaque article est accessible et modifiable via une API. Cela signifie que l'IA peut traiter tout le site comme des données - lire l'état, calculer les changements, les appliquer en masse et vérifier le résultat immédiatement. Au lieu de cliquer des centaines de fois dans le panneau, l'IA travaille sur toute la structure d'un coup.

En pratique, cela s'est déroulé ainsi :

Reconnaissance. L'IA a récupéré l'inventaire complet des pages via l'API, identifié lesquelles étaient polonaises et lesquelles anglaises, et calculé la liste exacte des changements. Des surprises sont apparues d'emblée - par exemple, certaines sous-pages plus anciennes avaient d'anciennes adresses codées en dur dans leurs données hreflang. Sans ce balayage, elles ne seraient apparues que dans Google, des semaines plus tard.

Exécution. Changement des chemins en /pl et /en, remappage des redirections pour que chaque ancienne adresse mène en un seul saut vers sa nouvelle adresse finale (zéro chaîne), mise à jour du hreflang et des liens dans le contenu, génération d'un sitemap complet, mise en place de la redirection de l'accueil selon la langue du navigateur. Le tout de façon cohérente, avec une sauvegarde avant chaque changement.

Vérification. C'est la partie qu'un humain saute d'habitude par fatigue - et que l'IA fait avec minutie. Après la migration, elle a balayé tout le site et vérifié :

• si le canonical et l'og:url pointent vers les nouvelles adresses (zéro reste des anciennes)
• s'il y a des chaînes de redirection
• si chaque URL du sitemap renvoie un 200 (et non une redirection ou un 404)
• s'il reste un seul lien interne cassé dans le contenu
• si le sélecteur de langue mène vers le bon équivalent
• si Google Tag Manager a des règles épinglées aux anciens chemins (ce n'était pas le cas - l'analytique suit par adresse automatiquement, la migration ne l'a donc pas touchée)

L'audit est revenu propre. Et là où quelque chose dépassait tout de même - par exemple des sous-pages encore affichées en polonais parce que leur version anglaise n'était pas terminée - l'IA les a simplement traduites, en préservant toute la mise en page, les noms propres et la terminologie métier.

Le résultat

Deux marques entièrement passées à /pl + /en. Plusieurs centaines d'adresses, un jeu complet de redirections 301, un hreflang correct, des sitemaps soumis à Google, un sélecteur de langue qui mène vers la bonne page équivalente. Sans interruption, sans liens perdus, en un après-midi au lieu de semaines.

À retenir

La migration d'URL n'a pas à être un projet que l'on redoute. Quand le CMS est bâti autour d'une API - comme Siteor - et que l'IA prend en charge le travail ingrat et risqué, on obtient ce que le workflow classique ne peut pas offrir : l'échelle et la rigueur en même temps. L'IA ne fatigue pas à la centième sous-page, n'oublie pas une redirection et ne saute pas la vérification. Et vous obtenez un résultat qui exigerait normalement une équipe et un budget d'agence.

Si vous gérez un site multilingue et que vous songez à mettre de l'ordre dans vos adresses - c'est exactement le genre de tâche où Siteor associé à l'IA montre les dents.