Repérer l’ancienne adresse dans le tableau de bord
Après un passage en HTTPS ou un déménagement, Site Kit peut afficher une adresse inattendue, une demande de reconnexion ou un tableau de bord qui ne correspond plus aux pages du site. Commencez par noter l’écran exact. Un message indiquant que l’URL a changé, un refus d’autorisation et une période sans données sont trois observations différentes. Pour chaque observation, indiquez l’adresse de l’administration, l’adresse publique attendue et le module affiché. Ce guide traite des données de recherche associées à Search Console. Une divergence dans Analytics demande de relever sa propre propriété et ses réglages.
Ouvrez une page représentative du site depuis un lien connu et notez son adresse finale. Comparez le protocole, le nom d’hôte et le chemin avec l’adresse que le propriétaire a validée. Une redirection temporaire vers l’ancien site ou une connexion ouverte sur un autre WordPress peut expliquer le symptôme avant toute modification dans Site Kit. Dans WordPress, les adresses de Réglages > Général peuvent différer volontairement si les fichiers sont dans un sous-dossier. Lisez-les pour comprendre le montage. Une égalisation des deux valeurs sans vérifier ce montage peut empêcher l’accès.
Avec un accès de consultation, consignez le message et la période sans demander des droits d’administration supplémentaires. Avec un accès WordPress qui permet de gérer Site Kit, relevez aussi la configuration. Le compte Google qui voit les données de Search Console et le rôle WordPress qui permet de configurer Site Kit répondent à des autorisations différentes. Demandez au propriétaire de les rapprocher au lieu d’emprunter une session.
Comparer les périmètres avant de changer de propriété
Dans WordPress, ouvrez Site Kit > Réglages > Services connectés > Search Console. Relevez la propriété affichée. Depuis Search Console, un utilisateur déjà autorisé peut ouvrir le sélecteur et lire le périmètre des propriétés auxquelles il a accès. Une propriété de domaine englobe les protocoles et les sous-domaines de ce domaine. Une propriété de préfixe couvre les adresses qui commencent par le préfixe spécifié, y compris le protocole et le chemin éventuel. Une propriété couvrant davantage d’adresses peut afficher plus de données pour la même période.
Exemple fictif. Une propriété de préfixe en HTTP suivait l’ancienne adresse. Le site répond désormais en HTTPS. Comparez cette propriété et celle qui couvre effectivement les pages HTTPS. Si l’équipe utilise une propriété de domaine, filtrez le rapport direct sur une page ou une adresse représentative avant de rapprocher les résultats. Le total du domaine et le total du préfixe peuvent rester différents pour une raison légitime. Gardez le même intervalle et un périmètre de pages comparable.
Le tableau de bord Site Kit affiche une partie des données. Pour vérifier que la source est la bonne, privilégiez le nom de la propriété et le contexte du rapport plutôt qu’une égalité au clic près entre deux écrans. Une période récente peut être incomplète. Le message de collecte peut aussi apparaître temporairement après une nouvelle connexion. Choisissez une période passée avec un témoin connu dans Search Console si vous pouvez y accéder. Si aucun compte autorisé ne voit la propriété voulue, faites d’abord résoudre cet accès.
Approche 1. Choisir une autre propriété lorsqu’elle est proposée
Cette approche s’applique quand le tableau de bord de l’installation fonctionne et que la propriété voulue est disponible dans les réglages du module. Avant de changer, notez la propriété actuelle et la propriété attendue. Vérifiez que l’une est réellement la cible voulue. Une propriété d’équipe peut être plus large qu’une propriété dédiée à une sous-section. Le choix doit correspondre à l’usage prévu des rapports, même si les deux couvrent la page d’accueil.
Ouvrez les réglages Search Console dans Services connectés, puis choisissez la propriété disponible qui correspond au périmètre validé. Enregistrez si l’interface le demande, rouvrez les réglages et relevez l’identifiant affiché. Le module Search Console est requis pour Site Kit. Son réglage peut permettre de choisir entre plusieurs propriétés du même site, mais il ne fournit pas une déconnexion indépendante comme certains services facultatifs.
Si la propriété attendue est absente, vérifiez d’abord le compte Google associé et sa capacité à ouvrir cette propriété directement. Si le compte a perdu un accès ou a changé pendant l’ajout d’un autre service, faites intervenir le propriétaire. Relevez le message d’autorisation sans transmettre de jeton ou de capture contenant des données privées. Tant que la propriété est introuvable pour ce compte, une réinitialisation globale risque de remplacer un diagnostic d’accès par plusieurs services à reconnecter.
Distinguer un refus d’accès d’une période sans données
Lorsque Site Kit signale des droits insuffisants, demandez au titulaire du compte concerné d’ouvrir la même propriété directement dans Search Console. Comparez deux cas. Si l’accès direct manque également, le propriétaire de la propriété doit vérifier les droits du compte. Si l’accès direct fonctionne avec le même compte et que Site Kit refuse encore, consignez le compte effectivement associé à l’extension et le service après lequel le problème est apparu. Une connexion à un autre service avec un compte différent peut avoir modifié le compte associé.
Si les droits sont corrects et que les deux écrans affichent une période vide, élargissez la période vers des dates dont les données devraient être consolidées. La documentation Site Kit indique qu’après une connexion récente, l’affichage peut prendre environ 48 heures pour commencer à se remplir. Ce délai est un repère. Il ne garantit ni l’existence de données pour un nouveau préfixe, ni la disponibilité d’un rapport pour une adresse qui n’est pas couverte. Notez la date de connexion pour décider du prochain contrôle.
Demandez enfin si la personne qui a signalé l’écart voit un tableau de bord partagé ou le tableau de bord d’administration. Le partage permet à certains rôles de consulter des données sans connecter leur propre compte Google. Une disparition de cet écran après une réinitialisation peut refléter la perte du partage local, alors que le propriétaire voit toujours les rapports directement dans Search Console. Comparez d’abord les deux parcours et notez quels rôles doivent retrouver la lecture. L’ajout d’un rôle administrateur uniquement pour afficher des mesures élargirait inutilement ses possibilités.
Pour transmettre ce constat, préparez un relevé qui distingue trois états. Indiquez si le module est configuré, si le propriétaire voit la propriété et si le profil WordPress de consultation accède au tableau partagé. Ces contrôles orientent respectivement vers la configuration locale, l’autorisation Google ou le partage du tableau de bord. Refaire le test avec le même rôle après correction permet de vérifier le résultat attendu pour la personne concernée.
Sur une copie, évitez d’utiliser le tableau de bord comme preuve d’indexation de cette copie. Google documente un mode de préproduction dans lequel Site Kit affiche volontairement les données du site public. Si ce mode est utilisé, vérifiez avec le responsable que la configuration de test vise bien cette lecture. Une copie locale qui ne peut pas joindre les services ne reproduit pas le parcours de connexion. Elle reste suffisante pour contrôler l’adresse, les rôles et la présentation des écrans sans agir sur une propriété réelle.
Approche 2. Préparer une reconnexion quand l’URL du site a réellement changé
Si l’extension affiche explicitement que l’URL du site a changé et bloque la configuration, confirmez d’abord que le déménagement est terminé pour les pages utilisées. Une redirection encore en cours, une adresse temporaire ou un changement d’hôte non confirmé demandent un relevé avant une reconnexion. Le support Site Kit documente une réinitialisation de l’extension pour ce cas lorsqu’il faut effacer l’ancienne URL de sa configuration. Réservez-la au propriétaire qui peut remettre les services en place.
Avant de choisir cette opération, inventoriez les services connectés, les propriétés, les conteneurs et les réglages de partage du tableau de bord. Pour les services qui placent des balises sur le site, notez qui les fournit et vérifiez si Site Kit les a insérées. Une réinitialisation supprime les réglages locaux de l’extension, déconnecte ses utilisateurs et retire les extraits de code qu’elle avait placés. Elle ne supprime pas la propriété Search Console ni les rapports déjà conservés chez Google. Une collecte peut toutefois s’interrompre si sa balise dépendait de Site Kit et n’est pas rétablie.
Avec l’administrateur autorisé, utilisez Outils > Outils disponibles > Réinitialiser Site Kit si c’est le chemin accessible. Si les réglages de l’extension restent utilisables, la documentation indique aussi Site Kit > Réglages > Réglages d’administration. Relisez le périmètre de l’action et confirmez que l’équipe est prête à reconfigurer les services nécessaires. Pendant la configuration suivante, lisez l’adresse et la propriété proposées. Si la propriété voulue n’est pas disponible, consignez l’écart et revenez au contrôle des droits avant d’autoriser d’autres services.
Reconnecter les services prévus et vérifier leur source
Reliez d’abord l’installation à la propriété de recherche qui couvre l’adresse validée. Site Kit peut choisir une propriété vérifiée existante et peut créer une propriété de préfixe dans certains cas où aucune n’est associée. Ne traitez pas le premier choix automatique comme une preuve que le périmètre répond aux besoins de l’équipe. Vérifiez dans Services connectés la propriété effectivement retenue. Si l’équipe doit garder un préfixe historique pour les comparaisons, laissez ce rapport accessible aux personnes autorisées dans Search Console.
Reprenez ensuite le relevé des services supplémentaires. Rétablissez seulement les connexions prévues, avec les comptes et propriétés approuvés. Pour un service qui place une balise, faites vérifier la présence et l’origine de la balise après le retour. Si une autre extension la pose déjà, évitez d’activer un deuxième placement sans examiner ce montage. Reconstituez enfin les réglages de partage du tableau de bord nécessaires aux rôles qui les utilisaient avant l’opération.
Comparez l’ancienne adresse et la nouvelle dans le dossier de remise. Indiquez quelles données sont historiques, quelle propriété couvre les pages actuelles et quelle observation sera répétée après la collecte. Si la configuration reste bloquée, préservez les messages et la liste des services rétablis. Une deuxième réinitialisation avant de comprendre le premier échec peut interrompre des services qui avaient déjà été remis en place.
Exécuter une comparaison reproductible sur une copie autorisée
Préparez un tableau de recette avec deux adresses fictives, par exemple un ancien préfixe HTTP et une adresse HTTPS dans un sous-dossier. Notez pour chacune le protocole, l’hôte et le chemin. Demandez à un autre membre de l’équipe de déterminer quelle propriété de préfixe couvre chaque URL et si une propriété de domaine les couvre toutes deux. Si vous avez une préproduction connectée selon la procédure prévue par le site, reprenez l’exercice avec les identifiants de propriétés autorisés. Le résultat attendu est de pouvoir expliquer le périmètre de la propriété affichée sans déplacer la connexion publique.
Avec le compte de consultation, ouvrez une période passée et une page témoin. Notez si les données visibles proviennent de la propriété attendue. Avec un administrateur de la copie qui possède aussi les droits Google nécessaires, essayez le choix d’une propriété alternative seulement si les deux propriétés sont explicitement réservées à cet essai ou si le responsable a validé leur usage en lecture. Rétablissez le premier choix et vérifiez que l’identifiant revient. Une copie sans service de test peut servir à la comparaison documentaire. Consignez dans ce cas que le changement d’une connexion n’a pas été éprouvé.
Sur le site concerné, la correction se vérifie par trois observations. L’adresse publique est celle prévue, le module affiche la bonne propriété et un compte autorisé peut lire une période représentative ou expliquer pourquoi elle ne contient encore aucune donnée. Si les services supplémentaires ont été reconnectés, vérifiez-les séparément. Un rapport de recherche revenu ne prouve pas que les balises ou le partage des autres modules sont rétablis.
Prévoir le retour avant toute réinitialisation
Si vous avez seulement changé de propriété, revenez à la valeur précédente si elle reste proposée et si son accès est toujours valide. Comparez ensuite l’écran du module et le rapport direct. Si le compte a perdu ses droits, l’ancien choix peut ne plus être disponible. Le propriétaire doit alors traiter cet accès au lieu de multiplier les changements d’URL ou de recréer une propriété.
Une réinitialisation complète demande un retour de configuration service par service. La documentation décrit la reconnexion et la reconfiguration des services après cette action. Préparez donc la liste des propriétés et des réglages, ainsi que la personne qui peut refaire chaque étape. Un ancien fichier ou une ancienne base WordPress ne suffit pas à garantir la remise en place des autorisations Google. Pour une migration encore réversible, coordonnez le retour d’adresse avec le responsable du site avant de reconnecter les modules au mauvais domaine.
Gardez dans la remise le message initial, les adresses, la propriété avant et après, le résultat du contrôle de droits et la date du prochain relevé. Si une période de collecte ou une autorisation reste en attente, indiquez laquelle. Une personne qui reprend le dossier pourra ainsi vérifier la cause qui reste ouverte sans réinitialiser les services qui fonctionnent déjà.
