Website-Relaunch ohne SEO-Verlust: Die Checkliste.

Ein Relaunch kann deine Rankings kosten, muss er aber nicht. Der komplette SEO-sichere Prozess: von Bestandsaufnahme und Redirect-Mapping über 301-Weiterleitungen und Staging bis zu Monitoring und Checkliste. Plus: warum der Relaunch sogar eine Chance ist.

Veröffentlicht: Aktualisiert: 12 Min. Lesezeit
Migrations-Flow von Alt zu Neu mit Schutzschild für erhaltene SEO.

Es ist der Albtraum nach jedem Relaunch: Die neue Seite ist live, sieht großartig aus - und drei Wochen später ist der organische Traffic eingebrochen. Rankings weg, Anfragen weg, und niemand weiß, warum.

Das passiert öfter, als man denkt, und fast immer aus demselben Grund: SEO wird beim Relaunch als Nachgedanke behandelt. Dabei lässt sich der Verlust komplett vermeiden, wenn man ein paar Dinge vorher richtig macht.

Diese Checkliste führt dich durch die wichtigsten Schritte - vor, während und nach dem Relaunch. Sie ist so geschrieben, dass du sie deinem Team oder deiner Agentur direkt vorlegen kannst.

Das Wichtigste in Kürze

  • Ein Relaunch kostet nur dann Rankings, wenn SEO zu spät ins Boot geholt wird. Wer URLs, Weiterleitungen und Inhalte sauber plant, kann aus dem Relaunch sogar einen Sichtbarkeitsgewinn machen.
  • Der teuerste Fehler: geänderte URLs ohne 301-Weiterleitung. Google findet deine rankenden Seiten nicht mehr, der Traffic bricht ein. 301 (permanent) überträgt die Ranking-Signale, 302 und 307 (temporär) tun das nicht.
  • Jede alte URL braucht eine 301-Weiterleitung auf ihr neues Pendant. Beim Plattformwechsel (Wix, WordPress oder Webflow auf Next.js/Astro) kommen 8 Prüfpunkte dazu, vor allem Slugs, Bild-URLs und Rendering.
  • Ein Redirect-Mapping (alte URL zu neuer URL) ist das Herzstück. Grundlage: ein vollständiger Crawl der Altseite plus deine Top-Traffic- und Top-Backlink-Seiten aus GSC und einem SEO-Tool.
  • Plane Geduld ein. Nach einem größeren Relaunch braucht Google oft mehrere Wochen bis zu rund drei Monaten, um neu zu crawlen, zu indexieren und die Rankings zu stabilisieren. Nicht in Panik verfallen, sondern monitoren.

Warum kostet ein Relaunch oft Rankings?

Ein Website-Relaunch ist mehr als ein neues Design. In der Regel ändern sich gleichzeitig Inhalte, Navigation, URL-Struktur und die Technik dahinter. Genau in dieser Gleichzeitigkeit liegt das Risiko: Suchmaschinen müssen die Seite quasi neu bewerten, alle URLs neu crawlen, neu indexieren und neu einsortieren. Wird dieser Umzug schlecht vorbereitet, verlierst du Sichtbarkeit, die du dir über Jahre erarbeitet hast.

Die klassischen Ursachen sind fast immer dieselben. URLs ändern sich, ohne dass jemand Weiterleitungen einrichtet, also findet Google die alten, rankenden Seiten nicht mehr. Gut rankende Seiten werden im Zuge der Content-Bereinigung gelöscht. Technische Fehler wie ein versehentlicher noindex oder eine falsch gesetzte robots.txt sperren die neue Seite aus dem Index aus. Das Bittere daran: Keiner dieser Fehler ist nötig. Sie entstehen, weil SEO nicht von Anfang an mitgedacht wird, sondern erst, wenn der Traffic schon eingebrochen ist.

Die gute Nachricht ist die eigentliche Kernbotschaft dieses Artikels: Ein Relaunch muss keine Rankings kosten. Sauber geplant überträgst du deine Autorität vollständig auf die neue Seite und behebst gleichzeitig Altlasten, die dich bisher gebremst haben. Aus dem gefürchteten Risiko wird dann eine der besten Gelegenheiten, deine Sichtbarkeit zu steigern.

Wann ist ein Relaunch überhaupt sinnvoll?

Bevor du dieses Risiko eingehst, lohnt eine ehrliche Frage: Brauchst du wirklich einen kompletten Relaunch, oder reicht eine Renovierung? Ein Relaunch gleicht dem Abriss und Neubau eines Hauses. In vielen Fällen ist die schrittweise Optimierung der bestehenden Seite der klügere, günstigere und für SEO deutlich sicherere Weg. Die erfolgreichsten Websites der Welt machen faktisch nie einen großen Relaunch, sondern werden kontinuierlich weiterentwickelt.

Ein echter Relaunch ist sinnvoll, wenn tiefgreifende strukturelle Gründe vorliegen: ein veraltetes CMS mit Sicherheitslücken oder ohne Updates, fehlende mobile Optimierung, über Jahre unpflegbar gewachsene Strukturen, ein Rebranding oder eine strategische Neupositionierung. Übertrieben ist er dagegen, wenn nur kleine Anpassungen anstehen, das Budget knapp ist oder das Ziel unklar bleibt. Ein Relaunch, nur weil die Konkurrenz auch einen gemacht hat, richtet oft mehr Schaden an, als er nützt.

Die vier Relaunch-Arten und ihr Risiko

Nicht jeder Relaunch trägt dasselbe SEO-Risiko. Je nachdem, was sich ändert, ist die Gefahr für deine Rankings kleiner oder größer. Diese Einteilung hilft dir einzuschätzen, wie viel Vorsicht dein Projekt braucht:

Relaunch-Arten und ihr Ranking-Risiko

ArtWas sich ändertRisiko
Design-RelaunchNeues Design oder Theme, URLs bleibenGering bis mittel
CMS-RelaunchWechsel des Systems, z. B. WordPress zu WebflowMittel
URL-RelaunchUmbau der URL-StrukturHoch
DomainwechselNeue Domain für die gesamte SeiteSehr hoch

Wie läuft ein SEO-sicherer Relaunch ab?

Ein Relaunch ist ein Projekt mit klaren Phasen. Wer sie in der richtigen Reihenfolge durchläuft und SEO in jeder Phase mitdenkt, vermeidet die typischen Einbrüche. Die folgenden fünf Phasen sind das Grundgerüst. Der wichtigste Grundsatz vorweg, und da sind sich alle Fachleute einig: Nimm dir Zeit. Fast jeder katastrophale Relaunch wurde durch Zeitdruck und Ungeduld ausgelöst, nicht durch fehlendes Wissen.

1

Phase 1: Bestandsaufnahme und Snapshot

Bevor sich irgendetwas ändert, sicherst du den Ist-Zustand. Crawle die komplette alte Seite (mit einem Tool wie Screaming Frog) und speichere die URL-Liste ab. Erstelle einen Snapshot deiner aktuellen Keyword-Rankings, deiner wichtigsten Backlinks samt Zielseiten und deiner Top-Traffic-Seiten aus der Google Search Console und Analytics. Diese Daten sind später deine einzige verlässliche Referenz, um Einbrüche zu erkennen und weiterzuleitende Seiten zu priorisieren.

2

Phase 2: Planung, Content-Audit und Struktur

Jetzt entscheidest du, welche Inhalte bleiben, welche zusammengelegt und welche gestrichen werden. Seiten mit Traffic, Rankings oder Backlinks behältst du oder migrierst sie sauber. Altlasten ohne jeden Nutzen kannst du entfernen. Parallel planst du die neue URL-Struktur. Wichtig: Ändere URLs nur, wenn es einen echten Grund gibt. Jede unnötige URL-Änderung ist ein vermeidbares Risiko.

3

Phase 3: Staging und Redirect-Mapping

Die neue Seite entsteht in einer passwortgeschützten Staging-Umgebung, die den Googlebot per robots.txt oder noindex aussperrt, damit keine Testversion indexiert wird. Hier baust du das Herzstück: das Redirect-Mapping, eine Liste jeder sich ändernden alten URL und ihres neuen Ziels. Grundlage ist dein Crawl aus Phase 1. Jede weitergeleitete Seite sollte thematisch auf die passendste neue Seite zeigen, nicht pauschal auf die Startseite.

4

Phase 4: Launch mit korrekten 301-Weiterleitungen

Beim Go-live werden alle geänderten URLs per 301-Weiterleitung (permanent) auf ihr neues Ziel geleitet, inklusive Bilder und PDFs. Setze niemals 302 oder 307 (temporär), diese übertragen die Ranking-Signale nicht zuverlässig. Reiche eine frische XML-Sitemap in der Google Search Console ein. Bei einem Domainwechsel nutzt du dort zusätzlich die Adressänderungs-Funktion. Prüfe, dass Tracking-Code, Canonicals und hreflang korrekt sitzen.

5

Phase 5: Monitoring nach dem Launch

Direkt nach dem Live-Gang crawlst du die neue Seite erneut und prüfst alle Status-Codes: Funktionieren die Weiterleitungen, gibt es 404-Fehler, Weiterleitungsketten oder 500er? In der Google Search Console beobachtest du Indexierung, Abdeckung und Crawling-Fehler. Neue 404-Seiten bekommen sofort einen passenden 301-Redirect. Danach monitorst du Rankings, Traffic und Sichtbarkeit über Wochen. Geduld: Es dauert oft mehrere Wochen bis Monate, bis sich alles einpendelt.

Warum sind 301-Weiterleitungen so entscheidend?

Wenn ein einziger technischer Punkt über Erfolg oder Misserfolg deines Relaunches entscheidet, dann sind es die Weiterleitungen. Eine URL ist wie deine Adresse. Änderst du sie ohne Nachsendeauftrag, landen Google und deine Besucher im Nichts. Der Nachsendeauftrag im Web ist der 301-Redirect.

Der Statuscode 301 signalisiert eine dauerhafte Änderung. Google überträgt die Ranking-Signale der alten URL auf die neue und konsolidiert sie dort. Laut Googles eigener Dokumentation gehen bei einem korrekt umgesetzten permanenten Redirect (301 oder 308) auf eine thematisch passende Zielseite keine Ranking-Signale verloren. Genau deshalb sind 302 und 307 hier tabu: Sie signalisieren eine temporäre Änderung, und Google leitet die Signale dann nur zögerlich oder gar nicht weiter.

Ein paar Regeln aus der Praxis. Leite so relevant wie möglich weiter, also auf die inhaltlich nächste neue Seite, nicht pauschal auf die Startseite. Vermeide Weiterleitungsketten, bei denen A auf B und B erst auf C zeigt. Für endgültig gelöschte Seiten ohne Ersatz ist ein sauberer 410 (Gone) oft ehrlicher als eine erzwungene Weiterleitung. Und bei besonders wertvollen Backlinks lohnt es sich, den verlinkenden Betreiber direkt um eine Anpassung auf die neue URL zu bitten, statt dich nur auf die Weiterleitung zu verlassen.

Der technische Relaunch-Check: die Checkliste

Diese Checkliste bündelt die Punkte, die vor dem Launch in der Staging-Umgebung und direkt danach in der Live-Umgebung geprüft werden. Jeder Relaunch ist individuell, deshalb ergänze sie um deine projektspezifischen Punkte. Aber ohne diese Basis geht kein Relaunch sicher live. Wenn du ohnehin alles anfasst, gehört auch die Barrierefreiheit nach BFSG auf die Liste.

Relaunch-Checkliste: was vor und nach dem Launch zu prüfen ist

BereichPrüfpunkt
WeiterleitungenAlle geänderten URLs per 301 auf passendes Ziel? Keine 302/307, keine Ketten?
IndexierungKein versehentliches noindex, keine rankrelevanten Seiten in robots.txt gesperrt?
Status-CodesCrawl zeigt keine unerwarteten 404 oder 500? Interne Links zeigen direkt aufs Ziel?
SitemapFrische XML-Sitemap erstellt und in der Google Search Console eingereicht?
Canonicals & hreflangCanonical-Tags korrekt, hreflang bei Mehrsprachigkeit vollständig?
Meta-Daten & H1Jede Seite mit Title, Description und genau einer H1?
PerformanceCore Web Vitals und Ladezeit mindestens so gut wie vorher, idealerweise besser?
TrackingAnalytics- und Tracking-Code auf der neuen Seite aktiv?
Bilder & PDFsWichtige Bilder und PDFs 1:1 übernommen oder weitergeleitet?

Plattformwechsel ohne Ranking-Verlust: von Wix, WordPress oder Webflow auf Next.js oder Astro

Ein Relaunch mit Plattformwechsel verliert nur dann Rankings, wenn Google die alten Seiten nicht mehr wiederfindet. Beim Wechsel von Wix, WordPress oder Webflow auf Next.js oder Astro ändern sich URL-Muster, Bild-Adressen, Rendering und CMS gleichzeitig, und jede dieser Ebenen braucht eine eigene Zuordnung von alt nach neu. Wer nur die Seiten-URLs weiterleitet, hat die Hälfte der Arbeit gemacht.

Warum ist das Risiko höher als bei einem Redesign auf derselben Plattform? Vier Gründe.

URL-Struktur und CMS-Slugs. Jede Plattform baut ihre Adressen anders. Wix legt Blogbeiträge unter `/post/`, Webflow unter dem Collection-Namen, WordPress je nach Einstellung mit Datum oder Kategorie im Pfad. Dazu kommen Trailing Slashes (der Schrägstrich am Ende), Groß- und Kleinschreibung und Sonderzeichen, die jedes CMS anders auflöst. Im neuen System entstehen die Slugs aus deinem Content-Modell in Sanity. Ohne Abgleich passt keine einzige Adresse mehr.

Rendering-Wechsel. Rendering heißt: Wo entsteht das HTML, das Google liest? Baukästen liefern Plattform-HTML mit viel eigenem Skript, Next.js rendert auf dem Server, Astro baut statisch. Das ist ein Vorteil, aber nur, wenn jeder Text im ausgelieferten HTML steht und nicht erst im Browser nachgeladen wird.

Bild-URLs. Deine Bilder liegen heute auf dem CDN der Plattform (Wix, Webflow oder unter `/wp-content/uploads/`). Kündigst du die Plattform, sind diese Adressen tot. Bilder-Rankings und externe Links auf Bilder gehen mit.

Interaktionen. Tabs, Akkordeons, Slider und Webflow-Interaktionen enthalten Text, den Google heute indexiert. Werden sie im neuen System per JavaScript gebaut, das den Inhalt erst beim Klick erzeugt, verschwindet dieser Text aus dem Index.

Die normale Checkliste oben gilt weiter. Diese acht Punkte kommen beim Systemwechsel dazu:

Acht Punkte, die beim Systemwechsel dazukommen

PunktWarumWas wir tun
1. Slug-Mapping aus dem CMS-ExportAlte Slugs stehen nicht in der Sitemap allein, sondern im CMS mit Kategorie, Datum oder Collection-PfadWir exportieren alle Einträge (Webflow-CSV, WordPress-WXR, Wix-Export), erzeugen die Redirect-Map aus dem Export statt von Hand und legen die Trailing-Slash-Regel im Code fest
2. Bild- und Datei-URLsAssets liegen auf dem Plattform-CDN und sind nach der Kündigung wegAlle Assets herunterladen, in Sanity neu hochladen, Alt-Texte mitnehmen, Bilder mit Impressionen in der Search Console per 301 weiterleiten
3. Rendering-PrüfungGoogle bewertet das HTML, das der Server ausliefert, nicht das, was der Browser nachbautJede Vorlage im Rohquelltext prüfen (Server-Antwort ohne JavaScript) und in der Search Console mit der URL-Prüfung „Gecrawltes HTML" abgleichen
4. Text in InteraktionenAkkordeons, Tabs und Slider verlieren beim Nachbau oft ihren Text aus dem IndexInhalt im HTML ausliefern, Interaktion nur als Sichtbarkeit steuern, FAQ-Akkordeons zusätzlich als FAQPage-Schema
5. Meta-Daten, Canonicals, hreflangDie Plattform hat Title, Description, Canonical und Open Graph automatisch erzeugt; im Code-System muss jedes Feld im Content-Modell existierenFeld-für-Feld-Mapping vom Export in Sanity, bestehende Titles 1:1 übernehmen, hreflang wechselseitig inkl. x-default aus dem Code
6. Sitemap, robots.txt, 404-StatusPlattformen liefern Sitemap und Redirects per Oberfläche; im Code musst du beides selbst bauenSitemap aus Sanity generieren, Redirects in der Hosting-Konfiguration hinterlegen, 404-Seiten mit echtem Status 404 ausliefern (kein Soft 404 mit Status 200)
7. Plugin-Funktionen ersetzenWordPress-SEO-Plugins erzeugten Schema und Breadcrumbs, Formulare und Suche hingen an der PlattformSchema im Code neu aufbauen und mit dem Rich-Results-Test prüfen, Formulare auf das neue Ziel umziehen, Suche neu anbinden
8. DNS- und Hosting-CutoverDie Domain wechselt die Nameserver oder DNS-Einträge; falsche TTL oder fehlendes SSL kostet Stunden mit FehlerseitenDNS-TTL vor dem Launch senken, www/non-www und HTTP zu HTTPS einheitlich weiterleiten, alte Plattform erst kündigen, wenn alle Redirects nachweislich greifen

Die Reihenfolge ist nicht beliebig. Punkte 1, 2 und 5 erledigst du vor dem ersten Build, weil das Content-Modell in Sanity davon abhängt. Punkte 3, 4, 6 und 7 laufen während der Entwicklung, jeweils pro Vorlage. Punkt 8 gehört auf den Launch-Tag, mit der Redirect-Map als Testliste: Jede alte URL wird nach dem DNS-Wechsel einmal aufgerufen, bevor jemand die alte Plattform kündigt.

Wie das in der Praxis aussieht, zeigt unsere eigene Website. in-sync.io lief bis 2026 auf Wix und läuft seit Juni 2026 auf Next.js, Sanity und Vercel. Wir hatten wenig zu verlieren, die alte Wix-Website rankte für praktisch nichts. Trotzdem sind wir die Liste vollständig durchgegangen: Vorher-Crawl, Redirect-Map für jede alte Wix-URL, alle Bilder neu in Sanity, DE und EN mit hreflang, vollständiges Server-Rendering, Sitemap und llms.txt aus dem Code, Einreichung in Search Console und Bing plus IndexNow. Heute kommen 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten aus einem Content-Modell. Die Rankings bauen sich seit Juni auf. Auf Wix hätten wir dasselbe Content-Modell nicht mit derselben Kontrolle über Rendering, Schema und Sitemap gebaut.

Wenn du vor derselben Entscheidung stehst: Den Weg von Webflow zu Next.js beschreiben wir Schritt für Schritt in Webflow zu Next.js migrieren, die Abwägung davor in Webflow vs. Next.js. Was ein Headless CMS ist und warum die Inhalte beim Wechsel in eine strukturierte Content-Datenbank gehören, steht im eigenen Artikel. Die Einordnung aller drei Stufen findest du im Vergleich Baukasten, Webflow oder Next.js. Und wenn du den Umzug nicht selbst verantworten willst: Als Website-Relaunch-Agentur übernehmen wir Crawl, Redirect-Map, Migration und Monitoring als ein Paket.

Welche Tools brauchst du für einen Relaunch?

Du brauchst kein teures Setup, aber ein paar Werkzeuge sind unverzichtbar. Der Crawler ist das wichtigste: Screaming Frog gilt als Standard, um alle URLs, Weiterleitungen, Status-Codes, Canonicals und Meta-Daten der alten und der neuen Seite auszulesen. Die Google Search Console ist kostenlos und Pflicht, um Indexierung, Abdeckung, Crawling-Fehler und Traffic-Veränderungen zu beobachten und die neue Sitemap einzureichen. Bei einem Domainwechsel läuft die Adressänderung ebenfalls über die GSC.

Für die Rankings- und Backlink-Snapshots vor dem Relaunch nutzt du ein SEO-Tool wie Ahrefs, Sistrix oder Semrush. Damit erkennst du, welche Seiten wirklich Traffic und Backlinks tragen und deshalb im Redirect-Mapping oberste Priorität haben. Diese Kombination aus Crawler, Search Console und einem Sichtbarkeits-Tool deckt den kompletten Prozess von der Bestandsaufnahme bis zum Monitoring ab.

Wie lange dauert die Erholung nach dem Relaunch?

Selbst bei einem perfekt umgesetzten Relaunch sind kurzfristige Schwankungen normal. Google muss die neue Seite komplett neu crawlen, indexieren und bewerten. Verfall also nicht in Panik, wenn die Rankings in den ersten Tagen zittern. Das gehört zur Re-Evaluierung dazu.

Als Orientierung: Bei kleineren Relaunches mit gleicher URL-Struktur beruhigt sich die Sichtbarkeit oft binnen zwei bis vier Wochen. Bei größeren Umbauten mit geänderten URLs oder einem Domainwechsel kann die vollständige Neubewertung durch Google mehrere Wochen bis rund drei Monate dauern. Je mehr sich geändert hat, desto länger braucht der Algorithmus. Wichtig ist die Richtung: Wenn dein Relaunch die Nutzererfahrung, die Ladezeit und die Relevanz wirklich verbessert hat, kann die Re-Evaluierung am Ende sogar zu besseren Rankings führen als vorher. Genau das ist das Ziel.

Relaunch als Chance: SEO, Performance und KI-Sichtbarkeit

Der beste Relaunch verteidigt nicht nur den Status quo, er hebt ihn. Weil ohnehin alles auf den Tisch kommt, ist der Relaunch der ideale Moment, um Altlasten zu beheben: eine sauberere Seitenstruktur, bessere interne Verlinkung, schnellere Ladezeiten und starke Core Web Vitals, konsequente mobile Optimierung. Alles Dinge, die auf der alten Seite oft nur schwer nachzurüsten waren.

2026 kommt ein Punkt dazu, den die meisten Relaunch-Ratgeber noch überspringen: die Sichtbarkeit in KI-Antworten. Wer beim Relaunch auf ein modernes CMS oder ein Framework wechselt, das Inhalte erst per JavaScript im Browser zusammenbaut, riskiert, dass KI-Crawler wie GPTBot oder ClaudeBot eine leere Seite sehen, denn viele rendern kein JavaScript. Serverseitiges Rendering (SSR) ist damit kein Nice-to-have mehr, sondern gehört in die technischen Anforderungen an die neue Seite. Ein Relaunch, der das mitdenkt, macht deine Inhalte gleichzeitig für Google und für die generativen Engines lesbar. Mehr dazu in unserem Artikel zur Generative Engine Optimization.

Genau so gehen wir Website-Relaunches an: Wir sichern zuerst deine bestehende Sichtbarkeit über sauberes Redirect-Mapping und Monitoring und legen die neue Seite gleichzeitig technisch so an, dass sie schneller, crawlbarer und KI-lesbarer ist als die alte. Der Relaunch wird so nicht zum Risiko, sondern zum Hebel. Was am Ende dabei herauskommen kann, zeigt der Relaunch von Silencio, den wir im Presse-Beitrag zur Silencio-Funding-Runde beschreiben.

Häufige Fragen

Nicht zwangsläufig. Rankings gehen nur verloren, wenn SEO zu spät eingeplant wird, etwa geänderte URLs ohne 301-Weiterleitung, gelöschte rankende Seiten oder ein versehentliches noindex. Mit sauberem Redirect-Mapping, Staging und Monitoring überträgst du deine Sichtbarkeit vollständig auf die neue Seite und kannst sie sogar verbessern.

Das Redirect-Mapping mit 301-Weiterleitungen. Jede sich ändernde oder wegfallende URL muss per permanenter 301-Weiterleitung auf die thematisch passendste neue URL zeigen. So findet Google deine Inhalte wieder und überträgt die Ranking-Signale. Grundlage ist ein vollständiger Crawl der alten Seite vor dem Launch.

Immer 301. Eine 301-Weiterleitung ist permanent und überträgt die Ranking-Signale auf die neue URL. Eine 302 oder 307 ist temporär, Google geht dann davon aus, dass die Änderung nicht bleibt, und leitet die Signale nur zögerlich oder gar nicht weiter. Beim Relaunch haben 302 und 307 deshalb nichts verloren.

Bei kleineren Relaunches mit gleicher URL-Struktur oft zwei bis vier Wochen. Bei größeren Umbauten mit geänderten URLs oder Domainwechsel kann die vollständige Neubewertung durch Google mehrere Wochen bis rund drei Monate dauern. Je mehr sich geändert hat, desto länger. Panik in den ersten Tagen ist normal, aber unbegründet.

Eine Staging-Umgebung ist eine passwortgeschützte Testversion deiner neuen Seite, die den Googlebot aussperrt. Dort baust und testest du in Ruhe, ohne dass eine unfertige Version indexiert wird oder Besucher darauf landen. Nie live an der aktiven Seite basteln, das ist einer der häufigsten und teuersten Relaunch-Fehler.

Nur wenn es einen echten Grund gibt. Jede URL-Änderung erhöht das Risiko und macht Weiterleitungen nötig. Wenn deine bestehenden URLs sauber und sprechend sind, lass sie so, wie sie sind. Musst du sie ändern, plane die 301-Weiterleitungen besonders sorgfältig und leite thematisch passend weiter.

Nein, wenn die Zuordnung auf allen vier Ebenen stimmt: Seiten-URLs, Bild-URLs, Rendering und Text in Interaktionen. Webflow-Slugs kommen per CSV- oder API-Export in die Redirect-Map, Bilder ziehen vom Webflow-CDN nach Sanity um, jede Vorlage wird im Server-HTML geprüft. Ein Kunde mit fünfsprachiger Website (Yarowa) hat den Webflow-Export 1:1 nach Astro portiert, das Design blieb identisch.

Für eine Marketing-Website mit 10-30 Seiten typischerweise 3-6 Wochen. Den Zeitplan treiben vier Dinge: Seitenzahl, Umfang der CMS-Inhalte (Blog, Cases, Sprachen), Anzahl der nachzubauenden Interaktionen und ob das Design aus Figma oder aus dem alten Export kommt. Redirect-Map und Vorher-Crawl entstehen vor dem ersten Build und werden danach parallel zur Entwicklung gepflegt. Der DNS-Wechsel selbst ist eine Sache von Stunden, wenn die TTL (die Zeit, die Zwischenspeicher einen DNS-Eintrag behalten) vorher gesenkt wurde.

20-Minuten Gespräch, ohne Verkaufsdruck. Ihr beschreibt, was ihr vorhabt und wir sagen, ob und wie wir helfen können.

Max Herzer

Max Herzer

Consultant & Business Development