SEO • REDESIGN
Ein Redesign kann UX, Conversion und technische Qualität verbessern. Es kann aber auch in einem einzigen Deployment jahrelang aufgebaute organische Signale entfernen, wenn URLs, Inhalte und interne Links ohne Plan verändert werden.
Kurzantwort: Was sollte man vor einem Redesign prüfen?
Vor einem Neuaufbau sollte man bestehende URLs inventarisieren, Seiten mit organischem Traffic und Backlinks markieren, Search-Console-Daten exportieren, gute URLs möglichst erhalten, ein Old→New-Mapping vorbereiten, permanente Redirects planen, alte und neue Inhalte vergleichen, Canonicals und interne Links prüfen, Staging schützen, Tracking und Formulare testen, die neue Website vor dem Launch crawlen und nach Veröffentlichung eng überwachen.
1. Liste aller bestehenden URLs erstellen
Nutze Crawl, XML-Sitemap, Search Console, Analytics, CMS und – wenn vorhanden – Serverdaten. Ziel ist eine möglichst vollständige URL-Inventur.
Warum reicht die Sitemap allein nicht?
Sie kann alte, verwaiste oder nicht mehr eingetragene URLs übersehen, die trotzdem Traffic oder Backlinks besitzen.
2. URLs mit bestehendem SEO-Wert markieren
Besonders wichtig sind Seiten mit Klicks, Impressionen, Rankings, Backlinks, Leads oder historischer Bedeutung.
Einfache Tabelle
Alte URL → Traffic → wichtige Queries → Backlinks → neue Ziel-URL → Redirect → Content-Aktion.
3. Google Search Console vor Änderungen prüfen
Exportiere Performance-Daten und notiere wichtige Landingpages und Suchanfragen.
Besonders wichtig
- Seiten mit vielen Impressionen
- Queries nahe Top 10
- starke lokale Signale
- Seiten mit fallender oder steigender Sichtbarkeit
- Indexierungsprobleme
4. Eine Seite nicht nur nach Klicks bewerten
Eine URL kann wenige Klicks haben, aber starke Backlinks, wichtige Markenrelevanz oder eine unterstützende Rolle im Funnel. Entscheidungen brauchen mehr als einen KPI.
5. Backlinks auf einzelne Seiten prüfen
Wenn eine alte URL verlinkt ist, sollte ihr Wert nicht durch 404 oder irrelevante Weiterleitung verloren gehen.
Was tun?
URL erhalten oder auf die semantisch passendste neue Seite dauerhaft weiterleiten.
6. Gute URLs behalten, wenn es keinen Grund zur Änderung gibt
Eine bereits funktionierende URL ist ein Asset.
URL nicht ändern, nur weil die neue „sauberer“ aussieht
Der ästhetische Gewinn ist selten größer als das Migrationsrisiko.
7. Old URL → New URL Mapping vorbereiten
Jede entfernte oder geänderte wichtige URL braucht eine Entscheidung.
Mapping sollte semantisch sein
Eine alte Leistungsseite gehört zur entsprechenden neuen Leistung, nicht pauschal zur Homepage.
8. Permanente Redirects für permanente Änderungen
Für dauerhaft verschobene Inhalte 301 beziehungsweise geeignete permanente Redirects nutzen.
9. Redirect-Ketten vermeiden
Alt A → Alt B → Neu C ist unnötig. Alte URLs sollten möglichst direkt zur finalen Ziel-URL führen.
Vor Launch
Bestehende Redirect-Regeln mit dem neuen Mapping konsolidieren.
10. Canonical Tags prüfen
Staging-Domains, alte URLs und kopierte Template-Canonicals sind häufige Fehlerquellen. Produktionsseiten sollten die gewünschte Hauptversion signalisieren.
11. Interne Verlinkung aktualisieren
Prüfe:
- Navigation
- Footer
- Breadcrumbs
- Contentlinks
- CTA
- Bildlinks
- strukturierte Daten
Interne Links sollten direkt auf neue finale URLs zeigen und nicht durch Redirects laufen.
12. Sitemap mit neuen Canonical-URLs aufbauen
Sie sollte indexierbare 200-URLs enthalten und nach Launch in Search Console verfügbar sein.
13. Staging: nicht nur auf noindex verlassen
Staging sollte nicht öffentlich crawlbar sein, wenn es sich vermeiden lässt.
Sicherer Ansatz
Authentifizierung beziehungsweise Zugriffsschutz plus noindex als zusätzliche Ebene.
Größtes Risiko
Staging-noindex wird auf Produktion übertragen und die neue Website bleibt unsichtbar.
14. Staging-robots.txt nicht auf Produktion übertragen
Ein Disallow: / ist im Development verständlich und im Live-System katastrophal.
15. Title Tags und H1 vor Migration vergleichen
Wenn gut rankende Seiten ihre klare Themenzuordnung verlieren, kann Sichtbarkeit leiden.
Beispiel
Eine konkrete H1 wie „Tworzenie stron internetowych“ sollte nicht durch eine rein kreative Aussage ersetzt werden, die das Thema nicht mehr erkennen lässt.
16. Alte und neue Inhalte vergleichen
Ein Redesign verändert oft Texte, Abschnittsreihenfolge und sichtbare Informationen.
Redesigns entfernen oft Content für visuelle Einfachheit
Weniger Text kann gut sein, wenn redundanter Inhalt verschwindet. Schlecht ist es, wenn wichtige Suchintentionen, FAQ oder Kaufargumente unbemerkt entfernt werden.
17. Content mit eigener SEO-Historie erhalten
Starke Artikel, Services oder Cases sollten nicht nur deshalb gelöscht werden, weil sie nicht in ein neues visuelles Raster passen.
Besserer Ansatz
Content prüfen, aktualisieren, neu strukturieren und in das neue Design integrieren.
18. Kannibalisierung vor der Reorganisation prüfen
Wenn mehrere alte Seiten dieselbe Intention bedienen, kann das Redesign eine Chance zur Zusammenführung sein – aber nur mit sauberem Mapping.
19. Nicht für jede Keywordvariation eine neue Seite bauen
Eine Hauptintention sollte eine Haupt-URL bekommen. Synonyme und nahe Varianten gehören häufig auf dieselbe Seite.
20. Strukturierte Daten prüfen
Organization, LocalBusiness, Product, Breadcrumbs, FAQ oder andere Markups müssen zur neuen sichtbaren Struktur passen.
21. Bilder und wichtige Assets prüfen
Wenn Bilder starke Backlinks oder Google-Images-Traffic besitzen, sollte ihre Migration berücksichtigt werden. Alt-Texte und Dateipfade nur ändern, wenn es sinnvoll ist.
22. Core Web Vitals vor und nach dem Launch messen
Eine neue Website sollte Performance nicht verschlechtern.
Nicht nur einen Lighthouse-Test auf einer URL vergleichen
Prüfe mehrere Templates und – wenn möglich – Felddaten.
23. Mobile: echte Journeys testen
Navigation, Formulare, CTA, Suche, Produktvarianten, Checkout und Kontaktwege auf realen kleinen Screens prüfen.
Wichtig für SEO und Conversion
Mobile Probleme können gleichzeitig Rankings, Nutzererfahrung und Leads beeinflussen.
24. Formulare und Conversions
Vor Launch
Echte Formularübermittlung, E-Mail-Zustellung, Spam-Schutz, Danke-Zustand und Conversion-Event testen.
25. GA4 und GTM
Tracking-Code, Consent und Events dürfen beim Template-Wechsel nicht verloren gehen oder doppelt feuern.
26. Search-Console-Verifizierung
Bei unveränderter Domain meist weiter gültig; bei Domain-/Property-Änderungen muss Zugang sauber vorbereitet werden.
27. Domainwechsel ist eine eigene Risikokategorie
Designwechsel + CMS-Wechsel + URL-Wechsel + Domainwechsel gleichzeitig erhöht Komplexität deutlich.
Beispiel
Wenn möglich, unnötige Variablen vermeiden und den Relaunch kontrollierbar halten.
28. Change of Address nur bei Domain- oder Subdomainwechsel
Dieses Search-Console-Werkzeug ist nicht für normale Pfadänderungen innerhalb derselben Domain gedacht.
29. Server auf erhöhtes Crawling nach Migration vorbereiten
Google und andere Bots können nach Launch viele alte und neue URLs abrufen. Hosting und Redirect-Logik sollten stabil bleiben.
30. Launch zu einem sinnvollen Zeitpunkt planen
Nicht kurz vor Feiertagen oder wenn niemand für Monitoring und Fehlerbehebung verfügbar ist.
31. Rollback vorbereiten – aber vorsichtig einsetzen
Backups und Deploy-Recovery sind wichtig. Ein Rollback nach bereits gestarteter Indexierung sollte trotzdem bewusst erfolgen, weil wiederholtes Hin und Her neue Signale erzeugt.
32. Staging vor Launch crawlen
Prüfe Statuscodes, Canonicals, noindex, interne Links, Titel, Überschriften, Sitemaps und Assets.
Dann mit Produktion vergleichen
So werden fehlende Seiten und strukturelle Unterschiede sichtbar.
33. Nach Launch erneut crawlen
Minimum nach Launch
- keine unerwarteten 404/5xx
- Redirects funktionieren
- Canonicals korrekt
- robots/noindex korrekt
- Sitemap erreichbar
- interne Links direkt
34. Search Console in den folgenden Wochen beobachten
Monitor:
- Indexierung
- Clicks/Impressions
- Landingpages
- Canonicals
- Core Web Vitals
- manuelle Maßnahmen/Sicherheitsprobleme
35. Redirects lange bestehen lassen
Alte URLs können noch lange über Links, Bookmarks oder Suchsysteme aufgerufen werden. Dauerhafte Redirects sollten nicht nach wenigen Wochen entfernt werden.
36. Wichtigste externe Links aktualisieren, wenn möglich
Bei wertvollen Partner- oder Profil-Links ist ein direkter Link auf die neue URL besser als dauerhafte Abhängigkeit vom Redirect.
37. Dinge nicht ändern, die nicht geändert werden müssen
Ein Relaunch ist kein Wettbewerb darum, möglichst viele Variablen gleichzeitig zu ersetzen.
38. Wann lohnt sich eine URL-Änderung trotz Risiko?
Wenn die alte Struktur dauerhaft problematisch, falsch, unskalierbar oder technisch nicht mehr tragfähig ist und der langfristige Nutzen die Migrationskosten übersteigt.
39. Was tun mit entfernten Seiten ohne Ersatz?
Wenn es kein relevantes Ersatzthema gibt, kann 404/410 korrekt sein. Nicht jede entfernte URL braucht einen Redirect auf die Homepage.
40. Auch ein Redesign ohne URL-Änderungen braucht SEO-Kontrolle
Content, Headings, interne Links, JavaScript, Canonicals, noindex und Performance können sich auch bei identischen URLs ändern.
41. Pre-Redesign-Checkliste
Daten
- ☐ GSC exportiert
- ☐ Analytics gesichert
- ☐ wichtige Conversions dokumentiert
URLs
- ☐ vollständige Inventur
- ☐ Old→New Mapping
- ☐ Redirects vorbereitet
Content
- ☐ starke Seiten identifiziert
- ☐ alte/neue Inhalte verglichen
- ☐ Metadata/H1 geprüft
Technik
- ☐ Canonicals
- ☐ robots/noindex
- ☐ Sitemap
- ☐ Structured Data
UX / Performance
- ☐ Mobile Journeys
- ☐ Core Web Vitals
- ☐ Forms/Checkout
Tracking
- ☐ GA4/GTM
- ☐ Consent
- ☐ Conversions
Launch
- ☐ Crawl vor Launch
- ☐ Crawl nach Launch
- ☐ Monitoring-Verantwortung
- ☐ Backup/Rollback
Aus der FreenetPro-Praxis: Ein Redesign beginnt mit einer Karte dessen, was nicht verloren gehen darf
Wir wollen weder „nichts ändern wegen SEO“ noch „alles ändern, weil es moderner aussieht“.
„Nichts ändern wegen SEO“
Kann schlechte Architektur dauerhaft konservieren.
„Alles ändern, weil es moderner wird“
Kann funktionierende URLs, Content und Suchsignale unnötig zerstören.
Die richtige Lösung ist selektiv: Erhalten, was funktioniert, und gezielt umbauen, was das Geschäft begrenzt.
FAQ
Kann ein Redesign SEO schaden?
Ja, wenn URLs, Content, Redirects oder technische Signale schlecht migriert werden.
Müssen URLs geändert werden?
Nein. Gute URLs sollten möglichst erhalten bleiben.
Was, wenn eine URL geändert werden muss?
Auf die passendste neue URL dauerhaft weiterleiten und interne Links aktualisieren.
Verliert ein 301 Redirect den gesamten SEO-Wert?
Nein. Saubere permanente Redirects sind der Standard für dauerhaft verschobene Inhalte, auch wenn Migrationen trotzdem sorgfältig überwacht werden sollten.
Kann man alle alten Seiten zur Homepage redirecten?
Nein, das ist meist semantisch falsch.
Wie lange sollten Redirects bleiben?
Langfristig, besonders bei historischen URLs mit Links und Traffic.
Muss die Sitemap aktualisiert werden?
Ja.
Reicht noindex zum Schutz von Staging?
Besser ist zusätzlicher Zugriffsschutz.
Brauche ich vor Redesign einen SEO-Audit?
Bei Websites mit organischer Sichtbarkeit ist mindestens eine Migrations- und Bestandsanalyse sehr empfehlenswert.
Soll Metadata einfach kopiert werden?
Nicht blind. Gute Metadata erhalten, schwache anhand neuer Intention und Content verbessern.
Wie schnell nach Launch SEO prüfen?
Sofort technisch und anschließend über mehrere Wochen in GSC und Analytics.
Die Kernregel
Ein Redesign darf modernisieren, aber es sollte nicht vergessen, welche URLs, Inhalte, Links und Daten bereits Wert besitzen. Erst dokumentieren, dann verändern.
