WordPress abgeschaltet: Mein Relaunch zur Static Site mit Claude Code

Am 28. April 2026 habe ich angefangen, jens.marketing neu zu bauen. Am 2. Mai 2026 war die WordPress-Installation aus. Vier Tage. 214 Blog-Posts, 482 Tool-Reviews, 10 synchronisierte Newsletter-Ausgaben, 460+ URLs erhalten — und keine einzige der ~250 Such-Rankings, die ich bei Google für KI-Marketing-Themen halte, ist weggebrochen.

Diese Site, die du gerade liest, ist das Ergebnis. Kein WordPress mehr, kein Plugin-Stack, kein Update-Roulette, keine MySQL-Datenbank, kein Yoast-Wizard. Stattdessen: ein Ordner mit Markdown-Dateien, ein Static-Site-Generator, ein Vercel-Deploy — und Claude Code als mein eigentlicher Editor. Ich schreibe Beiträge inzwischen über Sprache, lasse die KI das Drumherum machen, kontrolliere das Ergebnis, push direkt in die Live-Site. Was vorher ein Plugin-Tanz war, ist jetzt ein Chat.

Dieser Beitrag ist die ehrliche Innenansicht: warum ich WordPress nach mehr als zehn Jahren abgeschaltet habe, wie die Migration konkret abgelaufen ist, was ich behalten habe, was ich gelöscht habe, wie ich die SEO-Rankings unbeschadet rübergebracht habe, welche neuen Features dazugekommen sind, und wie das tägliche Arbeiten mit Claude Code aussieht. Geschrieben für Marketing-Verantwortliche, die ihre eigene Site mit ähnlichem Schmerz betrachten und überlegen, ob ein Relaunch sich lohnen würde. Spoiler: für viele ja, aber nicht für alle.

Warum WordPress 2026 nicht mehr meine Plattform ist

Ich war mehr als zehn Jahre auf WordPress. Es hat funktioniert. Es hat traffic gebracht. Es hat unzählige Beiträge ausgeliefert. Aber irgendwann fängt der Stack an, mehr Energie zu fressen, als er liefert. Drei Schmerzpunkte, in denen ich mich wiedererkannt habe — und die ich von vielen DACH-Marketing-Leads in Workshops genauso höre:

Erstens: Plugin-Stack-Hölle. Yoast für SEO, WPRocket für Caching, Wordfence für Sicherheit, BackWPup für Backups, Akismet für Spam, ein Form-Plugin, ein Embed-Plugin, ein Newsletter-Plugin, ein Cookie-Plugin, ein Affiliate-Disclosure-Plugin. Jedes davon eine eigene Subscription, eigene Update-Zyklen, eigene Sicherheitslücken, eigene Konflikte mit dem nächsten Update. Die jährlichen Plugin-Kosten landen bei vielen Sites schnell jenseits von 600 Euro — bei meinen Specs eher Richtung 900.

Zweitens: Update-Roulette. Jeder dritte WordPress-Core-Update ist ein Glücksspiel. Eines hat mir Anfang 2025 die Newsletter-Sidebar zerschossen, ein anderes 2024 die Performance auf Mobil halbiert. Du hast die Wahl: nicht updaten (= Sicherheitsrisiko) oder updaten (= unangekündigte Regression). Beides ist falsch.

Drittens: Performance war Stau. Vor dem Relaunch: Largest Contentful Paint zwischen 2,2 und 3,4 Sekunden auf Mobil. Time-to-Interactive nicht selten über 5 Sekunden. PageSpeed-Score im gelben Bereich, an manchen Tagen rot. Hinter den Kulissen: Plugin-Render-Stack, externe Asset-Loads, ein Caching-Layer, der gelegentlich gegen einen anderen kämpfte. Das war 2018 unproblematisch. 2026 ist es ein Conversion-Killer und ein Google-Ranking-Faktor (Stichwort Interaction-to-Next-Paint).

Was am Ende den Ausschlag gegeben hat, war nicht ein einzelner Schmerz. Es war die Erkenntnis, dass ich mehr Zeit mit WordPress verbringe als mit Inhalten. Die Beweisführung: ich habe eine Woche lang gemessen, wie viele Stunden ich konkret in WordPress-Verwaltung gesteckt habe (Plugin-Updates, Yoast-Konfiguration, kaputte Vorschau-Bilder fixen, Cache leeren, Backup verifizieren). Es waren 6,5 Stunden. Inhalte: ungefähr genauso viele. Wenn dein Marketing-Tool die Hälfte deiner Marketing-Zeit verbraucht, ist es nicht mehr das richtige Tool.

Der Stack vorher und jetzt

Damit klar ist, wovon ich rede: hier sind die zwei Architekturen nebeneinander. Wer technisch nicht im Detail steckt: das wichtige ist nicht, dass du jeden Begriff verstehst — sondern dass du siehst, wieviele bewegliche Teile vorher gebraucht wurden, damit Inhalte beim Leser ankommen.

Was die Architektur konkret bedeutet, in einem Satz: Inhalte sind keine Datenbank-Einträge mehr, sondern Textdateien. Jeder Blog-Post, jede Tool-Bewertung, jede Service-Seite ist eine .mdx-Datei (Markdown mit erweiterten Möglichkeiten) in einem Ordner. Die Site wird einmal pro Deploy gebaut — alle Seiten sind dann statische HTML-Dateien, die das CDN ausliefert. Keine Datenbank-Abfrage beim Seitenaufruf, keine PHP-Verarbeitung, keine Plugin-Last. Was du als Leser bekommst, ist eine fertige HTML-Seite vom CDN-Edge — typischerweise unter 300 Millisekunden.

Die Migration in fünf Schritten

So lief der Umzug konkret ab. Wer das selbst angeht: das hier ist die echte Reihenfolge, nicht die idealisierte.

Schritt 1 — Inhalte aus WordPress automatisch herunterladen. WordPress hat eine eingebaute Schnittstelle (WP-JSON), über die alle Posts und Tool-Bewertungen abrufbar sind. Ein kleines Importer-Skript hat alle 246 Blog-Posts und 482 Tool-Reviews paginiert geholt, das HTML der Inhalte über ein Tool namens Turndown in Markdown zurückübersetzt und in eine saubere Datei-Struktur gespeichert. Dauer: rund 40 Minuten für den vollständigen Lauf, weitgehend unbeaufsichtigt.

Schritt 2 — Google-Search-Console-Daten dranflanschen. Der entscheidende Schritt für SEO-Erhalt. Ich habe einen GSC-Performance-Export gezogen (URLs, Klicks der letzten 16 Monate, Impressions, Position) und das Skript hat jeden Post mit seinen Traffic-Werten als Frontmatter-Felder verknüpft. Eine URL ohne GSC-Klicks bekommt 0, eine mit 4.500 Klicks bekommt 4.500. Diese Zahlen treiben später die Sitemap-Priorität und identifizieren die Seiten, die ich auf gar keinen Fall verlieren darf.

Schritt 3 — Redirect-Map aus dem URL-Inventar bauen. Hier kommt die Magie. Ein zweites Skript liest den GSC-Export plus die neue Slug-Struktur und generiert eine Tabelle von 474 Einträgen — jede legacy-WordPress-URL zeigt auf ihren neuen Ort. Ältere URLs mit Trailing-Slash, Default-WordPress-Pfade wie /2018/03/post-name/, gelöschte Affiliate-Pfade, Newsletter-Confirmations — alles abgedeckt. Im laufenden Betrieb fängt eine Middleware die alten URLs ab und schickt einen 301-Redirect zur neuen Adresse. Google sieht den 301, behält die Rankings beim alten Pfad, leitet die Nutzer korrekt um.

Schritt 4 — Service-Seiten und Schaufenster neu schreiben. Was nicht aus dem Import kam: die Über-mich-Seite, die Service-Beschreibungen, die Workshop-Detailseiten, das Impressum, die Datenschutzerklärung. All das war auf der alten Site auch da, aber teilweise in Custom-Fields, teilweise als unstrukturierte HTML-Tags eingebettet — schmerzhaft zu importieren. Schneller war: einmal sauber neu schreiben. Hat zwei volle Tage gekostet, war aber die Gelegenheit, die Service-Beschreibungen auf den aktuellen Stand zu bringen (KI-Bootcamp, KI-Sprint, KI-Führerschein). Jede dieser Seiten hat heute ein klares Ziel und eine klare Conversion-Achse.

Schritt 5 — Live schalten und obsessiv prüfen. Der eigentliche Switch war ein DNS-Wechsel: jens.marketing zeigt seitdem auf Vercel statt auf den alten Hoster. Ich habe in den ersten zwei Stunden ungefähr 80 alte URLs handgeprüft (mit curl und im Browser): bekomme ich überall einen 301 zur richtigen neuen Adresse? Sind die Schema.org-Daten in der HTML drin? Funktioniert die Suche? Funktionieren das Newsletter-Formular und der Cookie-Banner? Bei drei Edge-Cases war Nacharbeit nötig (zwei alte URLs hatten in WordPress einen non-Standard-Slash, einer war im GSC-Export nicht enthalten). Innerhalb von 24 Stunden waren alle gefunden und gefixt.

Was ich behalten habe — und was ich gelöscht habe

Hier wird's ehrlich. Aus dem WordPress-Import kamen 246 Blog-Posts und 482 Tool-Reviews. Heute live: 214 Posts und 482 Tool-Reviews. Heißt: 32 Posts habe ich gelöscht. Was und warum?

Die 32 gelöschten Posts hatten exakt null GSC-Klicks in den letzten 16 Monaten (Ausnahme: ein Black-Friday-Post mit drei Klicks, der war thematisch ohnehin durch). Die meisten waren strukturelle Reste aus WordPress-Plugins — Newsletter-Bestätigungs-Seiten, Follower-Insights-Deal-Pages, eine englische Stub-Version der Über-mich-Seite, ein leeres /blog-Archiv, Affiliate-Landing-Pages für Tools, die wir gar nicht mehr empfehlen. Alle waren über Verweise von außen praktisch nicht erreichbar — und tauchten nur auf der internen Übersicht-Seite als Karteileichen auf.

Das ist eine wichtige Lehre für jeden Marketer, der Migration plant: null GSC-Klicks ist kein Argument für „löschen" per se. Aber wenn null Klicks plus null externe Backlinks plus null thematische Relevanz zusammenkommen, ist es das. Die anderen 14 gelöschten Posts waren teils Doppelten (zwei Posts zum gleichen Thema in zwei Stages der Tool-Story), teils englischsprachige Reste aus einer kurzen 2019er-Bilingual-Phase, die nie zu echtem Volumen kam.

Was bei mir blieb, ohne zu zögern: jeder Post mit GSC-Traffic, auch wenn der Post vier Jahre alt ist. Ein 2021er-Beitrag, der pro Monat ~80 Klicks bringt, ist organischer SEO-Wert. Den umzubringen, weil er nicht „on-brand" wirkt, ist die teuerste Form von Selbstbeschäftigung. Inhaltliche Pflege gerne, Löschen nein.

Die 482 Tool-Reviews stehen alle. Tool-Tests altern langsam — selbst ein 2022er Review zu einem KI-Schreibtool ist relevant, weil Leute aktiv „Tool X Erfahrung" googlen und meine ehrliche Einschätzung aus 2022 (mit den Limits, die das Tool damals hatte) bis heute Klicks bringt. Was ich diese Woche zusätzlich gemacht habe: eine Backfill-Aktion, die auf allen 460+ Tool-Reviews den Direkt zum Tool-Button mit dem korrekten Affiliate-/Referral-Link ergänzt hat. Vorher waren das teilweise alte Drittanbieter-Links, teilweise tote URLs.

Die unsichtbare SEO-Arbeit — die 80 % des Werts

Hier ist der Teil, den die meisten WordPress-Relaunch-Berichte unterschlagen. Ein Migration-Projekt steht oder fällt damit, ob die organische Sichtbarkeit überlebt. Sechs konkrete Maßnahmen, die ich in dem Setup verankert habe:

1. URL-Erhalt 1:1. Jeder Post-Slug, der unter WordPress lief, läuft heute auf der neuen Site unter exakt der gleichen URL. Kein Verschieben unter /blog/, kein Umstellen auf andere Hierarchien. Was rankt, behält seinen Pfad. Wer aus dem WordPress-Universum kommt: das ist ein bewusster Verzicht auf eine „saubere" URL-Struktur zugunsten von Ranking-Erhalt — und es ist der wichtigste Hebel überhaupt.

2. 474 generierte 301-Redirects. Für alle Pfade, die WordPress aus historischen Gründen unter mehreren URLs ausgeliefert hat (Trailing-Slash-Variationen, alte Datums-basierte Pfade, gelöschte Plugin-URLs), gibt es einen 301-Redirect zum neuen Ort. Generiert aus dem GSC-Export, automatisch aktualisiert, sobald ich neue Slugs lösche oder umbenenne.

3. Sitemap mit datengetriebener Priorität. Die XML-Sitemap auf jens.marketing/sitemap.xml ist nicht statisch. Sie wird bei jedem Deploy neu gebaut: jede URL bekommt eine priority zwischen 0,5 und 1,0, abgeleitet aus den GSC-Klicks. Posts mit viel Traffic (z.B. der ChatGPT-Plus-Einladungen-Beitrag mit ~12.000 Klicks/Jahr) signalisieren Google höchste Priorität, neue oder schwache Posts entsprechend weniger. Das ist Detail-Arbeit, die in WordPress mit Yoast theoretisch geht, in der Praxis aber selten sauber konfiguriert ist.

4. Strukturierte Daten überall. Jede Seite emittiert Schema.org-JSON-LD: Organization und Person global, BlogPosting für jeden Blog-Beitrag, SoftwareApplication für jedes Tool, Service für die Workshops, BreadcrumbList durchgängig. Das ist die Sorte Markup, die Google AI Overviews und ChatGPT-Search aktiv lesen — und 2026 kein Nice-to-have mehr.

5. Internal-Linking via Skript. Statt manuell „verwandte Beiträge" zu suchen, läuft ein Skript, das mir für jeden neuen Beitrag passende interne Verweise aus den 200+ vorhandenen Posts vorschlägt — gewichtet nach thematischer Überlappung, GSC-Position der Ziel-URL und Aktualität. Bei diesem Beitrag hier hat das Skript mir konkrete Vorschläge geliefert, von denen ich inzwischen mehrere inline gesetzt habe — mit dem Hinweis, dass dieselben Hebel im Claude-Code-Guide und im Beitrag zu Meta Ads über MCP ausführlicher beleuchtet sind.

6. llms.txt als Experiment. Unter jens.marketing/llms.txt liegt seit dem Relaunch eine Datei, die Inhalte für AI-Crawler maschinenlesbar listet. Ehrliche Einordnung: das ist Try-and-Error. Ob das Format 2026 wirklich Citation-Wirkung hat — ich teste es. Die aktuelle LinkedIn-Auswertung zur AI-Citation-Realität zeigt, dass die Mechaniken im Fluss sind. Wer ausprobieren will, was Wirkung zeigt, gehört zu denen, die in zwölf Monaten bessere Daten haben als alle, die abwarten.

Die Cleanup-Aktion mit den 32 gelöschten Posts ist über den Redirect-Mechanismus mit abgesichert: für jeden gelöschten Post gibt es eine sinnvolle Ziel-URL (meistens die zentrale Blog-Übersicht oder ein thematisch passender, neuerer Beitrag) — kein 404, kein verlorener Backlink-Equity.

Was an neuen Features dazugekommen ist

Migrieren ist nicht „Inhalte hin und her schieben". Es ist die Gelegenheit, alles, was im WordPress nervös geworden ist, neu und besser zu bauen. Diese fünf Features sind seit dem Relaunch live und auf der alten Site nicht da gewesen:

Cmd-K-Suche. Der schwarze Knopf oben rechts (oder Cmd-K von überall). Volltext-Suche über alle 700+ Inhalte (Posts, Tools, Newsletter), Fuzzy-Matching, Tastatur-Navigation, lädt einmal beim ersten Öffnen — danach Sekunden-schnell. Das alte WordPress-Such-Plugin war so langsam, dass ich es vor zwei Jahren rausgeworfen hatte.

Tool-Browser mit Kategorie-Filter. Die Tool-Sammlung hat jetzt eine durchsuchbare Übersicht mit Kategorie-Filtern und Lazy-Loading. Vorher war das eine WordPress-Custom-Post-Type-Anzeige, die bei mehr als 100 Einträgen langsam wurde.

HTML-Sitemap unter /uebersicht. Eine menschenlesbare Übersicht aller Inhalte — strukturiert nach Hauptseiten, Beratungs-Formaten, Workshop-Formaten, Newslettern, rechtlichen Seiten. Brauchen Marketer für interne Audits, brauchen Suchmaschinen für Crawling-Effizienz.

Dino-Game als Easter-Egg. Wer das Jens-Portrait auf der Startseite oft genug klickt, landet im Mini-Game. Mit globalem Leaderboard auf Upstash-Redis und HMAC-signierten Score-Tokens gegen Cheating. War kein Migrationsziel — entstand Sonntagabend um zehn, weil ich Lust hatte. Das kostet auf der neuen Architektur 20 Minuten, in WordPress wäre es ein Custom-Plugin gewesen.

OG-Image-Generierung pro Seite. Wenn jemand einen meiner Posts auf LinkedIn oder X teilt, erscheint ein automatisch generiertes Vorschau-Bild mit dem Beitragstitel und dem Markendesign. Vorher war das ein leeres oder fehlerhaftes WordPress-Default-Bild.

Der eigentliche Game-Changer: Schreiben mit Claude Code

Das ist die Stelle, an der „Migration zu Static Site" auf einmal mehr ist als ein technisches Update. Auf WordPress war mein Schreibworkflow: Beitrags-Editor öffnen, Block-für-Block tippen, Bilder hochladen, Yoast-Hinweise ignorieren, dreimal vorschauen, publizieren, hoffen dass die Vorschau-Bild-Cache-Invalidation mitgemacht hat. Dauer pro 1.500-Wörter-Beitrag: vier bis sechs Stunden, davon mindestens zwei Stunden reines „in WordPress arbeiten".

Heute: ich öffne das Terminal in meinem Site-Repo, starte Claude Code, sage „Schreib mir einen Beitrag über X, mit drei SVG-Grafiken im Site-Stil, internal links via suggest-links.mjs, ehrlicher Voice — siehe content-guide.md." Während ich Mittag mache, laufen fünf Recherche-Subagents parallel, ziehen Quellen, sortieren Daten, kommen mit strukturierten Briefs zurück. Claude schreibt den Beitrag in meiner Stimme (er kennt sie aus der jens-brief.md-Datei), validiert das Frontmatter gegen das Schema, baut die SVGs, schlägt mir interne Links vor.

Ich review das Ergebnis. Korrigiere wenn nötig. Push.

Drei Befehle: git push origin main && vercel --prod — und die Site ist live. Vorbereitung bis Live: heute eher 30–45 Minuten als 4 Stunden. Der Beitrag, den du gerade liest, ist genau so entstanden — Recherche durch Claude (Verifizierung der Migrations-Zahlen aus dem Repo), Schreiben in meiner Stimme (nach Voice-Brief), Internal-Linking auf vorhandene Beiträge automatisch vorgeschlagen, drei SVG-Grafiken im Stil, validiert, deployed.

Das ist das, was sich für mich qualitativ verändert hat: Claude Code ist nicht „KI hilft mir beim Schreiben" — es ist „die Maschine kennt meine Marke und kann routinemäßig in meiner Stimme handeln, ich kontrolliere die Richtung und das Urteilsvermögen". Wer das Konzept tiefer verstehen will: ich habe es im ehrlichen 2026-Guide zu Claude Code ausführlich beschrieben — inklusive der sieben Use-Cases, die wirklich tragen, und dem Cost-Check pro Persona.

Was kostet mich das jetzt im Vergleich

Ehrliche Zahlen, die ich für die WordPress-Site gegen das aktuelle Setup habe.

Vorher (WordPress-Stack, monatlich):

Jetzt (Static-Site-Stack, monatlich):

Differenz: ~55 EUR weniger pro Monat. Plus die qualitative Veränderung: Stunden, die ich nicht mehr in WordPress-Verwaltung stecke. Konservativ gerechnet (3 Stunden weniger pro Monat × 200 EUR/Stunde Marketing-Berater-Satz): nochmal 600 EUR an versteckten Kosten gespart.

Wichtige Einschränkung: das Setup ist auf einen Solo-Operator zugeschnitten, der die Site selbst pflegen will und sich vor Markdown-Dateien nicht fürchtet. Wer eine 5-Personen-Marketing-Abteilung mit zehn nicht-technischen Redakteur:innen ausstattet, muss anders rechnen — entweder mit einem Headless-CMS-Plus-Static-Setup (z.B. Sanity, Contentful, Payload) oder bei WordPress bleiben. Das WordPress-Verbot ist hier kein Glaubenssatz.

Was ich gelassen habe — und gerne ehrlich sage

Damit das ehrlich bleibt, drei Dinge, die mit dem Relaunch verloren gegangen sind:

Kommentare. Auf der WordPress-Site gab es Kommentar-Funktion unter jedem Beitrag. War seit Jahren ein 95-%-Spam-Magnet, der pro Woche 30 Minuten Pflege gekostet hat. Trotzdem: vereinzelt sind echte Kommentare gekommen, mit Hinweisen, mit Nachfragen. Diese 5 % der echten Kommentare sind weg. Ersatz: das Kontaktformular, der LinkedIn-DM, die E-Mail. Die echten Fragen kamen ohnehin meist über diese Kanäle.

Native WordPress-Plugins, die ich nicht ersetzt habe. Ein Affiliate-Disclosure-Plugin, das automatisch unter jedem Tool-Beitrag eine Footer-Box gerendert hat. Ein Plugin, das aus YouTube-URLs automatisch Embeds machte. Beides habe ich für die Migration in den Velite-Schema-Builder eingebaut, aber die UX ist anders. Wer aus WordPress das „klick auf Plugin-Settings, alles erledigt"-Modell gewohnt ist, muss sich umgewöhnen.

Die Möglichkeit, von einem fremden Rechner aus zu schreiben. Auf WordPress ist wp-admin von überall erreichbar. Mein neues Setup will, dass ich Claude Code lokal habe, den Repo lokal habe, eine Authentifizierung im Terminal habe. Auf einem fremden Laptop in der Bahn ist das nicht in einer Minute herzustellen. Lösung: ich arbeite an einem Telegram-Bot, der mir Claude Code remote ansprechbar macht — der entsprechende Vorschlag dazu liegt schon, mit Setup-Plan und Kosten-Check. Hat noch keine Priorität, weil ich an einem fremden Rechner ohnehin selten poste.

Würdest du es genauso machen?

Wenn du eine WordPress-Site hast, die regelmäßig Inhalte produziert, deren Plugin-Stack über die Jahre gewachsen ist und wo du mehr Zeit mit Plugin-Updates als mit Schreiben verbringst — ja, ein Relaunch lohnt sich wahrscheinlich. Die zwei Bedingungen, die zusammenkommen müssen:

1. Du bist bereit, mit Markdown-Dateien zu arbeiten — direkt oder über ein vorgeschaltetes CMS. Wer ausschließlich in einem Klick-Editor existiert, wird nicht happy.
2. Du hast jemanden, der das Setup einmal sauber aufzieht — einen technisch affinen Marketer, einen Freelancer, oder dich selbst nach einer Workshop-Vorbereitung. Die Migration ist nicht „in zwei Stunden mit Plugin X". Sie ist vier konzentrierte Tage, mit einer Person die weiß was sie tut, oder einem KI-Tool wie Claude Code, das die operative Routine übernimmt.

Wer das nicht hat, bleibt entweder bei WordPress (mit besserem Plugin-Hygiene) oder geht zu einer Headless-CMS-Lösung wie Sanity, Contentful, oder Webflow. Beide sind teurer als mein Setup, aber haben eine UI, die nicht an Markdown-Dateien hängt.

Wer es selbst angeht: drei kleine Hilfen aus meiner Praxis. Erstens, fang früh mit dem Redirect-Plan an — das ist die ein-Stelle-falsch-und-Rankings-weg-Stelle. Zweitens, lass die GSC-Daten in den Migrations-Prozess einfließen — sie sind dein bester Kompass für „was darf ich nicht löschen, was kann weg". Drittens, plan eine Woche „obsessive Prüfung" nach dem Live-Schalten ein — alle Hauptseiten manuell, alle Top-50-URLs aus der GSC manuell, alle Forms manuell. Die kleinen Edge-Cases sind die teuren.

Wenn du mit deinem Stack hadern und dir überlegst, ob ein Relaunch dir Zeit zurückgeben würde — schreib mir kurz, was bei euch ansteht. Werktags innerhalb von 24 Stunden Antwort. Und wenn du regelmäßig wissen willst, was sich an Tools, Workflows und KI-Marketing-Setups verändert, ohne jeden Wochen-Newsletter selbst recherchieren zu müssen — der KI-Newsletter liefert das jeden Sonntag in fünf Minuten.