Le récent incendie des serveurs de l’hébergeur OVH ont mis en avant l’impact parfois catastrophique des problèmes techniques sur le référencement naturel, et plus globalement sur la continuité de service des sites web. Dans une stratégie web, il faut donc impérativement prévoir le pire et savoir comment réagir en fonction de la nature du problème technique, surtout quand on aborde les problématiques de référencement naturel. Voyons donc cela en détails.

Pourquoi est-ce important ?

Quand un site web, quel qu’il soit, rencontre une problématique technique, l’impact peut être multiple. Bien entendu, tout dépend de la nature et de la durée de celle-ci, mais cela peut parfois fortement nuire au propriétaire du site (que ce soit une entreprise, une association ou encore un particulier).

Le premier problème qui vient en tête est celui sur le chiffre d’affaires et/ou sur les conversions (inscriptions, abonnements, téléchargements, etc.). Tant que le site est totalement ou partiellement indisponible, aucune vente ou conversion n’est possible. De même, cela nuit à l’expérience utilisateur : un visiteur arrivant sur une page d’erreur risque d’avoir une image dégradée du site, et dans le pire des cas, il est tout à fait possible qu’il ne revienne jamais.

Ces deux problématiques sont celles auxquelles on va penser le plus facilement. Mais deux autres se posent : la sécurité et la préservation des données d’une part, et surtout le référencement naturel d’autre part.

Si l’on prend le premier problème, un site qui rencontre un problème technique peut provoquer une perte ou une fuite de données (comptes clients, factures, historique de commande, stock et ainsi de suite). Prenons quelques exemples :

  • Lors d’un crash serveur (comme l’incendie d’OVH), les données peuvent être irrémédiablement perdues ;
  • Lors d’un piratage, les données peuvent avoir été transmises à des tiers non autorisés ;
  • Lors d’erreurs techniques (serveur surchargé, erreurs PHP, etc.), les données en cours de saisies peuvent être perdues ou corrompues, ou elles peuvent être exposées publiquement.

Seconde problématique à laquelle on ne pense pas immédiatement : le SEO. Dès que lors que son site est indisponible ou qu’il affiche des erreurs, les moteurs de recherche vont crawler et indexer ces éléments. Malheureusement, la sentence est souvent assez rapide (entre quelques heures et quelques jours) : désindexation de certains contenus, perte de positionnement, etc.

En d’autres termes, un site totalement ou complètement indisponible peut avoir de lourdes conséquences à court et moyen terme.

Avant d’agir, comprendre la problématique

Les types d’erreurs

Avant tout chose, il faut réussir à comprendre la problématique technique. Certaines sont bien plus complexes à gérer que d’autres et pour correctement agir, il faut savoir les différencier.

Serveur non trouvable

C’est sans doute l’un des pires problèmes : le serveur web qui héberge votre site n’est pas accessible. En d’autres termes, lorsque l’on tape le nom de domaine, il est impossible d’accéder à l’hébergement correspondant. Ce sera le cas notamment :

  • Lors d’un crash du serveur (panne technique, incendie, etc.), comme dans le cas d’OVH ;
  • D’une mauvaise configuration ou du non renouvellement du nom de domaine ;
  • Lors d’un mauvais paramétrage du serveur, d’un firewall ou d’un proxy ;
  • Etc.

Un exemple de message d’erreur sur l’un des sites impactés par l’incendie d’OVH. Source image : https://france3-regions.francetvinfo.fr/occitanie/castres-olympique-conseil-departemental-du-tarn-et-garonne-plusieurs-sites-web-hors-service-apres-l-incendie-chez-ovh-1994404.html

Les erreurs serveurs

Il existe bien entendu d’autres types de problèmes liés aux serveurs, qui peuvent afficher un message d’erreur, comme ci-dessous.

Un exemple de message d’erreur renvoyé par un serveur web

Dans cet autre exemple ci-dessous, le serveur n’a pas réussi à répondre. C’est souvent le cas lorsque les ressources du serveur sont insuffisantes, ou encore quand le code est trop gourmand (par exemple trop de requêtes SQL ou une boucle infinie ou non optimisée en PHP). Le serveur surcharge alors et ne répond pas. Cela peut d’ailleurs parfois arriver également lors d’un pic de visiteurs, comme lors d l’ouverture des soldes sur certains sites e-commerce.

Un serveur qui ne parvient pas à « répondre » à temps : le serveur est potentiellement surchargé.

Ces types de problématiques peuvent venir de plusieurs causes :

  • Un mauvais paramétrage du serveur ;
  • Un pic trop fort de visiteurs ;
  • Un code non optimisé qui sollicité trop de ressources ;
  • Un serveur n’ayant pas des capacités suffisantes (processeur, mémoire vive, taille de la base de données, etc.) ;
  • Un code provoquant des erreurs, entraînant alors la surcharge du serveur ;
  • Un seul serveur mal paramétré (par exemple une erreur dans le fichier .htaccess) ;
  • Etc.

Page non trouvée, page blanche ou message d’erreur

Il existera aussi des sites entiers ou des URL spécifiques qui n’affichent qu’une page blanche, un message « page non trouvée », ou encore un message d’erreur. Dans ces cas de figure, il s’agit d’une erreur de votre site et non de votre serveur. Votre CMS ou votre développement sur mesure a rencontré un bug, ce qui provoque :

  • La disparition de contenu (page non trouvée) ;
  • Une page blanche (une erreur est survenue mais rien n’est affiché) ;
  • Un message d’erreur PHP indiquant la nature du problème ;
  • Etc.

Quand ces problèmes surviennent sur quelques URL, ce sont des éléments à corriger, mais dont l’impact négatif sur le référencement naturel sera restreint. Par exemple, de très nombreux sites web ont des pages d’erreurs introuvables sans pour autant nuire fortement à leurs positionnements respectifs. Par contre, si une grande partie ou la totalité du site affiche une page blanche, un message « non trouvé » ou un autre message d’erreur, l’impact sera potentiellement aussi désastreux que lors que le serveur ne fonctionne plus.

Sachez également que ces problèmes techniques liés au site web peuvent aussi être partiellement ou totalement masqués. Par exemple, WordPress masque par défaut toutes les erreurs PHP. En soit, c’est une bonne chose car les moteurs de recherche ne les verront pas. Mais cela empêche le propriétaire du site d’en avoir connaissance, et parfois ces messages indiquent un crash potentiel à venir.

Sur d’autres types d’erreurs, la mise en page du site peut faire croire qu’il n’y a pas de problématique sur l’URL concernée. Dans l’exemple ci-dessous, on peut voir que le site LeMonde.fr a mis en page ces erreurs 404. Si on ne fait pas attention au message, on peut donc penser qu’il s’agit d’une URL « normale ».

La page d’erreur du site LeMonde ressemble à une page classique

Attention cependant, ce type de problématique peut aussi venir de l’utilisateur et ne pas être du tout une problématique technique : par exemple, si un utilisateur supprime une publication sans la rediriger, vous aurez aussi une « page non trouvée ».


Contenus remplacés

C’est sans doute le plus fourbe des problèmes techniques : il n’y a pas d’erreur à proprement parler, mais le contenu est modifié ou remplacé par un autre. Ici, la cause peut être multiple :

  • Piratage (nous en parlerons au point suivant) ;
  • Erreur de l’utilisateur (mauvaise manipulation des contenus, mauvais réglages) ;
  • Bug ou incompatibilité entre deux codes différents ;
  • Etc.

Le vrai souci est d’être capable de le détecter puisqu’aucune URL ne renverra de message d’erreur. La détection est donc humaine, et c’est pour cette raison qu’il est toujours recommandé de contrôler régulièrement et manuellement son site, à minima les pages les plus importantes.

Message de sécurité ou piratage

Enfin, dernier grand type de problème technique : tout ce qui est lié à la sécurité. Cela va du piratage pur et simple jusqu’à la mauvaise mise en place des éléments de sécurité, par exemple un certificat SSL expiré ou mal installé.

Un exemple de message d’erreur lié à un problème de connexion HTTPS

S’il s’agit de problèmes techniques, par exemple ceux liés aux certificats SSL, le risque SEO est modéré, puisque cela n’empêchera pas les robots de venir parcourir vos différents contenus. Par contre, dans le cadre d’un piratage, il est impératif d’agir rapidement car en règle générale, cela peut :

  • Supprimer vos contenus ;
  • Les remplacer ;
  • En ajouter d’autres.

Un exemple de site piraté où Google avait déjà indexé presque 4 millions d’URL indésirables

Dans ce dernier cas de figure, rappelez-vous toujours qu’il faut agir dans le bon ordre :

  1. Trouver la faille ;
  2. Remettre le site en ligne en corrigeant la faille ;
  3. Vérifier si le piratage n’a pas créé de nouveaux contenus qu’il faudrait rediriger (car Google et les autres moteurs de recherche les auront indexés) ;
  4. Vérifier si le site n’a pas reçu une action manuelle dans la Search Console. Si tel est le cas, il faut alors faire une demande de réexamen.

Comment savoir ?

Visuellement

C’est logique : une façon rapide pour savoir si son site a un problème, c’est de naviguer dessus. Une grande partie des problèmes techniques ont en effet une fâcheuse tendance à se voir très facilement.

Les entêtes HTTTP

Certains problèmes sont plus complexes à détecter. On utilisera alors souvent les entêtes HTTP des URL pour cela.

Petite explication : chaque URL sur le web, quelle qu’elle soit, va renvoyer des entêtes HTTP que votre navigateur va utiliser pour afficher le contenu. C’est le cas pour vos articles mais aussi pour vos images, vos scripts, vos vidéos, etc. Une URL « saine », renverra un code 200 (« OK »).

Mais si elle renvoie un code d’entête différent, il peut y avoir une vraie problématique technique cachée derrière. Il en existe beaucoup, voici ceux les plus importants :

  • 3xx : l’URL est redirigée
    • 301 : redirection permanente prise en compte par les moteurs de recherche.
    • 302 : redirection temporaire pouvant nuire à votre SEO.
  • 4xx : l’URL a rencontré une erreur (la « requête »)
    • 401 : accès interdit.
    • 404 : page non trouvée.
    • 410 : contenu qui n’existe plus.
    • Etc.
  • 5xx : le serveur a rencontré une erreur
    • 500 : erreur serveur.
    • 503 : serveur en maintenance.
    • 504 : le serveur n’a pas répondu.
    • Etc.

Pour voir ces entêtes, il existe de nombreuses extensions pour les navigateurs. Par exemple, vous pouvez utiliser Link Redirect Trace sur Chrome ou Firefox. L’icône affichera alors cette information comme le montre la figure ci-dessous.

Link Redirect Trace affiche clairement l’entête 404 de cette URL

La Search Console

Même si les données ne sont pas en temps réel (il y a souvent un décalage de quelques jours), la Search Console de Google peut faire remonter un grand nombre de problématiques sur le site : sécurité, temps de chargement, pages en erreur, etc.

Pensez donc à consulter régulièrement les différents menus de l’outil pour détecter les différents types de problème.

Le monitoring et les tests en ligne

C’est sans doute la meilleure façon de détecter un problème : utilisez des outils externes pour monitorer vos sites, ou a minima vos pages les plus importantes. Vous recevrez alors une alerte dès qu’un problème est survenu. Utilisez aussi les outils des tests en ligne pour chaque aspect technique : cela pourra là aussi vous faire remonter de précieuses informations.

Dans un cas comme dans l’autre, nous vous donnerons plus loin les outils pour faire cela.

Mesurer la « durée » du problème

C’est un point clé : avoir des erreurs techniques sur un site, cela peut arriver pour de multiples raisons. Il faut surtout en comprendre la cause et déterminer la durée de présence et de correction du problème. Car c’est en fonction de cette dernière information que l’on saura quelles actions mettre en place.

Si par exemple il s’agit d’une erreur serveur et qu’il suffit de redémarrer ce dernier en quelques minutes, l’impact sera faible à condition d’agir vite. De même avec des pages 404 causées par exemple avec un simple problème de réécriture d’URL dans WordPress : une simple réinitialisation et tout rentre dans l’ordre.

À l’inverse, lors de piratages ou encore de crash serveur, la durée risque d’être bien plus longue, et la liste des actions à mettre en place le sera d’autant plus.

Plus le problème est constant et long, plus il est urgent d’intervenir. Google a l’habitude d’avoir des erreurs lors de son crawl. Et heureusement, les moteurs de recherche ne déclassent pas un site dès la première apparition d’une erreur. Prenons là encore un exemple : si votre site rencontre un pic de visiteur, il peut surcharger. Google ne le fera pas descendre dans les résultats, sauf si cette surcharge continue pendant de nombreuses heures.

Mais attention, plus un problème va durer, plus Google le prendra en compte en SEO.

Sur un problème partiel, corrigez-le dès que possible

C’est assez logique : si la problématique ne touche pas l’ensemble du site mais uniquement quelques URL, il vous suffira de les corriger. Il n’y a pas d’urgence à le faire, mais ne tardez pas trop non plus. L’impact sur la totalité du site devrait être faible (sauf s’il s’agit d’URL importantes dans votre stratégie ou dans la structure du site.).

Le vrai problème, c’est quand le site entier est impacté : serveur brulé, site piraté, CMS qui ne fonctionne plus, etc.

Quelles actions pour minimiser l’impact ?

Il faut savoir que chez Google, une URL qui renvoie des erreurs peut rapidement être déclassée. Par exemple, si une page qui était positionnée en première position est transformée en page d’erreur 404, elle perdra très rapidement de la visibilité avant d’être à terme désindexée.

En d’autres termes, cela veut dire une chose : lors d’une problématique technique globale, il faut agir vite pour ne pas perdre de référencement. Par contre, une fois le site proprement remis en ligne, l’impact négatif va théoriquement disparaître au bout de quelques jours pour revenir à la normale.

Renvoyer un entête 503

Pourquoi et quand le faire ?

Une solution à très court terme est de renvoyer, pour toutes vos URL, un entête HTTP 503 indiquant que le site est en maintenance. Les moteurs de recherche comprennent cette indication et vont revenir alors quelques heures plus tard pour vérifier si le site est de nouveau en ligne. C’est d’ailleurs natif dans certains cas, par exemple lors de la mise à jour de WordPress.

Cependant, faites très attention : renvoyer un entête 503 ne vous protège que quelques jours. Les équipes de Google on en effet indiqué récemment qu’au bout de 1 ou deux jours, une code 503 n’est pas suffisant pour conserver l’URL à son positionnement initial, voire dans son index.

« Serving 503 to all requests gives you a day or two before Search starts dropping URLs »

Source : https://twitter.com/JohnMu/status/1369654452387471367

La documentation officielle de Google en parle également ici : https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime : 

« It is important, however, to not treat 503 as a permanent solution: lasting 503s can eventually be seen as a sign that the server is now permanently unavailable and can result in us removing URLs from Google's index »

Comment faire ?

Il existe différentes solutions, en fonction bien entendu de votre serveur ou CMS.

La plus courante, sur un serveur Apache classique (il existe des tutoriels pour faire l’équivalent sur des serveurs NGINX), est qu'il faudra modifier le fichier .htaccess à la racine du site pour ajouter tout en haut de ce dernier ces règles :

RewriteEngine on

RewriteCond %{REQUEST_URI} !^/maintenance.php [NC]

RewriteRule .* /maintenance.php [L]

Ainsi, toutes les pages du site vont utiliser le contenu du fichier maintenance.php que vous devrez également créer à la racine de votre serveur web. Puis, au tout début de ce fichier, il faudra ajouter les entêtes désirés, à savoir :

<?php

header('HTTP/1.1 503 Service Unavailable');

header('Retry-After: 3600');

?>

<!DOCTYPE html>

<html>

<head>

    …

Ainsi, toutes les URL de votre site vont renvoyer l’entête HTTP 503, vous donnant quelques heures de plus pour corriger vos problèmes techniques.

Sachez aussi qu’il existe d’autres solutions :

  • Certains hébergeurs ont une option « Maintenance du serveur » ;
  • Si votre CMS fonctionne encore, il existe des extensions qui permettent de faire cela, par exemple ici avec « Maintenance » sur le CMS WordPress : https://wordpress.org/plugins/maintenance/

Migrer vers un nouveau serveur

Malheureusement, la solution précédente part du principe que vous pouvez encore agir sur votre serveur. Dans le cas de l’incendie d’OVH, ce n’était pas le cas. En effet, tous les sites hébergés dans ce Datacenter ne pouvaient plus fonctionner. Et malheureusement, le rétablissement physique des serveurs est forcément long. Il faut donc opter le plus vite possible pour une solution plus drastique : migrer vers un nouveau serveur.

Avant cela, il est impératif de comprendre comment interagissent votre site, votre serveur et votre nom de domaine. N’importe quel site web fonctionne ainsi :

  • Du code et une base de données : c’est le cœur du site qui permet de gérer les fonctionnalités, les utilisateurs, les contenus, etc. ;
  • Ce code et cette base de données sont stockés sur un serveur web (chez votre hébergeur), donc si on schématise, sur un « ordinateur ». Ce serveur dispose de sa propre adresse : une adresse IP (un équivalent de votre adresse postale) ;
  • Votre nom de domaine est une adresse Web. Quand l’utilisateur l’utilise, voici alors ce qui se passe :
    • L’ordinateur de l’internaute fait une requête DNS pour connaître l’adresse IP du serveur ;
    • L’ordinateur de l’internaute peut alors se connecter à cette adresse IP, donc à votre site.

Le nom de domaine et l’adresse IP sont gérés au niveau de ce qu’on appelle les registrars. Ce n’est pas stocké sur le serveur web. Cela veut dire une chose simple : si ce dernier est indisponible (incendie, panne matérielle, etc.), alors on peut toujours agir sur le nom de domaine pour en changer son adresse IP. On parle de « changement de DNS ». Si vous disposez de sauvegarde de votre site (fichiers et base de données), vous pouvez donc à tout moment migrer vers un nouveau serveur web, voir même chez un nouvel hébergeur en routant son adresse web vers une autre adresse IP (celle de sa version de sauvegarde).

En cas de panne technique longue, il est ainsi conseillé de migrer au plus vite vers un nouveau serveur web. En simplifiant le travail à réaliser, voici ce qu’il faut faire :

  1. Si possible, mettre l’entête 503 sur le serveur actuel ;
  2. Copier les fichiers et la base sur un nouvel hébergement ;
  3. Tester si la migration est correcte (pas d’erreurs, pas de fichiers manquants, etc.) ;
  4. Changer les DNS du nom de domaine pour « pointer » vers le nouvel hébergement quand ce dernier est prêt.

On peut alors parfois changer de serveur web en l’espace de quelques heures.

Déployer une version statique de ses pages importantes

Si vous n’avez pas la possibilité de migrer vers un nouveau serveur, par exemple si vous n’avez pas de sauvegarde, il existe une autre solution complexe et longue à mettre en place mais qui peut fonctionner.

C’est John Mueller de Google qui l’a donnée ici https://twitter.com/JohnMu/status/1369939925064355841. Le but est de remettre en ligne le plus vite possible les pages-clés de son site, que ce soit sur le serveur si on peut agir dessus, ou sur un nouveau serveur en changeant les DNS. Voici ce qu’il préconise :

  1. Sur son futur serveur, faire en sorte que les erreurs 404 renvoient toutes des entêtes 503 ;
  2. Page par page :
    • Aller sur archive.org ;
    • Chercher l’URL ;
    • Copier le contenu complet de la page si vous la trouvez (HTML, Images, etc.) ;
    • Copiez le tout sur votre serveur web en tant que page statique HTML ;
    • Répétez l’opération pour toutes les pages importantes, si possible pour le site entier.

Attention, c’est un travail long et fastidieux, et malheureusement vous n’avez pas de garantie de trouver toutes vos URL sur Archive.org.

Un exemple du contenu archivé de la page d’accueil d’Abondance.com

Points de vérifications

L’importance du recettage lors de la remise en état

Que vous remettiez en ligne votre site sur votre serveur actuel, que vous ayez corrigé des erreurs techniques, que vous ayez réparé un site piraté ou que vous ayez changé de serveur, il est impératif de mettre en place une vérification de l’ensemble de vos URL.

Tout problème technique, quelle que soit sa nature et sa taille, peut avoir des effets secondaires sur le référencement naturel du site. Vous devez donc toujours vérifier que tout est entièrement remis en ordre. Et il ne suffit pas de naviguer sur quelques pages pour s’en assurer.

Crawler son site

C’est une première méthode simple qui permet de déceler une partie des problèmes. Vous devez utiliser un outil de crawl, que ce soit un logiciel ou un outil en ligne. Ce type d’outil va parcourir toutes les URL comme le ferait un moteur de recherche. Vous pourrez alors :

  • Trouver des pages en erreur ;
  • Voir si certaines URL sont manquantes ;
  • Découvrir des contenus qui ne devraient pas exister ;
  • Ou encore voir si certains éléments de la page ont été modifiés à tort (balise Title, méta description, nombre de mots, balise robots, etc.).

Il existe des dizaines et dizaines de solutions qui font cela. On peut notamment citer :

Vérifier les URL des logs

Trop peu souvent utilisés, les logs serveurs ont une vraie utilité.

De quoi s’agit-il ? Tous les hébergeurs enregistrent tout ce qui se passe sur leurs serveurs, souvent sur une période de 7 à 14 jours. Ainsi, toute visite d’un humain comme celle d’un robot est notée, que ce soit sur les contenus HTML ou sur les images et autres ressources.

Si vous y avez accès, il est ainsi fortement recommandé de les analyser. Vous pourriez ainsi :

  • Après la remise en ligne, vérifier si toutes les URL présentes dans les logs sont correctes et ne renvoient pas d’erreur ;
  • Avant la mise en ligne, pouvoir lister (ou détecter) les URL posant problème.

Là encore, il existe de nombreux outils, comme Screaming Log File Analyzer : https://www.screamingfrog.co.uk/log-file-analyser/.

Un exemple d’analyse de logs avec Screaming Log File Analyzer

Les messages de la Search Console

Cette méthode est assez simple et connue : les centres pour webmasters de Google et des autres moteurs de recherche indiquent en effet quand ils découvrent des problématiques techniques.

Après une remise en état, vous devez impérativement contrôler dans les jours qui suivent les différents menus pour voir si les éléments néfastes ont été corrigés, et si de nouveaux éléments posant problèmes sont apparus ou non.

On conseille ainsi de contrôler les différentes sections de la Search Console pendant au moins 2 à 3 semaines après la remise en ligne du site.

Les outils en ligne

Bien entendu, il existe également de nombreux outils en ligne dédiés à différents aspects d’un site. En les utilisant, on s’assure ainsi qu’aucune problématique technique ne perdure après correction. Le gros avantage est que vous pouvez faire un test immédiat sans attendre une remontée d’information de la part de la Search Console de Google. Notez aussi que les outils de tests de Google permettent en plus de voir presque exactement le contenu tel que le moteur de recherche le voit, ce qui est particulièrement utile en cas de contenu cloaké par un piratage (vous voyez votre contenu habituel mais Google en voit un autre).

On peut notamment citer les outils suivants :

Anticiper les erreurs

Dans le meilleur des mondes, il faut éviter de rencontrer le problème technique. Dans une stratégie web et dans une stratégie SEO également, l’anticipation technique est un élément indispensable à mettre en place.

Backups, backups et backups

La première chose à faire, dès la création de son site, est de s’assurer d’avoir des sauvegardes régulières. Cela inclut la base de données d’une part, et l’intégralité des fichiers d’autre part (ceux du CMS, les images, les vidéos, etc.).

L’objectif est simple : en cas de problème technique, vous devez toujours être capable d’utiliser une sauvegarde récente pour remettre en ligne le site.

Théoriquement, on pourrait être tenté de ne faire appel qu’aux sauvegardes automatiques de l’hébergeur, mais cela pose plusieurs problèmes :

  • Tous les hébergeurs ne font pas de sauvegardes (nous en avons connu certains sans aucune option correspondante) ;
  • Les sauvegardes sont souvent proches physiquement du serveur web : dans le cas d’un incendie comme OVH, les sauvegardes ne servent à rien puisqu’elles seront endommagées en même temps que le reste du site web ;
  • Elles se font sur un temps court, souvent les 7 ou 14 derniers jours. Hors parfois, il est utile de revenir plus longtemps en arrière (par exemple lors de la détection trop tardive d’un piratage).

Pensez aussi ponctuellement à vérifier que vos sauvegardes fonctionnent toujours : si vous les avez mises en place l’année dernière, il est possible que cette protection ne fonctionne plus à cause d’un problème technique, et donc que vous n’ayez plus aucune sauvegarde récente.

Mettre en place un monitoring

C’est le second point important : utilisez toujours un outil de monitoring, voir même plusieurs. L’idéal, c’est d’en avoir un dédié au serveur et nom de domaine, et un second au niveau du CMS. Le but est simple : recevoir des alertes automatiquement et bien plus vite pour chaque nouvelle problématique rencontrée.

Là encore, il existe de nombreuses solutions. On peut notamment citer :

Sécuriser et maintenir

Bien entendu, une partie des problèmes techniques vient de problèmes de sécurité ou d’un manque cruel de maintenance : pensez à appliquer toutes les bonnes pratiques web, car cela évite en règle générale un très grand nombre de problématiques techniques (piratage, erreurs PHP, etc.).

Pour cela, pensez à :

  • Protéger les différentes accès avec des logins et mots de passés sécurisés et différents (Administration du site, accès hébergeur, accès FTP, base de données, etc.) ;
  • Utiliser des ordinateurs toujours à jour et avec un antivirus ;
  • Garder à jour votre serveur (version de PHP, d’Apache, de SQL, etc.) ;
  • Garder à jour votre site (Mise à jour majeures du CMS, extensions, etc.) ;
  • Vérifier régulièrement l’espace disque disponible ainsi que l’espace restant dans la base de données ;
  • Mesurez si possible les pics de trafic.

Améliorer les performances

Dernier point qui permet d’anticiper : mettez l’accent sur le temps de chargement de votre site. Pourquoi ? Car cela va réduire fortement tous les problèmes techniques liés à des surcharges serveurs ou à du code peu performant.

Ainsi, on essaiera d’appliquer toujours les bonnes pratiques suivantes :

  • Un code PHP récent et performant ;
  • Un bon hébergeur en termes de puissance (processeur, espace disque, base de données, mémoire vive) ;
  • Un rendu visuel pas trop gourmand (un seul fichier CSS, un seul fichier JavaScript, pas trop d’images, pas de vidéo en lecture automatique, etc.) ;
  • Pour les sites utilisant un CMS, un système de cache pour ne pas recalculer constamment chaque page est indispensable (le cache peut être géré via le CMS ou via le serveur).

Conclusion

Les problèmes techniques sont récurrents dans le Web. Et il n’existe aucun site au monde qui n’en rencontre jamais. L’impact sur le référencement naturel peut alors être bénin comme catastrophique.

Il existe ainsi deux règles d’or à respecter en tout temps : avoir des sauvegardes régulières accessibles et redondantes, et mettre en place un vrai monitoring de son site pour être alerté le plus vite possible d’une problématique technique.

A vous ensuite d’agir rapidement pour corriger les différentes erreurs rencontrées, et ainsi réduire ou supprimer tout effet négatif sur votre positionnement dans Google.

 

Daniel Roch, consultant WordPress, Référencement et Webmarketing chez SeoMix (https://www.seomix.fr)