L'état HTTP et les codes d'erreur sont comme un court message du serveur qui apparaît en haut d'une page Web. Cela ne fait en fait pas partie de la page Web. Ce message, renvoyé lorsque le serveur est contacté, vous permet de savoir comment les choses se sont passées lorsque le serveur a reçu une demande de visualisation de la page.
Ces messages sont renvoyés chaque fois que le navigateur interagit avec le serveur, même si vous ne les voyez pas. Les codes d'état HTTP sont un outil inestimable pour diagnostiquer et corriger les erreurs survenues dans la configuration d'un site.
Cet article présente les codes d'état et les codes d'erreur les plus courants.
D'où viennent-ils?
Chaque fois que vous cliquez sur un lien ou entrez une URL et cliquez sur " Entrer”, le navigateur envoie une requête au serveur. Il reçoit et traite la demande, puis renvoie les ressources demandées avec l'en-tête HTTP.
Les codes d'état sont transmis au navigateur dans un en-tête HTTP. Même si vous ne pouvez pas les voir. Mais quand quelque chose ne va pas, l'utilisateur voit un code d'état dans le navigateur. C'est la façon dont le serveur dit : Quelque chose ne va pas. Voici le code qui explique exactement ce que».
Code d'état HTTPGoogle 404
Pour voir les codes d'état que le navigateur n'affiche pas normalement, vous aurez besoin d'outils spéciaux. Les navigateurs populaires tels que Chrome et Firefox ont leurs propres extensions disponibles. Il existe également de nombreux services pour afficher les en-têtes, tels que Web Sniffer.
Pour afficher le code d'état HTTP à l'aide de l'un de ces outils, recherchez la ligne en haut du rapport qui indique "État : HTTP/1.1". Il est suivi du code d'état renvoyé par le serveur.
Classes de code d'état HTTP
Les codes d'état HTTP sont divisés en 5 classes :
- 100 : Codes d'information indiquant qu'une requête initiée par le navigateur est en cours.
- 200 : codes de demande réussie. Renvoyé lorsqu'une demande de navigateur a été reçue, reconnue et traitée avec succès par le serveur.
- 300 : les codes de redirection sont renvoyés lorsque la ressource demandée a été remplacée par une nouvelle.
- 400 : erreurs http qui se produisent côté client et indiquent qu'il y a un problème avec la requête.
- 500 : Codes d'erreur du serveur indiquant que la demande a été acceptée, mais une erreur sur le serveur l'a empêchée de se terminer.
Liste des codes d'état HTTP
Il existe plus de 40 codes d'état de serveur différents. Mais ceux que vous rencontrerez régulièrement sont moins d'une douzaine. Voici une liste de codes d'état HTTP :
Code d'état 200
200 : "Tout va bien." Il s'agit du code renvoyé lorsqu'une page Web ou une ressource agit exactement comme prévu.
Codes d'état 300
301 : " La ressource demandée a été définitivement déplacée". Ce code est renvoyé lorsqu'une page Web ou une ressource est remplacée par une autre ressource. Il est utilisé pour rediriger en permanence les URL.
302 : Il s'agit d'une erreur http" La ressource demandée a été déplacée mais a été trouvée". Ce code est utilisé pour indiquer que la ressource demandée a été trouvée, mais pas à l'endroit où elle était attendue. Il est utilisé pour rediriger temporairement les URL.
304 : " La ressource demandée n'a pas été modifiée depuis son dernier accès". Indique que les ressources stockées dans le cache du navigateur n'ont pas changé. Il est utilisé pour accélérer la livraison des pages Web en réutilisant les ressources précédemment téléchargées.
Codes d'état 400
erreur http 403 : " L'accès à cette ressource est refusé". Renvoyé lorsque l'utilisateur essaie d'ouvrir une ressource pour laquelle il n'a pas de droits d'accès. Par exemple, une tentative par un utilisateur non autorisé d'afficher un contenu protégé par mot de passe peut entraîner une erreur 403.
404 : " La ressource demandée n'a pas été trouvée". Le message d'erreur le plus courant. Indique que la ressource demandée n'existe pas et que le serveur ne sait pas si elle a déjà existé.
405 : " Méthode Non Autorisée". Levée lorsque le serveur d'hébergement (serveur source) prend en charge la méthode reçue, mais qu'il n'y a pas de ressource cible.
406 : " Réponse inacceptable". La ressource demandée est uniquement capable de générer un contenu qui n'est pas acceptable selon les en-têtes Accept envoyés dans la requête.
408 : " Le serveur a expiré en attendant que le reste de la demande du navigateur arrive". Levé lorsque le serveur abandonne le traitement après l'expiration d'une requête complète du navigateur. En d'autres termes, le serveur n'a pas reçu remplir la demande, envoyé par le navigateur. Un des causes possibles il peut y avoir une congestion du réseau entraînant une perte de paquets entre le navigateur et le serveur.
410 : " La ressource demandée est manquante et ne sera pas retournée". Similaire au code 404 "Not Found", sauf que le code d'état 410 indique que statut donné attendue de façon continue.
429 : Il s'agit d'une erreur http" Trop de demandes". Généré par le serveur lorsque l'utilisateur a envoyé trop de requêtes dans le temps imparti ( Limitation de vitesse). Parfois, la cause de l'erreur peut être des robots essayant d'accéder au site. Dans ce cas, vous devrez peut-être modifier l'URL de connexion au panneau d'administration WordPress.
429 trop de demandes
499 : " Le client a clôturé la demande". Renvoyé par NGINX lorsque le client ferme la demande alors que NGINX est toujours en train de la traiter.
Codes d'état500
500 : "N et le serveur a rencontré une erreur et la requête n'a pas pu être complétée". Code http générique, également appelé " Erreur interne du serveur". Quelque chose s'est mal passé sur le serveur et la ressource demandée n'a pas été livrée. Ce code est généré par des plugins tiers lorsque le code PHP ou la connexion à la base de données échoue.
Erreur de connexion à la base de données
501 : "Non implémenté." Cette erreur indique que le serveur ne prend pas en charge les fonctionnalités requises pour traiter la demande. L'erreur est presque toujours liée au serveur lui-même, et pour la résoudre, vous devez contacter le support du fournisseur d'hébergement.
La page 404 a pour but d'informer l'utilisateur que l'url (adresse de la page) qu'il a indiquée n'existe pas.
Ces URL incorrectes peuvent également être appelées "liens brisés".
De nombreux sites créent leurs pages 404 pour la commodité de leurs utilisateurs. Il fait souvent beau et pages intéressantes, ce qui fait sourire l'utilisateur au lieu d'être frustré que l'adresse de la page soit incorrecte.
Lors de la création d'une page 404, il existe un élément technique important qui affecte grandement le classement des sites dans moteurs de recherche si tout n'est pas configuré correctement.
Si vous êtes intrigué par la création de la page 404, alors vous devez considérer trois points :
1) Redirigez toutes les URL incorrectement saisies vers la page 404 dans .htaccess.
2) Corrigez la réponse du serveur après la redirection (le code http de la page doit être 404 et non 200).
3) Fermeture de la page 404 de l'indexation dans robots.txt
Je note tout de suite que tout ce qui précède est écrit pour des sites auto-écrits, principalement en php. Pour wordpress, il existe des plugins pour personnaliser le même. Mais dans cet article, nous verrons à quoi tout ressemble dans la réalité. %)
Redirection (redirection) des URL incorrectes vers une page 404
La première chose que vous faites est de créer la page 404 elle-même afin qu'il y ait où envoyer les gens%%.L'URL de redirection est configurée dans le fichier .htaccess
Entrez simplement la ligne :
ErreurDocument 404 http://monsite.com/404.php
Où "monsite.com" est votre domaine et http://monsite.com/404.php est le chemin vers la page réelle. Si votre site est en html, alors la ligne ressemblera à :
ErreurDocument 404 http://monsite.com/404.html
La vérification est très simple. Après avoir uploadé le fichier .htaccess avec la ligne ci-dessus sur l'hébergeur, faites une vérification en saisissant une URL volontairement inexistante (lien brisé), par exemple : http://monsite.com/$%$%
Si la redirection vers la page que vous avez créée s'est produite, alors tout fonctionne.
Ainsi, le fichier .htaccess complet, où UNIQUEMENT la redirection vers 404 est configurée, ressemblera à ceci :
____________________________
Moteur de réécriture activé
ErreurDocument 404 http://monsite.com/404.html
____________________________
Réponse correcte du serveur (code http de la page)
Il est très important que lors de la redirection, il y ait une réponse correcte du serveur, à savoir 404 pas trouvé.Cela doit être expliqué séparément.
Toute url sur demande se voit attribuer un statut (code http de la page).
Pour toutes les pages existantes, c'est : HTTP/1.1 200 OK
Pour les pages redirigées : HTTP/1.1 302 Trouvé
Si la page n'existe pas, elle doit être HTTP/1.1 404 Not Found
Autrement dit, quelle que soit l'URL saisie, un statut lui est attribué, un certain code de réponse du serveur.
Vous pouvez vérifier la réponse du serveur sur une ressource telle que bertal.ru ou SEARCH CONCOLE GOOGLE - Scan / View as a GOOGLE bot.
Lorsque vous n'aviez pas de redirection .htaccess vers une page 404, alors toute url inexistante saisie par l'utilisateur, ainsi que les liens brisés, recevaient la réponse "HTTP/1.1 404 Not Found" 
Après avoir mis en place une redirection vers la page 404 de votre auteur via .htaccess, comme décrit ci-dessus, puis en saisissant un lien brisé (url invalide qui n'existe évidemment pas), comme http://monsite.com/$%$% , le la réponse du serveur :
- premier HTTP/1.1 302 Found (redirection),
- suivi de HTTP/1.1 200 OK (la page existe). 
Vérifiez sur bertal.ru.
Que menace-t-il ? Cela signifie que Google pourra entrer tous les liens brisés dans sa base de données (index) comme des pages existantes avec le contenu de la page 404. En fait, des pages en double. Et cela est incroyablement nocif pour l'optimisation des moteurs de recherche.
Dans ce cas, vous devez faire deux choses :
1) Configurez la réponse correcte du serveur sur la page 404.
2) Fermez la page 404 de l'indexation. Cela se fait via le fichier robots.txt
Configurer la réponse du serveur HTTP/1.1 404 Not Found pour les pages inexistantes
La réponse du serveur est paramétrable grâce à fonctions php tout en haut de la page :Écrivez-le au début du fichier 404.
En conséquence, nous devrions obtenir une réponse à un lien brisé :
Fermer la page 404 de l'indexation
Vous pouvez fermer la page de l'indexation dans le fichier rodots.txt. Soyez prudent avec cet outil, car à travers ce fichier votre site, en effet, communique avec les robots de recherche !Le texte intégral du fichier rodots.txt, où l'indexation 404 pages est UNIQUEMENT fermée, ressemble à ceci :
____________________________
Agent utilisateur: *
Refuser:
Interdire : /404.php
____________________________
Notes de code : "/404.php" signifie le chemin d'accès à la page. Si sur votre site la page 404.php (ou 404.html, respectivement) se trouve dans un dossier, alors le chemin ressemblera à :
/titulaire/404.php
où "titulaire" est le nom du dossier.
En fait, il s'agit de la page 404. Vérifiez le fonctionnement de la page, les redirections de liens brisés et les réponses du serveur.
Je le répète : tout ce qui précède concerne les sites auto-écrits. Si vous utilisez wordpress, vous pouvez rechercher un plugin d'erreur 404 décent.
Impossible sans connaître les réponses du serveur.
Exemple:
404 Non trouvé
Les actions ultérieures dépendent exactement du code de réponse fourni par le serveur ou la page. Étant donné que l'ensemble de codes est standard pour tous les sites / pages / serveurs, les actions lors de l'émission d'un code particulier seront également standard.
A ce jour, 5 grandes classes de code réponse ont été identifiées :
1xx : Informationnel (rus. Informationnel) - la demande a été correctement perçue, mais son traitement n'a pas été terminé.
2xx : Succès (rus. Avec succès) - la demande a été correctement reçue et traitée avec succès.
3xx : Redirection (redirection russe) - redirige les codes vers d'autres pages.
4xx : Erreur client (rus. Erreur client) - une erreur côté client.
5xx : Erreur de serveur (rus. Erreur de serveur) - une erreur côté serveur.
Examinons maintenant certains des codes de statut IANA un par un.
Réponse du serveur 1XX
100 Continuer Code serveur
100 Continuer indique que la connexion avec le serveur a déjà été établie, que le serveur a accepté la demande correcte et que des données sont en cours d'échange entre le serveur et le client. Ce code est temporaire, c'est-à-dire il est toujours suivi d'un autre. Le code 100 est interne et ne s'applique pas aux erreurs. Celles. "La porte est ouverte, lisez ce dont vous avez besoin, quand vous avez terminé, fermez-la." Le code 100 peut ne pas être généré si l'utilisateur a déjà reçu une partie des données du serveur.
101 protocoles de commutation
Ce code n'est pas faux non plus. Généré lors du passage d'un protocole à un autre. Par exemple, lors d'une demande de changement de ancienne version HTTP vers un plus récent.
C'est l'un des codes de serveur les plus simples. Cela signifie qu'une demande a été faite par l'utilisateur pour changer le type de protocole utilisé sur le serveur Web, et que le serveur a donné son accord.
102 Traitement
En un sens, il s'agit d'un analogue du code 100. Il est généré lorsque le traitement d'une demande peut prendre beaucoup de temps. À ces fins, le temporisateur d'attente est réinitialisé et l'attente d'autres commandes se produit comme d'habitude. Ce n'est pas non plus un code d'erreur.
Réponse du serveur 200 OK
Occupe à juste titre la toute première place en importance et en popularité, car. le serveur le donne en cas de traitement réussi et correct de la demande de l'utilisateur.
Réponse du serveur 301
C'est aussi l'un des codes de réponse courants. Il vous indique que la page demandée est adresse donnée n'est plus disponible puis redirigé vers une autre adresse. La redirection 301 peut être utilisée, par exemple, lorsqu'un site "déplace" de Protocole HTTP sur HTTPS (cela est généralement implémenté via le fichier .htaccess disponible sur les serveurs Apache).
Réponse du serveur 302
Ce code signale que l'emplacement de la page demandée a été temporairement modifié. Des informations sur le nouvel emplacement du document demandé doivent également être fournies. Ce code était à l'origine utilisé comme méthode de redirection principale.
Réponse du serveur 404
C'est quelque chose, et seuls ceux qui n'étaient pas encore nés et ceux qui sont morts avant la création d'Internet n'ont pas vu l'erreur de réponse du serveur 404. Ce code indique que le document demandé n'est pas disponible sur le site pour une raison quelconque. Le code d'erreur de réponse du serveur 404 ne doit être renvoyé que s'il n'y a jamais eu de document à l'adresse spécifiée par l'utilisateur. Si le document était auparavant disponible à cette adresse, puis qu'il a été supprimé du site, alors le serveur doit renvoyer le code 410, et non 404.
Faux 404 pages
La plupart des webmasters ne prêtent aucune attention aux pages 404, cependant, cela peut sérieusement nuire au classement du site. Paradoxalement, une page avec un message 404 File Not Found ne renvoie pas toujours un code 404. Ces pages sont généralement appelées "Soft 404". Les raisons de l'occurrence sont simples - pour une raison quelconque, la page renvoie un code autre que 404 et 410 - par exemple, 200. C'est tout à fait possible si la page a déjà été créée, mais qu'il n'y a pas encore de contenu dessus.
Réponse du serveur 500
Tous les codes de la série 5xx indiquent que le serveur n'est pas en mesure de terminer le traitement de la demande. Avec le code, un indice explicatif (avec la raison) en anglais devrait également apparaître.
500 Erreur de serveur interne
Le code 500 est renvoyé en cas d'erreur interne du serveur, à l'exception des autres erreurs de classe 5xx. Une telle erreur peut être retournée lorsque le lien est généré sur le serveur directement au moment de la requête. L'exemple le plus simple- recherche interne du site : il n'y a pas de document physique sur le lien demandé.
Réponse du serveur 502
Le code 502 peut s'afficher dans les cas où le serveur joue le rôle d'une passerelle ou d'un proxy, mais il n'a pas été possible de "trouver un langage commun" entre lui et le serveur en amont, c'est-à-dire qu'il s'agit en fait d'une simple erreur d'échange de données .
Réponse du serveur 550
Lorsque l'erreur 550 se produit, il est nécessaire de vérifier à quel point les enregistrements MX sont correctement orthographiés afin d'éliminer ces erreurs de réponse du serveur.
La sortie sera un tableau.
Vous devez vous assurer qu'il contient les entrées nécessaires pour que votre messagerie fonctionne :
IMPORTANT! Le mélange d'enregistrements MX n'est pas autorisé, c'est-à-dire dans le tableau sur le problème, il ne devrait y avoir que les enregistrements MX qui sont spécifiquement nécessaires pour votre courrier. Si nécessaire, vous devez corriger les entrées, corriger les erreurs et / ou supprimer celles qui ne sont pas nécessaires.
Comment obtenir les codes de réponse du serveur (pages) via Yandex
Étape 1. Vérifiez le code de réponse du serveur sur la page du site qui devrait figurer dans la recherche.
Nous ouvrons toute page de votre site située dans Résultats de recherche Yandex, puis copiez son URL depuis la barre d'adresse.
Passons maintenant au service Yandex (http://webmaster.yandex.ru/server-response.xml), avec lequel vous pouvez regarder le site à travers les yeux d'un robot et vérifier la vitesse de réponse du serveur dans le panneau Yandex.
Collez simplement l'adresse URL de la page qui nous intéresse dans le champ de texte et cliquez sur le bouton "Vérifier". Dans ce cas, nous avons reçu un code 200 OK, indiquant que la page fonctionne normalement.
Étape 2. Vérifiez la réponse du serveur à une page qui n'existe pas.
Dans le même service, entrez le nom_domaine / some_crocozybra
Dans ce cas, nous avons reçu une réponse 301 Moved Permanently. Cela indique que l'adresse de la page est incorrecte et redirige vers la bonne adresse.
Sinon, comment connaître les codes de réponse du serveur (site) ?
Alternativement, vous pouvez percer le code de réponse en utilisant le service http://mainspy.ru. Cela fonctionne de la même manière que le service Yandex : collez l'URL qui vous intéresse et cliquez sur "Vérifier". Le code de réponse dans ce cas est dans la toute première ligne :
Bertal, contrairement à Mainspy, vous permet de regarder la page non seulement à travers les yeux d'un bot Yandex, mais aussi à travers les yeux de robots de recherche Bing et Google, et en prime, il peut imiter navigateurs populaires. Pour plus de commodité, regardons les mêmes pages à travers les yeux de GoogleBot. Dans ce cas, le code de réponse est surligné en vert.
Vérification en masse des réponses du serveur (site) en ligne
La vérification en masse des codes de réponse peut être utile pour trouver des sites cassés où des liens ont été achetés (par le biais d'échanges ou directement - cela n'a pas d'importance).
Dimax.biz - http://backlinks-checker.dimax.biz/tools/proverka_answer_servera.php est l'un des meilleurs vérificateurs. Le seul point négatif est qu'en mode gratuit, vous ne pouvez pas faire plus de 2 demandes de 50 liens chacune. Pour les volumes plus "sérieux", vous devrez utiliser le tarif PRO payant. En sortie, nous obtenons une liste triée par code de réponse. Dans ce cas, le tri n'est pas nécessaire, car il n'y a que 2 adresses dans la liste, et les deux donnent le code 200.
Urlitor est un autre service pour contrôle de masse codes de réponse. Le service est bon car les résultats du contrôle sont résumés dans un tableau pour une meilleure perception. D'ailleurs, les liens dans le tableau sont cliquables.
Comment vérifier la rapidité (délai) de la réponse du serveur du site ?
Combien de ces services ont déjà divorcé - ne comptent pas. Considérons certains d'entre eux.
Il s'agit d'un outil en anglais qui analyse la vitesse à tous égards. Avec lui, vous pouvez connaître la vitesse en secondes, le poids de la page testée, ainsi qu'obtenir une estimation et des recommandations pour l'améliorer. Avantage ce service en ce que chaque élément individuel est analysé. Une telle analyse vous permet de savoir exactement ce qui ralentit le chargement d'une seule page et/ou du site dans son ensemble.
Qui se charge plus rapidement
La principale caractéristique de ce service est qu'il analyse le temps de chargement de deux ressources en même temps. Cela vous permet de savoir laquelle des deux ressources s'exécute le plus rapidement. Le seul inconvénient est différentes connexions et en différents navigateurs le résultat peut différer.
Aperçus de Google PageSpeed
Google PageSpeed Insights est également l'un des outils les plus puissants pour mesurer les performances des mobiles et des ordinateurs de bureau. L'évaluation se fait sur une échelle de 100 points. 85 points ou plus est un bon indicateur. De plus, en prime, il donne des recommandations d'amélioration.
Réponse longue du serveur
Une réponse qui dure plus d'une demi-seconde est appelée une réponse « longue ». Par conséquent, lorsque le site se charge pendant une longue période, vous pouvez voir un message dans le navigateur "expiré en attente d'une réponse du serveur". Il peut y avoir beaucoup de raisons pour une réponse longue :
Logique complexe de fourniture de données
Le serveur n'a pas le temps de traiter les demandes entrantes en temps opportun en raison de leur grand nombre
Les requêtes elles-mêmes (soit complexes, soit non optimisées, soit les deux)
Demandes à un grand nombre de ressources externes
Grand nombre de fichiers exécutables
Le serveur Web lui-même prend beaucoup de temps pour traiter la demande.
Les endroits les plus "douloureux" des performances du serveur :
Serveur Web utilisé (Apache, IIS).
Un certain nombre de serveurs Web, même lorsqu'ils servent des fichiers statiques, peuvent créer des retards, car. ils ne sont pas conçus au niveau architectural pour traiter un grand nombre de requêtes, et à cause de cela, il peut y avoir un message indiquant que le temps de réponse du serveur a été dépassé. Par conséquent, pour fonctionnement normal serveur Web, il est logique d'utiliser nginx (de plus, en conjonction avec Apache, php-fpm, ainsi que d'autres serveurs d'applications pour le traitement des calculs de serveur).
Utilisation d'OpCache.
Réduisez le temps de réponse du serveur en mettant en cache le code exécutable (scripts de site Web) - cela vous permet d'utiliser un résultat prêt à l'emploi au lieu de traduire à chaque fois les instructions PHP en code binaire. Mais cette mise en cache n'a rien à voir avec la mise en cache des résultats de l'exécution de scripts PHP.
Requêtes de base de données.
La deuxième étape des performances du serveur consiste à configurer des tables (index) dans la base de données et à les structurer pour faciliter le traitement des requêtes. Cela inclut également le recalcul des intermédiaires et la mise en cache des résultats les plus fréquemment utilisés dans des tables séparées. Cela réduira de plusieurs fois la consommation des ressources du serveur et contribuera à réduire le temps de réponse du serveur.
Logique complexe de traitement des données.
La troisième étape consiste à simplifier la logique du serveur. Essentiellement, il s'agit simplement d'éliminer les opérations inutiles et de profiler le temps d'exécution des scripts côté serveur.
Accès à des services tiers.
Les requêtes à des services tiers écrites dans le code des scripts de serveur sont une "histoire commune" qui peut apporter de nombreuses surprises, car les performances des services auxquels les données sont demandées ne sont presque jamais vérifiées par qui que ce soit. Mais le temps de réponse d'un service tiers affecte directement le temps de réponse du serveur. Par conséquent, il est préférable d'utiliser uniquement des sources internes dans les requêtes du serveur, dont la qualité des performances peut être surveillée à tout moment, ou en mode attente, demander des données sur le client.
Pourquoi la vitesse de réponse du serveur Web affecte la promotion.
Premièrement, parce que la vitesse de téléchargement est l'un des facteurs de classement (mais pas décisif). Google déclare ouvertement que moins de 1% des sites se classent pour la vitesse de la page. MAIS…
Deuxièmement, si la page prend trop de temps à se charger, l'utilisateur la fermera simplement. Ce comportement de l'utilisateur est communément appelé "refus". Soit dit en passant, les rebonds ont un impact direct sur les positions dans les résultats de recherche. Plus la vitesse de téléchargement est élevée, plus le taux de rebond est faible et, par conséquent, plus la position est élevée.
Expiration du délai d'attente d'une réponse du serveur.
Pour commencer, il est important de comprendre la cause de l'échec. Celles. l'utilisateur entre l'adresse, et le navigateur envoie à ce moment un groupe de requêtes, et inclut également un chronomètre inversé pour chacune d'elles. Si, après un délai spécifié, le navigateur ne reçoit pas de réponse à sa demande, l'utilisateur verra alors une image aussi désagréable.
Il y a plusieurs raisons principales d'échec :
- Il est impossible de se connecter au site en raison du fonctionnement instable de ses serveurs ;
- Paramètres de navigateur cassés ou son encombrement ;
Problèmes de connexion Internet de la part de l'utilisateur ;
La ressource est bloquée.
Que faire pour résoudre ?
Si l'échec est unique, rechargez la page à l'aide de la combinaison Ctrl + F5. Vous devrez peut-être recharger la page plusieurs fois. Si cela ne vous aide pas, vérifiez votre connexion Internet.
Paramètres réseau.
1. Certains sites sont parfois "coquins". Pour l'IP dynamique, la solution sera simple - redémarrez le routeur en coupant l'alimentation.
2. Une connexion lente provoque parfois une erreur ERR_CONNECTION_TIMED_OUT. La vitesse d'Internet peut être vérifiée via Yandex-internetometer. Si la vitesse est trop faible, vous devez contacter votre fournisseur d'accès Internet.
3. Vous devez vérifier les "Propriétés du réseau" pour les adresses DNS étrangères. S'il existe de telles adresses, supprimez-les (après les avoir réécrites quelque part au cas où) et vérifiez la présence de virus dans le système à l'aide du logiciel antivirus installé sur le PC - NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web, etc. Il est préférable d'utiliser des Live-loaders à ces fins.
4. Vérifiez les paramètres du routeur lui-même. Le paramètre MTU est le plus souvent perdu. Il est impossible de donner des recommandations universelles pour la configuration d'un routeur, car. cela dépend directement du modèle du routeur et du fournisseur d'accès Internet. Habituellement, le MTU est 1500, 1460, 1476.
Quel devrait être le temps de réponse du serveur ?
Et voici les numéros spécifiques :
Les pages qui se chargent complètement en 1,8 et 2,7 secondes pour les pages Web et de bureau ont les taux de conversion les plus élevés. version mobile respectivement
Le taux de rebond le plus bas pour les pages qui se chargent complètement en 1 et 0,7 secondes pour les versions de bureau et mobiles, respectivement
Ces chiffres sont tirés d'une étude d'Akamai Technologies.
Donc, vous avez vérifié le site pour la vitesse de chargement. Mais comment réagir aux résultats ?
<1 секунды - идеал
1-2 secondes - presque idéal
3-5 secondes - tolérablement, mais il est logique de terminer
5-10 secondes - mauvais, vous devez le terminer de toute urgence
≥10 secondes - très mauvais, vous devez le terminer de toute URGENCE
Cependant, il ne faut pas oublier une règle ultra-importante - la vitesse de téléchargement doit être supérieure à celle des concurrents. Les recherches du New York Times ont prouvé qu'une différence de 0,25 seconde peut suffire pour que les visiteurs préfèrent un site plus rapide. Et vous n'aurez pas le temps de cligner des yeux (au sens le plus littéral), car l'utilisateur vous quittera pour un concurrent.
Réduction de la réponse du serveur
Optimisation graphique.
Nous avons dit précédemment que certains vérificateurs fournissent également des recommandations d'optimisation. Parmi eux, vous pouvez trouver les adresses des images qui peuvent être optimisées en les réduisant.
Utiliser le cache du navigateur.
Le navigateur téléchargera les images dans son cache. Par conséquent, le retéléchargement des images à partir du serveur ne sera plus nécessaire, ce qui économisera beaucoup de temps de téléchargement.
Activer la compression.
Pertinent si gzip est utilisé. En conséquence, la quantité de données est réduite d'un facteur 4 voire 5. Plus la quantité de données transmises est faible, moins il faut de temps pour les transférer.
Réduire le temps de réponse du serveur.
À l'aide du service Pingdom, vous pouvez calculer le temps nécessaire au serveur pour renvoyer le code de réponse. Le temps idéal n'est pas supérieur à 0,2 seconde.
Ces instructions aideront à accélérer considérablement le site. Cependant, il existe un risque de nuire à la fonctionnalité ou à l'apparence. Par conséquent, avant chaque action, il est obligatoire de faire des sauvegardes des fichiers sources. Cela ne fait pas de mal non plus de consulter des spécialistes techniques.
Nous avons publié un nouveau livre, "Social Media Content Marketing : Comment entrer dans la tête des abonnés et les faire tomber amoureux de votre marque".
Le code de réponse 200 est l'un des types de codes HTTP qui informe l'utilisateur que la demande a été traitée avec succès. En fonction de l'état, le serveur peut fournir le corps et l'en-tête du message.
Plus de vidéos sur notre chaîne - apprenez le marketing internet avec SEMANTICA
Prenons un exemple. Vous avez envoyé un colis dans une autre ville. La poste vous a donné un numéro de suivi. Sur celui-ci, vous voyez ce qui se passe avec votre envoi - ici il a quitté le centre de tri de votre ville, ici il est arrivé dans un autre. Ici, il a été remis au destinataire. A chaque fois le système vous donne un statut en réponse à une demande.
Comment ça fonctionne
Pour commencer, jetons un coup d'œil. Ainsi, l'utilisateur ouvre un navigateur et fait une demande à une ressource Internet. Après cela, le navigateur reçoit une réponse de l'hôte, où le code à trois chiffres est indiqué. Par une combinaison de nombres, vous pouvez déterminer quelle situation est actuellement observée sur l'hôte.
HTTP est un protocole spécial pour l'échange de données entre différents (le navigateur de l'utilisateur et le serveur Web sur lequel se trouve le site lui-même). C'est-à-dire que le navigateur envoie une requête au serveur qui l'intéresse, il peut s'agir d'une action ou d'un document, puis reçoit une réponse. Si la réponse à la requête est positive, le code de réponse du serveur 200 s'affiche et le téléchargement du fichier commence. Si négatif, c'est-à-dire que la page demandée n'a pas été trouvée ou qu'il y a des problèmes dans le service, un message d'erreur s'affiche.
Que signifie le code 200 pour la bonne indexation du site
La catégorie de réponse du serveur 2xx est la catégorie "Succès". Cette catégorie informe les utilisateurs d'un résultat positif. En particulier, le code « 200 OK » indique à l'utilisateur que sa requête a abouti. Par exemple, le client a demandé certaines données. La réponse du serveur 200 signifie que ces données sont affichées dans l'en-tête ou le message.
Aujourd'hui, tous les moteurs de recherche indexent des ressources et des liens qui fournissent aux requêtes un code de réponse de 200. Le moteur de recherche comprend cela de la manière suivante : la page existe réellement, ce qui signifie qu'elle peut être incluse dans la base de données de l'index. Si vous souhaitez que le moteur de recherche indexe telle ou telle page, assurez-vous qu'il émette un code de réponse 200.
Il est important de vérifier si des pages inexistantes renvoient un code 200. Cela est possible même lorsque vous voyez visuellement « 404 - page introuvable » à l'écran. La cause de ce problème peut être une mauvaise configuration du site. Si vous ne voulez pas de problèmes avec la promotion de votre ressource, vérifiez tous les types de pages pour la réponse correcte du serveur. De cette façon, vous pouvez identifier les pages qui ne font que prétendre être nécessaires.
Comment vérifier les codes de réponse
Pour ce faire, vous pouvez utiliser l'un des nombreux programmes disponibles sur Internet. Certains effectuent des vérifications en masse de toutes les pages du site, d'autres nécessitent la saisie de chaque URL. Choisissez un service en fonction de vos besoins.
En fait, il existe un grand nombre de codes de réponse du serveur, mais les plus courants sont les suivants :
- Si au début la page a répondu à la requête avec le code 200, a été indexée avec succès, mais ensuite elle a été supprimée, lorsque vous y accédez, le code 404 (introuvable) s'affichera.
- Si vous utilisez une redirection temporaire (302), les deux adresses entreront dans l'index.
- Si une page web utilise une redirection permanente, vous obtiendrez une réponse avec un code 301. Et le moteur de recherche n'indexera que l'adresse finale avec le code souhaité.
Si vous attribuez une redirection 301 à une page, elle sera ensuite supprimée de la base d'indexation, tandis que son poids pourra être transféré à la page vers laquelle la redirection dirige. Cependant, la réindexation est un processus long ; dans certains cas, Yandex l'exécute en un an. Par conséquent, il est préférable d'éditer immédiatement les pages correctement, de configurer le travail correct avant l'indexation.
Bonjour, chers lecteurs du site blog. Aujourd'hui, je souhaite examiner les codes d'état et les en-têtes HTTP qui font partie de la réponse du serveur et fournir des informations précieuses sur le fonctionnement du site. Eh bien, voyons quels outils vous permettent de les vérifier.
Ce matériel sera une suite logique de l'article précédent, où j'ai présenté des informations générales sur, qui servent ni plus ni moins qu'un "véhicule" pour transmettre l'hypertexte (), qui est précisément le contenu de n'importe quelle page d'une ressource Web.
Si chaque page de votre site renvoie une réponse avec le code correct lors des requêtes au serveur, ce sera une grande contribution à sa promotion réussie. Et inversement, un code qui ne correspond pas à l'état de la page web peut grandement gâcher la vie du webmaster et initier des affaissements de postes. Par conséquent, je vous conseille de ne pas négliger cet aspect et de lui accorder toute l'attention nécessaire, du moins de manière générale, après avoir lu cet article.
Réponse du serveur et ses composants pouvant affecter le référencement
Dans l'article expliquant l'essence du transfert de données via le protocole HTTP (HTTPS), dont le lien est donné au début de la publication, j'ai expliqué comment la communication se déroule en principe, qui est basée sur le schéma "requête du client - réponse du serveur".
Permettez-moi de vous rappeler brièvement comment cela se fait. Le navigateur, après que l'utilisateur a saisi l'URL de la page dans la barre d'adresse, accède au serveur DNS le plus proche, qui stocke les listes de tous les domaines (), ainsi que leurs adresses IP correspondantes (chaque appareil sur Internet possède, y compris les serveurs où sites "vivants" ).
Après avoir reçu l'IP souhaitée, le navigateur envoie une requête GET au serveur IP correspondant pour obtenir le contenu souhaité. Le logiciel serveur traite la demande et envoie une réponse qui inclut le contenu de la page Web sous forme de code HTML, qui est ensuite modifié par le navigateur Web pour afficher le contenu de la page sous une forme lisible.
Mais, comme on dit, pas un seul navigateur ... De même, tout programme client équipé des fonctionnalités nécessaires pour cela, y compris robots des moteurs de recherche. Les principes du mécanisme d'une telle interaction pour diverses applications sont absolument identiques, la différence n'est que dans les détails.
L'une des nuances est que la tâche principale du navigateur Web est d'afficher le contenu de la page dont l'utilisateur a besoin. Pour les robots de recherche, la fonction d'affichage du contenu sur l'écran du moniteur n'est pas du tout pertinente. Ils utilisent les informations qui sont toujours contenues dans la réponse du serveur à leurs propres fins égoïstes, à savoir, comme un facteur supplémentaire utilisé lors de l'évaluation d'une page de ressources.
Afin de vérifier pratiquement la réponse du serveur à la demande du robot du moteur de recherche Yandex, vous pouvez utiliser un outil spécial, où vous entrez l'URL de la page à l'étude, et également sélectionner le bot souhaité dans la liste déroulante (dans en plus du principal, il existe des robots pour les miroirs, pour les photos, pour la recherche de vidéos et autres) :
Ci-dessous, je vous dirai plus en détail quelles informations utiles peuvent être tirées de ces données. Après tout, si nous comprenons cela, nous pouvons savoir dans quelle direction se diriger en termes d'optimisation SEO des pages du site. Eh bien, prêtons attention aux autres services en ligne grâce auxquels vous pouvez vérifier le code de réponse du serveur et afficher le contenu des en-têtes HTTP.
Codes d'état HTTP - 200, 301, 302, 403, 404, 500 et autres
Le code d'état fourni dans la réponse du serveur détermine l'état de la page Web du site pour laquelle l'application cliente envoie une demande au serveur. Par exemple, HTTP 200 OK signifie que tout le contenu de la page a été soumis et sera disponible pour consultation.
Pour une promotion réussie, l'essentiel est que, dans chaque cas, le code de statut soit correct et corresponde à l'état actuel des choses. Disons que si l'adresse a été modifiée définitivement pour une raison ou une autre, alors la réponse du serveur doit indiquer la présence par rapport à la page étudiée (dans la capture d'écran ci-dessous, l'url de la page vers laquelle la redirection a été faite est indiquée comme le Valeur "Emplacement") :
Un exemple pratique est la redirection permanente, qui crée des pages en double avec le même contenu, ce qui, sans mesures appropriées pour les éliminer, peut entraîner un plantage. Avant de poursuivre la discussion, voyons quels codes existent en général, qui sont divisés en cinq groupes :
1. 1XX- des informations, dans lesquelles le serveur rend compte du processus de traitement de la demande.
2. 2XX- Codes HTTP informant des données transférées avec succès. J'ai déjà mentionné 200 OK, le reste en sont des dérivés.
3. 3XX— redirection de différents types d'une URL à une autre. Par exemple, si 301 signifie que l'adresse de la page a changé définitivement, alors le code 302 indique une redirection temporaire. Contrairement à une redirection 302 permanente, ce n'est pas un signal aux moteurs de recherche pour transférer le poids de la page de l'ancienne adresse, donc en pratique, elle n'est utilisée que dans des situations exceptionnelles où c'est la solution la plus optimale.
4. 4XX- Codes d'erreur HTTP dans la requête du client. Par exemple, le code d'état bien connu 404 signifie qu'il n'y a pas de document à cette adresse sur l'hôte.
5. 5XX- une erreur sur le serveur, à la suite de laquelle la page ne peut pas être fournie.
Pour une liste plus détaillée des codes d'état fournis dans la réponse HTTP du serveur, vous pouvez visiter la page Wikipedia associée.
L'importance du statut correct des pages d'une ressource Web est très difficile à surestimer. Par conséquent, essayez de temps en temps de vérifier les codes de réponse du serveur pour les pages de votre site, cela peut vous protéger de nombreux problèmes.
Il y a eu des cas, par exemple, lorsque le serveur répond par un code HTTP 404 au lieu des 200 attendus, car en réalité les pages web sont parfaitement accessibles et s'ouvrent. Si une telle situation, à Dieu ne plaise, se produit lorsque le serveur répond à une requête du même robot Yandex, il est probable que ces pages tomberont de l'index, ce qui sera très décevant.
Mais même si un tel cas de force majeure se produit, une vérification rapide du code d'état aidera à détecter ce problème à temps et à corriger ses conséquences avec un minimum de temps et d'efforts dont vous pourriez avoir besoin pour d'autres tâches importantes d'optimisation de site Web.
Si vous avez un hébergement mutualisé standard, alors contacter votre support technique est souvent la meilleure solution. Si votre ressource est située sur un serveur dédié, vous devrez probablement résoudre le problème vous-même, mais l'essentiel est que vous connaissiez non seulement son existence, mais également "d'où poussent ses jambes".
Si vous regardez la capture d'écran ci-dessus, où la réponse du serveur est donnée, vous verrez que juste en dessous de la ligne avec le code d'état, il y a une explication qui comprend des informations sur le temps de réponse du serveur, l'adresse IP du site, l'encodage et la taille de la page :
Particulièrement intéressant temps de réponse du serveur, qui fait partie intégrante de . Cet indicateur fait partie des facteurs de classement, nous sommes donc extrêmement intéressés par la manière de le réduire.
Quel doit être le temps de réponse ? Google, par exemple, définit une limite maximale de 200 ms (millisecondes), mais bien sûr, plus elle est basse, mieux c'est. Comment augmenter la vitesse de réponse du serveur ? Pour commencer, essayez de réaliser quelques activités sur, il est fort possible que l'installation d'un plugin de mise en cache règle le problème.
Il est possible que les actions que vous avez entreprises n'aident pas beaucoup, car beaucoup dépend des paramètres et des capacités du logiciel serveur lui-même. Il est alors logique de contacter l'administrateur du serveur d'hébergement. Si vous n'obtenez pas de réponse claire, et que le temps de réponse du serveur dépasse largement la limite indiquée ci-dessus, vous devriez penser à au moins changer de fournisseur.
Les en-têtes HTTP et leur signification
Dans cette optique, nous examinerons des exemples de réponses à requêtes du robot du moteur de recherche car ils nous intéressent au premier chef. Pour plus de clarté, je présente d'abord une capture d'écran avec les en-têtes HTTP correspondant à l'url de la page avec le statut 200 OK :
serveur— nom et version du serveur Web. Dans cet exemple, il s'agit de nginx qui, en raison de la faible utilisation des ressources et de la flexibilité de la configuration, résout le problème d'optimisation du fonctionnement du serveur Apache principal et est utilisé conjointement avec celui-ci.
Date— date et heure auxquelles le contenu de la page demandée a été renvoyé.
longueur du contenu- la quantité de contenu transmis en octets ().
lien- lien. Le paramètre keep-alive signifie qu'après l'émission du document, la connexion avec le serveur n'est pas interrompue et des requêtes supplémentaires peuvent être envoyées.
Varier- cet en-tête permet de renvoyer le bon document s'il existe plusieurs versions de celui-ci. Il est pertinent, par exemple, lors de l'utilisation de la technologie de compression de page, lorsque les versions compressées et non compressées sont stockées dans le cache. Avec une réponse Accept-Encoding, le cache contiendra différentes versions de la page demandée pour différentes applications clientes (agents).
Cache-Control- gestion du cache. Dans notre exemple, cet en-tête reflète le type de cache dans lequel se trouve le document (public) et le temps pendant lequel il doit être dans le cache (max-age). La valeur publique spécifie que cette opération s'applique aux fichiers stockés dans le cache public. Le paramètre max-age donne le temps en secondes.
X-Hyper-Cache est un titre spécial que de nombreux utilisateurs de WordPress ont probablement identifié tout de suite. Sans aucun doute, il touche le travail, que je considère peut-être le meilleur de sa catégorie. La valeur "hit - gzip" indique que la page mise en cache a été compressée à l'aide de la méthode gzip.
encodage de contenu- un moyen d'encoder (au sens général) le contenu de la page transmis dans la réponse. Dans notre exemple, la compression gzip a été appliquée. Il s'agit d'un signal au programme client (agent utilisateur) pour décompresser le contenu pour sa perception correcte.
Et maintenant, je vais marquer les en-têtes de réponse, au contenu desquels les webmasters doivent porter une attention particulière, car cela peut avoir un impact sérieux sur la promotion. De plus, si vous utilisez un site comme outil de gestion de contenu, à l'aide duquel des pages HTML sont générées à la volée, alors avec une forte probabilité, si une page Web a un problème, le reste en souffrira également.
type de contenu— type de contenu, qui dans cet exemple est HTML encodé en UTF-8. Une spécification incorrecte de l'encodage peut entraîner des difficultés dans la perception du texte par les utilisateurs et les robots PS, et cela se traduit par le fait que la page n'entre pas dans l'index.
Après tout, si l'encodage est mal défini, au lieu d'un texte russe adéquat, les mêmes utilisateurs verront un "fou" incompréhensible sur la page, ce qui n'augmentera pas le prestige de votre site Web.
Dernière modification— date de la dernière modification de la page Web. Si le client (dans notre cas, le robot Yandex) a reçu cet en-tête du serveur avec la date de mise à jour du contenu, la prochaine fois qu'il accédera à l'URL de la même page, il l'enverra au serveur dans le cadre de la demande. Si-Modifié-Depuis.
Le serveur Web allouera l'intervalle entre la dernière heure modifiée et l'heure spécifiée dans l'en-tête If-Modified-Since. Si pendant cette période la page n'a été modifiée d'aucune façon, le serveur enverra une réponse avec un code HTTP 304 Non modifié, auquel cas le contenu de la page ne sera pas envoyé. Si l'édition a eu lieu, alors le robot recevra le code 200 OK avec le contenu modifié.
Ce mécanisme, s'il est configuré correctement, vous permet de fournir des informations constamment actualisées. Après tout, la pertinence des données est importante ici, ce qui est assuré par la mise en œuvre correcte de la vérification de l'heure de la dernière mise à jour. Après tout, si le paramétrage est incorrect (si la date spécifiée dans Last-Modified ne change pas), le robot peut simplement recevoir un code 304 Not Modified (au lieu de 200 OK avec une nouvelle version du document), bien que le contenu ait été édité plusieurs fois.
Comment pouvez-vous vérifier si Last-Modified fonctionne correctement pour le serveur sur lequel se trouve votre site ? Essayons de comprendre sur un exemple concret.
Sur le même service Yandex, le lien vers lequel j'ai déjà suggéré ci-dessus, il existe une option spéciale qui vous permet d'ajouter une demande If-Modified-Since et de spécifier la date et l'heure dont vous avez besoin (au format GMT, c'est-à-dire GMT, par rapport au fuseau horaire de Moscou, c'est - 3 heures) jusqu'à minutes, ce qui déterminera l'intervalle de temps pour vérifier les mises à jour :
Jetez un œil à la capture d'écran 10 ci-dessus à partir d'ici, qui montre le résultat de la vérification par rapport à l'URL de l'une de mes pages de blog (où toutes les sections de la réponse du serveur sont marquées). Là, dans la partie des en-têtes, une certaine valeur Last-Modified est donnée, c'est-à-dire la date de la dernière mise à jour. Maintenant, j'inclus une métrique If-Modified-Since dans la requête et vérifie la réponse du serveur :
Comme vous pouvez le voir, un code 304 Not Modified a été reçu sans contenu de page Web, ce qui est parfaitement correct pour cette situation, puisque le contenu n'a pas vraiment été mis à jour pendant cette période. Ensuite, pour tester, j'ai ajouté un petit morceau de texte dans cet article.
Ensuite, j'ai de nouveau envoyé une requête du robot Yandex au serveur, qui, si le mécanisme de mise en cache fonctionne correctement (après mise à jour de la page, la dernière version est présente dans le cache), devrait renvoyer une réponse 200 OK avec le nouveau contenu, qui arrivé:
Pour une tranquillité d'esprit totale, vous pouvez également consulter le contenu de l'en-tête Content-Lenght, qui montre que la quantité de contenu a légèrement augmenté, mais a augmenté (18443 contre 18437 avant édition). C'est vrai, parce que j'ai juste ajouté une fraction du texte. De même, vous pouvez vérifier si les en-têtes sont correctement définis pour votre serveur.
emplacement est une autre rubrique que je voudrais mentionner dans un souci d'exhaustivité sur ce sujet. Il apparaît dans la réponse du serveur si le robot envoie une requête pour une page web, à partir duquel la redirection permanente a été effectuée(code HTTP 301) :
La nouvelle adresse qui a été redirigée sera présente dans l'en-tête Emplacement. Le contenu de la page manque dans la réponse, ce qui est assez logique, mais dans l'explication qui suit le code de réponse 301 Moved Permanently, la taille de la page vers laquelle la redirection est effectuée est indiquée.
Vérification de la réponse du serveur dans les services en ligne
De plus, dans un souci d'exhaustivité, il est utile de noter les services en ligne qui vous permettent de vérifier la réponse HTTP du serveur. Sur Internet, j'ai aimé celui-ci (Checkmy.ru), qui a des fonctionnalités décentes. Vérifions maintenant la réponse du serveur dessus, mais à la demande du robot Google pour un changement :
Après avoir activé le processus juste en dessous, vous recevrez une réponse avec tous les layouts :
Le service Checkmy offre aux utilisateurs non seulement le choix de l'application (User Agent) à partir de laquelle la requête sera envoyée, mais également l'utilisation des en-têtes If-Modified-Since et Accept-Encoding, dont il a été question plus haut.
De plus, lorsqu'une réponse contient un code de redirection, le nombre de redirections sera indiqué (idéalement, il devrait être le seul). Plusieurs redirections consécutives donnent déjà matière à réflexion, car ce n'est pas la meilleure option pour optimiser une ressource.
Le site dispose également d'une fonctionnalité telle qu'un signet de navigateur, qui fournira une vérification rapide de toute page Web sur laquelle vous vous rendez. Pour ce faire, faites simplement défiler la page jusqu'à l'emplacement souhaité en cliquant sur le lien "Accès rapide" dans le menu supérieur. Ensuite, en saisissant le bouton avec le bouton gauche de la souris "Vérifier mon", déplacez-le dans la barre de favoris du navigateur :
En conclusion, je voudrais noter un autre service, à l'aide duquel vous pouvez effectuer avec succès une vérification de réponse de masse du serveur pour 200 URL à la fois, et il est possible de télécharger une archive ZIP avec des URL. Et pour le dessert, une vidéo sur ce qu'est le code 404 Soft et pourquoi il est dangereux pour les webmasters :
