• Home
  • Blog
  • Fallstudie: Die neue Website für Flaiz & Eger IT Consulting
Case Study
Web development

Fallstudie: Die neue Website für Flaiz & Eger IT Consulting

01 September 2026 6 min read

Einleitung

Seit diesem Sommer ist die neue Website der Flaiz und Eger IT Consulting GbR aus Grosselfingen online: fe-itconsulting.com. Sechs Seiten, zwei Sprachen, ein Kontaktformular, vier Leistungsbereiche — Prozessanalyse, Prozessoptimierung, individuelle Software sowie KI und Automatisierung.

Von außen sieht man einer Website nicht an, wie sie gebaut ist. Zwei Seiten können identisch aussehen und sich völlig unterschiedlich verhalten: beim ersten Aufruf über das Mobilfunknetz, in der englischen Fassung, bei der Bedienung mit der Tastatur, im Umgang mit den Daten der Besucher. Dieser Beitrag zeigt solche Entscheidungen an einem Projekt, das wir zeigen dürfen — der Auftraggeber nennt uns im Fuß seiner Seite ohnehin selbst als Umsetzer.

Die Seite ist da, bevor jemand wartet

Jede der zwölf Adressen liegt als fertige HTML-Datei bereit, erzeugt beim Bauen. Beim Aufruf wird nichts mehr zusammengesetzt: Der Besucher bekommt die vollständige Seite, und Suchmaschinen bekommen sie ebenfalls, ohne dafür erst Skripte ausführen zu müssen.

Im Auslieferungsweg läuft bewusst kein Server. Die einzige Komponente, die zur Laufzeit arbeitet, gehört zum Kontaktformular und tut nur etwas, wenn jemand absendet. Weniger bewegliche Teile heißt auch: weniger, das ausfallen oder gepflegt werden muss.

Auch das Gewicht ist eine Entscheidung. Übertragen wird, was die Seite wirklich braucht — und sonst nichts. Ein Beispiel, an dem sich die Größenordnung ablesen lässt: Eine vollständige Symbolschrift bringt über 7.000 Zeichen mit, diese Website benutzt 25 davon. Genau diese 25 liegen als Zeichnungen im Seitenquelltext, der Rest wird gar nicht erst geladen. Wer später ein Symbol einbaut, das es nicht gibt, erfährt es beim Bauen statt auf der fertigen Seite.

In beiden Sprachen auffindbar

Deutsch und Englisch sind hier zwei echte Adressen: /about ist deutsch, /en/about englisch, beide werden in ihrer Sprache fertig erzeugt. Ein englischer Link lässt sich also weitergeben und kommt beim Empfänger auch englisch an.

Für Suchmaschinen zahlt sich das doppelt aus: Beide Fassungen sind eigenständig indexierbar und verweisen wechselseitig aufeinander, sodass Google sie als dieselbe Seite in zwei Sprachen erkennt. Die Umleitung nach Browsersprache bleibt dabei bewusst abgeschaltet — Googles Renderer meldet sich als englischsprachig und hätte die deutsche Fassung sonst nie zu sehen bekommen.

Die Sitemap führt alle zwölf Adressen und nennt zu jeder das Datum der letzten inhaltlichen Änderung, gezogen aus der Versionsgeschichte der Seite statt auf das Tagesdatum gestempelt. Ein Datum, das täglich springt, ohne dass sich etwas geändert hat, verliert seinen Wert. Ergänzend sagt eine llms.txt KI-Systemen in je einem Satz, welche Seite welche Frage beantwortet.

Wer anfragt, kommt an

Das Kontaktformular führt zu einer echten E-Mail, und der Weg dorthin ist auf einen einzigen Fall hin gebaut: Eine ernst gemeinte Anfrage darf nicht verloren gehen.

Der Spam-Schutz weist deshalb nur ab, wo etwas eine Tatsache ist — ein von Google zurückgewiesenes Token etwa. Der Wahrscheinlichkeitswert, den die Bot-Erkennung zusätzlich liefert, wird an der Mail vermerkt statt zur Ablehnung zu führen: Über Spam entscheidet ein Mensch, der die Nachricht gelesen hat. Den offensichtlichen Fall fängt ohnehin ein unsichtbares Feld ab, das nur Automaten ausfüllen, und ein Kennzeichen je Absendevorgang sorgt dafür, dass aus einem Doppelklick eine Anfrage wird statt zwei.

Wer beim Ausfüllen etwas vergisst, erfährt an Ort und Stelle, welches Feld gemeint ist. Und die Prüfung der E-Mail-Adresse bleibt großzügig genug für Umlautdomains — eine abgewiesene Anfrage kommt kein zweites Mal.

Besucherdaten bleiben, wo sie hingehören

Vier Entscheidungen stecken in dieser Website, die man ihr nicht ansieht:

  • Die Schriften liegen auf dem eigenen Server. Kommen sie von einem fremden Anbieter, überträgt jeder Seitenaufruf die IP-Adresse des Besuchers dorthin — vor jeder Zustimmung und auch bei dem, der nur kurz vorbeischaut.

  • Die Karte auf der Kontaktseite lädt erst auf Klick. Sie später zu laden hätte den Zeitpunkt verschoben, die Übertragung aber nicht verhindert.

  • Die Bot-Erkennung startet erst, wenn jemand das Formular anfasst, nicht schon beim Betreten der Seite.

  • Für die Karte wird bewusst nichts gespeichert. Ein gemerktes Ja wäre selbst wieder ein Eintrag auf dem Gerät; ein Klick pro Besuch ist zumutbar.

Entscheidungen im Einwilligungsdialog werden protokolliert, weil Art. 7 Abs. 1 DSGVO verlangt, eine erteilte Einwilligung nachweisen zu können. Zeitpunkt und Herkunft setzt dabei der Server: Kämen die Werte aus der Anfrage des Browsers, ließen sie sich frei erfinden, und der Nachweis wäre keiner. Die IP-Adresse wird vor dem Speichern gekürzt — was sie nicht anonym macht, und genau so steht es auch im Quelltext. Nach drei Jahren löscht sich jeder Nachweis von selbst; die Frist entspricht der regelmäßigen Verjährungsfrist des § 195 BGB. Verarbeitet und gespeichert wird in Frankfurt am Main.

Dazu legen Regeln, die der Server mit jeder Seite ausliefert, fest, aus welchen Quellen Skripte, Bilder und Schriften überhaupt stammen dürfen.

Bedienbar auch ohne Maus

Die vier Bereiche auf der Leistungsseite lassen sich über Register umschalten, und diese Register sind echte Schaltflächen: mit der Tabulatortaste erreichbar, mit Leertaste und Eingabetaste bedienbar, und ein Screenreader kündigt sie als das an, was sie sind.

Dasselbe Prinzip trägt das Menü auf dem Handy. Der Knopf sagt, was er tut, das Menü schließt sich beim Wechsel auf eine andere Seite von selbst, und wo der Tastaturfokus gerade steht, ist jederzeit sichtbar. Geprüft wurde das im Browser, nicht auf dem Papier.

Geprüft wird zum Schluss, nicht nur zwischendurch

Zu diesem Projekt gehörte ein eigener Durchgang, der erst nach der Fertigstellung begann: Die Website wurde noch einmal vollständig gegen die eigenen Annahmen gehalten — Quelltext, Auslieferung, Dokumentation und die laufende Seite im Browser.

Der letzte Punkt ist der, den man leicht übergeht. Manches lässt sich am Quelltext gar nicht beurteilen: Wie lange ein Browser eine Seite zwischenspeichert, bevor er sie neu holt, entscheidet sich an der ausgelieferten Adresse — und das merkt nur, wer dort nachsieht. Für den Betreiber ist das der Unterschied zwischen „die Änderung ist online" und „die Änderung ist beim Besucher angekommen".

Damit es so bleibt, laufen bei jeder Änderung acht automatische Prüfungen mit: ob beide Sprachdateien zueinander passen, ob Adressliste, Sitemap und erzeugte Seiten dasselbe sagen, ob die E-Mail-Prüfung im Browser und auf dem Server identisch ist.

Woran sich das am eigenen Auftritt festmachen lässt

Vieles davon lässt sich an einer bestehenden Website in wenigen Minuten prüfen, ganz ohne Zugang zum Quelltext: Führt die Sitemap alle Seiten, und stehen dort echte Änderungsdaten? Lässt sich die Seite mit der Tabulatortaste durchlaufen, und sieht man dabei, wo man gerade ist? Lädt beim ersten Aufruf schon eine Karte oder eine fremde Schrift, bevor irgendjemand zugestimmt hat? Gibt es die englische Fassung unter einer eigenen Adresse?

Das Projekt entstand zwischen Ende Juni und Mitte August 2026. Wer für den eigenen Auftritt dieselbe Sorgfalt möchte, muss sie im Übrigen nicht erraten: Wie eine Website ausgeliefert wird, welche Adressen sie kennt und was sie beim ersten Aufruf lädt, lässt sich vorab besprechen — und danach nachprüfen.

Ausprobieren