Google ne note pas votre hébergeur, il mesure ce qu'il renvoie
Posons le décor tout de suite : il n'existe aucun critère « type d'hébergement » dans l'algorithme. Googlebot ne sait ni ce que vous payez ni chez qui. Il envoie une requête HTTP, il reçoit un code de réponse et un contenu, et il note le temps que tout ça a pris. Point.
L'hébergement joue donc de façon indirecte, par deux canaux. Le premier, c'est l'exploration. Google ajuste le nombre de connexions qu'il s'autorise sur votre serveur en fonction de sa santé : s'il répond vite et de façon stable, la limite monte. S'il ralentit ou renvoie des erreurs serveur, elle baisse, et Google explore moins. C'est écrit tel quel dans sa documentation sur le budget d'exploration. Pour un site de cinquante pages, ça ne change à peu près rien. Pour une série de sites logés au même endroit, ça commence à compter (voir mon article sur la définition du budget de crawl et les cas où son optimisation vaut le coup).
Le second canal, c'est l'expérience des visiteurs. Le temps de réponse du serveur, le fameux TTFB, n'est pas un Core Web Vital, mais il précède tout le reste : un serveur qui met deux secondes à livrer le HTML a très peu de chances d'afficher le contenu principal dans le délai que Google juge bon. Le site web.dev, édité par Google, conseille de viser 0,8 seconde ou moins. Gardez quand même les proportions en tête : un serveur rapide n'a jamais fait monter une page médiocre.
Le mutualisé : largement suffisant, jusqu'au jour où il ne l'est plus
Sur un mutualisé, vous partagez un serveur (processeur, mémoire, disque) avec beaucoup d'autres clients. L'hébergeur s'occupe de tout : mises à jour, sécurité, sauvegardes. Pour un site vitrine ou un blog WordPress doté d'un cache de pages correct, c'est très bien. J'ai vu des sites au trafic honorable tenir sans broncher sur des offres d'entrée de gamme, parce que PHP n'y travaillait presque jamais.
Les ennuis arrivent par trois portes. Les voisins d'abord : quand un autre site du serveur s'emballe, vos temps de réponse en pâtissent, et vous n'y pouvez rien. Les plafonds ensuite : nombre de processus PHP simultanés, mémoire, temps d'exécution. Dès que vous les touchez (un pic de visites, un robot un peu agressif, une extension gourmande), le serveur répond par des erreurs 503. Là, on quitte le confort pour entrer dans un vrai sujet SEO, celui de l'impact des erreurs 500 et 503 sur le référencement dans Google.
La troisième porte concerne directement l'éditeur qui monte en volume : l'empilement. Dix ou vingt sites sur le même compte mutualisé, ce sont dix ou vingt sites qui se partagent un seul quota. Il suffit que Googlebot décide d'explorer sérieusement l'un d'eux, ou qu'une tâche planifiée se déclenche partout à la même heure, pour que tous ralentissent ensemble.
Le VPS : des ressources à vous, et un serveur à tenir
Un VPS vous réserve une part fixe de mémoire et de processeur. Personne ne vient la grignoter. Vous choisissez aussi la configuration : version de PHP, cache serveur, compression, réglages de la base de données. C'est cette maîtrise, plus que la puissance brute, qui fait baisser le temps de réponse.
La contrepartie tient en une phrase : l'administrateur, c'est vous. Mises à jour de sécurité, pare-feu, sauvegardes, surveillance, renouvellement des certificats. Un VPS livré nu, avec une base de données aux réglages par défaut et aucun cache, est plus lent qu'un bon mutualisé. Je retrouve ça régulièrement en audit : on a migré « pour le SEO », et le temps de réponse a empiré. Si vous n'avez jamais ouvert un terminal, regardez plutôt du côté des VPS infogérés, plus chers, mais où l'hébergeur garde la main sur le système.
Mutualisé contre VPS, critère par critère
Si je ramène le comparatif à ce qui compte pour Google et pour vos visiteurs :
- Temps de réponse : comparable tant que les pages sortent du cache. Le VPS prend l'avantage sur les pages dynamiques (recherche interne, panier, back-office) et sous charge.
- Stabilité : le mutualisé dépend de ses voisins et de ses plafonds, le VPS dépend de vous. Dans les deux cas, ce sont les erreurs 5xx et les lenteurs répétées qui finissent par réduire l'exploration.
- Exploration par Googlebot : aucune différence pour un petit site. Sur un gros volume de pages, un serveur stable laisse Google accélérer.
- Administration : quasi nulle sur un mutualisé, bien réelle sur un VPS, à la mise en place puis dans la durée.
- Coût : un mutualisé se loue quelques euros par mois, un VPS d'entrée de gamme guère plus. Rapporté au nombre de sites hébergés, le VPS devient vite le moins cher des deux, à condition de compter votre temps.
Vous le voyez, aucune ligne ne dit « Google préfère ». La question utile est ailleurs : votre hébergement actuel produit-il des symptômes ?
Votre hébergement vous freine-t-il ? Trois vérifications
Avant de sortir la carte bancaire, regardez les données. Dans la Search Console, ouvrez Paramètres puis Statistiques sur l'exploration. Deux éléments m'intéressent : l'état de l'hôte, qui signale les problèmes de disponibilité rencontrés par Googlebot, et la courbe du temps de réponse moyen. Pas la valeur d'un jour donné, la tendance. Une courbe qui grimpe à mesure que vous ajoutez des sites sur le compte, voilà le signal.
Deuxième vérification, les codes de réponse. Le même rapport ventile les requêtes de Googlebot par type de réponse et montre la part d'erreurs serveur. Avec les logs bruts, c'est encore mieux : vous voyez à quelles heures elles tombent.
Troisième vérification, les données de terrain de PageSpeed Insights, qui affichent le TTFB mesuré chez de vrais utilisateurs quand le site reçoit assez de visites.
Si ces trois indicateurs sont au vert, changer d'hébergement ne changera rien pour Google, et votre budget sera mieux employé ailleurs. S'ils virent à l'orange, commencez par le moins cher : un cache de pages bien réglé suffit souvent à régler le problème sans déménager.
Et le déménagement lui-même, c'est risqué ?
Beaucoup moins qu'on le croit. Changer d'hébergeur en gardant les mêmes URL, c'est changer une adresse IP derrière un nom de domaine. Google décrit la marche à suivre dans sa page sur le changement d'hébergement sans modification d'URL : abaisser la durée de vie (TTL) des enregistrements DNS au moins une semaine avant, copier le site à l'identique sur le nouveau serveur, basculer le DNS, puis laisser l'ancien serveur allumé tant qu'il reçoit encore du trafic.
Attendez-vous à voir l'exploration baisser juste après la bascule, puis remonter dans les jours qui suivent. C'est normal. Les vrais accidents viennent d'ailleurs. Un certificat HTTPS oublié, un robots.txt de préproduction resté en place, des redirections qui n'ont pas suivi. Bref, tout ce qu'on surveille dans une migration de site web menée sans perdre son SEO. Et si vous gérez plusieurs sites, déménagez-les un par un, en commençant par le moins important.