Google précise quand l'outil de changement d'adresse est nécessaire

La page « Migrer un site » a été mise à jour le 11 septembre 2026. Elle conditionne désormais explicitement la demande de changement d'adresse à un changement de domaine ou de sous-domaine, et énumère trois cas où l'outil ne sert à rien.

Migrer un site ↗ page datée du 11 septembre 2026 par Google

L'étape 4 de la procédure de migration s'appelait jusqu'ici « Envoyez une demande de changement d'adresseOutil de la Search Console par lequel on signale à Google que le contenu d'un site passe d'une adresse à une autre. pour l'ancien site dans la Search Console », sans condition. Elle s'intitule maintenant « Si vous changez de nom de domaine ou de sous-domainePréfixe placé devant un nom de domaine, comme la partie « boutique » dans boutique.example.com, qui constitue une adresse distincte aux yeux de Google., envoyez une demande de changement d'adresse pour l'ancien site dans la Search Console ». La consigne devient conditionnelle, et un paragraphe entier vient délimiter son périmètre.

Ce paragraphe est la vraie nouveauté : « Vous n'avez besoin de cet outil que lorsque vous passez d'un domaine ou d'un sous-domainePréfixe placé devant un nom de domaine, comme la partie « boutique » dans boutique.example.com, qui constitue une adresse distincte aux yeux de Google. à un autre (par exemple, de example.com à example.net, ou de a.example.com à b.example.com). Vous n'en avez pas besoin pour passer de HTTP à HTTPS, pour basculer entre www et non-www sur le même domaine, ou pour déplacer des chemins d'accès au sein du même domaine. » L'ancienne version ne mentionnait qu'un seul cas d'exclusion, la migration de HTTP vers HTTPS. Les deux autres, le passage entre www et non-www sur un même domaine et la réécriture de chemins d'URL à l'intérieur du même domaine, sont ajoutés ici. Le déplacement de example.com/page.php?id=1 vers example.com/widget, que la page cite en introduction comme un cas de migration à part entière, relève donc des redirections seules, sans démarche dans la Search Console.

La page ne dit pas pourquoi l'outil est inutile dans ces trois cas, et il ne faut rien lui faire dire de plus : elle énonce un périmètre, pas un mécanisme.

À l'inverse, pour un vrai changement de nom de domaine, la consigne est resserrée d'un cran. Le texte parle maintenant de « toutes les sous-domainePréfixe placé devant un nom de domaine, comme la partie « boutique » dans boutique.example.com, qui constitue une adresse distincte aux yeux de Google.) pour lesquelles vous avez prouvé dans la Search Console que le site vous appartient.">variantes validéesLes différentes écritures d'une même adresse (avec ou sans www, en HTTP ou HTTPS, avec ou sans sous-domaine) pour lesquelles vous avez prouvé dans la Search Console que le site vous appartient. de l'ancien domaine (y compris les sous-domaines et les versions avec et sans "www") », là où il disait auparavant « tous les sous-domaines et les variantes avec et sans www ». L'exemple reste le même : envoyer des demandes depuis en.example.com, www.example.com et example.com vers new-example.net, « même si vous n'utilisez pas activement ces variantes ». Et la page rappelle que ces variantes doivent être validées dans la Search Console, ce qui est la condition pratique pour pouvoir déposer la demande.

Deux autres phrases ont été réécrites dans un sens plus prudent. Sur les délais, on lisait « quelques semaines peuvent être nécessaires au déplacement de la majorité des pages d'un site Web de taille moyenne dans notre index » ; on lit maintenant « il peut s'écouler quelques semaines ou plus avant que Google ne commence à afficher progressivement les nouvelles URL à la place des anciennes (et encore plus longtemps pour les sites plus volumineux) ». Le repère n'est plus le moment où la majorité des pages a basculé, mais le moment où le remplacement commence à être visible. C'est un horizon annoncé plus lointain et plus flou, utile à avoir en tête quand on doit justifier auprès d'un client une absence de mouvement trois semaines après une migration.

Sur l'exploration, « la vitesse d'exploration de GooglebotLe programme automatique de Google qui parcourt les pages du Web pour les récupérer. dépend de la taille de votre site en plus d'autres facteurs » devient « dépend de la taille de votre site et de la vitesse d'exploration possibleLe rythme maximal auquel Google peut demander des pages à votre serveur sans le surcharger. ». Le facteur flou est remplacé par un facteur nommé, qui renvoie à ce que le serveur est capable d'encaisser. La définition de la fin de migration, elle, ne bouge pas : elle est atteinte lorsque Googlebot a accédé au moins une fois à toutes les URL de l'ancien et du nouveau site, une URL après l'autre.

La mention selon laquelle les redirections 301 et les autres redirections permanentesRéponse du serveur indiquant qu'une adresse a définitivement été remplacée par une autre, le code 301 en étant la forme la plus courante. n'entraînent pas de baisse de PageRankMesure historique de Google qui évalue la valeur d'une page à partir des liens qui pointent vers elle. est inchangée sur le fond ; seule la tournure a été retouchée.

Les termes employés7 DÉFINITIONS
changement d'adresse
Outil de la Search Console par lequel on signale à Google que le contenu d'un site passe d'une adresse à une autre.
sous-domaine
Préfixe placé devant un nom de domaine, comme la partie « boutique » dans boutique.example.com, qui constitue une adresse distincte aux yeux de Google.
variantes validées
Les différentes écritures d'une même adresse (avec ou sans www, en HTTP ou HTTPS, avec ou sans sous-domaine) pour lesquelles vous avez prouvé dans la Search Console que le site vous appartient.
Googlebot
Le programme automatique de Google qui parcourt les pages du Web pour les récupérer.
redirections permanentes
Réponse du serveur indiquant qu'une adresse a définitivement été remplacée par une autre, le code 301 en étant la forme la plus courante.
PageRank
Mesure historique de Google qui évalue la valeur d'une page à partir des liens qui pointent vers elle.
vitesse d'exploration possible
Le rythme maximal auquel Google peut demander des pages à votre serveur sans le surcharger.

Citations à l’appui

Chaque affirmation ci-dessus s’appuie sur un extrait littéral de la source officielle.

Vous n'avez besoin de cet outil que lorsque vous passez d'un domaine ou d'un sous-domaine à un autre (par exemple, de `example.com` à `example.net`, ou de `a.example.com` à `b.example.com`). Vous n'en avez pas besoin pour passer de HTTP à HTTPS, pour basculer entre www et non-www sur le même domaine, ou pour déplacer des chemins d'accès au sein du même domaine.
Le périmètre de l'outil de changement d'adresse est désormais délimité, avec trois cas d'exclusion explicites.
4. **Si vous changez de nom de domaine ou de sous-domaine, envoyez une demande de [changement d'adresse](https://support.google.com/webmasters/answer/9370220?hl=fr) pour l'ancien site dans la Search Console**.
L'étape 4 de la procédure est devenue conditionnelle.
**Pour les migrations HTTP vers HTTPS** : si vous migrez votre site HTTP vers le protocole HTTPS, vous n'avez pas besoin d'utiliser l'outil de **changement d'adresse**.
Version antérieure : seul le passage HTTP vers HTTPS était mentionné comme exclusion.
si vous passez à un nouveau nom de domaine, veillez à envoyer des demandes de **changement d'adresse** pour toutes les variantes validées de l'ancien domaine (y compris les sous-domaines et les versions avec et sans "www") vers le nouveau domaine (par exemple, de `en.example.com`, `www.example.com` et `example.com` vers `new-example.net`), même si vous n'utilisez pas activement ces variantes.
Pour un changement de domaine, toutes les variantes validées doivent faire l'objet d'une demande.
il peut s'écouler quelques semaines ou plus avant que Google ne commence à afficher progressivement les nouvelles URL à la place des anciennes (et encore plus longtemps pour les sites plus volumineux)
Le repère temporel a été reformulé : il désigne maintenant le début du remplacement des URL, pas le basculement de la majorité des pages.
La vitesse d'exploration de Googlebot dépend de la taille de votre site et de la vitesse d'exploration possible.
Le facteur « autres facteurs » a été remplacé par la vitesse d'exploration possible.
Voir la preuve techniqueDIFF, RÉVISIONS, SOURCE
Diff vérifiable

8 ligne(s) ajoutée(s) · 8 retirée(s)

+ AJOUTÉ

À chaque fois que vous apportez un changement significatif à un site, son classement peut varier pendant que Google procède de nouveau à son exploration et à son indexation. En règle générale, pour les sites Web de taille moyenne, il peut s'écouler quelques semaines ou plus avant que Google ne commence à afficher progressivement les nouvelles URL à la place des anciennes (et encore plus longtemps pour les sites plus volumineux). La vitesse à laquelle les URL migrées sont découvertes et traitées par Googlebot ainsi que par nos systèmes dépend en grande partie de leur nombre et de la vitesse de votre serveur.

`301` et les [autres redirections permanentes](https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=fr#permanent-server-side-redirects) n'entraînent pas de baisse dans [PageRank](https://wikipedia.org/wiki/PageRank).

La migration d'un site est considérée comme terminée lorsque Googlebot a accédé au moins une fois à toutes les URL de votre ancien et de votre nouveau site. La fréquence d'exploration n'est pas fixe. La vitesse d'exploration de Googlebot dépend de la taille de votre site et de la vitesse d'exploration possible. La migration est effectuée une URL après l'autre.

4. **Si vous changez de nom de domaine ou de sous-domaine, envoyez une demande de [changement d'adresse](https://support.google.com/webmasters/answer/9370220?hl=fr) pour l'ancien site dans la Search Console**.

Vous n'avez besoin de cet outil que lorsque vous passez d'un domaine ou d'un sous-domaine à un autre (par exemple, de `example.com` à `example.net`, ou de `a.example.com` à `b.example.com`). Vous n'en avez pas besoin pour passer de HTTP à HTTPS, pour basculer entre www et non-www sur le même domaine, ou pour déplacer des chemins d'accès au sein du même domaine.

**Pour les migrations de domaine** : si vous passez à un nouveau nom de domaine, veillez à envoyer des demandes de **changement d'adresse** pour toutes les variantes validées de l'ancien domaine (y compris les sous-domaines et les versions avec et sans "www") vers le nouveau domaine (par exemple, de `en.example.com`, `www.example.com` et `example.com` vers `new-example.net`), même si vous n'utilisez pas activement ces variantes. Assurez-vous que toutes ces variantes sont validées dans la Search Console.

Une fois la migration du site lancée, essayez de mettre à jour immédiatement autant de liens que possible, afin d'améliorer l'expérience utilisateur et de réduire la charge de votre serveur. Voici quelques exemples :

[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2026/09/11 (UTC)."],[],["To minimize the impact of site moves on Google Search, prepare by mapping old URLs to new ones, updating internal links, and creating a new sitemap. Implement server-side redirects (301/308) from old to new URLs, avoiding chained redirects. For large sites, move in sections. Monitor traffic on both sites via Search Console and analytics. Update external links and profile links, submit the new sitemap, and maintain redirects for at least a year. Finally, address any `noindex`, robot.txt blocks and crawl errors.\n"]]

− RETIRÉ

À chaque fois que vous apportez un changement significatif à un site, son classement peut varier pendant que Google procède de nouveau à son exploration et à son indexation. En règle générale, quelques semaines peuvent être nécessaires au déplacement de la majorité des pages d'un site Web de taille moyenne dans notre index. Le processus peut être plus long pour les sites plus volumineux. La vitesse à laquelle les URL migrées sont découvertes et traitées par Googlebot ainsi que par nos systèmes dépend en grande partie de leur nombre et de la vitesse de votre serveur.

`301` et les [autres redirections permanentes](https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=fr#permanent-server-side-redirects) n'entraînent pas de baisse du [PageRank](https://wikipedia.org/wiki/PageRank).

La migration d'un site est considérée comme terminée lorsque Googlebot a accédé au moins une fois à toutes les URL de votre ancien et de votre nouveau site. La fréquence d'exploration n'est pas fixe. La vitesse d'exploration de Googlebot dépend de la taille de votre site en plus d'autres facteurs. La migration est effectuée une URL après l'autre.

4. **Envoyez une demande de [changement d'adresse](https://support.google.com/webmasters/answer/9370220?hl=fr) pour l'ancien site dans la Search Console**.

**Pour les migrations HTTP vers HTTPS** : si vous migrez votre site HTTP vers le protocole HTTPS, vous n'avez pas besoin d'utiliser l'outil de **changement d'adresse**.

**Pour les migrations de domaine** : si vous migrez votre site d'un domaine vers un autre, veillez à envoyer des demandes de **changement d'adresse** pour tous les sous-domaines et les variantes avec et sans "www" de l'ancien nom de domaine (par exemple, de `en.example.com`, `www.example.com` et `example.com` vers `new-example.net`), même si vous n'utilisez pas activement ces variantes. Assurez-vous que toutes ces variantes sont validées dans la Search Console.

Une fois la migration du site lancée, essayez de mettre à jour immédiatement autant de liens que possible, afin d'améliorer l'expérience utilisateur et de réduire la charge de votre serveur. Par exemple :

[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2026/06/24 (UTC)."],[],["To minimize the impact of site moves on Google Search, prepare by mapping old URLs to new ones, updating internal links, and creating a new sitemap. Implement server-side redirects (301/308) from old to new URLs, avoiding chained redirects. For large sites, move in sections. Monitor traffic on both sites via Search Console and analytics. Update external links and profile links, submit the new sitemap, and maintain redirects for at least a year. Finally, address any `noindex`, robot.txt blocks and crawl errors.\n"]]

Historique des versions
  • v2 12 septembre 2026 — Contenu modifié à 2 % · 61 mots ajoutés.
  • v1 12 juillet 2026 — Première indexation.
Contenu archivé
Envoyer des commentaires

# Migrer un site

Ce document explique comment modifier les URL des pages existantes de votre site tout en réduisant au maximum l'impact négatif sur les résultats de recherche Google. Voici quelques exemples de ce que recouvre ce type de migration de site :

- Modification d'URL où `HTTP` est remplacé par `HTTPS`
- Modification du nom de domaine (où, par exemple, `example.com` est remplacé par `example.net`), ou fusion de plusieurs noms de domaine ou noms d'hôte
- Modification de chemins d'URL où `example.com/page.php?id=1` est remplacé par `example.com/widget`, ou `example.com/page.html` par `example.com/page.htm`

**Les URL resteront les mêmes ?** Si vous souhaitez modifier l'infrastructure (par exemple, en changeant d'hébergement), [commencez plutôt ici](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes?hl=fr).

## Présentation

1. [**Bonnes pratiques générales pour les migrations de sites**](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=fr#general_recommendations_for_site_moves).
   Renseignez-vous sur ce qui vous attend, ainsi que sur les conséquences pour vos utilisateurs et sur votre classement. Si vous passez du protocole HTTP au protocole HTTPS, consultez [ces bonnes pratiques](https://web.dev/articles/enable-https?hl=fr).
2. [**Préparez le nouveau site**](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=fr#prepare-new-site) et testez-le minutieusement.
3. [**Élaborez un mappage**](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=fr#prepare-url-mapping) entre les URL actuelles et le nouveau format correspondant.
4. [**Entamez la migration du site**](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=fr#start-site-move) en configurant le serveur afin qu'il redirige les anciennes URL vers les nouvelles.
5. [**Surveillez le trafic**](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=fr#monitor) à la fois sur les anciennes et sur les nouvelles URL.

## Bonnes pratiques générales pour les migrations de site

- **Selon la taille de votre site, procédez à la migration en plusieurs étapes séparées.**  
  Si votre site est volumineux et que cela est techniquement possible, nous vous recommandons de commencer par migrer une seule partie du site afin de tester les effets sur le trafic et l'indexation liée à la recherche. Migrez ensuite le reste du site en une seule fois, ou section par section. Lorsque vous choisissez la première section du site à tester, sélectionnez-en une qui change peu souvent, et qui n'est pas significativement affectée par des événements fréquents ou imprévisibles. Gardez aussi à l'esprit que, même si la migration d'une seule section de votre site constitue un moyen de test efficace, cela n'est pas nécessairement représentatif de la migration du site dans son intégralité en ce qui concerne son affichage dans les résultats de recherche. Plus vous migrez de pages, plus vous vous exposez à des problèmes à résoudre. Une planification minutieuse peut réduire au maximum les problèmes.
- **Ne modifiez qu'une seule chose à la fois**  
  Planifiez les modifications de votre site les unes après les autres, et non en même temps. Par exemple, si vous souhaitez migrer votre site vers un nouveau nom de domaine, changer de système de gestion de contenu (CMS) et mettre à jour votre site pour utiliser une nouvelle mise en page, effectuez un seul changement à la fois. Autrement dit, commencez par migrer votre site vers le nouveau domaine, puis modifiez sa mise en page.
- **Dans la mesure du possible, effectuez la migration au moment où le trafic sur votre site est faible.**  
  Si le trafic est saisonnier ou chute certains jours de la semaine, il est judicieux de migrer votre site pendant les périodes de faible trafic. Cela signifie que moins de personnes seront touchées par les problèmes qui peuvent potentiellement se produire lors de la migration du site, et que davantage de ressources de votre serveur peuvent être dédiées à l'exploration de votre site par Googlebot.
- **Pendant la migration, il est possible que le classement de votre site connaisse une certaine fluctuation.**  
  À chaque fois que vous apportez un changement significatif à un site, son classement peut varier pendant que Google procède de nouveau à son exploration et à son indexation. En règle générale, pour les sites Web de taille moyenne, il peut s'écouler quelques semaines ou plus avant que Google ne commence à afficher progressivement les nouvelles URL à la place des anciennes (et encore plus longtemps pour les sites plus volumineux). La vitesse à laquelle les URL migrées sont découvertes et traitées par Googlebot ainsi que par nos systèmes dépend en grande partie de leur nombre et de la vitesse de votre serveur.
  L'[envoi d'un sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap?hl=fr) peut contribuer à accélérer le processus de découverte. En outre, sachez que vous avez la possibilité de migrer votre site section par section.
- **Ne vous souciez pas des recommandations de liens.**  
  `301` et les [autres redirections permanentes](https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=fr#permanent-server-side-redirects) n'entraînent pas de baisse dans [PageRank](https://wikipedia.org/wiki/PageRank).
- **Utilisez la Search Console.**  
  La Search Console est votre alliée, en particulier quand vous migrez votre site. Vérifiez séparément les données de chaque propriété dans la Search Console. Utilisez le [rapport État de l'indexation](https://support.google.com/webmasters/answer/7440203?hl=fr) pour obtenir un aperçu. Consultez le [rapport sur les sitemaps](https://support.google.com/webmasters/answer/7451001?hl=fr) pour savoir combien d'URL ont été indexées parmi celles qui ont été envoyées dans un sitemap.
- **Soyez patient.**  
  La migration d'un site est considérée comme terminée lorsque Googlebot a accédé au moins une fois à toutes les URL de votre ancien et de votre nouveau site. La fréquence d'exploration n'est pas fixe. La vitesse d'exploration de Googlebot dépend de la taille de votre site et de la vitesse d'exploration possible. La migration est effectuée une URL après l'autre.

## Préparer le nouveau site

Les détails de la préparation du site varient pour chaque migration, mais de manière générale, vous effectuez au moins l'une des actions suivantes :

- **Configurez le CMS** (de préférence le même que celui de l'ancien site utilisé) et importez le contenu de l'ancien site.
- **Transférez les images et les téléchargements** (tels que les documents PDF) que vous hébergez.  
  Il est possible que ces éléments reçoivent du trafic provenant de la recherche Google ou de liens, et il est utile d'indiquer leur nouvel emplacement aux internautes, ainsi qu'à Googlebot.
- **Pour une migration vers le protocole HTTPS**, obtenez les certificats TLS requis et configurez-les sur votre serveur.
- **Configurez un fichier robots.txt pour votre nouveau site** et assurez-vous que les règles du fichier robots.txt du nouveau site reflètent correctement les parties qui ne doivent pas être explorées.

  Notez que certains propriétaires de sites bloquent toute exploration pendant la période de développement. Si vous suivez cette stratégie, assurez-vous de savoir à quoi ressemblera le fichier robots.txt lorsque la migration du site débutera. De même, si vous utilisez des règles `noindex` pendant le développement, préparez une liste des URL avec des règles `noindex` à supprimer au début de la migration du site.
- **Fournissez les codes d'erreur appropriés pour les contenus supprimés ou fusionnés** si vous ne transférez pas l'ensemble de votre ancien contenu vers le nouveau site. Assurez-vous que ces URL renvoient correctement un code de réponse HTTP `404` ou `410` 
Métadonnées
  • Redondance mesurée avec l’archive : 81 %
  • Rédigé par claude-opus-5 · consigne editorial-v1
  • Relu et publié le 16 septembre 2026
ESPACE SÉCURISÉ

ADMINISTRATION

Les actions techniques restent ici, loin de la lecture quotidienne.