Site disparu de Google : ce qu'il faut vérifier

D'abord, confirmez que le site a vraiment disparu

Cherchez l'URL exacte de votre page d'accueil, puis lancez site:example.com. Aucun résultat du tout pour l'un ou l'autre pointe vers une cause à l'échelle du site et la liste ci-dessous s'applique. Des résultats pour la page d'accueil mais pas pour une section pointent vers un seul modèle ou un seul chemin, ce qui réduit considérablement la recherche. Des résultats tous présents mais classés moins bien que le mois dernier est un problème différent : c'est un changement de classement, pas une désindexation, et aucune de ces étapes n'y remédie.

1. Vérifiez une action manuelle

Search Console, Sécurité et actions manuelles, Actions manuelles. Une action manuelle signifie qu'un évaluateur humain a appliqué une pénalité, et elle nomme la raison et la portée. Rien d'autre dans cette liste ne corrigera un site qui en porte une. Le chemin du retour consiste à corriger ce que décrit l'avis et à soumettre une demande de réexamen, ce qui prend des jours à des semaines. Ceci est en premier dans la liste car c'est un seul clic et cela rend les six autres points sans objet.

2. Vérifiez le noindex

La cause la plus fréquente de la disparition d'un site entier sans que rien ne semble cassé :

curl -sI https://example.com/ | grep -i x-robots-tag
curl -s https://example.com/ | grep -i 'name="robots"'

Si l'une ou l'autre commande affiche noindex, vous avez votre réponse. Vérifiez une page de chaque modèle majeur, pas seulement la page d'accueil, car la fuite est souvent confinée à une seule route. Le mécanisme et les façons habituelles dont cela arrive sont couverts dans ce que fait noindex.

3. Vérifiez robots.txt

Ouvrez https://example.com/robots.txt. Un Disallow: / sous User-agent: * bloque l'exploration de tout le site. Confirmez aussi que le fichier lui-même renvoie 200 : un 5xx persistant sur robots.txt peut faire mettre en pause l'exploration de l'hôte par Google même si chaque page de ce dernier va bien. Les règles et les pièges sont dans comment vérifier robots.txt.

4. Vérifiez l'URL canonique

curl -s https://example.com/ | grep -i 'rel="canonical"'

Si l'URL canonique nomme un hôte de préproduction, un domaine de développement ou toute URL qui n'est pas la page que vous avez récupérée, chaque page demande à être repliée ailleurs. C'est une URL canonique pointant vers la préproduction, et cela produit exactement ce symptôme pendant que le site continue de renvoyer 200.

5. Vérifiez si le site est piraté ou sur liste noire

Un site compromis est souvent retiré des résultats avant que son propriétaire ne remarque quoi que ce soit. Regardez d'abord le rapport Problèmes de sécurité de Search Console, puis vérifiez les listes de réputation depuis l'extérieur : la vérification gratuite Web Risk indique si les propres listes de logiciels malveillants et de phishing de Google signalent actuellement votre URL, et la vérification gratuite de liste noire couvre les listes noires DNS qui affectent aussi la livraison de votre courrier. Un signalement sur l'une ou l'autre signifie que trouver et retirer le contenu injecté passe avant tout le reste, car un réexamen ne sera pas validé tant que le site est encore compromis.

6. Vérifiez les erreurs serveur

Les pages qui renvoient un 5xx ou qui expirent pour le robot d'exploration sont abandonnées, et un serveur qui échoue seulement sous la charge des robots d'exploration paraît parfaitement sain dans un navigateur. Vérifiez le rapport de statistiques d'exploration dans Search Console pour un pic de requêtes échouées, et confirmez le code de statut que votre site renvoie depuis plusieurs réseaux, car des règles de protection anti-robots qui répondent 403 aux plages d'adresses de centres de données sont invisibles depuis un navigateur normal.

7. Vérifiez que le domaine n'a pas expiré

L'échec auquel personne ne s'attend, car il met le site hors service complètement et silencieusement : un domaine qui a expiré au renouvellement, ou un enregistrement DNS qui a été retiré avec lui. La recherche WHOIS gratuite montre les dates d'enregistrement et d'expiration ainsi que les serveurs de noms actuels. Une date d'expiration dans le passé, ou des serveurs de noms qui ne sont pas les vôtres, explique tout ce qui précède dans cette liste.

Pourquoi cette liste est longue

Chaque cause ici, sauf l'action manuelle, produit un site qui se charge correctement, renvoie 200 et passe une vérification d'uptime ordinaire, ce qui explique pourquoi le premier signal est en général un graphique de trafic une semaine après que le changement a été déployé. Effectuer ces vérifications à la main les détecte une fois. L'outil gratuit d'exploration de site couvre la moitié sur-page de la liste en un seul passage sur chaque page, plutôt que sur les deux ou trois que vous avez pensé à tester. Pour détecter le prochain le jour même de sa mise en ligne, l'option Indexability d'un moniteur HTTP HostTracker lit les directives noindex et le canonique de vos pages clés à chaque vérification et envoie une notification quand l'un des deux change - le monitoring SEO montre comment cela fonctionne aux côtés des vérifications d'uptime, de certificat et d'expiration de domaine.