Ce que fait Googlebot quand il tombe sur un 500 ou un 503
Commençons par la mauvaise nouvelle pour ceux qui cherchent un chiffre : il n'existe pas de compte à rebours officiel. Google n'a jamais écrit « au bout de X jours d'erreur, on désindexe ». En revanche, la mécanique est documentée, et elle est plutôt rassurante.
Quand Googlebot reçoit un code 5xx, il fait trois choses, décrites noir sur blanc dans la documentation Search Central sur les codes HTTP. Il ignore le contenu renvoyé avec l'erreur. Il ralentit l'exploration du site, d'autant plus fort que le nombre d'URL en erreur est élevé. Et il conserve les pages déjà indexées, qui ne sortent de l'index que si le problème dure.
Autrement dit, une erreur serveur n'est pas une porte qui claque. C'est un « repasse plus tard », et Google le prend comme tel. Dès que le serveur répond de nouveau normalement, le robot remonte son rythme de passage. Progressivement, j'insiste : il ne revient pas à plein régime le lendemain matin.
Quelques heures, deux jours, une semaine : l'échelle du risque
Faute de chiffre officiel, voici comment je lis la situation, doc de Google et logs de sites en panne à l'appui.
- Quelques minutes à quelques heures : aucun effet mesurable dans l'immense majorité des cas. Une coupure nocturne ne fait pas bouger vos positions.
- Un à deux jours : c'est la durée que Google cite lui-même, dans sa page consacrée à la mise en pause d'un site, comme acceptable pour couper un site en urgence avec un 503. Au-delà, il prévient que les effets sur la recherche peuvent être importants.
- Plusieurs jours d'affilée : les premières URL commencent à décrocher. Souvent celles que Googlebot visite le plus, tout simplement parce qu'il les teste plus souvent et accumule les échecs plus vite.
- Une semaine et plus : le retrait peut devenir massif, et le retour n'a rien d'instantané. Google précise d'ailleurs qu'après un retrait complet, il n'existe aucun délai garanti pour retrouver sa place.
Ces paliers ne sont pas des seuils gravés dans le marbre. Un gros site crawlé en permanence verra les effets plus vite qu'un petit blog que Googlebot visite quelques fois par semaine.
Un site qui tombe souvent : le coût qu'on ne voit pas
Revenons à votre cas : des coupures à répétition. Là, franchement, la désindexation n'est pas le premier risque.
Chaque série d'erreurs 5xx pousse Google à réduire son rythme d'exploration. Si les pannes reviennent toutes les semaines, le robot n'a jamais le temps de retrouver son niveau normal. Résultat : vos nouveaux articles sont découverts plus tard, vos mises à jour sont prises en compte en retard, et sur un site de plusieurs milliers de pages, certaines zones profondes ne sont presque plus visitées. C'est exactement ce que j'explique quand je détaille ce qu'est le budget de crawl et comment l'optimiser : la santé du serveur fait partie de l'équation, au même titre que la structure du site.
Et puis il y a les visiteurs. Un internaute qui clique depuis Google et tombe sur une page d'erreur repart aussitôt. Si ça se répète, vous perdez des clients, et la note est souvent plus salée là que du côté de Google.
Un site qui tombe régulièrement ne se fait pas sanctionner par Google : il se fait oublier, petit à petit.
500 ou 503 : même traitement, pas le même message
Côté Google, les deux codes rentrent dans la même case. Erreur serveur, on ralentit, on garde l'index un moment. La différence tient à ce que vous dites au robot.
Le 500 signifie « quelque chose a planté » : une erreur PHP, une base de données saturée, une extension qui casse tout. C'est un accident. Le 503 veut dire « service temporairement indisponible », et c'est le code à renvoyer volontairement pendant une maintenance, une migration ou un pic de charge. Vous pouvez y ajouter un en-tête Retry-After qui suggère quand repasser. Utile, mais ne comptez pas sur lui pour piloter Googlebot à la minute près.
Et surtout, ne confondez pas avec le 404. Lui annonce que la page n'existe plus, et l'URL sort de l'index bien plus vite qu'avec une erreur serveur. Si le sujet vous travaille, j'ai fait le point sur la gravité réelle d'une erreur 404 pour le SEO.
Les erreurs qui transforment une panne banale en vraie casse
Dans les audits, ce n'est presque jamais la panne qui fait les dégâts, c'est la façon dont elle est gérée.
- Le robots.txt qui répond en 5xx. Le piège le plus méconnu. Si Googlebot ne peut pas lire ce fichier à cause d'une erreur serveur, il cesse d'explorer tout le site pendant les 12 premières heures, puis se rabat sur la dernière version valide pendant 30 jours, d'après les spécifications publiées par Google. Il déconseille d'ailleurs explicitement de servir un 503 sur ce fichier, même pendant une maintenance.
- La page de maintenance servie en 200. Le plugin affiche « site en travaux », mais le serveur répond « tout va bien ». Google peut alors prendre ce message pour le contenu réel de vos pages. Avec un 503, ce contenu est ignoré. Avec un 200, il ne l'est pas.
- Le serveur qui ne répond plus du tout. Délais d'attente dépassés, connexions coupées, DNS en panne : pour Google, ce n'est pas mieux qu'un 500. Ces erreurs réseau sont traitées comme des erreurs serveur, avec les mêmes conséquences.
Après une panne : vérifier les dégâts et accélérer le retour
Premier réflexe : la Search Console. Dans les paramètres, le rapport Statistiques sur l'exploration affiche un bloc « État de l'hôte » qui signale les soucis de récupération du robots.txt, de résolution DNS et de connectivité du serveur. Vous y voyez aussi la courbe des requêtes de Googlebot. Si elle s'est effondrée pendant la panne, vous savez qu'il a levé le pied.
Ensuite, le rapport Indexation des pages, et le motif « Erreur de serveur (5xx) ». S'il gonfle, ce sont des URL que Google a testées pendant la coupure. Pour les pages qui comptent vraiment (vos meilleures pages de trafic, vos pages qui vendent), passez-les dans l'outil d'inspection d'URL et demandez une indexation une fois le site rétabli. Inutile de le faire pour des milliers d'adresses : Googlebot reviendra de lui-même.
La source la plus fiable reste les logs. Ils vous disent à la minute près quand Googlebot est passé, sur quelles URL, et quel code il a reçu. C'est le seul moyen de savoir si la panne l'a vraiment touché ou si elle est passée entre deux visites. Si vous n'avez jamais fait l'exercice, voici comment analyser les logs de votre serveur dans une optique SEO.
Dernier point, et pas le moindre : installez un monitoring de disponibilité qui vous alerte dès que le site ne répond plus. Une panne découverte le lundi matin alors qu'elle a commencé le vendredi soir, c'est déjà deux jours et demi d'erreurs. Et si les coupures reviennent sans cesse, le problème n'est pas SEO : c'est l'hébergement, et c'est lui qu'il faut changer.