Zum Inhalt springen
ELOQUINONLINE MARKETING

Fachwissen · Relaunch und technisches SEO

Einen Website-Relaunch mit bestehenden URLs vorbereiten

Bevor ein neues Design umgesetzt wird, braucht jede wichtige bestehende Adresse eine begründete Entscheidung. Eine kleine URL-Matrix verbindet Seitenzweck, hilfreiche Inhalte, interne Links und verfügbare Suchdaten mit dem künftigen Zustand.

Direkt zur Antwort ↓

Die direkte Antwort

Entscheiden Sie über Seitenaufgaben, bevor Adressen verändert werden

Ein Relaunch verlangt nicht automatisch neue URLs. Stellen Sie zuerst die wichtigen bestehenden Seiten, ihre Aufgaben, hilfreichen Inhalte und Verbindungen zusammen. Entscheiden Sie dann pro Adresse: unverändert erhalten, Inhalt unter derselben URL überarbeiten oder eine nachvollziehbare Nachfolgeseite mit Weiterleitung vorsehen. Erst diese Entscheidungen bilden eine belastbare Grundlage für Design und Umsetzung.

Beziehen Sie vorhandene Suchzugriffe und externe Verweise ein, ohne daraus ein pauschales Änderungsverbot abzuleiten. Eine Seite mit wenigen Klicks kann eine wichtige Kontakt- oder Informationsaufgabe erfüllen. Umgekehrt beweist ein historischer Klick nicht, dass der Inhalt unverändert bleiben muss.

Vor dem Konzept

Ein brauchbarer Bestand verbindet Technik und Inhalt

Eine reine Liste von URLs sagt noch nicht, was erhalten werden muss. Ergänzen Sie pro wichtiger Adresse den Seitenzweck, die angesprochene Person, hilfreiche Inhalte, Kontakt- oder Buchungsfunktionen und eingehende interne Links. Vermerken Sie den aktuellen Status, den deklarierten Canonical und die bisherige Indexierungsabsicht.

  • Vorhandene Inhalte: Welche konkrete Frage beantwortet die Seite? Welche Angaben sind weiterhin richtig? Welche Dokumente, Bilder und Downloads werden tatsächlich gebraucht?
  • Verbindungen: Welche Navigationseinträge, Textlinks, Kampagnen oder externen Verweise führen zur Seite? Welche Weiterleitungen bestehen bereits?
  • Suchdaten: Aus welchem Zeitraum und welcher URL-Variante stammen Klicks und Impressionen? Liegen echte gemeinsame Suchanfrage-/Seiten-Daten vor oder nur getrennte Tabellen?
  • Funktionen: Was muss nach dem Relaunch weiterhin funktionieren – etwa Formular, Download oder Übergang in ein fremdes Portal?
  • Verantwortung: Wer bestätigt Inhalte und entscheidet über die neue Seitenaufgabe? Wer setzt technische Regeln um und wer nimmt sie ab?

Getrennte Tabellen für Suchanfragen und Seiten dürfen nicht zu angeblich nachgewiesenen Suchbegriff-Zielseiten-Paaren verbunden werden. Bewahren Sie Original-URLs und Zeiträume. Fehlende Daten werden als offene Informationsgrundlage vermerkt und nicht durch erfundene Suchvolumina ersetzt.

Für einen überschaubaren Auftrag genügt eine begrenzte, begründete Auswahl. Prüfen Sie besonders wichtige Einstiegsseiten, historische Klickpfade und den tatsächlichen Anfrageweg. Eine kleine Stichprobe ist dabei keine vollständige Bestandsabnahme.

Ausgearbeitetes Planungsbeispiel

Vier Pfade, vier begründete Entscheidungen

Die Beispielwebsite bietet Heizungswartung an. Zwei vorhandene Seiten erklären im Szenario dieselbe Wartungsleistung; eine Kontaktseite führt zur Anfrage und ein Ratgeber hilft bei der Vorbereitung. Diese Ausgangslage ist eine ausdrücklich gesetzte Planungsannahme. Es liegen dafür keine Kunden- oder Suchmessdaten vor.

Geplante Entscheidungen für eine fiktive Wartungswebsite
Bisheriger Pfad / ZweckEntscheidung und künftiges ZielBegründung und nötige ArbeitAbnahmekriterium
/leistungen/heizungswartung
Wartungsangebot verstehen
URL behalten; Inhalt gezielt ergänzen.Die Adresse passt weiterhin zur Leistung. Voraussetzungen, enthaltene Arbeiten und Grenzen fachlich bestätigen und verständlich erklären.Direkt 200; erwarteter Inhalt und Anfrageverweis vorhanden; Canonical zeigt auf denselben Pfad.
/service/wartung
Im Szenario eine zweite Darstellung derselben Leistung
Inhalt zusammenführen; dauerhafte Weiterleitung auf /leistungen/heizungswartung planen.Nur wenn die fachliche Prüfung dieselbe Nutzeraufgabe bestätigt. Einzigartige hilfreiche Angaben zuerst übernehmen; bei abweichender Aufgabe nicht pauschal weiterleiten.Alter Pfad führt mit vereinbartem permanentem Status direkt zum passenden 200-Ziel. Interne Links nutzen das Ziel; keine Schleife oder Weiterleitungskette.
/kontakt
Eine passende Anfrage vorbereiten
URL behalten und Inhalt überarbeiten.Pflichtangaben, Ablauf nach dem Senden und Kontaktalternative erklären. Die Aufgabe ist vom allgemeinen Leistungsangebot verschieden.Kontaktseite 200; Tastaturweg, Validierungsfehler und bestätigte Backendannahme mit Testtransport prüfen.
/ratgeber/wartung-vorbereiten
Benötigte Informationen zusammenstellen
URL und eigenen Seitenzweck erhalten; fachliche Aktualität prüfen.Die Vorbereitung beantwortet eine andere Frage als das Leistungsangebot. Ein verständlicher Anschluss an Wartung und Anfrage ersetzt keine eigenständige Antwort.Ratgeber 200; zutreffende Inhalte, lesbare Struktur und passende echte Links; eigenständiger Canonical.

Die Matrix ist erst dann umsetzbar, wenn die fachliche Zuständigkeit die Annahmen bestätigt. Vermerken Sie bei jeder Entscheidung Freigabe, technische Umsetzung und Prüfergebnis. Ein leeres Suchdatenfeld bedeutet „nicht vorhanden oder noch nicht geprüft“ – nicht „ohne Suchwert“.

Die zweite Zeile ist bewusst bedingt. Wenn /service/wartung in Wirklichkeit ein anderes Angebot oder einen eigenen Serviceprozess bedient, trägt die Zusammenführung nicht. Dann muss die Matrix angepasst werden. Ein ähnlicher Seitenname allein ist keine ausreichende Weiterleitungsbegründung.

Zwei verschiedene Aufgaben

Eine Weiterleitung führt weiter; ein Canonical gibt eine bevorzugte Version an

Eine serverseitige Weiterleitung beantwortet den Aufruf einer alten Adresse mit einem anderen Ziel. Wenn eine Seite dauerhaft an eine fachlich passende neue Adresse zieht, kommen permanente Statuscodes wie 301 oder 308 infrage. Prüfen Sie die konkrete Serverregel und leiten Sie direkt zum endgültigen Ziel weiter.

Ein rel="canonical" im HTML ist dagegen ein Hinweis auf die bevorzugte URL bei gleichen oder sehr ähnlichen Inhalten. Er versetzt Besucher nicht automatisch auf eine andere Seite. Ein Canonical ersetzt deshalb keine notwendige Weiterleitung eines tatsächlich aufgegebenen Pfads.

Google bewertet mehrere Signale. Ein selbstreferenzierender Canonical auf der neuen Seite, passende interne Links und konsistente Sitemap-Einträge erleichtern eine klare Zuordnung; sie garantieren nicht, welche URL Google tatsächlich auswählt. Diese Auswahl ist nach der Veröffentlichung mit geeigneten Search-Console-Daten gesondert zu prüfen.

Leiten Sie alte Seiten nicht gesammelt auf eine unpassende Startseite um. Im Beispiel ist die neue Wartungsseite nur dann ein sinnvoller Ersatz, wenn sie dieselbe Aufgabe erfüllt und hilfreiche bisherige Inhalte übernommen hat. Für eine entfernte Seite ohne passenden Ersatz braucht es eine eigene Entscheidung statt eines scheinbar bequemen Sammelziels.

Die im Artikel beschriebene Weiterleitung betrifft eine geplante Seitenzuordnung. Host-, HTTPS- und Proxyregeln sind eine weitere Konfigurationsebene. Ihre tatsächliche Infrastruktur muss separat bekannt sein, damit Regeln nicht gegeneinander arbeiten oder Schleifen auslösen.

Vorher technisch abnehmen

Die Matrix im vorbereiteten Stand überprüfen

  1. Ausgangsstand sichern: Vorhandene Seiten, Regeln, Medien und die freigegebene URL-Matrix nachvollziehbar versionieren. Den späteren Rücknahmeweg vorbereiten.
  2. Jedes vorgesehene Ziel öffnen: Status, H1, Title, Beschreibung, Hauptinhalt und wichtige Funktion anhand der Matrix prüfen. Kein gültiges Ziel darf nur eine leere Vorlagenseite sein.
  3. Links und Medien prüfen: Navigation, Textlinks, Sprungziele, Downloads und tatsächliche Bilddateien im neuen Stand kontrollieren. Interne Links möglichst direkt auf die künftigen Ziele setzen.
  4. Signale vergleichen: Canonical, Robots, Social-URLs, strukturierte Daten und Sitemap müssen zu den freigegebenen Seitenentscheidungen passen. Bewusste Ausschlüsse bleiben bewusst; Entwicklungsregeln werden nicht blind übernommen oder entfernt.
  5. Weiterleitungen isoliert testen: Jede geplante alte Adresse gegen das genaue Ziel und den vereinbarten Status prüfen. Ketten, Schleifen und fachlich falsche Sammelziele erkennen.
  6. Kontakt praktisch durchspielen: Ungültige Angaben, Korrektur, gültige Annahme und Wiederholung mit Testdaten prüfen. Keine echten Nachrichten als Test versenden.

Ein bestandener lokaler Lauf bestätigt den lokalen Stand. Er beweist weder die spätere Produktionskonfiguration noch Google-Indexierung oder Rankingentwicklung. Die technische SEO-Leistung zeigt, wie aus einem begrenzten Befund eine Aufgabe mit Abnahmekriterium wird.

Danach am wirklichen System prüfen

Veröffentlichung und Suchwirkung sind getrennte Nachweise

Nach einer freigegebenen Veröffentlichung werden die gleichen wichtigen Pfade an der tatsächlichen Domain erneut geprüft: Weiterleitung, Endstatus, Canonical, Robots, Sitemap, Medien und Anfrageweg. Auch die reale HTTPS-Erkennung hinter vorgeschalteten Proxys gehört dazu. Ein korrektes lokales Beispiel ersetzt diese Betriebskontrolle nicht.

Beobachten Sie danach fehlende Seiten, unerwartete Weiterleitungen und technische Fehler. Prüfen Sie in der Search Console vorhandene Indexierungs- und URL-Inspection-Daten. Vergleichen Sie Suchzugriffe über sinnvolle Zeiträume und berücksichtigen Sie Kampagnen, Saisonalität und parallel geänderte Inhalte. Kurzfristige Schwankungen sind keine belastbare Wirkungsaussage über eine einzelne Änderung.

Für den Rücknahmefall muss klar sein, welche Dateien und Konfigurationen zurückgesetzt werden können. Ein alter Datenbankabzug darf dabei nicht neu eingegangene Anfragen oder andere inzwischen entstandene Daten überschreiben. Planen Sie die Rücknahme des betroffenen Codes getrennt vom Erhalt aktueller Geschäftsdaten.

Ein eigenes regionales Beispiel zeigt die Übernahmeanalyse bestehender Informations- und Buchungsaufgaben. Es behandelt echte öffentliche Inhalte, aber keine von Eloquin durchgeführte Migration des dort untersuchten Angebots.

Wenn gleichzeitig die Inhaltsverwaltung gewählt wird, unterstützt die WordPress-Entscheidungshilfe zu Standardfunktionen, Erweiterungen und Pflege diese gesonderte Systementscheidung.

Primärquellen

Die technische Grundlage des Prüfplans

Quellen gelesen am 27. Oktober 2026. URL-Matrix und Abnahmeablauf sind ein eigenes Planungsbeispiel. Für eine tatsächliche Umsetzung müssen die eigenen Seiten und Betriebsbedingungen geprüft werden.

Passend weiter

Von der Prüffrage zur passenden Aufgabe

Ihr konkreter Fall

Welche Frage möchten Sie an Ihrer Website klären?

Nennen Sie die Website, den betroffenen Weg und die Beobachtung. Gemeinsam lässt sich eingrenzen, welche Prüfung oder Umsetzung dafür sinnvoll ist.

Projektanfrage vorbereitenAufgabe und Voraussetzungen besprechen.
WhatsApp
ELOQUINProjektanfrage
Schritt 1 von 7 14%

Ihr wichtigstes Ziel

Was soll Ihr digitaler Auftritt als Erstes verbessern?

Wählen Sie den Bereich, der aktuell die größte Wirkung für Ihr Unternehmen hätte.