Après un changement d'hébergement, une migration WordPress vers Next, un passage sur Vercel ou une bascule DNS, le site peut sembler parfaitement accessible dans le navigateur. C’est précisément le piège. Côté SEO, la vraie question commence souvent après la mise en ligne : Googlebot arrive-t-il bien sur les bonnes URLs, au bon rythme, avec les bons codes HTTP ?
Les logs serveur ne remplacent pas Search Console, mais ils ajoutent une couche que l'interface ne montre pas toujours : la date exacte de passage de Googlebot, les URLs demandées, les statuts renvoyés, les redirections, les erreurs et parfois les lenteurs. C'est ce que je regarderais pour distinguer une migration saine d'une migration qui “semble” saine.
Pourquoi les logs comptent après une migration
Une migration SEO ne se juge pas seulement au design, au score Lighthouse ou au fait que la home s'affiche. Je la juge aussi à la manière dont les robots retrouvent les anciennes URLs, découvrent les nouvelles, suivent les redirections et récupèrent les pages importantes sans tomber sur des erreurs.
Google recommande, pour un changement d'hébergement sans changement d'URL, de surveiller les logs de l'ancien et du nouveau serveur, d'utiliser plusieurs outils de vérification DNS publics et de suivre l'exploration dans Search Console. Cette recommandation paraît simple, mais elle évite beaucoup de faux diagnostics.
Par exemple, si votre ordinateur voit déjà le nouveau site mais que certains FAI ou certains robots tombent encore sur l'ancienne infrastructure, je ne conclurais pas trop vite à un problème de contenu. C'est parfois une propagation DNS, un cache, un proxy, une configuration de domaine ou une redirection incomplète.
Ce que Googlebot dit vraiment dans les logs
Un log serveur peut montrer qu'une URL a été demandée par Googlebot, à quelle heure, avec quel statut HTTP, quel user-agent et parfois quel temps de réponse. Ce n'est pas une preuve que la page est indexée, ni qu'elle rankera, mais c'est une preuve concrète que Googlebot a tenté de récupérer quelque chose.
Dans son article de mars 2026 sur le fonctionnement de Googlebot, Google rappelle que Googlebot n'est pas un programme unique isolé, mais un client de l'infrastructure de crawl de Google Search. C'est aussi dans ce contexte que la limite des 2 Mo par URL, hors PDF, a été clarifiée pour Googlebot.
Ici, ce point est déjà détaillé dans l'article sur la limite de Googlebot pour Google Search. Ici, je veux surtout montrer ce que les logs permettent de vérifier après une migration ou un changement d'hébergement.
Ancien serveur, nouveau serveur : quoi comparer
Quand vous changez seulement d'hébergement en gardant les mêmes URLs, je comparerais les logs des deux côtés pendant quelques jours. L'ancien serveur doit voir son trafic baisser. Le nouveau doit voir arriver les visiteurs, puis Googlebot, puis les autres robots utiles.
Si l'ancien serveur continue à recevoir beaucoup de requêtes Googlebot après la bascule, cela peut indiquer un DNS encore non propagé, un ancien record oublié, un proxy intermédiaire ou une partie du trafic qui ne passe pas encore par la nouvelle configuration. Si le nouveau serveur ne reçoit aucun Googlebot, il faut vérifier le robots.txt, les règles de firewall, le cache CDN, les entêtes, les redirections et la configuration HTTPS.
Quand la migration implique aussi des changements d'URL, la lecture devient plus stricte. Google conseille, dans sa documentation sur les migrations avec changement d'URL, de suivre les sitemaps, les erreurs de crawl et les requêtes Search Console pendant que les anciennes URLs diminuent et que les nouvelles prennent le relais.
Les codes HTTP à surveiller
Un peu de 404 n'est pas forcément dramatique après une migration. Certaines anciennes URLs inutiles, des fichiers inexistants ou des requêtes parasites peuvent naturellement répondre en 404. Je m'inquiéterais surtout quand des pages qui avaient de la valeur, des backlinks, du trafic ou un rôle de maillage répondent soudain en erreur.
Les 500 et 503 demandent une lecture plus urgente. Googlebot peut réduire son rythme s'il rencontre des problèmes de disponibilité ou de capacité serveur. La documentation Google sur les erreurs de crawl recommande notamment d'utiliser le rapport de statistiques d'exploration, l'inspection d'URL et les logs pour relier les erreurs à des URLs concrètes.
Point important : ne transformez pas une maintenance, un rate limit ou une panne en faux 200. Une page d'erreur qui répond 200 peut être plus confuse qu'une erreur claire, car elle brouille le signal envoyé aux moteurs et aux outils d'audit.
Pour les sites très dépendants de JavaScript, le sujet se complique encore. Google explique dans son guide JavaScript SEO que les pages en 200 peuvent partir dans la file de rendu, alors qu'un statut non-200 peut faire sauter cette étape. L’article sur JavaScript et les pages non-200 complète donc bien cette vérification.
Crawl rate, capacité serveur et Search Console
Après un changement d'hébergement, une variation temporaire du rythme de crawl n'est pas forcément inquiétante. Google indique qu'il est normal de voir une baisse temporaire de la fréquence de crawl après un changement d'infrastructure, suivie d'une remontée progressive si le nouveau serveur répond correctement.
Le piège serait d'interpréter chaque baisse comme une sanction. Dans la pratique, je regarderais la tendance, les erreurs, les temps de réponse, les URLs touchées et le contexte. Si le site vient de changer d’architecture, de DNS, de CDN et de template en même temps, Googlebot doit redécouvrir une partie du terrain.
La page Google sur le dépannage des erreurs de crawl rappelle aussi que Search Console ne donne pas un historique de crawl filtrable par URL ou chemin. Pour savoir si une URL précise a été demandée par Googlebot, les logs restent donc utiles. Pour savoir si elle est indexée, il faut croiser avec l'inspection d'URL, la recherche Google et les rapports Search Console.
Checklist post-migration
| Moment | Ce qu'il faut regarder | Signal rassurant | Signal à corriger |
|---|---|---|---|
| J0 | DNS, HTTPS, home, robots.txt, sitemap, anciennes URLs majeures, redirections. | Le site répond, les anciennes URLs stratégiques redirigent, le sitemap liste les bonnes URLs. | NXDOMAIN, certificat cassé, robots.txt bloquant, anciennes pages importantes en 404. |
| J+1 | Logs ancien/nouveau serveur, premières requêtes Googlebot, erreurs 4xx/5xx répétées. | Le trafic bascule vers le nouveau serveur et Googlebot commence à demander les nouvelles pages. | Googlebot reste surtout sur l'ancien serveur ou reçoit des 500/503 sur des pages utiles. |
| J+3 | Search Console, sitemap, erreurs de crawl, URLs découvertes mais non explorées. | Les nouvelles URLs apparaissent progressivement et les erreurs restent limitées. | Le sitemap liste des URLs futures, redirigées, bloquées ou incohérentes. |
| J+7 | Courbe de crawl, pages stratégiques, backlinks importants, catégories et anciens slugs. | Les pages qui comptent sont demandées, répondent en 200 ou redirigent proprement. | Les URLs à backlinks restent en erreur ou les redirections forment des chaînes trop longues. |
| J+30 | Trafic, impressions, logs résiduels sur l'ancien hébergement, pages orphelines. | L'ancien serveur ne reçoit plus de trafic utile et les nouvelles URLs ont pris le relais. | Des anciennes URLs vivantes, des erreurs persistantes ou des pertes sur les pages qui rankaient. |
Cas Next, Vercel, CDN et cache
Sur une architecture moderne, les logs ne sont pas toujours au même endroit qu'avec un hébergement classique. Selon l'architecture, je regarderais les logs Vercel, les logs du CDN, les analytics serveur, les traces de redirection, les erreurs de fonctions et les caches. Le but reste le même : vérifier ce que le serveur ou la plateforme a réellement renvoyé à Googlebot.
Ce point rejoint le guide sur la migration WordPress vers Next/Vercel. Une reconstruction peut garder les textes et les URLs, mais changer complètement la manière dont les pages sont servies, mises en cache, redirigées ou listées dans le sitemap.
Il rejoint aussi le sujet des publications programmées et du maillage différé sur Next. Si un article est programmé, il ne doit pas apparaître trop tôt dans le sitemap ou les archives. Si une page sort, elle doit recevoir ses liens seulement quand elle répond réellement en 200.
Les erreurs à éviter
La première erreur est de ne regarder que le navigateur. Votre page peut être visible pour vous et mal servie aux robots à cause d'un cache, d'un user-agent bloqué, d'un ancien DNS ou d'une règle CDN trop agressive.
La deuxième erreur est de ne regarder que Search Console. L'outil est indispensable, mais il ne donne pas toujours l'heure précise de chaque passage de Googlebot sur chaque URL. Pour les cas fins, les logs restent la preuve terrain.
La troisième erreur est de croire qu'une migration est terminée le jour du déploiement. En SEO, la migration continue tant que les anciennes URLs utiles ne sont pas correctement traitées, que les nouvelles pages ne sont pas découvertes, et que les erreurs importantes ne sont pas stabilisées.
Verdict ToolsBoxSEO
Après une migration, les logs serveur servent surtout à calmer le diagnostic. J'aime bien les regarder parce qu'ils évitent de confondre une propagation DNS avec une perte SEO, une variation normale de crawl avec une sanction, ou une page visible dans le navigateur avec une page bien récupérée par Googlebot.
La bonne méthode reste simple : garder les anciennes traces quelques jours, vérifier les nouvelles, suivre les statuts HTTP, surveiller les redirections, contrôler le sitemap, regarder Search Console, puis corriger les erreurs qui touchent les pages réellement importantes.
Mon avis : les logs ne sont pas un luxe réservé aux très gros sites. Même sur un blog ou un site éditorial, ils deviennent très utiles après une refonte technique, une bascule d'hébergement, une panne DNS ou une reconstruction complète. Ce n'est pas glamour, mais c'est souvent là que la migration se gagne.
FAQ
Faut-il analyser les logs après chaque migration SEO ?
Oui, au moins de façon légère. Après une migration, je regarderais les logs pour voir si Googlebot arrive bien sur le nouveau site, quelles URLs il demande et quels statuts HTTP il reçoit.
Une baisse de crawl après changement d'hébergement est-elle grave ?
Pas forcément. Google indique qu'une baisse temporaire peut arriver après un changement d'infrastructure, puis remonter si le nouveau serveur répond correctement. Ce sont les erreurs répétées et les pages importantes non explorées qui doivent inquiéter.
Search Console suffit-elle pour suivre Googlebot ?
Non. Search Console est indispensable, mais les logs serveur donnent une lecture plus directe des requêtes reçues, des statuts renvoyés et des URLs demandées à un moment précis.
Quels codes HTTP surveiller en priorité ?
Je surveillerais surtout les 404 sur anciennes pages utiles, les 500, les 503, les 429, les longues chaînes de redirection et les pages d'erreur qui répondent à tort en 200.
Combien de temps garder l'ancien hébergement après migration ?
Je le garderais le temps de vérifier que le trafic utile et Googlebot ne passent plus par l'ancien serveur. Google recommande de surveiller les logs des deux côtés jusqu'à ce que le trafic de l'ancien hébergement tombe à zéro.
Les logs prouvent-ils qu'une page est indexée ?
Non. Les logs prouvent qu'une URL a été demandée et comment le serveur a répondu. L'indexation doit être vérifiée avec Search Console, l'inspection d'URL et les résultats de recherche.