Ich habe Hunderte von Website-Redesign-RFPs im Laufe der Jahre überprüft. Die meisten sind schrecklich. Sie sind besessen von Farbpaletten und Hero-Image-Animationen und ignorieren völlig das, was ihren organischen Traffic ruiniert: Migrationsspektrum und SEO-Erhaltung. Das Ergebnis? Eine glänzende neue Website, die innerhalb von Wochen nach dem Launch 30-60% ihres Suchverkehrs verliert.

Das ist keine Theorie. Wir wurden mehrfach angeheuert, um Redesigns zu reparieren, die schiefgegangen sind, weil das ursprüngliche RFP keine einzige Zeile über Redirect-Mapping, URL-Struktur-Erhaltung oder Core Web Vitals-Ziele enthielt. Ein Kunde verlor 2,3 Millionen Dollar an jährlichen organischen Einnahmen, weil ihre vorherige Agentur SEO als Nachgedanken behandelte.

Wenn Sie bereits wissen, dass Sie Hilfe benötigen und vorspulen möchten, reichen Sie Ihr RFP ein und wir werden es mit SEO-zentriertem Fokus überprüfen.

Hier ist die RFP-Vorlage, die ich mir wünsche, dass jede Organisation bei der Planung eines Website-Redesigns 2026 verwenden würde. Sie basiert auf echten Projekten, echten Fehlern und echten Wiederherstellungen.

Inhaltsverzeichnis

Warum die meisten Redesign-RFPs bei SEO scheitern

Das typische Redesign-RFP liest sich wie eine Wunschliste für eine Designagentur. Es wird Seiten über Brand-Guidelines, Stakeholder-Approval-Workflows und Mobile-Responsiveness haben. Alles wichtig. Aber SEO-Erhaltung? Vielleicht ein Aufzählungspunkt, der besagt „Erhaltung aktueller Suchplatzierungen" mit null Spezifikationen, wie das funktionieren soll.

Hier ist, was falsch läuft:

  • Keine Baseline-Audit-Anforderung. Sie können nicht bewahren, was Sie nicht gemessen haben. Wenn Ihr RFP keinen Pre-Migration-SEO-Audit erforderlich macht, fliegen Sie blind.
  • URL-Struktur wird als Design-Entscheidung behandelt. Informationsarchitekten ändern URLs, um der neuen Navigation zu entsprechen, ohne zu bemerken, dass sie Tausende von indexierten Seiten zerstören.
  • Redirect-Mapping ist ein Nachgedanke. Es wird in die letzten zwei Wochen vor dem Launch gequetscht, durchgeführt von einem Junior-Developer mit einer Tabelle.
  • Kein Post-Launch-Überwachungsplan. Die Agentur startet, feiert und geht weiter. Währenddessen sinken Ihre Platzierungen ab.

Eine 2025-Studie von Ahrefs ergab, dass 74% der Websites, die ein Major-Redesign durchliefen, signifikanten organischen Traffic-Verlust erlebten, wobei die durchschnittliche Wiederherstellungszeit 6-12 Monate betrug. Für Websites, die detaillierte SEO-Migrationsspezifikationen in ihrem RFP enthielten, sank diese Zahl auf 21%.

Der Unterschied ist kein Glück. Es ist Planung.

Die vollständige RFP-Vorlagenstruktur

Hier ist ein Überblick über das, was ein ordnungsgemäßes Redesign-RFP enthalten sollte, wenn die Bewährung der SEO eine Priorität ist:

Abschnitt Zweck Typische Seitenzahl
Projektübersicht Geschäftskontext, Ziele, KPIs 2-3 Seiten
Technisches Migrationsspektrum Plattform, Hosting, Infrastruktur 3-5 Seiten
Anforderungen zur SEO-Erhaltung Redirects, Schema, Indexierung 4-6 Seiten
Content-Migrationsspezifikationen Inhaltstypen, Taxonomie, Metadaten 3-4 Seiten
Performance-Ziele Core Web Vitals, Ladezeiten 2-3 Seiten
Kriteria zur Anbieter-Evaluierung Scoring-Rubrik, Referenzen 2-3 Seiten
Zeitplan & Akzeptanz Meilensteine, QA-Kriterien 2-3 Seiten
Gesamt 18-27 Seiten

Ja, es ist mehr als die meisten Organisationen schreiben. Das ist der Sinn. Jede Seite, die Sie hier überspringen, kostet Sie Monate an Traffic-Wiederherstellung später.

Abschnitt 1: Projektübersicht und geschäftlicher Kontext

Hier wird die Bühne bereitet. Beschreiben Sie nicht nur, was Sie wollen. Erklären Sie warum Sie ein Redesign durchführen und was Erfolg in messbaren Begriffen ist.

Was Sie einbeziehen sollten

## 1. Projektübersicht

### 1.1 Organisationaler Hintergrund
- Unternehmensbeschreibung, Branche, Zielgruppe
- Aktuelle Website-URL und Technologie-Stack
- Jährlicher organischer Traffic (Sitzungen, Nutzer, Umsatz-Zuordnung)

### 1.2 Redesign-Ziele (nach Priorität geordnet)
1. [z.B. Konversionsrate von organischem Traffic um 25% verbessern]
2. [z.B. Seitenladezeit auf unter 2 Sekunden reduzieren]
3. [z.B. Von WordPress zu Headless-CMS-Architektur migrieren]
4. [z.B. 95%+ des aktuellen organischen Suchverkehrs bewahren]

### 1.3 Erfolgskennzahlen
- Organischer Traffic innerhalb von 90 Tagen nach dem Launch: ≥95% der Baseline vor dem Launch
- Core Web Vitals: Alle Seiten bestehen auf Mobilgeräten und Desktop
- Indexierte Seiten: 100% der Zielseiten innerhalb von 60 Tagen indexiert
- Konversionsrate: ≥ aktuelle Baseline innerhalb von 90 Tagen

### 1.4 Budget-Bereich
- Gesamtes Projektbudget: $XX.000 - $XX.000
- Laufendes Wartungsbudget (monatlich): $X.000 - $X.000

Das Kritische hier: Setzen Sie diese Metrik zur Erhaltung des organischen Traffic genau in die Ziele. Machen Sie es zu einer vertraglichen Verpflichtung, nicht zu einem schönen Extra. Wenn ein Anbieter Ihr RFP liest und SEO nicht bis Seite 15 sieht, werden sie das Projekt entsprechend staffieren -- ohne SEO-Expertise.

Abschnitt 2: Technisches Migrationsspektrum

Dieser Abschnitt definiert die Grenzen dessen, was sich ändert. Seien Sie explizit über den aktuellen Zustand und den gewünschten Endzustand.

Anforderungen an Plattform und Architektur

## 2. Technisches Migrationsspektrum

### 2.1 Aktueller Zustand
- CMS: [z.B. WordPress 6.x mit WooCommerce]
- Hosting: [z.B. WP Engine, Growth-Plan]
- CDN: [z.B. Cloudflare Pro]
- Gesamte Seiten: [z.B. 4.200 indexierte Seiten pro Google Search Console]
- Gesamt-URLs (einschließlich Parameter): [z.B. ~12.000]
- Drittanbieter-Integrationen: [alles auflisten]

### 2.2 Gewünschter Endzustand
- CMS: [z.B. Headless CMS (Sanity, Contentful oder gleichwertig)]
- Frontend: [z.B. Next.js oder Astro mit SSR/SSG]
- Hosting: [z.B. Vercel, Netlify oder AWS]
- CDN: [z.B. Vercel Edge Network oder Cloudflare]

### 2.3 Migrationstyp
- [ ] Gleiche Domain, gleiche Plattform (nur optisches Redesign)
- [ ] Gleiche Domain, neue Plattform (Re-Plattform)
- [ ] Domain-Wechsel + neue Plattform (höchstes Risiko)
- [ ] Subdomain-Konsolidierung

Wenn Sie einen Wechsel zu Headless-Architektur in Betracht ziehen -- was zunehmend üblich ist für Performance-fokussierte Redesigns -- wollen Sie einen Anbieter mit Erfahrung in dieser Übergang. Wir haben ausführlich über unseren Ansatz zu Headless-CMS-Entwicklung und den spezifischen SEO-Überlegungen geschrieben.

Infrastruktur-Spezifikationen

Fügen Sie Server-Side-Rendering-Anforderungen, Edge-Caching-Strategie und wie dynamische Inhalte behandelt werden, ein. Eine Headless-Einrichtung mit einem Framework wie Next.js oder Astro kann Core Web Vitals drastisch verbessern, aber nur wenn die Rendering-Strategie richtig ist.

Abschnitt 3: Anforderungen zur SEO-Erhaltung

Dies ist das Herzstück des RFP. Seien Sie hier nicht vage. Erklären Sie genau, was Sie erwarten.

3.1 Pre-Migration-SEO-Audit

### 3.1 Pre-Migration-Audit-Anforderungen

Der ausgewählte Anbieter muss vor Beginn jeglicher Entwicklung 
Folgendes abschließen und liefern:

1. **Vollständiger Crawl der vorhandenen Website** mit Screaming Frog, Sitebulb 
   oder gleichwertig (Mindestkapazität: 50.000 URLs)
2. **Inventar der Top-Performance-Seiten**: Alle Seiten, die organischen 
   Traffic generieren (Mindestschwelle: 10 Sitzungen/Monat in den letzten 12 Monaten)
3. **Backlink-Profil-Export**: Alle Seiten mit externen Backlinks 
   (Ahrefs, Semrush oder Majestic)
4. **Aktuelle Ranking-Positionen**: Ziel-Keywords mit aktuellen SERP-Positionen 
   (Mindestens Top 100)
5. **Technical-SEO-Baseline**: Crawl-Fehler, verwaiste Seiten, Canonical-Probleme, 
   hreflang-Tags, Structured-Data-Inventar
6. **Karte der internen Linking-Struktur**: Visualisierung der aktuellen 
   Verteilung des internen Link-Equity

3.2 Anforderungen an Redirect-Mapping

Wir sind auf einen Fortune-500-Kunden gestoßen. Ihre vorherige Agentur hatte Wildcard-Redirects verwendet, um einen ganzen /resources/-Ordner auf eine einzelne Landing Page zu mappen. Sah ordentlich in der Tabelle aus. In der Praxis tötete es 340 indexierte Seiten, die 18.000 Dollar pro Monat in organischem zuschreibbaren Umsatz generierten. Jede dieser URLs brauchte einen 1:1-Redirect zum tatsächlichen Gegenstück auf der neuen Website.

Seien Sie rücksichtslos spezifisch:

### 3.2 Redirect-Mapping

1. **1:1-Redirect-Map** für jede URL, die einen 200-Statuscode 
   auf der aktuellen Website zurückgibt
2. Redirect-Map muss als CSV mit Spalten bereitgestellt werden:
   - Source-URL (aktuell)
   - Ziel-URL (neu)
   - HTTP-Statuscode (301 oder 308)
   - Seitentyp (Produkt, Blog, Kategorie, usw.)
   - Monatliche organische Sitzungen (letzte 12 Monate)
   - Anzahl der verweisenden Domains
3. **Keine Redirect-Ketten**: Maximal einen Hop von alter zu neuer URL
4. **Keine Wildcard-Redirects** ohne explizite Genehmigung. Jeder Pattern-Redirect 
   muss mit Beispiel-URLs dokumentiert werden.
5. Redirect-Map muss **in Staging mit automatisierter Tooling getestet** 
   werden, bevor die Produktionsbereitstellung erfolgt
6. Alle Redirects müssen auf der **Server-/Edge-Ebene implementiert** werden, 
   nicht über JavaScript

3.3 On-Page-SEO-Anforderungen

### 3.3 On-Page-SEO-Erhaltung

1. **Title-Tags**: Migrieren Sie vorhandene Title-Tags für alle indexierten Seiten. 
   Alle Änderungen müssen dokumentiert und genehmigt werden.
2. **Meta-Beschreibungen**: Migrieren Sie vorhandene Meta-Beschreibungen. 
   CMS muss Anpassungen pro Seite unterstützen.
3. **H1-Tags**: Ein H1 pro Seite, passend zum Ziel-Keyword-Intent
4. **Schema-Markup**: Migrieren Sie alle vorhandenen strukturierten Daten. 
   Neue Seiten müssen angemessene Schema-Typen enthalten.
   Mindestens: Organization, BreadcrumbList, Article/Product je nach Bedarf
5. **Open Graph und Twitter Cards**: Alle Seiten müssen vollständige 
   Social-Metadaten haben
6. **Canonical-Tags**: Selbstverweisende Canonicals auf allen indexierbaren Seiten. 
   Anbieter muss die Canonical-Strategie für gefilterte/paginierte Inhalte dokumentieren.
7. **XML-Sitemaps**: Automatisch generiert, nach Inhaltstyp geteilt, 
   maximal 50.000 URLs pro Datei, eingereicht bei Google Search Console 
   innerhalb von 24 Stunden nach dem Launch
8. **Robots.txt**: Muss vor dem Launch überprüft und genehmigt werden. 
   Keine versehentlichen noindex/nofollow auf Produktion.

Ich kann diesen letzten Punkt nicht genug betonen. Ich persönlich habe drei Major-Launches gesehen, bei denen jemand einen noindex-Meta-Tag aus Staging im Produktions-Build hinterlassen hatte. Eine Website verlor ihren gesamten Google-Index für 11 Tage.

3.4 International SEO (Falls zutreffend)

Wenn Sie eine mehrsprachige oder Multi-Region-Website haben, fügen Sie spezifische Anforderungen für die hreflang-Implementierung, ccTLD-vs.-Subdirectory-Strategie und wie das neue CMS locale-spezifische Inhalte handhaben wird.

Abschnitt 4: Content-Migrationsspezifikationen

Inventar der Inhaltstypen

Erstellen Sie eine Tabelle aller Inhaltstypen und ihres Migrationsstatus:

Inhaltstyp Aktuelle Anzahl Migrationsaktion Priorität
Blogbeiträge 847 Alle mit organischem Traffic >0 migrieren Hoch
Produktseiten 234 Alle migrieren, Template redesignen Hoch
Kategorieseiten 45 Migrieren, wo angegeben konsolidieren Hoch
Landing Pages 32 Migrieren mit aktualisierten Designs Mittel
Hilfe-/FAQ-Seiten 120 Auditor und konsolidieren Mittel
Pressemitteilungen (vor 2023) 200+ 301 auf relevante Kategorieseite Niedrig
Autorenseiten 15 Mit aktualisierten Bios migrieren Niedrig

Taxonomie und URL-Struktur

### 4.2 URL-Struktur-Regeln

1. **Bevorzugte URL-Struktur**: Wo möglich vorhandene Struktur beibehalten
   - Blog: /blog/[slug]
   - Produkte: /products/[category]/[slug]
   - Seiten: /[slug]
2. **URL-Konventionen**:
   - Nur Kleinbuchstaben
   - Bindestriche als Trennzeichen (keine Unterstriche)
   - Keine nachgestellten Schrägstriche (oder immer nachgestellte Schrägstriche -- wählen Sie eins)
   - Keine Dateierweiterungen (.html, .php)
   - Keine Session-IDs oder Tracking-Parameter in indexierbaren URLs
3. **Alle Änderungen der URL-Struktur** müssen von einer aktualisierten 
   Redirect-Map begleitet und von [designiertem Stakeholder] genehmigt werden

Abschnitt 5: Performance- und Core Web Vitals-Ziele

Googles Page-Experience-Signale bleiben 2026 wichtig. Ihr RFP sollte spezifische, messbare Performance-Ziele setzen:

Metrik Ziel (Mobilgerät) Ziel (Desktop) Messtool
Largest Contentful Paint (LCP) ≤ 2,0s ≤ 1,5s CrUX / PageSpeed Insights
Interaction to Next Paint (INP) ≤ 150ms ≤ 100ms CrUX / PageSpeed Insights
Cumulative Layout Shift (CLS) ≤ 0,05 ≤ 0,05 CrUX / PageSpeed Insights
Time to First Byte (TTFB) ≤ 400ms ≤ 200ms WebPageTest
Gesamtgewicht der Seite ≤ 1,5MB ≤ 2,0MB Lighthouse
Lighthouse Performance Score ≥ 90 ≥ 95 Lighthouse CI 
### 5.2 Performance-Test-Anforderungen

1. Lighthouse CI muss in die Deployment-Pipeline integriert werden 
   mit minimalen Score-Schwellwerten als Gate-Checks
2. Real User Monitoring (RUM) muss vor dem Launch implementiert werden 
   (z.B. Vercel Analytics, SpeedCurve oder gleichwertig)
3. Performance-Budget muss dokumentiert und durchgesetzt werden für:
   - JavaScript-Bundle-Größe (gesamt und pro Route)
   - Bild-Optimierungs-Pipeline (WebP/AVIF mit Fallbacks)
   - Font-Loading-Strategie (Preload, font-display: swap)
4. Anbieter muss Performance-Vergleichsbericht bereitstellen: 
   aktuelle Website vs. neue Website über 20 repräsentative Seiten

Moderne Frameworks machen diese Ziele erreichbar. Wir erreichen routinemäßig sub-1s LCP auf Astro-Builds und sub-1,5s auf Next.js-Projekten mit ordnungsgemäßer Optimierung. Aber Sie müssen diese Erwartungen im RFP setzen, oder Sie erhalten, was auch immer der Standard des Anbieters ist.

Abschnitt 6: Kriteria zur Anbieter-Evaluierung

Hier ist eine Scoring-Rubrik, die Sie anpassen können:

Kriterium Gewichtung Scoring (1-5)
SEO-Migration-Erfahrung (Case Studies mit Traffic-Daten) 25%
Technischer Architektur-Ansatz 20%
Track Record bei Performance-Optimierung 15%
Content-Migration-Methodik 15%
Teamzusammensetzung (dedizierte SEO-Ressource?) 10%
Zeitplan und Meilenstein-Realismus 10%
Preis-Transparenz 5%

Beachten Sie, dass die SEO-Migration-Erfahrung das höchste Gewicht trägt. Das ist beabsichtigt. Eine schöne Website, die Traffic verliert, ist eine Verbindlichkeit, keine Anlage.

Fragen, die Sie Anbieter-Referenzen stellen sollten

  1. "Welcher Prozentsatz des organischen Traffic wurde 90 Tage nach dem Launch bewahrt?"
  2. "Gab es unerwartete Ranking-Rückgänge? Wie wurden sie behandelt?"
  3. "Wie wurde der Redirect-Mapping-Prozess verwaltet?"
  4. "Hat der Anbieter Post-Launch-SEO-Überwachung bereitgestellt?"

Wenn ein Anbieter nicht mindestens zwei Referenzen bereitstellen kann, in denen er diese Fragen mit spezifischen Zahlen beantworten kann, ist das ein rotes Flaggen.

Wenn Sie gerade aktiv Ihr RFP schreiben und fachkundige Augen darauf werfen möchten, bevor es rausgeht, senden Sie uns Ihr RFP und wir werden Ihnen ehrlich Feedback geben, was fehlt.

Abschnitt 7: Zeitplan, Meilensteine und Akzeptanzkriterien

Ein realistisches Redesign mit ordnungsgemäßer SEO-Migration dauert 12-20 Wochen für eine mittelgroße Website (1.000-10.000 Seiten). Jeder, der weniger verspricht, schneidet irgendwo Ecken ab.

### 7.1 Meilenstein-Zeitplan

| Phase | Dauer | Lieferungen | Akzeptanz-Gate |
|-------|----------|-------------|------------------|
| Discovery & Audit | 2-3 Wochen | SEO-Audit, Content-Inventar, technische Bewertung | Stakeholder-Freigabe |
| Strategie & Architektur | 2-3 Wochen | IA, URL-Mapping, Redirect-Plan, Wireframes | SEO-Überprüfung + Genehmigung |
| Design | 3-4 Wochen | Design-System, Key-Page-Templates | Brand + UX-Genehmigung |
| Entwicklung | 4-6 Wochen | Funktionale Staging-Website | Technical QA bestanden |
| Content-Migration | 2-3 Wochen | Alle Inhalte zu Staging migriert | Content + SEO QA |
| Pre-Launch-QA | 1-2 Wochen | Vollständiger Redirect-Test, Crawl-Vergleich, Performance-Audit | SEO-Freigabe erforderlich |
| Launch | 1 Tag | DNS-Cutover, Redirect-Aktivierung | War-Room-Überwachung |
| Post-Launch-Überwachung | 4-8 Wochen | Wöchentliche Traffic-Reports, Crawl-Überwachung, Index-Coverage | 90-Tage-Traffic-Vergleich |

### 7.2 Pre-Launch-Checkliste (Muss bestanden werden)
- [ ] Alle 301-Redirects getestet und verifiziert (automatisiert)
- [ ] XML-Sitemap generiert und validiert
- [ ] Robots.txt überprüft (keine versehentlichen Blöcke)
- [ ] Alle Seiten rendern korrekt ohne JavaScript (für Crawler)
- [ ] Schema-Markup validiert über Google Rich Results Test
- [ ] Canonical-Tags auf allen indexierbaren Seiten verifiziert
- [ ] Core Web Vitals auf repräsentativen Seiten bestanden
- [ ] Google Search Console-Eigenschaft für neue Website verifiziert
- [ ] Analytics-Tracking auf allen Seiten-Templates verifiziert
- [ ] Keine noindex-Tags auf Produktionsseiten

Diese letzte Checkliste sollte eine vertragliche Anforderung sein. Der Launch erfolgt erst, wenn jedes Kästchen angekreuzt ist.

Häufige RFP-Fehler, die organischen Traffic zerstören

Nach Jahren, dies zu tun, sind hier die Muster, die ich wiederholt sehe:

1. "Wir werden Redirects nach dem Launch handeln." Nein. Redirects müssen zum Zeitpunkt des Launch vorhanden sein. Jede Stunde ohne sie entdeckt Google 404er und entwerten Ihre Seiten.

2. "Wir ändern nur das Design, nicht den Inhalt." Das Ändern von Templates ändert, wie Google Ihren Inhalt sieht. Unterschiedliche Heading-Strukturen, veränderbare interne Links, neues JavaScript-Rendering -- es beeinflusst alles Rankings.

3. "Unser Entwickler kennt SEO." Vielleicht. Aber SEO zu kennen und eine Website-Migration ausgeführt zu haben sind sehr unterschiedliche Dinge. Fragen Sie nach spezifischer Migration-Erfahrung.

4. "Wir werden einfach alles zur Homepage umleiten." Das ist funktional dasselbe wie ein 404 in Googles Augen. Es ist ein Soft-404. Tun Sie das nicht.

5. "Wir wollen unsere URL-Struktur bereinigen, während wir hier sind." Dies erhöht das Migrationsrisiko erheblich. Wenn Sie URLs ändern müssen, okay. Aber verstehen Sie, dass Sie wochenlange zusätzliche Redirect-Mapping-Arbeit hinzufügen und höheres Risiko akzeptieren.

Technology Stack-Überlegungen für 2026

Die Technologie, die Sie wählen, beeinflusst die SEO-Migration-Komplexität direkt. Hier ist, was wir sehen:

Ansatz SEO-Vorteile SEO-Nachteile Best für
Next.js (App Router) SSR/SSG, großartig CWV, eingebaute Image-Optimierung Hydration kann INP beeinflussen, wenn falsch konfiguriert Dynamische Seiten, E-Commerce
Astro Fast-null JS standardmäßig, ausgezeichnetes CWV Kleineresystemfür komplexe Interaktivität Inhalts-schwere Seiten, Blogs
WordPress (Headless) Vertraut CMS, riesiges Plugin-Ökosystem Performance hängt stark vom Frontend ab Teams in WP-Workflows investiert
Webflow Visual-Builder, schnelle Launches Begrenzte SEO-Anpassung, Vendor Lock-in Marketing-Seiten mit kleinen Teams
Traditionelles WordPress Reife SEO-Tools (Yoast, Rank Math) Performance-Decke, Sicherheits-Overhead Budget-begrenzte Projekte

Wir haben gefunden, dass Headless-Architekturen mit Next.js oder Astro gekoppelt mit einem Headless CMS wie Sanity oder Contentful die beste Kombination von Editor-Erlebnis und SEO-Performance bieten. Aber die Migration von einem traditionellen CMS zu Headless erhöht die Komplexität, die Ihr RFP berücksichtigen muss.

Wenn Sie Anbieter für diese Art von Projekt evaluieren, sprechen wir immer gerne über die technischen Überlegungen. Sie können unsere Preisgestaltung überprüfen oder direkt Kontakt aufnehmen -- ohne Verpflichtung, wir genießen wirklich, darüber zu nerd-sein.

FAQ

Wie lange dauert ein typisches Website-Redesign mit SEO-Erhaltung?

Für eine mittelgroße Website (1.000-10.000 Seiten) rechnen Sie mit 12-20 Wochen vom Kickoff bis zum Launch, plus 8-12 Wochen Post-Launch-Überwachung. Seiten mit mehr als 10.000 Seiten oder komplexer E-Commerce-Funktionalität können 6-9 Monate dauern. Das Beschleunigen des Zeitplans ist der einzelne größte Vorhersage des Traffic-Verlusts.

Welcher Prozentsatz des organischen Traffic sollten wir erwarten, nach einem Redesign zu bewahren?

Mit ordnungsgemäßer Migrations-Planung sollten Sie 90-100% des organischen Traffic innerhalb von 90 Tagen bewahren. Eine gewisse vorübergehende Schwankung (ein 10-15% Rückgang) in den ersten 2-4 Wochen ist normal, da Google neu crawlt und neu indexiert. Wenn Sie einen 30%+ Rückgang sehen, der über 4 Wochen anhält, ist etwas bei der Migration falsch gelaufen.

Sollten wir SEO-Anforderungen im Haupt-RFP oder in einem separaten Dokument enthalten?

Beziehen Sie sie in das Haupt-RFP ein. Wenn SEO-Anforderungen in einem separaten Dokument leben, werden sie als optional behandelt. Anbieter müssen diese Anforderungen neben der Design- und Entwicklungsumfang sehen, damit sie entsprechend staff und Budget kalkulieren können.

Wie viel kostet ein Website-Redesign mit ordnungsgemäßer SEO-Migration?

Das Budget variiert stark, aber hier ist ein grober Leitfaden: Ein Redesign einer mittelgroßen Website mit ordnungsgemäßer SEO-Migration kostet normalerweise 50.000-200.000 Dollar für den initialen Build. Enterprise-Seiten können 500.000 Dollar überschreiten. Die SEO-Migration-Arbeit spezifisch (Auditing, Redirect-Mapping, QA, Überwachung) fügt ungefähr 15-25% zu den Gesamtprojektkosten hinzu. Das ist Geld gut investiert, wenn Sie den Revenue-Risiko betrachten.

Was ist das größte Risiko in einem Website-Redesign aus einer SEO-Perspektive?

Gebrochene oder fehlende Redirects. Vollständig. Jedes andere SEO-Problem -- fehlende Meta-Tags, geänderte Heading-Strukturen, langsamere Seitengeschwindigkeit -- kann Post-Launch mit verwaltbarem Impact behoben werden. Aber wenn Google Tausende von 404-Seiten crawlt, weil Redirects nicht vorhanden waren, verstärkt sich der Schaden schnell und die Wiederherstellung ist langsam.

Sollten wir Content-Änderungen während der Migration einfrieren?

Ja, implementieren Sie 2-3 Wochen vor dem Launch ein Content-Einfrieren. Jeder neue Inhalt, der während dieses Fensters veröffentlicht wird, muss manuell zu beiden, der alten und der neuen Website, hinzugefügt werden, was zusätzliche Arbeit und Fehlermöglichkeiten erzeugt. Planen Sie Ihren Editorial-Kalender um die Migrations-Timeline.

Wie überwachen wir SEO-Gesundheit nach dem Launch?

Richten Sie tägliche Überwachung für die ersten 30 Tage ein. Mindestens verfolgen: Google Search Console Index-Coverage-Report (achten Sie auf Spitzen in "Ausgeschlossenen" Seiten), Crawl-Statistiken (Crawl-Rate sollte nach dem Launch zunehmen, da Google Änderungen entdeckt), organischer Traffic vs. Baseline (vergleichen Sie denselben Wochentag, nicht sequenzielle Tage) und Ranking-Positionen für Ihre Top 50-100 Keywords. Tools wie ContentKing oder Lumar können Echtzeit-Überwachung automatisieren.

Können wir unseren Domainnamen während eines Redesigns ändern?

Sie können, aber verstehen Sie, dies ist die höchst-riskante Migrations-Szenario. Ein Domänenwechsel plus ein Redesign bedeutet, dass Google zwei Haupt-Signale gleichzeitig verarbeiten muss. Wenn möglich, trennen Sie die zwei: Redesign auf der vorhandenen Domain zunächst, stabilisieren Sie 3-6 Monate lang, dann migrieren Sie zur neuen Domain. Wenn Sie beide gleichzeitig tun müssen, fügen Sie mindestens 4-6 zusätzliche Wochen zum Zeitplan für zusätzliches QA und Überwachung hinzu.

Bereit anzufangen?

Wenn Sie ein Redesign am Horizont haben und nicht mit Ihrem organischen Traffic spielen möchten, erhalten Sie einen Vorschlag in 48 Stunden. Wir überprüfen Ihre Anforderungen und sagen Ihnen genau, wie ein migrationsicheres Redesign für Ihre Website aussieht.