On entend parfois qu'il suffit de changer d'hébergeur pour « monter dans Google ». C'est faux, et nous préférons le dire d'emblée. Ce qui est vrai, c'est qu'un serveur mal tenu peut ruiner des mois de travail sur le contenu, et qu'un serveur bien tenu donne à ce travail toutes ses chances. Voici comment, concrètement.
01Ce que l'hébergeur ne fait pas
Google classe des pages pour leur pertinence : le contenu, la réponse apportée à la question posée, les liens qui pointent vers elles. Aucun hébergement, aussi rapide soit-il, ne fera remonter une page qui ne répond pas à la question. Le serveur n'apparaît dans aucun critère de classement sous son propre nom.
Mais Google mesure aussi l'expérience de la page, explore le site avec des robots qui ont une patience limitée, et retire de ses résultats les sites dangereux. Sur ces trois terrains, l'infrastructure n'est plus un détail : elle peut faire perdre ce que le contenu a gagné.
02La vitesse, mesurée par Google
Google mesure l'expérience réelle des visiteurs à travers trois indicateurs, les Core Web Vitals, collectés dans le navigateur Chrome :
| Indicateur | Ce qu'il mesure | Seuil « bon » | Part du serveur |
|---|---|---|---|
| LCP | Temps d'affichage du plus gros élément visible | 2,5 s ou moins | Forte : tout commence par la réponse du serveur |
| INP | Réactivité aux clics et saisies | 200 ms ou moins | Faible : surtout le JavaScript de la page |
| CLS | Stabilité visuelle pendant le chargement | 0,1 ou moins | Nulle : affaire de mise en page |
Le LCP dépend directement du temps de réponse du serveur (TTFB) : tant que le premier octet n'est pas arrivé, rien ne s'affiche. Les recommandations de Google visent un TTFB de 0,8 seconde au plus ; un site bien hébergé répond en 100 à 300 millisecondes.
Ce que l'exploitation du serveur règle, et que l'agence web ne peut pas régler seule :
- Le cache : cache d'opcodes PHP, cache objet (Redis), cache de pages. Une page WordPress servie depuis le cache répond dix à cinquante fois plus vite.
- PHP-FPM dimensionné : trop peu de processus, et les visiteurs font la queue ; trop, et le serveur manque de mémoire aux heures de pointe.
- HTTP/2 ou HTTP/3, compression Brotli ou gzip : moins d'allers-retours, moins d'octets.
- Une base de données entretenue : tables optimisées, requêtes lentes repérées dans les journaux et signalées au développeur.
- Un serveur proche des visiteurs : pour un public français, un hébergement en France gagne des dizaines de millisecondes sur chaque aller-retour.
03La disponibilité et l'exploration
Googlebot passe régulièrement sur votre site. S'il rencontre des erreurs serveur (codes 5xx) ou des délais d'attente, il ralentit son exploration pour ne pas aggraver la situation. Si les erreurs durent, les pages concernées finissent par sortir de l'index. Une panne de quelques minutes est sans conséquence ; des erreurs intermittentes pendant des semaines, que personne ne remarque parce que « le site marche quand on le teste », font des dégâts silencieux.
Pendant une intervention planifiée, le serveur doit répondre 503 avec un en-tête Retry-After, et non 200 avec une page « site en maintenance ». Le premier dit à Google de revenir plus tard ; le second lui fait indexer votre page de maintenance à la place de votre contenu.
La supervision externe, qui interroge le site toutes les minutes depuis l'extérieur, est le seul moyen de voir ces erreurs intermittentes. La Search Console les montre aussi, mais avec plusieurs jours de retard.
04Le piratage, pire ennemi du classement
C'est le scénario qui fait le plus de dégâts, et le plus fréquent sur les sites mal entretenus : un CMS ou une extension non mis à jour, une faille connue, et le site se retrouve à servir, à côté de vos pages, des milliers de pages de pharmacie en ligne ou de casino. Souvent invisibles pour vous, parfaitement visibles pour Google.
- Google affiche « Ce site a peut-être été piraté » sous vos résultats.
- Les navigateurs peuvent afficher un écran rouge d'avertissement avant d'entrer sur le site.
- Une action manuelle peut retirer tout ou partie du site de l'index.
- Après nettoyage, il faut demander un réexamen, puis attendre que la confiance revienne : des semaines, parfois des mois.
Une PME voit son trafic issu de Google chuter de 70 % en trois semaines. Le site s'affiche normalement, l'agence ne trouve rien dans le contenu. En réalité, une extension de formulaire non mise à jour depuis deux ans a permis d'injecter des milliers de pages en japonais, visibles seulement par les robots. Le nettoyage prend deux jours ; le retour aux positions précédentes, quatre mois. Une mise à jour appliquée à temps, ou une alerte sur la création de fichiers PHP inconnus, aurait suffi.
05Les détails de configuration qui coûtent
| Détail | Ce qui se passe s'il est mal réglé |
|---|---|
| Une seule adresse canonique | Le site répond sur http, https, avec et sans www : quatre copies du même contenu se partagent les signaux |
| Redirections 301 qui conservent le chemin | Une redirection mal écrite renvoie toutes les pages vers l'accueil : les liens entrants sont perdus |
| Certificat renouvelé à temps | Un certificat expiré affiche une alerte de sécurité plein écran : les visiteurs repartent, Google le remarque |
| robots.txt et sitemap | Un robots.txt de préproduction oublié en production interdit tout le site aux robots |
| En-têtes de sécurité (HSTS, CSP) | Pas un critère de classement, mais une protection directe contre l'injection de contenu |
| Pages d'erreur qui répondent 404 | Une page « introuvable » qui répond 200 crée des milliers de pages vides indexables |
Chacun de ces points se vérifie en quelques minutes et se règle une fois pour toutes. Le problème est qu'ils se dérèglent : une mise à jour, une migration, un changement de prestataire. D'où l'intérêt d'une vérification régulière plutôt que ponctuelle.
06Ce que l'infogérance change concrètement
Un serveur réglé pour votre site
Cache, PHP-FPM, compression et base de données ajustés à votre trafic réel, et revus quand il change.
Les erreurs vues avant Google
Supervision externe à la minute, alertes sur les 5xx, temps de réponse suivi dans la durée.
Les failles fermées à temps
Mises à jour du système, de PHP et du CMS suivies, blocage automatique des attaques, alerte sur les fichiers modifiés.
Les détails qui ne se dérèglent plus
Certificats, redirections, canonique et en-têtes vérifiés après chaque intervention.
07La liste de contrôle
- Mesurez le TTFB de vos pages principales, depuis la France et à plusieurs heures de la journée : sous 0,8 seconde, toujours.
- Consultez le rapport Core Web Vitals de la Search Console : il repose sur vos vrais visiteurs, pas sur un test de laboratoire.
- Vérifiez les redirections : http vers https, sans www vers www (ou l'inverse), en un seul saut et en conservant le chemin.
- Regardez le rapport d'exploration de la Search Console : la courbe des erreurs serveur doit être plate.
- Listez les extensions de votre CMS : chacune non mise à jour depuis plus de six mois est une question à poser.
- Notez la date d'expiration de votre certificat, et vérifiez qu'elle se renouvelle seule.
Générateur Nginx et Apache
Redirections, compression, cache et en-têtes de sécurité, prêts à coller.
Simulateur du coût d'une panne
Ce que coûte une journée de site indisponible, ou désindexé.
Un hébergement qui travaille pour votre référencement
Nous hébergeons et infogérons des sites en France, sur une infrastructure écoresponsable : cache, HTTP/2, certificats, supervision et correctifs compris. Votre agence travaille le contenu, nous tenons la salle des machines.