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

[FlodAriege]

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à !

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 :


Bizarre non ?

Merci d'avance pour vos conseils.
Flo

[RobertG]

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.

[FlodAriege]

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



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...

[jfque]

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.

[woluweb]

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.

[jfque]

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.

[woluweb]

ah, juste jfque ! J'ai lu trop vite "AdWords" alors qu'il s'agissait bien de "AdWords"

[FlodAriege]

Bonsoir,

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

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 ??

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...

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.

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...

[FlodAriege]

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 ?

[jfque]

"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 ?

[FlodAriege]

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 ?

[jfque]

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.

[FlodAriege]

Bonjour,

Encore moi...

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.":

<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...)

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 ?

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:

 [TABLE]
[TR]
[TD]<!-- Global site tag (gtag.js) - Google Analytics -->[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]<script async src="[URL="https://www.googletagmanager.com/gtag/js?id=UA-48863218-1"]https://www.googletagmanager.com/gtag/js?id=UA-123445678-1[/URL]"></script>[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]<script>[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]window.dataLayer = window.dataLayer || [];[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]function gtag(){dataLayer.push(arguments);}[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]gtag('js', new Date());[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD] [/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]gtag('config', 'UA-12345678-1');[/TD]
 		[/TR]
[TR]
[TD] [/TD]
 			[TD]</script>[/TD]
 		[/TR]
[/TABLE]

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

[jfque]

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.

[FlodAriege]

Me revoilà.

* 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.

* 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)

* 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...

* 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.

* Pour le Tag Manager, (...) J'ai écris un article à ce sujet.

Très clair votre article.

* 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 !!