Alle Episoden
27
48 min

Webseiten-Migration Teil B: Go-Live, SEO-Crash und Bot-Attacken

Doppelfolge, Teil B: Die ehrliche Bilanz nach dem Go-Live von kernkompetenz-pferd.de. Wie 150 Blogposts und 420 Bilder rübergekommen sind, wie Bots im Klick-Tipp-Formular gelandet sind und mit drei Tricks gestoppt wurden, was beim DNS-Switch passiert ist und wie der SEO-Healthscore von 23 auf 96 zurückkam. Plus: vier konkrete Gewinne nach der Migration und das ehrliche Fazit für wen dieser Weg passt – und für wen nicht.

SoloWebseiteMigrationNext.jsWordPressSEOGo-LiveDSGVOBotsClaude CodeVercelPraxis-Beispiel

Externer Inhalt blockiert

Der Podcast-Player wird von Podigee bereitgestellt. Bitte akzeptiere externe Inhalte in den Cookie-Einstellungen, um den Player zu laden.

Das nimmst du mit

  • Content-Migration über die WordPress-API: Alle 150+ Blogposts und 420 Bilder via Skript exportiert, Bilder lokal ins Repo gezogen, Bild-URLs auf relative Pfade umgeschrieben. Typische Stolperstellen: Umlaute in Dateinamen und einzelne Bilder, die erst nach dem Go-Live in der Search Console als tot auffallen.
  • Bot-Schutz ohne Captcha: Drei Filter gleichzeitig stoppen automatisierte Anmeldungen – ein Honeypot-Feld (versteckt im Code, nur Bots füllen es aus), eine Zeitprüfung (Mensch braucht mindestens ein paar Sekunden) und ein Rate-Limit pro IP-Adresse. Alles serverseitig vor der Klick-Tipp-Übergabe.
  • DSGVO-Cookie-Consent selbst gebaut: Das eigentliche An/Aus von Tracking ist trivial – die Pflicht zur Aufzeichnung jeder Consent-Entscheidung über bis zu einem Jahr braucht eine separate Datenbank (bei KKP: Supabase).
  • Nach dem Go-Live ging der SEO-Healthscore zunächst auf 23. Ursachen: nur ein Bruchteil der 154 Blogposts wurde indexiert (Migrations-Klassiker zwischen Frameworks), uneinheitliche Canonical-URLs (mit und ohne www) und doppelte Markennamen in Titel und Meta-Beschreibung. Nach Analyse mit Search Console, Ahrefs und Claude Code: an einem Vormittag auf 96 zurück.
  • Die echten Gewinne nach der Migration: eine Notion-Blog-Pipeline (Transkript rein, fertiger SEO-Artikel in drei Minuten), der Pferdemenschen-Typentest komplett auf der eigenen Seite ohne E-Mail-Hopping, eine KI-illustrierte Wurm-Geschichte als Funnel-Element und ein eigenes A/B-Test-Framework über Vercel Analytics – statt 500 € pro Monat für externe Tools.

Disclaimer vorweg

Diese Folge ist deutlich technischer als üblich – und deutlich länger. Wer das Grundsätzliche zur Migration mitnehmen möchte, ist mit Folge 26 (Teil A) gut bedient. Wer wissen will, was beim Go-Live wirklich passiert und welche Stolperfallen nach dem DNS-Switch auf einen warten: hier weiterlesen oder weiterhören.

Ein Vorteil der kleinen Verspätung dieser Folge: Es gibt nicht nur Theorie zum Go-Live, sondern auch die ehrlichen Themen aus den Wochen danach – SEO-Einbruch, Bot-Anmeldungen, 404-Aufräumarbeiten. Genau das, was bei "kürzlich migriert" sonst gerne unter den Tisch fällt.

Content-Migration: 150 Blogposts, 420 Bilder

Mengenmäßig der größte Brocken. Über 150 Blogposts, mehr als 50 Danke-Seiten, alle Hauptseiten und Varianten der Unterseiten – plus rund 420 Bilder. Das musste alles rüber, möglichst im richtigen Zusammenhang und funktional unverändert.

Schritt 1: WordPress-API anzapfen

Mit Claude Code wurde ein Skript gebaut, das alle Posts als JSON aus der WordPress-API zieht – Inhalt, Titel, Slug, Veröffentlichungsdatum, Kategorien, Featured Image. Die gesamte Sammlung landet als eine große JSON-Datei im Repository. Beim Aufruf eines Blogartikels liest das System diese Datei aus.

Klingt simpel. War es am Ende doch nicht. Drei Stolperstellen.

Stolperstein 1: Bilder

In WordPress liegen Bilder in einer eigenen Medienbibliothek und werden referenziert. Auf den ersten Blick könnte man die Medienbibliothek einfach weiternutzen – aber genau das war nicht das Ziel. Komplett weg von WordPress hieß auch: weg vom alten Server als Bilderquelle. Wäre der irgendwann offline gegangen, wäre es zappenduster gewesen. Auch aus SEO-Gründen ein Nogo.

Lösung: Alle Bilder über die API vom Server geholt, lokal in einen Ordner (public/images/blog/...) gesichert und in der JSON-Datei sämtliche Bild-URLs auf relative Pfade umgeschrieben. Statt "von der WordPress-Domain laden" steht da jetzt ein lokaler Pfad.

Stolperstein 2: Umlaute in Bilddateinamen

Klassiker. Manche Webserver sind bei Umlauten zickig, manche Browser kodieren ö als ö, andere als oe, am Ende hat man tote Bildlinks. Knapp 40 Bilder wurden nach dem Go-Live wegen falscher Zeichenkodierung nicht mehr gefunden.

Stolperstein 3: Bilder, die einfach weg waren

In der Google Search Console tauchten nach dem Go-Live einzelne kaputte Bildreferenzen auf – Bilder, die im Post verlinkt waren, aber nirgendwo mehr lagen. Im Migrations-Skript schlicht übersehen, weil sie im WordPress-Backend an einer ungewöhnlichen Stelle gespeichert waren.

Glück gehabt: Das komplette WordPress-Backup vor dem Go-Live war noch da (siehe Folge 26 – bitte unbedingt ein Vollbackup ziehen). Daraus ließen sich fast alle fehlenden Bilder rekonstruieren und ohne Umlautfehler an die richtige Stelle bringen.

Lehre für die Praxis: Bei einer gewachsenen WordPress-Seite fehlt am Ende immer irgendwo etwas. Beim ersten Durchlauf findet man es nicht, beim zweiten vielleicht – oder erst, wenn der erste Nutzer schreibt: "Hey, hier fehlt ein Bild." Kein Weltuntergang, aber Zeit dafür sollte fest eingeplant sein.

Bonus nebenbei: Content-Aufwertung

Was sich bei dieser Gelegenheit angeboten hat: Bei den wichtigsten Beiträgen wurde manuell eine "Das Wichtigste in Kürze"-Box vorangesetzt und ein FAQ-Block mit strukturierten Daten (JSON-LD) ergänzt. Das hilft Lesern, hilft aber vor allem der KI-Suche von Google, die Kernaussage zu erfassen, und sorgt für reichere Suchergebnis-Darstellung. Bei knapp 50 Beiträgen nachträglich eingebaut – ein super wertvoller Bonus, der allein schon den Aufwand der Migration in einem anderen Licht erscheinen lässt.

Integrationen: Klick-Tipp, Cookie-Consent, Tracking, SEO

Eine Webseite ist nie nur Inhalt. Externe Anbindungen sind ein eigenes Kapitel.

Klick-Tipp – und das Bot-Problem

Bei Kernkompetenz Pferd hängt das komplette E-Mail-Marketing an Klick-Tipp – DSGVO-konform, deutsch gehostet. Auf der neuen Seite sind es jetzt noch zehn verschiedene Formulare (Infobrief, Gesundheitsampel, Mini-Trainingstagebuch, Lungentagebuch, Wartelisten, …) – auf der alten waren es deutlich mehr. Der Umzug war gleichzeitig die Gelegenheit, Karteileichen auszumisten.

Statt den klassischen Klick-Tipp-Embed-Code zu nutzen, wurde mit Claude Code ein eigenes Formular gebaut, das die Daten über die Klick-Tipp-API direkt an das System übermittelt. Lief wunderbar – bis auffiel, dass täglich Anmeldungen mit eindeutig automatisch generierten Adressen ankamen. Reine Zahlen-Buchstaben-Codes als Vorname, oft mit echten Gmail- oder GMX-Adressen dahinter, teilweise auch gefakte Domains.

Was waren das? Bots. Solche Bots scannen das Internet ununterbrochen nach Formularen und Lücken. Bei KKP ist nichts Schlimmes passiert – wegen Double-Opt-In hingen die in der Bestätigungsschleife und ließen sich rausfiltern. Aber sauber war das nicht.

Die Ursache war klar: Der Capture-Schutz von Klick-Tipp steckt im Klick-Tipp-Embed-Code – nicht in der API. Wer direkt gegen die API spricht, fliegt unter diesem Schutz hindurch.

Drei Tricks statt Captcha

Gefixt wurde das nicht mit einem Captcha (das nervt echte Nutzer), sondern mit drei Filtern gleichzeitig. Hendrik kannte diese Techniken vorher nicht – im Sparring mit Claude Code erarbeitet und umgesetzt.

Trick 1: Honeypot-Feld. Ein verstecktes Eingabefeld, das im HTML-Code existiert, aber visuell unsichtbar ist. Menschen sehen es nicht und füllen es nicht aus. Bots lesen den Code, sehen das Feld und füllen es brav mit aus. Genau dann weiß das System: kein Mensch. Eintragung blockiert.

Trick 2: Zeitprüfung. Ein Mensch braucht mindestens fünf bis zehn Sekunden, um Name und E-Mail einzutippen (auch mit Autofill). Ein Bot schickt das Formular oft in unter einer Sekunde ab. Alles, was zu schnell geht, fliegt raus.

Trick 3: Rate Limit pro IP-Adresse. Maximal fünf Anmeldungen in zehn Minuten von derselben IP. Bots tragen sich oft mehrfach hintereinander von derselben Adresse ein – das wird so abgefangen.

Alle drei Filter laufen nicht im Browser, sondern auf einem eigenen Server-Endpunkt. Das Formular schickt nicht mehr direkt an Klick-Tipp, sondern an die eigene API – die filtert und reicht nur saubere Anmeldungen weiter. Aus Nutzersicht ist davon nichts zu merken. Die Bots sind seitdem komplett draußen.

Zeitaufwand für die komplette Lösung: rund eine halbe Stunde, nachdem das Problem bemerkt war.

Cookie-Consent und Tracking

DSGVO: Bevor Tracking lädt, braucht es das Einverständnis des Nutzers. Bei KKP gibt es einen eigenen Cookie-Banner, der auf allen Subdomains gleich aussieht und gleich funktioniert. Einmal entschieden, gilt für alles.

Am Banner hängen Meta Pixel (Facebook/Instagram), optional Google Analytics und weitere Tracker. Zustimmung → Skripte laden. Ablehnung → nichts läuft. Auch externe Video-Einbettungen (Vimeo, YouTube) sind davon betroffen, weil dabei Daten – inklusive IP – an Drittanbieter fließen.

Der eigentliche Aufwand steckt nicht im An/Aus-Schalter, sondern in der Consent-Aufzeichnung. Streng genommen müssen Consent-Entscheidungen bis zu einem Jahr nachweisbar sein – wer hat wann zugestimmt oder abgelehnt? Dafür braucht es eine Datenbank. Bei KKP läuft das jetzt über Supabase.

Microsoft Clarity

Im Nachgang ergänzt: Microsoft Clarity – kostenlos, liefert Heatmaps und Session Replays. Sichtbar wird, wo Nutzer hinschauen, wo sie klicken, wo sie scrollen, wo sie wieder abspringen. Sehr aufschlussreich für die Frage, ob der Lesefluss einer Seite wirklich so funktioniert wie geplant. Hängt selbstverständlich am Cookie-Consent.

SEO-Setup

Sitemap, robots.txt, Canonical-URLs, Open Graph für Social Media, JSON-LD für FAQs – klingt nach viel Fachchinesisch, ist im Kern ein kompaktes Set an Dateien und Konfigurationen. Die Details aber haben es in sich. Wie genau, gleich beim Go-Live.

Der Go-Live-Tag

Geplant für Ende April, gut vorbereitet, mit viel Adrenalin am Tag selbst.

Vorbereitung

  1. Komplettes WordPress-Backup – Dateien, Datenbank, Plugins, das ganze Verzeichnis. Lokal gesichert. Damit lässt sich der Stand jederzeit wiederherstellen, falls etwas grandios schief geht.
  2. Subdomain für die alte WordPress-Seite eingerichtet, sodass sie nach dem Go-Live unsichtbar weiterläuft. Sehr nützlich in den ersten Wochen, um nachzuschauen: "Wie sah das früher genau aus? Welcher Text stand da? Welcher Button?" Die alte Seite läuft tatsächlich heute noch im Hintergrund.
  3. Letzten kritischen Bug gefixt: In der Klick-Tipp-Anbindung gab es einen Fehler, der Doppel-Eintragungen erzeugt und Nutzer auf eine falsche Seite geleitet hätte. Am Vortag noch entdeckt und behoben.

Der DNS-Switch

Technisch ist der Go-Live ein einziger Vorgang: dem DNS-Eintrag sagen, dass die Domain jetzt auf Vercel zeigt statt auf den alten WordPress-Server. Konkret drei Änderungen: ein A-Record auf die neue Root-IP, ein neuer CNAME-Eintrag, ein kleiner Verifikations-Eintrag. Drei Klicks – und dazwischen eine Phase von einer Minute bis zu einer Stunde, in der unklar ist, wo Besucher gerade landen.

Aus genau diesem Grund: spät abends machen, wenn wenig Verkehr läuft. In dieser Übergangszeit landen manche auf der neuen, andere noch auf der alten Seite.

Bei KKP ging es überraschend schnell – innerhalb von rund 20 Minuten zeigte alles auf Vercel, das SSL-Zertifikat war automatisch ausgestellt, die Seite lief. Erstmal aufatmen.

Was nach dem Go-Live passierte

In den ersten zwei Wochen wurden Google Search Console und Analytics streng beobachtet. Und tatsächlich: Klicks und Impressionen gingen erst leicht, dann deutlich nach unten. In der Search Console standen plötzlich viele "nicht indexierte" Seiten – ein Moment, in dem es kurz wummerig wurde.

Diagnose mit Claude Code und Ahrefs

Statt in Panik zu verfallen: Reports gezogen, Analyse-Tools wie Ahrefs und die Search Console parallel laufen lassen, alles in Claude Code analysiert. Drei konkrete Ursachen kamen heraus.

1. Indexierungsproblem. Google hat von 154 Blogposts nur einen Bruchteil indexiert gelesen. Ein klassischer Migrations-Fehler beim Sprung aus einem alten in ein modernes Framework. Wenn man es weiß, passiert es nie wieder. Schnell behoben.

2. Doppelte Canonical-URLs. Auf manchen Seiten stand kernkompetenz-pferd.de als kanonische URL, auf anderen www.kernkompetenz-pferd.de. Vercel hat dazwischen umgeleitet – aber Google mag widersprüchliche Canonical-Signale gar nicht. Ergebnis: verwirrtes Ranking.

3. Doppelte Markennamen. In Titel und Meta-Beschreibung tauchte oft zweifach "Kernkompetenz Pferd" auf. In der Suchergebnis-Anzeige sah das gedoppelt aus – drückt die Klickrate.

Mit Analyseberichten plus Claude Code: an einem Vormittag durch. Vorher Healthscore 23 (sehr schlecht), nachher 96 (sehr gut).

Der Punkt dabei: In der WordPress-Welt wäre das wahrscheinlich gar nicht aufgefallen – oder erst spät, mit Hilfe eines externen SEO-Experten, ohne zu wissen, ob die vorgeschlagene Lösung überhaupt greift. Im neuen Setup: nah dran, schnell diagnostiziert, selbst behoben.

404-Fehler und alte Subdomains

Über zehn Jahre wachsen Links – intern und extern. Nach so einer Migration sind viele Pfade nicht mehr vorhanden. Die Liste der 404-Fehler wurde aus der Search Console exportiert und über Weiterleitungsregeln auf die passenden neuen Seiten umgeleitet. Dazu noch zwei alte Subdomains, die sinnvoll in die Hauptdomain eingearbeitet werden mussten – ebenfalls mit Claude Code analysiert und umgebaut.

Die echten Gewinne nach der Migration

Bis hier hin klang alles nach harter Arbeit. Es war auch harte Arbeit. Aber jetzt zu dem, was sich seitdem auftut – und was vorher gar nicht möglich war.

1. Notion-Blog-Pipeline

Eine Tabelle in Notion: Transkript einer Podcastfolge rein, Veröffentlichungsdatum eintragen, zwei, drei Klicks – und es liegt ein fertiger, KI-geschriebener und SEO-/GEO-optimierter Blog-Artikel auf der Webseite. Drei Minuten statt eines halben Tages. Vorher technisch undenkbar.

Und die generelle Ladegeschwindigkeit: Wo WordPress gefühlt 10 Sekunden brauchte, bis die Seite da war, ist heute jeder Klick: bumm, da. Eine andere Liga.

2. Pferdemenschen-Typentest direkt auf der Seite

Vorher lief der Typentest über ein externes Formular-Tool: Button klicken → fremde Seite → Test machen → E-Mail bekommen → in der E-Mail klicken → Ergebnis. Drei bis vier Conversion-Killer-Schritte hintereinander.

Heute komplett bei KKP, direkt auf der Seite. Selbe Fragen, Ergebnis sofort im Modal, kein E-Mail-Hopping. Wer das vollständige Ergebnis will, trägt sich mit Vorname und E-Mail ein – aber alles aus einem Guss. Organisch, harmonisch, ohne Reibung.

3. KI-Bilderbuch zur Wurm-Geschichte

Veronika erzählt vieles in Geschichten – die Britta-und-Sina-Geschichten kennen einige. Aus einer dieser Geschichten wurde mit KI eine Bilderbuch-Comic-Illustrationsreihe erstellt und an passender Stelle in den Wurmkurs-Funnel auf der Webseite eingebaut. Hat super viel Spaß gemacht und ist ein echtes Funnel-Asset.

4. Eigenes A/B-Test-Framework

Bis hierhin war Hendrik für A/B-Tests immer auf externe Tools angewiesen – schnell 500 € pro Monat. Jetzt ist das Test-Framework direkt in Next.js integriert und die Auswertung läuft über Vercel Analytics. Mit einer kurzen Sprach- oder Texteingabe lässt Claude Code Varianten von Buttons, Texten oder ganzen Pop-Ups gegeneinander testen. Kosten nach der Einmalentwicklung: 0 €.

Und Pop-Ups – früher das Hell-Thema in WordPress – sind heute kein Problem mehr. In Kombination mit dem A/B-Test-Framework lässt sich genau messen, welcher Trigger funktioniert.

Ehrliches Fazit: Für wen ist dieser Weg?

So unaufgeregt wie möglich – weil um KI gerade so viel Hype gemacht wird und dieser Podcast bewusst keiner sein soll.

Das ist was für dich, wenn …

  • … du eine technische Veranlagung hast und Lust, dich in komplexere Themen einzuarbeiten. Kein Entwickler-Background nötig, aber die Bereitschaft, ein paar Stunden mit der KI im Sparring zu verbringen und Zusammenhänge zu verstehen.
  • … dein Geschäft an deiner Webseite hängt: viele Ideen pro Woche, ständig neue Funnels, schnelle Iteration. Dann lohnt sich die Investition, weil danach Ideen wirklich am Tag selbst live gehen können.
  • … dir Unabhängigkeit wichtig ist: Code im eigenen GitHub, Daten in der eigenen Datenbank, KI-Tool austauschbar. Heute Claude Code, morgen vielleicht etwas anderes – die Webseite bleibt davon unberührt.

Das ist nichts für dich, wenn …

  • … du keine Lust auf das hast, was hier beschrieben wurde. Ganz einfach.
  • … du keinerlei technische Veranlagung und keine Lust auf Weiterentwicklung hast. Dann lieber jemanden engagieren, der eine schlanke, moderne Seite aufsetzt.
  • Eine ganz kleine Seite ist tatsächlich kein Gegenargument – im Gegenteil, dort entfallen viele der hier beschriebenen Stolperfallen. Aber auch da gilt: Lust auf den Weg muss da sein.

Abschließend

Die Migration ist mit Abstand eine der besten technischen Entscheidungen für Kernkompetenz Pferd in den letzten Jahren. Nicht weil sie billiger war (war sie nicht). Nicht weil sie schneller fertig war als geplant. Sondern weil die Seite jetzt der eigenen Hand gehört – Ideen können umgesetzt werden, kein Plugin-Update-Roulette mehr, keine Wartetermine bei Dienstleistern für jede kurzfristige Aktion.

Und das ist noch nicht der Status quo, sondern der Startpunkt. In einem Jahr gibt es vermutlich noch einmal viel zu erzählen – aus Setup, Routinen und allem, was darauf aufgebaut wird.

Ein Rat zum Schluss

Egal ob kleine Seite, große Seite, noch keine Seite oder gerade keine Seite: Das Thema Webseite wird gerade neu gedacht. Wer heute bei null anfängt, sollte ernsthaft direkt mit einer kodierten Seite starten – egal in welcher Größe.

Wichtig dabei wie immer: klein anfangen, Kopf einschalten, mit Realismus und Wissen ans Werk gehen. Im Sparring mit der KI – nicht als Zauberstab, sondern als Werkzeug.

Themenwünsche, eigene Erfahrungen mit Migration oder Vorschläge für spannende Pferdemenschen rund um KI? Gerne per Mail an hendrik@ki-tuepfelchen.de – Tüpfelchen mit ue geschrieben.