URL-Weiterleitungen mit WebBlocks Redirect Manager verwalten

Verwenden Sie eine Test-Site und ein Super admin-Konto. Der offizielle Katalog nennt für Redirect Manager 0.1.28 die Kompatibilität CMS ^1.100.0, PHP ^8.3 und Laravel ^13.0. Ihre CMS-Version kann weitere Anforderungen stellen; dieses Beispiel läuft unter PHP 8.4. Prüfen Sie die Kompatibilität Ihres Hosts im offiziellen Redirect-Manager-Katalog.

Erstellen und veröffentlichen Sie zuerst die Zielseite. Im Beispiel ist /workshops bereits erreichbar. Das Plugin liefert eine Weiterleitungsantwort; es erstellt keine Zielseite, veröffentlicht keine Entwürfe, aktualisiert keine Links und prüft keine entfernten Websites auf Erreichbarkeit.

Legen Sie vor dem Speichern den alten Pfad, das gewünschte Ziel und die zuständige Site oder Domain fest. Verwenden Sie für eine gewöhnliche Änderung an einer Website den Site-Geltungsbereich. Globale Regeln betreffen passende Anfragen der gesamten Installation; wählen Sie sie nur, wenn dies beabsichtigt ist.

1. Öffnen Sie als Super admin System → Plugins.
2. Wählen Sie Browse Plugin Catalog und suchen Sie WebBlocks Redirect Manager.
3. Prüfen Sie Version, Versionshinweise und Kompatibilität; wählen Sie anschließend Install from Catalog.
4. Stellt Ihr Administrator stattdessen das offiziell veröffentlichte Archiv bereit, wählen Sie es unter Plugin ZIP und klicken Sie auf Upload Plugin ZIP.
5. Prüfen Sie das installierte Paket vor dem Aktivieren.

Unser Beispiel verwendet die offizielle ZIP-Datei. Ein neu installiertes Plugin ist zunächst Disabled. Das aktuelle CMS wendet Datenbankänderungen im normalen Installations- und Aktivierungsablauf an.

Öffnen Sie WebBlocks Redirect Manager und wählen Sie Enable Plugin. Bestätigen Sie Enabled, den Speicherstatus Healthy und Migrations Up to Date. Eine intakte Installation meldet einsatzbereiten Weiterleitungsspeicher und aktive öffentliche Weiterleitungsverarbeitung.

Öffnen Sie Maintenance → Redirects. Bei einer neuen Installation steht dort No redirects have been created yet. Mit Create redirect öffnen Sie das Regelformular.

Erscheint das Menü nach dem Aktivieren nicht sofort, laden Sie das Panel neu. Ist der Speicher nicht bereit, beheben Sie zuerst die Datenbank- oder Kompatibilitätswarnung des Plugins.

Redirect Manager trennt das Lesen der Liste vom Ändern der Regeln:

Für die Regelverwaltung werden normalerweise beide Berechtigungen benötigt. Installation und Plugin-Lebenszyklus bleiben administrative Aufgaben. Vergeben Sie passende Rechte anhand von Rollen und Berechtigungen.

Die Panelliste enthält Regeln der gesamten Installation. Applies to bestimmt, welche öffentlichen Anfragen passen; es begrenzt nicht, welche Regeln ein Panelbenutzer sehen oder verwalten kann. Die Verwaltungsberechtigung erlaubt Routingänderungen für die ganze Installation. Site-Beschränkungen der internen API sind eine separate Integrationskontrolle.

Wählen Sie Create redirect und tragen Sie Folgendes ein:

Das Formular wählt zunächst All sites and domains, 301 permanent und Enabled. Ändern Sie diese Vorgaben bewusst für unser Beispiel. Regeln haben keinen eigenen Veröffentlichungsschritt: Eine aktivierte gespeicherte Regel verändert das öffentliche Routing, sobald eine Anfrage das aktive Plugin erreicht.

Klicken Sie auf Create redirect. Die Erfolgsmeldung bestätigt das Speichern. Die Zeile zeigt Geltungsbereich, Quelle, Ziel, Status, Aktivierung, Hits und Last hit. Neue Regeln beginnen bei null Treffern; beim letzten Treffer steht ein Strich.

Möchten Sie eine Regel zunächst nur vorbereiten, entfernen Sie vor dem Speichern das Häkchen bei Enabled. Aktivieren Sie sie nach Prüfung von Quelle, Geltungsbereich und Ziel.

Öffnen Sie die alte öffentliche URL auf der tatsächlichen Site-Domain. Im Beispiel führt /old-workshops zu /workshops, wo die Ersatzseite normal erscheint. Prüfen Sie auch die Browseradresse; der sichtbare Zielinhalt allein zeigt nicht, ob die Antwort 301 oder 302 war.

Kehren Sie zu Maintenance → Redirects zurück und aktualisieren Sie die Liste. Das Beispiel zeigt nun 1 Treffer und einen Wert unter Last hit. Dieser entstand durch eine echte Weiterleitungsanfrage, nicht durch manuelle Eingabe.

Für eine genaue Antwortprüfung verwenden Sie das Network-Panel Ihres Browsers oder einen HTTP-Client gegen Ihre eigene Site. Eine HEAD-Anfrage prüft die Antwortheader, ohne die Zielseite herunterzuladen:

Ersetzen Sie den Beispielhost durch Ihren eigenen. Erwarten Sie für diese Regel 302 und einen Location-Header mit /workshops. Der Befehl folgt der Weiterleitung nicht. Prüfen Sie das Ziel zusätzlich und bestätigen Sie den gewünschten Seiteninhalt.

GET und HEAD zählen beide als Treffer. Überwachungswerkzeuge, Crawler und wiederholte Tests können den Gesamtwert erhöhen. Treffer zählen passende Weiterleitungen, die die Anwendung erreichen, keine eindeutigen Personen, erfolgreichen Zielbesuche oder abgeschlossenen Conversions.

Applies to bietet drei Geltungsbereiche. Site- und Domainauswahl stammen aus den CMS-Datensätzen. Fehlt die benötigte Domain, konfigurieren Sie zuerst die aktiven Domains der Site; neue Hostnamen werden nicht im Weiterleitungsformular registriert. Siehe Mehrere Sites.

Eine globale Regel dient als allgemeiner Rückfall für einen passenden Pfad in der Installation. Hier führt /programme zu /contact, wenn keine spezifischere aktive Regel Vorrang hat.

Eine Site-Regel passt zu den registrierten aktiven Domains dieser Site. Unsere Site-Regel für /programme führt zu /workshops und hat auf Northstar-Studio-Domains Vorrang vor der globalen Regel.

Dieser Geltungsbereich folgt den aktiven Domainregistrierungen der Site. Prüfen Sie das Routing beim Hinzufügen, Entfernen oder Deaktivieren von Domains. Ein unbekannter Hostname erbt die Regeln der primären Site nicht allein deshalb, weil diese der Installationsstandard ist.

Eine Domain-Regel passt nur zum ausgewählten Hostnamen. Unsere Ausnahme für events.example.test leitet /programme nach /summer-workshops. Sie gilt nicht automatisch für studio.example.test, eine www-Variante oder andere Subdomains.

Die drei Regeln können nebeneinander bestehen, weil der Quellpfad nur innerhalb seines Geltungsbereichs eindeutig sein muss, nicht über alle Geltungsbereiche hinweg.

Aktive passende Regeln für denselben Quellpfad werden so priorisiert:

1. Exakte Domain.
2. Die dem eingehenden Hostnamen zugeordnete Site.
3. Alle Sites und Domains.

Für unsere drei /programme-Beispiele ergibt sich:

Die letzte Zeile beschreibt das Plugin-Verhalten nach Eingang der Anfrage im CMS. Sie konfiguriert weder DNS noch die Auslieferung über unregistrierte Hostnamen. Hosting-, Domain- und Canonical-Domain-Einstellungen gelten weiterhin.

Nach den Hosttests zeigen die einzelnen Zähler, welche Regeln Anfragen verarbeitet haben. Deaktivieren Sie eine spezifischere Regel, kann darunter eine breitere aktive Regel wirksam werden. Prüfen Sie daher Site- und globale Rückfallregeln beim Abschalten einer Domain-Ausnahme.

Testen Sie den genauen öffentlichen Hostnamen einschließlich Alias- und Canonical-Domain-Verhalten. Webserver, CDN oder Domain-Weiterleitungen können antworten, bevor die Anfrage Redirect Manager erreicht.

Source path ist ein interner Pfad, keine vollständige URL. Geben Sie /old-workshops statt https://your-site.example/old-workshops ein. Das Plugin ergänzt den führenden Schrägstrich und normalisiert abschließende Schrägstriche; old-workshops, /old-workshops und /old-workshops/ bezeichnen dieselbe Quelle.

Nach der Normalisierung wird exakt verglichen. Eine Regel für /old-workshops passt nicht zu /old-workshops/photography. Das Formular unterstützt keine Platzhalter, regulären Ausdrücke, Präfixersetzung oder automatische Übernahme nachfolgender Pfadteile. Achten Sie auf Groß-/Kleinschreibung; unser Testhost ordnete /OLD-WORKSHOPS dem kleingeschriebenen Beispiel nicht zu.

Eingehende Abfrageparameter werden bei der Quellzuordnung ignoriert. /old-workshops und /old-workshops?utm_source=newsletter passen zur gleichen Regel. Der eingehende Query-String wird nicht automatisch an das Ziel kopiert. Tragen Sie eine feste benötigte Abfrage direkt in Target URL ein, etwa /workshops?from=legacy.

Das Ziel darf ein rootrelativer Pfad wie /workshops oder eine vollständige http/https-URL wie https://destination.example/workshops sein. Ein rootrelatives Ziel behält den eingehenden Host bei; für einen Domainwechsel verwenden Sie eine vollständige URL. Protokollrelative Ziele wie //destination.example/workshops werden abgelehnt. URL-Fragmente werden im Browser verarbeitet und können eingehende Quellregeln nicht unterscheiden.

Verwenden Sie das Plugin nicht für Formularübermittlungen oder API-Schreibzugriffe. Es prüft öffentliche GET- und HEAD-Anfragen; andere Methoden bleiben bei der Hostanwendung. Die reservierten Namensräume /admin, /api, /webadmin, /cms, /storage, /assets, /static, /build, /vendor und /webblocks-ui samt Unterpfaden werden übersprungen. Direkt vom Webserver ausgelieferte Dateien erreichen das CMS-Routing möglicherweise gar nicht.

Eine aktive Regel kann eine vorhandene öffentliche Seite am gleichen Pfad übersteuern. Bestätigen Sie vor dem Speichern, dass die alte Seite bewusst aus dem normalen Aufruf genommen werden soll. Die Quelle muss nicht zunächst 404 zurückgeben.

Bei einer zweiten Regel mit derselben normalisierten Quelle im gleichen Geltungsbereich meldet das Formular The source path has already been taken. Bearbeiten Sie die vorhandene Regel. Auch eine deaktivierte Regel belegt ihre Quelle.

Das Plugin verhindert eine direkte interne Selbstweiterleitung. /loop-check darf nicht auf /loop-check?from=legacy zeigen, weil ein Query-String den eigentlichen Pfad nicht ändert. Die Meldung lautet The target must not redirect this path back to itself.

Dieser Schutz ersetzt nicht die Prüfung der gesamten Kette. Vermeiden Sie /a → /b zusammen mit /b → /a oder Domainwechsel, die ein anderes System zurückleitet. Verweisen Sie alte Adressen direkt auf das endgültige Ziel und testen Sie die gesamte Kette.

Für die Startseite geben Sie / als Quelle an und wählen Site oder Domain. Eine aktive globale Startseitenregel wird mit Choose a site or domain for a homepage redirect. abgelehnt. Dadurch kann eine globale Root-Regel nicht alle Startseiten übernehmen.

Prüfen Sie Startseitenziele besonders sorgfältig: Ein relatives Ziel bleibt auf der aktuellen Domain. Wählen Sie einen engen Geltungsbereich und stellen Sie sicher, dass das Ziel keine Regel zurück zu / besitzt.

Bleiben Sie bei 302 temporary, während Sie Quelle, Hostname, Ziel und Treffer prüfen. Ist der Umzug dauerhaft vorgesehen und sind die Tests erfolgreich:

1. Suchen Sie die Regel unter Maintenance → Redirects.
2. Wählen Sie das Stiftsymbol Edit redirect.
3. Prüfen Sie Applies to, Source path und Target URL.
4. Stellen Sie Status code auf 301 permanent.
5. Lassen Sie Enabled aktiviert und wählen Sie Save changes.

Die Liste zeigt nun 301 und den Hinweis zum Browsercache. Beim Bearbeiten bleiben Trefferzahl und letzter Treffer erhalten.

Browser können 301-Weiterleitungen zwischenspeichern und ohne CMS-Kontakt wiederverwenden. Dadurch kann ein geändertes Ziel unverändert erscheinen und ein neuer serverseitiger Treffer ausbleiben. Prüfen Sie mit einem HTTP-Client, der eine neue Anfrage stellt, oder deaktivieren Sie den Cache in den Browser-Netzwerkwerkzeugen. Das Abschalten einer Regel kann bereits im Client oder vorgelagerten Systemen gespeicherte Antworten nicht zurückrufen.

Um eine Weiterleitung bei Erhalt von Konfiguration und Historie anzuhalten, bearbeiten Sie sie, entfernen das Häkchen bei Enabled und wählen Save changes.

Die Zeile bleibt als Disabled erhalten. Neue Anfragen verwenden diese Regel nicht mehr und erhöhen ihren Zähler nicht. Ohne andere aktive Geltungsbereichsregel oder Weiterleitungsebene liefert der Host die normale Seite oder 404. Im Workshop-Beispiel liefert die ungenutzte alte Adresse nach dem Abschalten 404.

Zur Wiederherstellung bearbeiten Sie dieselbe Zeile, aktivieren Enabled, prüfen das Ziel und speichern. So vermeiden Sie eine doppelte Quelle und behalten die Historie.

Das Papierkorbsymbol Delete redirect entfernt Regel und Trefferhistorie. In 0.1.28 wird die Aktion direkt ausgeführt; das Plugin hat keinen Papierkorb oder Wiederherstellungsbildschirm. Sichern Sie benötigte Angaben vorher und verwenden Sie für eine umkehrbare Pause Disabled.

Das Deaktivieren des gesamten Plugins unter System → Plugins stoppt seine Weiterleitungen und blendet seine Beiträge aus. Die Plugin-Tabellen bleiben beim aktuellen Lebenszyklus erhalten. Diese Aktion betrifft mehr als eine Regel und leert weder Browser- noch CDN-Caches.

Redirect Manager 0.1.28 bietet einzelne Regeln, zwei Statuscodes, Geltungsbereiche und eine zusammengefasste Trefferhistorie. Es fügt keinen Seitenbaustein hinzu: Das aktive Plugin verarbeitet passende öffentliche Anfragen direkt.

Das Panel bietet keine Zeitplanung, keinen CSV-Massenimport/-export, keine Platzhalterzuordnung, Besucher-Einzelanalyse oder automatische Suche nach defekten Links. Planen Sie diese Anforderungen separat, statt nicht unterstützte Muster in Source path einzutragen. Eine Zählerrücksetzung gibt es in dieser Version ebenfalls nicht.

Ändern Sie eine Seitenadresse im CMS, prüfen Sie die alte URL selbst. Eine Umbenennung erzeugt nicht automatisch eine Plugin-Regel. Aktualisieren Sie Navigation und interne Links auf die endgültige Adresse; behalten Sie gezielte Weiterleitungen für externe Lesezeichen und nicht änderbare Links. Siehe Seitenadresse ändern.

Für Automatisierungen stellt das Plugin seine Regeln über die Internal Content API unter /webadmin/api/redirect-manager/redirects bereit. Lesen erfordert plugins.read, Schreiben plugins.manage und die zutreffenden Site-Beschränkungen. Die API-Erkennung des CMS zeigt Endpunkte und Anfragevertrag des installierten Plugins. Panelbenutzer benötigen für diese Anleitung keinen API-Token.

Bestätigen Sie vor dem Aktivieren eines echten Umzugs, dass die Ersatzseite veröffentlicht ist und auf dem Zielhost den gewünschten Inhalt liefert. Beginnen Sie mit 302, prüfen Sie die alte Adresse ohne Folgen der Weiterleitung auf Status und Location-Header und rufen Sie danach das endgültige Ziel auf.

Prüfen Sie alle betroffenen Domains, spezifischere Regeln, abschließende Schrägstriche und Query-Erwartungen. Das Ziel darf nicht zurückleiten; GET/HEAD-Tests müssen die erwarteten Zähleränderungen liefern. Wechseln Sie erst bei feststehendem dauerhaftem Umzug zu 301.

Aktualisieren Sie nach dem Start die von Ihnen kontrollierten Links, dokumentieren Sie Geltungsbereich und Zweck der Regel und prüfen Sie regelmäßig die Trefferzahlen. Deaktivieren Sie vor dem Löschen, wenn Sie nur pausieren möchten. Damit halten Sie alte URLs in einem wiederholbaren Ablauf nutzbar und bestimmen genau, wo jede Weiterleitung gilt.