Moin! Und wieder einmal scheitert der Versuch, alle Artikel in einer einzigen aussagekräftigen Headline zusammenzufassen.

Dabei ist echt viel los. Das Pfund stürzt ab. In Berlin stürzen Weltrekorde und Flo stürzt sich auf die SEO-Wiesn .

Was ich aber versucht hatte zusammenzufassen:

• Matt ist verwirrt (über Zitatmengen bei wissenschaftlichen Werken)

• Andreas ist entspannt (weil er in Garys News keine News finden kann)

• Nils ist offen für einen neuen Crawler

• Johan prüft automatisiert ob Text automatisiert erstellt wurde

Jetzt aber ran an die Wortwolken:

Hast Du bei Google in den letzten Tagen einmal nach wissenschaftlichen oder medizinischen Artikeln gesucht?

Falls ja, ist Dir vielleicht etwas aufgefallen: Bei wissenschaftlichen und medizinischen Publikationen wird im Snippet neuerdings nicht mehr nur die übliche Meta Description ausgespielt, sondern auch der Name des Autors bzw. der Autorin, das Erscheinungsjahr der Veröffentlichung und die Zahl, wie häufig der Artikel von anderen Quellen zitiert wurde.

Das sieht in der SERP dann folgendermaßen aus:

Oder so:

Sieht erstmal toll aus, nicht wahr?

Stimmt. Allerdings ist hier Vorsicht geboten! Bei genauerer Betrachtung fällt nämlich auf, dass sich die Anzahl der Zitate, die in der SERP angezeigt wird, meist nicht mit denen des Artikels decken. Um bei unserem Beispiel von gerade zu bleiben:

Hier ist auf der linken Seite die Rede von lediglich 57 Quellen, die auf die Publikation verweisen, und nicht von 147 wie im Snippet bei Google behauptet.

Besonders kurios wird die Angelegenheit, wenn man nach einem speziellen Werk sucht: Hier kann es nämlich passieren, dass für das gleiche Werk plötzlich unterschiedliche Zahlen angezeigt werden. Im folgenden Beispiel ist demnach beim ersten Ergebnis die Rede von 249 Zitationen, beim zweiten Ergebnis von 250:

Da stellt sich doch die Frage: Woher nimmt sich Google die Zahl, die im Snippet ausgespielt wird und wieso weicht sie mitunter so deutlich von der echten Anzahl ab? Es lohnt sich sicher, das Ganze in nächster Zeit etwas genauer im Auge zu behalten.

Anfang des Monats hat Gary Illyes wieder einmal eine Frage zum Crawl-Budget einer Website beantwortet . Dabei ging es um die Frage, ob sich die unterschiedlichen Crawler von Google eigentlich das Crawl-Budget einer Website teilen. Und die Antwort lautet "ja" und er ging noch einen Schritt weiter und betonte noch einmal, dass es auch für jeden Host (also auch Subdomains) ein unterschiedliches Crawl-Budget gibt. Warum mich diese Antwort erst einmal kalt lässt? Ganz einfach: Da wir das eigentliche Crawl-Budget für einen Host nicht kennen und die wenigsten Websites überhaupt ein Problem mit dem Crawl-Budget haben, ist diese Information erst einmal so interessant wie ein SEO-Streit zwischen Subdomain und Folder.

Hintergrund: Die Antwort ist eigentlich für uns SEOs nichts Neues. Schon lange war klar, dass das Crawl-Budget auch für jegliche Content-Elemente wie Bilder, Videos, PDFs usw. zählte. Interessant könnte es aber werden, wenn sich wirklich alle Google-Bots das Crawl-Budget teilen müssten. Darunter\ befinden sich natürlich Crawler, die erstens nichts mit der organischen Suche zu tun haben und zweitens ggf. sogar erst durch Benutzerinteraktion (Google Read Aloud-Dienst) ausgelöst werden. Alleine schon der Gedanke an einen Benutzer, der eine Anfrage an den Google Read Aloud-Dienst bei einem überzogenen Crawl-Budget stellt, lässt schon vermuten, dass wir nicht alle Crawler über einen Kamm scheren sollten bzw. können.

Daher gilt für uns: Sicherlich handelt es sich dabei um eine interessante Information, die aber nicht unbedingt sehr viel Neues auftut.

Daher gilt weiterhin: Vermeide unnötige URLs da wo sie entstehen. Gerade wenn es sich um Parameter-URLs wie Filterfacetten oder eine interne Suchfunktion handelt entstehen an diesen Stellen häufig unnötig viele URL-Variationen mit nahezu identischen Inhalten. Neben der Tatsache, dass solche URLs die URL-Warteschlange von Google verstopfen und damit unnötig an unserem Crawl-Budget nagen, bringen diese URLs natürlich weitere Probleme für uns SEOs mit sich (Near DC, Soft 404, etc.).

Bei den Wingmen nehmen wir Announcements über neue Tools in der Regel so gleichgültig entgegen wie ein Hamburger den Nieselregen dieser Jahreszeit. Das hängt damit zusammen, dass beides relativ häufig vorkommt. Der Unterschied dabei ist, dass man beim Regen weiß, was einen erwartet. Wenn ein neues Tool angekündigt wird, sind häufig erstmal viele Versprechungen dabei, von denen man im Vorfeld nicht weiß, ob sie auch gehalten werden können.

Das gilt für Tools im Allgemeinen und auch für (SEO-)Crawler. Davon haben wir auch schon einige kommen und gehen sehen. Nun sind wir allerdings ein wenig hellhöriger geworden als sonst. Das liegt an dem " Artikel Horseman SEO Crawler. And why you REALLY (!) need it. " von Christian Hänsel. Er erzählt darin von ein paar Features des Crawlers "Horseman", der von Chris Johnson aka @defaced ins Leben gerufen wurde. Von Chris habt ihr womöglich schon mal ein SEO-Tool benutzt, davon hat er schon so einige programmiert. Ich finde zum Beispiel seinen Layout Shift Generator ganz nett. Dort kann man eine URL reinschmeißen und bekommt ein kleines GIF, das CLS-Quellen in einem bunten Rahmen hervorhebt.

Seit einer Weile arbeitet er aber schon an dem Crawler. Der Artikel von Christian hebt insbesondere die Möglichkeiten durch die Verwendung von Headless Chrome und dem damit verbundenen Zugriff auf JavaScript hervor. Die Möglichkeit, eigene Code-Schnipsel im Crawler zu erstellen und zu verwenden, klingt schon sehr spannend. Auch wenn man dafür natürlich erstmal Javascript beherrschen oder  zumindest ein geeignetes Stück Code per Copy/Paste einfügen können muss.

Im Gegensatz zu vielen anderen Tools von Chris ist der Crawler allerdings nicht kostenlos verfügbar. Zugriff erhält man, wenn man ihn bei Github sponsert. Falls Dir Dein bisheriger Werkzeugkasten an zu vielen Stellen Grenzen aufzeigt und dich ein neues Tool nicht abschreckt, dann könnte Horseman für Dich interessant sein. Insbesondere bei der potentiellen Individualisierung sehen wir hier viele Möglichkeiten. Wenn Dir der Screaming Frog bisher immer gereicht hat, brauchst Du aber nicht umsteigen.

Im Helpful Content Update ist eine Gruppe betroffener Seiten relativ klar: Diejenigen mit mittelmäßigem oder schlechtem automatisierten Content.

Stellt sich also noch mal die Fragen: Dürfen wir denn jetzt automatisierten Content verwenden oder nicht?

Für mich ist die Antwort ganz klar: Natürlich dürfen wir. Solange der Content gut genug ist. Und das meint nicht nur Orthographie und Satzbau, sondern vor allem den Inhalt. Google ist es am Ende egal, wie der Content zustande kommt: Ob automatisiert generiert, handgeschrieben und digitalisiert, gesprochen und transkribiert oder wie auch immer. Wichtig ist der Inhalt des Contents.

Technisch ist es vergleichsweise einfach, auch gut gemachte Automatisierungen zu erkennen . Aber es geht nicht darum, wie der Text erstellt wurde, sondern ob er hilfreich und qualitativ hochwertig ist.

Natürlich gibt es bei der Automatisierung ein paar Probleme zu bedenken: Erstmal habe ich keinen Autor, dem ich den Text zuweisen kann. Aber natürlich könnte man den Weg gehen, dass man den menschlichen Reviewer, der die Abnahme vor dem Livestellen übernimmt, als Autor führt.

Wie machst Du das? Nutzt Du GPT-3 und Konsorten, um Content aus Deinen Briefings werden zu lassen? Lässt Du den Bot gleich ganze Artikel schreiben? Oder einen Vorschlag, damit Deine Autoren einen Ansatzpunkt haben?