SEO-Relaunch: Was bei einem B2B-Projekt wirklich entscheidet

Bevor irgendetwas am neuen System gebaut wird, braucht es einen vollständigen Bestandsaufnahme der alten Seite. Drei Datensätze gehören dazu:

• Crawl der bestehenden Domain. Zuerst sollte jede URL durch einen Crawl erfasst werden - inklusive Statuscode, Title, Description, H1, Canonical, interne Verlinkung und Indexierbarkeit. Das Ergebnis ist eine Tabelle, die später die Grundlage für das Redirect-Mapping bildet.
   

• Performance-Daten der letzten 12 Monate. Aus der Google Search Console: Welche URLs führen zu Klicks und Impressionen, und mit welchen Suchanfragen ranken diese URLs? Aus Analytics oder Matomo: Sessions, Conversions, Assisted Conversions. So wird sichtbar, welche Seiten echten Geschäftswert haben.
   

• Backlink-Profil. Über die Search Console und ergänzenden SEO-Tools lassen sich die wichtigsten verlinkten URLs identifizieren. Genau diese URLs dürfen beim Relaunch nicht verloren gehen.

Aus der Kombination dieser drei Datensätze entsteht eine priorisierte Liste: Welche Seiten müssen 1:1 übernommen werden, welche werden zusammengeführt und welche können ggf. entfallen.

Ein Relaunch ist der richtige Zeitpunkt, das Keyword-Set zu überprüfen. B2B-Suchverhalten ändert sich, neue Wettbewerber besetzen Themen, eigene Produkte werden umpositioniert. Wichtig ist dabei die Eins-zu-eins-Zuordnung: Jedes priorisierte Keyword bekommt genau eine Ziel-URL. Das verhindert, dass mehrere eigene Seiten um dasselbe Keyword konkurrieren.

Aus der Recherche entstehen drei Entscheidungen pro Bestandsseite:

• Behalten und übernehmen: Seite rankt, hat Traffic, der Inhalt ist aktuell.
• Konsolidieren: Mehrere dünne Seiten zu einem ausführlichen Hub zusammenführen.
• Entfernen: Seite hat keine Klicks, keine Backlinks, keine strategische Relevanz – sauberer 410-Statuscode statt Zombie-Content.

Das Redirect-Mapping ist der Punkt, an dem die meisten Relaunches scheitern. Die Logik ist simpel, die Umsetzung ist Detailarbeit.

Grundregeln:

• Permanente Weiterleitungen werden als 301 ausgespielt, nicht als 302.
• Jede alte URL bekommt das thematisch passende neue Äquivalent. Pauschal-Weiterleitungen auf die Startseite erzeugen Soft-404 und werden von Google als „nicht hilfreich" gewertet.
• Gibt es kein Äquivalent und die Seite war historisch unwichtig, ist 410 die ehrlichere Antwort als 404.
• Redirect-Ketten vermeiden: A → B → C wird zu A → C aufgelöst. Jede zusätzliche Stufe kostet Crawl-Budget und verzögert die Auflösung.
• Bei mehreren tausend URLs lohnt sich eine Mischung aus regelbasierten Weiterleitungen (etwa Pfadmuster über RegEx) und manuellem Einzelmapping für Top-URLs.
• Bei internationalen Relaunches: Hreflang-Beziehungen müssen 1:1 mitgepflegt werden, sonst entstehen unklare Sprachsignale.

Vor dem Go-Live wird die Redirect-Liste in einer Staging-Umgebung gegen die Crawl-Daten geprüft: Schickt jeder Eintrag auf die richtige Ziel-URL, mit Status 301, ohne Umweg?

Die technische Basis bestimmt, wie effizient Google die neue Seite crawlt und indexiert. Vier Themenfelder sollten vor dem Go-Live abgehakt sein:

• Core Web Vitals. Realistische Zielwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Klassische Relaunch-Falle: Die neue Brand-Schriftart wird über einen externen Anbieter geladen und kippt das LCP. Lösung sind Font-Preloading, Self-Hosting oder font-display: swap.

• Indexierungssteuerung. Robots.txt, LLM.txt und Meta-Robots-Angaben müssen exakt sitzen. Im CMS sollten Canonical-Tag, Noindex-Flag und Sitemap-Aufnahme pro Seite steuerbar sein – wer das nur global einstellen kann, hat im Detail keine Kontrolle.

• Strukturierte Daten. Für B2B-Produktseiten lohnen sich Schema.org-Markups (Product, Organization, BreadcrumbList, FAQPage). Sie verbessern nicht direkt das Ranking, aber die Darstellung in den SERPs und damit die Klickrate.

Mobile und Rendering. Google indexiert mobile-first. Wenn die Seite zentrale Inhalte erst per JavaScript nachlädt, sollte mit dem URL-Inspection-Tool der GSC geprüft werden, ob Google diese Inhalte tatsächlich sieht.

Ein Hinweis zur Bounce Rate: Sie ist seit GA4 kein Standardwert mehr und ist auch kein direkter Rankingfaktor. Wer Nutzerverhalten messen will, schaut auf Engagement-Rate, Scroll-Tiefe und Conversion-Pfade. 

Der Termin sollte in einer traffic-armen Zeit liegen, im B2B typischerweise Freitagabend oder Samstag (aber danach unbedingt checken, ob alles geklappt hat, bevor ins Wochenende gegangen wird). Davor und danach gehören diese Punkte zwingend auf die Checkliste:

Vor dem Go-Live:

• Staging-Umgebung durch Basic-Auth geschützt, nicht über noindex allein
• Sitemap auf Staging gegen Crawl-Liste abgleichen: keine fehlenden, keine überzähligen URLs
• Alle Redirects in Staging getestet

Beim Go-Live:

• noindex-Header oder Robots-Disallow auf der Live-Seite entfernen – das ist der häufigste einzelne Fehler überhaupt
• Neue XML-Sitemap in der Search Console einreichen
• Bei Domain-Wechsel: Change-of-Address-Tool in der GSC nutzen
• Vollständigen Crawl der Live-Seite starten und gegen die Redirect-Matrix prüfen

In den ersten 24 Stunden:

• GSC-URL-Inspection für die Top-20-URLs: Wird die Seite korrekt gerendert? Ist sie indexierbar?
• Live-Server-Logs prüfen: Wie reagiert der Googlebot? Welche 404er tauchen auf?

In den ersten zwei bis vier Wochen entscheidet sich, wie schnell Google die neue Struktur verarbeitet. Ein leichter Sichtbarkeitsknick in dieser Phase ist normal, ein dauerhafter Einbruch nicht.

Was beobachtet werden sollte:

• GSC-Indexierungsbericht: Steigt die Zahl der „Gefunden – zurzeit nicht indexiert"-URLs? Tauchen unerwartete 404er auf? Wird die Sitemap fehlerfrei verarbeitet?
• Sistrix oder vergleichbare Tools: Wie entwickelt sich der Sichtbarkeitsindex auf Domain- und Verzeichnisebene? Welche Top-Rankings sind weg, welche neuen kommen?
• Server-Logs: Welche URLs crawlt Google wie oft? Verirrt sich der Bot in Parameter-URLs oder Filterseiten?
• Conversion-Tracking: Funktionieren Lead-Formulare technisch, läuft das Tracking sauber?

Wenn nach zwei Wochen kein Recovery sichtbar ist, ist eine systematische Fehlersuche angezeigt. Erfahrungsgemäß liegt die Ursache dann in einem der folgenden Bereiche: Redirect-Lücken, Sitemap-Inkonsistenzen, falsche Canonicals oder versehentliche Noindex-Anweisungen.

Einer unserer heutigen Kunden ging mit einer neuen Website live, ohne direkte SEO-Begleitung im Projekt. Die Symptome zeigten sich innerhalb weniger Wochen: Die organische Sichtbarkeit brach ein, Produktseiten verschwanden aus dem Index und die Anfragen über die Website gingen messbar zurück.

Ein Screaming-Frog-Crawl gegen den GSC-Indexierungsbericht und die ausgelieferte Sitemap brachte unter anderem folgende Probleme zutage:

Trailing-Slash-Routing. Produktseiten waren sowohl mit als auch ohne abschließenden Slash erreichbar. Beide Varianten lieferten Status 200, beide wurden indexiert. Ohne Canonical-Tag wertete Google das als Duplicate Content und entschied selbst, welche Variante in den Index wandert – oft die schwächere.

Duplicate URL-Strukturen. Dieselben Produkte waren zusätzlich über Kategoriepfade und über eine flache Produkt-URL erreichbar.

Sitemap nicht synchron mit den tatsächlichen Produktseiten. Die XML-Sitemap listete URLs, die im Relaunch entfernt worden waren, und ließ einen Teil der neuen Produktseiten weg. Google bekam so widersprüchliche Signale.

Schlecht aufgebautes HTML. Viele der Seiten hatten mehrere <head> und <body>-Tags und mehrere H1-Überschriften.

Veraltetes CMS. Das eingesetzte System bot keine saubere Steuerung von Canonical-Tags, keine konsistente URL-Normalisierung und keine zuverlässige Sitemap-Generierung. Die Probleme waren also nicht durch besseres Redaktionshandeln lösbar, sondern strukturell verankert.

Für die Aufarbeitung waren folgende Schritte nötig: erzwungene URL-Normalisierung über die Webserver-Konfiguration (Redirect der Slash-Variante auf die kanonische Form), Bereinigung der Duplicate-Pfade über 301s und Canonicals, manuelle Neugenerierung der Sitemap mit Abgleich gegen den Live-Crawl sowie eine saubere HTML-Struktur. Mittelfristig stand ohnehin ein CMS-Wechsel an, weil ein System ohne Kontrolle über Canonicals, hreflang und Indexierung für ein internationales B2B-Geschäft nicht tragfähig ist.

Die Lehre aus dem Projekt ist nicht neu, aber sie zeigt sich hier exemplarisch: Indexierungsprobleme entstehen selten aus einem einzelnen Fehler. Sie entstehen, wenn mehrere kleine technische Unsauberkeiten zusammenkommen und das CMS keine Werkzeuge bietet, sie systematisch zu beheben.

Wir betreuen Relaunches im B2B-Umfeld ganzheitlich – von der Konzeption über die technische Umsetzung bis zum SEO-seitigen Monitoring nach dem Go-Live. Das heißt: Die Themen aus diesem Artikel sind nicht in verschiedenen Gewerken verteilt, sondern werden in einem Team koordiniert. Wenn Sie einen Relaunch planen und das Risiko für Ihre organische Sichtbarkeit konkret einschätzen wollen, melden Sie sich für ein erstes Audit-Gespräch.

Ein gut gemachter SEO-Relaunch ist keine Schutzmaßnahme gegen Verluste, sondern eine Gelegenheit. Die Bestandsdaten zeigen genau, welche Seiten Geschäftswert haben, das Mapping zwingt zu einer aufgeräumten URL-Struktur, das technische Setup wird vom Ballast alter Systeme befreit. Wer von Anfang SEO-Ownership hat - nicht erst zwei Wochen vor Go-Live - kommt nicht nur ohne Verluste durch den Relaunch, sondern oft mit einer deutlich besseren Ausgangslage als vorher.