Sauvegarder les données Google Analytics 4 et Search Console avant une migration

Une refonte ou une migration de site se juge sur un point : le trafic et les conversions sont-ils au rendez-vous après la mise en ligne ? Pour répondre, il faut une base de comparaison, et cette base se prépare avant la migration, pas après. Deux outils de Google la fournissent : Google Analytics 4, qui mesure ce qui se passe sur le site, et la Google Search Console, qui mesure ce qui se passe avant, dans les résultats de recherche. Leurs données servent aussi en amont : elles indiquent quelles pages reçoivent des visites, des clics et des liens, donc lesquelles ne doivent à aucun prix perdre leur redirection.

Cet article porte sur Google Analytics 4. Universal Analytics a cessé de collecter des données en juillet 2023 et ses données ont été supprimées en 2024 : les anciennes méthodes d'export, comme le module complémentaire Google Analytics pour Google Sheets, ne s'appliquent plus. La sauvegarde des données de mesure complète celle des fichiers, de la base et de la configuration : voir notre liste de ce qu'il faut sauvegarder avant une migration.

Google Analytics 4 rattache les données à une propriété et à un flux de données, pas à une adresse. Tant que la nouvelle version du site porte la même balise (le même identifiant de mesure), l'historique continue dans la même propriété, même si le nom de domaine change. Vous ne perdez donc pas vos données en migrant, à condition de ne pas créer une nouvelle propriété sans nécessité.

En revanche, les rapports par page se lisent par chemin ou par adresse. Après la migration, chaque nouvelle URL apparaît sur sa propre ligne, et l'ancienne ligne cesse de recevoir des visites. Pour comparer une page avant et après, il faut savoir quelle ancienne URL correspond à quelle nouvelle : c'est exactement ce que décrit votre plan de redirection.

En résumé, voici ce qui est conservé et ce qui risque d'être perdu :

• conservé : l'historique de la propriété, les rapports standards, les événements clés déjà enregistrés, les liaisons avec la Search Console, Google Ads ou BigQuery ;
• à risque : les données détaillées utilisées par les explorations, effacées au-delà de la durée de conservation choisie ; les événements clés qui dépendent d'une URL (une page de remerciement qui change d'adresse) ; les pages de la nouvelle version où la balise a été oubliée ; les paramètres de campagne (utm_source, utm_medium, etc.) si une redirection supprime la chaîne de requête.

Inutile de tout exporter. Concentrez-vous sur ce qui servira à décider et à comparer :

• les pages de destination, avec les sessions, les utilisateurs et les événements clés, sur l'ensemble du trafic et sur le seul groupe de canaux « Organic Search » ;
• les pages vues par chemin de page, pour repérer les contenus consultés en cours de visite et pas seulement à l'arrivée ;
• les événements clés par page et par source, pour savoir où se font les conversions ;
• les sites référents, qui montrent les liens externes qui apportent réellement des visites ;
• une période assez longue pour couvrir vos variations saisonnières, et la même période de l'année précédente si vous l'avez.

Depuis 2024, Google Analytics 4 appelle « événements clés » ce qu'il appelait « conversions » ; le terme « conversions » est désormais réservé à Google Ads.

Dans une propriété Google Analytics 4 standard, les données détaillées au niveau de l'événement sont conservées 2 mois par défaut, ou 14 mois si vous le choisissez. Le réglage se trouve dans l'administration, rubrique « Collecte et modification des données », puis « Conservation des données ».

Cette durée ne concerne pas les rapports standards, qui reposent sur des données agrégées et gardent l'historique de la propriété. Elle limite en revanche les explorations : avec 2 mois de conservation, une exploration ne remonte pas plus loin. Passez donc à 14 mois le plus tôt possible. Le changement ne vaut que pour l'avenir : il ne récupère pas les données déjà effacées. C'est une raison de plus pour exporter vos explorations avant la migration et pour activer l'export BigQuery.

Dans un rapport standard (par exemple « Pages de destination », dans la partie Engagement), choisissez d'abord la période, puis ajoutez si besoin une comparaison ou un filtre, par exemple sur le groupe de canaux par défaut « Organic Search ». L'icône « Partager ce rapport », en haut à droite, propose « Télécharger le fichier », au format PDF ou CSV.

Le CSV se retravaille dans un tableur, le PDF se partage avec un client ou une équipe. Vérifiez avant chaque téléchargement la période et les filtres appliqués : un filtre oublié donne un export partiel sans que rien ne l'indique dans le nom du fichier. Nommez vos fichiers avec la date et le périmètre, et rangez-les dans un dossier partagé du projet de migration.

Les explorations, dans le menu « Explorer », permettent des tableaux plus précis que les rapports standards : une exploration libre avec la page de destination en ligne, les sessions, les utilisateurs et les événements clés en valeurs, et un filtre sur le canal. Elles s'exportent depuis le menu d'export de l'exploration, notamment vers Google Sheets ou en CSV.

Deux limites à connaître : une exploration ne remonte pas au-delà de la durée de conservation des données d'événements, et sur de gros volumes elle peut être échantillonnée, ce que signale l'indicateur de qualité des données en haut de l'exploration. Pour un site à fort trafic, réduisez la période ou passez par BigQuery.

Google Analytics 4 peut exporter ses données brutes, événement par événement, vers BigQuery, l'entrepôt de données de Google Cloud. La liaison se fait dans l'administration de la propriété, parmi les associations avec les autres produits Google, et elle est disponible pour toutes les propriétés, y compris gratuites. L'export quotidien est gratuit côté Analytics ; le stockage et les requêtes dans BigQuery relèvent de la facturation Google Cloud, avec une part gratuite chaque mois.

Ce qu'il faut savoir avant une migration :

• l'export n'est pas rétroactif : il commence à la date de la liaison. Activez-le plusieurs semaines avant la mise en ligne pour disposer d'une période de référence ;
• pour une propriété standard, l'export quotidien est plafonné à un million d'événements par jour ;
• en mode bac à sable de BigQuery (sans facturation activée), les tables expirent automatiquement au bout de 60 jours : activez la facturation si vous voulez les garder ;
• les données exportées ne dépendent plus de la durée de conservation de la propriété : c'est le seul moyen de garder durablement le détail des événements.

BigQuery demande de savoir écrire des requêtes SQL. Si personne ne le sait dans l'équipe, activez quand même l'export : les données seront là le jour où vous en aurez besoin.

Looker Studio, l'outil gratuit de tableaux de bord de Google, se connecte directement à Google Analytics 4, à la Search Console, à BigQuery et à Google Sheets. Préparez avant la migration un tableau de bord qui suit les sessions organiques, les pages de destination et les événements clés, avec une comparaison à la période précédente : le jour de la mise en ligne, il sera prêt.

Attention, Looker Studio n'est pas une sauvegarde : il interroge les sources à chaque affichage et ne stocke pas les données. Il montre ce que la propriété Analytics ou BigQuery contient encore, rien de plus.

Google Analytics 4 permet d'ajouter des annotations datées, visibles sur les graphiques des rapports. Notez-y la date de mise en ligne, celle de l'activation des redirections et tout changement de balisage : dans six mois, personne ne se souviendra pourquoi la courbe a bougé tel jour.

Doublez ces annotations d'un journal de migration tenu hors d'Analytics, dans le dossier du projet : date et heure de chaque étape, version du plan de redirection déployée, corrections apportées ensuite. Il servira aussi à lire les données de la Search Console, qui n'ont pas d'annotations.

Une migration casse souvent le suivi sans que personne ne s'en aperçoive. Avant la mise en ligne, vérifiez en préproduction, puis le jour même en production :

• que la balise Google Analytics (ou le conteneur Google Tag Manager) est présente sur tous les gabarits de la nouvelle version, et qu'elle utilise le même identifiant de mesure ;
• que les événements clés définis à partir d'une URL (une page de remerciement, une étape de commande) visent les nouvelles adresses ;
• que les formulaires, boutons et paniers qui déclenchent des événements portent toujours les mêmes identifiants ou classes ;
• si le nom de domaine change ou si le parcours passe par plusieurs domaines, que la liste des domaines du flux de données et la liste des sites référents indésirables sont à jour ;
• que les liens de vos campagnes (e-mails, publicités, réseaux sociaux) pointent vers les nouvelles URL, plutôt que de compter sur une redirection qui pourrait perdre les paramètres utm.

Le rapport « Temps réel » et le mode DebugView permettent de voir les événements arriver pendant vos tests. Dans les semaines qui suivent, comparez les événements clés par page de destination à vos exports : une baisse brutale sur un type de page signale plus souvent un problème de balisage qu'une perte de positions. Notre article sur les problèmes SEO après une refonte aide à faire la différence.

La Google Search Console donne, par page et par requête, les impressions, les clics et la position moyenne dans Google. Elle ne conserve que les 16 derniers mois, et aucun réglage ne prolonge cette durée : ce qui n'a pas été exporté disparaît. Pour une migration, c'est la source la plus directe de ce que Google voit et envoie, page par page.

Associez aussi votre propriété Search Console à Google Analytics 4, depuis l'administration de la propriété, pour retrouver ces données dans Analytics. Cette association ne remplace pas les exports : elle ne fait qu'afficher les données que la Search Console garde encore.

Dans le rapport « Performances », onglet « Résultats de recherche », choisissez la plus longue période disponible, affichez les clics, les impressions, le CTR et la position, puis exportez les onglets « Pages » et « Requêtes » (Google Sheets, Excel ou CSV). L'export depuis l'interface est limité à 1 000 lignes par onglet : sur un site de plusieurs milliers de pages, filtrez par répertoire et exportez section par section, ou passez par l'API de la Search Console, que des connecteurs comme Looker Studio ou des extensions de tableur utilisent.

Pour garder au-delà de 16 mois, deux solutions : un export mensuel rangé dans le dossier du projet, ou l'export groupé des données vers BigQuery, que la Search Console propose depuis 2023. Comme celui de Google Analytics, il n'est pas rétroactif : il commence à la date de son activation.

Le rapport « Pages », dans la partie Indexation, liste les pages indexées et celles qui ne le sont pas, avec la raison. Exportez les exemples de chaque état (limités à 1 000 par état) : après la migration, ils permettent de vérifier que les anciennes URL sortent de l'index au profit des nouvelles, et que des pages jusque-là exclues ne deviennent pas indexables par erreur. Relevez aussi la liste des sitemaps déclarés et leur nombre d'URL découvertes.

Le rapport « Liens » donne les pages de votre site qui reçoivent le plus de liens externes, les sites qui vous lient et les pages les plus liées en interne. Le bouton d'export propose les liens externes, en échantillon ou les plus récents. Une URL qui reçoit des liens doit être redirigée vers son équivalent exact, même si elle n'a plus de trafic : c'est elle qui transmet la popularité acquise. Voir notre article sur l'importance des backlinks pendant une migration.

Ajoutez et validez la nouvelle propriété dans la Search Console avant la mise en ligne, puis déclarez le déménagement avec l'outil « Changement d'adresse » une fois les redirections actives. Gardez l'ancienne propriété : elle reste le seul endroit où lire l'historique de l'ancien domaine, et où suivre la sortie de ses URL de l'index.

Les pages qui reçoivent des clics depuis Google sont les premières à rediriger : notre article où trouver les URL à rediriger dans la Google Search Console explique comment les repérer.

Toutes ces données ont une utilité immédiate : décider quelles URL doivent impérativement être redirigées, et vers quoi. Swan, l'outil de plan de redirection, crawle votre site actuel et sa préproduction, puis rapproche chaque ancienne URL des nouvelles par proximité sémantique. Il peut aussi recevoir des URL d'autres sources, ce qui évite d'oublier des pages que le crawl ne trouve pas :

• la Google Search Console, connectée directement à votre projet, qui apporte les pages ayant des impressions dans Google ;
• l'import manuel, une URL par ligne, avec leur origine : Ahrefs, Majestic, Semrush, journaux du serveur, l'export des liens de la Search Console, ou Analytics pour une liste issue de vos exports Google Analytics 4.

Swan ne se connecte pas à Google Analytics : partez de votre export CSV des pages de destination. Les rapports donnent des chemins (/categorie/page) ; ajoutez devant le protocole et le nom de domaine pour obtenir des URL complètes avant de les coller. Les pages qui portent vos conversions peuvent être importées avec l'origine « URL prioritaire » : elles restent dans le projet même si elles correspondent à un motif d'exclusion.

Vous validez ensuite les correspondances proposées, en commençant par les pages qui comptent le plus dans vos exports. Swan contrôle les redirections en préproduction puis en production, et exporte le plan en CSV, avec l'origine de chaque URL, ou en règles de redirection. Ce même CSV, rapproché de vos exports Analytics et Search Console, sert de table de passage pour comparer chaque page avant et après la migration.

• Que sauvegarder avant une migration : la liste complète
• Sauvegarder la base de données
• La liste de contrôle d'une migration SEO