--- title: "Checklist SEO migration de site : gardez vos positions — Dardo" description: "Changez de plateforme ou de domaine sans perdre vos positions Google : inventaire des URL, redirections 1:1, vérifications du jour J et suivi sur 90 jours." url: "https://dardo.studio/fr/blog/checklist-seo-migration-site-web/" language: "fr" translations: {"en":"https://dardo.studio/en/blog/website-migration-seo-checklist/","es":"https://dardo.studio/es/blog/migrar-pagina-web-sin-perder-posicionamiento/","de":"https://dardo.studio/de/blog/website-relaunch-seo-checkliste/","it":"https://dardo.studio/it/blog/checklist-seo-migrazione-sito-web/","pt":"https://dardo.studio/pt/blog/checklist-seo-migracao-de-site/","nl":"https://dardo.studio/nl/blog/website-migratie-seo-checklist/","sv":"https://dardo.studio/sv/blogg/checklista-webbplatsmigrering-seo/","pl":"https://dardo.studio/pl/blog/migracja-strony-seo-checklista/","uk":"https://dardo.studio/uk/blog/website-migration-seo-checklist/","ru":"https://dardo.studio/ru/blog/website-migration-seo-checklist/","ar":"https://dardo.studio/ar/blog/website-migration-seo-checklist/","hi":"https://dardo.studio/hi/blog/website-migration-seo-checklist/","th":"https://dardo.studio/th/blog/website-migration-seo-checklist/","ja":"https://dardo.studio/ja/blog/website-migration-seo-checklist/","ko":"https://dardo.studio/ko/blog/website-migration-seo-checklist/","zh-Hans":"https://dardo.studio/zh-Hans/blog/website-migration-seo-checklist/","zh-Hant":"https://dardo.studio/zh-Hant/blog/website-migration-seo-checklist/"} updated: "2026-10-10T08:05:51.880Z" --- [Blog](https://dardo.studio/fr/blog/) # Checklist SEO de migration de site web : changer de plateforme ou de domaine sans perdre ses positions Les positions chutent rarement à cause de la nouvelle plateforme, mais parce que des URL qui généraient du trafic ne répondent plus. Une checklist, de l'inventaire des URL au 90e jour. Par [Nicolás Cerón](https://dardo.studio/fr/studio/) ·10 octobre 2026 ![Une vieille ville fortifiée et une ville moderne sur les deux rives d'un fleuve, de nuit, reliées par un pont de pierre où un trait de lumière carmin guide les voyageurs de l'ancienne porte jusqu'à la nouvelle ville.](https://dardo.studio/_astro/01M4GYEE19GWZ3941KFH1RTVRX_27BhoE.webp) ## La réponse courte Un site conserve ses positions lors d'une migration quand chaque URL qui génère du trafic ou des liens répond toujours après la mise en ligne : le même contenu à la même adresse, ou une redirection permanente côté serveur vers son équivalent le plus proche. La plupart des problèmes de migration viennent d'une URL que personne n'avait mise dans la liste. Le [guide de Google sur les déménagements de site avec changement d'URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) pose les bases : associer chaque ancienne URL à une nouvelle, utiliser des redirections permanentes côté serveur comme 301 ou 308, les conserver « généralement au moins 1 an » et « s'attendre à des fluctuations temporaires du classement du site pendant le déménagement ». Le même guide conseille de ne changer qu'un élément à la fois : d'abord le nouveau domaine, ensuite la nouvelle structure. La [documentation Google sur le changement d'adresse](https://support.google.com/webmasters/answer/9370220) est plus directe. Si vous combinez un déménagement avec une refonte du contenu et de la structure des URL, « vous constaterez probablement une perte de trafic » le temps que Google réévalue chaque page. Si vous avez besoin des deux, planifiez la [refonte](https://dardo.studio/fr/services/refonte-de-site-web/) comme une phase à part. ## Trois types de migration | Migration | Ce qui change | Redirections | Search Console | | ----------------------------------------------------- | --------------------------------------------------- | ------------------------------------ | ------------------------------------------------- | | Hébergement uniquement | Serveurs ou CDN ; toutes les URL restent identiques | Aucune | Surveiller l'exploration et l'indexation | | Plateforme (Wix vers WordPress, WordPress vers Astro) | CMS, templates et en général certains schémas d'URL | Toutes les URL dont le chemin change | Nouveau sitemap, puis suivi | | Domaine ou sous-domaine | Toutes les URL | Toutes | Changement d'adresse pour chaque variante validée | Pour une migration d'hébergement seul, le [guide d'hébergement](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes) de Google recommande de réduire le TTL du DNS « au moins une semaine avant le déménagement » et de laisser tourner les anciens serveurs jusqu'à ce que leur trafic tombe à zéro. Une courte baisse du rythme d'exploration après la mise en ligne est normale. ## Avant la migration : lister tout ce qui possède une URL Une table de redirections ne vaut que ce que vaut la liste des anciennes URL sur laquelle elle repose, et chaque source oublie quelque chose. ### Explorer le site en production Lancez un crawl du site actuel et exportez chaque URL avec son code de statut, son titre, sa meta description, ses balises canonical et hreflang, puis ajoutez toutes les URL du sitemap XML. Google suggère aussi de consulter les logs du serveur pour repérer les URL visitées au moins une fois récemment. ### Récupérer les pages de destination dans Search Console et l'analytics Dans le [rapport de performances](https://support.google.com/webmasters/answer/7576553) de la Search Console, exportez l'onglet Pages sur la plus longue période possible, puis faites de même pour les pages de destination organiques dans votre outil d'analytics. Ces pages apportent le trafic et les contacts : chacune est donc vérifiée à la main au lancement. ### Identifier ce qui pointe vers vous Le [rapport sur les liens](https://support.google.com/webmasters/answer/9049606) affiche vos pages les plus liées, mais ses tableaux « sont limités à 1 000 lignes » et Google précise qu'il ne s'agit pas d'une liste exhaustive. Croisez-le avec l'outil de backlinks que vous utilisez. ### Lister formulaires, intégrations et médias Notez chaque formulaire et la destination de ses envois, chaque outil intégré (réservation, chat, cartes, paiements) et chaque fichier vers lequel des internautes font un lien direct. Le guide de Google demande d'inclure dans le plan « les vidéos, images, fichiers JavaScript et CSS », car ces URL se déplacent comme n'importe quel autre contenu. ### Construire la table de redirections Une ligne par ancienne URL : ancienne URL, nouvelle URL, code de statut, notes, testé. Quatre règles : - Associez chaque ancienne URL à son équivalent le plus proche. Rediriger de nombreuses anciennes URL vers une seule destination sans rapport, comme la page d'accueil, « peut être traité comme une erreur soft 404 ». - Si plusieurs anciennes pages ont été fusionnées en une seule, redirigez-les toutes vers celle-ci. - Si une page n'a pas d'équivalent, faites-lui renvoyer un code 404 ou 410, pas une redirection. - Conservez les chemins inchangés partout où la nouvelle plateforme le permet. ## Pendant la construction : les redirections et ce qui doit les accompagner ### Utiliser des redirections 301 ou 308 côté serveur, en 1:1 La [documentation de Google sur les redirections](https://developers.google.com/search/docs/crawling-indexing/301-redirects) indique que 301 et 308 signalent que « la cible de la redirection doit être canonique » et recommande « une redirection permanente côté serveur chaque fois que possible ». Les codes temporaires (302, 303, 307) ne le font pas, et les redirections JavaScript sont un dernier recours. Redirigez directement vers l'URL finale. Les robots de Google suivent [jusqu'à 10 redirections successives](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes), mais le guide de déménagement conseille de « rediriger directement vers la destination finale ». Si une migration précédente a laissé des redirections, faites-les aussi pointer vers les nouvelles URL finales. Vérifiez le code de statut par défaut de l'outil qui gère vos redirections. Sur Cloudflare Workers, où Dardo héberge les sites qu'il conçoit, un fichier \_redirects utilise 302 sauf si vous écrivez 301 sur chaque ligne, accepte jusqu'à 2 000 redirections statiques et 100 dynamiques, et ne peut pas faire correspondre des paramètres de requête. Les permaliens simples de WordPress (/?p=123) nécessitent donc une logique de redirection dans le code du Worker. ### Quand renvoyer plutôt un 404 ou un 410 Les pages minces, les offres expirées et les doublons n'ont pas besoin de survivre. Le guide de Google indique que le contenu que vous ne déplacez pas doit « renvoyer correctement un code HTTP 404 ou 410 », et les robots de Google traitent tous les codes 4xx sauf 429 de la même façon : l'URL sort de l'index. ### Reprendre métadonnées, canonicals et hreflang - **Titres et meta descriptions.** Migrez-les champ par champ au lieu de laisser les nouveaux templates les générer. - **Canonicals.** Chaque nouvelle page porte une balise canonical auto-référencée avec sa nouvelle URL. Le [guide de Google sur la canonicalisation](https://developers.google.com/search/docs/crawling-indexing/canonicalization) décrit la canonical comme « une indication, pas une règle » : canonicals, redirections et sitemap doivent donc être cohérents. - **Hreflang.** Chaque version linguistique « doit se référencer elle-même ainsi que toutes les autres versions linguistiques », et « si deux pages ne pointent pas l'une vers l'autre, les balises seront ignorées », selon le [guide de Google sur les versions localisées](https://developers.google.com/search/docs/specialty/international/localized-versions). Mettez à jour chaque annotation avec les nouvelles URL. ### Données structurées, liens internes et URL d'images - **Données structurées.** Reconstruisez les balisages Organization, Breadcrumb, Article ou Product dans les nouveaux templates et testez-les avec le test des résultats enrichis. Le guide de déménagement de Google n'en parle pas : on les perd donc facilement. - **Liens internes.** Faites-les pointer vers les nouvelles URL, pas vers des redirections. - **Images et fichiers.** Conservez des noms de fichiers descriptifs et des textes alternatifs, et redirigez les anciennes URL d'images et de PDF qui reçoivent des liens ou du trafic depuis la recherche d'images. ### Analytics et consentement Réinstallez l'outil d'analyse, les événements de conversion et les pixels publicitaires, puis testez-les sur l'environnement de préproduction. Si l'ancien site demandait le consentement aux cookies, le nouveau doit le demander de la même façon avant le déclenchement de ces balises. ## Ce qui casse le plus souvent, plateforme par plateforme Ces notes proviennent de la documentation propre à chaque plateforme, à la date d'octobre 2026. Elles décrivent le fonctionnement des plateformes, pas des défauts. | Plateforme | Structures d'URL à mapper | Limites d'export et de redirection | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | WordPress | Les [permaliens](https://wordpress.org/documentation/article/customize-permalinks/) peuvent être simples (/?p=N), basés sur la date ou sur le titre de l'article. Les archives de catégories et d'étiquettes conservent toujours une base telle que /category/. | Depuis [WordPress 6.4](https://make.wordpress.org/core/2023/10/16/changes-to-attachment-pages/), les pages de fichiers joints sont désactivées sur les nouvelles installations, mais restent actives sur les sites mis à jour ; les sites plus anciens peuvent donc avoir une URL par fichier téléversé. | | Webflow | Les éléments du CMS se trouvent dans les pages de collection. | L'[export du code](https://help.webflow.com/hc/en-us/articles/33961386739347-How-do-I-export-my-Webflow-site-code) exclut le contenu du CMS, l'e-commerce, les comptes utilisateurs, le traitement des formulaires, la recherche interne et les pages localisées, et nécessite un forfait Workspace. Les collections s'exportent séparément en CSV. | | Wix | Les articles de blog se trouvent sous un préfixe /post/ qui peut être renommé, mais pas supprimé. Sur WordPress, une structure de permaliens personnalisée de type /post/%postname%/ permet de le conserver. | Un site Wix [« doit fonctionner sur les serveurs de Wix »](https://support.wix.com/en/article/exporting-or-embedding-your-wix-site-elsewhere) : le quitter implique donc de reconstruire les pages. | | Framer | Modifier un sous-chemin [ne met pas à jour les règles de redirection existantes](https://www.framer.com/help/articles/how-to-setup-redirects-to-maintain-seo-ranking/) ; d'anciennes règles peuvent donc pointer vers des chemins inexistants. | Les sites sont publiés en HTML, CSS et JavaScript standard ; le [contenu du CMS s'exporte via des plugins](https://www.framer.com/help/articles/porting-your-data-from-framer/) en CSV ou JSON. | | Squarespace | Les [correspondances d'URL](https://support.squarespace.com/hc/en-us/articles/205815308-URL-mappings) acceptent une variable \[name\] pour des collections entières, par exemple /blog/\[name\] -> /posts/\[name\] 301. | L'[export](https://support.squarespace.com/hc/en-us/articles/206566687-Exporting-your-site) est un fichier XML WordPress comprenant une page de blog, des pages de mise en page et des galeries, mais ni pages de boutique, ni blocs produit, vidéo ou audio, ni CSS personnalisé. Les correspondances d'URL ne peuvent pas rediriger les URL d'images ou de fichiers et sont limitées à environ 2 500 lignes. | | Shopify | Les URL de la boutique se trouvent sous des chemins tels que /products/, /collections/, /pages/ et [/blogs//](https://shopify.dev/docs/api/liquid/objects/blog) ; Shopify considère /products et /collections comme fixes. | Les [redirections](https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect) ne fonctionnent qu'à partir d'URL qui ne chargent plus de page, et les boutiques sont limitées à 100 000 (20 000 000 avec Plus). | Quitter Wix implique de reconstruire chaque page ; quitter Squarespace implique d'importer ce que couvre l'export et de reconstruire le reste. Passer à Shopify modifie généralement les URL des produits, et le plan de redirection doit donc couvrir chaque produit. ## Le jour du lancement 1. **DNS.** Si l'hébergement ou le DNS change, réduisez le TTL au moins une semaine à l'avance. 2. **Blocages d'exploration.** Supprimez les balises `noindex` de préproduction et les blocages du fichier robots.txt. Google recommande de lister toutes les URL où vous avez utilisé `noindex` pendant le développement. 3. **Redirections.** Mettez-les en ligne dans la même mise en production que le nouveau site. 4. **Test des redirections.** Passez tout le plan de redirection dans un script : chaque ancienne URL renvoie un code 301 ou 308 vers la bonne URL finale en une seule étape, et cette URL renvoie un code 200. 5. **Search Console.** Validez le nouveau site et soumettez le nouveau sitemap, ainsi qu'un sitemap des anciennes URL pour qu'elles soient réexplorées. Les avertissements indiquant que ces URL sont redirigées sont normaux. 6. **Changement d'adresse.** En cas de changement de domaine, soumettez-le depuis une propriété dont vous êtes propriétaire des deux côtés, avec le même compte Google, pour chaque variante de l'ancien domaine, avec et sans www. 7. **Parcours clés.** Envoyez un vrai formulaire, effectuez un paiement test et vérifiez que les événements d'analyse arrivent bien. 8. **Vos propres liens.** Mettez à jour [les profils sociaux, les publicités et les fiches d'annuaires](https://dardo.studio/fr/blog/checklist-lancement-rebranding/). ## Les 30, 60 et 90 jours suivants ### Jours 1 à 30 : attendez-vous à des variations Les positions peuvent fluctuer « pendant que Google réexplore et réindexe votre site », et « pour un site de petite ou moyenne taille, la plupart des pages peuvent mettre quelques semaines à bouger, et davantage pour les sites plus grands ». Surveillez : - **Rapports d'indexation et de sitemap.** Les URL indexées diminuent sur l'ancien site et augmentent sur le nouveau. - **Performances par page.** Les nouvelles URL commencent à obtenir des impressions et des clics. - **Journaux serveur et erreurs 404.** Chaque 404 inattendue correspond à une ligne manquante dans le plan. Vérifiez chaque jour pendant deux semaines. ### Jours 31 à 60 : comparer avec la référence Comparez vos principales pages d'atterrissage avec leurs nouvelles URL. Pour toute page qui a perdu des clics, vérifiez dans l'ordre : la redirection mène-t-elle à la bonne page en une seule étape, le contenu ou le titre ont-ils changé, les liens internes pointent-ils toujours vers elle, figure-t-elle dans le sitemap. Demandez ensuite aux sites qui font les backlinks les plus précieux de les mettre à jour. ### Jour 90 et au-delà : conservez les redirections Le guide de Google recommande de conserver les redirections « généralement au moins 1 an » et, du point de vue des utilisateurs, de « envisager de les conserver indéfiniment ». Pour les changements de domaine, la page Changement d'adresse fixe un minimum de 180 jours, après lequel Google considère l'ancien site comme sans rapport s'il est toujours explorable. Elle recommande aussi de continuer à payer l'ancien domaine « pendant au moins un an » pour que personne d'autre ne puisse l'acheter. ## La check-list | Phase | Tâche | Terminé quand | | ------------ | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Avant | Explorer le site, le sitemap et les journaux serveur | Une liste unique de toutes les anciennes URL avec leur code de statut | | Avant | Exporter les pages d'atterrissage et les pages les plus liées | Pages principales et cibles de backlinks signalées dans le plan | | Avant | Lister les formulaires, intégrations, scripts et fichiers | Chacun a un responsable et une solution prévue sur le nouveau site | | Avant | Construire le plan de redirection | Chaque ancienne URL a une cible ou une décision 404/410 | | Construction | Redirections 301 ou 308 côté serveur | Une seule étape, pas de chaînes, pas de redirections en masse vers la page d'accueil | | Construction | Titres, descriptions, canoniques, hreflang | Identiques aux anciennes pages ; canoniques et hreflang utilisent les nouvelles URL | | Construction | Données structurées, liens internes, URL d'images | Le test des résultats enrichis est réussi ; aucun lien interne ne passe par une redirection | | Construction | Analytics, conversions et consentement | Les événements se déclenchent en préproduction, uniquement après consentement si nécessaire | | Lancement | Supprimer noindex et les blocages du robots.txt | Les nouvelles URL sont explorables | | Lancement | Tester le plan de redirection | Chaque ligne renvoie le code et la cible attendus | | Lancement | Search Console : validation, sitemaps, changement d'adresse | Soumis sans erreur critique | | Après | Surveiller l'indexation, les 404 et les performances | Les anciennes URL reculent, les nouvelles gagnent des impressions | | Après | Conservez les redirections et l'ancien domaine | Au moins un an | ## Se faire accompagner pour une migration Dardo migre les sites vers des builds Astro sur mesure hébergés sur Cloudflare Workers, et la carte des redirections est un livrable que nous testons avant le lancement et remettons avec le site. Découvrez notre service de [migration de site web](https://dardo.studio/fr/services/migration-de-site-web/), ou de [refonte de site web](https://dardo.studio/fr/services/refonte-de-site-web/) si la migration s'accompagne d'un nouveau design. Ou [dites-nous ce que vous migrez](https://dardo.studio/fr/contact/). [Nicolás Cerón](https://dardo.studio/fr/studio/) Nicolás Cerón est le fondateur de Dardo, un studio de branding, de design et de développement web basé à Bogotá, en Colombie. ## Continuez à explorer. - [Service · **Migration de site web sans perdre votre référencement SEO**](https://dardo.studio/fr/services/migration-de-site-web/) - [Votre projet · **Lançons la conversation**](https://dardo.studio/fr/contact/)