Hört, hört, edle Recken und holde Maiden unseres erhabenen Newsletters! So sei es kundgetan, dass sich unsere tapfere Schar unlängst auf den Weg nach Göttingen begab, um dort im Schatten von Schloss Berlepsch, einer Festung so ehrwürdig wie ehrfurchtgebietend, unser Offsite zu begehen. Die Mauern des Schlosses erzählten von längst vergangenen Zeiten, als dort stolze Ritter zu Tafelrunden riefen und kühne Turniere bestritten.

Inmitten dieser historischen Kulisse ließen auch wir den Alltag hinter uns und widmeten uns den ritterlichen Tugenden: Teamgeist, Tapferkeit und Treue. Bei Spielen und Herausforderungen, die eines wahren Ritters würdig waren, stellten wir unsere Geschicklichkeit beim Armbrustschießen und unsere Stärke beim Tauziehen unter Beweis.

Nach diesen heldenhaften Taten kehrten wir mit Anbruch des neuen Tages in die Gegenwart zurück, um uns mit den Herausforderungen der Neuzeit zu befassen: dem geheimnisumwobenen Google Leak. Mit der Wachsamkeit eines Spähers auf der Zinne analysierten wir die Lage und schmiedeten Strategien.

Diese Themen sind diese Woche aus den tiefen Kerkern des Schlosses entflohen:

• Drachenhüter Johan bewacht das lodernde Core-Update und rüstet Dich mit klugen Taktiken. 🐉
• Falkner Philipp beobachtet, wie die AI-Overviews nur zögerlich über die Lande fliegen, statt die Welt im Sturm zu erobern. 🦅
• Zeitwächterin Nora betont die Macht der Timestamps, die als wertvolle User-Signale im Video-SEO unverzichtbar sind. ⏳
• Kriegsstrategin Jolle zeigt Dir, wie effizientes Crawling ein Segen für unser aller Königreich sein kann. 🏰
• Wegkundschafterin Anita navigiert durch die geheimnisvollen Lande von Apple Maps. 📜

Mögen diese Themen Dich weiser und stärker machen 🏹

Deine Wingmenschen

Manchmal (aber nur manchmal) bin ich schneller als das Google Search Quality Team erlaubt:

In unserer Leseliste in Slack, in der wir News der SEO-Branche sammeln, haben wir auch die Updates des Google Search Status Dashboards eingebunden. In diesem Dashboard werden Updates und Probleme kommuniziert.

Die Ankündigung dieses Core Updates hatten wir dann 5 Minuten vor dem Dashboard in unserer Leseliste. 🎉

Die eigentliche News ist:

• Google hat das in diesen Wochen erwartete Core Update live gestellt (15.08.2024 8 Uhr Pacific Time, also 18 Uhr in Deutschland)
• Google hat wenige Stunden später einen Bug, der eine große Anzahl Suchergebnisse betrifft.

Was Google nicht sagt: der Name des Core Updates könnte „Lily Ray“ sein und nicht „August 2024 Core Update“. Lily hat in den letzten Monaten immer wieder auf Fehler im Ranking hingewiesen. Darauf, wie Reddit und Quora (zu) viel Sichtbarkeit bekommen und kleine Publisher benachteiligt werden.

Genau diese Punkte spricht John in seiner Ankündigung des Updates an. Die letzten Updates wurden nicht angekündigt. Daher ist es schon außergewöhnlich, dass Google etwas zum Core-Update schreibt.

Zeitgleich wurde die Core Update Seite deutlich überarbeitet.

Dieses Core-Update soll (laut Ankündigung):

• Mehr Content anzeigen, den Menschen wirklich nützlich finden und der nicht primär für Ranking-Zwecke gebaut wurde (das schreibt Google immer).
• Feedback der letzten Monate berücksichtigen (das schreibt Google fast nie).
• Wie immer, Seiten mit hoher Qualität anzeigen. Kleine Seiten werden hier aber auffällig betont (das mit den kleinen Seiten ist besonders).
• Auffällig ist auch die Einschränkung auf den User-Intent (kommt aber gelegentlich vor).
• Verbesserungen von Seiten sollen besser berücksichtigt werden (das ist besonders).

In der kleinen Synopse habe ich für Dich die alte und die neue Version der Guideline gegenübergestellt und kommentiert.

Was tue ich jetzt?

Die richtige Antwort ist „erstmal nichts“. Durch den aktuellen Ranking-Bug ist es unmöglich, Ranking-Änderungen dem Core-Update zuzuschreiben.

Gleichzeitig betont Google, dass Änderungen durch das Core Update erst nach dem Update richtig sichtbar sind. Und in der Tat haben wir in den letzten Updates gegen Ende noch deutliche Bewegungen gesehen.

Das ist besonders unbefriedigend, da die Ankündigung im Dashboard von einer Rollout-Phase von einem Monat spricht. Das bedeutet für uns SEOs, dass wir quasi blind sind. Denn ein Monat bringt so viele Änderungen mit, dass die Analyse schwer wird. Wenn das Update fertig ist, ändert sich das Suchverhalten (z. B. Wetter und Ende der Sommerferien). In einem Monat ändert sich auch die Konkurrenzlage.

Trotzdem müssen wir nicht untätig sein. Wenn wir schon während des laufenden Updates Änderungen sehen, dann ist eine kritische Auseinandersetzung mit den Inhalten sinnvoll. Der Google Fragebogen ist ein guter Startpunkt.

Gleichzeitig wissen wir, dass das Core Update nicht auf technische Faktoren abzieltt. Trotzdem können technische Optimierungen natürlich negative Auswirkungen kompensieren.

Meine Prioritäten wären (Punkte überspringen sofern schon ordentlich durchgeführt – natürlich sieht die Priorisierung je nach Domain anders aus und ist auch nicht abschließend):

• Content-Audit und Verbesserungen (insbesondere mit Fokus auf Intent und Information Gain)
• Interne Verlinkung reviewen / optimieren
• Neuen Content schaffen
• Technische Verbesserungen (= Content für Suchmaschinen aufbereiten)

Hinweis: Content ist nicht nur Text. Content ist auch Bild, Tools, Video oder (ganz wichtig auf Kategorieseiten) interne Verlinkung.

P.S.: Über Information Gain spricht übrigens Saskia heute Abend auf dem SEO-Meetup Hamburg.

Von den Hiobsprophezeihungen sind wir zwar schon lange weg, aber AI Overviews sorgen immer noch für Schlagzeilen und Angst. Google hat verkündet, dass sie die AI Overviews global ausrollen. So liest man es zumindest in einigen Headlines (nicht in meiner).

“Google's AI Overviews goes global”

“Google Search Expands AI Overviews Globally”

“Google's AI Overviews go global in latest update”

Stimmt alles nicht.

In Kurzform: Was hat Google zu den AI Overviews gesagt?

• Sie rollen in 6 weiteren Ländern aus: UK, Indien, Japan, Indonesien, Mexiko und Brasilien.
• Alle 120 Länder, die Search Labs haben, bekommen die Testfunktion freigeschaltet (also quasi SGE, die Testumgebung).
• Sie sprechen zwar von “to roll out globally” bei den Search Labs, referenzieren aber “in all launched countries”, was diese Liste ist und auf der Deutschland z. B. weiterhin fehlt.
• Seit dem Rollout sollen Nutzer*innen zufriedener sein und vor allem die 18-24 Jährigen AI Overviews besonders gerne mögen.
• Google testet weitere Varianten, Verlinkungen in AI Overviews zu platzieren und dadurch soll es den Tests zufolge mehr Traffic geben.

Meine Meinung zu der Ausbreitung der AI Overviews

Wenn man genau liest, hat sich nicht wirklich viel geändert. Das hindert LinkedIn, Twitter und News-Portale aber nicht daran, für viel Wind zu sorgen.

Am interessantesten finde ich die Verlinkungsexperimente. Im Blog-Artikel hat Google folgende Grafik gezeigt:

Anstatt dem Caret, also dem Dropdown-Pfeil, haben sie ein Icon eingebaut, das deutlich besser als “hey, hier sind Links” verstanden wird und nicht “wenn Du mich klickst siehst Du noch mehr”. Das dadurch mehr Traffic kommt, wundert mich nicht.

Wie ich an unterschiedlichen Stellen geschrieben habe: AI Overviews können als Produkt nur funktionieren, wenn es weiterhin viel Traffic und Klicks gibt, da ansonsten die Geldmaschine (= bezahlte Suchanzeigen) kein Benzin mehr hat.

Wenn Traffic kommt und dieser gut vorqualifiziert ist, dann ist eine Conversion bzw. Zielerreichung näher. Das ist logisch.

Gibt es wirklich mehr Traffic, wie sie behaupten?

Die Frage ist, worauf sich das “higher” bezieht.

• Mehr als in der regulären Suche?
• Insgesamt mehr oder nur auf den Test bezogen?
• Mehr, als wenn man auf Position 83 ranken würde?

Es wäre überzeugender, wenn sie uns konkrete Zahlen liefern würden.

Zahlen ist ein gutes Stichwort. In Googles Dokumentation zu Clicks, Impressions und Positions hat Google eine Sektion zu AI Overviews ergänzt:

• Clicks sind Clicks – Überraschung :D
• Impressions = der Link muss im Viewport zu sehen sein (z. B. durch Scrollen)
• Positions = alle Links im AI Overview haben die gleiche Position

Autsch bei der Position. Einige Links sind prominent sichtbar, während andere versteckt sind und trotzdem bekommt alles die gleiche Position. Aber das ist alles egal, solange wir in der GSC zu AI Overviews keinen Filter haben, um die Daten separiert von normalen Web-Ergebnissen sehen zu können.

Ich halte Dich auf dem Laufenden und schaue genau hin. Was denkst Du, kommen AI Overviews nach Deutschland? Und wenn ja, wann?

Wir waren auf einem Offsite und haben in den Google Leak geschaut. Das war richtig spannend und ich bin sehr froh, dass wir diese Zeit investiert haben. Eine kleine Erkenntnis zu User-Signalen habe ich heute für Dich dabei.

Johan hat Dir schon in seinem Newsletter-Artikel „Leak mich am Arm, ist das ein geniales Google-Geschenk" vom Google Leak berichtet. Auch in der aktuellen Ausgabe der Website Boosting bekommst Du jede Menge spannende Insights zum Google Leak. Der Leak umfasst mehr als >2.000 Module und über >14.000 Attribute. Darunter auch VideoContentSearchNavboostAnchorFeatures.

Aber was verbirgt sich hinter diesem sperrigen Begriff?

Dieses Feature dreht sich um Suchabfragen, die mithilfe von sogenannten Navboost-Daten und timed anchors – also zeitlich markierten Ankerpunkten – erstellt wurden. Vereinfacht gesagt, geht es darum, wie Nutzer mit spezifischen Timestamps in Videos interagieren. Google könnte diese Daten nutzen, um das Ranking von Videos in den Suchergebnissen zu beeinflussen.

Stell Dir vor, Du suchst nach einer Lösung für ein Problem. Anstatt ein 20-minütiges Video komplett anzusehen, springen viele Nutzer direkt zu einem relevanten Abschnitt, der in der Videobeschreibung verlinkt ist. Genau diese Interaktionen könnten Google signalisieren, dass dieser bestimmte Abschnitt besonders relevant für die Suchanfrage des Users ist – und das Video entsprechend höher ranken.

Das ist nicht nur innerhalb des YouTube-Rankings relevant, sondern auch innerhalb des Video Verticals in der Google-Suche (Beispiel: tipps hunde sommer).

Was steckt dahinter?

Das Feature basiert auf verschiedenen Attributen, darunter anchorText (der Text, der den Anker definiert), navboostText (die spezifische Navboost-Suchanfrage) und source (Abfrage ist ein String, der Kontext darüber liefert, wie die "navboost-anchor"-Abfrage erstellt wurde).

Laut den Best Practices von Google für strukturierte Daten von Videos sind Timestamps entscheidend, um den Nutzern relevante Abschnitte in Videos leichter zugänglich zu machen. Google empfiehlt, Videos mit strukturierten Daten und präzisen Timestamps zu versehen, um die Sichtbarkeit und Auffindbarkeit zu verbessern.

Diese Attribute könnten dazu verwendet werden, um Suchergebnisse noch präziser auf die Nutzerintention abzustimmen und die Suchergebnisse entsprechend anzupassen.

Was bedeutet das für Dich?

• Verwende strukturierte Daten auf Deiner Website: Implementiere das Video-Markup, um Google klare Hinweise auf die wichtigsten Abschnitte zu geben. Das geht allerdings nur, wenn das Video Hauptbestandteil der Seite ist.
• Gebe Timestamps bei YouTube an: In Deiner Video-Description kannst Du Timestamps mit einer Kapitelbezeichnung angeben. Per Default ist die Funktion automatische Video-Kapitel eingestellt. Diese sind aber nicht immer passend.

In Sandras Artikel “5 Basic-Tipps für YouTube-Videos” findest Du zudem weitere Tipps für Deinen YouTube-Erfolg.

Es ist nicht klar, in welchem Umfang Google dieses Feature tatsächlich für das Ranking von Videos nutzt. Was jedoch sicher ist: Timestamps sind nützlich für User und garantieren Dir mehr Aufmerksamkeit in den Suchergebnissen. 📹

In der Search-Off-The-Record-Folge “Crawling Smarter Not Harder” philosophieren Gary, Lizzi und John darüber, wie das Crawling für Googlebot effizienter gestaltet werden kann.

Nur Crawlen, wenn sich etwas verändert hat

Das grundsätzliche Dilemma für Webcrawler versteckt sich in dieser Frage: Wie können wir alle relevanten Änderungen im Internet mitbekommen, ohne permanent Dinge anzuschauen, die sich gar nicht verändert haben?

Microsoft/Bing hat sich zur Lösung dieses Problems mit Yandex und anderen zusammengetan und das Open Source Protokoll IndexNow an den Start gebracht. Google verwendet den Standard bislang nicht und erwähnt ihn im Podcast mit keinem Wort.

Ein Grund dafür dürfte sein, dass Spammer solche Standards schnell derart missbrauchen, bis sie jeglichen Nutzen verlieren. So haben sowohl Bing als auch Google die Möglichkeit abgeschafft, Sitemaps per API bei den Suchmaschinen anzupingen, wie Anita in einem vergangenen Artikel erklärt  hat.

In dem Artikel erfährst Du auch, warum Google keine Lust mehr hat, die Priority- oder ChangeFrequency-Angaben in Sitemaps zu berücksichtigen. Das LastMod-Datum ist zwar weiterhin relevant. Aber nur, wenn wir es nicht missbrauchen. Sobald massenweise Seiten auf ein frisches Datum gestellt werden, obwohl sich am Inhalt gar nichts verändert hat, behält sich Google vor, die Angabe komplett zu ignorieren.

Significant Changes

Deshalb wünschen sich Suchmaschinen, dass wir das LastMod-Datum nur dann aktualisieren, wenn wir auf der Seite nicht nur einen Typo korrigieren, sondern “signifikante Änderungen” am Inhalt vornehmen. Das lesen wir nicht nur aus öffentlichen Äußerungen von Google heraus, sondern indirekt auch aus dem Google Content Warehouse API Leak.

Im Modul “PerDocData” werden vermeintlich alle Attribute aufgelistet, die Google zu einem Dokument (erreichbar über eine URL) wegspeichert oder zumindest in der Vergangenheit gespeichert hat. Darunter finden wir auch das Attribut “lastSignificantUpdate”, kurz LSU. Als “Quality Signal” will Google das Attribut dennoch nicht verstanden wissen, wie wir aus der Doku zum Modul “CompositeDocQualitySignals” lernen:

Dazu passt, dass sich Gary, Lizzi und John im Podcast über Crawl Requests als Qualitätskriterium austauschen.

Viel Crawling = tolle Website?

Nicht direkt. Seltenes Crawling kann für gute Inhalte vollkommen ausreichend sein. Nämlich dann, wenn sich an den Seiten nur selten etwas ändert – wie bei einer Archivseite. Die Startseiten von Nachrichtenportalen müssen natürlich viel häufiger gecrawlt werden als ein alter Blogpost. Die Änderungsfrequenz ist das wichtigere Kriterium.

Und trotzdem ziehen wir die Crawl Requests des Googlebots zuweilen auch als Qualitätskriterium heran. Es muss uns stutzig machen, wenn wir guten Content liefern und der Bot trotzdem selten vorbeikommt. Zum Beispiel auf Kategorieseiten eines Shops, wo neue, nachgefragte Produkte dazukommen und alte ausverkauft werden.

Dann müssen wir uns fragen:

• Sieht Google die Produkte?
• Sind die Überschriften und Beschreibungen sinnvoll betextet?
• Geben wir den korrekten Status Code aus?
• Kann unser Server die Hits verkraften und zügig beantworten?

In diesem Sinne dürfen wir ableiten, dass Google Teile einer Seite gut gefallen, wenn regelmäßig gecrawlt wird. Als alleiniges Kriterium taugt die Crawl Rate natürlich nichts.

Mehr Effizienz für den Crawl-Prozess?

Zurück zur Aufgabe, überflüssig (umfangreiches) Crawling einzudämmen. Auch deshalb gibt Google den Website-Betreibern – zum Beispiel über die Core Web Vitals – Hinweise und Aufgaben wie die folgenden an die Hand:

• die eigene Seite schlanker gestalten,
• nicht unnötig große Bilder ausliefern,
• sich selten ändernde Ressourcen cachen und
• allgemein weniger Last über den Äther schicken.

Dann wird Crawling nicht nur für Google, sondern auch für Betreibende von Websites günstiger und weniger belastend für das Klima. Im Podcast können wir aber noch eine weitere Bitte von Google an Website-Zuständige herauslesen.

Nutze den Status Code 304

Dazu besteht keine Pflicht, aber die 304-Response “Not Modified” kann helfen. Hiermit werden Anfragen an eine Server-Ressource implizit an eine gecachte Variante des Inhalts weitergeleitet, wenn:

• Sich entweder der String des Etags nicht verändert hat (If-None-Match\=FALSE; Bedeutet Etag ist gleich geblieben und wir brauchen die Ressource nicht nochmal)
• Oder die Ressource nach einem bestimmten (Cache-) Datum angefragt wird (If-Modified-Since\=FALSE; Seite hat sich seit dem angegebenen Datum nicht verändert und wir brauchen die Ressource nicht nochmal)

Die komplette Ressource mit 200er Status Code kommt also nur zurück, wenn sich die Ressource verändert hat. Andernfalls kommt nur der Header mit dem Redirect an die bereits vorrätigen, gecachten Ressourcen.

Dass Google den 304er-Status tatsächlich respektiert, hat Dave Smart vor ein paar Jahren schon mal auf TameTheBots getestet.

Googles Wunsch ist sicher nicht uneigennützig, allerdings profitieren wir alle davon, wenn überflüssige Server-Anfragen gar nicht erst stattfinden. Arbeitest Du schon mit dem 304 Status Code?

Vorletzte Woche habe ich über Sitemaps geschrieben. In der Ausgabe davor über Google Maps. Heute geht es um Apple Maps.

Vielleicht fragst Du Dich ja: Apple Maps? Was ist daran so interessant? Denn lange Zeit war Apple Maps nur via App verfügbar und entsprechend nur von Menschen mit den erforderliche Gerätschaften nutzbar. Oder über einen Umweg mit DuckDuckGo.

Seit dem 24. Juli ist Apple Maps nun weltweit auf Englisch mit einer Auswahl weit verbreiteter Browser unter http://beta.maps.apple.com/ nutzbar. Erstmal “nur” als Beta, aber immerhin. Apple hat diese Neuerung relativ lapidar als “Kurzmeldung” gedropt (Deutsch / Englisch).

Darin heißt es:

Spannende Apple Maps Features, die Golem hervorhebt, sind

• Direktaktionen: Unter anderem soll dies ermöglichen, direkt aus der Kartenoberfläche heraus beim Lieferdienst einer Gastronomie zu bestellen.
• Führungen: Die Reiseführer sind bisher auf wenige Orte begrenzt und auch noch ohne Ziel in Deutschland.

Andrew Shotland von Localogy berichtete kurz nach der Bereitstellung von Apple Maps für Browser darüber, dass diese Web-Version indexierbar ist. Dies ist zwar grundsätzlich korrekt, allerdings ist der von Andrew vermutete Impact kleiner als erwartet. Aufgrund seiner Screenshots ist zu vermuten, dass die mittlerweile bestehende robots.txt-Sperre damals noch nicht vorhanden war.

Wie diese site:-Abfrage zeigt, ist zwar die ein oder andere URL tatsächlich im Index gelandet, durch das Crawl-Verbot sehen die Snippets aber nicht besonders interessant aus.

Leider konnte ich keine sinnvollen Statistiken dazu finden, wie stark die Nutzung der Kartendienste von Apple und Google bisher im Vergleich stattgefunden hat. Es wäre jedoch zu erwarten, dass Apple hier – sofern die potenziellen Nutzer*innen davon Kenntnis erreichen – ein paar Prozentpunkte gut machen könnte.

Wobei man selbstverständlich bedenken muss, dass innerhalb der Google-Suche auch weiterhin Google Maps integriert ist und ein Aufruf von Apple Maps hingegen relativ bewusst erfolgen muss.

Nichts desto trotz ist diese Meldung ein guter Reminder, sich die eigenen Apple Maps Einträge einmal anzuschauen, auch wenn hier vermeintlich weniger Menschen unterwegs sind. Zumindest, wenn Du also in irgendeiner Form stationär unterwegs bist, solltest Du einen Blick darauf werfen. Hast Du Deine Einträge überhaupt geclaimed? Wenn nicht, wird es Zeit!