Yandex beschreibt seinen eigenen Ablauf in vier Phasen, und zu wissen, zu welcher Phase ein Problem gehört, macht aus einer vagen Beschwerde ein behebbares Problem.
Phase 1 — Crawling
Der Roboter entscheidet, welche Websites gecrawlt werden, wie oft und wie viele Seiten. Seine Liste bekannter Seiten stammt aus internen und externen Links, der Sitemap, Yandex Metrica-Daten und robots.txt. Seiten, die größer als 10 MB sind, werden nicht indexiert.
Die Antwortverarbeitung ist eindeutig:
200 OK— gecrawlt.3XX— der Roboter crawlt das Weiterleitungsziel.4XXund5XX— die Seite wird nicht einbezogen und wird entfernt, falls sie bereits im Suchindex war.
Und der nützliche Trick danach: Wenn eine Seite vorübergehend durch einen CMS-Fehler ausfällt, konfigurieren Sie den Server stattdessen so, dass er 429 antwortet. 429 Der Roboter prüft den Code und verwirft die Seite nicht. Aber anhaltendes signalisiert Yandex, dass der Server zu kämpfen hat, undreduziert die Crawl-Rate
, es ist also ein Pflaster, keine Einstellung. HTTP/2 wird unterstützt
— schnelleres Laden und geringere Serverlast, obwohl Yandex klarstellt, dass dies weder die Crawl-Frequenz noch das Ranking verändert und HTTP/1.1 weiterhin funktioniert.
Phase 2 — Indexierung Der Roboter analysiert und speichert den Inhalt: den description Meta-Tag,title , Schema.org-Auszeichnung für das Snippet; die noindex -Direktive, die die Seite fernhält;rel=”canonical”
, die die bevorzugte Adresse für eine Gruppe angibt; sowie Text, Bilder und Video. Wenn Inhalte auf Seiten übereinstimmen, werden sie zu Duplikaten.
Phasen 3 und 4 Eine Datenbank mit für die Suche geeigneten Seiten wird zusammengestellt, und die Ergebnisse werden daraus generiert. Die Ergebnisse werden regelmäßig aktualisiert, und diese Aktualisierungen können die Position einer Website verändern, ohne dass sich auf der Website etwas geändert hat
— was die richtige Antwort auf die meisten Fragen wie „Wir sind abgestürzt und nichts hat sich geändert“ ist.
Warum das Modell wichtig ist
So setzen wir das um
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.
Verwandte Leistungen