Der Claude-Code-Tech-Stack für eine agentische Website

Kurz gesagt: Eine agentische Website ist eine Marketing-Website, die KI-Agenten mit aufbauen, betreiben und verbessern, während Menschen die wichtigen Änderungen freigeben. Der passende Stack hält alles, was ein Agent anfasst, in Dateien, die er lesen kann: ein statisches Website-Framework wie Astro, ein Headless-CMS mit Schemas im Code wie Sanity, ein Hosting mit Deploy-Previews und geplanten Funktionen wie Netlify und Claude Code, das über Pull Requests arbeitet.

Die meisten B2B-SaaS-Teams nutzen inzwischen KI, um Texte zu schreiben. Deutlich weniger lassen einen Agenten die Website selbst ändern, und wer es versucht, merkt oft auf die harte Tour, woran es liegt: Eine Plattform, die für Klicks in einem visuellen Editor gebaut ist, gibt einem Agenten nichts zum Lesen, nichts zum Testen und keinen sicheren Ort zum Ausprobieren. Abhilfe schafft ein Stack mit Regeln, die von Anfang an für den Agenten ausgelegt sind.

Dieser Leitfaden beschreibt diesen Stack, die Leitplanken, die eine Live-Website schützen, und die Agent-Workflows, die darauf laufen. Er basiert auf dem Relaunch von saas-hackers.com, der auf Astro, Tailwind, Sanity und Netlify läuft und mit Claude Code gebaut wurde. Falls Sie noch klären, was Ihre Website überhaupt leisten soll, beginnen Sie mit unserem Leitfaden zur B2B-SaaS-Website-Strategie und kehren Sie für den Aufbau hierher zurück.

Was ist eine agentische Website?

Eine agentische Website ist eine Website, bei der KI-Agenten einen Großteil von Aufbau und Pflege übernehmen, und zwar innerhalb von Regeln, die Menschen festlegen, und mit Prüfungen, die jedes Mal laufen. Agenten schreiben Seiten, beheben Links, aktualisieren Inhalte und eröffnen Code-Änderungen. Menschen bestimmen, wofür die Website da ist, geben Riskantes frei und kontrollieren die Ergebnisse.

Das unterscheidet sie von einem KI-Website-Builder, der eine Website einmalig aus einem Prompt erzeugt. Auf einer agentischen Website arbeitet der Agent nach dem Launch weiter, wie es ein Entwickler und ein Content-Redakteur täten, und jede seiner Änderungen durchläuft dieselbe Prüfung wie die eines Menschen.

Drei Dinge machen eine Website agentisch und nicht nur KI-gestützt:

• Der Agent kann alles lesen, was die Website definiert. Seitentemplates, Inhaltstypen, Design-Tokens, Weiterleitungen und die Regeln selbst liegen in einem Code-Repository und nicht nur in einem Dashboard.
• Jede Änderung lässt sich testen, bevor sie live geht: mit einem Build, der bei einer defekten Seite fehlschlägt, einem Vorschau-Link für jede Änderung und einem Testlauf für jedes Content-Skript.
• Menschen behalten die entscheidenden Schlüssel. Code zusammenführen, sensible Inhalte veröffentlichen und alles, was Geld kostet, bleibt bei einer namentlich benannten Person.

Warum ist der Stack wichtiger, wenn Agenten die Arbeit erledigen?

Der Stack ist umso wichtiger, weil ein Agent nur mit dem sicher arbeiten kann, was er sehen und prüfen kann. Ein Mensch erkennt in einem visuellen Editor, dass eine Seite falsch aussieht. Ein Agent braucht dieses Wissen schriftlich festgehalten: als Schema, das ein fehlendes Feld ablehnt, als Prüfung, die den Build scheitern lässt, oder als Regel in einer Datei, die er vor jeder Sitzung liest.

Ein für Agenten gebauter Stack hat vier Eigenschaften:

1. Text statt Klicks. Konfiguration, Content-Modelle und Styles sind Dateien im Repository, sodass ein Agent sie lesen, ändern und erklären kann.
2. Schnelles, ehrliches Feedback. Ein Build oder Test, der laut scheitert, sagt dem Agenten, dass er falsch liegt, bevor es ein Besucher merkt.
3. Ein sicherer Ort zum Ausprobieren. Branches, Entwürfe und Vorschau-Links erlauben es einem Agenten, seine Arbeit zu zeigen, ohne die Live-Website anzufassen.
4. Ein einziges Review-Gate. Jede Code-Änderung kommt als Pull Request, den eine Person lesen und zusammenführen oder ablehnen kann.

Sind diese Voraussetzungen erfüllt, spielt die Wahl des Modells eine geringere Rolle. Fehlen sie, geht irgendwann auch bei einem sorgfältigen Agenten etwas kaputt, weil ihm nichts sagt, dass es passiert ist.

Wie sieht der Claude-Code-Tech-Stack für eine agentische Website aus?

Der Stack besteht aus fünf Schichten: einem statischen Website-Framework, einem Headless-CMS, einem Hosting, dem Agenten und dem Review-Gate dazwischen. Jede Schicht ist da, weil sie dem Agenten etwas zu lesen oder etwas zu prüfen gibt.

Ein statisches Website-Framework: Astro

Astro baut Seiten im Voraus. Standardmäßig rendert es jede Seite, Route und jeden Endpoint beim Build vorab als statisches HTML, und einzelne Routen schalten Sie bei Bedarf auf Rendering auf Anfrage um (Astro, 2026). Für einen Agenten ist statische Ausgabe ein Geschenk: Nach dem Build existiert die ganze Website als Dateien, sodass ein Skript jede Seite prüfen kann, bevor etwas live geht.

SaaS Hackers rendert jede Seite statisch. Die einzige Seite, die auf Anfrage gerendert wird, ist die Entwurfsvorschau, die Redakteure aus dem CMS öffnen, um unveröffentlichte Änderungen zu sehen. Alles andere wird beim Build geprüft, und der Inhalt steckt schon beim ersten Laden im HTML, einschließlich jedes Eintrags in einer gefilterten Liste.

Ein Headless-CMS mit Schemas im Code: Sanity

Ein Headless-CMS trennt den Inhalt vom Design der Website und liefert ihn über eine API an die Website aus. Für Agenten kommt es darauf an, wo das Content-Modell liegt. In Sanity beschreibt ein Schema die Dokumenttypen und Felder, die Redakteure anlegen dürfen, und es wird im Code in der Konfiguration des Studios definiert (Sanity, 2026).

Weil die Schemas Code sind, kann ein Agent genau nachlesen, woraus ein Blogbeitrag oder ein Profil besteht, über einen Pull Request ein Feld hinzufügen und Inhalte per Skript schreiben, die das Schema validiert. Redakteure behalten trotzdem einen visuellen Editor. SaaS Hackers hält jedes Schema im Repository und nie nur im Dashboard, so steht es in der Projektdatei.

Ein Hosting mit Previews und Funktionen: Netlify

Das Hosting gibt dem Agenten zweierlei: eine Vorschau jeder Änderung und einen Ort für kleine Jobs. Netlify baut automatisch eine Deploy-Preview, sobald in einem verbundenen Repository ein Pull Request eröffnet wird, unter einer eigenen Adresse und mit einem noindex-Header, damit Suchmaschinen sie ignorieren (Netlify, 2026). Über diesen Vorschau-Link prüft eine Person die Änderung eines Agenten auf einer echten Seite, bevor sie zusammengeführt wird.

Geplante Funktionen von Netlify laufen wie ein Cron-Job nach festem Zeitplan in UTC, nur auf dem veröffentlichten Produktions-Deploy und mit einem Limit von 30 Sekunden pro Lauf (Netlify, 2026). Kurze, geplante Jobs passen gut zur agentischen Pflege: prüfen, ob sich etwas geändert hat, und dann entscheiden, ob neu gebaut wird.

Claude Code: CLAUDE.md, Skills, Hooks und MCP

Claude Code ist der Agent. Vier seiner Funktionen machen aus einem leistungsfähigen Modell ein verlässliches Teammitglied:

• CLAUDE.md. CLAUDE.md-Dateien sind Markdown-Dateien, die Claude dauerhafte Anweisungen für ein Projekt geben und die Claude zu Beginn jeder Sitzung liest (Anthropic, 2026). Über die Versionskontrolle geteilt, enthält die Projektdatei die Build-Befehle, Standards und Regeln, nach denen alle arbeiten.
• Skills. Ein Skill ist eine SKILL.md Datei mit Anweisungen, die Claude seinem Werkzeugkasten hinzufügt und bei Bedarf nutzt. Anders als CLAUDE.md wird der Inhalt eines Skills erst geladen, wenn er gebraucht wird, sodass lange Abläufe bis dahin fast nichts kosten (Anthropic, 2026). Unser Erklärartikel zu Claude Skills für Marketing-Teams zeigt, wie sie für Texte funktionieren.
• Hooks. Hooks sind Shell-Befehle, die Claude Code an festgelegten Punkten ausführt. Das schafft deterministische Kontrolle: Bestimmte Aktionen passieren immer, statt dass das Modell sie auswählen muss (Anthropic, 2026). Nutzen Sie sie für Regeln, die nie nachgeben dürfen, etwa um Änderungen an einer Datei mit Zugangsdaten zu blockieren.
• MCP-Server. Das Model Context Protocol ist ein Open-Source-Standard, um KI-Tools mit anderen Systemen zu verbinden, und MCP-Server geben Claude Code Zugriff auf Ihre Tools, Datenbanken und APIs (Anthropic, 2026). So liest ein Agent Analytics, Rankings oder ein CMS direkt aus, statt mit dem zu arbeiten, was Sie einfügen. Unser Leitfaden zu KI-Marketing-Agenten und MCP zeigt, welche Marketing-Tools Sie anbinden können.

Cloud-Sessions und geplante Aufgaben

Eine Cloud-Session ist eine Claude-Code-Sitzung, die auf Cloud-Infrastruktur statt auf Ihrem Laptop läuft und weiterläuft, wenn Sie den Deckel schließen (Anthropic, 2026). Geplante und ausgelöste Läufe starten jeweils als Cloud-Session. So kann ein Agent um 01:43 Uhr einen Blogbeitrag veröffentlichen oder an einem Dienstagmorgen Rankings messen, ohne dass jemand an der Tastatur sitzt.

GitHub Pull Requests als Review-Gate

Jede Code-Änderung eines Agenten landet in einem Branch und kommt als Pull Request an. Daraus wird die Deploy-Vorschau gebaut, darauf laufen die Prüfungen, und eine Person führt den Pull Request zusammen oder eben nicht. Bei SaaS Hackers gilt eine klare Regel: Agenten eröffnen Pull Requests, und Darren führt sie zusammen. Kein Agent mergt seine eigene Arbeit.

Wie verhindern Sie, dass ein Agent eine Live-Website kaputt macht?

Ein Agent bringt eine Live-Website nicht zum Absturz, wenn der sichere Weg der einzige Weg ist: ein Backup vor jedem Schreibvorgang, ein Probelauf, der die Änderung zeigt, Prüfungen in jedem Build und Grenzen dafür, was er allein ändern darf. Nichts davon hängt davon ab, dass der Agent daran denkt, vorsichtig zu sein. Es ist in Skripten, Schemata und im Build festgeschrieben.

Sichern, Probelauf, dann schreiben

Jedes Skript, das bei SaaS Hackers veröffentlichte Inhalte ändert, funktioniert nach demselben Prinzip:

1. Sichern. npm run backup exportiert den gesamten Datenbestand in eine datierte Datei, bevor sich etwas ändert.
2. Probelauf. Das Skript läuft ohne --write, prüft alles und schreibt einen Bericht darüber, was es ändern würde.
3. Probelauf lesen. Der Agent oder eine Person liest diesen Bericht, bevor es weitergeht.
4. Schreiben. Erst dann läuft dasselbe Skript mit --write.
5. Prüfen. Die Website wird aus den veröffentlichten Inhalten gebaut, und die Routen- und Schema-Prüfungen laufen.

Die Übergabe nach jedem Auftrag nennt das erstellte Backup, sodass sich jede Änderung rückgängig machen lässt.

Sperren im CMS

Manche Fehler verhindert man im CMS günstiger, als man sie später findet. Im Studio von SaaS Hackers wird ein Slug gesperrt, sobald sein Dokument veröffentlicht ist, sodass sich eine Live-Adresse nicht versehentlich ändern kann. Eine Seite kann nicht unter einer Adresse veröffentlicht werden, für die eine aktive Weiterleitung besteht, und neue Bilder lassen sich nicht ohne Alt-Text veröffentlichen. Skripte nehmen Inhalte aus der Veröffentlichung, statt sie zu löschen, und lassen die Entwürfe anderer Personen unangetastet.

Prüfungen in jedem Build

Der Build ist der ehrlichste Kritiker des Agenten. Bei SaaS Hackers npm run build bricht ab, wenn eine dieser Prüfungen fehlschlägt:

• veraltete Design-Tokens, Farben oder Größen außerhalb der Tokens oder Text mit zu geringem Kontrast;
• ein CMS-Abschnittsblock ohne passende Seitenkomponente;
• strukturierte Daten, die sich nicht parsen lassen oder das Schema ihres Seitentyps nicht erfüllen, oder eine Seite ohne genau eine H1;
• Sprachverweise (hreflang), die nicht in beide Richtungen zeigen.

Nach einem Build bestätigt die Routenprüfung, dass jede relevante Live-Adresse einen 200-Status liefert, und die Paritätsprüfung vergleicht Titel, Beschreibungen, Canonicals, Überschriften und Schema mit der Live-Website. Auch die Geschwindigkeit gehört in die Prüfungen: Unser Handbuch-Eintrag zu Core Web Vitals erklärt, welche Messwerte sich zu beobachten lohnen.

Zugangsdaten bleiben aus dem Repository heraus

Tokens und Schlüssel liegen in einer lokalen .env Datei, die git ignoriert, und in den Umgebungsvariablen des Hosts. Das Repository enthält nur eine Liste ihrer Namen. Ein Agent kann einen Schlüssel aus seiner Umgebung verwenden, ohne ihn je in eine Datei, einen Commit oder einen Bericht zu schreiben.

Grenzen für das, was ein Agent allein ändern darf

Legen Sie im Voraus fest, was ein Agent ohne Rückfrage tun darf, halten Sie es schriftlich fest und erzwingen Sie es, wo möglich, im Code. So teilt SaaS Hackers das heute auf:

• Blogbeiträge werden direkt veröffentlicht, sobald die Prüfungen des Skripts bestanden sind, und eine Person prüft sie anschließend.
• Seitentexte, Titel und interne Links ändert der SEO-Agent, innerhalb fester Grenzen pro Lauf.
• Code-Änderungen gehen in einen Pull Request, den eine Person zusammenführt.
• Profilanfragen von Agenturen warten, bis eine Person in Slack auf „Approve“ tippt.
• Scores, Bewertungen und Rankings ändert ein Agent nie, auch nicht auf Anfrage.

Kostengrenzen

Agenten können schnell Geld ausgeben, daher sind auch die Kosten eine Leitplanke. SaaS Hackers hat früher bei jeder Veröffentlichung neu gebaut, und jedes Produktiv-Deployment kostet 15 Netlify-Credits. Neu gebaut wird jetzt nur noch einmal am Tag: Eine geplante Funktion läuft um 05:17 UTC und baut nur dann neu, wenn seit dem Live-Build etwas veröffentlicht wurde. Außerdem steht im Briefing des SEO-Agenten, dass er nie selbst ein Deployment auslösen darf.

Welche Agent-Workflows laufen auf einer agentischen Website?

Sobald Stack und Leitplanken stehen, können Agenten die wiederkehrenden Aufgaben übernehmen, die sonst gern untergehen: veröffentlichen, messen, aktualisieren und übersetzen. Jeder Workflow hat ein schriftliches Briefing, einen Zeitplan, Grenzen und einen Bericht.

Alle zwei Tage einen Blogbeitrag veröffentlichen

Eine geplante Aufgabe schreibt und veröffentlicht alle zwei Tage um 01:43 UTC einen Beitrag aus dem Content-Backlog, vor dem täglichen Rebuild. Sie schreibt mit einem Copywriting-Skill und prüft den Text mit einem Content-Audit-Skill. Anschließend lehnt ein Veröffentlichungsskript den Beitrag ab, wenn es einen Gedankenstrich, einen Platzhalter, einen falschen Slug, eine zu lange Meta-Beschreibung, weniger als drei interne Links oder einen internen Link findet, der nicht live ist. Es legt ausschließlich neue Beiträge an und ändert nie einen bestehenden.

Ein SEO-Agent, der zweimal pro Woche misst und handelt

Dienstags und freitags um 06:41 UTC misst eine frische Sitzung die Rankings, bewertet die Website anhand ihrer Ziele und arbeitet eine nach Priorität sortierte Liste von Maßnahmen ab. Pro Lauf darf der Agent höchstens 8 Seiten ändern, 1 neue Liste anlegen und 30 interne Links hinzufügen, mit Obergrenzen für kostenpflichtige Datenabrufe und Übersetzungskosten. Er hält jede Änderung mit einer Vorher-Kopie fest, sodass sie sich rückgängig machen lässt, leitet Code-Änderungen in Pull Requests und berichtet im Slack-Kanal des Teams. Unser Vergleich von Claude Code und AirOps für Content-Teams zeigt, wann ein solches Setup ein No-Code-Tool übertrifft.

Verzeichnisprofile aktuell halten

Ein monatliches Skript prüft die Website jeder Agentur und hält fest, ob sie funktioniert, umgezogen ist oder nicht mehr erreichbar ist. Ein vierteljährlicher Crawl liest die eigene Website jeder Agentur und speichert die dort genannten Fakten. Dabei ergänzt er Service- und Branchen-Tags, die die Website nennt, entfernt aber nie einen. Scores, Bewertungen und Rankings werden von keinem der beiden angetastet.

In Slack freigegebene Anfragen

Agenturen können darum bitten, ihr Profil zu aktualisieren, oder sich für einen Eintrag bewerben. Jede Anfrage wird per E-Mail bestätigt, von Claude anhand der eigenen Website der Agentur geprüft, als CMS-Entwurf gespeichert und als Karte an Slack gesendet. Nur eine freigabeberechtigte Person kann auf „Approve“ tippen, jeder Klick wird anhand der Anfragesignatur von Slack geprüft, und über jede Anfrage lässt sich nur einmal entscheiden.

Jede Seite übersetzen

Jede Seite von SaaS Hackers gibt es auch auf Deutsch, Französisch, Spanisch, Niederländisch, Japanisch und in brasilianischem Portugiesisch. Claude Sonnet 5.5 hat die Website über die Batch API übersetzt, insgesamt für 91,35 $, und spätere Läufe senden nur noch geänderten Text. Zitate und das, was Agenturen auf ihren eigenen Websites über sich sagen, bleiben wortgetreu auf Englisch.

Wie wurde SaaS Hackers auf diesem Stack gebaut?

SaaS Hackers wurde mit Claude Code in Phasen von Webflow auf Astro, Tailwind, Sanity und Netlify umgebaut, jede Phase als Pull Request, den eine Person bei SaaS Hackers geprüft und zusammengeführt hat. Die Projektdatei legte Reihenfolge, Regeln und Befehle fest, und eine schriftliche Spezifikation definierte, was „fertig“ für jede Phase bedeutete. Die Designseite dieses Umbaus behandelt unser Leitfaden zum Erstellen einer Website mit Claude Code.

Bei der Migration wurden 233 Beiträge und 172 Expertenprofile zunächst als Entwürfe nach Sanity übertragen und mit den Live-Seiten verglichen, bevor irgendetwas veröffentlicht wurde. In der SEO-Phase kamen eine Prüfung hinzu, ob die strukturierten Daten jeder Seite parsbar sind, sowie eine Paritätsprüfung gegen die Live-Website. Als die neue Website Webflow ablöste, lieferte die Routenprüfung 494 von 494 Live-Adressen, ein Build mit 3.936 Seiten (Englisch, die US-Version und sechs Sprachen) dauerte 8,5 Minuten, und die Lighthouse-Mobile-Performance lag auf den im Produktivsystem getesteten Seiten bei 99 bis 100.

Derselbe Stack trägt heute die oben beschriebenen Agenten-Workflows. Drei Dinge haben das möglich gemacht: eine Projektdatei, die jede Sitzung liest, Skripte, die fehlerhafte Eingaben ablehnen, und eine Person, die den Code zusammenführt. Wenn Sie den Blick auf Marketing Operations ergänzen möchten, behandelt unser Leitfaden zu B2B-SaaS-Marketing-Operations die Daten und Tools rund um die Website.

Welche Vorteile hat eine agentische Website?

Der Nutzen entsteht dadurch, dass wiederkehrende Arbeit pünktlich und jedes Mal erledigt wird, samt Protokoll darüber, was sich geändert hat:

• Die Pflege erfolgt pünktlich. Defekte Links, veraltete Fakten und fehlende Meta-Beschreibungen werden nach Zeitplan behoben statt in einer jährlichen Großaktion.
• Änderungen lassen sich rückgängig machen. Dank Backups, Vorher-Kopien und Pull Requests kann jede Änderung eines Agenten nachverfolgt und zurückgenommen werden.
• Es gibt weniger Übergaben. Ein Agent kann Inhalte, Templates und Prüfungen im selben Pull Request ändern, statt die Arbeit zwischen Texter, Entwickler und SEO weiterzureichen.
• Die laufenden Kosten können mit dem richtigen Stack niedrig sein. Die eigene Kostenprüfung von SaaS Hackers ergab für die neue Website keine zusätzlichen Hosting-Gebühren, wobei vor allem die Netlify-Credits für Deployments im Blick behalten werden müssen.

Typische Probleme agentischer Websites und wie Sie sie lösen

Der Agent macht denselben Fehler zweimal. Er erinnert sich nicht an die letzte Sitzung. Schreiben Sie die Regel in CLAUDE.md oder einen Skill, sobald Sie ihn korrigieren, damit jede künftige Sitzung damit beginnt.

Änderungen sehen im Code gut aus, wirken auf der Seite aber falsch. Ohne Vorschau sieht niemand die Seite, bevor sie live ist. Verlangen Sie in jedem Pull Request einen Link zur Deploy-Vorschau und prüfen Sie die Seite selbst, bevor Sie mergen.

Die Checks laufen durch, doch die Website driftet trotzdem. Checks fangen nur ab, was sie testen. Rutscht etwas durch, fügen Sie dem Build einen Check dafür hinzu, damit es nicht noch einmal passiert.

Die Kosten steigen schleichend. Jeder Rebuild, jeder Crawl und jeder API-Aufruf kostet etwas. Legen Sie in der Anweisung jedes Agenten ein Limit fest, bündeln Sie Rebuilds und lassen Sie die Ausgaben in der Übergabe jedes Durchlaufs ausweisen.

Niemand weiß, was der Agent geändert hat. Verlangen Sie nach jeder Aufgabe eine Übergabe: was sich geändert hat, welches Backup erstellt wurde, welche Checks gelaufen sind und was der Agent nicht erledigen konnte.

Worauf Sie achten sollten, wenn Sie sich beim Aufbau Hilfe holen

Wenn Sie eine Agentur oder einen Entwickler für eine agentische Website hinzuziehen, lassen Sie sich die Leitplanken zeigen, nicht nur das Design. Ein guter Partner zeigt Ihnen:

• eine Projektanweisungsdatei und die darin enthaltenen Regeln;
• Content-Skripte mit Probelauf (Dry Run) und Backup-Schritt;
• Build-Checks, die bei echten Problemen fehlschlagen, samt den Befehlen zum Ausführen;
• eine klare Trennung zwischen dem, was Agenten ändern dürfen, und dem, was ein Mensch freigibt;
• die laufenden Kosten schriftlich, einschließlich Deployments und API-Nutzung.

Spezialisten können Sie in unserer Liste der besten Webdesign-Agenturen für B2B SaaS vergleichen.

Über SaaS Hackers

SaaS Hackers ist eine Community von B2B-SaaS-Spezialisten, die praxisnahe Erkenntnisse teilen, aufgebaut von den Menschen hinter dem Wachstum: Marketern, Strategen und Machern. Sie veröffentlicht Leitfäden, ein Handbuch und Bestenlisten und betreibt ein Verzeichnis von B2B-SaaS-Marketingagenturen und -Experten. SaaS Hackers wird von Team 4 betrieben, einer B2B-SaaS-Marketingagentur, die im Verzeichnis gelistet und bewertet ist.