Google Preferred Sources: der eine AI-Search-Hebel, den du wirklich ziehen kannst

Fast alles, was dir als "AI Search Optimization" verkauft wird, ist geraten. Niemand hat die Gewichte. Niemand hat die Logs. Es ist Astrologie mit einem Slack-Channel.

Und dann gibt es Preferred Sources, das genaue Gegenteil davon. Ein Leser klickt einen Button, Google schreibt es auf, und ab diesem Moment werden deine Artikel für genau diesen Menschen anders behandelt: eher in den Top Stories, und mit einem sichtbaren Badge in AI Overviews und im AI Mode. Kein Signal, das du dir verdienen musst, kein Schema, das du erfinden musst, kein Berater nötig. Du musst nur fragen.

Über 600.000 Seiten wurden schon von irgendjemandem ausgewählt. Seit dem 20. August 2026 kannst du diese Frage direkt auf deine eigene Seite packen, statt zu hoffen, dass Leser ein Einstellungsmenü finden, von dem sie noch nie gehört haben. Ich habe es letzten Monat für einen Kunden eingebaut, es hat ungefähr eine halbe Stunde gedauert, und eine dieser dreißig Minuten habe ich auf eine Seite gestarrt, die völlig in Ordnung aussah, während das Ganze still tot war. Dazu später mehr.

600.000 Quellen, und 255.000 davon seit Mai

Hier ist die Wachstumskurve, denn sie sagt dir, ob das ein Feature ist, zu dem Google steht, oder eins, das leise wieder verschwindet.

Während des begrenzten Tests, der im August 2025 startete, hatten Leser knapp 90.000 einzelne Quellen ausgewählt. Ende Mai 2026 waren es 345.000. Am 20. August 2026, als Google den Publisher-Button ausrollte, waren es über 600.000. Rund 255.000 davon kamen in weniger als drei Monaten dazu, und der Sprung fällt fast exakt damit zusammen, dass Google die Funktion am 27. Mai auf den AI Mode und die AI Overviews ausgeweitet hat.

Die Mechanik selbst ist simpel. Ein Leser geht in Googles Quelleneinstellungen, oder klickt deinen Button, und markiert deine Seite als eine, von der er mehr sehen will. Die Einstellung hängt an diesem Leser, an seinem Konto, bis er sie ändert. Es ist keine seitenweite Ranking-Eigenschaft. Es gibt keine API, kein Markup, keinen Score. Heißt: Niemand kann dir eine "Preferred-Sources-Strategie" verkaufen, und wenn es jemand versucht, weißt du jetzt genug, um Nein zu sagen.

Was Google wirklich dokumentiert, und was nicht

Bei diesem Teil will ich vorsichtig sein, denn die Zahl, die überall zitiert wird, muss mehr tragen, als sie kann.

Googles Dokumentation sagt zwei verschiedene Dinge über zwei verschiedene Oberflächen, und die Leute rühren daraus ständig eine einzige Behauptung. Für die Top Stories (in der deutschen Doku heißen sie "Schlagzeilen") steht dort, deine Inhalte werden "eher" dort angezeigt und mit einem Badge als "bevorzugt" gekennzeichnet. Das ist ein Sichtbarkeitseffekt. Für den AI Mode und die AI Overviews (deutsch: "KI-Modus" und "Übersichten mit KI") steht dort, deine Inhalte "können mit einem Badge als bevorzugt hervorgehoben werden" für Nutzer, die deine Seite ausgewählt haben. Das ist ein Kennzeichnungseffekt, kein Sichtbarkeitseffekt.

Der Unterschied zählt. Als Google die Funktion im Mai auf den AI Mode ausgeweitet hat, hat sich nicht geändert, welche Quellen die KI auswählt. Es kam ein Badge auf Links von Quellen, die der Leser ohnehin schon gewählt hatte. Wenn du also hoffst, dass Preferred Sources dich in eine AI Overview bringt, in der du sonst nicht aufgetaucht wärst: Das hat Google so nicht gesagt, und ich habe nichts gesehen, was etwas anderes zeigt. Für dieses Problem bist du wieder bei der ganz normalen Arbeit, über die ich in So wirst du von ChatGPT zitiert (was eine Studie mit 1,4 Mio. Prompts wirklich ergab) geschrieben habe.

Und dann die berühmte Zahl. Nick Fox, bei Google SVP für Knowledge and Information, sagte, Leute klicken doppelt so wahrscheinlich auf eine Seite durch, nachdem sie sie als bevorzugte Quelle markiert haben. Das ist Googles eigene Untersuchung, keine unabhängige, und lies den Nenner mit: doppelt so wahrscheinlich, unter Lesern, die dich mochten genug, um sich aktiv dafür zu entscheiden. Das sind Menschen, die sowieso schon geneigt waren zu klicken. Die ehrliche Lesart ist nicht "verdopple deinen Traffic". Sie ist "deine bestehenden Leser verlieren dich nicht mehr im Rauschen".

Und genau das ist, wenn du zugesehen hast, wie eine AI-Zusammenfassung still den Traffic aufsaugt, der früher auf deiner Seite ankam, eigentlich das, was du wolltest. Die Symptome habe ich in 6 Anzeichen, dass dein Traffic-Einbruch ein AI-Overview-Problem ist, kein Ranking-Problem durchgegangen. Das hier repariert den Algorithmus nicht. Es stellt deinen Namen wieder vor die Leute, die dich schon einmal gewählt haben.

Meine eigene Vermutung, als Vermutung gekennzeichnet: Für die meisten Nicht-News-Seiten ist das Badge vermutlich mehr wert als der Top-Stories-Effekt, weil ein Badge ein Vertrauenssignal in genau dem Moment ist, in dem ein Leser entscheidet, ob er einen Link in einer KI-Antwort anklickt. Beweisen kann ich das nicht. Google hat keine Zahl veröffentlicht, die die beiden Oberflächen trennt.

Funktioniert das überhaupt auf Deutsch? Ja, seit dem Frühjahr

Das musst du wissen, bevor du irgendwem etwas versprichst, denn fast alles, was du dazu liest, kommt aus den USA und aus einer Zeit, in der die Funktion nur auf Englisch lief.

Der Start im August 2025 war ein begrenzter Test. Das ist vorbei. Googles eigene Dokumentation sagt heute: Für Schlagzeilen ist die Funktion weltweit in allen Sprachen verfügbar, in denen es die Google Suche gibt. Für den KI-Modus und Übersichten mit KI gilt dasselbe, in allen Sprachen und Gebieten, in denen es diese Funktionen gibt. Auf Deutsch lief es ab Ende April 2026, und ab Juli 2026 waren die "bevorzugt"-Badges auch auf deutschen Suchergebnisseiten in den AI Overviews zu sehen.

Praktisch heißt das: Ein Leser mit deutschem Google-Konto kann deine Domain heute auswählen, und es wirkt. Die Einstellungsseite ist dieselbe URL, sie kommt nur auf Deutsch. Der Publisher-Button und das SDK sind sprachunabhängig, du baust exakt denselben Code ein wie eine US-Seite. Der einzige echte Unterschied ist dein Button-Text, und dazu sage ich weiter unten noch etwas.

Ein Punkt, bei dem ich mich nicht festlege: ob im deutschsprachigen Raum schon genug Leser das Feature überhaupt kennen, damit relevante Zahlen dabei rauskommen. Die 600.000 Quellen sind eine globale Zahl. Wie viele davon deutsche Domains sind, hat Google nicht aufgeschlüsselt, und ich habe keine Grundlage zu raten.

Prüf die Eligibility, bevor du eine einzige Zeile Code schreibst

In den Quelleneinstellungen tauchen nur Seiten auf Domain- und Subdomain-Ebene auf. Googles eigenes Beispiel: https://www.example.com/ und https://code.example.com/ sind zulässig. https://www.example.com/blog ist es nicht, war es nie, und es gibt keinen Umweg.

Ich hätte das beinahe für einen Kunden eingeplant, dessen kompletter redaktioneller Output in einem Unterverzeichnis liegt. Zwanzig Sekunden Prüfen hätten mir ein Gespräch erspart, das ich danach zurückrudern musste. Also nimm dir die zwanzig Sekunden: bei einem Google-Konto anmelden, google.com/preferences/source öffnen, deine Domain suchen. Taucht sie nicht auf, hör auf. Es gibt nichts zu bauen.

Zwei Dinge werden hier regelmäßig falsch verstanden. Erstens: Es ist nicht auf News beschränkt. Googles Doku begrenzt es nirgends auf Nachrichtenverlage, und jede Seite, die regelmäßig frische Inhalte veröffentlicht, kann infrage kommen. Zweitens: Wenn du in diesem Tool auftauchst, behandelt Google dich in der Regel bereits als Publikation. Für die fünfseitige Seite eines Sanitärbetriebs ist das ein Ziel, keine Dienstagnachmittags-Aufgabe. Wenn du zwei Beiträge im Jahr veröffentlichst, löse erst das, und komm dann wieder.

Und du kannst das weder aus dem Terminal noch ausgeloggt prüfen. Es braucht ein echtes, eingeloggtes Google-Konto, was mäßig nervig ist und gut zu wissen, bevor du einem Kunden eine Antwort in fünf Minuten versprichst.

Die ganze Implementierung sind zwei Zeilen

Googles Standardversion:

<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>
<div google-add-preferred-source-btn></div>

Das gibt dir Googles Button in Googles Styling, das du nicht ändern kannst. Auf einer Seite mit echter Designsprache liest er sich wie eine Anzeige und wird weggescrollt. Deshalb wollen die meisten Projekte den manuellen Modus, bei dem du das SDK mit einem Attribut lädst und dein eigenes Element bindest:

<script async preferred-sources-control="manual"
  src="https://news.google.com/swg/js/v1/publisher.js"></script>

Eine Regel würde ich in keinem Framework aufweichen: Mach den Button zu einem echten <a> mit einem echten href auf den Deeplink, und ruf preventDefault() im Click-Handler erst auf, wenn das SDK tatsächlich gebunden hat. Kein href="#" plus onClick. Das Script ist async, Adblocker haben news.google.com auf dem Schirm, und deine eigenen Security-Header können es abschießen. Ein Link, der immer funktioniert und manchmal aufgewertet wird, schlägt einen Button, der manchmal nichts tut.

Das andere, was beißt: Lad das SDK einmal pro Seite, nicht einmal pro Button. Zwei Buttons, einer am Artikelende und einer im Footer, ist das normale Layout. In Next.js dedupliziert next/script mit einer stabilen id, und nimm onReady statt onLoad, damit sich der Callback bei clientseitigen Navigationen neu registriert. In Astro wird ein verarbeitetes <script> gehoistet und genau einmal gebundelt, egal wie oft die Komponente rendert. is:inline ist das, was es dupliziert, und dann registriert sich der Queue-Callback zweimal und jeder Klick feuert doppelt.

Meine CSP hat das Script gefressen und niemand hat es mir gesagt

Das ist die Stunde, die ich verloren habe, und das Praktischste in diesem ganzen Beitrag.

Wenn deine Seite einen Content-Security-Policy-Header ausliefert, und das tut jede Seite, die ich in den letzten drei Jahren gebaut habe, dann weigert sich der Browser, Googles Script zu laden, und die Seite sieht völlig normal aus. Kein kaputtes Layout. Kein Fehler-Toast. Der Button rendert weiterhin, denn er ist ja nur ein Anchor-Tag. Er wird nur nie zum eigentlichen Flow auf der Seite. Nie.

Drei Direktiven müssen angefasst werden, nicht eine:

script-src  … https://news.google.com
connect-src … https://news.google.com
frame-src   … https://news.google.com https://www.google.com

frame-src ist die, die alle vergessen, denn du merkst erst, dass du sie brauchst, nachdem du script-src repariert hast und dann feststellst, dass der Flow einen Service-Iframe und ein Popup öffnet. Finde die CSP, bevor du die Komponente schreibst, nicht danach. Sie versteckt sich in public/_headers bei Cloudflare Pages, in netlify.toml, in vercel.json, im Header-Block von next.config, in einer Middleware mit Nonce pro Request oder in einem <meta http-equiv> im Base-Layout. Das hier beendet die Diskussion in einer Sekunde:

curl -sI https://deineseite.de/ | grep -i content-security-policy

Ein Projekt ganz ohne CSP ist eine gültige Antwort. Dann gibt es nichts zu ändern, und du sagst das auch, statt eine Policy zu erfinden, weil es sich gründlich anfühlt. Und wenn du eine hast, verdient der Rest davon vermutlich auch einen Blick, was ungefähr die Checkliste in Die Website-Sicherheits-Checkliste (Keine Plugins, kein BS) ist.

Verifizieren sind vier Checks in einem echten Browser, in dieser Reihenfolge. Konsole auf eine CSP-Verletzung prüfen, das ist meistens schon die Antwort. Dann bestätigen, dass das Tag mit intaktem Attribut gelandet ist. Dann ein paar Sekunden warten und typeof window.PREFERRED_SOURCE prüfen: "object" heißt, das SDK hat die Queue abgearbeitet und alles ist gut, "array" heißt, das SDK wurde nie geladen, "undefined" heißt, dein Registrierungscode ist nie gelaufen. Drei verschiedene Bugs. Dann klicken, und die Seite darf nicht navigieren. Auf localhost meldet das SDK publicationId=publication-id-free, was alarmierend aussieht und keins ist. Google löst die echte Publikation über die Live-Domain auf.

Der Link, den du überall reinpacken kannst, zählt mehr als der Button

Der Button auf der Seite erreicht nur Leute, die schon auf deiner Seite sind. Und das ist, wenn du dir Sorgen machst, dass AI Search deine Leser abfängt, genau die Gruppe, um die du dir am wenigsten Sorgen machen musst.

Das andere Deliverable braucht überhaupt kein JavaScript:

https://www.google.com/preferences/source?q=example.com

Das gehört in deinen Newsletter-Footer, in deine Social-Bios, ans Ende einer Podcast-Beschreibung, unter einen LinkedIn-Post. Es funktioniert überall dort, wo du kein Script einschleusen kannst, also an den meisten Orten, an denen deine wiederkehrenden Leser tatsächlich Zeit verbringen. Pack ein UTM dran, und du hast die einzigen Klickdaten, die du zu diesem Feature jemals bekommen wirst.

Der Text zählt hier mehr als die Platzierung, und auf Deutsch noch ein Stück mehr. "Add to Preferred Sources" sagt einem normalen Menschen genau nichts, und "Als bevorzugte Quelle hinzufügen" klingt wie eine Schaltfläche aus einem Behördenformular. Etwas näher an "Wenn dir diese Beiträge was bringen, sag Google, dass du mehr davon willst" erklärt wenigstens, worum du bittest. Ich habe noch nicht genug Volumen darüber, um zu beweisen, dass das besser ist. Ich sage dir, dass es eine Vermutung ist, weil es eine ist.

Niemand kann das messen, auch Googles eigene Tools nicht

Die Search Console hat keine Preferred-Sources-Dimension. Nicht versteckt, nicht verzögert. Sie sagt dir nicht, wie viele Leser dich ausgewählt haben, wie oft das Badge zu sehen war oder welcher Anteil deiner Google-Klicks über die Mechanik kam. GA4 kippt jeden dieser Klicks als google / organic in denselben Topf wie alles andere.

Angesichts dessen, wie viel die Search Console in letzter Zeit dazubekommen hat, inklusive der AI-Traffic-Zahlen, durch die ich mich in Google Search Console zeigt jetzt AI-Traffic. Das sagen meine Zahlen. gegraben habe, ist diese Lücke eher auffällig als zufällig.

Du bekommst also zwei schwache Hilfsgrößen. Klicks auf den UTM-getaggten Deeplink, die die Frage messen und nicht das Ergebnis. Und Brand-Search-Trends über einen Zeitraum, der lang genug ist, um etwas zu bedeuten, und der ein Dutzend Dinge gleichzeitig misst. Ich schaue mir trotzdem beides an, und ich tue nicht so, als würde eins davon Kausalität beweisen.

Hier lande ich. Auf einer zulässigen Domain ist das ein 30-Minuten-Job. Er verlangt nicht, dass du Googles Absichten errätst, was ihn gerade in eine sehr kleine Kategorie stellt, und über den Rest des Felds habe ich in GEO ist das neue Schlangenöl (oder doch nicht?) genug gesagt. Er bringt dich nicht dorthin, wo du ohnehin nicht zitiert worden wärst. Er taucht in keinem Report auf. Was er tut: Er gibt den Lesern, die dich ohnehin mögen, einen Weg, Google genau das zu sagen, und hält die KI-Schicht davon ab, dich still bei den Leuten zu ersetzen, die dich ursprünglich gewählt haben.

Wenn jemand prüfen soll, ob deine Domain überhaupt infrage kommt, bevor du dafür ein Angebot einholst, melde dich. Ich sage dir ehrlich, wenn die Antwort Nein lautet, und bei einem Blog im Unterverzeichnis lautet sie das immer.