Automatisation des rapports techniques pour le référencement
Au fur et à mesure que le Web devient plus complexe, avec le framework JavaScript et les frontaux de bibliothèque sur les sites Web, les applications Web progressives, les applications d’une seule page, JSON-LD, etc., nous constatons de plus en plus une surface de plus en plus grande pour que les choses tournent mal . Lorsque tout ce que vous avez est HTML et CSS et des liens, vous ne pouvez pas tout gâcher. Cependant, dans le monde actuel des sites Web générés dynamiquement avec des interfaces JS universelles, il y a beaucoup de place pour que des erreurs se glissent.
Le deuxième problème auquel nous sommes confrontés avec une grande partie de cela est qu’il est difficile de savoir quand quelque chose ne va pas, ou quand Google a changé la façon dont ils gèrent quelque chose. Cela n’est aggravé que lorsque vous tenez compte de situations telles que les migrations ou les refontes de sites, où vous pouvez soudainement archiver beaucoup d’anciens contenus ou remapper une structure d’URL. Comment relever alors ces défis ?
L’ancienne manière
Historiquement, la façon dont vous analysiez des choses comme celle-ci consistait à consulter vos fichiers journaux à l’aide d’Excel ou, si vous êtes inconditionnel, de Log Parser. C’est super, mais ils vous obligent à connaître vous avez un problème, ou que vous cherchez et que vous obtenez une section de journaux contenant les problèmes que vous devez résoudre. Ce n’est pas impossible, et nous avons beaucoup écrit à ce sujet dans notre blog et dans notre guide d’analyse des fichiers journaux.
Le problème avec cela, cependant, est assez évident. Cela exige que vous regardiez, plutôt que de vous faire prendre conscience qu’il y a quelque chose à rechercher. Dans cet esprit, j’ai pensé passer un peu de temps à chercher s’il y avait quelque chose qui pourrait être fait pour que l’ensemble du processus prenne moins de temps et agisse comme un système d’alerte précoce.
Un coup de main
La première chose que nous devons faire est de configurer notre serveur pour qu’il envoie les fichiers journaux quelque part. Ma solution standard à cela est devenue l’utilisation de la rotation des journaux. Selon votre serveur, vous utiliserez différentes méthodes pour y parvenir, mais sur Nginx, cela ressemble à ceci :
# time_iso8601 looks like this: 2016-08-10T14:53:00+01:00 if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})") { set $year $1; set $month $2; set $day $3; } <span class="redactor-invisible-space"> </span>access_log /var/log/nginx/$year-$month-$day-access.log; Cela vous permet d’afficher les journaux pour une date spécifique ou un ensemble de dates en extrayant simplement les données des fichiers relatifs à cette période. Après avoir configuré la rotation des journaux, nous pouvons ensuite configurer un script, que nous exécuterons à minuit à l’aide de Cron, pour extraire le fichier journal relatif aux données d’hier et l’analyser. Si vous le souhaitez, vous pouvez regarder plusieurs fois par jour, ou une fois par semaine, ou à n’importe quel intervalle qui convient le mieux à votre niveau de volume de données.
La question suivante est : Que voudrions-nous rechercher ? Eh bien, une fois que nous avons les journaux de la journée, voici ce sur quoi mon système doit faire rapport :
30* codes d’état
Générez une liste de toutes les pages visitées par les utilisateurs qui ont entraîné une redirection. Si la page qui renvoie à cette ressource se trouve sur votre site, redirigez-la vers le point de terminaison réel. Sinon, contactez la personne qui vous relie et demandez-lui de trier le lien vers l’endroit où il doit aller.
404 codes d’état
Histoire similaire. Toutes les ressources 404ing doivent être vérifiées pour s’assurer qu’elles sont supposées être manquantes. Tout ce qui devrait s’y trouver peut faire l’objet d’une enquête pour savoir pourquoi il ne se résout pas, et les liens vers tout ce qui manque réellement peuvent être traités de la même manière qu’un code 301/302.
50* codes d’état
Quelque chose de grave s’est produit et vous n’allez pas passer une bonne journée si vous voyez de nombreux codes 50*. Votre serveur meurt sur les demandes de ressources spécifiques, ou peut-être sur l’ensemble de votre site, en fonction de la gravité de la situation.
Budget d’exploration
Une liste de toutes les ressources explorées par Google, le nombre de fois qu’elles ont été demandées, le nombre d’octets transférés et le temps nécessaire pour résoudre ces demandes. Comparez cela avec votre plan de site pour trouver les pages que Google n’explorera pas, ou qu’il martèle, et corrigez-les si nécessaire.
Ressources les plus/moins demandées
Semblable à ce qui précède, mais détaillant les éléments les plus et les moins demandés par les moteurs de recherche.
Mauvais acteurs
De nombreux robots à la recherche de vulnérabilités adresseront des requêtes à des éléments tels que wp_admin, wp_login, 404s, config.php et d’autres URL de ressources communes similaires. Toute adresse IP qui fait des demandes répétées à ces types d’URL peut être ajoutée automatiquement à une liste noire d’adresses IP.
Création de rapports sur les URL avec correspondance de modèle
Il est simple d’utiliser regex pour faire correspondre les URL demandées avec des modèles prédéfinis, pour signaler des zones spécifiques de votre site ou des types de pages. Par exemple, vous pouvez signaler les demandes d’image, les appels de fichiers Javascript, la pagination, les soumissions de formulaires (via la recherche de demandes POST), les fragments échappés, les paramètres de requête ou pratiquement n’importe quoi d’autre. À condition qu’il se trouve dans une URL ou une requête HTTP, vous pouvez le configurer en tant que segment sur lequel faire l’objet d’un rapport.
Comportement d’exploration de recherche pointu
Enregistrez le nombre de requêtes effectuées par Googlebot chaque jour. S’il augmente de plus de x%, c’est quelque chose d’intéressant. En passant, avec la plupart des séries de nombres, un calcul pour repérer les valeurs aberrantes extrêmes n’est pas difficile à créer et vaut probablement votre temps.
Sortie de données
En fonction de l’importance d’une section particulière, vous pouvez ensuite configurer les données pour qu’elles soient enregistrées de plusieurs manières. Premièrement, de grandes quantités de codes de statut 40 * et 50 * ou de demandes d’acteurs malveillants mériteraient de déclencher un e-mail. Cela peut vous faire savoir rapidement si quelque chose se passe qui indique potentiellement un problème important. Vous pouvez alors maîtriser tout ce qui peut être et le résoudre en priorité.
L’ensemble des données peut également être paramétré pour faire l’objet d’un reporting via un tableau de bord. Si vous n’avez pas autant de données dans vos journaux quotidiennement, vous pouvez simplement interroger les fichiers au moment de l’exécution et générer le rapport à chaque fois que vous le visualisez. D’un autre côté, les sites avec beaucoup de trafic et donc des fichiers journaux plus volumineux peuvent souhaiter mettre en cache la sortie de chaque jour dans un fichier séparé, afin que les données n’aient pas à être calculées. Évidemment, le type d’approche que vous utilisez pour faire cela dépend beaucoup de l’échelle à laquelle vous allez opérer et de la puissance de votre matériel serveur.
Conclusion
Grâce aux journaux de serveur et aux scripts de base, il n’y a aucune raison pour que vous ayez une situation où quelque chose ne va pas sur votre site et que vous ne le sachiez pas. Les notifications proactives de problèmes techniques sont une chose nécessaire dans un monde où Google explore à un rythme de plus en plus rapide, ce qui signifie qu’ils pourraient commencer à réduire votre classement en raison de temps d’arrêt du site ou d’erreurs en quelques heures.
Mettez en place une surveillance adéquate et assurez-vous de ne pas être pris de court !
