Projekte

SEO-Dashboard: fünf Datenquellen, eine Ansicht.

Eigenprojekt29. Juli 2026

Bereich

Medien / Content

Umsetzung

2 Wochen

Kompetenz

SEO · Business Intelligence

Stack

Python · Vanilla JS · Cloudflare · Google Search Console · Google Analytics · Microsoft Clarity · Directus · Git

Dieses Dashboard habe ich für ein eigenes Projekt gebaut: eine gewachsene Content-Website mit gut dreitausend Inhalten. Das Problem daran war nicht der Mangel an Daten, sondern das Gegenteil.

Die Zahlen lagen vollständig vor — verteilt über fünf Systeme. Die Search Console wusste, welche Seiten in Google gefunden werden. Google Analytics wusste, was Besucher danach taten. Microsoft Clarity zeichnete Sitzungen auf. Cloudflare zählte den echten Traffic, auch den ohne Cookie-Zustimmung. Und das CMS wusste, welche Inhalte überhaupt existieren und welche Anfragen daraus entstanden waren.

Fünf Logins, fünf Oberflächen, fünf verschiedene Zeitfenster. Um eine einzige Frage zu beantworten — «welche Inhalte verlieren gerade Sichtbarkeit?» — musste man alle fünf öffnen und im Kopf zusammenrechnen. Das tut niemand regelmäßig. Also schaute ich, wie die meisten, ein- oder zweimal im Quartal.

Was daraus wurde

Eine einzige HTML-Seite. Kein Backend, keine Datenbankabfrage beim Öffnen, keine externen Requests. Jede Nacht um 04:40 UTC läuft ein Skript, holt sich die fünf Quellen, rechnet sie zu einem Snapshot zusammen und baut daraus eine fertige Seite. Wer sie morgens öffnet, lädt eine Datei — und hat alles.

Der Aufbau folgt der Art, wie man tatsächlich fragt. Die Übersicht beantwortet «wie läuft es insgesamt». Eine Materialliste zeigt die Inhalte einzeln, mit Klicks, Impressionen, CTR, Position, Sitzungen und Anfragen nebeneinander.

Ein Klick auf eine Zeile öffnet die Detailansicht: Wochenverlauf, dazu die Historie der Snapshots — man sieht also nicht nur den heutigen Stand, sondern auch, wie sich die Bewertung dieses Inhalts über die Tage verändert hat. Redaktionelle Eingriffe sind als Ereignisse markiert, sodass man Ursache und Wirkung nebeneinander liest statt zu raten.

Die eigentliche Arbeitsansicht ist aber die dritte: Bewegungen. Sie vergleicht zwei Zeitfenster und listet, was gestiegen und was gefallen ist — sortiert nach absoluter Veränderung, nicht nach Prozent. Prozente sind bei kleinen Zahlen Rauschen; ein Inhalt von 1 auf 3 Klicks macht +200 % und bedeutet nichts.

Eine vierte Ansicht arbeitet nicht mit Inhalten, sondern mit Suchbegriffen: Wo steht die Website knapp außerhalb der ersten Seite, wo konkurrieren zwei eigene Inhalte um denselben Begriff, wo ist Sichtbarkeit ganz verschwunden. Das sind die Fälle, bei denen sich Arbeit am schnellsten auszahlt.

Drei Entscheidungen, auf die es ankam

Inhalte statt URLs zählen. Die Website hatte eine komplette Migration hinter sich — alte und neue Adressen zeigen auf dieselben Inhalte. Wer pro URL auswertet, sieht für jeden Jahresvergleich Nullen, weil vor einem Jahr praktisch alle Klicks auf die alten Adressen fielen. Das Dashboard rechnet deshalb über eine stabile Inhalts-ID und zählt alte und neue Adressen als eine Zeile zusammen. Erst dadurch ist der Jahresvergleich über die Migration hinweg überhaupt aussagekräftig — und man sieht zusätzlich, welcher Anteil der Klicks noch auf alten Adressen landet.

Der Jahresvergleich macht noch etwas, das ich für den wichtigsten Teil halte: Er misst nicht gegen Null, sondern gegen die Entwicklung der ganzen Website. Wenn das Gesamtbild 28 % unter Vorjahr liegt, ist ein Inhalt mit −25 % kein Problem, sondern Durchschnitt. Auffällig sind nur die, die deutlich vom Trend abweichen. Diese Unterscheidung entscheidet darüber, ob man an der richtigen Stelle arbeitet.

Historie, die sich selbst korrigiert. Die Search Console liefert Daten mit etwa drei Tagen Verzögerung und verfeinert sie danach noch rückwirkend. Ein Bericht, der einmal gespeichert und nie wieder angefasst wird, friert diese Ungenauigkeit ein. Der nächtliche Lauf rechnet vergangene Zeitfenster deshalb neu, statt sie festzuschreiben — die Historie wird mit der Zeit genauer, nicht älter.

Eine Datei, kein Backend. Der Snapshot wird komprimiert, indem Nullwerte gar nicht erst geschrieben werden. So passen 3.103 Inhalte samt Verlauf in etwa 650 KB. Das Ergebnis ist eine Seite, die auch von file:// funktioniert: kein Server, keine laufende Datenbank, kein Dienst, der ausfallen kann. Der Zugang liegt an der Kante — eine Funktion bei Cloudflare prüft den Zugriff, die Daten liegen in privatem Speicher in der EU.

Was das mit Ihrem Betrieb zu tun hat

Die Datenquellen sind hier SEO-Werkzeuge, weil es ein Content-Projekt ist. Das Muster darunter ist aber genau das, was in einem Handwerks- oder Dienstleistungsbetrieb schiefläuft: Die Zahlen sind vorhanden, aber verteilt. Kontostand in der Banking-App, offene Rechnungen im Rechnungstool, Aufträge im CMS oder auf Zetteln. Jede Quelle für sich ist in Ordnung. Zusammen ergeben sie nur dann ein Bild, wenn jemand sie zusammenträgt — und dafür hat im laufenden Betrieb niemand den Kopf.

Die Antwort ist in beiden Fällen dieselbe: Ein Skript sammelt nachts, was verteilt liegt, und legt es in eine Ansicht, die morgens fertig ist. Genau das ist der Gedanke hinter dem Paket Owner’s Cockpit — dort mit Bank, Rechnungstool und Auftragslage statt mit Suchmaschinen-Daten. Warum das mehr bringt als der Monatsbericht vom Steuerberater, habe ich in Liquidität im Blick statt Monatsende-Überraschung aufgeschrieben.

Zwei Punkte, die ich aus diesem Projekt mitnehme und in Kundenprojekten genauso handhabe: Es läuft auf eigener Infrastruktur, ohne Abhängigkeit von einem Anbieter, der morgen die Preise ändert. Und es kommt ohne Cookies und ohne Tracking beim Betrachten aus — die Daten liegen in der EU, die Seite lädt beim Öffnen nichts nach.

Wenn Sie so eine Ansicht für Ihre eigenen Zahlen brauchen: Offen für eine Festanstellung in Data Analytics und Automatisierung? Kontakt aufnehmen.

← Alle Projekte