Points SEO à vérifier quand on change de template ?

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] Points SEO à vérifier quand on change de template ?

    Bonjour,

    Suite à des problèmes techniques que j'avais sur la précédente version de mon site (et une attaque qui l'a rendue inutilisable), j'ai accéléré le travail que je faisais sur une nouvelle version, développée sous un nouveau template.

    Visuellement tout va bien, le site fonctionne nickel, et aucun contenu n'a changé ni n'a été retiré.
    L'aspect est quasiment identique à la précédente version.

    Et pourtant...
    J'assiste à un véritable effondrement des stats de visite

    Pour tout vous dire, elles étaient même tombées à zéro pendant près d'une semaine... avant que je réalise que j'avais tout bonnement oublié de remettre le code de suivi !!

    J'ai réparé ma bêtise, et les stats sont revenues, mais... avec environ 400 visiteurs / jour au lieu des 1000 et quelques que j'avais jusque là !
    Stats Google Analytics 30 derniers jours comparés aux 30 jours précédents
    D'où ma question :
    Se pourrait-il que j'ai oublié un (autre) point important en réinstallant le site ?


    A noter que, par contre et à l'exception de la période pendant laquelle je n'avais pas de code de suivi en place, je n'assiste pas à un changement notable dans les stats de Google Adsense :

    Stats Google Adsense 30 derniers jours comparés aux 30j précédents
    Bizarre non ?

    Merci d'avance pour vos conseils.
    Flo


    Dernière édition par FlodAriege à 01/05/2019, 11h51 Raison: 1: penser à remettre le code de suivi ! 2: attendre quelques jours, les stats se stabilisent (3: possible dysfonctionnement passager de GA)
    Flo, Ariège

    Il n'y a que celui qui a honte d'apprendre qui a peur de demander

  • #2
    Bonjour,

    Si tes adresses de pages n'ont pas changé, tu n'as a priori rien à faire.
    Mais si je ne me trompe, ton site a été inaccessible en attendant que tu mettes sa nouvelle version en ligne, ça peut éventuellement expliquer une baisse de fréquentation, si des gens se sont retrouvés pendant quelques jours sur une page d'erreur.
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide). MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info hébergés chez PHPNET - +sites gérés chez 1and1 et OVH - Site pro : www.robertg-conseil.fr

    Commentaire


    • #3
      Bonjour Robert,

      En effet, le site a été inaccessible 2 ou 3 jours, puis je l'ai remis en ligne, mais sans le code de suivi.
      5 avril : mise hors ligne par mon hébergeur qui avait détecté une attaque, je m'en aperçois tard le soir
      8 avril : mise en ligne de la nouvelle version (sans code suivi GA)
      12 avril : je remets le code GA, les stats réapparaissent mais avec 400 visiteurs au lieu des 1000-1200 habituels.

      Et quand je compare mes rapports Analytics / Adsense, je vois :
      - dans Analytics : à la réapparition des stats, environ 50% de visiteurs en moins par rapport à la même période l'année dernière (300-400 utilisateurs/jour contre 700-750 l'an dernier.) et carrément 75% de moins par rapport à fin mars / début avril (1000-1400 fin mars 2019 !!)
      - dans Adsense : à la réapparition des stats, à peu près le même nombre de pages vues que l'an dernier (un peu plus en fait : en gros 1200 pages vues cette année contre 800-900 l'an dernier)

      Comme un bon vieux graphique parle plus que bien des mots, voici ce que j'essaie de dire.

      En jaune et orange : les stats de ces 30 derniers jours
      En bleu et gris : les stats de l'an dernier
      30 derniers jours vs l'an dernier, dans Adsense et dans Analytics


      Je sais bien qu'un visiteur et une page vue, ce n'est pas la même statistique, mais ce qui m'interpelle ici c'est la différence de réaction entre les deux outils.

      Dans Google Analytics (orange), les stats se sont effondrées bien en deça de ce que j'obtenais l'an dernier
      Tandis que dans Adsense (jaune), les stats sont revenues, après la période d'inaccessibilité du site, à peu près au niveau de ce qu'elles étaient juste avant, et un peu au-dessus de ce que j'obtenais l'an dernier.

      Se pourrait-il que Analytics ait besoin de temps pour se remettre à compter après une période de disparition du code de suivi ?
      Ou bien mon code pourrait-il être "mal implanté" et du coup ne compter que partiellement les visiteurs ?


      Là, il y a vraiment un truc que je ne comprends pas...

      Flo, Ariège

      Il n'y a que celui qui a honte d'apprendre qui a peur de demander

      Commentaire


      • #4
        GA comptabilise les pages dès que le code est présent, mais il est possible que le code ne soit pas présent sur toutes les pages ou qu'il fonctionne mal pour une raison quelconque. Comment est-il inséré dans les pages ? Utilisez-vous Google Tag Manager ?
        Un moyen de vérifier si le code est présent et fonctionne est de se mettre sur "temps réel" dans GA en naviguant sur le site pour voir si toutes les pages répondent. Evidemment s'il s'agit d'un gros site, ce n'est pas très pratique.
        Voir aussi sur la Search Console ou avec un outil de crawl si toutes les pages sont bien accessibles (pas de pages bloquées par le fichier robots.txt, pas d'erreurs 404, ...).
        Si le site a été victime d'une attaque, s'assurez que le problème est effectivement bien corrigé (pas de "porte dérobée" encore active) et que le site n'a pas été blacklisté. Un moyen rapide est de faire un scan sur Sucuri.
        Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
        Administrateur certifié Joomla! 3
        https://www.betterweb.fr/services

        Commentaire


        • #5
          Bonjour,
          Sauf si quelque-chose m'échappe, le fait que Google Analytics soit installé ou pas (et sur toutes les pages ou pas) n'influence PAS le nombre de visites.
          (juste que si on ne le met pas, forcément on peut pas voir les stats).
          Exemple : on pourrait très bien utiliser https://matomo.org/ plutôt que Google Analytics

          Par contre, même si un site est down (imaginons), AdWords c'est de la pub. Donc tant qu'on ne change pas la campagne, il n'y a pas de raisons que le nombre de "vues" de la campagne change.

          Si le site a été hors ligne quelques jours, là c'est par contre très possible que le site ait perdu son ranking en référencement naturel... et qu'il reçoive donc moins de visite.
          Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter lla base de connaissance : https://kb.joomla.fr

          Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez régulièrement ? Alors adhérer à l'AFUJ : https://www.joomla.fr/association/adherer

          Présentations : slides.woluweb.be | Coordonnées complètes : www.woluweb.be

          Commentaire


          • #6
            Attention, on parle de AdSense, pas de AdWords (qui s'appelle Google Ads maintenant), donc le nombre de visites a une influence.

            Et si les visites s'effectuent sur des pages où le code GA ne figure pas, elles ne seront pas comptabilisées, donc forcément le nombre total de visites va s'en ressentir.

            Le fait que le site ait été hors ligne n'influence le référencement naturel qu'en fonction du code retourné par le serveur pendant la mise hors ligne : il faut que la page "ce site est en maintenance ..." retourne un code 503 (temporairement indisponible) pour ne pas avoir d'influence. Il faut aussi savoir qu'à moins que le contenu du site change très fréquemment, googlebot ne passe pas tous les jours, donc il est très possible qu'il n'ait même pas détecté la mise hors ligne. Vous pouvez vérifier les dates de passage dans les logs du serveur si vous y avez accès.
            Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
            Administrateur certifié Joomla! 3
            https://www.betterweb.fr/services

            Commentaire


            • #7
              ah, juste jfque ! J'ai lu trop vite "AdWords" alors qu'il s'agissait bien de "AdWords"
              Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter lla base de connaissance : https://kb.joomla.fr

              Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez régulièrement ? Alors adhérer à l'AFUJ : https://www.joomla.fr/association/adherer

              Présentations : slides.woluweb.be | Coordonnées complètes : www.woluweb.be

              Commentaire


              • #8
                Bonsoir,

                D'abord, merci !
                Ensuite, pour vous répondre :

                Envoyé par jfque Voir le message
                GA comptabilise les pages dès que le code est présent, mais il est possible que le code ne soit pas présent sur toutes les pages ou qu'il fonctionne mal pour une raison quelconque. Comment est-il inséré dans les pages ? Utilisez-vous Google Tag Manager ?
                Le code est inséré via le template (template creator)
                Non, je n'utilise pas (encore ?) Google Tag Manager. N'ayant qu'un seul site et un seul code de suivi, je ne m'y suis pas intéressée, mais je devrais peut-être ??

                Envoyé par jfque Voir le message
                Un moyen de vérifier si le code est présent et fonctionne est de se mettre sur "temps réel" dans GA en naviguant sur le site pour voir si toutes les pages répondent. Evidemment s'il s'agit d'un gros site, ce n'est pas très pratique.
                Je peux faire quelques tests par sondage, mais le site à quelques 450 urls...

                Envoyé par jfque Voir le message
                Voir aussi sur la Search Console ou avec un outil de crawl si toutes les pages sont bien accessibles (pas de pages bloquées par le fichier robots.txt, pas d'erreurs 404, ...).
                Non, de ce côté-là tout semble en ordre.

                Envoyé par jfque Voir le message
                Si le site a été victime d'une attaque, s'assurez que le problème est effectivement bien corrigé (pas de "porte dérobée" encore active) et que le site n'a pas été blacklisté. Un moyen rapide est de faire un scan sur Sucuri.
                J'ai mis en ligne une version du site sur laquelle je travaillais depuis un moment. Enfin... Mis en ligne il l'était déjà mais sur un sous-domaine no index, no follow. La sauvegarde sur laquelle il se base est bien antérieure à l'attaque.
                Je vais regarder ce sucuri pour voir si je n'ai pas été blacklistée dans l'intervalle...
                Flo, Ariège

                Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                Commentaire


                • #9
                  Envoyé par jfque Voir le message
                  Attention, on parle de AdSense, pas de AdWords (qui s'appelle Google Ads maintenant), donc le nombre de visites a une influence.

                  Et si les visites s'effectuent sur des pages où le code GA ne figure pas, elles ne seront pas comptabilisées, donc forcément le nombre total de visites va s'en ressentir.

                  Le fait que le site ait été hors ligne n'influence le référencement naturel qu'en fonction du code retourné par le serveur pendant la mise hors ligne : il faut que la page "ce site est en maintenance ..." retourne un code 503 (temporairement indisponible) pour ne pas avoir d'influence. Il faut aussi savoir qu'à moins que le contenu du site change très fréquemment, googlebot ne passe pas tous les jours, donc il est très possible qu'il n'ait même pas détecté la mise hors ligne. Vous pouvez vérifier les dates de passage dans les logs du serveur si vous y avez accès.
                  Pendant la courte période d'inaccessibilite, j'avais juste un "Access denied" à l'écran.
                  Quelle erreur était renvoyée au serveur ? 503 ? Aucune idée... Comment le savoir ?
                  Flo, Ariège

                  Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                  Commentaire


                  • #10
                    "Access denied", ça resemble à un code 403. Pas idéal, mais pour quelques jours ce n'est probablement pas très grave.

                    Dans le cas présent, comme les recettes AdSense semblent avoir le même niveau que précédemment, on peut présumer que la quantité de visite est la même. je penche donc pour un problème d'insertion ou de fonctionnement du code GA. Peut-être un conflit JS sur certaines pages ?
                    Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
                    Administrateur certifié Joomla! 3
                    https://www.betterweb.fr/services

                    Commentaire


                    • #11
                      Bonsoir

                      Pas de blacklist, ouf !

                      Mais par contre, Sucuri me donne des infos qui ne me plaisent guère :

                      Protection

                      No website application firewall detected. Please install a cloud-based WAF to prevent website hacks and DDoS attacks.

                      Security Headers

                      Missing security header for XSS Protection.

                      Missing security header to prevent Content Type sniffing.

                      Missing Strict-Transport-Security security header.

                      Leaked PHP version. Your site is displaying your PHP version in the HTTP headers. Please set expose_php = Off.


                      => À part la dernière ligne que je dois pouvoir réparer moi même, pour le reste je met vais qu'aesecure (premium) faisait ça, non, je me trompe ?

                      Flo, Ariège

                      Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                      Commentaire


                      • #12
                        Pour les security headers, le code pour XSS protection est inclus dans la dernière version du .htaccess de J!. Pour les autres, les composants de sécurité comme Admin Tools (et probablement les autres) les proposent.
                        Pour la détection du code éventuellement manquant, un outil de crawl comme Screaming Frog SEO peut le détecter. Malheureusement, il va détecter s'il est présent ou pas, pas s'il fonctionne !

                        Peut-être une piste serait de comparer la période actuelle avec la période précédent la chute et regarder le résultat dans l'onglet "Comportement > Contenu du site" pour voir quelles URL ont vraiment chuté. Ensuite il faut naviquer sur ces pages et vérifier que le code est bien présent et que la console d'erreur ne signale aucun problème.
                        Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
                        Administrateur certifié Joomla! 3
                        https://www.betterweb.fr/services

                        Commentaire


                        • #13
                          Bonjour,

                          Encore moi...

                          Envoyé par jfque Voir le message
                          Pour les security headers, le code pour XSS protection est inclus dans la dernière version du .htaccess de J!. Pour les autres, les composants de sécurité comme Admin Tools (et probablement les autres) les proposent.
                          J'ai pourtant mis à jour vers la 3.9.5, je ne comprends pas pourquoi Sucuri ne détecte pas cette protection dans ce cas.
                          ceci dit, et bien que je puisse voir "Joomla! 3.9.5" en bas à droite de mon écran admin, quand je vais sur extensions / mises à jour, le composant me propose de passer de la 3.9.4.1 à la 3.9.5.2... Bizarre non ?

                          ceci dit, j'ai eu un message post-installation lors du passage de la 3.9.3 à la 3..9.4 qui disait :

                          Modifications pour .htaccess
                          Ajouter les lignes suivantes avant "## Mod_rewrite in use.":
                          Code:
                          <IfModule mod_headers.c>
                          Header always set X-Content-Type-Options "nosniff"
                          </IfModule>
                          Modifications pour web.config
                          Ajouter les lignes suivantes après "</rewrite>":
                          <httpProtocol>
                          <customHeaders>
                          <add name="X-Content-Type-Options" value="nosniff" />
                          </customHeaders>
                          </httpProtocol>
                          Est-ce que ça a quelque chose à voir avec le XSS ?

                          Je n'ai pas modifié mon htaccess car, ayant aeSecure premium activé dessus, j'ai d'abord voulu savoir si le htaccess mis en place par aeSecure ne prévoyait pas déjà cette nouvelle protection. J'ai posé la question sur le forum privé d'aeSecure il y a plus de 15 jours, et je n'ai toujours pas de réponse (qu'est-ce que je regrette Christophe...)



                          Envoyé par jfque Voir le message
                          Pour la détection du code éventuellement manquant, un outil de crawl comme Screaming Frog SEO peut le détecter. Malheureusement, il va détecter s'il est présent ou pas, pas s'il fonctionne !
                          Alors, j'ai bien installé Screaming Frog, mais franchement je n'arrive pas à trouver cette fonctionnalité : où se cache-t-elle ?
                          Tant qu'on y est, existe-t-il un moyen de lui faire crawler le site section par section ? (pour ne pas se heurter à la limite des 500 URLs)

                          Et puis, ensuite, comment puis-je vérifier que le code fonctionne ?

                          Envoyé par jfque Voir le message
                          Peut-être une piste serait de comparer la période actuelle avec la période précédent la chute et regarder le résultat dans l'onglet "Comportement > Contenu du site" pour voir quelles URL ont vraiment chuté. Ensuite il faut naviquer sur ces pages et vérifier que le code est bien présent et que la console d'erreur ne signale aucun problème.
                          Alors : je retrouve en haut du classement les pages que j'ai habituellement, et elles subissent toutes une baisse de fréquentation de l'ordre de 75 à 80%.
                          Si j'essaie de comparer la valeur 'Pages vues' de GA avec celle de Adsense, je vois pour la période des 7 derniers jours :
                          - 3835 pages vues selon GA
                          - 7758 pages vues selon Adsense
                          J'y perds mon latin.

                          Je reviens sur Google Tag Manager dont tu as parlé précédemment : quel est l'avantage d'utiliser ce moyen par rapport à l'insertion classique du code ?
                          Ceci dit, quand je regarde mon code GA de près, je vois qu'il est question de Google Tag Manager:
                          Code:
                           
                          <!-- Global site tag (gtag.js) - Google Analytics -->
                          <script async src="https://www.googletagmanager.com/gtag/js?id=UA-123445678-1"></script>
                          <script>
                          window.dataLayer = window.dataLayer || [];
                          function gtag(){dataLayer.push(arguments);}
                          gtag('js', new Date());
                          gtag('config', 'UA-12345678-1');
                          </script>
                          Je me suis alors tournée vers ma Search Console.
                          Et là je crois que j'ai aussi un problème :

                          Sous l'onglet Sitemaps, je lis "462 URL découvertes"
                          Mais sou l'onglet Couverture, je ne vois plus que 229 pages envoyées et indexées + 57 indexées mais non envoyées via un sitemap.
                          Alors que j'en avais 485 de valides jusqu'au 2 avril...
                          (la différence est allée se loger, semble-t-il, dans les Pages exclues... pourquoi diable ??)
                          Et que jusqu'au 4 avril j'avais 1000 et quelques visiteurs/jour, chiffre tombé à zéro le 5 avril quand le site a été mis hors ligne.

                          Donc pour moi il y a même 3 problèmes là derrière :
                          1) pourquoi Google n'indexe-t-il pas la totalité des 462 URLS découvertes ?
                          2) pourquoi le nombre d'URL valides est-il tombé de moitié 2 jours avant que le site ait été mis hors ligne ??
                          3) pourquoi la moitié ou presque des URL (qui étaient parfaitement valides jusque là) sont-elles passées dans le compte des pages exclues ? La seule catégorie de pages exclues qui a bondi en nombre à cette date, ce sont les Explorées actuellement non indexées, qui passe de 4 le 2 avril à 218 le 3 avril (soit 2 jours avant le shut-down du site)

                          Bon, mon post est déjà à rallonge, désolée, donc je l'envoie comme ça et m'en vais faire quelques analyses sur Analytics pour tenter de comparer les statistiques de l'ensemble des pages sur 2 périodes de 7 jours avant et après le shut-down.

                          je reviendrai ensuite avec les résultats, mais j'ai déjà posé plein de questions ....
                          Merci infiniment pour toute lumière apportée, même parcellaire, sur ce problème qui, pour l'heure, me dépasse.

                          Flo
                          Flo, Ariège

                          Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                          Commentaire


                          • #14
                            Bon, dans l'ordre :

                            * Les protections sont à inclure dans le fichier .htaccess. Une simple mise à jour de J! ne le fera pas automatiquement parce que c'est un fichier htaccess.txt qui est présent, pas un .htaccess. Ceci parce que la configuration de chaque serveur peut être différente et il n'est pas possible d'avoir un .htaccess "universel".

                            * Cette mise à jour 3.9.5.2 ne concerne que le fichier langue en français. Les versions de J! n'ont que trois chiffres, jamais quatre. Vous pouvez faire cette mise à jour.

                            * Oui, c'est une erreur de ma part, c'est la protection "nosniff" qui est proposée, pas contre le XSS, mais comme dit plus haut, c'est une modification que vous devez faire manuellement.

                            * Pour Screaming Frog, il faut passer par les champs "Custom", mais je ne sais pas s'ils sont présents dans la version gratuite. Pour limiter le crawl, on pourrait partir d'une sous-section du site (par exemple www.mondomaine.com/section1), mais il est à peu près certain que vous avez un menu sur cette page, donc il va suivre tous les liens de ces menus et, avec un gros site, vous arriverez vite à la limite, d'autant que ce ne sont pas des URL mais des URI, donc des "objets" (images, fichiers CSS, fichiers JS, ...). C'est un super programme, mais il est cher et il faut en avoir l'usage (je l'utilise pour les audits SEO de mes clients).

                            * Différences entre pages vues par GA et Adsense : bien qu'ayant très peu d'expérience avec AdSense, ça ne me paraît pas anormal. GA, c'est la "machine" qui interagit avec la page (via un script JS), tandis que pour AdSense, c'est un autre code qui est contenu dans l'annonce, avec un autre script. On peut très bien avoir un conflit avec l'un et pas l'autre. La bonne nouvelle là dedans c'est qu'a priori vos recettes de publicité ne diminuent pas, donc il n'y a pas de problème de visibilité/fréquentation réelle du site, juste un problème de "comptage".

                            * Pour le Tag Manager, son intérêt est quand on doit insérer plusieurs codes de suivi (AdSense, pixel Facebook, autres codes de suivi, ...) : tout se fait au même endroit et en insérant une seule balise. Le code que vous affichez est bien celui de GA, mais ils ont changé récemment le nom et ça porte à confusion. Peut-être une préparation pour un moment où ils imposeront le Tag Manager ? Attention quand même avec ce Tag Manager : il faut bien en sécuriser l'accès parce que celui qui y a accès peut alors injecter n'importe quel code sur votre site. J'ai écris un article à ce sujet.

                            * Pour le changement dans l'indexation, il faudrait voir si la Search Console donne une raison pour l'exclusion des URLs. Voir aussi si ces pages n'ont pas une balise "meta robots" avec noindex qui se serait égarée.
                            Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
                            Administrateur certifié Joomla! 3
                            https://www.betterweb.fr/services

                            Commentaire


                            • #15
                              Me revoilà.

                              Envoyé par jfque Voir le message
                              * Les protections sont à inclure dans le fichier .htaccess. Une simple mise à jour de J! ne le fera pas automatiquement parce que c'est un fichier htaccess.txt qui est présent, pas un .htaccess. Ceci parce que la configuration de chaque serveur peut être différente et il n'est pas possible d'avoir un .htaccess "universel".
                              * Oui, c'est une erreur de ma part, c'est la protection "nosniff" qui est proposée, pas contre le XSS, mais comme dit plus haut, c'est une modification que vous devez faire manuellement.
                              OK. Je vais essayer de scruter le .htaccess d'aeSecure voir s'il ne contient pas déjà ces instructions, et j'ajouterai les codes le cas échéant, merci.

                              Envoyé par jfque Voir le message
                              * Cette mise à jour 3.9.5.2 ne concerne que le fichier langue en français. Les versions de J! n'ont que trois chiffres, jamais quatre. Vous pouvez faire cette mise à jour.
                              Oh! Pinaize! Fait, merci !
                              (je le jure, je ne suis pas blonde)

                              ​​​​​​​
                              Envoyé par jfque Voir le message
                              * Pour Screaming Frog, il faut passer par les champs "Custom", mais je ne sais pas s'ils sont présents dans la version gratuite. (...).
                              Oui, il y a bien un champ Custom dans la version gratuite. Mais après... ?? Comment saisir le ou les filtres ?
                              Et ceci dit, comme vous le dites, il va voir si le code est là, mais pas s'il fonctionne...
                              ​​​​​​​
                              Envoyé par jfque Voir le message
                              * Différences entre pages vues par GA et Adsense : bien qu'ayant très peu d'expérience avec AdSense, ça ne me paraît pas anormal. GA, c'est la "machine" qui interagit avec la page (via un script JS), tandis que pour AdSense, c'est un autre code qui est contenu dans l'annonce, avec un autre script. On peut très bien avoir un conflit avec l'un et pas l'autre. La bonne nouvelle là dedans c'est qu'a priori vos recettes de publicité ne diminuent pas, donc il n'y a pas de problème de visibilité/fréquentation réelle du site, juste un problème de "comptage".
                              Oui, je suis d'accord avec vous dans votre analyse.
                              Du coup je peux prendre un peu de temps pour rétablir le bon comptage, sachant qu'il ne s'agit pas vraiment de visiteurs perdus.
                              ​​​​​​​
                              Envoyé par jfque Voir le message
                              * Pour le Tag Manager, (...) J'ai écris un article à ce sujet.
                              Très clair votre article.
                              ​​​​​​​
                              Envoyé par jfque Voir le message
                              * Pour le changement dans l'indexation, il faudrait voir si la Search Console donne une raison pour l'exclusion des URLs. Voir aussi si ces pages n'ont pas une balise "meta robots" avec noindex qui se serait égarée.
                              Ah ! Voilà le gros morceau !

                              J'ai une quantité invraisemblable de pages qui ne sont plus indexées à partir du 3 avril (2 jour avant le signalement de l'attaque et la fermeture du site).
                              Au même moment, c'est la sous-catégorie des pages "explorées, actuellement non indexées" qui connait une forte augmentation, et qui atteint à peu près le nombre de pages disparues de l'index (218 pages concernées).

                              Quand je clique sur le détail des pages en question, je vois :
                              dernière exploration : 1 avril 2019

                              a) elles ne sont pas bloquées par robots.txt

                              b) quand je fais 'Inspecter l'URL', ça affiche :

                              9 fois sur 10 environ :
                              OK Cette URL est sur Google
                              Elle peut figurer dans les résultats de la recherche Google (du moment qu'elle ne fait pas l'objet d'une action manuelle ou d'une demande de suppression) avec toutes les optimisations appropriées
                              OK Couverture
                              Envoyée et indexée ===> dans ce cas pourquoi cette page figure-t-elle dans la liste des pages "explorées, actuellement non indexées" ???

                              OK Ergonomie mobile
                              pages adaptée aux mobiles

                              La fois sur 10 restante :
                              ! Cette URL est sur Google, mais présente des problèmes
                              OK Couverture
                              Envoyée et indexée

                              ! Ergonomie mobile
                              Page non adaptée aux mobiles
                              => texte illisible, car trop petit
                              => éléments cliquables trop rapprochés
                              => contenu plus large que l'écran
                              ==>> J'inspecte alors l'URL en ligne pour voir quels éléments ne sont pas compatibles mobile et... Tout est OK, et les coches vertes OK Mobile reviennent sur la Search console.

                              Franchement, là, je suis complètement larguée !!
                              ​​​​​​​
                              Flo, Ariège

                              Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                              Commentaire

                              Annonce

                              Réduire
                              1 sur 2 < >

                              C'est [Réglé] et on n'en parle plus ?

                              A quoi ça sert ?
                              La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                              Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                              Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                              Comment ajouter la mention [Réglé] à votre discussion ?
                              1 - Aller sur votre discussion et éditer votre premier message :


                              2 - Cliquer sur la liste déroulante Préfixe.

                              3 - Choisir le préfixe [Réglé].


                              4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                              2 sur 2 < >

                              Assistance au forum - Outil de publication d'infos de votre site

                              Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                              Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                              Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                              UTILISER À VOS PROPRES RISQUES :
                              L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                              Problèmes connus :
                              FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                              Installation :

                              1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                              Archive zip : https://github.com/AFUJ/FPA/zipball/master

                              2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                              3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                              4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                              5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                              6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                              et remplacer www. votresite .com par votre nom de domaine


                              Exemples:
                              Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/
                              Pour executer le script: http://www..com/fpa-fr.php

                              Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/cms/
                              Pour executer le script: http://www..com/cms/fpa-fr.php

                              En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                              Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                              Voir plus
                              Voir moins

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X