Es war einmal, an einem Mittwochnachmittag, dem 20 Mai 2020 um 15:14 Uhr, da schickten wir mutig unseren allerersten SEO-Newsletter hinaus in die große, weite Welt. Noch etwas scheu, aber mit klopfendem Herz und ordentlich Keyword-Magie im Gepäck, machte er sich auf den Weg durch Postfächer, Spamfilter und morgendliche Kaffee-Routinen. Und siehe da: Einige treue Leser*innen nahmen ihn auf, lasen ihn und wollten mehr. Das ist mittlerweile fünf Jahre her. Auf den heutigen Tag genau FÜNF!

Deshalb wird in dieser Woche nicht nur informiert, sondern auch gefeiert! Und zwar mit diesen ganz besonderen Geburtstagsgästen:

• Kerzenkünstlerin Kriemhild mit einem Recap zum UX Barcamp Bremen
• Ballonbändiger Behrend mit Teil zwei zu Martins Vortrag auf dem Tech SEO Summit 2025
• Konfettikönigin Cleo, die versucht UX messbar zu machen
• Party-Philipp, der untersucht, ob die Google Suche tatsächlich schlechter geworden ist
• Deko-Darius mit 5 Denkfehler im Arbeitsalltag

Also, Lieblingsmensch vorm Screen: Mach’s Dir gemütlich, schnapp Dir ein virtuelles Stück SEO-Torte und lass Dich von uns wie jeden Dienstagmorgen anlächeln.

Auf die nächsten fünf Jahre! Deine Wingmenschen

Am 09.05.25 durften Cleo und ich in eine etwas andere Bubble eintauchen. Wir haben das UX Camp Bremen 2025 in der Bremer Überseestadt besucht. Hier hatten Designer, Entwickler und natürlich auch SEOs die Möglichkeit, sich im Rahmen eines Barcamps über die verschiedensten Themen auszutauschen. Das Event startete mit einer inspirierenden Keynote von Ida Persson, die den Einfluss von Design kritisch beleuchtete und auf die möglichen negativen, sowie positiven Einflussfaktoren von Design hinwies.

Danach folgte die Sessionplanung und aus den geplanten 15 wurden am Ende sogar 19.

Mach dir das Leben nicht unnötig schwer - Native HTML Elemente

Als erstes schnappte ich mir einen Platz bei Timur Çelikel, Front End Developer, UX- und UI- Experte, der das Thema “Nutzung von nativen HTML Elementen” zur Diskussion stellte.

Native HTML-Elemente sind standardisierte, vom Browser direkt unterstützte HTML-Tags wie <button>, <form>, <select>, usw. Diese Elemente bringen bereits von Haus aus eine semantische Bedeutung, Standardverhalten, Tastatursteuerung und Styles mit. Sie unterscheiden sich von benutzerdefinierten Komponenten oder JavaScript Lösungen.

Nach einer Einführung von Timur in das Thema, folgte ein spannender Austausch zwischen allen, in dem Vor- und Nachteile herausgestellt wurden:

Vorteile für Entwickler, UXler und SEOs:

• Einfachheit: Weniger Code für Standardverhalten (z. B. <button> ist automatisch klickbar, fokussierbar)
• Konsistenz: Einheitliches Verhalten über Browser hinweg (Standardkonformität)
• Wartbarkeit: Leichter zu lesen, zu pflegen und zu debuggen
• Zeitersparnis: Kein Neuentwickeln von Grundfunktionen wie Datepicker
• Vertrautheit: In vielen Fällen kennen Nutzer das Verhalten (z. B. wie ein <select> funktioniert)
• Responsives Verhalten: Viele native Elemente passen sich automatisch Bildschirmgrößen an
• Performance: Schnellere Ladezeiten durch weniger JavaScript und einfache HTML Struktur
• Darstellung: Einfache Anpassung durch CSS (z. B. mit appearance: none; Entfernt natives Styling oder all: unset; Entfernt alle Styles und Verhalten → ACHTUNG: erzeugt wiederum wesentlichen Mehraufwand)
• Semantik: Suchmaschinen verstehen native Elemente in der Regel ohne Probleme
• Screenreader-Kompatibilität: Native Elemente haben automatisch richtige ARIA-Rollen und beschreibende Labels
• Tastaturbedienbarkeit: Eingebaute Keyboard-Navigation (z. B. mit <button>)
• Fokusmanagement: Automatisch korrektes Fokusverhalten ohne Extra-Code

Nachteile:

• Eingeschränkte Designflexibilität: Native Elemente sehen je nach Betriebssystem und Browser unterschiedlich aus und verhalten sich teils leicht unterschiedlich – was ein konsistentes UI-Design erschweren kann
• Limitierter Funktionsumfang: Custom-UI-Komponenten (z. B. die Auswahlmöglichkeit einer Daterange) erfordern oft eigenes Verhalten und lassen sich schwer mit ausschließlich nativen Mitteln umsetzen
• Eingeschränkte Interaktivität: Einige komplexe Interaktionen (z. B. Drag-and-Drop) sind mit nativen Elementen schwer oder gar nicht umsetzbar

Sehr interessant fand ich die Initiative der großen Browser-Anbietern, die seit 2022 stattfindet:

Was ich für mich mitgenommen habe:

• Native HTML-Elemente sind eine sichere Bank für Standardinteraktionen, weil sie mit Barrierefreiheit, SEO und Usability von Haus aus kommen
• Für einfache oder standardisierte Interaktionen (z. B. Formulare, Navigation, Buttons) sollte der Einsatz stets bevorzugt geprüft werden
• Custom-Elemente sollten nur verwendet werden, wenn native Elemente funktional oder gestalterisch nicht ausreichen

Fokus auf Minimalismus & Effizienz

Die zwei Themen “Nachhaltigkeit” und “Barrierefreiheit” zogen sich eingeleitet durch die Keynote durch den gesamten Tag.

Die prägnantesten Punkte des Tages in aller Kürze:

• Weniger ist mehr: Nutze einfache responsive Layouts und reduziere unnötige Animationen
• Reduziere die Dateigrößen (Bilder, Videos, Fonts)
• Verwende moderne Bildformate (z. B. WebP) und Lazy Loading
• Wähle einen Hosting-Anbieter, der auf erneuerbare Energien setzt
• Nutze standardisierte, gut dokumentierte Technologien
• Vermeide veraltete Plugins
• Baue sauberen Code: semantisches HTML
• Sinnvolle Seitenstruktur: So viele URLs wie nötig, aber so wenig URLs wie möglich

Natürlich muss immer abgewogen werden, welche Maßnahmen im Hinblick auf das Unternehmen umgesetzt werden können. Ein minimalistisches Design der Website passt nicht zu jeder Brand, aber zum Glück gibt es viele Möglichkeiten, wenigstens ein bisschen nachhaltiger zu werden.

Das Thema “Barrierefreiheit” war ebenfalls sehr präsent, aber da Sandra über dieses Thema bereits mehrfach berichtet hat, kommt dazu zu einem späteren Zeitpunkt sicher nochmal ein Beitrag von uns.

Falls Du jetzt schon mehr erfahren willst und Sandras Beiträge verpasst hast:

• Sag “Nein” zu Accessibility-Overlays
• Accessibility Checks mit Screaming Frog 21.0

Fazit:

Lass die Bereiche Entwicklung, Design und SEO noch mehr zusammenwachsen und vor allem die Kommunikation besser werden. So können wir alle unsere Projekte viel besser umsetzen und uns gegenseitig supporten.

Denn was mir stark aufgefallen ist, wir schauen teilweise auf dieselben KPIs (worüber Cleo Dir in ihrem Beitrag noch mehr erzählt), wir brauchen an ähnlichen Stellen Ressourcen und Überzeugungskraft und wir verfolgen die gleichen Ziele.

Fragt nach und schafft gegenseitiges Verständnis für die Bereiche in Eurem Unternehmen.

In unserem Newsletter von letzter Woche habe ich schon angefangen, über Martins Vortrag auf dem Tech SEO Summit 2025 zu erzählen. Was bei async und defer, Minify und Komprimieren zu beachten ist und was zur Hölle Layout Thrashing ist, hatte ich Dir schon zusammengefasst.

Jetzt geht es weiter mit dem JavaScript Deep Dive:

Code Splitting & Loadable Components

Es macht Sinn, den Code sinnvoll aufzuteilen. Seit HTTP/2 müssen wir nicht mehr die Zahl der Requests klein halten. Ein großes Code-Bundle ist nicht mehr sinnvoll.

Das JavaScript für die Animation im Footer muss nicht zusammen mit allem anderen übertragen werden. Und irgendein Skript-Schnipsel, das nur für das Tabellenelement auf der Dankeseite der Newsletteranmeldung gebraucht wird, schon gar nicht.

Schneide lieber den Code in funktionelle Bestandteile und lade das, was gebraucht wird, dort, wo es gebraucht wird.

Moderne Frameworks bieten dafür auch sinnvolle Lösungen. Für React gibt es beispielsweise Loadable Components.

Wenn ein Relaunch ansteht, sollte das von Grund auf mitgedacht werden.

Denn: Wenn das nicht von Anfang an mitgedacht wurde, ist das ein ganz schönes Brett, das nachzuziehen. Vielleicht reicht schon das gezielte Auslagern bestimmter Komponenten für eine 80/20-Lösung.

Animations

Das ist jetzt genau genommen kein reines JavaScript-Thema, sondern gilt auch für CSS-Animationen.

Die Kurzfassung ist: Wenn man Elemente verschiebt und jedes Frame einen Paint auslöst, ist das unpraktisch. Es gibt Varianten, Animationen zu bauen, die das nicht tun – die wesentlich performanter sind.

Für die längere Fassung verweise ich Dich wieder auf Dokumentationen. Beispielsweise den Animations Guide von web.dev oder diesen Guide zu CSS- und JS-Animations und Performance in den MDN Web Docs.

Debouncing, Long Tasks, Web Workers und Co.

Ein großes Performance-Problem ist der Main Thread. Standardmäßig arbeiten Browser nur in einem Thread mit der CPU. Und solange der Main Thread voll ist, kann der Browser auf nichts anderes reagieren. Das kann beim Rendern dazu führen, dass Frames droppen. Dann sieht die Seite ruckelig aus. Noch schlimmer: Währenddessen kann der Browser nicht auf Nutzerinteraktionen reagieren.

Damit das nicht passiert, sollte man lange, teure Operationen vermeiden.

Nicht alle Reaktionen auf Nutzerinteraktionen sollten immer ausgeführt werden. Wenn viele Nutzerinteraktionen hintereinander kommen und aufwändig zu verarbeiten sind, sollte vielleicht nicht jedes Mal das ganze Feuerwerk losgehen.

Als Beispiel wählte Martin Suggests bei Suchen. Nicht bei jedem getippten Buchstaben sollte Deine Suche neue Suggests abholen. Suggests sind ein relativ teurer Prozess, und es reicht vermutlich – oder ist besser –, ein paar Millisekunden zu warten, bis ein Nutzer das erste Wort fertig getippt hat. Die Zauberworte hierbei heißen Debouncing und Throttling. FreeCodeCamp hat, finde ich, die Idee von Debouncing gut dargestellt.

Außerdem gibt es noch die Möglichkeit, Prozesse, die nicht synchron stattfinden müssen, auszulagern. Web Worker ist hier das Zauberwort.

Martin hat dabei noch auf die WebGL-API hingewiesen, mit der sogar die GPU mit einbezogen werden kann.

Dann hat Martin noch das Fass mit scheduler: yield() aufgemacht. Das wirkte für mich eher nach schwarzer Magie als nach JavaScript – aber es gibt bestimmt die ein oder andere Stelle, wo das sinnvoll eingesetzt werden kann.

Im Nebensatz zu den Web Workern gab es dann aber noch ein kleines SEO-Nugget. Sinngemäß war die Aussage zu Web Workern:

Das hat mich aufhorchen lassen.

Klar. Googlebot führt keine Nutzerinteraktionen aus, insofern ist Inhalt, der erst auf Nutzerinteraktion in den DOM-Tree kommt, für Google unsichtbar.

Solange der Inhalt ohne Nutzerinteraktion nachgeladen wird, kann Google das normalerweise rendern. Und auch mit Lazy Loading kommt Google klar. John Mu hat klargestellt, dass Google dafür schlicht einen seeehr langen Viewport verwendet.

Wenn Google die Inhalte trotzdem nicht sieht, ist häufig das entsprechende Third-Party-Skript für Googlebot via robots.txt gesperrt (bei Taboola, Outbrain und Co. zum Beispiel geschieht das sehr bewusst).

Aber wenn Deine Inhalte nicht sauber gerendert werden und Du beim Debugging alles Offensichtliche abgeklopft hast, dann guck doch mal, ob das Lazy Loading vielleicht in einen Web Worker ausgelagert wurde.

Fazit:

Das war ein schöner Vortrag mit Live Coding, bei dem nicht nur SEOs, sondern auch Frontend-Entwickler eine ganze Menge lernen konnten.

Die kurze Zusammenfassung ist:

Nutze JavaScript nur dann, wenn Du es auch wirklich brauchst – und dann nutze es weise.

Und sonst:

Don’t use JavaScript.

In einem vorherigen Artikel erzählt Kriemhild davon, wie das UX Camp den historischen Schuppen Eins in Bremen in einen brodelnden Ideenkessel verwandelt hat. Zwischen Keynotes, spontanen sonnigen Session-Slots auf der Terrasse und spannenden, produktiven Diskussionen tauchte bald eine Frage auf, die jedes Team kennt, das um Budgets kämpft: Wie begründet/verargumentiert man eigentlich User Experience und womit belegt man ihren Wert?

Was UX ist und wo sie beginnt

Die Norm ISO 9241-210 fasst UX als *„A person's perceptions and responses that result from the use and/or anticipated use of a product, system or service.” *usability.de.

Genau das sprang mir gleich im ersten Slot ins Gesicht: Philip Köhler, Film-Nerd mit eigenem Projekt Movie Flip, bat uns um Feedback zu seiner Seite, die anhand von vier Fragen den nächsten Film zum Schauen empfiehlt. Das Versprechen: Keine endlose Netflix-Scrollerei mehr, sondern eine präzise, Deinen Bedürfnissen angepasste Filmempfehlung.

Aus einem “Ich schau mir die Seite mal an” wurde schnell eine richtige UX-Klinik. Wir hielten uns nicht mit Farben und Formen auf, sondern pflückten das gesamte Erlebnis auseinander und setzten es mit vielen kreativen und produktiven Ideen wieder zusammen.

Ich habe gelernt: UX startet, sobald jemand eine Werbung sieht oder eine App entdeckt, setzt sich während der Nutzung des Produkts fort und klingt erst nach der letzten Erinnerung wieder ab. Websites, Apps, Verpackungen oder der Sound des neuen Staubsaugers… selbst die Rechnung und der Newsletter: Alles gehört zu einer Erlebnis­kette. Das ist wichtig zu verstehen, denn genau in dieser Erkenntnis steckt der Grund, warum wir alle uns mit dem Thema beschäftigen sollten und dies nicht nur für UX Designer, sondern auch für die Entwickler, SEOs und weitere Abteilungen ein relevantes Thema ist.

Wie man UX verargumentiert → unsere Messpunkte

In einer spontan einberufenen Outdoor-Session fiel der Satz: „UX ist wichtig, aber verdammt schwer zu verargumentieren.“, obwohl es wie wir sehen einen so großen Umfang hat. Wie belegt man UX also in Zahlen? Auf Post-Its haben wir Metriken gesammelt:

Login-Quote und Monthly Active Users zeigen, ob Menschen nach der Registrierung wirklich aktiv werden. Der erste Lackmus­test dafür, ob Kund:innen das Produkt tatsächlich nutzen, weil das Produktversprechen aus der Werbung nicht nur eine leere Hülle war.

Interaktionen, Verweil­dauer und Absprung­rate erzählen, ob Inhalt und Bedienung fesseln oder vergraulen. Rutscht die Verweil­dauer, steigen meist auch die schnellen Rücksprünge in die Such­ergebnisse, ein guter Hinweis auf Verbesserungspotenzial.

Task Completion Time und Task Success Rate decken Reibungs­punkte in Journeys auf. Muss jeder zweite Warenkorb abgebrochen werden, liegt die TSR unter einer bestimmten individuellen-Prozent-Schmerzgrenze → 🔔Ding Ding: Handlungsbedarf!

Session-Recordings sind eine Idee um das Warum und Wo hinter Peaks und Tälern zu liefern. Wo passieren Rage Clicks? Was klappt gut und wo hängen User:innen fest?

Net Promoter Score, System Usability Scale und einfache Zählungen von Beschwerden machen Zufriedenheit, Loyalität und Support Aufwand zählbar. Sinkende Ticket­zahlen sind das Ziel.

Und schließlich ein weiterer gelber Zettel „Wertung & Ranking + Konkurrenz“ als Reminder, dass bessere UX auch in Sichtbarkeit, Bewertungen und Rankings messbar wird.

Gemeinsam spannen diese Kennzahlen ein Netz, das Adoption, Engagement, Effizienz und Stimmung zugleich erfasst, eine Sprache, die Controller genauso verstehen wie Designer.

Wenn UX und SEO dieselbe Sprache sprechen

Google stuft die Nutzer­signale stetig höher ein und betont, dass Seiten mit „gutem Nutzer­erlebnis“ bevorzugt werden. Schnelle Lade- und Reaktions­zeiten, stabile Layouts, niedrige Absprung­quoten, genau die Faktoren, die auch UX-Teams optimieren, fließen in Rankings ein. Steigt die Task Success Rate oder verlängert sich die Verweil­dauer, profitiert nicht nur das Erlebnis, sondern auch die organische Sichtbarkeit. Zwei Disziplinen, ein Handshake. 🤝

Fazit

Lass mich das kurz poetisch ausdrücken: UX beginnt beim ersten Erwartungs­flackern und endet mit dem letzten Erinnerungs­faden (online wie offline). Wer ihren Wert belegen will, “übersetzt” das Erlebnis in Kennzahlen, dann wird aus einer Idee eine belastbare Größe, die Projekt­budgets rechtfertigt.

Man hört und liest es immer wieder: Die Google Suche ist schlechter geworden.

Kann man das wirklich sagen? John Keats hat das Konzept der “Negative Capability” erfunden. Laut ihm beschreibt das

Wir sind schnell darin, Annahmen zu treffen, um dem Gefühl “ich weiß es nicht” oder “beides könnte stimmen” aus dem Weg gehen zu wollen. Gewissheit, die Antwort zu kennen, kann schnell zu einer kognitiven Verzerrung führen.

Darum habe ich eine Untersuchung zu dem Thema “Google wird immer schlechter” gestartet und meine Erkenntnisse in einem Text-Blockbuster mit Überlänge für Search Engine Land festgehalten.

Hinweis: Hier entlang zum Director’s Cut von “Is Google really getting worse? (Actually, it’s complicated)” inkl. Grafiken.

Nachfolgend eine handgeschriebene Rapid Fire Zusammenfassung des Inhalts:

• Suchqualität im Vakuum bezogen auf Endnutzer:innen ist zu kurz gedacht. Eine Sucherfahrung, die auf keinem nachhaltigen Geschäftsmodell fußt, ist keine Erfahrung, die uns langfristig etwas bringt.
• Google steckt in einem Zwiespalt aus unterschiedlichen Erwartungen und Anreizen.
• Was könnte Google schlechter gemacht haben? Viel Druck:
  • Shopping startet nicht mehr bei Google (neben Amazon gesellt sich jetzt auch OpenAI als Dorn im Auge hinzu)
  • Soziale Medien machen mehr Spaß und erzeugen Nachfrage
  • KI-Suchsysteme verändern, wie wir Informationen akquirieren und suchen + Google ist nicht genAI-Marktführer
  • Misstrauen gegenüber Google als Unternehmen
  • Mehrere Gerichtsverfahren, die den Handlungsspielraum begrenzen
• Google ist daher strategisch die meiste Zeit passiv, bedacht darauf, Fehler zu vermeiden und wenig aktiv bereit, Fehler zu machen.
• Viele Argumente, die man zu der Annahme findet, haben Lücken, lassen sich widerlegen oder sind subjektive Einschätzung und nicht objektiv anerkannt.
• Alle Datenpunkte, die wir haben, sind unzureichend.
  • Ein zu kurzfristiger Zeithorizont
  • Zu kleine Stichproben
  • Suggestivfragen, die negativ framen
  • Fehlende Replizierung (und Fehlinterpretation der Zielgruppe)
• Unabhängig von unzureichenden Daten denken wir trotzdem, dass Google schlechter ist, weil
  • Wir uns als die (einzige) Zielgruppe sehen
  • Wir ein sich selbst verstärkendes Narrativ aufgebaut haben
  • Wir lieber mit dem Finger auf andere zeigen
• Wenn uns die Suchqualität wirklich wichtig ist, müssen wir mit dem Müll und der Manipulation aufhören – sowohl in der SEO als auch bei LLMs.
• Was wirklich verrät, wie schlecht Google ist: Das, was wir tun – wäre Google wirklich so schlecht, wäre der Schmerz zu bleiben größer, als der Schmerz, zu wechseln.
• Wir können daher nicht mit Konfidenz und Gewissheit sagen, “Google ist schlechter geworden”.
• Google macht mehr Knete, hat mehr User und bessere Aktienkurse als jemals zuvor (abgesehen von kürzlichen, politischen Einflüssen und den Safari-News).
• Klar: Die Suche könnte besser sein, aber Google (als Gärtner:in) kann auch nur mit dem arbeiten, was an Pflanzen da ist (Content).
• In diesem lebendigen Ökosystem tragen wir alle Verantwortung. Wir alle müssen unser Päckchen in der Mission tragen, um das Internet und die Suche jeden Tag ein bisschen besser zu machen.
• Wenn uns das wirklich wichtig ist, dann tun wir das auch.

Klare Empfehlung: Lies den ganzen Artikel bei Search Engine Land. Ich habe 3,5k Wörter auf ca. 500 eingedampt und musste viel Fleisch am Knochen weglassen.

Was mich interessiert: Was denkst Du, vor allem nach dem Lesen des Artikels?

Daten sind das Rückgrat im Online Marketing. Wir analysieren, vergleichen und visualisieren, um dann Entscheidungen zu treffen: Landingpage A oder B? Attribution nach First Click oder Last Click? SEO-Fokus auf Keyword-Cluster X oder Y?

Aber: Dashboards zeigen Zahlen – aber keine Wahrheit. Die entsteht erst durch die richtige Einordnung.

Warum sind unsere Datenanalysen oft nicht so objektiv, wie wir glauben?

Unser Gehirn ist darauf ausgelegt, schnell und effizient zu denken, nicht unbedingt korrekt. Es filtert, vereinfacht und ergänzt Informationen, ohne dass wir es merken. Das war früher überlebenswichtig, heute führt es oft zu Fehlinterpretationen.

In der datengetriebenen Arbeitswelt kann genau das aber zu Fehlern führen und zwar ganz automatisch.

Denn unsere Interpretation von Daten ist alles andere als objektiv. Sie ist geprägt von unbewussten Denkmustern – sogenannten kognitiven Verzerrungen (Biases).

Warum wir Denkfehler vor allem bei anderen sehen und nicht bei uns selbst

Wenn wir auf die Fehler anderer schauen, sind wir oft gnadenlos klar: „Das war voreilig“, „Da wurde nicht sauber analysiert“, „Typischer Denkfehler“.

Bei uns selbst hingegen? Sehen wir vor allem gute Gründe: „Ich hatte wenig Zeit“, „Die Datenlage war unklar“, „Ich musste schnell entscheiden“.

Das hat einen Namen: den Blind-Spot Bias, eine kognitive Verzerrung, bei der wir uns selbst für objektiver und rationaler halten als andere.

Das liegt daran, dass wir unsere eigenen Gedanken von innen erleben – wir kennen unsere Absichten, unsere Argumente, unseren Kontext. Bei anderen sehen wir nur das Verhalten von außen. Und das wirkt oft unlogischer oder fehlerhafter, als es eigentlich ist.

Außerdem geben uns kognitive Verzerrungen ein Gefühl von Sicherheit. Sie helfen, Komplexität zu reduzieren und Entscheidungen schneller zu treffen. Deshalb wollen wir sie gar nicht immer erkennen – sie sind bequeme mentale Abkürzungen.

Aber kognitive Verzerrungen können im schlimmsten Fall dazu führen, dass wir die falschen Schlüsse ziehen, Budgets verschwenden oder echte Probleme übersehen.

Daher sind hier für Dich fünf typische Denkfehler, die Dir bei der Arbeit mit Daten begegnen können – und wie Du sie erkennst:

1. Confirmation Bias – Du findest, was Du suchst

Wenn Du eine klare Erwartung hast, interpretierst Du Daten meist so, dass sie genau diese Erwartung bestätigen. Widersprüchliches wird dabei oft unbewusst ausgeblendet.

Beispiel: Du bist überzeugt, dass Backlinks ein entscheidender Hebel für Deine SEO sind. Entsprechend interpretierst Du auch den kürzlich bekannt gewordenen Google-Leak unter dieser Prämisse – oder suchst gezielt nach Fällen, in denen Seiten mit weniger Links im Ranking gefallen sind.

Oder: Du hast viel Zeit und Budget in ein neues Content-Format gesteckt. Natürlich willst Du, dass es erfolgreich ist. Also analysierst Du Scrolltiefe oder Verweildauer und blendest aus, dass der Content seinen Fokus verloren hat, sich mit anderen Seiten kannibalisiert oder gar nicht mehr auf das Haupt-Keyword optimiert ist.

🔍 Was passiert?

Du blendest unbewusst alles aus, was nicht zur Erwartung passt. Auch gegenteilige Hinweise oder Schwächen übersiehst Du – weil Dein Fokus auf Bestätigung liegt.

🛠️ Was hilft?

• Formuliere aktiv Gegenthesen: „Was würde gegen meine Annahme sprechen?“
• Peer-Checks: Lass andere mit anderem Fokus auf die Daten blicken.
• Dokumentiere Ausgangsfragen und Alternativszenarien.

2. Availability Bias – was leicht abrufbar ist, wirkt relevanter

Was Dir gerade präsent oder emotional nah ist, erscheint automatisch wichtiger – auch wenn es objektiv kaum Bedeutung hat.

Beispiel: Du hast gerade einen Traffic-Drop nach einem Core Update analysiert – jetzt achtest Du bei jedem Projekt übertrieben auf Schwankungen, obwohl sie statistisch normal sind.

Oder: Du hast bei einem Kunden durch eine Snippet-Optimierung einen starken Anstieg erzielt – und glaubst nun, das sei immer der effektivste Hebel. Dass der Effekt oft nur beim ersten Mal stark ausfällt (insbesondere wenn dort die Hausaufgaben zuvor nicht gemacht wurden), wird leicht übersehen.

🔍 Was passiert? Ein einzelner Fall überstrahlt alle anderen. Du generalisierst eine Ausnahme – und setzt falsche Prioritäten.

🛠️ Was hilft?

• Daten im Kontext betrachten: „Wie oft ist das schon passiert?“
• Baselines definieren: Was ist normal? Was ist tatsächlich außergewöhnlich?
• Lass Dich nicht von Einzelbeobachtungen triggern, sondern analysiere Muster.

3. Survivorship Bias – Du siehst nur die Erfolgreichen

Erfolgreiche Fälle sind sichtbarer als gescheiterte – aber oft auch irreführend. Wer nur auf Gewinner schaut, lernt nichts aus dem Scheitern.

Beispiel: Du orientierst Dich an Zalando, Amazon oder anderen starken Wettbewerbern – und kopierst deren Setup, ohne zu sehen, wie viele mit ähnlicher Struktur gescheitert sind. Gerade “die Großen” machen nicht immer alles richtig, können es sich aber leisten. Du eventuell aber nicht!

Oder: Du analysierst nur Deine erfolgreichsten Landingpages – und vergisst, dass viele mit gleichem Aufbau nie Rankings erzielt haben.

🔍 Was passiert?

Du ziehst Schlüsse auf Basis einer verzerrten Auswahl. Die Erfolgreichen sind sichtbar – die Gescheiterten blendest Du aus.

🛠️ Was hilft?

• Auch „Flops“ auswerten: Was fehlt dort? Was unterscheidet sie?
• Bewerte Umsetzungen nicht nur nach Outcome, sondern nach Voraussetzungen.
• Denke Setup, Wettbewerb und Marktumfeld kritisch mit.

4. Anchoring – der erste Wert verzerrt alles

Du kennst das vielleicht aus Verhandlungen: Wir orientieren uns übermäßig an der ersten Zahl oder Info, die wir bekommen – egal, ob sie relevant ist oder nicht.

Beispiel: Dir wird gesagt, ein Artikel habe „nur“ 300 Wörter – Du hältst ihn sofort für zu kurz, obwohl er alle nötigen Infos enthält.

Oder: Du erinnerst Dich an ein Projekt, in dem eine bestimmte Bounce Rate oder eine andere Metrik als „gut“ galt – und bewertest nun eine andere Seite aus einer anderen Branche mit völlig anderem Nutzungsverhalten nach denselben Maßstäben.

🔍 Was passiert?

Ein erster Wert setzt unbewusst einen Rahmen – und beeinflusst Deine Beurteilung, auch wenn er willkürlich ist.

🛠️ Was hilft?

• Vergleichswerte immer kritisch hinterfragen:  „Woher kommt dieser Benchmark?“
• Baue eigene Zeitreihen auf und verlasse Dich nicht (nur) auf Branchen-Benchmarks.
• Treffe Einschätzungen erst nach einer vollständigen Analyse.

5. False Causality – Korrelation ist nicht gleich Kausalität

Zwei Ereignisse treten gemeinsam auf – und wir denken, das eine sei die Ursache des anderen. Dabei übersehen wir andere Einflussfaktoren.

Beispiel: Nach einem Relaunch sinken die Rankings – und Du machst sofort das neue Design verantwortlich. Dass auch interne Verlinkung und Seitenstruktur geändert wurden, bleibt unbeachtet.

Oder: Du setzt eine Maßnahme um – und gleichzeitig steigen die KPIs. Du schließt daraus auf einen Erfolg, ohne andere parallel laufende Änderungen zu prüfen.

🔍 Was passiert?

Du stellst einen falschen Ursache-Wirkung-Zusammenhang her – und ziehst voreilige Schlüsse.

🛠️ Was hilft?

• Ursachenkette visualisieren: Was hat sich wann, wie verändert?
• Sichere Dich ab, indem Du Zeitverläufe und Wechselwirkungen prüfst.
• Verfalle nicht sofort in den Aktionismus und prüfe erst Zusammenhänge.

Fazit: Analyse braucht Reflexion

Zahlen sind wichtig – aber sie sprechen nicht für sich selbst. Unsere Interpretation ist immer gefärbt: durch Erfahrung, Erwartung, Emotion. Gerade im datengetriebenen Online Marketing lohnt sich ein zweiter Blick.

Nur weil Du mit Daten arbeitest, heißt das noch lange nicht, dass Du objektiv entscheidest. Dein Gehirn will schnell, effizient und bestätigt denken. Und genau das führt zu Fehlern – ganz automatisch.

Wenn Du also künftig in Zahlen eintauchst, denk an diese fünf Punkte:

1. Hinterfrage Deine eigene Annahme aktiv.
2. Schau nicht nur auf das, was funktioniert – sondern auch auf das, was fehlt.
3. Hol Dir öfter mal eine zweite Sichtweise.
4. Bewerte Zahlen im Kontext, nicht isoliert.
5. Und akzeptiere, dass manche Zusammenhänge komplexer sind, als sie auf den ersten Blick wirken.

Denn wer Denkfehler erkennt, entscheidet besser – und holt mehr aus seinen Daten heraus.

💡 Dieser Artikel ist Teil einer kleinen Serie über Denkfehler im Online Marketing. In einer der nächsten Ausgaben schauen wir uns an, wie unser Kopf uns bei Entscheidungen austrickst – und was Du dagegen tun kannst. Gerade im SEO-Alltag, wo Unsicherheit und Komplexität zum Tagesgeschäft gehören, kann das einen echten Unterschied machen.