Wix & Jimdo zu Next.js migrieren — Strategie & Umsetzung

Wix und Jimdo sind der schnelle Einstieg für viele Dienstleister — und später oft die technische Decke. Anders als bei WordPress-Migration gibt es hier keine REST-API und keinen belastbaren Full-Site-Export: Layout, Medien und Formulare sitzen in einer proprietären Runtime. Die Migration zu Next.js ist deshalb kein Theme-Wechsel, sondern ein kontrollierter Ausstieg aus dem Baukasten — mit Inventar, Extraktion, Rebuild und Cutover. Dieser Beitrag analysiert die strategische Rationale, die typischen Lock-in-Fallen und die konkrete Umsetzungsfolge — und bindet sie an den Modern-Stack-Migrationspfad.

Für KMU und Praxen war der Baukasten oft die richtige erste Entscheidung: Domain kaufen, Seiten klicken, Formular aktivieren, fertig. Das Problem entsteht später — wenn du Conversion steuern, Schema setzen, Redirects besitzen oder KI-Crawler sauberes HTML liefern willst. Dann merkst du: du mietest eine geschlossene Plattform, du besitzt keine Webseite im technischen Sinn. Genau an diesem Punkt setzt die Migration an — regional relevant etwa in Bad Schönborn, Bruchsal und dem Kraichgau, aber der Mechanismus ist bundesweit derselbe.

Warum proprietäre Runtime und Editor-Skripte die Migration erzwingen

Antwort zuerst: Solange die Auslieferung am Baukasten hängt, kontrollierst du weder Markup noch Skript-Budget noch Hosting — jede Unterseite trägt Editor-Runtime mit.

Wix und Jimdo rendern Seiten in ihrer eigenen Infrastruktur. Du bearbeitest im Editor; öffentlich läuft eine geschlossene Pipeline aus Templates, Widgets und Client-Skripten. Caching und CDN des Anbieters kaschieren Ladezeiten, lösen aber die Architektur nicht: du kannst kein deterministisches HTML festnageln, keine eigenen Edge-Regeln zuverlässig setzen und keine Editor-Skripte entfernen, ohne den Vertrag zu verlassen. Selbst „Premium“-Pläne ändern das Grundprinzip nicht — sie erweitern Features innerhalb derselben Blackbox.

Praktisch heißt das: Jede Leistungsseite lädt nicht nur deine Inhalte, sondern auch Editor- und Tracking-Reste des Anbieters. Für Menschen wirkt das oft „schnell genug“. Für Core Web Vitals, Crawl-Budgets und Retrieval-Pipelines ist es Rauschen. Du kannst einzelne Widgets abschalten — die Runtime selbst bleibt. Migration ist der einzige Weg, das Skript-Budget und das HTML-Determinismus-Problem an der Wurzel zu lösen.

Next.js adressiert den Engpass mit hybriden Rendering-Strategien (Next.js Caching/Rendering):

• Static Site Generation (SSG): Marketingseiten werden im Build als HTML vorkompiliert und über ein CDN ausgeliefert — ohne Editor-Bundle.
• Incremental Static Regeneration / On-Demand Revalidation: einzelne Seiten aktualisieren sich ohne Full-Rebuild.
• Server-Side Rendering (SSR): dynamische Pfade entstehen nahe am Request — ohne Vendor-Widget-Zoo.

Core Web Vitals (LCP, INP, CLS) sind damit kein Kosmetik-Audit, sondern Ranking- und Extraktionssignal. KI-Crawler mit Timeout priorisieren langsame Origins herunter; Conversion reagiert empfindlich auf Latenz. Die Migration ist Geschäftsentscheidung: Besitz am Code statt Miete am Editor. Praxisnachweis: Core Web Vitals nach Modernisierung.

Warum unvollständiger Export und CDN-Medien Lock-in erzeugen

Antwort zuerst: Es gibt keinen sauberen Full-HTML-Export — Medien hängen oft nur am Anbieter-CDN; Texte stecken in Widgets, Bildern oder Mobile-Only-Sektionen.

Das ist der zentrale Unterschied zur WordPress-Welt. Bei WordPress kannst du REST/GraphQL oder zumindest WXR ansetzen. Bei Wix/Jimdo:

1. Kein belastbarer Site-Dump als unabhängige Webseite-Basis — Exporte decken oft nur Teilmengen ab oder bleiben an die Runtime gebunden.
2. CDN-Medien-Lock-in: Bilder und Videos liegen auf Hosts des Anbieters; nach Vertragsende oder ohne Re-Host brechen URLs.
3. Unvollständige Metadaten: Alt-Texte, Canonicals, saubere H1/H2 und strukturierte Daten fehlen oder sind Editor-Zufall.
4. Versteckte Substanz: Mobile-Only-Blöcke, Texte in Bildern, eingebettete Maps/Kalender/Chat — der Crawl muss das mit Handarbeit abgleichen.

Ein häufiger Fehler ist, „Backup“ mit „Migration“ zu verwechseln. Ein PDF- oder Teil-Export der Texte rettet dich nicht, wenn Hero-Bilder, Galerien und Formularzustellung weiter am Vendor hängen. Ohne Re-Host der Medien und ohne Rebuild der Interaktionen bleibt die neue Webseite eine Attrappe mit kaputten Assets. Deshalb ist Content-Migration aus Baukästen immer Inventar + Extraktion + Rebuild, nie „Import-Knopf und fertig“. Medien wandern in Object Storage/CDN unter deiner Kontrolle; URL-Rewrites in Texten gehören in dieselbe Pipeline — nicht in den Go-Live-Freitag.

Wie Formulare und generische URLs den Cutover gefährden

Antwort zuerst: Formulare posten aufs Vendor-Backend; viele Pfade heißen /about-1 oder /kopie-von-… — ohne 301-Matrix und neuen Anfragepfad verlierst du Leads und Rankings.

Baukasten-Formulare speichern und mailen im Anbieter-System. Nach dem DNS-Cutover ist dieses Backend weg — es sei denn, du baust vorher einen geprüften Anfragepfad (Spam-Schutz, Notify, optional CRM). Ohne Staging-Test der Anfragezustellung ist der Cutover ein Blindflug: die Webseite läuft, aber keine einzige Lead-Mail kommt an. Siehe Datenschutz & Formulare und Conversion.

URL-Hygiene ist der zweite Stolperstein. Editoren erzeugen generische oder fragmentierte Pfade (/about-1, parallele Kinderpfade, Shop-Reste, /kopie-von-…). Search Console zeigt oft Impressionen auf genau diesen URLs. Migration heißt: sinnvolle Zielrouten definieren und jede Alt-URL mit Impressionen als 301 mappen — sonst Soft-404 und Rankingverlust. Disziplin wie bei Rankingverlust vermeiden und Redirects. Buchmarks, Visitenkarten und alte Google-Einträge folgen der 301-Matrix — nicht dem Wunschdenken „die neue Startseite reicht“.

Vergleich: Baukasten vs. offener Stack

Antwort zuerst: Der Baukasten optimiert für „schnell zusammenklicken“; der offene Stack für Besitz, Tempo, Schema und Conversion ohne Vendor-Gate.

Das ist dieselbe Entkopplungslogik wie bei Pagebuilder-Ablösung — nur härter, weil der Baukasten Hosting, Editor und Formulare in einem Vertrag bündelt.

Was der Census zur Wix- und Jimdo-Migration sagt

Antwort zuerst: Migration allein macht dich nicht „AI-ready“ — sie entfernt den Baukasten-Bottleneck; der Maschinen-Layer kommt danach.

In der AI-Readiness-Studie (6.675 Audits) laufen 69,4 % der Sites auf Legacy-CMS bzw. Baukästen. Benchmarks: Agent-Ready Ø 25/100, llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %, robots 72,5 %, Markdown-Negotiation 0,3 %.

Wix-/Jimdo-Vorlagen setzen Organization- und LocalBusiness-Schema selten durchgängig ohne Nacharbeit. Baukästen bieten für llms.txt und Markdown-Negotiation meist keine first-class Oberfläche — deshalb liegen viele Baukasten-Auftritte im unteren Quartil bei Extrahierbarkeit. Nach Migration setzt Modern Stack Basis-Technical SEO: JSON-LD, saubere Titel, Sitemap/robots, interne Verlinkung. Knowledge Graph, llms.txt und Conversion-Module sind die nächste Schicht — nicht Ersatz für den Stack-Wechsel.

Wie läuft die Migration phasenweise ab?

Antwort zuerst: Erfolgreiche Baukasten-Migration ist ein sequenzielles Programm: Inventar → Scrape/manuelle Extraktion → Rebuild → Redirects → Cutover — nicht „neues Template und DNS umstellen“.

Phase 1 — Inventar: URLs, Medien, Formulare, SEO-Baseline

Automatisierter Crawl erfasst alle öffentlichen Pfade, inkl. generischer und verwaister Editor-URLs. Anreicherung mit Search Console / Analytics: Top-Traffic vs. Null-Traffic der letzten 12 Monate (Konsolidierungskandidaten). Parallel: Medienliste (CDN-Hosts des Anbieters), Formular-Inventar, eingebettete Widgets, Baseline von Meta-Titles, Descriptions, Canonicals, H1 und vorhandenem Schema. Ergebnis: 1:1-Mapping-Matrix Alter Pfad → neue Next.js-Route — Basis für spätere 301er.

Phase 2 — Scrape und manuelle Extraktion

Weil kein sauberer Full-HTML-Export existiert, kombinieren wir Crawl/Scrape mit Handarbeit:

1. Sichtbare Texte und Hierarchie aus dem gerenderten DOM ziehen.
2. Mobile-Only- und Desktop-Only-Sektionen abgleichen.
3. Texte in Bildern markieren (OCR oder Neuschreiben — nie „Bild bleibt Textersatz“).
4. Medien herunterladen, deduplizieren, in eigenes Storage hochladen, URLs umschreiben.
5. Widgets (Maps, Kalender, Chat, Buchung) als Replace-or-Drop entscheiden.

Das ist aufwendiger als WordPress-Block-Mapping — und der Grund, warum Baukasten-Projekte früh ein klares Seitenbudget brauchen. Designmuster werden nachgebaut oder im Redesign gezielt verbessert; Markup wird nicht 1:1 aus dem Editor übernommen. Wo der Baukasten doppelte Leistungsseiten oder „Kopien von …“ angelegt hat, konsolidieren wir Inhalte in eine klare Route statt Rauschen 1:1 fortzuschreiben.

Phase 3 — Rebuild auf Next.js: Routing, Rendering, Schema

Informationsarchitektur wird in App-Router-Routen übersetzt. Statische Marketingseiten → SSG; häufig aktualisierte Listen → Revalidation; personalisierte/geschützte Bereiche → SSR. Strukturierte Daten (Organization, LocalBusiness, FAQ, Article) werden im Code gesetzt — nicht über Baukasten-Zufall. Parallel: Formulare ohne Vendor-Backend, Cookie/Consent, Analytics ohne Render-Blocker. Siehe SSR/SSG-Stack und Modernisierungsprojekt.

Im Rebuild entscheiden wir bewusst, was vom alten Look bleibt und was Conversion kostet: zu kleine CTAs, versteckte Kontaktwege, überladene Hero-Slider. Reine Technikmigration behält Substanz und sinnvolle Struktur; Redesign greift, wenn der Baukasten-Look selbst die Anfrage bremst. Beides ist legitim — vermischen ohne Briefing nicht.

Phase 4 — Redirect-Matrix, Paritätstests und Staging

Jede Zeile der Mapping-Matrix wird zum 301. Soft-404 und Kettenredirects sind FAIL. Staging-Checkliste: visuelle Parität der Top-20-URLs, Formular-E2E (Desktop + Mobilfunk), Mobile-LCP-Stichprobe, robots/sitemap, AI-Bot-Allowlist (kein unbeabsichtigtes Cloudflare-Blocken von GPTBot/PerplexityBot). Ranking-Risiken und Rollback: Rankingverlust vermeiden.

Phase 5 — DNS-Cutover bei erhaltener E-Mail

Cutover mit Maintenance-Fenster: A/AAAA bzw. Proxy auf neuen Stack → Redirect-Smoke-Tests → 48-Stunden-Monitoring (Verfügbarkeit, Search Console, Core Web Vitals). MX und Mail-DNS bleiben, wenn Postfächer beim bisherigen Anbieter bleiben sollen — Domain-Cutover ≠ Mail-Umzug. Der Baukastenvertrag endet für die Webseite-Auslieferung; Hosting folgt Hosting nach Migration. Kein „Freitag 17 Uhr ohne Plan“.

Live-Referenz — Wing Chun Akademie Bretten nach Wix

Antwort zuerst: alexandreliard.de zeigt den kompletten Ausstieg: Wix raus, offener Stack rein, messbare Lab-Scores 93 mobil / 99 Desktop.

Die Fallstudie Wing Chun Akademie Bretten (Sihing Alexandre Liard) dokumentiert Ausgangslage auf Wix — fragmentierte URLs, Formular→Mail, Pflege nur im Editor — und den Neuaufbau mit Next.js, eigener Domain-Führung, CRM und Maschinenoberflächen. PageSpeed Insights Lab (28.10.2026): Leistung mobil 93, Desktop 99. Das ist kein erfundenes Vorher-Score-Theater, sondern der Live-Nachweis nach Cutover.

Was du daraus für deine Migration mitnehmen kannst: generische Pfade brauchen eine 301-Matrix; Formular→Mail reicht nicht, wenn du Leads nachverfolgen willst; Domain und Code gehören dir, nicht dem Baukasten-Vertrag. Weitere Praxis mit sauberem Cutover: Mallorca Expats.

Wann lohnt sich eine Wix-/Jimdo-Migration — und wann nicht?

Antwort zuerst: Sinnvoll, wenn Inhalte und Marke tragen, der Baukasten aber zum Risiko wird — nicht als Ersatz für eine komplett neue Story.

Sinnvoll bei: Editor-Limits, schwachen Core Web Vitals trotz CDN, Formularen nur im Posteingang, generischen URLs, fehlendem Schema/llms.txt, Wunsch nach Code- und Domain-Besitz, monatlicher Plattformgebühr ohne Kontrolle.

Allein zu wenig, wenn: Informationsarchitektur und Conversion komplett veraltet sind — dann Migration + Redesign + Conversion. Wenn Look und UX zum Baukasten-Look gehören und Besucher den Anfrageweg nicht finden, reicht Technikwechsel allein nicht.

Wie verbessert die Migration GEO und AI-Sichtbarkeit?

Antwort zuerst: Sauberes HTML ohne Editor-Skripte senkt RAG-Rauschen; zitierfähige Inhalte und Entities kommen danach.

Generative Engines extrahieren Passagen — nicht ganze Widget-Seiten. Baukasten-DOM und Editor-Runtime erhöhen Halluzinationsrisiko im Retrieval. Princeton GEO (Aggarwal et al., arXiv:2311.09735) zeigt, dass Zitate, Statistiken und Quellen Sichtbarkeit in generativen Engines heben können — aber nur auf einer technisch extrahierbaren Basis.

Reihenfolge bei Modern Stack: Migration → optional Redesign → Knowledge Graph / llms.txt → Conversion. Stack zuerst, Content-Taktiken danach — sonst optimierst du Rauschen. Vertiefung: GEO & AI-Sichtbarkeit und Webarchitektur im KI-Zeitalter.

Was kostet die Migration — und was ist im Basispaket?

Antwort zuerst: Basis ab 500 € für bis zu 10 Seiten — Inventar, Extraktion, Rebuild, Redirect-Map, Staging, Cutover-Begleitung; Redesign ab 1.000 €.

Im Basisumfang typisch: URL-/Medien-Inventar, Scrape und manuelle Extraktion der Seiteninhalte, Rebuild auf Next.js, 301-Matrix für den Scope, Staging, DNS-Cutover bei erhaltener E-Mail. Außerhalb: umfangreiche Widget-Sonderlogik, Shop-Reste, Design-System von Grund auf, laufende Redaktions-Schulungen für neues CMS.

Zusatzmodule: Knowledge Graph ab 500 €, Conversion ab 500 €. Preise im Kontext: Preise & Pakete. Wartung nach Cutover: Wartung & Updates.

Checkliste vor dem Kick-off

Domain-Zugang und DNS-Rechte (ohne Mail zu brechen), Baukasten-Login, Export-/Medienrechte soweit vorhanden, Liste aller öffentlichen URLs inkl. generischer Pfade, Medien-CDN-Hosts, kritische Formulare und Widget-Abhängigkeiten, Top-20-URLs aus Search Console, Klarheit Migration vs. Redesign, Seitenzahl im Scope. Zusätzlich: welche E-Mail-Adresse soll nach dem Cutover Anfragen empfangen, und bleibt MX unverändert? Je vollständiger das Inventar, desto ruhiger der Go-Live.

Kurz: Wix- und Jimdo-Migration ist Infrastrukturentscheidung — Inhalte behalten, proprietäre Schicht tauschen, Formulare und DNS sauber trennen. Anfrage stellen · KI-Sichtbarkeits-Check