KI-Texte schlecht für SEO? Google misst nicht, ob du KI benutzt – sondern wie viel von dir selbst in deinem Text steckt
Jeder will KI zur Content-Erstellung einsetzen. Aber niemand will KI-Texte lesen, und KI-Einsatz per se im Content-Produktionsprozess schadet der SEO-Performance. Stimmt das überhaupt?
Ich will ehrlich sein: Wer KI nicht einsetzt, um in der Content-Produktion produktiver zu werden, ist ehrlicherweise und salopp formuliert ziemlich blöd. LLMs sind das mächtigste Recherche- und Formulierungswerkzeug, das unsere Branche je hatte. Wer das ignoriert, weil „echte Texte von Menschen geschrieben sein müssen“, hat nicht verstanden, wie diese Werkzeuge funktionieren – und was sie leisten können, wenn man sie richtig einsetzt.
Wer KI allerdings benutzt, um das Internet mit substanzlosem Müll zu fluten, ist auf eine andere Art blöd und handelt fahrlässig. Nicht nur sich selbst gegenüber, sondern gegenüber allen, die im Web nach Antworten suchen.
Ich erlebe es in meiner Arbeit regelmäßig: diese Erwartungshaltung an LLMs, Texte auf Knopfdruck zu generieren. Kein Briefing, kein Kontext, kein Fachwissen als Input – ein Prompt aus sieben Wörtern, und am Ende soll ein Fachartikel stehen, der unter dem eigenen Namen veröffentlicht wird. Jetzt mal im Ernst: Was soll das?
Ich verstehe die Intention dahinter bis heute nicht. Etwas zu publizieren, das zu 99 Prozent von einer Maschine stammt, ohne eigene Perspektive, ohne eigene Beispiele, ohne einen einzigen Gedanken, den nicht auch jeder andere mit demselben Prompt hätte produzieren können – das ist kein Content. Und natürlich können diese Inhalte auch absolut gar nichts zu einem fachlichen Diskurs beitragen.
Aber sei es drum. Denn die eigentlich relevante Frage ist nicht, ob KI-Einsatz erlaubt ist, sondern wo die Grenze zwischen sinnvollem Einsatz und Substanzlosigkeit verläuft.
Googles Search Liaison Danny Sullivan hat es schon im November 2022 auf den Punkt gebracht: „We haven’t said AI content is bad. We’ve said, pretty clearly, content written primarily for search engines rather than humans is the issue.“
Im Februar 2023 legte Google auf dem Search Central Blog nach: Der angemessene Einsatz von KI verstößt nicht gegen die Richtlinien. Und im September 2023 änderte Google den Wortlaut seiner Helpful-Content-Dokumentation von „content written by people“ zu „content created for people“. Das ist mehr als eine Nuance:
Die Herkunft deines Contents ist der Suchmaschine egal. Sein Zweck zählt.
Die richtige Frage muss demnach eine andere sein. Sie ergibt sich aus dem, was im Mai 2024 öffentlich wurde: über 14.000 Attribute aus Googles internem Content Warehouse, bekannt als Content Warehouse API Leak. Darunter ein Attribut namens contentEffort, beschrieben als „LLM-based effort estimation for article pages“. Eine auf einem Large Language Model basierende Schätzung des Aufwands, der in eine Seite geflossen ist. Die richtige Frage, die du dir also stellen musst, könnte lauten:
Habe ich so viel persönlichen Aufwand in meinen Text gesteckt, dass eine KI diesen nicht so einfach reproduzieren könnte?
Für Google zählt also nicht die Frage, ob ein Mensch den Text getippt hat, auch nicht ob ChatGPT, Gemini oder Claude beteiligt waren, sondern ob erkennbar ist, dass ein Mensch Aufwand investiert hat.
Sicher wirst du nun aber dieselbe Frage haben, die ich auch hatte: Wie, bitte sehr, misst eine Maschine – selbst mit Künstlicher Intelligenz – den menschlichen Input hinter einem Text?
Was contentEffort tatsächlich misst – und was nicht
Bevor wir darüber reden, was Content Effort für den Einsatz von KI bedeutet, müssen wir verstehen, was dieses Attribut technisch ist. Nicht was Experten hineininterpretieren, nicht was gut klingt, sondern was die Dokumentation tatsächlich hergibt und wo die Interpretation beginnt. Ich will das hier sauber trennen.
Was die Dokumentation sagt
Das Attribut contentEffort existiert innerhalb des QualityNsrPQData-Moduls. Dieses Modul sitzt im Kern von Googles pageQuality-Framework – also dort, wo die Qualitätsbewertung einzelner Seiten stattfindet. Die Beschreibung im Leak lautet wörtlich: „LLM-based effort estimation for article pages.“
Drei Dinge stecken in diesem Satz, die man einzeln auseinandernehmen muss.
- Erstens: „LLM-based.“ Die Bewertung erfolgt durch ein Large Language Model und nicht durch einfache heuristische Verfahren wie beispielsweise das Zählen von Wörtern. Ein LLM verarbeitet Text als Vektorrepräsentationen: Jedes Wort, jeder Satz wird in eine numerische Position übersetzt, die seine Bedeutung und seine Beziehung zum umgebenden Kontext abbildet. Dadurch kann das Modell prinzipiell unterscheiden, ob ein Absatz eine generische Wiederholung bekannter Zusammenhänge enthält oder eine spezifische Schlussfolgerung aus einem konkreten Kontext zieht – weil sich die Vektormuster dieser beiden Texttypen mathematisch unterscheiden. Was genau Googles konkretes Modell dabei bewertet und wie präzise es arbeitet, geht aus der Dokumentation nicht hervor.
- Zweitens: „effort estimation.“ Es ist eine Schätzung, keine exakte Messung. Das ist ein wichtiger Unterschied zu anderen Attributen im Leak, die auf mathematischen Berechnungen basieren. Dazu gleich mehr.
- Drittens: „for article pages.“ Die Dokumentation benennt explizit Artikelseiten als Anwendungsbereich. Ob das Attribut auch auf andere Seitentypen angewendet wird, geht daraus nicht hervor.
Ein technisches Detail sollte dabei nicht untergehen: contentEffort wird als VersionedFloatSignal gespeichert. Das bedeutet, Google hält nicht nur den aktuellen Wert fest, sondern führt ein historisches Protokoll. Ob Google aus dieser Versionierung aktiv einen Trend berechnet, geht aus der Dokumentation nicht hervor. Shaun Anderson – einer der SEOs, die den Leak am gründlichsten aufgearbeitet haben – interpretiert das Speicherformat als Hinweis auf das, was er „algorithmic momentum“ nennt: Google bewerte demnach nicht den Zustand einer Seite, sondern den Verlauf.
Das passt zu meiner Beobachtung, dass inhaltliche Verbesserungen oft Wochen brauchen, bis sie sich in den Rankings niederschlagen. Wenn Google den Trend trackt und nicht nur den aktuellen Stand, würde das diesen Verzögerungseffekt erklären. Aber es gibt auch andere mögliche Erklärungen – Crawl-Zyklen, Index-Updates, die Akkumulation von NavBoost-Daten. Ich kann nicht belegen, dass die Versionierung die Ursache ist.
Was Content Effort nicht ist
contentEffort operiert nicht allein. Es ist ein Attribut innerhalb eines Ökosystems, und die anderen Bausteine dieses Systems funktionieren technisch unterschiedlich. Das ist wichtig, weil man sie nicht über einen Kamm scheren darf.
OriginalContentScore sitzt im PerDocData-Modul und misst die Einzigartigkeit des Inhalts auf Dokumentebene auf einer fein aufgelösten Skala. Das ist kein qualitatives Analyse-Urteil wie bei contentEffort, sondern – nach allem, was die Dokumentation nahelegt – eine Messung: ein Abgleich gegen bestehende Inhalte im Index.
Die Dokumentation vermerkt, dass dieses Attribut speziell für Seiten mit wenig Text vorgesehen ist – etwa eine Produktseite, deren Beschreibung aus dem Herstellertext besteht, den auch hundert andere Shops verwenden. Es beantwortet die Frage: Gibt es diesen Text schon woanders oder ist er einzigartig?
siteFocusScore und siteRadius sitzen im QualityNsrNsrData-Modul und arbeiten auf einer anderen Ebene: nicht das einzelne Dokument wird betrachtet, sondern die gesamte Domain. Diese beiden Attribute basieren auf site2vecEmbeddingEncoded – einer komprimierten Vektor-Repräsentation des gesamten Website-Inhalts. Dabei handelt es sich um eine mathematische Berechnung im Vektorraum: Wie kohärent ist die thematische Ausrichtung dieser Website, und wie weit weicht ein einzelnes Dokument von ihrem thematischen Zentrum ab?
Anderson verwendet dafür eine hilfreiche Analogie: Stell dir deine Website als Sonnensystem vor. Das Kernthema ist die Sonne. Jede Seite ist ein Planet. siteRadius ist die Umlaufbahn eines einzelnen Planeten – je enger, desto näher am Thema. siteFocusScore bemisst die thematische Kohärenz des gesamten Systems. Eine Website, auf der alle Planeten bzw. Seiten eng um die Sonne kreisen, hat einen hohen siteFocusScore. Eine Website, deren Planeten thematisch stärker variieren – heute SEO, morgen Finanzen, übermorgen Medizin –, hat einen niedrigen.
Ein Punkt, den Anderson besonders betont und der vor Fehlschlüssen schützt:
Thematischer Fokus ist nicht dasselbe wie Qualität.
Die Zeitung Die Zeit zum Beispiel hat zweifellos einen hohen Q*-Score – Googles Gesamtbewertung für die Vertrauenswürdigkeit einer Domain. Aber sie hat keinen hohen siteFocusScore, weil sie Hunderte Themen abdeckt. Sie ist ein Generalist.
Umgekehrt kann eine thematisch stark fokussierte Nischenseite einen hohen siteFocusScore haben, aber einen niedrigen Q*-Score – weil der contentEffort der einzelnen Artikel gering ist, die Inhalte keine Originalität aufweisen, oder weil die Domain über siteAuthority keine externen Vertrauenssignale wie Backlinks oder Brand-Erwähnungen aufgebaut hat. Thematischer Fokus allein macht keine Qualität.
Aber die beiden Ebenen interagieren: Eine thematisch kohärente Website liefert den Rahmen, in dem ein hoher contentEffort-Wert seine volle Wirkung entfalten kann. Oder umgekehrt formuliert: Ein hervorragender Einzelartikel auf einer thematisch zerstreuten Domain hat es schwerer als derselbe Artikel auf einer thematischen enger ausgerichteten Domain.
Das ist auch der Grund, warum ich in meinem Topical-Map-Artikel geschrieben habe, dass die Architektur der Website genauso wichtig ist wie die Qualität einzelner Dokumente. contentEffort ist kein Attribut, das du isoliert optimieren kannst. Es ist eingebettet in ein System, das die gesamte Domain bewertet – und zwar auf unterschiedlichen Ebenen mit unterschiedlichen Methoden.
Was das LLM wahrscheinlich bewertet – und wo die Interpretation beginnt
Die geleakte Dokumentation benennt Attribute, aber nicht die exakten Bewertungskriterien. Wir haben die Variablennamen, aber nicht die Gewichtungen. Google-Ingenieur HJ Kim – der als Entwickler von NavBoost gilt – formulierte es in einer DOJ-Vernehmung vom Februar 2025 so: Der Leak benenne zwar Komponenten des Ranking-Systems, gehe aber nicht auf die „curves and thresholds“ ein, also die konkreten Kurven und Schwellenwerte, nach denen die Signale gewichtet werden. Die Dokumentation allein reiche nicht aus, um das System zu rekonstruieren.
Hintergrund
Was ist der DOJ-Prozess gegen Google?
Im Oktober 2020 verklagte das US-Justizministerium (Department of Justice) Google wegen illegaler Monopolbildung im Suchmaschinen- und Suchanzeigenmarkt. Im Verlauf des Prozesses sagten hochrangige Google-Ingenieure unter Eid aus – darunter Pandu Nayak (VP of Search) und Hyung-Jin Kim (Entwickler von NavBoost). Ihre Aussagen lieferten erstmals bestätigte Einblicke in Googles Ranking-Architektur: die Zwei-Säulen-Struktur aus Q* (Quality) und P* (Popularity), die Rolle von Klickdaten über NavBoost und die Funktionsweise handgefertigter Ranking-Signale. Die Prozessdokumente sind öffentlich einsehbar.
Dislcaimer: Was ich im Folgenden zusammenfasse, sind Schlussfolgerungen mehrerer unabhängiger SEOs und ihrer beeindruckenden Analysen. Es handelt sich dabei also nicht um meine Leistung, ich stelle diese nur kontextuell in Beziehung zueinander. Sie sind plausibel, aber sie sind teils Interpretationen. Ich kennzeichne das bewusst, weil es mir wichtig ist, dass du als Leser weißt, wo die Datenlage aufhört und die Expertenmeinung anfängt.
Replizierbarkeit ist die Dimension, bei der die Einigkeit unter den Analysten am größten zu sein scheint. Anderson formuliert es so: contentEffort ist im Kern ein Maß gegen die Austauschbarkeit von Inhalten. Die zentrale Frage scheint zu sein: Wie leicht kann diese Seite nachgebaut werden? Und zwar nicht von einem Konkurrenten mit mehr Budget, sondern von jeder Person mit Zugang zu einem LLM und fünf Minuten Zeit.
Denk an einen typischen SEO-Ratgeber zum Thema „Title Tags optimieren“. Solch einen Text wirst du bestimmt irgendwann gelesen haben. Tausende existieren, die meisten geben dieselben Informationen wieder: Platziere das Keyword vorne, halte unter 60 Zeichen ein, verwende einen einzigartigen Title pro Seite. Solch ein Artikel ist in Minuten mit KI generierbar, ohne großen menschlichen Input.
Jetzt stell dir dagegen einen Artikel vor, der anhand eigener Search-Console-Daten zeigt, wie eine systematische Umformulierung der Title Tags über ein konkretes Projekt hinweg die CTR in einem bestimmten Segment verändert hat – mit Vorher-nachher-Werten und der Erkenntnis, dass die Veränderung nur unter bestimmten Bedingungen eintrat. Diesen Artikel kann ein LLM allein nicht reproduzieren, weil die Erkenntnisse aus einem individuellen Projektbeispiel stammen.
Originalität der Information ist eng mit Replizierbarkeit verwandt – so eng, dass man sie als zwei Seiten derselben Medaille betrachten kann. Ein Text ist schwer replizierbar, weil er originäre Information enthält: eigene Daten, eigene Analysen, eigene Schlussfolgerungen, die vor seiner Veröffentlichung nicht im Web oder im Google-Index existierten. Ich trenne die beiden Aspekte hier trotzdem, weil sie im Leak auf unterschiedliche Attribute verweisen – contentEffort für den Aufwand, OriginalContentScore für die Einzigartigkeit. Aber die Logik dahinter ist dieselbe: Was nur du liefern kannst, hat mehr Wert als das, was jeder liefern könnte.
Multimediale Eigenleistung ist eine weitere plausible Dimension, bei der ich allerdings vorsichtiger bin als bei Replizierbarkeit. Mehrere Analysen, die ich gelesen habe, gehen davon aus, dass das LLM zwischen generischen Stock-Medien und eigens erstellten Visuals unterscheiden kann. Der Grund für meine Vorsicht: Während die Replizierbarkeitsthese von mehreren unabhängigen Analysten geteilt wird, stützt sich die Multimedia-Unterscheidung stärker auf Annahmen darüber, was ein LLM visuell erkennen kann – und das ist spekulativer. Das Prinzip ist aber konsistent: Zu Stockfotos hat jeder Zugang. Ein Diagramm, das deine eigene Analyse visualisiert, kann nur erstellen, wer die Analyse selbst durchgeführt hat.
Struktur und linguistische Merkmale verdienen mehr als eine beiläufige Erwähnung. Logische Überschriften-Hierarchie, Quellenangaben, die Korrektheit des Fachvokabulars – das sind Hinweise auf die Tiefe der Auseinandersetzung mit einem Thema. Die Entscheidung, genau dieses Google-Patent in genau diesem Argumentationskontext zu verwenden, ist eine menschliche Kuratierungsleistung – nicht weil eine KI das Patent nicht kennt, sondern weil die Passgenauigkeit zwischen Quelle und Argument einen Denkprozess voraussetzt, den kein Prompt automatisiert.
Das Zusammenspiel: Q* und P*
contentEffort existiert nicht in einem Vakuum, aber es existiert auch nicht in einer Hierarchie mit Klickdaten. Um zu verstehen, wie diese Signale zusammenwirken, muss man die Architektur kennen, die im DOJ-Prozess unter Eid bestätigt wurde.
Googles Ranking basiert auf zwei übergeordneten Signalen: Q* und P*.
Q* steht für Quality – eine primär auf Domain-Ebene wirkende Bewertung von Vertrauenswürdigkeit über inhaltliche Substanz, die Google-Ingenieur HJ Kim im DOJ-Prozess als „largely static and largely related to the site rather than the query“ beschrieb. In Q* fließen Signale auf verschiedenen Ebenen ein: Attribute auf Dokumentebene wie contentEffort ebenso wie Attribute auf Domain-Ebene wie siteAuthority. Q* aggregiert diese Signale zu einem Gesamtbild der Domain – was erklärt, warum die Qualität einzelner Artikel die Domain-Bewertung beeinflusst, und warum die Domain-Bewertung bestimmt, wie viel Sichtbarkeit ein einzelner Artikel überhaupt erreichen kann.
P* steht für Popularity und wird maßgeblich durch NavBoost gespeist, ein System, das im DOJ-Prozess von Google-VP Pandu Nayak als „eines der wichtigsten Signale“ bestätigt wurde. NavBoost ist im Kern eine riesige Tabelle: Für diese Suchanfrage hat dieses Dokument so viele Klicks bekommen plus wie viele Nutzer anschließend zur Suche zurückkehren. Dr. Eric Lehman beschrieb es unter Eid als „just a big table“ – für viele überraschend kein Machine-Learning-System, sondern aggregierte Klick- und Nutzerdaten über ein zyklisches 13-Monats-Fenster. P* bewertet die Passung zwischen einem Dokument und einer konkreten Suchanfrage über Nutzerengagement.
Warum das wichtig ist: Stell dir vor, du schreibst einen Fachartikel über Passage Indexing mit eigener Analyse, Patentverweisen, konkreten Beispielen aus der Search Console. Hoher Content Effort, hoher Q*-Beitrag. Google spielt den Artikel für zwei verschiedene Suchanfragen aus. Query A: „Was ist Passage Indexing?“ – dein Artikel beantwortet diese Frage im zweiten Absatz, der Nutzer bleibt, liest weiter, kehrt nicht zur Suche zurück. Gute NavBoost-Daten für diese Query. Query B: „Passage Indexing aktivieren“ – der Nutzer sucht eine technische Anleitung, findet bei dir einen konzeptionellen Fachartikel, klickt sofort zurück zur Suche. Schlechte NavBoost-Daten für diese Query.
Derselbe Artikel, derselbe contentEffort-Wert – aber unterschiedliche P*- bzw. NavBoost-Werte je nach Query. NavBoost „bestraft“ hier nicht die Qualität deines Artikels. Es korrigiert die Ausspielung: Für Query B wirst du langfristig nicht mehr angezeigt, für Query A bleibst du stabil.
Merke also: Qualität ohne Relevanz ist unsichtbar. Relevanz ohne Qualität ist kurzlebig.
Was wir nicht wissen
Drei Dinge muss ich offen einräumen.
- Erstens: Ob
contentEffortaktiv im Ranking verwendet wird oder nur intern getrackt wird, ohne direkte Auswirkung auf die Suchergebnisse, weiß ich nicht. Die Dokumentation beschreibt, was das Attribut tut – nicht, ob es eingeschaltet ist. - Zweitens: Für welche Suchanfragen der Check ausgelöst wird, weiß ich auch nicht. Aus dem DOJ-Prozess wissen wir, dass Pandu Nayak bestätigt hat, dass nicht jeder Algorithmus für jede Seite läuft – die Rechenkosten wären schlicht zu hoch.
- Drittens: Die exakten Gewichtungen sind unbekannt. Wir kennen die Architektur, aber nicht die Bedienungsanleitung.
Diese Ehrlichkeit ist mir wichtig. Wer auf Basis des API Leaks so tut, als hätte er Googles Algorithmus entschlüsselt, betreibt genau die Art von Halbwissen-Vermittlung, die ich in meinem Artikel über gute und schlechte SEOs kritisiert habe. Was wir haben, ist ein bisher einmalig detaillierter Blick in die Architektur. Das ist viel. Aber es ist eben nicht alles.
Das Helpful Content Update: Was wirklich passiert ist
Anderson argumentiert explizit: contentEffort sei das technische Fundament des Helpful Content Systems – oder zumindest ein wesentlicher Teil davon. Das ist eine plausible Interpretation, aber es ist seine Interpretation. Google hat diese Verbindung nicht bestätigt. Und die Geschichte des HCU selbst zeigt, warum man sie differenzierter betrachten sollte. Denn die Lücke zwischen dem, was Google ankündigt, und dem, was technisch dahintersteckt, ist größer als die Branche es gerne hätte.
Olaf Kopp hat diese Geschichte so gründlich aufgearbeitet wie kaum jemand sonst in der deutschsprachigen SEO-Branche – in einem kritischen Rückblick bei Search Engine Land und einer ausführlichen Analyse bei SISTRIX. Ich fasse seine Einordnung hier zusammen, weil sie für das Verständnis von contentEffort wesentlich ist.
Kopps zentrale These: Das erste Helpful Content Update im August 2022 sei in erster Linie eine professionell orchestrierte PR-Kampagne gewesen. Google kündigte das Update vorab an, informierte einflussreiche SEOs exklusiv, wählte einen sprechenden Titel und gab konkrete Handlungsempfehlungen – alles Muster, die bei Core Updates unüblich sind.
Die Branche reagierte mit massiver Aufmerksamkeit. Aber die messbaren Auswirkungen auf die Suchergebnisse blieben überschaubar. Betroffen waren hauptsächlich Klingeltöne-, Lyrics- und Coding-Seiten – Kategorien, die weder zum angekündigten Fokus auf Expertise noch zur erwarteten Abwertung von KI-Content passten.
Olaf Kopp identifiziert zwei strategische Ziele hinter der Kampagne: die Botschaft „Google wird hilfreicher“ verbreiten und Website-Betreiber dazu bewegen, weniger minderwertigen Content zu produzieren. Letzteres nützt Google unmittelbar, weil es die Kosten für Crawling und Indizierung senkt.
In einem späteren Artikel geht Olaf Kopp noch einen Schritt weiter. Er argumentiert, dass Google mit dem Helpful Content System nicht die Eigenschaften des Contents selbst bewerte, sondern ob der Content die Nutzerbedürfnisse befriedige. Er unterscheidet dafür zwischen Relevanz (passt das Dokument zur Suchanfrage?), Pertinenz (hat es subjektive Bedeutung für den konkreten Nutzer?) und Nützlichkeit (bringt es dem Nutzer etwas Neues?) – und schlussfolgert, dass „Helpful Content System“ eigentlich „User Satisfaction System“ heißen müsste.
Was danach kam
Auf das erste vergleichsweise wirkungslose HCU folgte im September 2023 ein zweites Helpful Content Update, und dieses Mal blieben die Auswirkungen nicht aus. Ganze Website-Kategorien verloren einen Großteil ihrer organischen Sichtbarkeit: Reiseblogs, Affiliate-Seiten, informationelle Websites mit Online-Tools. Diese Kategorien passten deutlich besser zum angekündigten Fokus des HCU als die Klingeltöne-Seiten von 2022, was nahelegt, dass Google zwischen dem ersten und zweiten Update nachgeschärft hat.
Im März 2024 folgte ein Core Update mit neuen Spam-Richtlinien gegen „Scaled Content Abuse“. Und im Mai 2024 wurde der API Leak öffentlich – mit dem contentEffort-Attribut.
Ob diese Chronologie einen kausalen Zusammenhang abbildet, kann ich nicht belegen. Aber die zeitliche Abfolge legt nahe, dass die technische Infrastruktur schrittweise aufgebaut wurde. Der API Leak zeigt die Attribute, die dabei entstanden sind.
Warum das für die Einordnung von Content Effort wichtig ist
Googles Botschaft war immer: Erstellt hilfreichen Content für Menschen, nicht für Suchmaschinen. Das ist eine gute Empfehlung. Aber es ist auch eine Empfehlung, die Google nützt, weil sie die Kosten für Crawling und Indizerung senkt, wenn weniger Müll im Index landet.
Die Datenlage aus dem API Leak und dem DOJ-Prozess zeigt ein System, das differenzierter arbeitet als Googles öffentliche Kommunikation vermuten lässt:
contentEffortmisst nicht „Helpfulness“ – es schätzt den investierten menschlichen Aufwand.- NavBoost misst nicht „Qualität“ – es misst Klickverhalten pro Suchanfrage.
siteFocusScoremisst nicht „Autorität“ – es berechnet thematische Kohärenz.
Offizielle Positionen und algorithmische Realität sind bei Google, wie die HCU-Chronologie zeigt, nicht immer dasselbe. Also schauen wir uns an, was die Mechanik von contentEffort tatsächlich für verschiedene Arten des KI-Einsatzes bedeutet.
Drei Arten, KI in der Content-Produktion einzusetzen
Ich sehe in meiner Arbeit im Wesentlichen drei Szenarien, wie Menschen KI für Content einsetzen. Sie unterscheiden sich fundamental in dem, was sie produzieren – und damit in dem, was ein LLM-basiertes contentEffort-Attribut daraus lesen kann.
Szenario 1: KI als Textgenerator
Das ist das Szenario, das ich eingangs beschrieben habe – der Prompt aus sieben Wörtern ohne Kontext, Briefing oder Fachwissen. Die Frage ist: Was liest contentEffort daraus?
Das Ergebnis eines solchen Prompts ist grammatisch korrekt, thematisch plausibel, strukturell vorhersagbar. Es liest sich wie eine Zusammenfassung von allem, was bereits im Web existiert. Das LLM wurde auf genau diesen Inhalten trainiert und gibt eine statistische Verdichtung davon zurück. Es gibt keine Informationen, die signifikant von dem abweichen, was das Modell für dieses Thema standardmäßig produzieren würde. Keine Perspektive, die nur der Autor haben kann. Für eine Effort-Schätzung gibt es hier nichts zu finden, weil nahezu kein Aufwand betrieben wurde.
Szenario 2: KI als Recherche- und Formulierungsassistent
Das ist das Szenario, in dem ich selbst arbeite und das ich jedem empfehle, der Content ernst nimmt. Du hast ein Thema, das du durchdrungen hast – durch eigene Erfahrung, durch Primärquellen, durch Analyse. Du nutzt KI, um schneller an relevante Informationen zu kommen: Studien finden, Gegenargumente durchspielen, Zusammenhänge prüfen. Du nutzt KI, um Formulierungen zu testen, Strukturen zu iterieren, Entwürfe zu beschleunigen. Aber die Substanz – die These, die Beispiele, die Schlussfolgerungen, die Auswahl dessen, was relevant ist und was nicht – kommt von dir.
Der Text enthält Informationen, die vor seiner Veröffentlichung nicht im Web existierten: deine Analyse, deine Daten, deine Perspektive auf ein Problem. Kein anderer Mensch mit demselben LLM könnte diesen Artikel reproduzieren, weil die differenzierende Substanz nicht aus dem Modell kommt, sondern aus deinem Kopf.
Die KI hat mir bei meinen eigenen Artikeln geholfen, schneller zu formulieren. Aber sie hätte keinen davon allein schreiben können, weil die Kuratierungsleistung – was rein darf, was rausfliegt, wie die Argumentation aufgebaut wird – von mir stammt.
Szenario 3: KI als Skalierungsmaschine
Das ist das Szenario, das Google mit dem March 2024 Core Update und den neuen Spam-Richtlinien adressiert hat: „Scaled Content Abuse“. Hunderte oder Tausende Seiten, generiert mit minimaler menschlicher Beteiligung, oft für Long-Tail-Keywords, oft thematisch breit gestreut. Jede Seite für sich grammatisch sauber – aber in der Masse ein eindeutiges Muster: gleichförmige Struktur, vorhersagbare Absätze, keine einzigartige Information auf irgendeiner der Seiten.
Hier greifen gleich mehrere der Attribute, die wir besprochen haben. contentEffort pro Seite: niedrig, weil replizierbar. OriginalContentScore: niedrig, weil die Seiten untereinander und im Vergleich zu bestehenden Web-Inhalten wenig Einzigartiges bieten. siteFocusScore: potentiell beschädigt, wenn die Masse an Seiten das thematische Profil der Domain verwässert. Und auf der P*-Seite: Wenn diese Seiten ausgespielt werden und schlechte NavBoost-Daten erzeugen, korrigiert das System die Ausspielung pro Query.
Die Frage, die bleibt
Was diese drei Szenarien zeigt: Die Trennlinie verläuft nicht zwischen „KI benutzt“ und „KI nicht benutzt“. Sie verläuft zwischen replizierbar und nicht replizierbar.
Oder, um es mit Olaf Kopps Mantra zu sagen, das mir seit meiner ersten Lektüre im Kopf geblieben ist: „Think like an engineer, act like a human.“ Versteh die Mechanik, aber liefere substantiellen Mehrwert für den menschlichen Leser.
KI macht Content nicht billiger. KI macht den Text billiger. Das Formulieren, das Strukturieren, das Iterieren von Entwürfen – all das geht schneller als je zuvor. Aber der Text war nie der teure Teil. Der teure Teil war immer: das Thema durchdringen, die richtigen Quellen finden, die eigene Erfahrung in eine Analyse übersetzen, die Entscheidung treffen, was rein darf und was nicht. Und genau diesen Aufwand versucht contentEffort zu erfassen.
Wer das verstanden hat, stellt nicht mehr die Frage „Darf ich KI benutzen?“. Die Antwort ist ja – und zwar ausdrücklich. Die Frage, die bleibt, ist eine andere: Wo genau setze ich meinen menschlichen Aufwand ein, damit er zählt?
Die Antwort, die sich aus der Mechanik von contentEffort ergibt, ist grundlegender, als es eine Checkliste je sein könnte: Dort, wo das Ergebnis nicht replizierbar ist. Dort, wo deine spezifische Erfahrung, dein spezifisches Wissen, deine spezifische Perspektive den Unterschied macht zwischen einem Text, den jeder mit demselben Prompt hätte erzeugen können – und einem, den nur du schreiben konntest.
Quellen und weiterführende Lektüre
Dieser Artikel stützt sich auf Primärquellen sowie auf die Analysearbeit mehrerer unabhängiger Experten, ohne deren Vorarbeit dieser Artikel nicht möglich gewesen wäre.
Primärquellen:
- Google Search Central: Google Search’s guidance about AI-generated content (Februar 2023)
- Google Content Warehouse API Leak (Mai 2024) – über 14.000 Attribute aus Googles internem Content Warehouse
- U.S. Department of Justice v. Google LLC – Vernehmung HJ Kim, Februar 2025
Shaun Anderson / Hobo Web – Content Effort und API Leak:
Andersons Arbeit ist die umfassendste mir bekannte Aufarbeitung des API Leaks in Bezug auf Content-Qualitätssignale. Ohne seine Analyse der QualityNsrPQData-Architektur und des Zusammenspiels zwischen contentEffort, OriginalContentScore und siteFocusScore wäre mein Verständnis dieser Zusammenhänge deutlich oberflächlicher.
- What is Google’s Content Effort Signal?
- The ContentEffort Attribute, the Helpful Content System and E-E-A-T
- Google’s Leaked QualityNsrPQData: The Core of Page Quality Assessment
- Topical Authority: Site Radius & Site Focus Score from the Google Leak
- Navboost: How User Interactions Rank Websites in Google
- How Google Works in 2025 – DOJ Antitrust Trial Disclosures
Olaf Kopp – HCU-Analyse und Helpful Content:
Olaf Kopp ist auch abseits des HCU eine SEO-Koryphäe, klar, aber seine kritische Einordnung des ersten Helpful Content Updates hat meine Perspektive auf Googles Update-Kommunikation grundlegend verändert. Seine Unterscheidung zwischen Relevanz, Pertinenz und Nützlichkeit liefert den konzeptionellen Rahmen, den die meisten HCU-Analysen vermissen lassen.
- Google’s Helpful Content Update: A Critical Recap (Search Engine Land)
- Ein kritisches Recap des Helpful Content Update (SISTRIX)
- Helpful content: What Google really evaluates?
Über diesen Artikel
Die inhaltliche Verantwortung für jeden Artikel auf diesem Blog liegt bei mir, Patrick Stolp. Thema, These, Recherche und fachliche Prüfung sind meine Arbeit – hier wird nichts veröffentlicht, das ich nicht selbst konzipiert, geschrieben und als korrekt verifiziert habe. Generative KI (Claude von Anthropic) kommt punktuell als Werkzeug zum Einsatz – etwa für Formulierungsentwürfe oder das Gegenlesen technischer Erklärungen. Kein KI-Output landet ungeprüft oder unverändert auf dieser Seite. Beitragsbilder werden mit Google Nano Banana 2 erstellt.
Mehr dazu in meinen Redaktionsrichtlinien.
