Votre hébergement est saturé ?

Votre site dépasse les ressources allouées par l’hébergeur : processeur, mémoire ou nombre de processus.

Sauvegardes et journaux stockés sur le serveur, boîtes e-mail volumineuses, fichiers de cache ou trop de fichiers.

Oui : robots agressifs et attaques sur la page de connexion consomment beaucoup de ressources.

Seulement si, après nettoyage et filtrage des robots, les ressources restent insuffisantes.

Cela dépend de l’extension. Pour un .be, DNS Belgium place le domaine en quarantaine pendant 40 jours : seul l’ancien titulaire peut le réactiver, via son registraire. Pour un .fr, la période de rédemption est de 30 jours. Pour un .com, le registraire accorde souvent une période de grâce, suivie d’une période de restauration de 30 jours, plus coûteuse. Pour les autres extensions (.lu, .ch…), les délais sont propres à chaque registre : vérifiez-les auprès de votre registraire.

L’adresse de contact du domaine est souvent celle d’un ancien prestataire ou une boîte qui n’est plus consultée, le renouvellement automatique est désactivé ou la carte enregistrée a expiré.

Pas toujours. S’il reprend votre marque et qu’il est utilisé de mauvaise foi, des procédures de litige existent : UDRP pour les .com, CEPANI pour les .be. Elles relèvent du juridique ; nous vous aidons à rassembler les éléments techniques.

Souvent quelques minutes, parfois jusqu’à 48 heures : les serveurs du monde entier mettent à jour leurs informations selon la durée de cache (TTL) des enregistrements DNS.

Via le WHOIS de l’extension (par exemple sur le site de DNS Belgium pour un .be) ou dans l’espace client de votre registraire.

Trois enregistrements DNS qui authentifient vos e-mails. SPF liste les serveurs autorisés à envoyer pour votre domaine (un seul enregistrement, 10 recherches DNS maximum). DKIM signe chaque message avec une clé dont la partie publique est publiée dans vos DNS. DMARC indique quoi faire des messages qui échouent à ces contrôles et vous envoie des rapports.

Oui. Depuis février 2024, tout expéditeur doit authentifier ses messages avec SPF ou DKIM. Au-delà de 5 000 messages par jour vers Gmail, SPF, DKIM et DMARC sont tous les trois exigés, avec un lien de désinscription en un clic et un taux de plaintes pour spam inférieur à 0,3 %.

Par une politique d’observation (p=none) avec réception des rapports, pour vérifier que tous vos outils d’envoi (messagerie, site, logiciel de facturation, newsletter) sont bien authentifiés. On passe ensuite progressivement à quarantine, puis reject.

Souvent parce qu’une boîte e-mail piratée a envoyé du spam, ou parce que vous partagez un serveur d’envoi avec d’autres expéditeurs peu scrupuleux. Nous vérifions les principales listes (comme Spamhaus), corrigeons la cause, puis demandons le retrait.

Les causes typiques : enregistrements MX modifiés lors d’une migration ou d’un changement de DNS, boîte pleine, ou domaine expiré.

Envoyez un message vers un outil de test comme mail-tester.com, ou lisez la ligne « Authentication-Results » dans les en-têtes d’un e-mail reçu : elle indique si SPF, DKIM et DMARC sont validés.

Les certificats gratuits Let’s Encrypt durent 90 jours et se renouvellent automatiquement. Le renouvellement échoue si les DNS pointent ailleurs, si la validation est bloquée par une règle du serveur ou si l’option a été désactivée.

C’est du contenu mixte : des images ou des scripts encore appelés en http://. Nous corrigeons les adresses dans la base de données et pouvons forcer leur chargement en https.

Oui : cela crée des doublons et expose les visiteurs. Il faut une redirection 301 permanente vers https et, idéalement, l’en-tête HSTS qui impose https au navigateur.

Le certificat ne couvre qu’une seule des deux versions. Il doit inclure le domaine nu et la version www.

Pas pour la grande majorité des sites. Les certificats payants à validation étendue n’affichent plus rien de particulier dans les navigateurs.

Erreur 508 « Resource Limit Is Reached », erreurs 503 répétées, e-mails rejetés pour boîte pleine, mises à jour impossibles faute d’espace.

Des sauvegardes stockées sur le serveur, des journaux, des fichiers de cache, des boîtes e-mail volumineuses, un nombre de fichiers trop élevé (limite d’inodes), et surtout des robots agressifs ou des attaques par force brute sur la page de connexion de WordPress.

Les journaux d’accès du serveur montrent les adresses IP et les signatures (user-agents) qui envoient le plus de requêtes. Nous les bloquons de façon ciblée, sans gêner Google ni vos visiteurs.

Seulement si, après nettoyage, externalisation des sauvegardes, mise en cache et filtrage des robots, les ressources restent insuffisantes.