Qu’est-ce qu’un code erreur 410 ?

L’erreur 410 Gone est un code d’état de réponse HTTP indiquant que la ressource demandée par le client a été définitivement supprimée et que le client ne doit pas s’attendre à une redirection ou une adresse de transfert alternative. Le code 410 Gone peut ressembler au code 404 page introuvable que j’ai abordé il y a quelques jours.

Les deux codes ont un objectif nettement différent. Un code 404 indique que la ressource demandée n’est pas disponible actuellement, mais qu’elle pourrait l’être lors de futures requêtes. À l’inverse, un code 410 indique explicitement que la ressource demandée existait auparavant, mais qu’elle a depuis été définitivement supprimée et ne sera plus disponible à l’avenir. Ainsi, un code de réponse 404 indique que l’agent utilisateur (navigateur) peut répéter des demandes pour la même URL de ressource, tandis qu’un code 410 indique à l’agent utilisateur de ne pas répéter les demandes pour cette même ressource.

Comme la plupart des codes de réponse HTTP, en particulier ceux qui indiquent une erreur, l’apparition d’une erreur 410 peut être un difficile à diagnostiquer et à résoudre correctement. Avec un ensemble potentiel de plus de 50 codes d’état qui représentent la relation complexe entre le client, une application web, un serveur web et souvent plusieurs services web tiers, déterminer la cause d’un code d’état peut s’avérer relativement technique.

These full-body stretches target every major muscle group steroids australia bloody muscle body builder in hell streaming

Dans cet article, je vais examiner plus en détail l’erreur 410 Gone en étudiant les causes possibles de ce message, ainsi que quelques conseils pour diagnostiquer et déboguer l’apparition de cette erreur dans votre propre application. Nous examinerons même un certain nombre de systèmes de gestion de contenu (SGC) parmi les plus populaires, à la recherche de problèmes potentiels qui pourraient amener votre propre site Web à générer une erreur 410 Gone de manière inattendue. C’est parti !

410 ou 404 : Quand faut-il configurer une 410 et pourquoi ?


Dans la plupart des scénarios, il est acceptable de laisser une page en 404, c’est-à-dire de laisser le serveur renvoyer une réponse 404, lorsqu’il n’y a pas de remplacement de contenu. Idéalement, lorsque vous retirez une page, vous avez une solution de remplacement prête à l’emploi, et au moment de retirer la page, vous la redirigez vers sa solution de remplacement.Parfois, cependant, ce n’est pas possible. Peut-être que le service ne peut plus être proposé. Peut-être qu’un produit ne sera plus proposé à l’avenir. Quel que soit le scénario, vous devez parfois retirer une page sans possibilité de faire une redirection. Si demain vous avez 100 produits qui disparaissent de votre site e-commerce, et que vous en les vendrez plus jamais, inutile de faire 100 redirections en code 301 vers la Home page.

Configurez un code de réponse 410 afin d’accélérer le processus de retrait de ces pages des index des moteurs de recherche et des résultats de recherche. Lorsque vous avez besoin qu’une page soit retirée le plus rapidement possible, c’est à ce moment-là que vous voudrez envoyer une réponse 410. La bonne nouvelle est que l’utilisation de WordPress rend cette tâche assez facile.

Comment configurer un code de réponse 410 dans WordPress


Dans les étapes ci-dessous, je vais vous montrer comment configurer un code de réponse 410, parfois appelé page d’erreur 410, avec WordPress. Je vous montrerai comment effectuer cette tâche, en couvrant quelques scénarios différents.

Comment configurer un code de réponse 410 avec Yoast SEO Premium

erreur 410 yoast


Le moyen le plus simple et le plus facile de configurer une réponse 410 dans WordPress est le plugin Yoast SEO Premium. Oui, Premium. Cela signifie que vous devrez vous abonner à Yoast SEO Premium pour accéder à cette option. Cela dit, avec Yoast SEO Premium, vous êtes en mesure de configurer un en-tête 410 rapidement et facilement. Cette fonction enverra une réponse 410 à tout client demandant une URL, y compris les crawlers.

Si vous souhaitez épargner la dépense et vous attaquer à cette tâche en utilisant des options non payantes voici une autre solution :

Configurer un code de réponse 410 avec Yoast SEO


Bien que Yoast Premium SEO puisse offrir l’option la plus simple, ce n’est pas la seule façon de tirer parti de Yoast pour configurer un code de réponse 410 pour une page. Grâce à l’éditeur de fichiers de Yoast, vous pourrez accéder au fichier .htaccess et ajouter une réponse 410 à l’aide de cette méthode.

Comment configurer un code de réponse 410 avec Yoast SEO :

  • Connectez-vous à WordPress (pour ces étapes, je suppose que vous avez déjà installé Yoast SEO).
  • Naviguez vers SEO > Tools.
  • Sélectionnez File editor (note : si vous ne voyez pas cette option, vous devrez activer l’édition de fichiers avant de continuer).
  • Faites défiler jusqu’au fichier .htaccess.
  • Section .htaccess dans l’éditeur de fichiers de Yoast.
  • Cliquez sur le champ et sur une nouvelle ligne, ajoutez le code suivant : « Redirect 410 [page path] »
  • Sélectionnez Enregistrer les modifications dans le fichier .htaccess.

Voilà, c’est fait. Vous êtes prêt !


Prenons un exemple. Supposons que je veuille rediriger ma page de contact vers 410 (ce que personne ne devrait faire, jamais) :

Redirect 410 /contact/


Dans l’exemple présenté, j’indique au serveur que tout client se rendant sur /contact/ doit recevoir une réponse 410.

Vous devrez également utiliser une nouvelle ligne pour chaque chemin de page. Plusieurs pages ne doivent pas figurer sur la même ligne.

Imaginons que je veuille donner une réponse 410 non seulement à ma page de contact mais aussi à ma page de services.

Voici à quoi cela ressemblerait dans le fichier .htaccess :

Redirect 410 /contact/
Redirect 410 /services/

Comment configurer un code de réponse 410 sans plugin WordPress ?


Ci-dessous, je vais vous montrer comment ajouter directement un en-tête 410 à votre fichier .htaccess :

Connectez-vous à votre hébergeur web :

  • Accédez à cPanel.
  • Accédez au gestionnaire de fichiers.
  • Sélectionnez le dossier public_html.
  • Sélectionnez le fichier .htaccess.
  • Sélectionnez Edit.
  • Ajoutez la page que vous voulez rediriger vers 410, en utilisant la syntaxe suivante : Redirect 410 [page-path]

Exemple : Redirect 410 /blog/article-xyz/


Enregistrez le fichier. Voilà, c’est fait. Vous êtes prêt.

Mais parfois le code erreur 410 n’est pas intentionnel. Il faut donc trouver le problème afin de la résoudre

Côté serveur ou côté client ?


Tous les codes d’état de réponse HTTP qui appartiennent à la catégorie 4xx sont considérés comme des réponses d’erreur client. Ces types de messages contrastent avec les erreurs de la catégorie 5xx, comme l’erreur 504 Gateway Timeout Error, qui sont considérées comme des réponses d’erreur de serveur. Cela dit, l’apparition d’une erreur 4xx ne signifie pas nécessairement que le problème se situe du côté du client, le « client » étant le navigateur Web ou le périphérique utilisé pour accéder à l’application. Souvent, si vous essayez de diagnostiquer un problème avec votre propre application, vous pouvez immédiatement ignorer la plupart du code et des composants côté client, comme le HTML, les feuilles de style en cascade (CSS), le JavaScript côté client, etc. Cela ne s’applique pas uniquement aux sites Web. De nombreuses applications pour smartphone qui présentent une interface utilisateur moderne sont en fait alimentées par une application Web normale en arrière-plan, qui est simplement cachée à l’utilisateur.

D’un autre côté, cela n’exclut pas non plus que le client soit la cause réelle de l’erreur 410 Gone Error. Dans de nombreux cas, le client peut envoyer involontairement une requête à la mauvaise ressource, ce qui peut conduire à une erreur 410. Nous allons explorer certains de ces scénarios (et les solutions possibles) ci-dessous, mais sachez que, même si l’erreur 410 Gone est considérée comme une réponse d’erreur du client, cela ne signifie pas en soi que nous pouvons exclure le client ou le serveur comme étant le coupable dans ce scénario. Dans ces scénarios, le serveur est toujours celui qui produit l’erreur 410 Gone et la renvoie au client sous forme de code de réponse HTTP, mais il se peut que le client soit à l’origine du problème.

Commencez par une sauvegarde complète de l’application


Comme pour toute chose, il est préférable d’avoir joué la carte de la sécurité dès le départ que de se planter et de le regretter plus tard. Il est donc essentiel d’effectuer une sauvegarde complète de votre application, de votre base de données, etc.. avant d’essayer de corriger ou de modifier le système. Mieux encore, si vous en avez la possibilité, créez une copie complète de l’application sur un serveur secondaire qui n’est pas « en direct » ou qui n’est pas actif et accessible au public. Vous disposerez ainsi d’un terrain d’essai propre sur lequel vous pourrez tester toutes les corrections potentielles pour résoudre le problème, sans menacer la sécurité ou l’inviolabilité de votre application en ligne.

Diagnostic de l’erreur 410 Gone


Comme nous l’avons vu dans l’introduction, l’erreur 410 Gone Error indique que l’agent utilisateur (le navigateur web, dans la plupart des cas) a demandé une ressource qui a été définitivement supprimée du serveur. Cela peut se produire dans plusieurs circonstances différentes :

  • Le serveur disposait d’une ressource valide à l’emplacement demandé, mais elle a été intentionnellement supprimée (en Ecommerce, lorsqu’un produit n’est plus disponible et ne sera plus jamais commercialisé, je recommande d’utiliser le code 410 pour signaler à Google de ne plus prendre en compte la page en question).
  • Le serveur devrait avoir une ressource valide à l’emplacement demandé, mais il signale involontairement que la ressource a été supprimée.
  • Le client essaie de demander une ressource incorrecte.


Dépannage du côté client


Étant donné que l’erreur 410 Gone est un code de réponse d’erreur client, il est préférable de commencer par résoudre tout problème côté client qui pourrait être à l’origine de cette erreur. Voici quelques conseils à essayer sur le navigateur ou l’appareil qui vous pose problème.

Vérifiez l’URL demandée


La cause la plus courante d’une erreur 410 Gone Error est tout simplement la saisie d’une URL incorrecte. Comme nous l’avons vu précédemment, de nombreux serveurs Web sont étroitement sécurisés pour interdire l’accès à des URL incorrectes auxquelles le serveur n’est pas prêt à donner accès. Il peut s’agir d’une tentative d’accès à un répertoire de fichiers via une URL ou d’une tentative d’accès à une page privée destinée à d’autres utilisateurs. Les codes 410 n’étant pas aussi courants que les codes 404, l’apparition d’un 410 signifie généralement que l’URL demandée a été valide à un moment donné, mais que ce n’est plus le cas. Dans tous les cas, il est conseillé de vérifier l’URL exacte qui renvoie l’erreur 410 Gone Error pour s’assurer qu’il s’agit bien de la ressource visée.

Debug


Si vous exécutez des logiciels sur le serveur qui répondent avec l’erreur 410 Gone, vous pouvez commencer par vérifier la stabilité et la fonctionnalité de ces plateformes. Les systèmes de gestion de contenu les plus courants, tels que WordPress, Joomla ! et Drupal, sont généralement bien testés, mais dès que vous commencez à apporter des modifications aux extensions sous-jacentes ou au code PHP (le langage dans lequel presque tous les systèmes de gestion de contenu modernes sont écrits), il est très facile de provoquer un problème imprévu qui entraîne l’erreur 410 Gone.

Vous trouverez ci-dessous quelques conseils destinés à vous aider à dépanner certaines de ces plateformes logicielles populaires

Annulation des mises à jour récentes


Si vous avez récemment mis à jour le système de gestion de contenu lui-même juste avant l’apparition de l’erreur 410 Gone, vous pouvez envisager de revenir à la version précédente que vous aviez installée lorsque tout fonctionnait bien. De même, les extensions ou les modules que vous avez récemment mis à niveau peuvent également causer des problèmes côté serveur, de sorte que le retour à des versions antérieures de ceux-ci peut également être utile. Pour obtenir de l’aide dans cette tâche, il suffit de chercher sur Google « downgrade [PLATFORM_NAME] » et de suivre. Dans certains cas, cependant, certains CMS ne fournissent pas vraiment de rétrogradation de version, ce qui indique qu’ils considèrent l’application de base, ainsi que chaque nouvelle version publiée, comme extrêmement stable et sans bogue. C’est généralement le cas pour les plates-formes les plus populaires, alors n’ayez pas peur si vous ne trouvez pas un moyen facile de revenir à une version antérieure de la plate-forme.

Désinstaller les nouvelles extensions, modules ou plugins


Selon le système de gestion de contenu utilisé par votre application, le nom exact de ces composants sera différent, mais ils servent le même objectif dans tous les systèmes : améliorer les capacités et les fonctionnalités de la plate-forme au-delà de ce qu’elle est normalement capable de faire. Mais attention : ces extensions peuvent, plus ou moins, prendre le contrôle total du système et apporter pratiquement n’importe quel changement, que ce soit au code PHP, HTML, CSS, JavaScript ou à la base de données. Il peut donc être judicieux de désinstaller toute nouvelle extension récemment ajoutée. Encore une fois, recherchez le nom de l’extension sur Google pour obtenir la documentation officielle et de l’aide pour ce processus.

Vérifier les changements inattendus dans la base de données


Il convient de noter que, même si vous désinstallez une extension via le tableau de bord du CMS, cela ne garantit pas que les modifications apportées par l’extension ont été entièrement annulées. Cela est particulièrement vrai pour de nombreuses extensions WordPress, qui ont carte blanche dans l’application, y compris des droits d’accès complets à la base de données. À moins que l’auteur de l’extension ne code explicitement de telles choses, il existe des scénarios dans lesquels une extension peut modifier des enregistrements de base de données qui n’appartiennent pas à l’extension elle-même, mais qui sont plutôt créés et gérés par d’autres extensions (ou même par le CMS de base lui-même). Dans ces scénarios, l’extension peut ne pas savoir comment revenir sur les modifications apportées aux enregistrements de la base de données, de sorte qu’elle ignorera ces choses pendant la désinstallation. Le diagnostic de tels problèmes peut être délicat, mais j’ai personnellement rencontré de tels scénarios à de multiples reprises. Votre meilleure ligne de conduite, en supposant que vous êtes raisonnablement convaincu qu’une extension est le coupable probable de l’erreur 410 Gone, est d’ouvrir la base de données et de regarder manuellement les tables et les enregistrements qui ont probablement été modifiés par l’extension.

Surtout, n’ayez pas peur de chercher votre problème sur Google. Essayez de rechercher des termes spécifiques liés à votre problème, tels que le nom du CMS de votre application, ainsi que l’erreur 410 Gone. Il y a de fortes chances que vous trouviez quelqu’un qui a rencontré le même problème.

Dépannage du côté du serveur


Si vous n’exécutez pas d’application CMS – ou même si vous en exécutez une, mais que vous êtes certain que l’erreur 410 Gone Error n’y est pas liée – voici quelques conseils supplémentaires pour vous aider à trouver la cause du problème du côté du serveur.

Confirmez la configuration de votre serveur


Votre application est probablement exécutée sur un serveur qui utilise l’un des deux logiciels de serveur web les plus populaires, Apache ou nginx. Ces deux serveurs Web représentent plus de 84 % des logiciels de serveur Web dans le monde ! Ainsi, l’une des premières mesures que vous pouvez prendre pour déterminer ce qui peut être à l’origine de ces codes de réponse 410 Gone Redirect est de vérifier les fichiers de configuration de votre logiciel de serveur web.

Pour déterminer quel serveur web votre application utilise, vous devez rechercher un fichier clé. Si votre serveur Web est Apache, recherchez un fichier . htaccess dans le répertoire racine du système de fichiers de votre site Web. Par exemple, si votre application se trouve sur un hôte partagé, il est probable qu’un nom d’utilisateur soit associé au compte d’hébergement. Dans ce cas, le répertoire racine de l’application se trouve généralement dans le chemin /home//public_html/, et le fichier . htaccess se trouve donc dans /home//public_html/. htaccess.

Si vous avez trouvé le fichier . htaccess, ouvrez-le dans un éditeur de texte et recherchez les lignes qui utilisent les directives RewriteXXX, qui font partie du module mod_rewrite d’Apache. Le fonctionnement exact de ces règles dépasse largement le cadre de cet article, mais le concept de base est le suivant : une directive RewriteCond définit un modèle textuel qui sera comparé aux URL saisies. Si une URL correspondante est demandée par un visiteur du site, la directive RewriteRule qui suit une ou plusieurs directives RewriteCond est utilisée pour effectuer la redirection de la demande vers l’URL appropriée.

Par exemple, voici une simple RewriteRule qui fait correspondre toutes les demandes entrantes à https://www.niches-detective.com/expired_pag et qui répond avec un code d’erreur 410 Gone Redirect :

RewriteEngine sur
RewriteRule ^(.*)$ https://www.niches-detective.com/expired_page$1 [R=410,L]
Remarquez l’indicateur R=410 à la fin de la RewriteRule, qui indique explicitement que le code de réponse doit être 410, ce qui indique aux agents utilisateurs que la ressource a été définitivement supprimée et qu’aucune demande ne doit être effectuée à l’avenir. Ainsi, si vous trouvez des directives RewriteCond ou RewriteRule étranges dans le fichier . htaccess, essayez de les commenter temporairement (en utilisant le préfixe #) et redémarrez votre serveur Web pour voir si cela résout le problème.

En revanche, si votre serveur fonctionne avec nginx, vous devrez rechercher un fichier de configuration complètement différent. Par défaut, ce fichier est nommé nginx.conf et se trouve dans l’un des quelques répertoires courants : /usr/local/nginx/conf, /etc/nginx, ou /usr/local/etc/nginx. Une fois localisé, ouvrez nginx.conf dans un éditeur de texte et recherchez les directives qui utilisent l’indicateur de code de réponse 410. Par exemple, voici une directive de bloc simple (c’est-à-dire un ensemble de directives nommées) qui configure un serveur virtuel pour airbrake.io et garantit que la page d’erreur présentée à un agent utilisateur qui fait une demande 404 Not Found est envoyée à la page d’erreur /deleted.html et reçoit une réponse avec un code d’erreur 410 Gone :

serveur {
listen 80 ;
listen 443 ssl ;
server_name airbrake.io ;
error_page 404 =410 /deleted.html ;
}

Recherchez dans votre fichier nginx.conf toute directive ou ligne anormale incluant le drapeau 410. Commentez toute anomalie avant de redémarrer le serveur pour voir si le problème a été résolu.

Analysez les logs


Presque toutes les applications Web conservent une certaine forme de journaux côté serveur. Les journaux d’application sont généralement l’historique de ce que l’application a fait, comme les pages demandées, les serveurs auxquels elle s’est connectée, les résultats des bases de données qu’elle fournit, etc. Les journaux de serveur sont liés au matériel qui exécute l’application, et fournissent souvent des détails sur la santé et l’état de tous les services connectés, ou même simplement le serveur lui-même. Recherchez « logs [PLATFORM_NAME] » si vous utilisez un CMS, ou « logs [PROGRAMMING_LANGUAGE] » et « logs [OPERATING_SYSTEM] » si vous exécutez une application personnalisée, pour obtenir plus d’informations sur la recherche des logs en question.

Déboguer le code ou les scripts de votre application


Si tout le reste échoue, il se peut qu’un problème dans un code personnalisé de votre application soit à l’origine du problème. Essayez de diagnostiquer l’origine du problème en déboguant manuellement votre application et en analysant les journaux de l’application et du serveur. Idéalement, faites une copie de l’application entière sur une machine de développement locale et effectuez un processus de débogage étape par étape, ce qui vous permettra de recréer le scénario exact dans lequel l’erreur 410 Gone Error s’est produite et de visualiser le code de l’application au moment où quelque chose ne va pas.

Quelle qu’en soit la cause – et même si vous avez réussi à la résoudre cette fois-ci – l’apparition d’un problème tel que l’erreur 410 Gone Error au sein de votre propre application est une bonne indication de la nécessité de mettre en place un outil de gestion des erreurs, qui vous aidera à détecter automatiquement les erreurs et à vous les signaler au moment même où elles se produisent.