Was sich im ersten Halbjahr 2026 in der Suche geändert hat

Bing zeigte Websitebetreibern, wo ihre Seiten in KI-Antworten zitiert werden. Google veränderte Discover, stellte FAQ-Rich-Results ein und führte eigene Berichte zu KI-Impressionen ein. Neben diesen sichtbaren Änderungen gaben Crawler-Grenzen, das Verhalten im Browser und Domainumzüge technischen Teams reichlich zu prüfen. Dieser Rückblick verbindet die Änderungen von Januar bis Juni mit den Berichten, Seiten und Release-Entscheidungen, die davon betroffen sind.

Daten

Die Abfolge, die Entscheidungen im Betrieb veränderte

Die Reihenfolge ist wichtig, weil die Ereignisse unterschiedliche Fragen beantworten. Im Januar wurde die Dokumentation zu strukturierten Daten für Übungsaufgaben entfernt und eine Anleitung zu Bevorzugten Quellen eingeführt. Im Februar folgte ein regional begrenztes Discover-Core-Update mit US-englischem Geltungsbereich und die erste öffentliche Vorschau von Bings AI Performance. Im März fielen Spam- und Core-Rollout zeitlich auseinander, und Google erklärte, wie der Googlebot Antworten verarbeitet. Im April wurde das Core-Update abgeschlossen und das Back-Button-Hijacking in die Spam-Richtlinie aufgenommen. Im Mai entfiel das FAQ-Rich-Result-Erscheinungsbild, und es erschien eine Anleitung zu generativer KI. Im Juni kamen KI-Berichte in der Search Console, eine Klarstellung zu Migrationen, erweiterte KI-Ansichten bei Bing und die stündliche Abfrageüberwachung bei Yandex hinzu.

Diese Einordnung verhindert außerdem Kategoriefehler. Einen Fehler in der Crawler-Antwort können Sie sofort beheben, auch wenn er während eines Core-Updates auftritt. Die Einstellung einer Funktion verlangt eine Entscheidung zu Template und Inhalt, eine neue Berichterstattung dagegen eine Messdefinition. Ordnen Sie das Ereignis neben dem betroffenen Seitenbefund ein, statt alles in eine unterschiedslose Spalte „Algorithmus-Update“ zu packen.

Produktänderung

Discover und bevorzugte Quellen

Googles Discover-Core-Update vom Februar startete mit US-englischem Geltungsbereich und Hinweisen zu lokaler Relevanz, aktueller Originalexpertise und weniger reißerischen Inhalten. Die erste Prüffrage ist deshalb geografisch und redaktionell: Lagen die betroffene Zielgruppe, Sprache und Darstellungsform innerhalb der dokumentierten Oberfläche? Eine Bewegung in Discover außerhalb dieses Kontexts ist kein Beleg dafür, dass eine allgemeine Seitenvorlage geändert werden muss. Prüfen Sie die Ortshinweise des Inhalts, die fachliche Expertise, den Veröffentlichungszeitpunkt und den tatsächlichen Discover-Bericht, bevor Sie Impressionen als allgemeines Rankingsignal deuten.

Die Funktion „Bevorzugte Quellen“ folgte einem anderen Weg. Google dokumentierte sie im Januar, weitete sie im April auf alle Suchsprachen aus und nahm im Mai AI Overviews und AI Mode in den dokumentierten Geltungsbereich auf, wie die Dokumentationsaktualisierungen zeigen. Websitebetreiber können eine Schaltfläche oder einen Link teilen, mit dem Leser sie als bevorzugte Quelle auswählen können. Die Entscheidung trifft der Leser; Schema-Markup kann sie nicht an seiner Stelle treffen. Geben Sie wiederkehrenden Lesern eine klare Publikationsidentität und eine einfache Möglichkeit, diese auszuwählen.

Ein praktischer Discover-Check beginnt beim Inhalt selbst: Prüfen Sie das sichtbare Datum, das Thema, die lokale Relevanz und die eigene Berichterstattung oder Analyse. Vergleichen Sie danach das betroffene Land und die Sprache mit dem veröffentlichten Geltungsbereich der Funktion. Bedient eine Website mehrere Märkte, erklären Sie ein Update mit US-englischem Fokus nicht für jede Sprachversion. Richten Sie redaktionelle Verbesserungen an dem Publikum aus, das die Oberfläche tatsächlich erreichen kann.

Produktänderung

KI-Berichte: Oberflächen strikt trennen

Im Februar führte Bing AI Performance zitatorientierte Berichte ein. Die Erweiterung im Juni brachte Intents, Topics, Citation Share und Compare mit dem Folgerelease von Bing. Diese Berichte helfen Websitebetreibern zu untersuchen, wie Bing-KI-Erlebnisse Seiten zitieren. Sie ersetzen aber keine Sitzungen, Google-Rankings oder eine Messung der KI-Übersichten. Ihre Frage ist die Sichtbarkeit von Zitaten innerhalb der definierten Berichtsoberfläche von Bing.

Googles Ankündigung zu KI-Berichten in der Search Console führte im Juni eigene Ansichten für Impressionen in generativen KI-Funktionen der Suche und in Discover ein. Diese Impressionen bleiben auch in der allgemeinen Leistungsberichterstattung enthalten; die eigenen Ansichten standen zunächst nur einem Teil der Websites zur Verfügung. Yandex hat stündliche Daten aus Query Monitoring ergänzt, eine andere Art von Bericht für beliebte Suchanfragen. Trennen Sie diese Produkte nach Plattform, Einheit und Berichtszeitraum. Wer Klicks, Zitate und vorläufige Stundenwerte zusammenführt, verschleiert, was jeder Bericht tatsächlich misst.

zoom_in

Definieren Sie für ein Dashboard die Zeile, bevor Sie Daten exportieren. Eine Zeile kann Klicks aus der Search Console für eine URL-Gruppe bedeuten, eine andere Bing-Zitate zu einem Thema, eine dritte stündliche Yandex-Beobachtungen zu Abfragen. Geben Sie jeder Zeile eigene Property oder Markt, Datumsbereich und Zeitzone. So entfällt die Versuchung, aus Kennzahlen eine glatte Kurve zu zeichnen, die nie zum Addieren gedacht waren.

Maßnahme

Crawler-Verarbeitung und die 2-MB-Grenze

Googles Crawler-Erklärung vom März machte eine alte, leicht übersehene Grenze praktisch relevant: Der Googlebot verarbeitet nur eine begrenzte Menge an Antwortinhalt, beim HTML-Antwortdokument liegt die praktische Grenze bei zwei Megabyte. Die Lehre lautet nicht, die Bundle-Größe zu zählen und dann aufzuhören. Prüfen Sie den tatsächlichen Status, die finale URL, den Antwortkörper, das Canonical-Tag und die kritischen Inhalte im gerenderten Ergebnis. Kommen wesentliche Anweisungen oder Inhalte zu spät, kann eine Browseransicht bei schneller Verbindung den Fehler verbergen.

Nehmen Sie bei einer großen JavaScript-Route eine Beispiel-URL und speichern Sie die rohen Antwort-Header und Bytes. Vergleichen Sie dann, was im initialen HTML ankommt, mit dem, was nach dem Rendering erscheint: Hauptinhalt, Canonical, Robots-Anweisungen, strukturierte Daten und Links zu den nächsten relevanten Seiten. Verlagern Sie nicht kritische Nutzlast aus dem kritischen Pfad, wenn die Befunde das stützen. Entfernen Sie aber keine Inhalte nur, um einen Byte-Wert zu erreichen. Die Abnahmebedingung lautet: Die geforderte Seitenaussage bleibt erreichbar und innerhalb der praktischen Grenzen des Crawlers renderbar.

zoom_in

Die Zwei-Megabyte-Grenze ist besonders relevant, wenn eine Vorlage große serialisierte Daten, Navigationsdaten oder doppeltes Markup vor dem Hauptinhalt ausliefert. Suchen Sie die Byte-Kosten im zurückgelieferten Dokument, nicht nur in der JavaScript-Build-Ausgabe. Wird das Canonical oder der Fließtext clientseitig erst nach einer langen Kette von Verarbeitungsschritten bereitgestellt, machen Sie diese Abhängigkeit explizit und testen Sie sie mit denselben Routenparametern, die ein Crawler anfordern kann.

Maßnahme

Spam-Rollout und Back-Button-Hijacking

Das Spam-Update im März lief vom 24. bis 25. März. Das Core-Update im März startete am 27. März und wurde im April abgeschlossen. Diese Zeiträume müssen in einer Untersuchung getrennt bleiben. Verliert eine Seite in einem der beiden Zeiträume Klicks, kann ein technischer Bruch, eine Verschiebung der Suchnachfrage, ein Canonical-Problem, ein Wechsel der Konkurrenz oder ein breiteres Qualitätsproblem dahinterstecken. Der Kalender entscheidet nicht, welche Ursache zutrifft.

Am 13. April ergänzte Google Back-Button-Hijacking als ausdrücklichen Verstoß gegen die Spam-Richtlinie, mit einer für den 15. Juni angekündigten Durchsetzung. Diese Frist gehört in den Release-Kalender. Es handelt sich um ein konkretes Browserverhalten, das Sie prüfen können: Wenn ein Besucher einem Ergebnis folgt, sollte die Zurück-Taste ihn zur vorherigen Seite bringen und ihn nicht in einer unerwarteten Navigationsfolge festhalten. Testen Sie das in einer sauberen Browsersitzung, auf dem Smartphone ebenso wie am Desktop, und prüfen Sie danach Weiterleitungen, Manipulationen des Verlaufs und eingeschleuste Skripte. Entfernen Sie den Mechanismus, statt ihn mit einer oberflächlichen Änderung der Landingpage zu überdecken.

Der Gegensatz zwischen der Richtlinienänderung und den Update-Zeiträumen ist bei der Triage wichtig. Back-Button-Hijacking ist ein reproduzierbarer Interaktionsfehler, sein Test endet mit klar bestanden oder nicht bestanden. Eine Überschneidung mit einem Core-Update ist dagegen ein Untersuchungskontext und braucht segmentierte Belege. Halten Sie diese Arbeitsstränge getrennt: Beheben Sie nachweisbar täuschende Navigation direkt, und nutzen Sie Daten auf Ebene von Suchanfragen und Seiten, bevor Sie über eine breitere inhaltliche Überarbeitung entscheiden.

Maßnahme

Migrationspläne müssen jede Host-Variante abdecken

Der Leitfaden zu Website-Umzügen von Juni machte die Empfehlungen zur Adressänderung für alle Domainvarianten ausdrücklich. Das ändert das Migrationsinventar: Root-Host, www-Host und jede relevante Subdomain brauchen ein festgelegtes endgültiges Ziel, keine stillschweigende Konvention. Eine Weiterleitungsliste, die nur einen bevorzugten Hostnamen abdeckt, kann doppelte, defekte oder ungeprüfte Varianten gegenüber Nutzern und Crawlern offenlassen.

Erstellen Sie den Testsatz, bevor Sie den Traffic umstellen. Halten Sie für jede bestehende alte URL die vorgesehene finale URL, eine direkte dauerhafte Weiterleitung, den finalen Statuscode, das Canonical, die Sitemap-Zugehörigkeit und den gerenderten kritischen Inhalt fest. Wiederholen Sie den Test dann über jede öffentlich erreichbare Host-Variante. Aktualisieren Sie interne Links, Canonical-Tags und Sitemaps auf den finalen Host; verlassen Sie sich nicht auf Weiterleitungsketten, um alte Konventionen zu reparieren. Hat eine URL keinen passenden Nachfolger, liefern Sie die passende Antwort „nicht gefunden“ aus, statt sie auf die Startseite zu schicken.

Die Prüfung der Host-Varianten sollte neben dem Hostnamen auch das Protokoll umfassen: HTTP-Root, HTTPS-Root, HTTP-www und HTTPS-www, soweit diese Varianten öffentlich auflösen. Migrationen scheitern häufig an den Rändern – ein Bild- oder hreflang-Ziel behält einen alten Host, oder eine alte Subdomain umgeht eine Weiterleitung. Eine kurze maschinenlesbare Zuordnung plus Browserprüfungen gibt Crawlern und Menschen ein gemeinsames endgültiges Ziel.

Produktänderung

Das Ende der FAQ-Rich-Results und eine engere Änderung bei Produktdaten

Im Mai kamen zwei sehr unterschiedliche Entscheidungen zur Pflege strukturierter Daten hinzu. Google zeigte FAQ-Rich-Results ab dem 7. Mai nicht mehr an, wie die Dokumentationsaktualisierungen festhalten. Eine sichtbare FAQ kann weiterhin die Frage eines Kunden beantworten, gültiges Markup bedeutet aber nicht mehr, dass dieses bestimmte Suchergebnis erscheint. Behalten Sie Fragen für Leser dort, wo sie nützlich sind. Entfernen Sie reine Implementierungen für die Funktion erst, nachdem Sie Abhängigkeiten bei Templates, Analyse und Barrierefreiheit geprüft haben.

Dieselben Mai-Updates ergänzten die Dokumentation für Produkte und Händler um hasAdultConsideration. Das Feld ist eng gefasst für Datensätze, in denen der Sachverhalt zutrifft und wahrheitsgemäß dargestellt wird. Es ist keine allgemeine Erweiterung für Produktfeeds und sollte nicht eingefügt werden, um ein Feature zu erreichen. Die allgemeine Regel: Bewahren Sie semantische Daten, die zur sichtbaren Seite passen, validieren Sie den Graphen und den jeweiligen Empfänger getrennt, und nehmen Sie Zusagen über ein Erscheinungsbild zurück, das die Suche nicht mehr anbietet.

Testen Sie bei einer FAQ die sichtbaren Fragen auf Desktop und Smartphone und fragen Sie dann, ob jede Antwort eine echte Frage vor dem Kauf oder im Support beantwortet. Ist das der Fall, kann der Inhalt auch ohne Anreiz durch ein Rich-Result bleiben. Verlangen Sie für hasAdultConsideration eine sachliche Quelle im Katalogdatensatz und eine sichtbare Darstellung, wo sie angebracht ist. So wird eine Eigenschaft mit Compliance-Charakter nicht als spekulatives SEO-Signal behandelt.

Maßnahme

Gezielte Prüfungen für die nächste Überprüfung

Die nächste Überprüfung sollte ein Belegblatt pro Oberfläche anlegen, nicht eine Gesamtbewertung. Für Auffindbarkeit halten Sie Land, Sprache, Format und den relevanten Produktbericht fest. Für die KI-Sichtbarkeit bewahren Sie Plattform, Berichtsname, Zeitraum, Einheit und Zuordnung auf. Bei der Crawl-Arbeit sichern Sie Antwort-Header, Größe des Antwortkörpers, gerenderten kritischen Inhalt sowie den Status von Canonical und Robots. Bei Migrationen dokumentieren Sie jeden Eingangs-Host und jede Routenzuordnung. Bei strukturierten Daten bewahren Sie die sichtbare Tatsache, die Graph-Validierung und die aktuelle Richtlinie zur Funktion. Solche Nachweise machen eine spätere Änderung erklärbar, ohne eine Ursache zu erfinden.

• Vergleichen Sie bei Discover ein betroffenes Land und Inhaltsformat mit dem dokumentierten Geltungsbereich der Funktion, bevor Sie redaktionelle Templates ändern.
• Führen Sie bei den Berichten von Google, Bing und Yandex getrennte Tabellen; addieren Sie niemals Zitate, Klicks aus der Search Console und stündliche Abfragebeobachtungen.
• Erfassen Sie bei einer schweren Route die rohe Antwortgröße und den gerenderten kritischen Inhalt vor und nach jeder Performance-Änderung.
• Testen Sie bei einer Migration Root, www und jede öffentliche Subdomain gegen die Weiterleitungsliste, die Canonical-Tags, die Sitemap und eine gerenderte Seite.
• Unterscheiden Sie bei strukturierten Daten zwischen sichtbaren Informationen, die nützlich bleiben, und einem Rich-Result-Format, das Google eingestellt hat.
• Prüfen Sie bei jedem Rollout-Zeitraum Suchanfragen, Landingpage und technische Belege, bevor Sie einem Update eine Ursache zuweisen.