Un échec de la vérification du site dans Google Merchant Center en 2026 ne se règle pas en supprimant plusieurs fois la balise ni en créant immédiatement un nouveau compte. Commencez par distinguer la propriété non vérifiée, le domaine non revendiqué et la revendication détenue par un ancien compte ; récupérez ensuite l’administrateur historique avant toute migration.
Cette méthode s’applique si votre boutique est déjà en ligne, si vos produits ou vos campagnes ont été associés à un compte existant, ou si vous reprenez un projet géré auparavant par une agence.
Le diagnostic initial
Dans ce type d’incident, le même domaine peut apparaître dans plusieurs écrans, mais les blocages ne correspondent pas au même niveau de contrôle. La vérification confirme que vous pouvez administrer le site. La revendication attribue ensuite le domaine à un compte Merchant Center, avec des limites lorsqu’un autre compte le détient déjà. L’association avec Google Ads, Shopify ou une source de produits constitue un troisième niveau.
Les règles officielles de Google distinguent bien la vérification et la revendication du site ; elles précisent également que la revendication d’une adresse peut dépendre de son compte propriétaire. Consultez la documentation officielle sur la vérification et la revendication d’un site dans Merchant Center avant de modifier votre configuration.
Commencez par conserver les éléments suivants, sans supprimer de balise ni retirer de fichier :
- le message d’erreur complet ;
- l’identifiant du compte Merchant Center concerné ;
- l’URL saisie, avec son protocole et son éventuel sous-domaine ;
- l’adresse Google actuellement connectée ;
- le nom des anciens administrateurs, prestataires ou agences ;
- les connexions existantes avec Google Ads, Shopify et les sources de produits.
Tableau de tri des incidents
| Symptôme observé | Niveau probable | Première action | Action à éviter |
|---|---|---|---|
| Merchant Center indique que le site n’est pas vérifié | Propriété du site | Recontrôler l’URL, la méthode de preuve et les droits | Ajouter plusieurs méthodes au hasard |
| Search Console confirme la propriété, mais Merchant Center refuse la revendication | Correspondance de compte ou d’adresse | Vérifier le compte Google utilisé et le type de propriété | Changer simultanément de compte et d’URL |
| Le domaine est déjà revendiqué | Conflit de compte | Identifier l’ancien Merchant Center et ses administrateurs | Créer un compte concurrent |
| Shopify ne relie pas le bon compte | Association de plateforme | Contrôler l’adresse Google et l’identifiant Merchant Center | Réinstaller l’application en boucle |
| Les produits ou les annonces ont cessé de fonctionner après un changement | Association historique rompue | Restaurer l’ancien accès et inventorier les connexions | Fermer l’ancien compte sans plan de reprise |
La vérification du site
Que faire lorsque Merchant Center affiche que le site n’est pas vérifié ?
Vérifiez d’abord que l’adresse déclarée correspond exactement à celle utilisée par votre boutique et vos liens produits. Examinez le protocole, le domaine racine, le préfixe www et les éventuels sous-domaines. Une propriété validée pour une adresse ne couvre pas nécessairement une autre adresse saisie dans Merchant Center.
Google peut proposer plusieurs méthodes, selon votre compte et l’état de votre site : validation par une balise HTML, fichier accessible publiquement, Google Analytics, Google Tag Manager, Search Console ou vérification proposée par une plateforme partenaire. L’interface disponible dans votre compte fait foi ; ne partez pas du principe que toutes les méthodes seront proposées à chaque utilisateur.
Pour isoler le problème, procédez dans cet ordre :
- Copiez l’URL affichée dans Merchant Center et comparez-la avec l’URL publique de la page d’accueil.
- Ouvrez la page dans une fenêtre de navigation privée, sans session Google active.
- Si vous utilisez une balise, consultez le code source public et vérifiez qu’elle est placée dans la section attendue.
- Si vous utilisez un fichier, testez directement son adresse publique depuis la même fenêtre privée.
- Contrôlez que le site ne redirige pas vers un autre domaine ou un autre sous-domaine.
- Capturez le message d’erreur, la source de la page et l’écran de la méthode choisie.
- Ne modifiez qu’un élément à la fois, puis relancez la vérification.
Les preuves à conserver
Votre dossier doit permettre à un autre administrateur de comprendre ce qui a été testé. Conservez notamment :
- une capture de l’erreur sans données personnelles inutiles ;
- l’URL exacte du site et la date de la tentative ;
- une capture de la balise ou du fichier, sans exposer de jeton sensible ;
- l’adresse Google utilisée pour la vérification ;
- le statut visible dans Merchant Center après chaque changement.
La propriété Search Console et la revendication
Pourquoi un site vérifié dans Google Search Console peut-il rester impossible à revendiquer ?
Parce que Search Console et Merchant Center ne donnent pas exactement le même niveau d’accès. La propriété peut être confirmée dans Search Console avec une adresse Google qui n’est pas administratrice du Merchant Center cible, ou avec une propriété qui ne couvre pas l’URL actuellement saisie.
Commencez par identifier le type de propriété Search Console :
- une propriété de domaine couvre généralement un domaine et ses variantes, selon la méthode de validation ;
- une propriété avec préfixe d’URL est limitée à l’adresse et au périmètre déclarés ;
- un sous-domaine ou un chemin différent peut donc ne pas correspondre à l’adresse utilisée dans Merchant Center.
Vérifiez ensuite que le propriétaire Search Console a été ajouté au compte Merchant Center cible avec un niveau d’accès suffisant. Être simple utilisateur d’un compte ne signifie pas nécessairement pouvoir modifier la revendication du site. Les niveaux d’accès et rôles des utilisateurs Merchant Center expliquent cette différence.
La correction la plus sûre consiste à ajuster un seul facteur à la fois :
- confirmer l’adresse Google active dans Search Console ;
- confirmer le type et le périmètre de propriété ;
- confirmer l’invitation au bon Merchant Center ;
- accepter l’invitation avec l’adresse appropriée ;
- relancer la revendication sans changer simultanément le domaine ;
- enregistrer le résultat et le message affiché.
L’ancien compte et le domaine déjà revendiqué
Comment réagir lorsqu’un ancien Merchant Center détient déjà la revendication du domaine ?
Recherchez d’abord l’ancien compte plutôt que de tenter une nouvelle revendication. Consultez les courriels historiques, les invitations de collaborateurs, les messages envoyés par l’agence et les comptes Google utilisés pour les campagnes. Demandez également à l’ancien responsable de confirmer l’identifiant Merchant Center, les sources de produits et les connexions Google Ads.
Si l’ancien compte reste accessible, la meilleure séquence est la suivante :
- ajoutez un administrateur actuel ;
- vérifiez que cette adresse peut ouvrir Merchant Center ;
- inventoriez les sources de produits, les campagnes et les utilisateurs ;
- confirmez que le domaine revendiqué est bien celui de la boutique actuelle ;
- transférez progressivement les responsabilités ;
- ne fermez l’ancien compte qu’après validation des associations.
Si l’ancien compte est réellement inaccessible, réunissez les preuves de propriété du site, les informations sur les administrateurs connus et l’historique des associations, puis utilisez la procédure officielle adaptée au conflit. La page Google consacrée à la résolution des conflits de comptes Merchant Center doit guider cette étape. Ne supprimez pas le compte historique avant d’avoir identifié ce que vous devrez reconstruire.
Attention : une adresse réseau américaine, un Mac distant ou une nouvelle session de navigation ne prouve pas la propriété d’un domaine et ne lève pas une restriction de compte. Ces moyens peuvent aider à reproduire un écran ou à séparer des sessions, mais ils ne remplacent jamais les droits administratifs ni la procédure officielle.
L’association Shopify et les comptes Google
Pourquoi Shopify Google & YouTube peut-il connecter le mauvais compte Merchant Center ?
Le problème vient souvent d’une différence entre l’adresse Google utilisée dans Shopify, celle active dans le navigateur et celle qui possède les droits nécessaires dans Merchant Center. L’application peut également être liée à un identifiant Merchant Center différent de celui que vous souhaitez conserver.
Avant de réinstaller ou de reconnecter l’application, vérifiez :
- l’adresse Google affichée pendant l’autorisation ;
- l’identifiant Merchant Center proposé ;
- le domaine Shopify actuellement publié ;
- le statut de la revendication dans Merchant Center ;
- les droits de l’utilisateur qui lance la connexion ;
- la présence d’autres sessions Google ouvertes dans le navigateur.
Conservez trois résultats séparés : l’état affiché dans Shopify, l’état du compte Google autorisé et le résultat final dans Merchant Center. Si le domaine est encore revendiqué par un ancien compte, traitez d’abord ce conflit. Réinstaller plusieurs fois l’application avant cette correction peut multiplier les associations difficiles à retracer.
La reprise par une nouvelle équipe
Lorsqu’un salarié quitte l’entreprise ou qu’une agence est remplacée, la priorité est de conserver la continuité plutôt que de repartir de zéro. Ajoutez les nouvelles adresses avant de retirer les anciennes, documentez la raison de chaque modification et sauvegardez les écrans de permissions.
Utilisez cette liste avant toute suppression :
- [ ] Le domaine exact a été comparé entre la boutique, Merchant Center et Search Console.
- [ ] Le message d’erreur complet et l’identifiant Merchant Center ont été conservés.
- [ ] L’ancien compte, ses administrateurs et ses invitations historiques ont été recherchés.
- [ ] Une adresse actuelle dispose d’un accès administrateur vérifiable.
- [ ] Les sources de produits et les liens Google Ads ont été inventoriés.
- [ ] Le statut Shopify Google & YouTube a été relevé avant toute reconnexion.
- [ ] Une seule modification a été effectuée entre deux tests.
- [ ] Les captures sont masquées et stockées dans un emplacement partagé contrôlé.
- [ ] Au moins deux administrateurs traçables peuvent reprendre le dossier.
- [ ] La date, l’auteur et le motif de chaque changement de domaine sont consignés.
Pour une équipe répartie entre plusieurs pays, un environnement Mac distant pour le travail d’équipe peut servir à conserver un navigateur propre, des profils utilisateurs séparés et un journal de captures. Un accès distant ne remplace toutefois ni la propriété du domaine, ni les droits Merchant Center, ni une décision prise par Google.
La réplique contrôlée et l’acceptation finale
Avant de déclarer l’incident résolu, reproduisez le parcours avec un compte autorisé et une session indépendante. Ouvrez la page publique, connectez-vous à Search Console, puis contrôlez Merchant Center sans utiliser les anciennes sessions enregistrées. Notez l’adresse sélectionnée par chaque écran.
Pour les équipes qui doivent se relayer sur des tâches de catalogue, de publicité ou de création visuelle, un Mac hébergé dans un environnement distant peut faciliter la conservation d’un poste de travail stable pour les captures, les contrôles Safari et les échanges entre opérateurs. Il ne faut pas le présenter comme un moyen de garantir une validation, d’effacer un conflit de compte ou de rétablir automatiquement une annonce.
L’acceptation finale doit répondre à quatre questions :
- Le compte actuel peut-il afficher le site comme vérifié et revendiqué ?
- Les URL des produits correspondent-elles au domaine réellement exploité ?
- Les sources de produits sont-elles encore rattachées au bon compte ?
- Les utilisateurs et les connexions Google Ads sont-ils identifiables par un responsable actuel ?
Pour un indépendant qui utilise uniquement son ordinateur actuel, le contrôle local est souvent suffisant, mais il devient moins pratique lorsque plusieurs personnes se succèdent, que les sessions Google se mélangent et que les preuves doivent rester disponibles en permanence. Les méthodes fondées sur des profils de navigateur locaux présentent alors trois faiblesses concrètes : elles dépendent d’un poste précis, elles conservent facilement de mauvaises sessions et elles offrent peu de séparation entre opérateurs.
Dans ce cas, louer un Mac auprès de MACGPU peut offrir un espace macOS distant et durable pour les vérifications, les captures et les relais d’équipe, sans prétendre résoudre les droits du domaine à votre place. La décision reste pertinente surtout pour des besoins temporaires ou de coordination ; pour une charge lourde permanente, un poste physique dédié ou une infrastructure interne peut être plus rationnel. L’essentiel est de rétablir d’abord la propriété et les associations officielles, puis d’utiliser l’environnement de travail comme support de suivi, jamais comme contournement.