[RÉGLÉ] Analyse de site par Cocolyze

[RobertG]

Bonjour,

On m'a demandé de me baser sur l'analyse Cocolyze (que je découvre) pour corriger des erreurs 404 mais aussi des "pages non analysables" trouvées par cet outil.
Pour ce qui est des pages non analysables, il y a une flopée d'adresses de flux Atom et RSS dont je ne trouve pas d'où elles proviennent (comment sont-elles repérées par Cocolyze ?), mais aussi des images existant bien.
Il y a également des adresses qui n'existent plus dans le site (deuxième langue dont tout a été supprimé) et que Cocolyze affiche comme non analysable du fait de la redirection des pages absentes vers l'accueil.

Si quelqu'un a une expérience de cet outil, que faut-il penser de ces résultats ?
Merci de vos lumières !

[Fred2FR3]

Coucou Robert,
https://web-eau.net/tutoriels-joomla...er-un-flux-rss histoire de te mettre dans le bain.
Il y a certainement un flux RSS ou/et Atom pas a jour, peut être un module, je ne sais pas ... Faut creusé.

Tu nous informes pas sur la version de J!, les redirections des pages inexistantes peuvent être facilement gérable nativement (enfin je crois).

[RobertG]

Merci Fred,

Dans le site, aucun fil d'actualité n'a été créé, c'est pourquoi se pose la question de savoir pourquoi Cocolyze en trouve. Pas de composant, module ou plugin qui pourrait en générer.
J'ai seulement vu quelque part un paramètre les autorisant, en explorant un peu le site avant devis...
Pour moi, en dehors de cette incompréhension, ce classement en non analysable est à négliger.

Les redirections peuvent en effet être faites en interne, au moins pour certaines, avec le composant et le plugin de redirection, mais dans le cas d'un site multilingue revenant en monolingue, cela veut dire générer à partir de la langue supprimée des erreurs 404 récupérables par cette extension, puis trouver l'adresse vers quoi rediriger si la page était associée à une page du site en français. Il y en a 130 !
En attendant, j'ai modifié le fichier error.php du template pour renvoyer toutes les erreurs 404 vers l'accueil.

[Fred2FR3]

Dans le site, aucun fil d'actualité n'a été créé, c'est pourquoi se pose la question de savoir pourquoi Cocolyze en trouve.

Peut etre un sitemap.xml a la racine du site ?
Il est tout a fait possible qu'il fut créer par un plugin (ou autre chose) antérieurement.

[RobertG]

Rien dans le sitemap à la racine du site, et il n'est d'ailleurs pas à jour...
Bref, le mystère reste entier.

[daneel]

Bonjour,

Cocolyze n'est pas à recommander si tu ne pratique pas les bases et pour les pro, il est moins bon que Semrush ou Ahrefs. Au résultat, soit on ne comprends rien, c'est normal, soit totalement inutile.

Bon, je vais reprendre le principe. Tu le sais déjà, Google Search Console est le point de relation unique avec Google pour ce qui est de ton référencement sur le moteur de recherche.
Tu est notifié régulièrement des problèmes afin de les corriger. Pour tout site créé, tu dois avoir une connexion à GSC pour gérer le référencement.
https://search.google.com/search-console/about?hl=fr

Donc quand tu évoque les erreurs 404, tu n'utilise pas un outil externe mais bien celui fourni gratuitement par Google.
Ne sois pas influencé par autre chose et prends en compte uniquement ce qu'indique GSC.

Les erreurs 404 sont issus de plusieurs choses, des pages qui n'existent plus mais également des liens obsolètes internes ou externes (backlink). Parfois généré de façon malveillante mais rien à craindre, cela s'élimine naturellement avec le temps. Donc on gère mais pas question d'aller dans l'extrême ou de paniquer car cela ne sert à rien.

Dans les vues de type blog, on a automatiquement les liens rss accessibles dans les metadonnées (entre head et /head). Il suffit d'ajouter ?format=feed&type=rss à l'url existante mais comme c'est en metadonnées, c'est pas dans le contenu de l'article. Donc pour simplifier, l'outil proposé fait sans doute quelques erreurs, ce qui me ferait douter de son efficacité. Par ailleurs, je n'ai jamais utilisé autre chose que GSC et le site pour gérer les erreurs 404.

Pour les correctifs, on applique des redirections j'utilise soit le htaccess qui permet de créer des regex pour gérer en masse notamment des segments. Mais également le composant de redirection. J'évite toutefois la collecte automatique du plugin pour ne pas surcharger le site. Parfois j'utilise des extensions tierces.

Le plan de site xml est une option qui me permet de définir la fréquence d'actualisation, Google peut décider de suivre ou non. Le plan xml n'est pas obligatoire et pour google, on peut soumettre directement le lien généré par un composant comme osmap. En réalité, je gère dynamiquement l'adresse du xml à la racine du site car l'url à sitemap.xml à la racine n'est pas pour google mais pour les autres moteurs de recherche. Pour cela, je créé tout simplement une redirection spécifique dans le htaccess. Il est également en cache pour éviter que les sollicitations des robots sur le fichier xml prennent trop de ressources. Quand le volume de pages est important, le passage des robots a des répercutions sur les performances du site si le serveur n'est pas adapté.

Enfin, il est important de maintenir à jour le fichier robots.txt notamment avec l'évolution de Joomla sur la gestion des templates et templates enfants.

Pour résumer, il vaut mieux utiliser et maitriser ce qui fonctionne déjà. GSC a de nombreuses outils, fonctions et on est loin de connaître toutes les particularités si on ne travaille pas tous les jours dessus. Je ne dénigre pas les services web (j'ai aussi mes propres services) proposant des analyses mais parfois cela s'éloigne du vrai résultat. Par ailleurs, une véritable analyse doit être régulière afin d'avoir un repère dans le temps. Parfois, on est tenté de bloquer certains robots comme semrush qui devient envahissant.

Bref, faites votre avis mais utiliser GSC avant tout, n'oubliez pas les autres comme Bing Webmaster tools et autres....

[RobertG]

Merci Yann de toutes ces explications, mais j'ai été mandaté pour utiliser les résultats de Cocolyze dont la cliente a décidé que c'était ce qu'il fallait utiliser et que le webmaster du site (ne touchant en fait pas à Joomla! mais seulement à la question SEO et à la gestion du serveur) utilise pour ce site et d'autres.

C'est sur la base des résultats Cocolyze déjà existants que je dois intervenir. J'ai fait en plus appel à Pagespeed, n'ayant pas accès au compte GSC de la cliente.

Le site est difficile, datant de 2011, et ne comporte que des pages individuelles, il me semble. La cliente, professionnelle, y tient comme à a prunelle de ses yeux et ne veut en aucun cas en changer le look de crainte de perturber ses clients (ce que je comprends tout à fait compte tenu de sa profession), ce qui contraint à conserver un vieux template patché pour fonctionner sous J5.

La partie "espagnol" a été supprimée, il y a 130 liens de menus à rediriger et je doute qu'on puisse le faire avec des regex puisque les noms sont dans la langue. Pour le moment, toutes les 404 renvoient à l'accueil par une redirection dans le error.php et la question est en suspens de rediriger individuellement les adresses de l'espagnol au français quand il y avait une association ou de cette redirection générique vers l'accueil.

Il y a en tout 320 liens de menus : articles, alias, séparateurs, et j'ai trouvé une liste d'article non affichée dans son menu. Je ne vois pas comment m'y prendre pour savoir s'il y a des pages de type blog.

Pour le sitemap, j'utilise OSmap sur la plupart des sites dont je m'occupe. Ici, je ne sais pas avec quoi il a été généré. Le site utilise 4SEO et 4SEF, dont je n'ai pas vraiment l'expérience et dont je ne sais pas si 4SEO serait en mesure d'en générer un, c'était mon projet pour ce matin.

Quant au fichier robots.txt, il exclut des tas de pages sans que je sache, ni le webmaster, pourquoi. A ce que je crois comprendre, il y a eu une exclusion d'adresses courtes générées par sh404SEF, mais aussi d'autres... dont certaines pages sont pourtant fonctionnelles (mais comment trouver si elles sont liées à des menus ? Le site fonctionnant apparemment depuis longtemps en adresse réécrites au vol, en dehors de certains liens internes utilisant des adresses réécrites, les liens de menus ne le sont pas.

Personnellement, j'ai encore eu ces derniers mois des avis GSC fantaisistes à propos d'adresses n'existant pas sur des sites, ou des alertes parce que j'avais interdit l'indexation de certaines pages, alors j'ai du mal avec cet outil.

PS : c'est bien 4SEO qui génère et tient à jour le sitemap, mais il est censé être nomma sitemap-4seo.xml mais il n'y a qu'un sitemap.xml obsolète à la racine... J'ai lancé une régénération.

[daneel]

Merci Yann de toutes ces explications, mais j'ai été mandaté pour utiliser les résultats de Cocolyze dont la cliente a décidé que c'était ce qu'il fallait utiliser et que le webmaster du site (ne touchant en fait pas à Joomla! mais seulement à la question SEO et à la gestion du serveur) utilise pour ce site et d'autres.

C'est sur la base des résultats Cocolyze déjà existants que je dois intervenir. J'ai fait en plus appel à Pagespeed, n'ayant pas accès au compte GSC de la cliente.
...
Personnellement, j'ai encore eu ces derniers mois des avis GSC fantaisistes à propos d'adresses n'existant pas sur des sites, ou des alertes parce que j'avais interdit l'indexation de certaines pages, alors j'ai du mal avec cet outil.

Je comprends mieux mais tu as demandé un avis sur les résultats de cocolyze. Après , c'est comme chaque outil, il y a du bon et du mauvais.

Donc ne tiens pas compte de l'histoire des flux rss et pense à les désactiver pour être tranquille (articles/paramètres/intégration/flux RSS)

Pour les erreurs 404, J'ai toujours géré avec GSC et anticipé les problèmes, c'est à dire de rediriger soit avec le htaccess ou avec le composant de redirection.
Sous Joomla 3, j'ai bloqué les urls "fantaisistes" à l'époque de l'ancien système de routage... depuis joomla 4, je n'ai plus rencontré ce problème.
La redirection vers la page d'accueil n'est pas vraiment top pour le seo pour les pages modifiées ou supprimées, cependant j'ai bien compris que le contenu espagnol est supprimé donc difficile de faire autrement.

En résumé, je pense que tu règlera facilement l'histoire des flux rss mais pour le reste, mis à part rediriger sur la page d'accueil, tu n'as pas grand chose à faire pour le moment.

[RobertG]

Merci Yann !

Je ne comprends rien au sitemap de 4SEO dont l'adresse est fonctionnelle mais continue à inclure deux sitemaps pour l'espagnol et le français alors qu'il n'y a plus rien d'espagnol dans les pages 4SEF et 4SEO, que les paramétrages du site ont exclu l'espagnol et que plus aucun lien de menu n'est lié à l'espagnol, et cerise sur le gâteau, le nom du fichier est introuvable sur le ftp (sans redirection dans le .htaccess.
De plus, 4SEO est censé ajouter un sitemap dans le robots.txt, mais le nom est celui d'un sitemap datant de 2 ans.
Je vais renvoyer cette gestion au webmaster...

[tataye]

Force à toi pour ce site !!

[RobertG]

Merci !

[tataye]

et tu sais pourquoi

[RobertG]

Le plus dur sera de convaincre de changer de template !
Le reste, c'est su temps à y passer...

[RobertG]

Bonjour,

Cocolyze me sort des adresses de pages fantaisistes qui renvoient des erreurs 404.
Elles sont construites sur nom de domaine, suivi par catégorie d'articles, sous-catégorie et enfin par exemple

/index.php?option=com_content&view=article&id=332

et je ne me souviens pas avoir déjà vu de telles adresses.
Le pire, c'est qu'il y a plusieurs adresses se terminant avec exactement le même texte !

Dans le site, nulle part je n'ai trouvé d'adresse de ce type ni d'alias pouvant correspondre, ni dans les menus, ni dans 4SEF ou 4SEO !

Au niveau du site, la page d'erreur 404 de 4SEO fait son office en proposant des articles proches, mais c'est bien une 404 et je ne vois pas comment empêcher cette création d'adresse !
Quel casse-tête !!!

PS : il y a bien un lien de menu utilisant l'adresse citée, vers l'article 332, je ne vois donc pas comment gérer les 76 URLs trouvées par Cocolyze, sinon laisser 4SEO s'en occuper...

[Fred2FR3]

De toutes les manières employées, il faudra un jour ou l'autre faire une maj Majeure pour le client => $$. La méthode d'indexation est vétuste et pose problème pour le futur, pour moi c'est certain.
Il faut rassuré le client, par des tests => tu reprod le site a ta façon en local ou en ligne et tu montres la puissance de J! + indexation revue.
Faire du neuf avec du vieux, ca ne tiendra pas ... On est pas sur une série automobile ou on revisite les années 2000-2010 voir antérieure. Les outils puissants hier ne le sont peut être plus d'une part, et d'autre leur pérennité a été discuté ici même.