Change of Address : déclarer toutes les variantes de domaine

Actualités SEO18 juin 202612 min de lecture

Un site move mal exécuté reste l'une des opérations les plus destructrices en SEO. Google vient de mettre à jour sa documentation d'aide pour préciser un point que beaucoup de SEOs négligent : lors d'un changement de domaine, il faut soumettre une demande Change of Address pour chaque variante de domaine — www, non-www, HTTP, HTTPS — et pas seulement pour la propriété "principale" dans Search Console.

Ce n'est pas un changement de fonctionnalité. C'est une clarification documentaire. Mais elle met en lumière une erreur technique courante qui peut coûter des mois de récupération de trafic.

Ce que Google a réellement modifié dans sa documentation

La page de documentation officielle sur le Change of Address tool a été mise à jour pour ajouter une instruction explicite : lors d'un site move avec changement de domaine, vous devez soumettre la notification Change of Address pour toutes les propriétés de domaine vérifiées dans Search Console, pas uniquement la variante canonique.

Concrètement, si vous possédez example.com et que votre site résout sur quatre variantes :

  • http://example.com
  • https://example.com
  • http://www.example.com
  • https://www.example.com

Et que vous migrez vers newdomain.com, Google attend que vous soumettiez le Change of Address depuis chacune de ces quatre propriétés, en pointant vers la variante correspondante sur le nouveau domaine.

Pourquoi c'est contre-intuitif

La plupart des équipes SEO raisonnent en termes de propriété canonique. Vous avez configuré vos redirections 301 pour consolider tout le trafic sur https://www.example.com. Vous avez une propriété Domain (example.com) dans Search Console qui agrège tout. Logiquement, soumettre le Change of Address depuis cette propriété devrait suffire.

Sauf que le Change of Address tool fonctionne au niveau de la propriété URL prefix, pas au niveau de la propriété Domain. Si vous avez ajouté example.com comme propriété Domain, le bouton Change of Address n'est même pas disponible — il n'apparaît que pour les propriétés URL prefix.

C'est un point que la documentation ne rendait pas explicite avant cette mise à jour. Et c'est la source d'erreurs systématiques sur les migrations de grande envergure.

L'impact technique réel

Le Change of Address tool envoie un signal interne à Google indiquant que le contenu a déménagé. Ce signal accélère le transfert des signaux de ranking (PageRank, ancienneté, etc.) de l'ancien domaine vers le nouveau. Sans ce signal, Google se fie uniquement aux redirections 301 — ce qui fonctionne, mais plus lentement.

Si vous ne soumettez le Change of Address que pour https://www.example.com mais que Google a encore des URLs indexées sous http://example.com (résidu d'un ancien crawl, backlinks pointant vers la version HTTP), ces URLs ne bénéficient pas du signal accéléré. Le transfert de signaux pour ces URLs se fait uniquement via la chaîne de redirections, ce qui peut prendre des semaines supplémentaires.

Audit des variantes de domaine avant migration

Avant de toucher au Change of Address tool, vous devez savoir exactement quelles variantes de votre domaine sont indexées et référencées. Ce n'est pas aussi trivial que ça en a l'air.

Vérifier l'index Google

Utilisez l'opérateur site: pour chaque variante :

# Vérifier chaque variante dans Google
# Lancez ces requêtes directement dans Google Search
site:http://example.com
site:https://example.com
site:http://www.example.com
site:https://www.example.com

# Pour une vérification programmatique via Search Console API :
curl -H "Authorization: Bearer $TOKEN" \
  "https://www.googleapis.com/webmasters/v3/sites/http%3A%2F%2Fexample.com/searchAnalytics/query" \
  -d '{
    "startDate": "2026-03-01",
    "endDate": "2026-06-15",
    "dimensions": ["page"],
    "rowLimit": 25000
  }'

Répétez cet appel API pour chaque variante de propriété URL prefix. Le nombre d'URLs retournées pour chaque variante vous indique l'ampleur du problème. Si http://example.com retourne 0 résultat, vous pouvez potentiellement ignorer cette variante (mais mieux vaut la déclarer quand même — le coût est nul).

Crawler les variantes avec Screaming Frog

Configurez Screaming Frog pour crawler spécifiquement une variante et observer les redirections :

Configuration > Spider > Always Follow Redirects: ON
Configuration > Spider > Crawl All Subdomains: OFF

Crawl séparé pour chaque variante :
1. http://example.com
2. https://example.com
3. http://www.example.com
4. https://www.example.com

Ce que vous cherchez : des pages qui retournent un 200 au lieu d'un 301 sur une variante non-canonique. C'est un signal que votre consolidation de domaine est incomplète — et c'est précisément ce qui crée des "résidus" dans l'index Google que le Change of Address doit couvrir.

Auditer les backlinks par variante

Vos backlinks ne pointent pas tous vers la même variante. Un lien obtenu en 2018 pointe probablement vers http://example.com. Un lien récent pointe vers https://www.example.com. Utilisez Ahrefs, Majestic ou Semrush pour filtrer vos backlinks par URL exacte et identifier quelle variante concentre le plus de liens externes.

Cette donnée détermine la priorité de vos déclarations Change of Address. Si 40% de vos backlinks pointent vers http://example.com, cette variante doit être traitée en premier.

Configuration serveur : les redirections multi-variantes

Le Change of Address tool ne remplace pas les redirections. Il les complète. Vos redirections doivent être irréprochables pour que le signal soit cohérent.

Nginx : redirection complète de toutes les variantes

# Bloc 1 : redirection HTTP non-www vers HTTPS www du nouveau domaine
server {
    listen 80;
    server_name example.com;
    return 301 https://www.newdomain.com$request_uri;
}

# Bloc 2 : redirection HTTP www vers HTTPS www du nouveau domaine
server {
    listen 80;
    server_name www.example.com;
    return 301 https://www.newdomain.com$request_uri;
}

# Bloc 3 : redirection HTTPS non-www vers HTTPS www du nouveau domaine
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    return 301 https://www.newdomain.com$request_uri;
}

# Bloc 4 : redirection HTTPS www vers HTTPS www du nouveau domaine
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    return 301 https://www.newdomain.com$request_uri;
}

Point critique souvent oublié : les variantes HTTPS nécessitent un certificat SSL valide sur l'ancien domaine. Si votre certificat a expiré sur example.com, la redirection HTTPS → HTTPS échouera avec une erreur SSL avant même que le 301 ne soit servi. Googlebot abandonne sur erreur SSL — ces pages ne seront jamais redirigées, et le signal de ranking associé sera perdu.

Le piège des chaînes de redirections

Beaucoup de configurations créent involontairement des chaînes de 2-3 redirections :

http://example.com → https://example.com → https://www.example.com → https://www.newdomain.com

Trois sauts. Google suit les chaînes de redirections (jusqu'à 10 sauts selon la documentation), mais chaque saut dilue potentiellement le signal et ralentit le traitement. La configuration Nginx ci-dessus évite ce problème en redirigeant directement chaque variante vers la destination finale.

Vérifiez vos chaînes avec curl :

# Vérifier la chaîne de redirection complète
curl -sIL -o /dev/null -w "%{url_effective}\n%{redirect_url}\n" \
  "http://example.com/category/shoes" 2>&1

# Version plus détaillée avec tous les sauts
curl -v -L "http://example.com/category/shoes" 2>&1 | grep -E "< HTTP|< location"

Le résultat attendu : un seul saut 301 directement vers https://www.newdomain.com/category/shoes.

Scénario concret : migration d'un e-commerce de 18 000 pages

Prenons un cas réaliste. chaussures-martin.fr migre vers martin-shoes.com dans le cadre d'un rebranding international. Le site compte 18 000 pages indexées, dont :

  • 12 000 pages produit
  • 3 500 pages catégorie/filtre
  • 1 800 pages de contenu éditorial
  • 700 pages diverses (CGV, FAQ, etc.)

État des lieux pré-migration

L'audit révèle la répartition suivante dans l'index Google :

Variante Pages indexées Backlinks entrants
https://www.chaussures-martin.fr 17 200 4 800
https://chaussures-martin.fr 340 1 200
http://www.chaussures-martin.fr 85 2 100
http://chaussures-martin.fr 12 890

Les 340 pages indexées sous https://chaussures-martin.fr (sans www) sont des résidus : des pages dont le crawl initial a eu lieu avant la mise en place de la redirection non-www → www. Plus critique : 2 100 backlinks pointent vers la variante HTTP www, et 890 vers la variante HTTP non-www. Ces backlinks transmettent du PageRank à travers les chaînes de redirections existantes, mais la migration va modifier ces chaînes.

Procédure Change of Address

L'équipe crée quatre propriétés URL prefix dans Search Console (si elles n'existent pas déjà) :

  1. http://chaussures-martin.fr
  2. https://chaussures-martin.fr
  3. http://www.chaussures-martin.fr
  4. https://www.chaussures-martin.fr

Pour chaque propriété, ils soumettent un Change of Address vers la propriété correspondante sur le nouveau domaine. En pratique, les quatre pointent vers https://www.martin-shoes.com puisque c'est la variante canonique cible.

Étape souvent ratée : il faut aussi créer et vérifier les quatre propriétés URL prefix du nouveau domaine dans Search Console avant de pouvoir soumettre le Change of Address. Le tool vérifie que la propriété cible existe et est vérifiée.

Résultats observés

  • Semaine 1-2 : Google recrawle massivement l'ancien domaine (pic de crawl visible dans les rapports d'exploration). Les pages avec le plus de backlinks sont recrawlées en premier.
  • Semaine 2-4 : le trafic organique chute de 30-40% — c'est normal et attendu. Les anciennes URLs sont progressivement remplacées dans l'index.
  • Semaine 4-8 : récupération progressive. Les sites qui ont soumis le Change of Address pour toutes les variantes récupèrent typiquement 80-90% du trafic en 6 semaines. Ceux qui n'ont couvert que la variante principale mettent 10-12 semaines pour atteindre le même niveau.

La différence de 4-6 semaines sur un e-commerce qui génère 200K€/mois de CA organique représente un manque à gagner direct. C'est le coût d'avoir oublié trois clics dans Search Console.

Automatiser la vérification post-migration

Après avoir soumis les Change of Address, vous devez vérifier en continu que les redirections fonctionnent, que les anciennes URLs sont bien remplacées dans l'index, et qu'aucune régression ne survient.

Script de vérification des redirections

// verify-redirects.ts
// Vérifie que toutes les variantes de l'ancien domaine redirigent correctement

const OLD_VARIANTS = [
  'http://chaussures-martin.fr',
  'https://chaussures-martin.fr',
  'http://www.chaussures-martin.fr',
  'https://www.chaussures-martin.fr',
];

const TARGET = 'https://www.martin-shoes.com';

const SAMPLE_PATHS = [
  '/',
  '/chaussures/running',
  '/produit/nike-air-max-90-blanc',
  '/blog/guide-taille-chaussures',
  '/sitemap.xml',
];

interface RedirectResult {
  source: string;
  finalUrl: string;
  statusCode: number;
  hops: number;
  success: boolean;
  error?: string;
}

async function checkRedirect(url: string): Promise<RedirectResult> {
  let hops = 0;
  let currentUrl = url;

  try {
    const response = await fetch(url, {
      redirect: 'manual',
      headers: { 'User-Agent': 'Mozilla/5.0 (compatible; migration-checker/1.0)' },
    });

    // Suivre manuellement les redirections pour compter les sauts
    let res = response;
    while (res.status >= 300 && res.status < 400 && hops < 10) {
      const location = res.headers.get('location');
      if (!location) break;
      currentUrl = new URL(location, currentUrl).toString();
      res = await fetch(currentUrl, { redirect: 'manual' });
      hops++;
    }

    const finalUrl = currentUrl;
    const success = finalUrl.startsWith(TARGET) && res.status === 200;

    return { source: url, finalUrl, statusCode: res.status, hops, success };
  } catch (error) {
    return {
      source: url,
      finalUrl: currentUrl,
      statusCode: 0,
      hops,
      success: false,
      error: error instanceof Error ? error.message : 'Unknown error',
    };
  }
}

async function main() {
  const results: RedirectResult[] = [];

  for (const variant of OLD_VARIANTS) {
    for (const path of SAMPLE_PATHS) {
      const url = `${variant}${path}`;
      const result = await checkRedirect(url);
      results.push(result);

      const status = result.success ? '✓' : '✗';
      console.log(
        `${status} ${url} → ${result.finalUrl} (${result.hops} hops, HTTP ${result.statusCode})`
      );

      if (result.hops > 1) {
        console.warn(`  ⚠ Chaîne de ${result.hops} redirections détectée`);
      }
      if (result.error) {
        console.error(`  ERROR: ${result.error}`);
      }
    }
  }

  const failures = results.filter((r) => !r.success);
  if (failures.length > 0) {
    console.error(`\n${failures.length}/${results.length} redirections en échec.`);
    process.exit(1);
  }

  console.log(`\n${results.length}/${results.length} redirections OK.`);
}

main();

Exécutez ce script quotidiennement pendant les 3 mois suivant la migration. Intégrez-le dans votre CI/CD si l'ancien domaine est servi par une infrastructure que vous contrôlez.

Ce que le monitoring automatisé détecte que vous ne verrez pas

Les régressions post-migration surviennent souvent de manière silencieuse :

  • Un certificat SSL qui expire sur l'ancien domaine après 90 jours (Let's Encrypt ne renouvelle plus si le DNS a changé)
  • Un CDN qui purge sa configuration et retourne des 404 au lieu de 301
  • Un hébergeur qui coupe le serveur de l'ancien domaine parce que le contrat a expiré

Un outil de monitoring comme Seogard détecte ces régressions dès qu'elles surviennent : si une URL qui servait un 301 commence à retourner un 502 ou un timeout, l'alerte est immédiate. Sans monitoring, vous ne découvrez le problème que lorsque le trafic chute — parfois des semaines plus tard.

Edge cases et situations complexes

Migration avec changement de structure d'URL

Si vous migrez chaussures-martin.fr/produit/nike-air-max-90 vers martin-shoes.com/shoes/nike-air-max-90, le Change of Address ne gère pas le mapping d'URL. Il signale uniquement que le domaine a changé. Le mapping URL-par-URL repose entièrement sur vos redirections 301.

Le Change of Address tool s'attend à ce que les redirections soient cohérentes avec le signal de changement de domaine. Si vous déclarez un Change of Address de https://www.chaussures-martin.fr vers https://www.martin-shoes.com, mais que certaines pages redirigent vers https://martin-shoes.com (sans www), vous créez une incohérence. Google la résoudra, mais plus lentement.

Domaines avec sous-domaines multiples

Si votre site utilise des sous-domaines (blog.chaussures-martin.fr, shop.chaussures-martin.fr), chaque sous-domaine est une propriété distincte dans Search Console. Le Change of Address doit être soumis séparément pour chaque sous-domaine, en plus des quatre variantes du domaine principal.

Pour un site avec 3 sous-domaines, vous avez potentiellement 16 propriétés URL prefix à gérer (4 variantes × 4 hosts). C'est fastidieux, mais c'est le seul moyen de couvrir tous les signaux.

Propriétés Domain vs URL prefix

La propriété Domain (example.com dans la vue Domain de Search Console) agrège les données de toutes les variantes. C'est pratique pour le reporting, mais le Change of Address tool n'est pas disponible pour les propriétés Domain. Vous devez utiliser les propriétés URL prefix.

Si vous n'aviez que la propriété Domain dans Search Console, vous devez créer les quatre propriétés URL prefix avant la migration. Vérifiez-les via DNS TXT record ou fichier HTML — les deux méthodes fonctionnent, mais le DNS est plus rapide quand vous devez vérifier quatre propriétés d'un coup.

Quand ne PAS utiliser le Change of Address

Le Change of Address est conçu exclusivement pour les changements de domaine. Il ne s'applique pas aux :

  • Migrations HTTP → HTTPS sur le même domaine (Google le détecte automatiquement via les redirections)
  • Déplacement de contenu au sein du même domaine (changement de structure d'URL)
  • Consolidation www/non-www sur le même domaine

Pour ces cas, les redirections 301 suffisent. Utiliser le Change of Address pour un cas non supporté ne provoque pas d'erreur, mais l'outil n'a aucun effet — c'est une perte de temps. La documentation mise à jour de Google est claire sur ce périmètre.

Maintenir les redirections dans la durée

Google recommande de maintenir les redirections pendant au moins 6 mois après une migration. En pratique, les SEOs expérimentés maintiennent les 301 tant que l'ancien domaine est sous leur contrôle — idéalement indéfiniment, ou au minimum 2 ans.

La raison : les backlinks vers l'ancien domaine continuent d'apporter du PageRank via les redirections. Si vous coupez les redirections, vous perdez ce signal. Et les backlinks existants ne seront pas mis à jour — les webmasters ne corrigent quasiment jamais leurs liens sortants.

L'infrastructure nécessaire est minimale. Un serveur Nginx qui ne fait que des return 301 consomme pratiquement aucune ressource. Sur un VPS à 5€/mois, vous pouvez maintenir les redirections pour des dizaines de domaines simultanément. Le coût est négligeable comparé à la valeur des backlinks préservés.

Si votre ancien domaine pointe vers un service comme un sitemap XML qui doit lui aussi rediriger correctement, pensez à tester ce point spécifiquement — un sitemap qui pointe vers un domaine inexistant est un signal négatif classique post-migration.

De même, vérifiez que votre stack de métadonnées est correcte sur le nouveau domaine. Des meta qui disparaissent silencieusement après un refactoring ou un override inattendu de meta entre layout et pages sont des régressions fréquentes lors de la mise en place d'un nouveau site.

Les signaux Search Console à surveiller post-migration

Dans Search Console, après soumission du Change of Address, surveillez ces indicateurs sur les propriétés de l'ancien domaine :

  • Rapport de couverture : le nombre de pages indexées doit diminuer progressivement. Si ce nombre stagne après 4 semaines, vos redirections ne sont probablement pas crawlées.
  • Statistiques de crawl : vous devriez voir un pic d'activité de crawl dans les 48-72h suivant la soumission du Change of Address, puis une décroissance progressive.
  • Performance : les impressions et clics doivent migrer vers les propriétés du nouveau domaine. Comparez les métriques agrégées (ancien + nouveau) avec la baseline pré-migration.

Sur les propriétés du nouveau domaine, les rapports Search Console, y compris les nouveaux rapports AI, vous donneront la visibilité sur la progression de l'indexation des nouvelles URLs.

La mise à jour de la documentation Google sur le Change of Address tool corrige une lacune qui coûtait du trafic à ceux qui ne connaissaient pas cette subtilité. Déclarer chaque variante de domaine est une opération de 15 minutes qui peut raccourcir de plusieurs semaines la récupération post-migration. Un outil de monitoring comme Seogard permet ensuite de vérifier en continu que les redirections restent fonctionnelles et qu'aucune régression technique ne vient compromettre le transfert de signaux.

Articles connexes

Actualités SEO17 juin 2026

Bing AI Citation Share : ce que ça change pour le SEO technique

Analyse technique du nouveau Citation Share dans Bing Webmaster Tools. Métriques AI, impact sur le trafic, et stratégies d'optimisation concrètes.

Equipe Seogard12 min de lecture
Actualités SEO15 juin 2026

AI Overview Click Data : ce que les clics révèlent vraiment

Les utilisateurs quotidiens d'AI Overview cliquent 3.5x plus sur les sources. Analyse technique des données et stratégies d'optimisation concrètes.

Equipe Seogard12 min de lecture
Actualités SEO14 juin 2026

Siri + Gemini : impact concret sur la visibilité SEO

Apple intègre Gemini dans Siri. Analyse technique des conséquences pour le crawl, le rendering, le structured data et la visibilité organique de vos pages.

Equipe Seogard12 min de lecture
Actualités SEO12 juin 2026

AI Overviews : les données de clics révèlent un comportement inattendu

Les utilisateurs quotidiens d'AI Overviews cliquent 3,5x plus sur les sources. Analyse technique des opportunités d'optimisation pour les sites à fort volume.

Equipe Seogard12 min de lecture
Actualités SEO11 juin 2026

Schema.org affiche l'adoption réelle de chaque type : exploitez ces données

Schema.org expose désormais le nombre de sites utilisant chaque type. Analyse technique, requêtes SPARQL et stratégies pour exploiter ces données d'adoption.

Equipe Seogard12 min de lecture
Actualités SEO9 juin 2026

Comment l'IA se forge une opinion sur votre marque

Construisez une empreinte numérique que les LLMs comprennent : structured data, entités, corpus de citations. Guide technique pour Lead SEO.

Equipe Seogard14 min de lecture

Seogard est un logiciel à code source disponible (licence BSL 1.1) édité par SAVEPNP SAS. Code distribué selon les termes de la BSL — tous autres droits réservés.

Notre mission est de protéger chaque page indexée contre les régressions SEO invisibles — avant que Google ne les découvre.
Objectif : 10 000 sites monitorés d'ici 2028.

Besoin d'aide ? [email protected]

GitHub

Questions fréquentes

Que monitore Seogard exactement ?

Seogard monitore en continu 65+ règles SEO et GEO sur chaque page : meta title et description, canonical, noindex accidentel, status codes (404, 500, redirections), régressions SSR/CSR, hreflang, Open Graph, llms.txt, blocage des crawlers IA de citation (OAI-SearchBot, PerplexityBot, Claude-SearchBot) et bien plus. Chaque régression déclenche une alerte temps réel par email, classée par sévérité.

Seogard est-il gratuit ?

La version self-hosted est gratuite, à code source disponible (licence BSL 1.1) et sans limite de pages. La version Cloud est facturée à l'usage pour ceux qui préfèrent ne pas gérer l'infrastructure.

En quoi Seogard est différent d'un crawler classique ?

Seogard compare automatiquement et en continu le HTML brut (ce que Google indexe) et le rendu JavaScript (ce que vous voyez), sur chaque page. Un SSR cassé passe inaperçu dans le navigateur — Seogard le détecte avant que Google ne re-rende vos pages.

Comment fonctionnent les alertes ?

Chaque page est crawlée quotidiennement. Dès qu'un changement est détecté (meta modifiée, status code anormal, SSR cassé), une alerte avec le diff avant/après est envoyée par email.

Liens

FonctionnalitésTarifsBlogBot / Crawlerllms.txt

Légal

CGUCGVConfidentialitéCookiesMentions légalesLicence (BSL 1.1)