Eine statische Website ist schnell veröffentlicht. Danach kommt die weniger sichtbare Frage: Hat der Link überhaupt etwas ausgelöst?
Wurde die Seite geöffnet? Kam der Besuch über LinkedIn, eine E-Mail, einen QR-Code oder direkt über die Domain? Öffnen die meisten Menschen die Seite am Smartphone? Wird eine Unterseite häufiger besucht als die Startseite? Und verbraucht ein großes PDF, ein Hero-Bild oder ein Portfolio-Slider schon mehr Bandbreite als erwartet?
Dafür braucht nicht jedes Projekt sofort ein großes Webanalyse-System. Für den Anfang reicht oft eine saubere Besucherstatistik, die zeigt, was nach dem Teilen des Links passiert.
Erst klären, wofür die Website veröffentlicht wurde
Analytics wird unbrauchbar, wenn jede Zahl gleich wichtig wirkt.
Statische Websites haben meistens einen klaren Zweck. Ein Portfolio soll geöffnet und geprüft werden. Eine Landingpage soll zeigen, ob ein Kanal funktioniert. Eine Bewerbungshomepage muss auf dem Handy ordentlich aussehen. Eine Kundenvorschau soll beweisen, dass die neue Version wirklich erreichbar ist.
Die erste Auswertung sollte zu diesem Zweck passen.
| Website-Typ | Erste Frage | Wichtige Kennzahlen |
|---|---|---|
| Portfolio | Wird der Link von echten Personen geöffnet? | Besucher, Referrer, Top-Seiten, Geräte |
| Landingpage | Welcher Kanal bringt Reichweite? | Referrer, UTM-Links, Länder, Top-Seiten |
| Kundenvorschau | Hat die richtige Person die aktuelle Version gesehen? | Aktuelle Besuche, Geräte, Länder, Seiten |
| Dokumentation | Landen Besucher auf der passenden Seite? | Top-Seiten, Referrer, ungewöhnliche Pfade |
| Studentenprojekt | Funktioniert der externe Zugriff im Kurs oder Seminar? | Seitenaufrufe, Browser, Geräte, öffentliche Zugriffe |
| Bild- oder PDF-lastige Seite | Wird Bandbreite zum Problem? | Bandbreite, Top-Seiten, Dateigrößen |
Wenn die Frage unklar ist, wird die Auswertung schnell zur Beschäftigungstherapie. Dann schaut man auf eine steigende Linie, weiß aber nicht, was als Nächstes geändert werden sollte.
Seitenaufrufe und Besucher getrennt lesen
Seitenaufrufe zeigen, wie oft eine Seite geladen wurde. Besucher zeigen eher, wie viele unterschiedliche Personen oder Browser die Website erreicht haben.
Beides ist nützlich, aber es beantwortet nicht dieselbe Frage.
Ein hoher Wert bei Seitenaufrufen kann bedeuten, dass ein Link gut verteilt wurde. Es kann aber auch heißen, dass Sie, ein Kunde oder ein Teammitglied dieselbe Vorschau mehrfach neu geladen haben. Umgekehrt kann eine Seite wenige Aufrufe haben, aber aus mehreren unabhängigen Quellen kommen. Für eine kleine Portfolio- oder Bewerbungsseite kann das relevanter sein als eine hohe Zahl aus internem Testtraffic.
| Kennzahl | Hilft bei | Typischer Fehler |
|---|---|---|
| Seitenaufrufe | Aktivität pro URL | Reloads als neue Nachfrage lesen |
| Besucher | Grobe Reichweite | Die Zahl als exakte Personenanzahl behandeln |
| Top-Seiten | Tatsächlich geöffnete Inhalte | Nur die Startseite prüfen |
| Bandbreite | Ressourcen- und Tarifdruck | Große Dateien erst bemerken, wenn Traffic kommt |
Die Begriffe unterscheiden sich je nach Tool. Google Analytics 4 arbeitet ereignisbasiert und sendet page_view-Events, wenn eine Seite geladen wird. Leichtere Tools wie Plausible oder Cloudflare Web Analytics zeigen stärker verdichtete Kennzahlen wie Seitenaufrufe, Besucher, Referrer, Länder, Geräte und Browser.
Wichtiger als der Name ist die Lesart: Eine einzelne Zahl reicht selten. Erst die Kombination aus Seitenaufrufen, Besuchern, Referrern und Top-Seiten zeigt, ob die Veröffentlichung in die richtige Richtung läuft.
DeployPages zeigt für Projekte Seitenaufrufe, geschätzte Besucher, Bandbreite, Top-Seiten, Referrer, Länder, Geräte, Browser, Betriebssysteme und aktuelle Besuchsereignisse. Für den ersten Launch einer statischen Website ist das bewusst näher an einer Besucherstatistik als an einem schweren Produktanalyse-Setup.
Referrer zeigen, ob die Verteilung funktioniert
Viele statische Seiten scheitern nicht am Hosting. Sie werden einfach zu wenig oder an der falschen Stelle geteilt.
Referrer-Daten helfen, diese Fälle zu trennen. Wenn fast niemand kommt, liegt das Problem vielleicht nicht im Layout, sondern in der Distribution. Wenn ein Kanal deutlich stärker ist als die anderen, lohnt sich ein zweiter Blick auf die Besucher, Top-Seiten und Geräte aus genau diesem Umfeld.
| Beobachtung | Mögliche Deutung | Sinnvoller nächster Schritt |
|---|---|---|
| Viele direkte Zugriffe | E-Mail, Messenger, QR-Code, kopierter Link oder fehlender Referrer | Beim nächsten Teilen UTM-Parameter verwenden |
| Ein Social-Kanal dominiert | Der Post oder die Weiterleitung funktioniert | Prüfen, ob die richtige Seite geöffnet wird |
| Erste Suchzugriffe erscheinen | Die Seite wird außerhalb der Erstverteilung gefunden | Title, Description und Domain prüfen |
| Interne oder Kunden-Domains tauchen auf | Review-Traffic läuft | Nicht mit öffentlicher Nachfrage verwechseln |
| Merkwürdige Referrer | Bot-Traffic oder Rauschen | Nicht vorschnell die Seite umbauen |
Für Kampagnen, QR-Codes, Newsletter und Social Posts lohnt es sich, Links sauber zu benennen. Der UTM-Link-Builder hilft dabei, Quelle, Medium und Kampagne festzuhalten. UTM-Parameter machen die Statistik nicht perfekt, aber sie verhindern viele spätere Diskussionen darüber, woher ein Besuch kam.
Geräte- und Browserdaten sind Testhinweise
Viele statische Websites werden am Desktop gebaut und am Smartphone bewertet.
Das klingt banal, ist aber einer der häufigsten Gründe für schlechte erste Eindrücke. Ein Portfolio-Raster kann auf einem großen Monitor ruhig aussehen und auf dem Handy zu lang werden. Eine Landingpage kann ihren Call-to-Action auf Desktop sauber zeigen und auf einem kleinen Display unter den sichtbaren Bereich drücken. Eine PDF-nahe Lebenslaufseite kann in Chrome auf dem Laptop gut wirken, aber in Safari auf dem iPhone zu eng sein.
Geräte-, Browser- und Betriebssystemdaten sagen nicht automatisch, welches Design richtig ist. Sie sagen, wo Sie als Nächstes testen sollten.
Wenn der Großteil der Besuche mobil ist, öffnen Sie den echten Link zuerst auf einem echten Smartphone. Wenn iOS Safari auffällig häufig vorkommt, prüfen Sie Bilder, Videoverhalten, Schriftgrößen und Tap-Ziele dort. Wenn Kundenvorschauen aus älteren Desktop-Browsern kommen, sollte die Seite beim Review nicht an unnötiger Interaktion hängen.
Das ist praktischer als ein allgemeines "mobile first". Die Statistik zeigt, wo diese konkrete Website gerade genutzt wird.
Top-Seiten decken falsche Annahmen auf
Eine statische Website hat oft einen geplanten Einstieg und mehrere echte Einstiege.
Jemand teilt direkt eine Unterseite. Eine alte URL liegt noch in einem Dokument. Ein QR-Code führt nicht zur Startseite, sondern zu einem Event-Pfad. Eine Suchmaschine findet zuerst einen Artikel. Bei einer KI-generierten Seite bleibt vielleicht ein Testpfad sichtbar, den niemand geprüft hat.
Top-Seiten sind besonders wichtig nach:
- einem neuen Upload,
- dem Wechsel von Vorschau-Link zu eigener Domain,
- einer Migration von GitHub Pages, einem alten Portfolio oder einer Dokumentationsseite,
- Kampagnen mit mehreren Links,
- Änderungen an
index.html, Navigation oder Dateipfaden, - dem Veröffentlichen von PDF-, Bild- oder Download-Seiten.
Wenn eine Unterseite häufiger besucht wird als die Startseite, ist das nicht automatisch schlecht. Vielleicht ist sie der bessere Einstieg. Kritisch wird es, wenn alte Pfade, kaputte Downloads oder unfertige Seiten mehr Aufmerksamkeit bekommen als die eigentliche Zielseite.
Bandbreite früh beobachten
Bandbreite wirkt weniger spannend als Besucherzahlen. Bei statischen Websites ist sie aber oft das erste echte Kostensignal.
Statische Websites lassen sich gut ausliefern, aber große Bilder, Videos, exportierte Design-Screenshots, PDF-Dateien und Fonts können schnell schwer werden. Solange nur zwei Personen eine Vorschau öffnen, fällt das kaum auf. Sobald eine Landingpage geteilt wird oder ein Portfolio mehr Aufmerksamkeit bekommt, merkt man es.
Achten Sie besonders auf Bandbreite, wenn:
- viele hochauflösende Bilder oder Produktfotos eingebunden sind,
- PDFs, Präsentationen, Menüs oder Medien direkt über die Website geteilt werden,
- ein Social Post kurzfristig viele Besuche bringt,
- das Projekt nahe an Tarifgrenzen kommt,
- viele Besucher mobil unterwegs sind.
Die Bandbreite sagt nicht automatisch, welche Datei zu groß ist. Sie ist der Hinweis, die Ressourcen zu prüfen: Bildabmessungen, Kompression, Lazy Loading, unnötige Videos, schwere Fonts und Dateien, die nur bei Bedarf verlinkt werden sollten.
Datenschutz nicht als Floskel behandeln
In Deutschland führt jede Analytics-Diskussion schnell zu Cookies, Tracking, Einwilligung und DSGVO. Das ist kein Detail, das man in einem Nebensatz erledigen sollte.
Für eine statische Website gibt es zwei unterschiedliche Ebenen:
| Ebene | Typische Frage | Beispiel |
|---|---|---|
| Launch-Statistik | Wurde der veröffentlichte Link geöffnet? | Seitenaufrufe, Referrer, Geräte, Länder, Bandbreite |
| Produkt- oder Marketing-Analytics | Was machen Nutzer im Detail? | Events, Funnels, A/B-Tests, Conversion-Tracking, Nutzersegmente |
Die erste Ebene ist oft genug, um nach einem Launch handlungsfähig zu sein. Die zweite Ebene kann sinnvoll werden, wenn aus einer statischen Seite ein dauerhaftes Marketing-, SaaS- oder Produktprojekt wird.
Wichtig ist die Grenze: Eine eingebaute Besucherstatistik ersetzt keine rechtliche Prüfung. Wenn Sie zusätzlich Google Analytics, Matomo, Plausible, Fathom, PostHog, Meta Pixel oder andere Skripte einbinden, müssen Sie prüfen, welche Daten erhoben werden, ob Cookies oder ähnliche Technologien genutzt werden, ob Einwilligung nötig ist und wie Ihre Datenschutzerklärung aussieht.
DeployPages sollte hier als erste Auswertungsschicht verstanden werden: Sie sehen grundlegende Launch-Signale, ohne vor dem ersten Teilen der Website ein separates Analytics-Projekt in die statischen Dateien einzubauen. Für tiefere Produktanalyse bleibt ein spezialisiertes Tool der richtige Ort.
Wann ein größeres Analytics-Setup sinnvoll wird
Ein eigenes Analytics-Tool lohnt sich, wenn die Fragen über den Launch hinausgehen.
| Bedarf | Eingebaute Besucherstatistik | Größeres Analytics-Setup |
|---|---|---|
| Link nach Upload prüfen | Sehr passend | Meist überdimensioniert |
| Referrer und Top-Seiten sehen | Passend | Ebenfalls möglich |
| Bandbreite beobachten | Passend | Nicht immer Kernfunktion |
| Button-Klicks messen | Eher nicht | Passend |
| Funnel und Conversion verfolgen | Eher nicht | Passend |
| A/B-Tests auswerten | Eher nicht | Passend |
| Login-Nutzer analysieren | Eher nicht | Passend |
| Kampagnen über mehrere Produkte vergleichen | Begrenzt | Passend |
Für viele statische Seiten ist der bessere Ablauf: erst veröffentlichen, dann die ersten Signale lesen, dann entscheiden.
Wenn die Seite ein einmaliger Kursnachweis, eine Kundenfreigabe, ein Portfolio-Update oder eine kleine Kampagnenseite ist, bleibt die einfache Statistik oft ausreichend. Wenn Budget, Anzeigen, Leads oder Produktentscheidungen daran hängen, sollte ein dediziertes Analytics-Tool bewusst geplant werden.
Eine einfache Routine für die erste Woche
Nach dem Launch muss niemand den ganzen Tag auf ein Dashboard schauen. Eine kurze Routine reicht.
| Zeitpunkt | Prüfen | Warum |
|---|---|---|
| Erste Stunde | Öffnet die Seite, gibt es offensichtliche 404- oder Pfadprobleme? | Fehler beheben, bevor der Link weiterläuft |
| Erster Tag | Referrer, Geräte, Top-Seiten | Verteilung und Darstellung gegen echte Nutzung prüfen |
| Erste Woche | Trends, Länder, Bandbreite, wiederkehrende Top-Seiten | Entscheiden, ob die Seite optimiert, erweitert oder unverändert bleibt |
| Nach neuem Upload | Top-Seiten und aktuelle Besuche | Sicherstellen, dass die neue Version keine funktionierenden Pfade bricht |
| Nach Domain-Wechsel | Direct, Suchzugriffe, alte URLs | Prüfen, ob die eigene Domain den Vorschau-Link ersetzt |
Diese Routine passt gut zu statischen Websites, weil sie den Aufwand klein hält. Die Zahlen sollen keine dauerhafte Analysepflicht erzeugen. Sie sollen zeigen, ob die nächste Handlung klarer wird.
So passt DeployPages in diesen Ablauf
DeployPages verbindet die Besucherstatistik mit dem Veröffentlichungsprozess.
Sie können einen statischen Ordner, eine ZIP-Datei, einen Framework-Build, einen KI-Export, eine Portfolio-Seite oder eine PDF-nahe Website veröffentlichen und danach im Projekt sehen, ob der Link genutzt wird. Die gleiche Projektoberfläche kann später eigene Domains, Passwortschutz, Rollback auf eine frühere Version, CLI-Deployments und Analytics aufnehmen.
Das ist für viele kleine und mittelgroße statische Projekte der sinnvollere Startpunkt: erst einen funktionierenden HTTPS-Link veröffentlichen, dann echte Nutzung prüfen, dann entscheiden, ob die Seite eine Domain, ein größeres Analytics-Setup oder einen wiederholbaren Deploy-Prozess braucht.