Core Update: was ein Kernupdate von Google ist

Google justiert mehrmals im Jahr die Systeme nach, die über die Reihenfolge der Ergebnisse entscheiden. Diese Anpassungen werden angekündigt, bekommen einen Namen mit Monat und Jahr und treffen alle Arten von Websites und Suchanfragen gleichzeitig. Die praktische Folge ist unbequem: Eine Seite kann fallen, ohne dass irgendjemand bei Google diese Seite angesehen hat.

Drei Dinge, die in Geschäftsgesprächen fast immer vermischt werden, gehören auseinander. Eine manuelle Maßnahme ist eine menschliche Entscheidung über eine konkrete Website, sie wird in der Search Console mitgeteilt und lässt einen Antrag auf erneute Prüfung zu. Ein Spam-Update verbessert die automatischen Systeme, die verbotene Praktiken erkennen. Ein Core Update tut keines von beidem: Es sortiert neu, mehr nicht.

Google erklärt die Wirkung mit einem häuslichen Vergleich. Wenn jemand heute seine Liste der zwanzig Lieblingsrestaurants neu schreibt, sind die abgestiegenen Lokale nicht schlecht geworden; es gibt schlicht neue Kandidaten und neue Kriterien. Positionen nach einem Core Update zu verlieren beweist nicht, dass die Seite gegen etwas verstößt.

Auch decken nicht alle Core Updates die gesamte Suche ab. Am 5. Februar 2026 veröffentlichte Google ein Core Update für Discover, mit derselben Bezeichnung und derselben allgemeinen Anleitung, aber begrenzt auf diese Oberfläche.

Der Rollout passiert nicht auf einen Schlag. Google veröffentlicht Start- und Enddatum in seinem Status-Dashboard für die Suche, und dazwischen bewegen sich die Ergebnisse stärker als sonst, weil die einzelnen Systeme zu unterschiedlichen Zeitpunkten aktualisiert werden. Berührt ein Update mehrere Systeme gleichzeitig, zieht sich der Vorgang: Bei der Ankündigung des Updates vom März 2024 wies Google darauf hin, dass der Rollout bis zu einem Monat dauern könne.

Solange der Rollout offen ist, ist jede Datenauswertung vorläufig. Die offizielle Empfehlung lautet, nach dem Abschluss mindestens eine volle Woche zu warten und diese Woche dann mit einer Woche vor dem Start zu vergleichen. Ein Vergleich gegen den Rollout-Zeitraum selbst liefert Zahlen, die sich von allein verändern.

Danach misst man die tatsächliche Bewegung pro Seite und pro Suchanfrage, nicht über die Summe der Website. Ein Rutsch von Position 2 auf 4 rechtfertigt keinen Eingriff, und Google rät ausdrücklich davon ab, gut laufende Inhalte anzufassen. Ein Rutsch von Position 4 auf 29 verlangt dagegen eine gründliche Analyse. Es hilft außerdem, Web, Bilder, Video und News getrennt zu betrachten, denn ein Einbruch, der sich auf eine einzige Oberfläche konzentriert, deutet auf eine andere Ursache.

Und hier kommt der Teil, den die Branche gern umschreibt. Auf die Frage „was tue ich, um mich zu erholen?“ folgt offiziell keine Liste von Reparaturen: Google sagt, es gebe keine spezifischen Maßnahmen zur Erholung von einem Core Update, und eine negative Auswirkung müsse nicht bedeuten, dass mit den Seiten etwas nicht stimmt. Angeboten wird stattdessen ein Fragenkatalog zur Selbsteinschätzung der gesamten Website, dazu der Hinweis, dass Verbesserungen Monate brauchen können und dass keine Änderung eine sichtbare Wirkung garantiert.

Die Entscheidung, die an diesem Begriff hängt, lautet: reagieren oder nicht, und mit welchem Budget. Ein Rückgang, der zeitlich mit einem Core Update zusammenfällt, sieht einem Rückgang durch einen technischen Fehler, durch einen Template-Wechsel oder durch einen Wettbewerber, der gerade etwas Besseres veröffentlicht hat, zum Verwechseln ähnlich. Die Verwechslung kostet Geld: Man schreibt neu, was gut war, und lässt unangetastet, was kaputt war.

Die zweite Entscheidung betrifft Fristen und Zusagen. Inhaltliche Änderungen können Monate brauchen, bis sie sich zeigen, und die Suchmaschine selbst garantiert keiner Änderung eine sichtbare Wirkung. Ein Plan, der die alte Position für den Folgemonat verspricht, verspricht etwas, das Google nicht verspricht.

Die dritte betrifft die interne Steuerung. Wird jede Ranking-Bewegung dem zuletzt angekündigten Update zugeschrieben, prüft niemand die langweiligen Ursachen: eine halb fertige Migration, ein vergessenes noindex, eine ausgelaufene Kampagne, ein saisonaler Nachfragerückgang. Den Vorfall zu datieren und mit dem offiziellen Kalender abzugleichen macht aus einer Meinungsdebatte eine Prüfung.

• Start- und Enddatum jedes angekündigten Updates im Analyse-Kalender notieren, um es später mit den eigenen Daten kreuzen zu können.
• Den Abschluss des Rollouts abwarten und eine weitere Woche verstreichen lassen, bevor Schlüsse gezogen oder Zahlen an einen Kunden gegeben werden.
• Die Woche danach mit einer Woche vor dem Start vergleichen, und zwar pro Seite und pro Suchanfrage, nicht nur über die Summe der Website.
• Zuerst technische und geschäftliche Ursachen ausschließen: Crawling, Indexierung, Template-Wechsel, Saisonalität, beendete Kampagnen.
• Den Fragenkatalog zur Selbsteinschätzung auf die gesamte Website anwenden und zusätzlich jemanden außerhalb des Projekts antworten lassen, weil der eigene Blick auf eigene Inhalte nachsichtig ist.
• An den am stärksten betroffenen Seiten mit substanziellen Verbesserungen des Nutzens arbeiten und das Löschen als letztes Mittel behandeln.

• Einen Rückgang nach einem Core Update Strafe nennen, womit man einen Schuldigen und ein Reconsideration-Formular sucht, die es hier nicht gibt.
• Während des Rollouts messen und mit Zahlen entscheiden, die sich noch bewegen.
• Schnelle Reparaturen vom Hörensagen anwenden, etwa ein Seitenelement entfernen, weil jemand es für schädlich erklärt hat.
• Ganze Bereiche aus Reflex löschen. Wenn Löschen die natürliche Reaktion ist, lautet die nützliche Frage, warum diese Bereiche veröffentlicht wurden.
• Jede Schwankung dem zuletzt angekündigten Update zuschreiben und Crawling, Indexierung und Nachfrage nie prüfen.