Wix/Squarespace‑Migration: Wann wechseln und wie Sie gewinnen

Was eine Wix/Squarespace‑Migration wirklich bedeutet

Eine „Migration“ von Wix oder Squarespace ist kein einziger Button‑Klick. Es ist ein koordinierter Umzug mehrerer Teile – manche übertragen sich sauber, andere müssen neu aufgebaut werden.

Was eine „Migration“ normalerweise umfasst

Inhalte: Seiten, Blogbeiträge, Produktlisten und Basistexte lassen sich oft exportieren oder kopieren, aber Formatierungen und Bausteine stimmen selten 1:1 überein.

Design: In der Regel bauen Sie das Look & Feel (Layout, Typografie, Komponenten) neu auf, anstatt das Theme „wörtlich zu verschieben“. Denken Sie daran, das Haus nach demselben Grundriss neu zu bauen.

Domain und E‑Mail: Ihre Domain kann beim aktuellen Registrar bleiben oder Sie übertragen sie. In jedem Fall gehören DNS‑Änderungen zur Launch‑Phase. E‑Mail (Google Workspace/Microsoft 365) bleibt meist unverändert, aber die Einträge müssen erhalten werden.

SEO: URLs, Titel, Meta‑Descriptions, Überschriften, interne Links, Bild‑Alt‑Text und Weiterleitungen brauchen einen Plan. Ziel ist es, die Sichtbarkeit in der Suche stabil zu halten, während die Seite unter der Haube verändert wird.

Funktionen und Integrationen: Formulare, Buchungen, Mitgliederbereiche, E‑Commerce, Analytics, CRM und benutzerdefinierte Skripte müssen auf der neuen Plattform repliziert (oder verbessert) werden.

Ein schnelles Entscheidungs‑Framework

Stellen Sie zwei Fragen:

1. Was schränkt Sie gerade ein? Beispiele: eingeschränkte SEO‑Kontrolle, langsame Bearbeitung, E‑Commerce‑Grenzen, Designlimits oder schwer wartbare Integrationen.

2. Was würde ein Wechsel freischalten? Beispiele: bessere Performance, fortgeschrittene Marketing‑Tools, klareres Content‑Management, flexibleres Design oder niedrigere laufende Kosten.

Wenn der aktuelle Schmerz gering ist und der Nutzen unklar bleibt, ist eine Migration wahrscheinlich verfrüht. Wenn der Schmerz dauerhaft ist und die neue Plattform ihn direkt löst, lohnt sich der Aufwand meist.

Häufige Zielplattformen (und warum)

Die meisten Wix/Squarespace‑Migrationen führen zu WordPress (Content‑Flexibilität), Webflow (Designkontrolle mit verwaltetem Gefühl), Shopify (E‑Commerce‑Fokus) oder zu einem Custom‑Build (besondere Anforderungen).

Erwartung richtig setzen

Ein gewisser Neuaufbau ist normal. Nicht jedes Widget, Template‑Element oder jede App lässt sich exakt „mitnehmen“. Eine erfolgreiche Migration fokussiert auf Ergebnisse: gleiche (oder bessere) Inhalte, sauberere Struktur, erhaltene SEO‑Signale und Features, die am ersten Tag zuverlässig funktionieren.

Anzeichen, dass ein Wechsel lohnt

Manchmal geht es bei einer Wix‑ oder Squarespace‑Migration nicht um bloße „Neugier“, sondern darum, Reibung zu entfernen, die das Wachstum bremst. Wenn Sie die folgenden Muster wiedererkennen, ist ein Plattformwechsel oft schneller als ständiges Basteln.

Sie sind aus den Templates herausgewachsen und brauchen echte Designkontrolle

Wenn jede Änderung in Workarounds endet (Kämpfen mit Bereichsregeln, Abstandsproblemen oder Mobil‑Layouts), zahlen Sie eine „Template‑Tax“. Ein Umzug von Wix oder Squarespace macht Sinn, wenn Sie wiederverwendbare Design‑Komponenten, sauberere Seitenstruktur und die Fähigkeit brauchen, neue Seiten zu skalieren, ohne jede einzeln neu zu designen.

Sie stoßen immer wieder an Funktionsgrenzen

Ein Wechsel lohnt, wenn zentrale Funktionen entweder fehlen oder schwer wartbar sind – denken Sie an Mitgliedschaften, erweiterte Formulare, Custom Fields, Buchungs‑Logik oder Integrationen mit Ihrem CRM/Marketing‑Stack. Wenn Sie auf mehrere Apps angewiesen sind, die nicht gut miteinander sprechen, tendiert die Entscheidung oft zu Migration plus einer strafferen, integrierten Lösung.

Performance‑Ziele sind schwer erreichbar

Wenn Sie schnellere Ladezeiten oder bessere Core Web Vitals anstreben und bereits Bilder komprimiert, Seiten aufgeräumt und unnötige Add‑ons entfernt haben, aber die Ergebnisse stagnieren, kann die Plattform der Flaschenhals sein. Bessere Performance bedeutet oft mehr Conversions, nicht nur bessere Scores.

SEO‑Anforderungen werden komplexer

Ein Plattformwechsel ist gerechtfertigt, wenn Sie stärkere Kontrolle über URLs, strukturierte Daten, Weiterleitungen und Content‑Architektur benötigen – besonders wenn Sie viele Landingpages oder eine große Content‑Bibliothek planen. Genau hier schützen eine SEO‑Migrationsplanung und eine Website‑Migrationscheckliste die Rankings.

Ihr Team braucht einen besseren Workflow

Wenn Publizieren von einer Person erledigt werden muss, oder Sie Rollen, Freigaben und Staging vermissen, blockiert das Wachstum. Eine Plattform mit klareren Berechtigungen und einem redaktionellen Prozess reduziert Fehler und beschleunigt Releases.

Wann Sie besser bleiben sollten (vorerst)

Eine Migration ist oft richtig – aber nicht immer der nächste Schritt. Wenn Ihre aktuelle Wix‑ oder Squarespace‑Seite ihren Zweck erfüllt, kann ein Plattformwechsel Kosten und Risiko ohne klaren Mehrwert bringen.

Bleiben Sie, wenn die Seite Ihr Geschäft bereits unterstützt

Ist die Website klein, lädt schnell und generiert zuverlässig Leads oder Verkäufe, kann eine Migration eine Ablenkung sein. Viele Firmen brauchen keinen flexibleren Stack; sie brauchen klarere Botschaften, bessere Seiten und konsistente Updates.

Bleiben Sie, wenn Sie selten Änderungen oder neue Funktionen brauchen

Wenn Sie Inhalte selten aktualisieren und keine größeren Features (Mitgliedschaften, erweiterte SEO‑Tools, custom Checkout‑Flows, komplexe Integrationen) planen, ist Ihre Plattform möglicherweise noch ein Jahr „gut genug“.

Bleiben Sie, wenn Zeit und Budget knapp sind

Eine saubere Migration erfordert Planung, Neubau von Templates, Migration von Inhalten und Verifikation der SEO. Wenn Sie in einer geschäftigen Phase stecken, kann es klüger sein, zuerst Verbesserungen mit schnellerem ROI vorzuziehen (Homepage‑Überarbeitung, Service‑Seiten‑Cleanup, Speed‑Tweaks) und den Wechsel später anzugehen.

Erwägen Sie Fixes vor einem kompletten Wechsel

Oft ist die Ursache eher Ausführung als Plattform. Viele Probleme lassen sich lösen durch:

• Ein Redesign oder Template‑Refresh
• Content‑Cleanup (veraltete Seiten entfernen, Navigation straffen)
• Bessere Texte und klarere Call‑to‑Actions

Achten Sie auf App‑Lock‑in

Wenn Sie stark von plattformspezifischen Apps/Erweiterungen abhängen – Buchungen, Formulare, Mitgliederbereiche, Payments – prüfen Sie, ob es äquivalente Tools auf der Zielplattform gibt, bevor Sie wechseln. Andernfalls müssen Workflows neu aufgebaut werden.

Wenn Sie sich entscheiden zu pausieren, dokumentieren Sie trotzdem, was nicht funktioniert. Diese Liste wird später zu Ihren Anforderungen und erleichtert die Durchführung Ihrer eventualen /blog/website-migration-checklist.

Die richtige Zielplattform wählen

Ihre beste Destination hängt weniger von „Wix vs Squarespace“ ab und mehr davon, was Ihre Seite als Nächstes tun muss: publizieren, verkaufen, in der Suche ranken oder individuelle Features unterstützen.

Kurze Entscheidungskriterien (was wirklich zählt)

Starten Sie mit diesen praxisnahen Checks:

• Bearbeitungsfreundlichkeit: Kann Ihr Team Seiten aktualisieren, ohne das Layout zu zerstören?
• Entwicklerflexibilität: Brauchen Sie Custom Code, Integrationen oder ein eigenes Designsystem?
• Gesamtkosten: Monatliche Gebühren plus Themes, Apps/Plugins, bezahlte Formulare, E‑Commerce‑Addons und laufende Hilfe.
• Apps/Plugins: Sind die Tools, auf die Sie angewiesen sind (Buchung, Mitglieder, E‑Mail‑Capture, Analytics), verfügbar und gut gepflegt?
• SEO‑Basics: Können Sie URL‑Struktur kontrollieren, 301‑Weiterleitungen erstellen und Sitemaps/robots.txt verwalten (oder zumindest Sitemap‑/Index‑Einstellungen)?

Top‑Optionen nach Anwendungsfall

Marketing‑Site (Lead‑Gen, Service‑Business): Webflow oder WordPress

Blog / Content‑Publishing: WordPress oder Ghost

Onlineshop: Shopify (oder WooCommerce, wenn WordPress bevorzugt wird)

Portfolio / leichte Broschüre: Webflow, Framer oder WordPress mit einem sauberen Theme

„Wähle dies, wenn…“ Mini‑Guide

• Wähle WordPress, wenn Sie maximale Flexibilität, viele Plugins, starkes Blogging möchten und Hosting managen (oder Hilfe dafür haben) können.
• Wähle Webflow, wenn Designkontrolle und sauberes visuelles Editing wichtig sind und Sie weniger Plugin‑Wartung wollen.
• Wähle Shopify, wenn E‑Commerce zentral ist und Sie einen zuverlässigen Checkout, Versand/Steuer‑Tools und ein großes App‑Ökosystem brauchen.
• Wähle Ghost, wenn Sie sich aufs Publizieren/Newsletter fokussieren und einen schnellen, minimalistischen Editor wollen.

Wenn SEO Priorität hat, setzen Sie Redirect‑Support und URL‑Kontrolle ganz oben auf die Shortlist – diese beiden Details entscheiden oft, ob ein Wechsel Rankings schützt oder schadet.

Ein Wort zu modernen „Custom Builds“ (ohne lange Entwicklungszyklen)

Wenn Sie ein Custom Build wählen, weil Sie Wix/Squarespace überholt haben, aber keine monatelange traditionelle Entwicklung wollen, kann ein sogenannter Vibe‑Coding‑Ansatz ein Mittelding sein. Beispielsweise erlaubt Koder.ai, Teams Web‑Apps per Chat‑Interface zu erstellen (React Frontend, Go + PostgreSQL Backend), anschließend Source‑Code zu exportieren, zu deployen und mit Snapshots/Rollbacks zu iterieren. Das ist besonders nützlich, wenn Ihre „Migration“ benutzerdefinierte Logik (erweiterte Formulare, Mitgliederflüsse, interne Tools) beinhaltet und nicht nur Seiten.

Pre‑Migration‑Audit: Vollständiges Site‑Inventar erstellen

Bevor Sie Design oder SEO‑Einstellungen anfassen, verschaffen Sie sich ein klares Bild Ihrer aktuellen Seite. Die meisten Migrationsprobleme entstehen, weil etwas „Kleines“ (eine versteckte Landingpage, ein altes PDF, eine Formularintegration) erst während des Rebuilds entdeckt wird.

1) Inventarisieren Sie alles, was Besucher erreichen können

Starten Sie mit einer Masterliste (ein Spreadsheet reicht) und erfassen Sie:

• Alle Seiten (inkl. Utility‑Seiten wie Datenschutzerklärung, Danke‑Seiten und passwortgeschützte Bereiche)
• Blogposts, Kategorien/Tags, Autoren (falls relevant)
• Produkte, Collections, Varianten und digitale Downloads
• Galerien, Portfolios, Events, Menüs und Standortseiten
• Formulare, Popups, Banner, Chat‑Widgets und Lead‑Magnete

Listen Sie außerdem, was neu erstellt werden muss, weil es sich nicht sauber übertragen lässt: Buchungstools, Multilingual‑Setups, Mitglieder/Logins, Custom‑Skripte und Automatisierungen.

2) Sammeln Sie Ihre aktuellen URLs (ja, auch die alten)

Exportieren oder crawlen Sie Ihre Seite und notieren Sie jede gefundene URL, inklusive:

• Versteckte Seiten, die nicht in der Hauptnavigation erscheinen
• Alte Kampagnen‑/Landing‑URLs, die in Anzeigen oder E‑Mails verwendet wurden
• PDFs und Dateilinks, die Nutzer eventuell gespeichert haben

Das wird später Ihre Weiterleitungskarte und schützt sowohl SEO als auch User Experience.

3) Erfassen Sie Baseline‑Performance‑Metriken

Laden Sie Benchmarks herunter, damit Sie nach dem Umzug prüfen können, ob Sie Boden verloren haben:

• Top‑Seiten nach Traffic und Conversions
• Suchanfragen/Landingpages aus der Search Console (falls vorhanden)
• Wichtige Conversion‑Aktionen (Formular‑Einreichungen, Käufe, Buchungen)

4) Sichern Sie Assets und Brand‑Essentials

Legen Sie einen Ordner mit Originalbildern, Videos, PDFs, Logo‑Dateien, Fonts, Farbwerten und Texten an, die in Widgets liegen (Ankündigungsleisten, Popups, Footer). Wenn Sie etwas später nicht einfach erneut herunterladen können, behandeln Sie es als „muss gesichert werden“.

SEO‑Plan: Rankings während des Umzugs schützen

Eine Wix‑ oder Squarespace‑Migration kann Ihrem Geschäft sehr helfen – bis der Traffic einbricht, weil Google Ihre Seiten nicht mehr findet. Das Ziel ist simpel: Machen Sie die neue Seite für Suchmaschinen „vertraut“, auch wenn sie auf einer anderen Plattform gebaut ist.

1) Beginnen Sie mit einem URL‑Mapping (bevor Sie bauen)

Exportieren oder crawlen Sie Ihre aktuelle Seite und listen Sie jede indexierbare URL (Seiten, Beiträge, Produkte). Entscheiden Sie dann, was aus jeder URL auf der neuen Site wird.

• Mappen Sie alte URLs auf neue URLs (bewahren Sie Struktur, wo möglich)
• Entscheiden Sie, was gestrichen, zusammengeführt oder verbessert wird (dünne Seiten, Duplikate)

Wenn Sie eine Seite löschen, leiten Sie nicht einfach alles zur Startseite weiter. Leiten Sie zur nächstbesten passenden Seite oder liefern Sie ein sauberes 404, wenn es wirklich keinen Ersatz gibt.

2) Planen Sie Weiterleitungen als Deliverable

Weiterleitungen sind oft der Unterschied zwischen einer erfolgreichen „Umzug von Wix“ und dem Verschwinden Ihrer besten Seiten aus der Suche.

• Planen Sie 301‑Weiterleitungen und vermeiden Sie Redirect‑Ketten

Erstellen Sie ein Redirect‑Spreadsheet mit drei Spalten: Alte URL → Neue URL → Notizen. Implementieren Sie die Weiterleitungen dann in Ihrer neuen Plattform (oder auf Serverebene, wenn Sie Kontrolle haben). Testen Sie sie zuerst in einer Staging‑Umgebung.

3) Bewahren Sie funktionierende On‑Page‑Elemente

Auch wenn das Design sich ändert, behalten Sie bewährte SEO‑Signale wo möglich bei:

• Bewahren Sie Titles, Meta‑Descriptions, Überschriften, Alt‑Text

Achten Sie besonders auf stark frequentierte Seiten und Beiträge. Wenn Sie sie redesignen, behalten Sie das primäre Thema und die Intention bei – vermeiden Sie, eine fokussierte Service‑Seite in eine generische Marketingseite zu verwandeln.

4) Technische SEO‑Checks für den Launch‑Tag

Bevor Sie DNS umschalten, vergewissern Sie sich, dass die neue Seite crawlbar und konsistent ist.

• Bereiten Sie SEO‑Checks vor: Sitemap, robots.txt, Canonicals, Schema

Prüfen Sie außerdem:

• Analytics und Search Console sind am neuen Property eingerichtet
• Keine „noindex“‑Tags vom Staging verbleiben
• Interne Links zeigen auf die neuen URLs (nicht auf weitergeleitete)

Ein sorgfältiger SEO‑Migrationsplan braucht Zeit, ist aber meistens die günstigste Art, Rankings beim Rebuild zu schützen und zu verbessern.

Content‑ und Medien‑Migration: Was sich sauber überträgt

Inhalte sind oft der zeitaufwändigste Teil einer Wix‑ oder Squarespace‑Migration – nicht weil es technisch schwierig ist, sondern weil Plattformen Inhalte unterschiedlich speichern. Die gute Nachricht: Die meisten Kerninhalte lassen sich übertragen, auch wenn es kein Ein‑Klick‑Vorgang ist.

Was typischerweise exportierbar ist

Blogbeiträge und Basisseiten übertragen sich in der Regel auf Textebene gut. Squarespace bietet Exporte, die auf gängige CMS‑Formate ausgerichtet sind, während Wix‑Exporte oft eingeschränkter sind – erwarten Sie, strukturierte Daten zu exportieren (wenn verfügbar) und dann die Formatierung neu aufzubauen.

Produkte und Shopdaten lassen sich oft via CSV exportieren (Produkte, Varianten, Preise, SKUs). Das ist eine solide Grundlage für das Re‑Importieren in Shopify, WooCommerce oder andere Plattformen. Bestellhistorie und Kundenkonten sind möglicherweise nur teilweise übertragbar oder benötigen separate Exporte.

Manuelle vs. automatisierte Migrationsoptionen

Sie wählen meist zwischen:

• CSV‑Ex-/Import für Produkte, einige Blog‑Metadaten, Redirects und Listen
• Copy/Paste oder Neuanlegen von Seiten, wenn Layouts stark individualisiert sind
• Migrationstools, die Inhalte über Feeds/APIs ziehen können, wo unterstützt (hilfreich für Posts und Basisseiten, weniger zuverlässig bei komplexen Layouts)

Ein praktischer Ansatz ist „automatisiere die Datenbank, baue die Präsentation manuell neu“. Das hält den Umzug schnell, ohne Qualität zu opfern.

Bilder und Medien: worauf Sie achten sollten

Medien übertragen sich selten perfekt. Planen Sie:

• Dateinamen so weit wie möglich zu erhalten (hilfreich für Organisation und manchmal SEO)
• Bilder in die neue Medienbibliothek neu hochzuladen und konsistente Ordner/Collection‑Regeln zu setzen
• Kompression beim Upload (oder vorher), damit die neue Seite schnell bleibt
• Alt‑Text neu anzulegen – er fehlt oft in Exporten, also erfassen Sie ihn in Ihrem Inventar

Formatierungsfallen (Tabellen, Embeds, Buttons)

Erwarten Sie, dass Elemente wie Tabellen, Buttons und Mehrspalten‑Abschnitte neu erstellt werden müssen, besonders wenn sie mit einem visuellen Editor gebaut wurden. Prüfen Sie außerdem:

• Embeds (YouTube, Calendly, Maps): erneut per Embed‑Block einfügen
• Shortcodes oder plattformspezifische Widgets: durch äquivalente Plugins/Apps ersetzen

Kommentare, Tags, Kategorien und Autoren

Bevor Sie Inhalte verschieben, entscheiden Sie, was es wert ist, erhalten zu bleiben:

• Tags/Kategorien: meist übertragbar, aber Namen und URL‑Strukturen können sich ändern
• Autoren: prüfen, ob echte Multi‑Author‑Zuweisung nötig ist oder nur Byline genügt
• Kommentare: native Kommentare wandern selten sauber mit; überlegen Sie, Exportarchive zu behalten oder auf ein Drittanbieter‑System umzusteigen, wenn Community‑Interaktion wichtig ist

Wenn Sie Content‑Migration als kontrollierten Neuaufbau behandeln (nicht als blindes Kopieren), erhalten Sie sauberere Seiten, leichtere Medien und weniger SEO‑Überraschungen.

Design & Features: Neuaufbauen ohne bei Null anzufangen

Eine Migration ist eine Chance, was visuell und funktional funktioniert zu behalten – ohne alle alten Workarounds mitzunehmen. Ziel ist nicht ein pixelgenauer Klon, sondern ein vertrautes Erlebnis für Besucher, gebaut aus saubereren Bausteinen, damit künftige Updates leichter sind.

Erstellen Sie zuerst die wichtigsten Templates

Starten Sie mit dem Neuaufbau einer kleinen Auswahl von Seitenvorlagen, die 80 % Ihrer Site repräsentieren. Für die meisten Unternehmen sind das:

• Homepage (Hauptbotschaft, Trust‑Elemente, primäre CTA)
• Leistungsseite (Vorteile, Ablauf, FAQs, Kontaktweg)
• Blogpost (Lesbarkeit, Überschriften, Autor/Datum, verwandte Inhalte)
• Produktseite (falls relevant: Preis, Varianten, Versand/Rückgabe, Bewertungen)

Wenn diese stimmen, werden die restlichen Seiten zu schnellen Variationen statt zu Einzelanfertigungen.

Stimmen Sie Markenbasis ab, bevor Sie Details jagen

Legen Sie Ihr Marken‑„System“ zuerst fest: Typografie, Farben, Abstände und wiederverwendbare Komponenten (Buttons, Karten, Callouts, Formularfelder). Wenn diese Basics konsistent sind, wirkt die Seite wie Ihre Marke, selbst wenn einzelne Layoutdetails anders sind.

Erstellen Sie ein einfaches Komponenten‑Set zur Wiederverwendung:

• Primär/sekundäre Buttons
• Abschnittsüberschriften und Intro‑Texte
• Testimonial‑Blöcke
• FAQ‑Accordion oder einfache Q&A‑Layouts
• Pricing‑/Paket‑Karten

Erstellen Sie kritische Features neu (und streichen Sie Unnötiges)

Listen Sie Ihre Must‑Have‑Funktionen auf und bauen Sie sie bewusst neu, statt jedes Plugin oder Widget zu reproduzieren.

Gängige „kritische“ Features, die früh geprüft werden sollten:

• Formulare (Kontakt, Lead‑Magnets, Dateiupload, Autoresponder)
• Terminbuchung (Verfügbarkeiten, Zeitzonen, Bestätigungen)
• E‑Commerce (Steuern/Versand, Rabatte, Inventar, Warenkorb‑Wiederherstellung)
• Site‑Suche (wichtig bei Blogs oder Produktkatalogen)

Wenn ein Feature nur existierte, weil die alte Plattform limitiert war (z. B. zusätzliche Seiten als Navigationsersatz), ist es auf der neuen Plattform möglicherweise überflüssig.

Barrierefreiheit von Anfang an

Accessibility im Nachhinein zu beheben ist langsam und fehleranfällig. Bauen Sie die Grundlagen von Anfang an ein.

Konzentrieren Sie sich auf:

• Ausreichenden Farbkontrast für Text und Buttons
• Sichtbare Fokus‑Zustände für Tastaturnavigation
• Korrekte Formularlabels (nicht nur Platzhalter)
• Klaren Überschriftenaufbau (H1, dann H2/H3 in Reihenfolge)

Erstellen Sie sich eine Mini‑Styleguide

Notieren Sie die Regeln, die Sie festgelegt haben – Fonts, Farben, Button‑Stile, Abstände und die Verwendung zentraler Komponenten. Schon eine einseitige Styleguide hält künftige Änderungen konsistent und verhindert, dass das Design ausfranst, wenn mehrere Personen die Seite bearbeiten.

Migrationsprojektplan und Zeitplan

Eine saubere Wix‑ oder Squarespace‑Migration ist weniger „Dateien verschieben“ als ein kleines Projekt mit klaren Schritten, Verantwortlichkeiten und einem vorhersehbaren Umschaltzeitpunkt. Ziel ist, Überraschungen zu vermeiden – besonders bei Navigation, SEO und DNS.

Wählen Sie Ihren Launch‑Ansatz

Big‑Bang‑Launch heißt: Sie bauen die ganze Seite neu und schalten dann auf einmal um. Das ist schneller und leichter zu kommunizieren, bündelt aber auch das Risiko auf den Launch‑Tag.

Phasenweiser Rollout verschiebt Bereiche schrittweise (z. B. zuerst Blog, dann Services, dann E‑Commerce). Das reduziert Risiko und erlaubt Lernen unterwegs, erfordert aber enges Tracking, um doppelte oder widersprüchliche Seiten zu vermeiden.

Struktur bauen, bevor Sie Inhalte importieren

Sperren Sie zuerst Ihre Sitemap, URL‑Struktur und Navigation. Importieren oder Überarbeiten von Inhalten zu früh führt meist dazu, dass Sie mehrfach umorganisieren. Bestätigen Sie, welche Seiten existieren, welche zusammengeführt/entfernt werden und wie das neue Menü aussieht.

Nutzen Sie Staging + legen Sie ein Content‑Freeze fest

Richten Sie eine Staging‑Umgebung (private Vorschau) ein, in der der Rebuild sicher stattfindet. Planen Sie dann ein kurzes Content‑Freeze – eine Zeitspanne, in der niemand die alte Seite bearbeitet – damit Sie keine neuen Updates, Blogposts oder Produktänderungen kurz vor dem Launch verpassen.

Verantwortliche benennen und Entscheidungen tracken

Geben Sie jedem Arbeitsstrang einen klaren Owner: SEO, Content, Design/Features, QA und Domain/DNS. Führen Sie eine gemeinsame Website‑Migrationscheckliste (ein Dokument) mit Entscheidungen wie Weiterleitungen, Seitenentfernungen, Formularzielen und Launch‑Aufgaben. Das verhindert spätere „Wer hat das genehmigt?“‑Momente.

Ein realistischer Zeitrahmen (typisch)

Die meisten kleinen bis mittleren Seiten benötigen 2–6 Wochen: 1 Woche Planung/Struktur, 1–3 Wochen Rebuild + Content, 1 Woche QA und Korrekturen, dann Launch + Monitoring nach dem Launch.

Domain, E‑Mail und DNS: Wechsel ohne Verlust

Hier werden oft Dinge kaputtgemacht, die „nicht die Website“ sind – E‑Mail, Tracking und Logins. Mit einem einfachen Plan gelingt der Wechsel sauber und mit minimaler Downtime.

Domain‑Transfer vs. DNS‑Pointing (was wählen?)

Zwei Hauptoptionen beim Umzug von Wix oder Squarespace:

• Domain transferieren zum neuen Registrar/Host. Das kann langfristig die Verwaltung vereinfachen, ist aber langsamer und erfordert zusätzliche Schritte (Zustimmungen, Transfer‑Sperren, Wartezeiten).
• Domain beim aktuellen Registrar belassen und DNS umstellen auf die neue Plattform. Das ist meist der schnellste und sicherste Weg während einer Migration, weil Sie zeitgenau cutten können.

Für die meisten Migrationen empfiehlt sich zunächst DNS‑Pointing. Einen Transfer können Sie später durchführen, wenn alles stabil ist.

E‑Mail schützen: MX‑Records zuerst

E‑Mail läuft über MX‑Records, nicht über die Website‑Plattform. Bevor Sie etwas ändern:

1. Exportieren oder screenshotten Sie Ihre aktuelle DNS‑Zone.
2. Identifizieren Sie Ihren E‑Mail‑Provider (Google Workspace, Microsoft 365 etc.).
3. Stellen Sie sicher, dass die gleichen MX‑Records und notwendigen TXT‑Records (SPF, DKIM, DMARC) erhalten bleiben.

Wenn Sie die DNS‑Zone überschreiben, ohne diese Einträge wiederherzustellen, kann E‑Mail ausfallen.

Vergessen Sie nicht die „versteckten“ DNS‑Einträge

Neben A/AAAA für die Seite und MX für E‑Mail nutzen viele Dienste:

• TXT‑Records für Verifikation und Sicherheit
• CNAME‑Records für Tools wie Mail‑Tracking, Landingpages oder Support‑Widgets

Listen Sie vor dem Cutover jede Integration auf, die Sie nachprüfen müssen: Analytics, Ad‑Pixels, CRM/Formulare, Terminbuchung und Payment‑Provider.

SSL, Sicherheit und Backups

Auf der neuen Plattform prüfen Sie:

• SSL ist aktiv (Site lädt über https://)
• Backups sind aktiviert (oder es gibt einen Rollback‑Plan)
• Grundlegende Sicherheitseinstellungen sind gesetzt (Admin‑Zugänge, Updates, Spam‑Schutz für Formulare)

Downtime vermeiden: TTL senken und Cutover planen

Eine einfache Methode, Ausfallzeiten zu minimieren, ist, die DNS‑TTL 24–48 Stunden vor dem Wechsel zu senken. Das beschleunigt die Propagation. Planen Sie ein Cutover‑Fenster mit geringem Traffic und prüfen Sie direkt danach: Homepage lädt, wichtige Formulare funktionieren, Checkout läuft (falls relevant) und E‑Mail sendet/empfängt weiterhin.

Launch‑ und QA‑Checkliste

Launch‑Tag ist weniger „Schalter umlegen“ als das Bestätigen, dass die neue Seite sich an allen für Besucher und Suchmaschinen relevanten Stellen wie die alte verhält (oder besser). Nutzen Sie diese Checkliste, um die häufigsten Migrationsfehler zu fangen, bevor sie zu Support‑Tickets werden.

1) Kernfunktionalität (das, was Verkäufe bricht)

Arbeiten Sie reale Nutzerpfade ab – klicken Sie nicht nur auf die Homepage.

• Links: Spot‑Checks für Navigation, Footer, Buttons und stark besuchte Blogposts
• Formulare: Testen Sie jede Form end‑to‑end (Bestätigungsnachricht, E‑Mail‑Zustellung, CRM/Zapier‑Verbindung)
• Suche: Einige Suchanfragen ausführen; Ergebnisse und Filter prüfen
• Checkout/Payments (falls): Test mit einer echten Transaktion oder Sandbox‑Order
• Tracking: Analytics und Ads‑Pixel auf Schlüsselergebnissen prüfen (Pageview, Form Submit, Purchase)
• 404s: Besuchen Sie alte URLs und prüfen Sie, ob sie korrekt weitergeleitet werden oder eine hilfreiche 404-Seite zeigen

2) Mobil, Browser und Speed

• Testen Sie zuerst auf Mobil (Menüs, Sticky‑Header, Touch‑Targets, Bildzuschnitt)
• Prüfen Sie mindestens Chrome, Safari, Firefox
• Führen Sie einen kurzen Speed‑Check durch; achten Sie auf große Bilder, Video‑Embeds und schwere Slider

3) Weiterleitungs‑Verifikation (Schutz der Rankings)

Validieren Sie nicht jede URL manuell. Stattdessen:

• Nehmen Sie eine Stichprobe Ihrer Top‑Seiten (Homepage, Services, wichtige Blogposts) und prüfen Sie alte→neue Weiterleitungen
• Fügen Sie eine Auswahl von historischen URLs hinzu, die Sie in Social Posts oder E‑Mails geteilt haben

4) Schritte für Suchmaschinen nach dem Launch

• XML‑Sitemap erzeugen/bestätigen und einreichen
• Seite in den Search‑Tools verifizieren und Indexierungsanfragen für wichtige Seiten stellen

5) 2–4 Wochen Monitoring

Kleine Schwankungen sind normal. Entscheidend sind Trends und Fehler.

• Überwachen Sie Crawl‑Fehler, Redirects und 404‑Reports
• Vergleichen Sie Traffic und Conversions Woche über Woche
• Führen Sie ein kurzes „Fix‑Log“, damit Probleme einmalig und nachhaltig behoben werden

Kosten, Aufwand und Hilfe holen

Eine Wix‑ oder Squarespace‑Migration ist kein Festpreis. Sie besteht aus mehreren Teilprojekten, die sich summieren – budgetieren Sie nach Bereichen statt nach einer einzigen Zahl.

Übliche Kosten‑Bausteine

• Design/Build: Templates, Layouts, Komponenten, Mobile‑Anpassungen
• Content‑Arbeit: Umschreiben, Formatieren, Seiten verschieben, neue Landingpages
• Medien + Assets: Bildkomprimierung, Downloads, Alt‑Text, Organisation
• SEO + Analytics: Weiterleitungen, Metadaten, Sitemap, GA4/GSC‑Setup, Tracking‑Checks
• Tools + Subscriptions: Plugins/Apps, Formulare, E‑Mail‑Marketing, Reviews, CRM
• Hosting + Wartung: Hostingplan, Backups, Sicherheit, laufende Änderungen

Was Aufwand und Zeitplan treibt

Der Aufwand wächst mit:

• Anzahl der Seiten und wie unterschiedlich diese sind
• Komplexität: Blog, Memberships, Buchung, Mehrsprachigkeit
• E‑Commerce: Produktanzahl, Varianten, Abos, Versand/Steuerlogik
• Custom Features: Rechner, gated content, Integrationen (Zapier/CRM)
• Schnelligkeit der Freigaben und Lieferung von Assets

Eine kleine Broschürenseite kann ein DIY‑Wochenende sein; eine content‑schwere oder E‑Commerce‑Site braucht Wochen inklusive Revisionen und Tests.

DIY vs. externe Hilfe (Risiko‑Tradeoff)

DIY eignet sich, wenn Sie Zeit haben, Checklisten folgen können und die Seite simpel ist. Externe Hilfe zahlt sich aus, wenn Rankings und Umsatz auf dem Spiel stehen – Fehler wie kaputte Weiterleitungen, fehlende Metadaten oder Checkout‑Probleme können teurer kommen als das Projekt.

Wenn Sie neu aufbauen im Rahmen der Migration, überlegen Sie, wie Sie nach dem Launch iterieren. Plattformen wie Koder.ai können Teams helfen, schneller zu liefern (und Momentum zu behalten), indem sie die neue App‑Struktur aus Chat generieren, Planungs‑Modi unterstützen und den Source‑Code exportierbar machen, wenn Sie die Kontrolle übernehmen möchten.

Wenn Sie eine schnelle Schätzung wollen, teilen Sie Ihr Inventar und Ihre Ziele über /contact oder vergleichen Sie Optionen auf /pricing.

Copy/paste Scope‑Template

Project goal:
Current platform (Wix/Squarespace):
New platform:
Pages to migrate (count + key URLs):
Blog posts (count):
Ecommerce? (products/SKUs/variants):
Must-have features (forms, booking, members, etc.):
Integrations (email/CRM/payments):
SEO requirements (redirects, metadata, analytics):
Design notes (keep similar vs redesign):
Target launch date:
Who provides copy/images:
Who approves and how fast: