Wirklich wahres Wingmen SEO Wissen fĂŒr wache Webmarketer #257 |
|
|
đ FĂŒnf Jahre. Ein Newsletter. |
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
|
|
UXler + SEOs + Entwickler = â„ïž |
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:
âOur shared objective is to enhance interoperability between web platforms, thereby simplifying the work of developers and enriching the overall experience for internet users.[...]Ultimately, Interop strives to eliminate inconsistencies between browsers and foster a unified vision within the industry.â (Quelle)
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:
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.
|
|
He was pretty Splitt about JavaScript Part 2 |
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:
Do not use [Web Worker] to fetch content without user interaction; the rendering service does funny things.
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.
|
|
UX Camp 2.0: UX messbar machen |
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.
|
|
Schnelle Nummer: Ist Google wirklich schlechter geworden? |
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
"[âŠ] when a man someone is capable of being in uncertainties, mysteries, doubts, without any irritable reaching after fact and reason."
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:
- 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?
|
|
5 Denkfehler, die Deine Datenanalyse trĂŒben â und wie Du sie vermeidest |
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:
- Hinterfrage Deine eigene Annahme aktiv.
- Schau nicht nur auf das, was funktioniert â sondern auch auf das, was fehlt.
- Hol Dir öfter mal eine zweite Sichtweise.
- Bewerte Zahlen im Kontext, nicht isoliert.
- 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.
|
|
Â
|
Fragen? Immer gerne fragen!
|
Wir sind fĂŒr Dich da.
Schreib uns gern jederzeit
eine E-Mail an [email protected] oder
ruf uns einfach kurz an: +49 40 22868040
Bis bald,
Deine Wingmenschen
|
|
Anckelmannsplatz 1, 20537 Hamburg, Germany
|
|