Website Relaunch SEO: Ranking-Risiken bei Migration senken

Soll aus der Bestandsaufnahme ein konkretes Entwicklungsprojekt werden, gehören Seitenumfang, Formulare, Systemwahl und Übergabe ebenfalls in die Abgrenzung. Diese Punkte sind auf der Leistungsseite Website erstellen lassen zusammengefasst.

Hinweis: Preis-, Kosten-, Stundensatz- und Prozentangaben ohne Quellenlink in diesem Beitrag sind eigene Einschätzungen oder Rechenbeispiele (Stand 09/2026) und ohne Gewähr.

Warum ein Website-Relaunch ohne 301-Redirects und E-E-A-T schnell Rankings kostet

Ohne Weiterleitung hat Google keinen direkten Hinweis, welche neue URL zur alten gehört. Google wertet serverseitige Weiterleitungen als Signal dafür, welche URL künftig im Index stehen soll. Fehlt dieses Signal, startet die neue URL ohne die Geschichte der alten: ohne die Verbindung zu externen Links und zu bestehenden Rankings. Dieser Artikel zeigt, welche technischen und inhaltlichen Fehler beim Relaunch am meisten Sichtbarkeit kosten, und wie Sie diese mit einer strukturierten SEO-Relaunch Checkliste vermeiden.

Praxis-Tipp: Mit dem kostenlosen Marketing- und SEO-Scan prüfen Sie live SEO-Grundlagen, Vertrauenssignale und KI-Sichtbarkeit Ihrer Website, ohne Anmeldung.

Das zentrale Problem: Viele Shop-Betreiber behandeln einen Relaunch als rein technisches Projekt. Neues Design. Neue Plattform. Neue URLs. Dabei hat jede URL eine Geschichte: externe Backlinks, interne Verlinkungen und bestehende Rankings. Wenn Sie URLs ohne 301-Redirect löschen oder umbenennen, geht diese Verbindung verloren. Bei einem Shop mit 50.000 EUR Monatsumsatz aus organischem Traffic wären 20 bis 30 % Rückgang 10.000 bis 15.000 EUR pro Monat (illustratives Rechenbeispiel, keine Messung). Wie lange es dauert, bis sich die Rankings stabilisieren, hängt von der Größe der Website und von den Fehlern ab. Google selbst nennt vorübergehende Schwankungen bei einem Umzug normal.

Aus der Praxis: Bei einem Next.js-Projekt läuft jede Veröffentlichung über ein Skript mit sechs geprüften Schritten: Paket packen und auf Vollständigkeit prüfen, hochladen und die Dateigröße vergleichen, eine Sicherung mit Zeitstempel anlegen, entpacken, auf dem Server bauen und zuletzt neun Seiten sowie drei Bilder auf den Status 200 testen. Schlägt Bau oder Dienststart fehl, stellt das Skript den vorherigen Stand automatisch wieder her. Übertragen auf einen Relaunch heißt das: Legen Sie vor der Umstellung einen Rückweg fest und prüfen Sie nach dem Go-live automatisiert, ob die wichtigsten URLs noch ausgeliefert werden, statt auf Stichproben zu hoffen.

Der zweite Punkt sind Vertrauenssignale, die unter dem Stichwort E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) zusammengefasst werden. Gemeint sind Inhalte, die zeigen, wer hinter einer Website steht und wie verlässlich sie ist: Impressum, Datenschutzerklärung, Autorenprofile, strukturierte Daten (Schema.org), HTTPS und gute Core Web Vitals. Diese Elemente gehen beim Relaunch gern verloren, weil sie nicht im Seitenbaum auftauchen. Entfernen Sie Autorenangaben, verschieben Sie das Impressum ohne Redirect oder migrieren Sie die strukturierten Daten nicht, fehlt später, was Nutzer und Prüfer erwarten. Das fällt selten am Launch-Tag auf, sondern erst bei der nächsten Kontrolle. Nehmen Sie diese Elemente deshalb ins URL- und Inhaltsinventar auf.

Welche Relaunch-Fehler bei robots.txt, noindex und Canonicals am häufigsten auftreten

Bei einem Website-Relaunch entscheiden oft Details in der Konfiguration über den Erhalt oder den Verlust der organischen Sichtbarkeit. Fehlerhafte Anweisungen in der robots.txt oder vergessene Meta-Tags aus der Staging-Umgebung können dazu führen, dass Google ganze Verzeichnisse aus dem Index entfernt. Die folgende Übersicht stellt die kritischsten Fehlerquellen, deren Auswirkungen und die notwendigen Korrekturmaßnahmen gegenüber, um eine saubere technische SEO Optimierung während der Migrationsphase zu gewährleisten.

Wichtig bei Sperren: Damit ein noindex wirkt, darf die Seite nicht per robots.txt blockiert sein. Sonst liest der Crawler die Anweisung nie, und die URL kann trotzdem in den Suchergebnissen erscheinen. Prüfen Sie deshalb mit der URL-Prüfung in der Search Console, was Googlebot tatsächlich sieht.

In welchen 7 Schritten Sie eine Website-Migration SEO-sicher vorbereiten

Eine Website-Migration ohne präzise Vorbereitung gleicht einer Operation am offenen Herzen ohne Anästhesie. Dieser Leitfaden ist Teil der Rubrik Webentwicklung auf webentwickler.pro und zeigt Ihnen, wie Sie technische Brüche vermeiden, die oft zu einem dauerhaften Sichtbarkeitsverlust führen, wenn die Struktur unsauber übertragen wird.

1. Erstellen Sie ein vollständiges URL-Inventar des aktuellen Systems. Bevor Sie eine einzige Zeile Code im neuen System schreiben, müssen Sie wissen, was Sie besitzen. Nutzen Sie Tools wie Screaming Frog, um alle indexierten URLs, Bilder und PDF-Dokumente zu erfassen. Vergessen Sie nicht, Daten aus der Google Search Console zu exportieren, um URLs zu identifizieren, die zwar Traffic generieren, aber intern kaum verlinkt sind.
2. Führen Sie ein technisches SEO-Audit der Ist-Situation durch. Dokumentieren Sie Ladezeiten (Core Web Vitals), Meta-Daten und die aktuelle interne Verlinkung. Halten Sie die Werte als Vergleichsbasis fest. Google nennt als gute Werte einen LCP (Largest Contentful Paint) von höchstens 2,5 Sekunden, einen INP von höchstens 200 Millisekunden und einen CLS von höchstens 0,1, gemessen am 75. Perzentil der Seitenaufrufe (Quelle: web.dev, Core Web Vitals, Stand 10/2024). Das neue System sollte nicht schlechter abschneiden als das alte.
3. Entwickeln Sie ein präzises Redirect-Mapping (301-Weiterleitungen). Dies ist der kritischste Schritt. Erstellen Sie eine Tabelle, in der jede alte URL einer neuen Ziel-URL zugeordnet wird, und setzen Sie sie als serverseitige Weiterleitung mit dem Statuscode 301 oder 308 um, die Google als dauerhaft behandelt. Vermeiden Sie Redirect-Ketten; lassen sie sich nicht vermeiden, rät Google im Idealfall zu bis zu drei, höchstens vier Weiterleitungen hintereinander. Leiten Sie nicht pauschal alle alten Seiten auf die Startseite um: Nutzer landen dann nicht beim gesuchten Inhalt, und die Zuordnung zwischen alter und neuer Seite geht verloren. Wo es keine passende neue Seite gibt, ist ein 404 oder 410 ehrlicher als ein Umweg. Ein Beispiel für nginx und Apache folgt im Abschnitt zum Redirect-Mapping.
4. Prüfen Sie die neue Informationsarchitektur auf einer Staging-Umgebung. Setzen Sie das neue System (JTL-Shop, Shopware oder Shopify) auf einer passwortgeschützten Subdomain auf. Schützen Sie die Testumgebung per Passwort (HTTP-Authentifizierung). Eine robots.txt mit „Disallow: /“ allein reicht nicht, weil eine per robots.txt gesperrte URL trotzdem in den Suchergebnissen erscheinen kann. Entfernen Sie Passwortschutz, Sperren und noindex-Angaben beim Livegang wieder. Hierbei hilft eine strukturierte SEO-Relaunch Checkliste, um keine technischen Details zu übersehen.
5. Konfigurieren Sie die n8n-Automatisierung für den Datentransfer. Anstatt Produktdaten manuell zu kopieren, sollten Sie Workflows nutzen, die Attribute, Kategorien und Kundenstämme sauber transformieren. Manuelle Fehler bei der Datenmigration bedeuten Nacharbeit an Artikelbeschreibungen oder fehlenden Varianten. Vergleichen Sie deshalb Stichproben und Stückzahlen zwischen Alt- und Neusystem.
6. Führen Sie eine umfassende Quality Assurance (QA) im Testsystem durch. Testen Sie alle Formulare, den Checkout-Prozess und vor allem die mobilen Ladezeiten.
7. Bereiten Sie die Search Console auf den Umzug vor. Validieren Sie die neue Domain (falls sich diese ändert), nutzen Sie die Adressänderung der Search Console nur bei einem Domainwechsel und halten Sie die neue XML-Sitemap mit den kanonischen neuen URLs bereit. Als Praxisregel (keine Vorgabe von Google) bietet sich ein Go-live unter der Woche am Vormittag an, damit Sie bei Problemen sofort reagieren können.

Wer seine technische Basis stabilisiert, findet in den Rubriken Web-Performance und SEO weitere Protokolle, um die Sichtbarkeit nach dem Wechsel gezielt zu steigern.

Relaunch-Checkliste: Was vor, beim und nach dem Livegang zu prüfen ist

Die Checkliste fasst die Schritte oben als Arbeitsliste zusammen. Sie ersetzt keine Prüfung im Einzelfall, hilft aber, nichts zu übersehen. Die Frist von einem Jahr für Weiterleitungen und die 180 Tage für die Adressänderung stammen aus der Google-Dokumentation zu Website-Umzügen, Stand 09/2026.

Redirect-Mapping als Code: nginx und Apache (.htaccess)

Das Mapping beginnt als Tabelle mit alter URL, neuer URL und Statuscode. Die folgenden Beispiele zeigen, wie daraus Serverregeln werden. Domain und Pfade sind Platzhalter. Passen Sie sie an Ihr Projekt an und testen Sie alles auf der Testumgebung, bevor Sie live gehen.

nginx

Eine map-Tabelle im http-Kontext hält alle Zuordnungen an einer Stelle. Der Statuscode 301 steht im return. Mit $is_args$args bleibt eine vorhandene Query-Zeichenfolge erhalten. Vor dem Neuladen prüfen Sie die Konfiguration mit nginx -t.

# Im http-Kontext, z. B. in conf.d/redirect-map.conf
map $uri $neue_url {
    default                                "";
    /alte-kategorie/                       /neue-kategorie/;
    /produkt/alter-name.html               /produkte/neuer-name/;
    ~^/blog/[0-9]+/[0-9]+/[0-9]+/(.+)/$    /ratgeber/$1/;
}

# Im server-Block der Domain (ssl_certificate usw. wie bisher)
server {
    listen 443 ssl;
    server_name www.beispiel.de;

    if ($neue_url) {
        return 301 https://www.beispiel.de$neue_url$is_args$args;
    }
}

Apache (.htaccess)

Ein einfaches Redirect gleicht Pfadanfänge ab und würde auch Unterpfade mitnehmen. Für exakte Zuordnungen eignet sich RedirectMatch mit Anker am Anfang und Ende. Geben Sie den Status immer ausdrücklich an: Ohne Angabe ist der Standard von Redirect eine temporäre Weiterleitung (302). Eine vorhandene Query-Zeichenfolge wird vom Modul mitgegeben. Prüfen Sie die Konfiguration vorab mit apachectl configtest.

# .htaccess (setzt voraus, dass der Server .htaccess auswertet, AllowOverride)
<IfModule mod_alias.c>
# Genaue Treffer zuerst, allgemeine Muster danach
RedirectMatch 301 ^/alte-kategorie/$ https://www.beispiel.de/neue-kategorie/
RedirectMatch 301 ^/produkt/alter-name\.html$ https://www.beispiel.de/produkte/neuer-name/
RedirectMatch 301 ^/blog/[0-9]+/[0-9]+/[0-9]+/(.+)/$ https://www.beispiel.de/ratgeber/$1/
</IfModule>

Test vor dem Livegang

Führen Sie alle Zeilen des Mappings auf der Testumgebung aus. Erwartet wird bei jeder alten URL der Status 301 mit der richtigen Ziel-URL, und das Ziel selbst muss 200 liefern. Liefert das Ziel wieder 301, liegt eine Kette vor. Wiederholen Sie dieselbe Schleife unmittelbar nach dem Livegang gegen die Live-Domain.

# mapping.csv: je Zeile "alte-URL;neue-URL", z. B. /alte-kategorie/;/neue-kategorie/
# Bei Passwortschutz zusätzlich: curl -u benutzer:passwort
while IFS=';' read -r alt neu; do
  antwort=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "https://staging.beispiel.de$alt")
  ziel=$(curl -s -o /dev/null -w '%{http_code}' "https://staging.beispiel.de$neu")
  echo "$alt | $antwort | Ziel liefert $ziel"
done < mapping.csv

Beachten Sie: Bei einer Testumgebung auf anderer Domain zeigt redirect_url die Live-Domain aus den absoluten Zielen. Das ist erwartet. Bei Domainwechsel setzen Sie in den Zielen die neue Domain ein.

Wie sich Relaunch SEO 2026 von klassischer Suchmaschinenoptimierung zu GEO und AI Overviews verschiebt

Auch 2026 bleibt die Grundlage eines Relaunchs gleich: crawlbare Seiten, saubere Weiterleitungen und klare Inhalte. Ergänzend lohnt der Blick auf GEO, Generative Engine Optimization, also auf die Frage, wie Inhalte in KI-Antworten wie AI Overviews genannt werden können.

Aussagen wie „klassisches SEO ist vorbei“ lassen sich nicht belegen. Für das Erscheinen in KI-Antworten gibt es keine feste Regel, und niemand kann eine Nennung zusagen. Für den Relaunch lassen sich daraus vorsichtige Hinweise ableiten (eigene Einschätzung):

• Schema.org-Markup (etwa Product, FAQPage, HowTo) im neuen Template wieder ausgeben und nach dem Livegang prüfen, statt es beim Systemwechsel zu verlieren.
• Kategorie-Seiten, Produktbeschreibungen und FAQ so schreiben, dass eine Frage direkt und nachvollziehbar beantwortet wird.
• Externe Links nicht entwerten: Das Redirect-Mapping bleibt auch in diesem Umfeld die Grundlage.

Mit welchen Kosten KMU, Mittelstand und Enterprise beim SEO-Relaunch in Deutschland rechnen

Die Kosten für einen SEO-Relaunch hängen maßgeblich von der technischen Komplexität und der Anzahl der zu migrierenden Datensätze ab. Während kleinere Shops primär auf ein sauberes Redirect-Management achten müssen, erfordern Enterprise-Systeme eine tiefgreifende strategische Neuausrichtung der Informationsarchitektur. Dieser Vergleich gehört zur Rubrik Webentwicklung auf webentwickler.pro und dient als Orientierungshilfe für die Budgetplanung bei Systemwechseln oder umfassenden Neustarts.

Welche DSGVO-, Impressum- und AVV-Punkte bei einem Relaunch rechtlich geklärt sein müssen

Ein Relaunch ohne rechtliche Absicherung ist teuer. Nicht nur Abmahnungen kosten Geld, auch Datenschutzverstöße, fehlende Bildrechte und unklar geregelte Auftragsverarbeitung führen zu erheblichen Bußgeldern. Wer 2026 eine Website neu aufsetzt, muss DSGVO-orientierte Tracking-Einwilligungen, ein vollständiges Impressum nach DDG, saubere Bildrechte und eine rechtlich sorgfältige Auftragsverarbeitungsvereinbarung (AVV) mit allen externen Dienstleistern klären. Fehlt einer dieser Punkte, kann es teuer werden: Die DSGVO sieht Bußgelder bis 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Ob und in welcher Höhe sie verhängt werden, hängt vom Einzelfall ab.

Dieser Artikel zeigt, welche rechtlichen Pflichtpunkte Sie vor dem Go-Live klären müssen. Ein Website-Relaunch betrifft nicht nur technische Migration und Content-Struktur, auch die rechtliche Infrastruktur muss sitzen: Tracking-Consent, Impressumspflicht, Bildrechte, AVV-Verträge und seit Juni 2025 auch die BFSG-Compliance für barrierefreie Websites öffentlicher Stellen und größerer Unternehmen. Wer diese Punkte ignoriert, zahlt nicht nur Anwaltskosten, sondern verliert auch Vertrauen bei Kunden und Suchmaschinen.

Zwei denkbare Szenarien: Ein Fotograf macht Ansprüche geltend, weil die Bildrechte nur für die alte Domain galten. Oder Google Analytics läuft ohne Consent-Banner, und ein Wettbewerber mahnt ab, mit Anwaltskosten und Unterlassungserklärung. Solche Fälle lassen sich vermeiden, wenn Sie vor dem Relaunch eine rechtliche Checkliste abarbeiten.

Impressum nach § 5 DDG und § 18 MStV: Pflichtangaben und Erreichbarkeit

Das Impressum muss leicht erkennbar, unmittelbar erreichbar und ständig verfügbar sein; üblich ist ein Link im Footer jeder Seite. Der Link muss „Impressum“ heißen, nicht „Kontakt“, nicht „Über uns“, nicht „Legal“. Laut § 5 Digitale-Dienste-Gesetz (DDG) müssen folgende Angaben enthalten sein: Name und Anschrift des Betreibers (bei juristischen Personen: Rechtsform, Vertretungsberechtigte, Registernummer), Kontaktdaten (E-Mail, Telefon), Umsatzsteuer-ID (falls vorhanden), zuständige Aufsichtsbehörde (bei regulierten Berufen). Bei redaktionellen Inhalten greift zusätzlich § 18 Medienstaatsvertrag (MStV): Sie brauchen einen Verantwortlichen im Sinne des Presserechts mit Anschrift.

Beim Relaunch passieren drei typische Fehler: Das Impressum verlinkt noch auf die alte Domain oder alte Firmierung. Die Telefonnummer fehlt. Nach § 5 Abs. 1 Nr. 2 DDG sind Angaben für eine schnelle elektronische Kontaktaufnahme und unmittelbare Kommunikation nötig. Nach der Rechtsprechung des EuGH sollte neben der E-Mail-Adresse ein zweiter schneller Kontaktweg stehen, etwa eine Telefonnummer. Bei GmbHs fehlt die Registernummer oder der Geschäftsführer ist nicht namentlich genannt. Kosten: Abmahnungen können je nach Streitwert erhebliche Anwalts- und Gerichtskosten verursachen.

Technisch ist das Impressum eine statische Seite, aber Sie müssen prüfen, ob Ihr CMS oder Template den Link im Footer auf allen Seiten korrekt rendert. Bei mehrsprachigen Websites brauchen Sie das Impressum in jeder Sprache. Bei Subdomain-Setups (z. B. shop.ihredomain.de) muss das Impressum auch dort verlinkt sein. Wenn Sie einen Blog auf einer separaten Domain betreiben, braucht auch der ein eigenes Impressum. Das klingt trivial, aber bei Relaunches mit neuer URL-Struktur wird das Impressum oft vergessen, weil es nicht im Content-Audit auftaucht.

Datenschutzerklärung nach Art. 13 DSGVO: Verarbeitungszwecke und Rechtsgrundlagen

Die Datenschutzerklärung muss alle Datenverarbeitungen dokumentieren: Welche Daten werden erhoben, zu welchem Zweck, auf welcher Rechtsgrundlage (Art. 6 DSGVO), wie lange werden sie gespeichert, an wen werden sie weitergegeben. Beim Relaunch ändert sich oft die technische Infrastruktur, und damit die Verarbeitungen. Wenn Sie von Google Analytics auf Matomo wechseln, muss das in der Datenschutzerklärung stehen. Wenn Sie ein neues CRM einbinden, muss das dokumentiert sein. Wenn Sie Formulare über einen neuen Anbieter hosten (z. B. Typeform statt Gravity Forms), muss das erwähnt werden.

Laut DSGVO Art. 13 müssen Sie folgende Punkte abdecken: Name und Kontaktdaten des Verantwortlichen, Kontaktdaten des Datenschutzbeauftragten (falls vorhanden), Zwecke und Rechtsgrundlagen der Verarbeitung, berechtigte Interessen (bei Art. 6 Abs. 1 lit. f), Empfänger der Daten (z. B. Hosting-Provider, Newsletter-Tool), Drittlandtransfer (z. B. USA bei Google Fonts), Speicherdauer, Betroffenenrechte (Auskunft, Löschung, Widerspruch, Beschwerde), Widerrufsmöglichkeit bei Einwilligung, Hinweis auf automatisierte Entscheidungsfindung (falls vorhanden). Das ist keine Checkliste für Juristen, sondern technische Dokumentation: Jeder externe Request ist eine Datenverarbeitung.

Ein konkretes Beispiel: Sie binden Google Fonts ein. Wenn Sie die Fonts von Google-Servern laden, überträgt der Browser des Nutzers dessen IP-Adresse an Google. Das ist eine Datenverarbeitung nach Art. 4 Nr. 2 DSGVO. Sie brauchen entweder eine Einwilligung (Art. 6 Abs. 1 lit. a) oder ein berechtigtes Interesse (Art. 6 Abs. 1 lit. f), und müssen das in der Datenschutzerklärung dokumentieren. Seit dem LG München I Urteil vom 20.01.2022 (Az. 3 O 17493/20) sind Schadensersatzforderungen wegen Google Fonts von Google-Servern ohne Einwilligung möglich. Die saubere Lösung: Fonts lokal hosten. Beim Relaunch ist das der richtige Zeitpunkt, das umzusetzen, und die Datenschutzerklärung entsprechend anzupassen.

Cookie-Consent und Tracking: Einwilligung vor Datenverarbeitung

Seit dem EuGH-Urteil „Planet49″ (C-673/17) vom 01.10.2019 gilt: Jedes nicht technisch notwendige Cookie braucht eine aktive Einwilligung, bevor es gesetzt wird. „Technisch notwendig“ heißt: Das Cookie ist zwingend erforderlich, damit die Website funktioniert (z. B. Session-Cookie für Login, Warenkorb-Cookie). Alles andere, Analytics, Marketing, Social Media Embeds, braucht Opt-in. Ein Cookie-Banner mit vorangekreuzten Häkchen oder „Alle akzeptieren“ als einziger Option ist nicht DSGVO-konform.

Beim Relaunch müssen Sie prüfen: Welche Cookies setzt Ihr neues Template oder CMS? Viele WordPress-Themes laden Google Fonts, Google Maps, YouTube-Embeds oder Facebook-Pixel automatisch, ohne Consent-Layer. Wenn Sie ein neues Analytics-Tool einbinden (z. B. Matomo statt Google Analytics), müssen Sie sicherstellen, dass es erst nach Einwilligung lädt. Wenn Sie ein neues Cookie-Consent-Tool nutzen (z. B. Cookiebot, Borlabs Cookie, Usercentrics), müssen Sie alle Skripte und Embeds damit blockieren, bis der Nutzer zustimmt.

Technisch bedeutet das: Sie müssen alle externen Skripte (Google Analytics, Facebook Pixel, LinkedIn Insight Tag, Hotjar, etc.) so einbinden, dass sie erst nach Consent-Klick ausgeführt werden. Das geht über Tag Manager (Google Tag Manager, Matomo Tag Manager) oder über Consent-Management-Plattformen (CMP). Wenn Sie YouTube-Videos einbetten, nutzen Sie den „Privacy Enhanced Mode“ (youtube-nocookie.com) oder einen Consent-Layer, der das Video erst nach Klick lädt. Wenn Sie Google Maps einbetten, nutzen Sie einen Platzhalter mit Consent-Abfrage. Das ist kein UX-Problem, sondern Standard: Nutzer erwarten inzwischen, dass sie gefragt werden, bevor Daten an Dritte fließen.

Lokale Einbindung externer Dienste: Google Fonts, Analytics, Maps

Die sauberste Lösung für DSGVO-Compliance: Externe Dienste lokal hosten oder durch datenschutzfreundliche Alternativen ersetzen. Google Fonts können Sie mit einem Tool wie „google-webfonts-helper“ herunterladen und auf Ihrem Server hosten, dann fließt keine IP-Adresse an Google. Google Analytics können Sie durch Matomo (selbst gehostet) oder Plausible (EU-Server) ersetzen. Google Maps können Sie durch OpenStreetMap oder Leaflet.js ersetzen. YouTube-Videos können Sie über einen Consent-Layer laden oder durch Vimeo (mit DSGVO-Vertrag) ersetzen.

Beim Relaunch ist das der richtige Zeitpunkt, diese Umstellung zu machen, weil Sie ohnehin die Frontend-Architektur anfassen. Ein konkretes Beispiel: Sie nutzen ein WordPress-Theme, das Google Fonts von Google-Servern lädt. Sie können entweder ein Plugin wie „OMGF“ (Optimize My Google Fonts) nutzen, das die Fonts automatisch lokal hostet, oder Sie passen die Theme-Dateien manuell an. Der Aufwand hängt vom Theme ab. Die Alternative: Sie lassen es, wie es ist, und riskieren Abmahnungen.

Mit dem Schrems-II-Urteil des EuGH (C-311/18, 16.07.2020) wurde der Privacy Shield für ungültig erklärt. Für Übermittlungen in die USA gilt seit dem 10.07.2023 das EU-US Data Privacy Framework für zertifizierte Empfänger; für andere Empfänger sind Standardvertragsklauseln nötig. Google Analytics 4 (GA4) überträgt Daten an US-Server. Die österreichische Datenschutzbehörde hat 2022 in einem Einzelfall entschieden, dass der Einsatz von Google Analytics ohne zusätzliche Maßnahmen gegen die DSGVO verstieß (vor dem EU-US Data Privacy Framework). Seit dem EU-US Data Privacy Framework hat sich die Lage für zertifizierte Empfänger geändert, Rechtliche Prüfung im Einzelfall empfohlen. Die Lösung: Entweder Sie nutzen GA4 mit IP-Anonymisierung, Consent und Auftragsverarbeitungsvertrag (AVV), oder Sie wechseln zu Matomo (selbst gehostet auf EU-Servern). Beim Relaunch ist das die Gelegenheit, auf ein datenschutzfreundliches Setup zu wechseln, und die BFSG Compliance 2025 gleich mitzunehmen.

Barrierefreiheit nach BFSG: Pflicht ab Juni 2025 für Unternehmen mit mehr als 10 Mitarbeitern

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Das BFSG gilt für bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft, darunter Verbraucherverträge im elektronischen Geschäftsverkehr. Kleinstunternehmen (weniger als zehn Beschäftigte und höchstens 2 Mio. EUR Jahresumsatz oder Bilanzsumme), die Dienstleistungen anbieten, sind nach § 3 Abs. 3 BFSG ausgenommen. Das betrifft nicht nur öffentliche Stellen (die sind seit 2019 verpflichtet), sondern auch private Unternehmen. Verstöße können mit Bußgeldern bis 100.000 EUR geahndet werden.

Barrierefreiheit bedeutet: Ihre Website muss für Menschen mit Sehbehinderung (Screenreader), motorischen Einschränkungen (Tastaturnavigation), Hörbehinderung (Untertitel für Videos) und kognitiven Einschränkungen (einfache Sprache, klare Struktur) nutzbar sein. Konkret heißt das: Alle Bilder brauchen Alt-Texte. Alle Formularfelder brauchen Labels. Alle interaktiven Elemente (Buttons, Links) müssen per Tastatur erreichbar sein. Kontraste müssen mindestens 4,5:1 (Text) bzw. 3:1 (UI-Elemente) betragen. Videos brauchen Untertitel. Die Seitenstruktur muss semantisch korrekt sein (H1-H6, <nav>, <main>, <footer>).

Beim Relaunch müssen Sie prüfen: Erfüllt Ihr neues Template die WCAG 2.1 Level AA? Viele moderne Templates sind nicht barrierefrei, weil sie auf visuelle Effekte setzen, die für Screenreader nicht funktionieren. Ein konkretes Beispiel: Ein Hamburger-Menü ohne aria-label ist für Screenreader unsichtbar. Ein Slider ohne Tastaturnavigation ist für Menschen mit motorischen Einschränkungen nicht bedienbar. Ein Kontrastfehler (hellgrauer Text auf weißem Hintergrund) ist für Menschen mit Sehschwäche nicht lesbar.

Die gute Nachricht: Barrierefreiheit ist kein Redesign, sondern eine technische Checkliste. Sie können Ihr bestehendes Design barrierefrei machen, indem Sie Alt-Texte ergänzen, Kontraste anpassen, Formular-Labels hinzufügen und die HTML-Struktur semantisch korrekt aufbauen. Tools wie WAVE (WebAIM), Lighthouse (Chrome DevTools) oder axe DevTools zeigen Ihnen die Fehler. Beim Relaunch ist das der richtige Zeitpunkt, Barrierefreiheit von Anfang an mitzudenken, nicht als Nachbesserung sechs Monate nach Launch, wenn die erste Beschwerde kommt. Mehr Details zur technischen Umsetzung finden Sie im Artikel BFSG Compliance 2025.

Auftragsverarbeitungsverträge (AVV) mit allen Dienstleistern

Wenn Sie externe Dienstleister nutzen, die personenbezogene Daten verarbeiten (Hosting-Provider, Newsletter-Tool, CRM, Analytics, Zahlungsanbieter), brauchen Sie mit jedem einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Der AVV regelt: Welche Daten werden verarbeitet, zu welchem Zweck, welche technischen und organisatorischen Maßnahmen (TOM) setzt der Dienstleister um, wo stehen die Server, gibt es Subunternehmer, wie läuft die Löschung. Ohne AVV ist die Datenverarbeitung nicht DSGVO-konform, und Sie haften als Verantwortlicher.

Beim Relaunch müssen Sie prüfen: Mit welchen neuen Dienstleistern arbeiten Sie? Wenn Sie zu einem neuen Hosting-Provider wechseln, brauchen Sie einen AVV. Wenn Sie ein neues Newsletter-Tool einbinden (z. B. Mailchimp, Brevo, CleverReach), brauchen Sie einen AVV. Wenn Sie ein neues CRM nutzen (z. B. HubSpot, Pipedrive), brauchen Sie einen AVV. Die meisten professionellen Anbieter bieten Standard-AVVs an. Sie müssen sie nur abschließen.

Ein konkretes Beispiel: Sie nutzen ein WordPress-Hosting bei einem deutschen Anbieter (z. B. Hetzner, IONOS, Raidboxes). Der Anbieter verarbeitet IP-Adressen, Log-Dateien, eventuell E-Mail-Adressen (bei Kontaktformularen). Das ist eine Auftragsverarbeitung nach Art. 28 DSGVO. Sie brauchen einen AVV. Die meisten deutschen Hoster bieten AVVs im Kundenbereich zum Download an. Sie müssen sie nur unterschreiben und archivieren. Wenn Sie einen US-Anbieter nutzen (z. B. AWS, Google Cloud), müssen Sie zusätzlich prüfen, ob ein angemessenes Schutzniveau besteht (z. B. EU-US Data Privacy Framework), oder ob Sie Standardvertragsklauseln (SCC) nach Art. 46 DSGVO abschließen müssen.

Checkliste: Rechts-Audit vor Go-Live

• Impressum vollständig und von jeder Seite erreichbar
• Datenschutzerklärung aktuell (alle neuen Tools dokumentiert)
• Cookie-Consent-Banner funktioniert (alle Skripte blockiert bis Einwilligung)
• Google Fonts lokal gehostet oder mit Consent
• YouTube-Videos mit Consent-Layer oder Privacy Enhanced Mode
• Google Maps mit Consent oder durch OpenStreetMap ersetzt
• AVVs mit allen Dienstleistern abgeschlossen
• Barrierefreiheit geprüft (WCAG 2.1 Level AA)
• SSL-Zertifikat aktiv (HTTPS)
• Kontaktformular mit Datenschutz-Checkbox
• Newsletter-Anmeldung mit Double-Opt-in

Diese Checkliste ist keine juristische Beratung, sondern eine technische Prüfliste. Wenn Sie unsicher sind, ob Ihr Setup DSGVO-orientiert ist, holen Sie sich eine Rechtsberatung (z. B. IT-Recht Kanzlei, eRecht24, Datenschutzbeauftragter). Beim Mittelstand-Relaunch ist das Rechts-Audit kein Nice-to-have, sondern Pflicht, weil Sie mit dem Launch die Verantwortung für die neue Infrastruktur übernehmen.

Wenn Sie den Relaunch mit einer Agentur oder einem Entwickler umsetzen, klären Sie vorher: Wer ist für die Rechts-Compliance verantwortlich? Manche Dienstleister liefern nur Design und technische Umsetzung, aber nicht die rechtliche Absicherung. Das ist kein Vorwurf, sondern eine Rollenklärung: Entwickler sind keine Juristen. Sie können technische Maßnahmen umsetzen (Fonts lokal hosten, Consent-Layer einbauen, AVVs einholen), aber die rechtliche Bewertung muss ein Jurist machen. Beim Relaunch sollten Sie Budget für eine Rechtsberatung einplanen, oder zumindest einen Generator wie eRecht24 oder IT-Recht Kanzlei nutzen, der Impressum und Datenschutzerklärung automatisch erstellt.

Welche KPIs nach dem Go-live über Search Console, Logs und Rankings täglich geprüft werden sollten

In den ersten Tagen nach dem Livegang zeigen sich die meisten technischen Fehler: fehlerhafte Redirects, blockierte URLs, eingebrochene Core Web Vitals. Je früher Sie sie finden, desto kleiner bleibt der Schaden. Tägliches Monitoring in der ersten Phase ist deshalb sinnvoll.

Ihr erstes Werkzeug: die Google Search Console. Schauen Sie täglich unter „Seiten“ → „Warum Seiten nicht indexiert werden“ nach. Die „Crawling-Statistiken“ zeigen Ihnen die Serverantwortzeiten. Steigende Serverantwortzeiten sind ein Warnsignal, weil langsame Antworten das Crawling bremsen können, vor allem bei sehr großen Shops. Prüfen Sie außerdem, ob wichtige Seiten noindex tragen oder per robots.txt gesperrt sind.

Server-Logs zeigen, was die Search Console versteckt. 404-Fehler, 5xx-Statuscodes und Redirect-Ketten: Alles ist hier sichtbar. Filtern Sie nach Googlebot-Zugriffen und prüfen Sie die HTTP-Codes. Häufig sind es vergessene Redirects in der Migrations-Tabelle. Redirect-Ketten (301 → 301 → 200) sollten Sie auf ein direktes Ziel kürzen. Jede zusätzliche Weiterleitung ist eine weitere Anfrage, und Google rät, Ketten möglichst zu vermeiden. Ein automatisiertes Monitoring-Tool (Screaming Frog Log Analyzer, Custom-Skripte) sollte täglich laufen und Sie sofort benachrichtigen.

Ihre wichtigsten Keywords zeigen Ihnen die Wahrheit. Tracken Sie täglich die Top-20 mit Sistrix, Ahrefs oder SEMrush. Als eigene Faustregel: Fällt ein Money-Keyword innerhalb von zwei Tagen um mehr als fünf Positionen, lohnt die Suche nach einer technischen Ursache, etwa falscher URL-Zuordnung, fehlenden 301-Redirects, fehlenden hreflang-Tags oder abgestürzten Ladezeiten. Vorübergehende Schwankungen gehören bei einem Umzug dazu. Besonders genau sollten Sie Kategorie-Seiten (z. B. „Herrenschuhe Leder“) beobachten. Beheben Sie technische Fehler möglichst schnell.

Core Web Vitals (LCP, INP, CLS) messen Ladezeit, Reaktionsfähigkeit und visuelle Stabilität. Nach einem Relaunch verschlechtern sie sich oft, etwa durch neue Skripte und Bilder. Nutzen Sie das Core Web Vitals-Dashboard in der Search Console. Prüfen Sie täglich die Feldwerte. Google empfiehlt einen LCP von höchstens 2,5 Sekunden (Quelle: Google, web.dev, Stand 09/2025). Die häufigsten Fehler: unoptimierte Bilder (fehlende WebP-Konvertierung), blockierendes JavaScript im Header, fehlendes Lazy Loading. Ein INP über 200 ms (Quelle: web.dev/articles/vitals)? Träge Interaktivität durch überladene Third-Party-Skripte (Tracking-Pixel, Chat-Widgets). CLS über 0,1? Fehlende width/height-Attribute bei Bildern oder dynamisch nachgeladene Werbebanner.

Ihre Conversion-Raten sind das Frühwarnsystem. Transaktionsraten, Warenkorbabbrüche und Checkout-Completion sollten Sie täglich tracken. Auffälligkeiten deuten oft auf kaputte Formulare, fehlerhafte Payment-Gateways oder schlechte Ladezeiten hin.

Google nennt für mittelgroße Websites einige Wochen oder mehr, bis die neuen URLs die alten in den Ergebnissen ersetzen, bei größeren Websites länger. Fehler, die in dieser Zeit bestehen bleiben, verlängern die Unsicherheit. Beheben Sie sie daher zügig.

Was Sie jetzt mitnehmen

Wie lange die Erholung dauert, lässt sich nicht seriös vorhersagen. Google spricht bei mittelgroßen Websites von einigen Wochen oder mehr und erwartet vorübergehende Schwankungen. Fehlerhafte Weiterleitungen verlängern diese Phase eher, als dass sie sie verkürzen (eigene Einschätzung).

Sie brauchen vier Dinge: Vorbereitung vor dem Design, saubere 301-Redirects mit Prüfprotokoll, rechtliche Compliance (DSGVO, Impressum, Widerrufsrecht) und kontinuierliches Monitoring in den ersten 90 Tagen. Dazu kommt eine Informationsarchitektur, die nicht nur Menschen verstehen, sondern auch AI-Systeme wie Google AI Overviews, Perplexity und ChatGPT. Die SEO-Relaunch Checkliste fasst alle technischen Schritte zusammen, von der Crawl-Analyse vor Go-Live bis zur Indexierungs-Validierung 30 Tage danach.

Drei Punkte sind besonders wichtig:

• Dokumentieren Sie die alte URL-Struktur vollständig, bevor das Design-Team startet. Ein nachträgliches Redirect-Mapping ist aufwendig und lässt Lücken, die Sie später kaum finden.
• Testen Sie Redirects automatisiert über alle URLs (Beispiel im Abschnitt zum Redirect-Mapping).
• Überwachen Sie nicht nur Rankings, sondern auch Crawl-Fehler, Indexierungsstatus und Core Web Vitals.

Der größte Fehler? Monitoring erst nach Go-Live starten. Richten Sie Google Search Console, Bing Webmaster Tools und ein Uptime-Monitoring (UptimeRobot, Pingdom) bereits einige Wochen vor dem Relaunch ein. Crawlen Sie die Staging-Umgebung wöchentlich. So erkennen Sie Canonical-Konflikte, fehlende Alt-Texte und langsame LCP-Werte, bevor sie live gehen.

Ein sauberer Relaunch senkt das Risiko von Traffic-Verlusten und spart Nacharbeit in den ersten Monaten. Das ist Zeit, die Sie in Content-Optimierung oder AI-taugliche FAQ-Strukturen investieren können, statt 404-Fehler zu jagen.

Webentwickler.pro

Stanislav Tonkich

Seit 1995 in der IT, seit 2018 Webentwickler im eCommerce. JTL, Shopware, Shopify, Individualentwicklung, n8n-Automatisierung, SEO. Weitere Projekte: STEP/SEEDS®, Marketing-Diagnostik für KMU · Bot-Agent.de, KI-Automatisierungen.