Le DNS de mon domaine .fr fonctionne-t-il correctement ?
Avant de toucher à l'hébergement, il faut écarter une panne DNS. Un domaine en .fr dépend d'enregistrements gérés chez le bureau d'enregistrement (OVH, Gandi, Ionos) qui pointent vers des serveurs de noms. Si l'enregistrement A, AAAA ou CNAME est absent, erroné, ou pointe encore vers un ancien hébergeur après une migration, les visiteurs chez Orange, Free ou SFR verront une erreur alors que le serveur web fonctionne normalement.
Lancez une recherche DNS et vérifiez que l'enregistrement A renvoie bien l'adresse IP attendue, et que les enregistrements NS correspondent à ceux affichés chez votre registrar. Après un changement de serveurs de noms, la propagation peut prendre plusieurs heures, et certains fournisseurs d'accès gardent une réponse en cache plus longtemps que d'autres.
Mon domaine pointe-t-il vers le bon serveur ?
Une fois le DNS résolu, encore faut-il vérifier qu'il pointe au bon endroit. Prenez l'adresse IP obtenue et consultez son hébergeur, son ASN et son pays. Si le site est censé être hébergé chez OVH ou un autre hébergeur français et que l'information IP montre un centre de données inconnu à l'étranger, cela révèle en général un enregistrement A obsolète, un serveur de test oublié encore actif, ou dans le pire des cas un domaine détourné.
Cette étape permet aussi de détecter un cas fréquent : le site s'affiche, mais il s'agit encore d'une ancienne version servie par le précédent hébergeur car le DNS n'a pas fini de basculer.
Quel code HTTP le serveur renvoie-t-il ?
Si le DNS et l'hébergement sont corrects, le problème vient de ce que le serveur renvoie. Un code 200 signifie que la page se charge mais qu'autre chose ralentit l'affichage, comme une requête de base de données ou un script bloquant. Une boucle de redirection 301 ou 302 vient souvent d'une règle dans le .htaccess ou d'un plugin mal configuré. Un 403 signifie que le serveur refuse de servir le fichier, en général à cause des droits ou d'un pare-feu. Un 404 signifie que le chemin demandé n'existe tout simplement pas.
Les erreurs côté serveur ont chacune leur signification propre : le 500 est une erreur applicative, le 502 signale en général que le reverse proxy n'a pas réussi à joindre le backend, le 503 pointe souvent vers un pool PHP-FPM saturé ou un mode maintenance resté activé, et le 504 signifie que le backend a mis trop de temps à répondre.
Que révèlent les en-têtes de réponse ?
Les en-têtes expliquent le comment derrière le code de statut. cache-control et expires indiquent si un navigateur ou un CDN sert une copie ancienne. cf-ray ou x-cache montrent si Cloudflare ou un autre CDN a traité la requête, utile quand une correction faite côté serveur ne semble pas s'appliquer chez les visiteurs. Un souci sur set-cookie peut casser silencieusement une page réservée aux comptes connectés, et l'absence de strict-transport-security sur un site censé forcer le HTTPS mérite d'être signalée aussi.
Collez les en-têtes bruts de la réponse et lisez chaque ligne expliquée en clair plutôt que de deviner leur sens.