Alle Projekte
Web & TechnologieVersion 1.5 · livePortfolio-Projekt

heleha.com — Diese Website

Diese Seite ist längst mehr als eine Portfolio-Visitenkarte. Aus einer schnellen, datenschutzfreundlichen Website mit Next.js und Cloudflare Pages ist Schritt für Schritt ein eigenständiges Webprojekt geworden: Browser-Tools, die alles lokal verarbeiten, ein wachsender Wissensbereich und ein produktionsreifer, abgesicherter Schülerbereich mit eigenem Login. Entstanden aus eigenem Interesse an der Sache, KI-gestützt entwickelt — aber jede Zeile selbst nachvollzogen, geprüft und verantwortet.

Zeitaufwand

150+ Stunden

Framework

Next.js 16

Hosting

Cloudflare Pages

Deployment

GitHub → CI/CD

Analytics

Cookiefrei

Status

Version 1.5 · live

Von Idee bis Deployment

Der Workflow hinter heleha.com — von Konzept bis Live.

💡

Idee & Konzept

Ziele, Inhalt, Struktur

📐

Design & Planung

Komponenten, Routing, Farben

💻

Entwicklung

Next.js, TypeScript, Tailwind

🔗

GitHub

Versionskontrolle & CI-Trigger

Cloudflare Pages

Build, CDN, HTTPS

🌐

Live auf heleha.com

Global ausgeliefert

Ausgangslage und Ziel

heleha.com entstand aus dem Wunsch, eigene Projekte sauber zu dokumentieren und nach außen darzustellen — ohne auf Template-Baukästen zurückzugreifen, die kaum Kontrolle über Datenschutz, Performance und Darstellung lassen.

Das Ziel war eine schnelle, datenschutzfreundliche Portfolio-Website mit echtem technischen Fundament: kein Shared-Hosting, kein CMS, kein Cookie-Banner, kein überdimensioniertes Framework — sondern eine statisch generierte Website, die sich auf Cloudflare Pages so verhält, wie sie auf dem lokalen Entwicklungsrechner aussieht.

Die Website ist unter dem Namen Heleha veröffentlicht — aus Hardware, Electricity und Handling. Das Wort „Handling" beschreibt dabei mehr als technische Bedienung: Organisation, Kontrolle, Feinarbeit und die Arbeit, die ein Projekt langfristig am Laufen hält.

Technischer Stack

Next.js 16 (App Router, Static Export)

Statische Seitenausgabe mit `output: export` — keine Server-Laufzeit notwendig, vollständig CDN-kompatibel.

TypeScript

Typsicherheit für alle Komponenten, Metadaten und Hilfsfunktionen — reduziert Flüchtigkeitsfehler erheblich.

Tailwind CSS v4

Utility-First-Styling direkt im JSX, konsistentes Design-System ohne separate CSS-Dateien.

Cloudflare Pages

Globale CDN-Auslieferung, automatisches HTTPS, Redirect-Regeln über `public/_redirects`.

GitHub Actions (CI/CD)

Automatisierte Prüfungen (Linting, Build, Typprüfung) und Deployment bei jedem Push auf den Hauptbranch — ergänzt um automatisierte Abhängigkeits-Updates, die einzeln geprüft statt blind übernommen werden.

Cloudflare Web Analytics

Cookiefreie Besucherstatistiken mit Fokus auf Datenminimierung — kein Tracking, keine personenbezogenen Daten.

Cloudflare Pages Functions

Schlankes Backend direkt am Edge — trägt Login, Schülerbereich und Administration, ohne die statisch-schnelle Auslieferung der öffentlichen Seiten aufzugeben.

D1, KV & R2

SQLite-Datenbank (D1) für Konten und Datei-Metadaten, Schlüssel-Wert-Speicher (KV) für Sitzungen und Sperrzähler, privater Objektspeicher (R2) für die hochgeladenen PDFs.

PBKDF2, Sessions & Turnstile

Gesalzene Passwort-Hashes über die native Web-Crypto-API, serverseitige Sitzungen, CSRF-Schutz und Bot-Abwehr per Turnstile — die Sicherheitsbausteine des Schülerbereichs.

Sicherheitsheader & CSP

Site-weite Sicherheitsheader (u. a. HTTPS-Erzwingung mit HSTS und eine restriktive Content-Security-Policy) härten die gesamte Website — nicht nur den Schülerbereich — gegen gängige Angriffsklassen ab.

KI-Einsatz: Teile des Codes wurden KI-gestützt entwickelt — unter anderem für Komponenten-Struktur und Tailwind-Klassen. Jede Zeile wurde nachvollzogen, geprüft und bei Bedarf korrigiert. Konzeption, Architekturentscheidungen und Inhalte stammen vollständig aus eigener Hand.

Wissen-Bereich & geschützter Schülerbereich

Aus der Portfolio-Seite ist eine produktionsreife Plattform geworden — abgesichert von Grund auf.

Der Wissen-Bereich ist größer gedacht als nur der geschützte Teil: Öffentliche Rubriken für Artikel, Gedanken und Lernmaterialien sind bereits angelegt und befinden sich im Aufbau — ausgereift, produktiv und vollständig abgesichert ist bislang vor allem der geschützte Schülerbereich.

Was als statische Portfolio-Seite begann, ist mit der Zeit zu einer vollwertigen Plattform gewachsen. Seit Version 1.0 — abgeschlossen, produktionsreif und im echten Einsatz — ergänzt ein geschützter Schülerbereich die öffentliche Website: Schülerinnen und Schüler melden sich mit einem individuellen Login an und finden dort ausschließlich die Unterlagen, die für sie bestimmt sind.

Damit das sicher funktioniert, bekam die ansonsten serverlose Website ein schlankes Backend direkt am Cloudflare-Edge — ohne den statisch-schnellen Charakter der öffentlichen Seiten aufzugeben. Sicherheit, Datenschutz und Skalierbarkeit standen dabei von Anfang an im Mittelpunkt.

  • Ein individueller Login je Schüler — dazu ein getrennter Administrationsbereich mit klarer Rollen- und Rechteverwaltung.
  • Der Verwaltungsbereich liegt zusätzlich hinter Cloudflare Access (Zero Trust) — eine zweite, netzwerkseitige Schutzschicht noch vor dem eigentlichen Login.
  • Passwörter werden nie im Klartext gespeichert, sondern ausschließlich als gesalzene PBKDF2-Hashes; angemeldet bleibt man über serverseitige Sitzungen.
  • Cloudflare Turnstile hält Bots und automatisierte Anmeldeversuche fern, eine vorgelagerte Web Application Firewall mit Rate-Limiting bremst Überlastungs- und Brute-Force-Versuche aus.
  • Strikte Mandantentrennung: Jeder Schüler sieht garantiert ausschließlich die eigenen Dateien — eigens getestet und bestätigt.
  • Unterlagen werden als PDF über die Verwaltung hochgeladen und stehen nur Berechtigten als geschützter Download bereit — nichts ist öffentlich abrufbar.
  • Das Backend besteht aus Cloudflares Datenbank (D1), schnellem Schlüssel-Wert-Speicher für Sitzungen (KV) und privatem Dateispeicher (R2).
  • Automatische, verschlüsselte Backups von Datenbank und Dateien sichern den Bestand — der Wiederherstellungsprozess wurde erfolgreich getestet.
  • Der Verwaltungsbereich macht Zugänge und Materialien übersichtlich handhabbar — inklusive nachvollziehbarer Zeitangaben rund um Upload und Bereitstellung, damit auch nach einiger Zeit noch klar ist, was wann bereitgestellt wurde.
  • Durchgängig datenschutzbewusst konzipiert: Datenminimierung, keine unnötigen personenbezogenen Daten und klare Löschwege, unter Berücksichtigung der Grundsätze der DSGVO von Grund auf mitgedacht.

Stand heute: Version 1.5 — abgeschlossen, abgesichert und produktiv im Einsatz. Weitere Schutzebenen (z. B. Audit-Protokolle und erweitertes Monitoring) sind bereits geplant.

Privacy by Design

Datenschutz war von Anfang an ein Designziel — nicht nachträglich hinzugefügt.

  • Keine Cookies — weder für Analytics noch für Formulare
  • Kein Tracking von Besuchern oder Nutzerverhalten
  • Über ein Dutzend Browser-Tools (u. a. Passwort-, PDF- und Textwerkzeuge) verarbeiten alle Eingaben ausschließlich lokal im Browser — nichts wird an einen Server übertragen
  • Cloudflare Web Analytics: aggregierte Statistiken, Privacy-by-Design
  • Formularübermittlung ohne Speicherung personenbezogener Daten auf eigenen Servern
  • Der geschützte Schülerbereich arbeitet mit anonymen Kennungen statt Namen oder E-Mail-Adressen — Datenminimierung von Anfang an mitgedacht
  • robots.txt und noindex für rechtliche Seiten (Impressum, Datenschutz)

Rechtliche Grundlage: Cloudflare Web Analytics nach Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Vollständige Informationen in der Datenschutzerklärung.

SEO & Social Preview

Schema.org JSON-LD `Person`-Markup mit vollständigen Angaben
OpenGraph-Bilder mit dynamischer Generierung (`opengraph-image.tsx`, `twitter-image.tsx`)
Sitemap.xml mit allen Seiten, korrekte Prioritäten und lastmod-Daten
Canonical-URLs und Trailing-Slash-Konsistenz für Cloudflare Pages
Metadaten (title, description, og:, twitter:) auf jeder Seite individuell gepflegt
Favicon in allen Größen + manifest.json für App-Icons

Google Search Console: Die technische Auffindbarkeit wird aktiv beobachtet — die Sitemap wird erfolgreich verarbeitet, eine Domain-Property ist eingerichtet, und der Indexierungsstatus einzelner Seiten wird regelmäßig geprüft. Eine kürzlich identifizierte Ursache für verzögerte Indexierung (ein doppelter Host über die www-Subdomain, siehe Herausforderungen) wurde technisch behoben; ob sich das messbar auf die Indexierung auswirkt, wird weiter beobachtet, statt es vorschnell als erledigt zu betrachten. Sitemap, robots.txt und Canonical-URLs sind bewusst so aufgebaut, dass sie auch von anderen Suchmaschinen wie Bing zuverlässig verarbeitet werden können — aktiv beobachtet und gepflegt wird die Sichtbarkeit derzeit vor allem über die Google Search Console.

Technische Herausforderungen

Static Export + dynamische OG-Bilder

Next.js `opengraph-image.tsx` erzeugt beim Build statische Bilddateien mit Content-Hash im Dateinamen. Manuelle `/opengraph-image.png`-Referenzen würden 404 liefern — gelöst durch ausschließliche Nutzung der automatischen Next.js-Erkennung ohne explizite URL-Angaben in Metadaten.

Client-Komponenten und Server-Metadata

Seiten mit `useState` (z.B. Kontaktformular) können kein `metadata`-Export haben. Lösung: Extraktion des interaktiven Teils in eine `"use client"`-Komponente, während die Seitenkomponente als Server Component Metadaten exportiert.

Design-Konsistenz über alle Seiten

Ohne Design-System-Tool: Farbpalette, Abstände und Komponenten-Stil manuell konsistent gehalten. Tailwind-Klassen wurden bewusst standardisiert — z.B. einheitliche `rounded-2xl`, `border-slate-200`, `text-slate-600`.

Redirect-Strategie für umbenannte Seiten

Ältere URL-Pfade (/leistungen, /ueber-uns) werden über `public/_redirects` auf 301-Ebene weitergeleitet — bevor Next.js überhaupt greift. Dadurch keine SEO-Verluste bei Umbenennung.

Sichere Passwörter ohne WebAssembly

Cloudflares Worker-Laufzeit erlaubt zur Laufzeit kein WebAssembly — gängige Hash-Bibliotheken (argon2/bcrypt als WASM) fallen damit aus. Gelöst durch native PBKDF2-Hashes über die Web-Crypto-API, fest auf die von Cloudflare maximal erlaubte Iterationszahl ausgelegt, salted und sicher kodiert abgelegt.

Doppelter Host durch www-Subdomain

www.heleha.com lieferte über die Domain-Konfiguration lange dieselbe Website als vollständigen zweiten Host aus — ein Signalproblem für Suchmaschinen, das sich über clientseitige Weiterleitungsregeln allein nicht lösen ließ. Behoben durch eine domainweite Weiterleitungsregel, die www-Aufrufe zuverlässig auf die kanonische Domain umleitet — inklusive Pfad und Query-String, live verifiziert.

Learnings

  • 1
    KI-gestützte Entwicklung ist effizient — aber nur, wenn man das Ergebnis kritisch prüft, versteht und verantwortet. Jede Zeile Code wurde nachvollzogen und bei Bedarf korrigiert.
  • 2
    Statische Deployments sind robust und günstig zu betreiben, erfordern aber klare Architekturentscheidungen von Anfang an. Wo echte Logik nötig wurde — etwa beim geschützten Schülerbereich — kamen gezielt serverlose Edge-Functions hinzu, ohne den statisch-schnellen Kern der öffentlichen Seiten aufzugeben.
  • 3
    SEO ist kein einmaliger Schritt, sondern ein laufender Prozess: Metadaten, strukturierte Daten, Sitemap und Social Preview müssen gepflegt werden.
  • 4
    Privacy by Design ist mehr als ein Rechtsbegriff — es ist eine Designentscheidung, die die gesamte technische Architektur beeinflusst.
  • 5
    Wartbarkeit entscheidet über Langzeitwert: saubere Komponentenstruktur, konsistente Benennung und eine lückenlos gepflegte technische Dokumentation zahlen sich schon nach wenigen Wochen aus — vor allem, wenn man selbst nach einer Pause wieder einsteigt.
  • 6
    Sicherheit ist kein Feature, das man am Ende dazuschaltet. Login, Mandantentrennung, verschlüsselte Backups und ihr Wiederherstellungstest mussten von Anfang an zusammengedacht werden — und gehören regelmäßig überprüft, nicht nur einmal eingerichtet.
  • 7
    Sichtbarkeit in Suchmaschinen ist ebenso ein andauernder Prozess wie Sicherheit: Über die Google Search Console wird beobachtet, wie Google die Seiten crawlt und indexiert — und technische Ursachen für Verzögerungen werden gezielt untersucht, statt sie zu ignorieren.

Du siehst gerade das Ergebnis.

Diese Seite ist nicht nur Projektbeschreibung — sie ist das Projekt selbst. Alles, was hier steht, wurde umgesetzt, geprüft und läuft live auf heleha.com.