Yandex décrit son propre processus en quatre étapes, et savoir à quelle étape appartient un problème permet de transformer une vague plainte en un problème résoluble.
Étape 1 — le crawl
Le robot décide quels sites crawler, à quelle fréquence et combien de pages. Sa liste de pages connues provient des liens internes et externes, du sitemap, des données de Yandex Metrica et de robots.txt. Les pages de plus de 10 Mo ne sont pas indexées.
La gestion des réponses est explicite :
200 OK— crawlée.3XX— le robot crawle la cible de la redirection.4XXet5XX— la page n’est pas incluse, et est supprimée si elle était déjà dans la recherche.
Et l’astuce utile qui suit : si une page est temporairement en panne à cause d’un problème de CMS, configurez le serveur pour qu’il réponde 429 à la place. 429 Le robot vérifie le code et ne supprime pas la page. Mais un continu indique à Yandex que le serveur est en difficulté etréduit la fréquence de crawl
, c’est donc un pansement, pas un paramètre. HTTP/2 est pris en charge
— chargement plus rapide et charge serveur réduite, bien que Yandex précise que cela ne change ni la fréquence de crawl ni le classement, et HTTP/1.1 continue de fonctionner.
Étape 2 — l’indexation Le robot analyse et stocke le contenu : la balise meta description , letitle , le balisage Schema.org pour l'extrait ; la directive noindex , qui exclut la page ;rel=”canonical”
, qui déclare l’adresse préférée pour un groupe ; ainsi que le texte, les images et la vidéo. Lorsque le contenu correspond sur plusieurs pages, elles deviennent des doublons.
Étapes 3 et 4 Une base de données des pages éligibles à la recherche est constituée, et les résultats en sont générés. Les résultats se mettent à jour régulièrement, et ces mises à jour peuvent modifier la position d’un site sans que rien n’ait changé sur le site
— ce qui est la bonne réponse à la plupart des questions du type « nous avons chuté et rien n’a changé ».
Pourquoi le modèle est important
Comment nous l'appliquons
The 429 behaviour is the practical gift here: during a CMS incident it keeps pages in the index instead of letting them be dropped for 5XX responses, which turns a two-hour outage into a non-event rather than a two-week recovery. We put it in the incident runbook for every client with a fragile stack — and we take it out again once the incident ends, because sustained 429 costs crawl rate.
Services associés