Une panne nuit-elle au SEO ? Ce qui arrive vraiment au classement

Une panne nuit-elle au SEO ? Une interruption courte n'a presque jamais d'effet, mais une indisponibilité qui dure plusieurs jours peut réduire la fréquence à laquelle Google explore le site, puis finir par faire sortir des pages de l'index. Ce qui décide de l'issue, c'est la durée de l'indisponibilité et le code HTTP que renvoie le site pendant la panne.

Pour une agence, réparer la panne est en général le travail de quelqu'un d'autre : l'hébergeur, le développeur du client, son service informatique. La remarquer, c'est votre travail. Un site que Googlebot ne peut pas atteindre ne peut pas garder ses positions, et le client demandera pourquoi personne ne l'a vu.

Ce que dit la documentation de Google

La page de Google consacrée à l'effet des codes HTTP sur l'exploration est assez claire. Les erreurs serveur 5xx et le code 429 Too Many Requests poussent Googlebot à ralentir l'exploration du site. Les URL déjà indexées sont conservées un certain temps, mais si les erreurs persistent, elles finissent par être retirées. Les timeouts et les connexions refusées sont traités à peu près comme des erreurs serveur.

Pour une indisponibilité planifiée ou temporaire, la réponse recommandée est 503 Service Unavailable. Elle indique aux robots que le problème devrait être passager. Un en-tête Retry-After précise quand revenir, par exemple Retry-After: 3600 pour une heure.

Un détail passe facilement inaperçu. Si le fichier robots.txt lui-même renvoie une erreur serveur, la documentation de Google sur le robots.txt indique que l'exploration du site s'arrête, et si l'erreur dure longtemps, Google se rabat sur la dernière copie du fichier en cache. Une panne qui fait tomber tout l'hébergement emporte le robots.txt avec elle.

Combien de temps de panne avant que le SEO en souffre

Google ne publie aucun seuil : lisez ces fourchettes comme des ordres de grandeur, pas comme des règles.

Durée de la panne	Ce qui se passe en général
Quelques minutes	Googlebot ne demande peut-être rien. S'il le fait, il réessaie plus tard. Aucun effet mesurable sur le classement.
Quelques heures	L'exploration ralentit. Les pages restent indexées et, avec un 503 propre, le site récupère dès qu'il est stable.
Un jour ou plus de 5xx	Le rythme d'exploration baisse et certaines URL peuvent sortir de l'index. La plupart reviennent après le rétablissement, pas toujours à la même position.
Pannes courtes et fréquentes	Chacune est mineure, mais un hébergement qui lâche régulièrement peut maintenir Googlebot dans une exploration prudente.

Le code de statut compte autant que la durée

Deux sites en panne pendant les mêmes quatre heures peuvent en sortir de façon très différente.

Le premier renvoie un 503 avec Retry-After depuis son mode maintenance. Google le lit comme temporaire et attend. Le second affiche une sympathique page « Nous revenons bientôt » avec un 200 OK. Pour Googlebot, c'est une vraie page dont le contenu a été remplacé par une phrase, et si elle est explorée dans cet état, le texte de maintenance peut se retrouver dans l'extrait de recherche jusqu'au retour du vrai contenu.

Un 500 Internal Server Error ou un timeout se situe entre les deux. Il ne sera pas indexé comme contenu, mais il ne porte pas non plus le signal « c'est temporaire ».

WordPress fait ce qu'il faut par défaut. Pendant les mises à jour du cœur et des extensions, il crée un fichier .maintenance et affiche « Brièvement indisponible pour cause de maintenance programmée » avec un statut 503. Les extensions tierces de maintenance ou de page « bientôt disponible » ne se comportent pas toutes de la même façon : vérifiez celle qu'utilise le site d'un client avant une interruption planifiée.

Où les dégâts apparaissent dans la Search Console

Si vous pensez qu'une panne a déjà touché un client, deux rapports vous aideront. Le rapport « Statistiques sur l'exploration », dans les Paramètres, contient une section « État de l'hôte » qui couvre la récupération du robots.txt, la résolution DNS et la connectivité du serveur sur les 90 derniers jours, ainsi qu'une répartition des requêtes d'exploration par code de réponse. Le rapport « Indexation des pages » liste les URL sous « Erreur de serveur (5xx) » lorsque Google n'a pas réussi à les récupérer.

Les deux regardent en arrière. Ils expliquent ce qui s'est passé la semaine dernière, ce qui est utile pour un rapport client mais n'empêche rien. Pour une autre défaillance d'infrastructure qui ressemble à une panne aux yeux des visiteurs, voyez la surveillance de l'expiration des certificats SSL.

Être prévenu pendant que la panne est en cours

Imaginez la version coûteuse. Le site d'un client tombe un vendredi en fin de soirée, personne ne regarde, Googlebot et les acheteurs tombent sur des erreurs tout le week-end, et vous l'apprenez le lundi. Pour un client e-commerce, les ventes perdues du week-end peuvent peser plus lourd que n'importe quelle baisse de positions, et c'est vous qui expliquerez les deux. Vérifier à la main 5 ou 50 sites clients n'est pas réaliste : la seule solution tenable est un outil qui alerte en cas de panne. Notre comparatif alternative à UptimeRobot passe les options en revue.

La surveillance d'uptime de Deltio vous alerte sur Slack et par e-mail, site par site, quand un site client tombe. Elle détecte aussi quand une page a été remplacée par une page de maintenance, ce qui repère le cas du « bientôt de retour » en 200 OK qu'un simple contrôle en ligne/hors ligne considère comme sain. Comme le même compte compare chaque jour le noindex, le robots.txt et les URL du sitemap, vous voyez aussi si un site revient d'un incident avec ses réglages SEO modifiés.

Deltio n'analyse pas le budget de crawl et ne lit pas les logs serveur. Pour cela, il vous faut toujours la Search Console et les logs d'accès de l'hébergeur. La façon dont uptime et indexabilité s'articulent est détaillée dans uptime et surveillance SEO.