Une semaine après la refonte, Search Console affiche 4 020 clics sur les pages de service, contre 4 000 sur la période témoin. Pourtant, le commerce retrouve seulement 63 nouvelles demandes dans le CRM, contre 96 auparavant. Le formulaire mobile affiche toujours une confirmation. Le risque est de prendre cette confirmation pour la preuve que le commerce a reçu le dossier.
En pratique, la comparaison doit couvrir le clic Google, la réception par le site et l’arrivée dans l’outil du destinataire. Paradoxalement, des clics stables et une mesure de formulaire stable peuvent coexister avec une baisse réelle des demandes que l’équipe commerciale peut traiter.
Dans une migration ou refonte SEO, ce diagnostic aide à décider où intervenir. Le cas fictif suit 102 demandes enregistrées jusqu’au CRM et montre comment distinguer un rejet de transmission, une demande encore en cours et une variation de mesure.
Le guide de migration SEO et de refonte CMS permet de choisir les parcours à tester avant la mise en ligne. Le contrôle reprend ce périmètre, avec une preuve de réception à chaque étape. C’est un point de recette de notre accompagnement en SEO technique sur les sites qui alimentent un CRM.
Dans quels cas les clics stables sont trompeurs
Commencez par comparer les mêmes familles de pages, les mêmes jours de la semaine et des données suffisamment consolidées. Regroupez chaque ancienne URL avec sa destination validée. Annotez les changements de gabarit, de formulaire et d’attribution. Le total du site peut rester stable pendant qu’une page de devis perd du trafic au profit d’un guide. Dans ce cas, la baisse commerciale peut commencer avant l’arrivée sur le formulaire.
Décomposez ensuite les pages de service par appareil. Si le volume se déplace de l’ordinateur vers le mobile, vérifiez le comportement de chaque parcours. Le rapport sur les dimensions Search Console explique l’attribution des données à l’URL canonique. Conservez dans votre correspondance l’URL effectivement servie, car c’est elle qui détermine le gabarit et le formulaire reçus par le visiteur.
Le cas ci-dessous porte sur les mêmes pages de service et le même formulaire, avec deux fenêtres fictives de sept jours. Les agrégats de clics sont un signal d’acquisition, tandis que les demandes serveur sont comptées sur le périmètre de ces pages, tous canaux. Le rapprochement entre le site et le CRM se fait ensuite demande par demande. Les demandes dont la source est inconnue restent dans une catégorie distincte si l’équipe doit ventiler par canal.
Choisir une preuve à chaque étape
Comparer les tendances d’acquisition sans apparier les personnes
Search Console compte des clics et GA4 observe notamment des sessions et des événements. Le guide Google sur l’usage conjoint des deux outils explique pourquoi ces volumes peuvent diverger. Comparez la tendance par page, période et appareil, en tenant compte des filtres, du consentement et des changements de collecte. Une différence entre les deux totaux ne mesure pas des demandes perdues.
Dans GA4, form_submit décrit l’activité du formulaire telle qu’elle est instrumentée. L’événement recommandé generate_lead peut servir au reporting de l’acquisition de prospects. Documentez le moment exact où votre site l’envoie. Un événement observé dans le navigateur et un dossier accessible au commerce sont deux preuves différentes. Modifier le marquage ne rattrape pas les demandes métier.
Suivre une référence de soumission entre le site et le CRM
À l’entrée du parcours métier, le serveur attribue une référence à la demande acceptée et la conserve avant de répondre. À la sortie du traitement, le CRM renvoie une référence de dossier ou le connecteur signale une cause de rejet. La journalisation garde le formulaire, le gabarit, la version livrée, l’horodatage et l’état de transmission. Un contrôle côté métier vérifie aussi que le dossier se trouve dans la bonne file et que le destinataire peut l’ouvrir.
Utilisez ces références dans les outils internes avec des accès et une durée de conservation adaptés. Le rapprochement d’exploitation se fait à partir des traces serveur et CRM. Évitez d’envoyer des noms, e-mails ou messages de formulaire à l’outil analytics. Pour les tests, employez un dossier témoin identifié qui ne remonte pas comme une demande commerciale réelle dans le bilan.
Cas chiffré : 102 demandes sur le site, 63 dans le CRM
Le site fictif utilise le même formulaire sur deux gabarits. Le tableau s’appuie sur des demandes serveur distinctes, avec les tests, le spam identifié et les doublons exclus selon les mêmes règles. Chaque cohorte est relue au même délai après envoi. Une demande est classée en « reçue » quand elle est visible dans la file CRM attendue. Les quatre dossiers encore en traitement avant la refonte restent dans le dénominateur des demandes acceptées.
| Indicateur | Avant | Après |
|---|---|---|
| Clics Google Search | 4 000 | 4 020 |
| Demandes acceptées par le site | 100 | 102 |
| Demandes visibles dans le CRM | 96 | 63 |
| Demandes en cours de transmission | 4 | 3 |
| Demandes rejetées par le connecteur | 0 | 36 |
La réception CRM diminue d’environ 34 % malgré deux demandes acceptées de plus. Après la refonte, 39 des 102 demandes ne sont pas visibles dans le CRM au moment de la lecture. Le registre en explique 36 par un rejet et trois par un traitement encore en cours. L’équipe ne relance que les demandes dont l’état et l’absence de dossier ont été vérifiés.
Retrouver les 36 rejets sur le gabarit mobile
Comparer les gabarits plutôt que la moyenne du site
Sur ordinateur, 60 des 62 demandes acceptées après la refonte sont visibles dans le CRM et deux sont en cours. Sur mobile, le site en accepte 40, mais le CRM n’en reçoit que trois. Une est encore en traitement et 36 portent le même motif de rejet. La répartition explique les 102 demandes et montre pourquoi la mesure globale des soumissions ne suffit pas.
L’équipe reproduit le même choix « Assistance » sur ordinateur et mobile avec deux demandes de test. Le gabarit mobile envoie un nouveau code de service. Le serveur enregistre la demande et confirme la réception. En revanche, le connecteur ne trouve pas de correspondance pour ce code et arrête le traitement avant tout appel au CRM. Le code historique émis sur ordinateur rejoint bien la file prévue.
La preuve associe la version du gabarit, la valeur envoyée et le motif de rejet du connecteur. Pour fermer l’enquête, l’équipe vérifie que le nouveau code désigne bien le même service et reçoit une nouvelle demande mobile dans la file attendue après correction. La valeur métier doit être approuvée avant d’ajouter la correspondance. Une règle générique qui envoie tous les codes inconnus vers la file principale ferait disparaître les rejets tout en détournant certaines demandes.
Rattraper les demandes conservées
La correction du code arrête les nouveaux rejets. Le rattrapage suit une décision séparée : isoler les 36 références qui portent le motif, retrouver leur choix de service initial et vérifier pour chacune la présence d’un dossier CRM avant de relancer. Si une demande a déjà été reprise à la main, alors reliez la référence à ce dossier au lieu d’en créer un autre.
Dans le scénario, après vérification, les 36 demandes sont rejouées et chacune est confirmée dans la bonne file. La cohorte d’après refonte passe ainsi de 63 à 99 demandes reçues sur 102. Les trois demandes encore en cours gardent leur état. Le bilan distingue le rattrapage d’une cohorte passée du retour à la normale sur les nouvelles entrées. Le parcours formulaire vers Pipedrive détaille la reprise avec conservation des références et contrôle des doublons.
Choisir la correction selon l’étape en défaut
| Premier écart confirmé | Action |
|---|---|
| Clics en baisse sur les pages de devis | Contrôler la correspondance des URL, la visibilité et le mélange des pages d’entrée. |
| GA4 baisse, site et CRM stables | Vérifier le consentement, la définition de l’événement et son déclenchement. |
| Le site accepte moins de demandes | Rejouer le formulaire par appareil. Vérifier le rendu, les validations et la réponse serveur. |
| Site stable, CRM en baisse | Rapprocher les références acceptées, les états de transmission et les dossiers destinataires. |
| Dossiers reçus, qualifiés en baisse | Examiner les critères de qualification, le délai de traitement et les motifs de rejet métier. |
Si une transmission peut être corrigée et les demandes préservées, privilégiez un correctif ciblé sur le gabarit ou le connecteur. Si le formulaire ne conserve plus les demandes, le repli peut rétablir le parcours qui fonctionnait, avec validation de la réception avant réouverture. Dans les deux cas, sauvegardez les demandes déjà acceptées et relevez la version des composants avant l’intervention.
Erreurs fréquentes après la refonte
- Conclure avec le seul total de clics. Examinez les pages qui génèrent des demandes et les appareils qui les visitent.
- Prendre le message de confirmation pour une preuve CRM. Vérifiez la référence du dossier et son accès par le destinataire.
- Traiter toute absence comme un rejet. Séparez un traitement encore dans son délai, une erreur confirmée et un résultat inconnu.
- Rétablir l’événement GA4 avant le parcours. La correction de mesure peut rendre le graphique cohérent alors que le commerce attend toujours les demandes.
Plan d’action : contrôler le parcours à chaque mise en ligne
Définir le témoin et ses preuves avant la bascule
Sélectionnez les formulaires qui alimentent réellement le commerce. Pour chacun, documentez l’URL d’entrée, les variantes de gabarit et la file destinataire. Faites partir un témoin sur ordinateur et mobile, puis consignez la réception serveur et la confirmation CRM. Le responsable métier valide qu’il peut traiter le dossier et qu’il retrouve le bon service. Gardez aussi un contrôle du marquage adapté aux choix de consentement prévus.
À l’entrée de la recette, conservez la version des gabarits et la liste des services. En sortie, la journalisation doit relier chaque témoin à sa référence de dossier, ou expliquer le blocage. Fixez un seuil d’alerte adapté au délai normal de transmission. Par exemple, une demande marquée rejetée déclenche une revue immédiate, alors qu’un traitement dans son délai reste surveillé.
Consignez la date du déploiement, les gabarits touchés et le délai normal de traitement. Un formulaire mobile corrigé le mardi doit être comparé sur une cohorte de demandes émises après cette correction et observées au même délai. Gardez dans le bilan une ligne distincte pour les reprises manuelles.
Suivre la reprise sur des demandes nouvelles
Après correction, vérifiez les nouvelles demandes du gabarit affecté plutôt que d’évaluer le retour à la normale avec le seul lot rattrapé. Le responsable du connecteur examine les nouveaux rejets et le commerce valide la file. Le responsable SEO garde les pages d’entrée sous surveillance pour détecter un éventuel problème d’acquisition indépendant.
Le compte rendu distingue la période d’incident, les demandes récupérées et les dossiers encore en cours. Si un rejet réapparaît, la procédure de repli désactive la variante fautive ou rétablit sa dernière configuration reçue tout en préservant les soumissions déjà conservées. Attribuez la responsabilité des dossiers non rapprochés avant de fermer l’incident.
Guides complémentaires pour élargir le diagnostic
Si le volume des pages d’entrée change aussi, la méthode pour mesurer une migration SEO sans confondre les causes aide à isoler les effets de la bascule, du calendrier et de la demande.
Si la refonte est encore en préparation, le parcours de recette d’une refonte de site web replace le formulaire dans les contrôles de redirection, de rendu mobile et de continuité des demandes.
Conclusion : vérifier la réception des demandes
Des clics Google stables indiquent que l’acquisition reste du même ordre sur le périmètre observé. Dans le cas fictif, les demandes étaient bien conservées par le site et la baisse se situait entre le gabarit mobile et le CRM.
Rapprochez les références jusqu’à la file commerciale, corrigez le premier point confirmé et mesurez séparément le rattrapage. Le retour à la normale se vérifie aussi sur les demandes arrivées depuis la correction.
Dawap accompagne les migrations et refontes SEO en reliant l’ancienne et la nouvelle page d’entrée au résultat métier attendu.
Notre équipe SEO technique peut intégrer cette recette à vos mises en ligne, du premier formulaire jusqu’à la demande réellement exploitable.
