Alle Beiträge
websiterelaunchmigrationeigene-erfahrung

Von Wix zur eigenen Website: unser eigener Umzug

Kein Kundenfall, sondern unserer. Zwei Stationen, drei Posten, die teurer waren als die Gestaltung — und was wir beim nächsten Mal anders machen würden.

Pixup MediaVeröffentlicht am Aktualisiert am 12 Min. Lesezeit
Illustration eines Mannes am Laptop, der eine Baukasten-Vorlage in eine individuell gestaltete Website überführt

Dieser Beitrag beschreibt keinen Kundenfall, sondern unseren eigenen. Wir haben unsere Website in zwei Schritten bewegt: vom Baukasten über eine Zwischenlösung auf eigenen Code, der als statische Seiten auf einem eigenen Server liegt. Der zweite Schritt ist im September 2026 fertig geworden.

Wir schreiben das auf, weil Umzugsberichte meistens von der Gestaltung handeln — und der Aufwand woanders lag.

Station 1: Der Baukasten

Er hat lange getragen. Man kommt schnell online, Vorlagen sehen ordentlich aus, und niemand muss sich um Updates kümmern. Für die ersten Jahre war das genau richtig.

Die Grenzen zeigten sich an drei Stellen:

Bei der Ladezeit. Eine Baukastenseite trägt viel mit, was man nicht benutzt. Das lässt sich verbessern, aber nicht abstellen.

Bei eigenen Seitentypen. Wir wollten Fachartikel mit Struktur — mit Belegkasten, Versionsangabe, Prüfdatum —, nicht nur Blogbeiträge mit Titel und Text. Ein Baukasten kennt die Seitentypen, die er kennt.

Bei der Frage, wem die Inhalte gehören. Der Export liefert Text. Er liefert nicht die Struktur, nicht die Adressen, nicht die Bilder in der Form, in der sie ausgeliefert wurden.

Station 2: Die Zwischenlösung

Mehr Gestaltungsfreiheit, schneller gebaut, aber eine neue Abhängigkeit: Die Seite lief bei einem Anbieter, dessen Laufzeitumgebung wir nicht kontrolliert haben. Für eine Agenturseite, die über Technik spricht, war das auf Dauer unpassend.

Die Zwischenlösung war kein Fehler. Sie war der Schritt, der uns gezeigt hat, welche Seitentypen wir tatsächlich brauchen — und das wussten wir vorher nicht.

Station 3: Eigener Code, eigener Server

Heute entstehen die Seiten aus Quelltext im eigenen Repository und werden als fertige HTML-Dateien ausgeliefert. Kein Server, der bei jedem Aufruf rechnet, keine Datenbank, keine fremde Laufzeitumgebung.

Was der Wechsel gebracht hat

0

Anwendungen, die bei einem Aufruf rechnen müssen

1 Commit

Umfang einer Änderung, vollständig nachvollziehbar

Bruchteil

Hostingkosten gegenüber dem Plattform-Abo

Tempo. Statische Dateien sind so schnell, wie der Server sie ausliefert. Kontrolle. Jede Änderung ist ein Commit. Was live ist, steht im Git. Freiheit. Eigene Seitentypen, eigene Strukturen, eigene Automatisierung.

Ob dieser Weg für Sie der richtige ist, hängt weniger an der Technik als an der Redaktion — das haben wir in Statische Website oder CMS auseinandergenommen.

Was der Umzug tatsächlich gekostet hat

Nicht die Gestaltung war der Aufwand, sondern drei andere Dinge.

Der Aufwand nach Posten: Gestaltung klein, Adressen und Inhalte groß.
Die Verteilung, die uns selbst überrascht hat. Die Gestaltung war der Teil, über den vorher am meisten gesprochen wurde.

Inhalte und Adressen

Jeder bestehende Beitrag musste übernommen werden, und jede alte Adresse brauchte ein Ziel. Wer das überspringt, verliert Sichtbarkeit — die Weiterleitungen sind kein Nebenschritt, sie sind der Kern des Umzugs.

Wie das bei einem Shop aussieht, haben wir in Redirects bei einem Shopware-Relaunch beschrieben; für eine Website gilt dasselbe in klein.

Formulare und Mailversand

Ein Kontaktformular ohne Plattform braucht einen eigenen Weg — bei uns ein kleiner Endpunkt, der über einen Mailversanddienst zustellt.

Rechtstexte und Auftragsverarbeiter

Wer den Anbieter wechselt, ändert auch die Liste der Dienstleister. Datenschutzerklärung und Verträge gehören mit umgezogen — und zwar zum Umschalttag, nicht danach.

Was wir am Umschalttag gemessen haben

Ein Umzug ist erst fertig, wenn er nachgewiesen ist. Diese Messungen haben wir am Tag der Umstellung gefahren — sie sind nachbaubar und gehören aus unserer Sicht in jedes Relaunch-Projekt:

Die Abnahme, die wir uns selbst auferlegt haben

  • Alle Seiten einzeln abgerufen: Statuscode und Inhalt gegen den alten Stand verglichen.
  • Alle Verweise auf Bilder, Stile und Skripte geprüft — jede einzelne, nicht stichprobenartig.
  • Jede Weiterleitung getestet: Kommt sie in einem Sprung an, nicht in zweien?
  • Das Kontaktformular zweimal abgeschickt: einmal über die Schnittstelle, einmal von Hand im Browser.
  • Die Seite im Browser beobachtet: keine Anfrage an einen fremden Host, keine Meldung in der Konsole.
  • Die Zertifikatslage geprüft, inklusive der Frage, wann die nächste Verlängerung fällig ist.

Der fünfte Punkt hat uns eine Nacharbeit erspart, die sonst niemandem aufgefallen wäre: Reste der alten Plattform, die in Skripten weiterlebten.

Für wen sich dieser Weg lohnt

Eine ehrliche Abgrenzung

Lohnt sich

  • mehr als zwanzig Seiten
  • eigene Seitentypen sind gewünscht
  • jemand im Haus oder an Ihrer Seite betreut Technik
  • die Website ist auf Jahre geplant

Lohnt sich nicht

  • fünf Unterseiten, einmal im Jahr angefasst
  • niemand, der einen Bauprozess betreut
  • häufige eilige Änderungen ohne technische Begleitung
  • die Seite ist in zwei Jahren ohnehin überholt

Die rechte Spalte sagen wir Interessenten auch, bevor ein Angebot entsteht. Ein Baukasten, der zur Lage passt, ist besser als eigener Code, den niemand pflegt.

Was wir anders machen würden

Die Struktur vor den Inhalten. Wir haben die Inhalte zuerst übernommen und die Seitentypen danach sortiert. Der umgekehrte Weg wäre schneller gewesen: erst festlegen, welche Typen es geben soll, dann übernehmen.

Die Weiterleitungsliste früher. Nicht am Ende als Abschlussarbeit, sondern als Erstes — weil sie bestimmt, welche Seiten überhaupt gebraucht werden. Eine alte Adresse ohne heutige Entsprechung ist entweder ein fehlender Inhalt oder eine bewusste Entscheidung; beides will man vor dem Umschalten wissen.

Den Umschalttag als Messpunkt planen. Wir haben nach dem Wechsel gemessen — alle Seiten, alle Assets, alle Weiterleitungen, das Formular zweimal. Das war richtig. Besser wäre gewesen, dieselben Messungen vorher auf dem alten Stand zu fahren, damit man einen Vergleichswert hat statt eines Gefühls.

Was es nicht gebracht hat

Der Wechsel hat die Website nicht schöner gemacht und keine Besucher gebracht. Er hat die Grundlage geschaffen, auf der wir seitdem eigene Seitentypen und einen automatisierten Veröffentlichungsweg bauen konnten — das ist der eigentliche Ertrag, und er war am ersten Tag nicht sichtbar.

Wer einen Umzug damit begründet, dass die Zahlen danach besser werden, wird enttäuscht. Wer ihn damit begründet, dass er danach bauen kann, was er braucht, nicht.

Wenn Sie vor einem ähnlichen Schritt stehen: Wir sagen Ihnen anhand Ihrer Seitenzahl und Ihrer Redaktionslage, ob sich der Aufwand trägt — und was er nach unserer Erfahrung tatsächlich umfasst. Mehr dazu unter Webseiten-Erstellung.