Website-Relaunch: Was meine eigene Website über meine Arbeit zeigt

Fremdes Terrain, bekanntes Vorgehen

Ich bin nativer App-Entwickler. Websites, Suchmaschinenoptimierung und die Sichtbarkeit in KI-Antworten gehören nicht zu meinen Leistungen, und ein Profi dafür bin ich nicht. Der Relaunch war für mich unbekanntes Terrain. Davor habe ich keine Angst: KI ist ein Werkzeug, das mir hilft, Neues zu verstehen und umzusetzen.

Das Vorgehen kannte ich dagegen schon. 17 Jahre in der stark regulierten Produktion von Biotechnologie und Pharma haben es geprägt, und ein Grundsatz von dort gilt auch hier: Was nicht dokumentiert ist, ist nicht passiert. Wie diese Jahre meinen Blick auf Softwareprojekte prägen, steht im Beitrag „Vom Schüttelkolben zum Pilotprojekt“.

Warum eine neue Website

Die alte Website hatte 21 Seiten. Seobility, ein Werkzeug für die technische Prüfung von Websites, bewertete sie im September mit 88 % für Technik und Meta, 78 % für die Struktur und 66 % für den Inhalt.

Heute sind es zwei Websites aus einem gemeinsamen Code. byteundhandwerk.de zeigt mein Unternehmen: die sechs Pakete mit Festpreis, meine eigenen Apps als Fallstudien und inzwischen 13 Beiträge. dominikbaki.com erzählt meinen Werdegang. Beide entstehen mit Astro als fertige, statische Seiten und liegen bei GitHub Pages.

Jede Änderung ein Pull Request

Am Relaunch hat sich nichts nebenbei geändert. Jede Änderung beginnt als Pull Request: Er beschreibt, was sich ändert, zeigt sichtbare Änderungen in Bildern am Handy und am großen Bildschirm und durchläuft automatische Prüfungen. Online geht sie erst, wenn ich sie gelesen und zusammengeführt habe. Bis zum 17. Oktober 2026 waren das 86 Pull Requests mit 378 Commits.

Nach dem Zusammenführen veröffentlicht ein automatischer Ablauf beide Websites und prüft danach, ob sie den neuen Stand ausliefern. Bis zum 17. Oktober ist er 30-mal gelaufen.

Auch hier gilt, was ich im Beitrag zum KI-Einsatz beschreibe: Claude steht als Mitautor in jeder Änderung, freigegeben habe ich jede selbst.

Im Kundenprojekt sieht das genauso aus. Anforderungen stehen als Tickets mit Akzeptanzkriterien, an denen sich prüfen lässt, ob ein Schritt fertig ist, und Mehraufwand gibt es nur nach Ihrer Freigabe.

Beleg vor Behauptung

Für jede Aussage über mich, meine Projekte, Technik und Preise gibt es einen Eintrag in einer Belegliste, am 17. Oktober 2026 sind es 62. Jeder nennt Quelle und Stand: ein Zeugnis, den Quellcode einer App, eine eigene Kalkulation oder eine Entscheidung von mir. Was sich nicht belegen lässt, steht nicht auf der Website.

Dazu kommen Regeln, die Tests durchsetzen. Kein Satz verspricht, dass KI ein Projekt schneller oder billiger macht, und keine Seite nennt Preise anderer Anbieter. Wo ich Regeln anderer wiedergebe, etwa von Apple, Google oder aus der KI-Verordnung, steht die Quelle mit dem Tag dabei, an dem ich sie gelesen habe.

Festpreise aus der eigenen Versionsgeschichte

Die Preise der sechs Pakete sind kalkulierte Festpreise. Geschätzt habe ich den Aufwand dafür nur am Anfang. Danach habe ich aus den Zeitstempeln der Commits meiner eigenen Apps nachgerechnet, wie viel Arbeit in einer Kernfunktion steckt, abgeglichen an einem Projekt, dessen Dauer ich kenne.

Beim MVP bestätigte die Messung die Kalkulation. Bei der Full-Service-App lag die Kalkulation darüber, also habe ich ihren Festpreis gesenkt. Verhandeln lässt sich über die Pakete nicht, das steht seit dem 17. Oktober auch auf der Seite „Kosten und Festpreise“.

Texte, die wie Code geprüft werden

Ein Satz kann aus richtig geschriebenen Wörtern bestehen und trotzdem falsch sein. Deshalb prüft LanguageTool jede Seite auf Rechtschreibung und Grammatik, auf meinem Rechner und in der automatischen Prüfung jedes Pull Requests.

Dazu kommen eigene Regeln, die eine allgemeine Prüfung nicht kennt. Beide Websites siezen, gleiche Linktexte führen immer zum selben Ziel, fett steht nur, was hervorgehoben werden soll, und kein Text deutet Spielraum bei den Festpreisen an. Verstößt eine Seite dagegen, schlägt ein Test an.

Zum Schluss habe ich jede Seite selbst gelesen, Seite für Seite in einer eigenen Abnahme-Liste. Alle 49 Seiten beider Websites sind dort freigegeben.

Gefunden werden

Hier habe ich am meisten Neues gelernt. Eine neue Website steht nicht sofort in der Suche. Für Google habe ich die Sitemap in der Search Console eingereicht und für die wichtigsten Seiten die Indexierung beantragt. Am 15. Oktober standen 20 neue Adressen auf „Gefunden – zurzeit nicht indexiert“: Google kannte sie, hatte sie aber noch nicht abgerufen.

Bei Bing sind alle Seiten eingereicht, und seit dem 16. Oktober meldet der Livegang neue und geänderte Seiten selbst über IndexNow.

Seobility habe ich dabei als Prüfliste genutzt. Das Werkzeug bewertete byteundhandwerk.de am Tag des Livegangs mit 87 %, am 17. Oktober mit 97 %, dominikbaki.com stieg von 83 auf 98 %. Jede Meldung habe ich nachgeprüft, befolgt habe ich nicht jede. Dass Teaser und Autorenkasten auf mehreren Seiten wortgleich stehen, ist gewollt. Zwei Links zur KI-Verordnung gelten bei Seobility als gestört, weil EUR-Lex automatische Abrufe abweist; im Browser laden sie.

Über die Website hinaus

Ein Relaunch endet nicht an der eigenen Domain. Mein Google-Unternehmensprofil und meine Auftritte bei LinkedIn erzählten Unterschiedliches, heute stehen dort dieselben Sätze wie auf der Website. Was ich am Google-Profil korrigiert habe, steht im Beitrag „Google-Unternehmensprofil: Was ich an meinem eigenen korrigiert habe“.

Was schiefging

Vier Fehler zeigen, wo Prüfungen und Durchsicht greifen und wo sie zu spät kamen.

Die falsche Schrift in den Vorschaubildern

Die Bilder, die beim Teilen einer Seite erscheinen, zeigten ihre Überschriften seit dem Relaunch in Georgia statt in Fraunces, der Schrift der Website. Das Skript, das sie erzeugt, durfte die Schriftdatei nicht laden, und der Browser nahm ohne Meldung die Ersatzschrift. Kein Test schlug an, weil keiner danach fragte. Aufgefallen ist es am 17. Oktober an Druckvorlagen, die mit derselben Technik entstanden. Seitdem bricht das Skript ab, wenn die Schrift fehlt, und alle Vorschaubilder sind neu.

Ein Livegang, der halb durchlief

Am 12. Oktober ging nur eine der beiden Websites live. GitHub hatte an diesem Nachmittag eine Störung und lehnte die Veröffentlichung der zweiten Seite ab. Weil der Ablauf nach dem Veröffentlichen prüft, ob beide Seiten den neuen Stand ausliefern, stand er sofort auf Rot. Nach der Störung habe ich ihn neu gestartet, und beide Seiten waren wieder gleich.

Eine Angabe, die veraltet war

Für Apples Prüfung neuer Apps stand auf einer Seite „meist in weniger als einem Tag“, Apple nennt inzwischen aber 90 Prozent der Einreichungen in weniger als 48 Stunden. Aufgefallen ist das beim Nachlesen für einen neuen Beitrag. Jetzt nennt der Satz zwei Tage, und ein Test achtet darauf, dass die alte Angabe nicht zurückkommt.

Eine Meldung, die falsch gedeutet war

Seobility meldete auf dominikbaki.com „wenige interne Links“. Gezählt werden dabei die Ziele, auf die eine Seite selbst verlinkt; die erste Deutung, von der KI vorbereitet, hatte das umgekehrt verstanden. Das Nachprüfen an zwei Seiten zeigte den Fehler, bevor eine Änderung danach online ging. Mit einer vierten Seite war die Meldung dann weg.

Fazit: Dieselben Regeln wie in Ihrem Projekt

Der Website-Relaunch war für mich als App-Entwickler fremdes Terrain, das Vorgehen stammt aus 17 Jahren regulierter Produktion. Er lief in 23 Tagen bis zum Livegang und in 86 Pull Requests bis zum 17. Oktober, jeder davon von mir freigegeben. Jede Aussage hat einen Beleg, die Festpreise stützen sich auf die Messung meiner eigenen Projekte, Texte werden geprüft wie Code, und die Fehler, die trotzdem passierten, haben zu neuen Prüfungen geführt. Nach denselben Regeln arbeite ich an Ihrer App.