Migration von Rebrandly: Branded-Domain-Übergabe ohne Slug-Verlust

Rebrandly ist um eine einzige zentrale Abstraktion herum gebaut: die Branded Domain. Slashtags, Tag-Taxonomien und Traffic-Routing-Regeln hängen alle darunter. Diese Designentscheidung macht Rebrandly zu einem kohärenten Produkt, und sie macht die Migration weg von Rebrandly anders als jeden anderen Shortener-Wechsel.

Wenn Sie Rebrandly verlassen, migrieren Sie nicht in erster Linie Links. Sie migrieren eine Domain. Die Links fahren mit, und die Details, wie Sie sie bewahren, hängen fast vollständig davon ab, was Sie mit der Domain machen wollen.

Dieser Beitrag behandelt die zwei realistischen Pfade, die Exportform aus der Rebrandly-API, den Bulk-Import-Call zu Elido und den Validierungsprozess vor der Ankündigung des Cutovers.

TL;DR

• Die Kern-Abstraktion von Rebrandly ist die Branded Domain. Die Migration ist zuerst eine DNS-Übergabe, dann Linkerhaltung.
• Pfad A: Die Domain bleibt gleich, nur der Shortener ändert sich. Slugs auf Elido vorbereitstellen, CNAME umlegen, fertig.
• Pfad B: Auch die Domain ändert sich. Sie brauchen entweder eine 301-Kette von der alten Domain (Rebrandly-Pro-Stufe) oder akzeptieren eine Slug-Änderung auf der neuen Domain.
• Rebrandly-Tags lassen sich sauber auf Elido-Tags abbilden. Rebrandly-Kategorien brauchen manuelles Mapping - sie haben kein direktes Pendant.

Was Sie zuerst inventarisieren müssen

Bevor Sie sich auf einen der beiden Pfade festlegen, machen Sie eine Bestandsaufnahme von vier Dingen.

Branded Domain oder Domains. Das Workspace-Modell von Rebrandly erlaubt mehrere Custom-Domains pro Konto. In einem Agentur- oder Multi-Brand-Workspace ist jede Domain eine separate Migrationseinheit. Zählen Sie sie auf, bevor Sie Cutover-Fenster planen - eine Domain pro Nacht ist ein sichereres Zeitplan als alle auf einmal.

Aktive Links. Nutzen Sie für große Bestände die Rebrandly REST API (abgerufen am 2026-05-12) statt des CSV-Exports. Der Endpunkt /v1/links paginiert mit den Query-Parametern last und limit und gibt das vollständige Link-Objekt inklusive Slashtag, Ziel, Domainnamen, Tag-Set und createdAt zurück. Der CSV-Export aus dem Workspace-Settings-Panel ist für unter ein paar hundert Links in Ordnung, schneidet Felder aber bei größeren Exporten inkonsistent ab.

Integrationen. Wenn Ihr Team Links über Zapier-, Make- oder Workato-Workflows erstellt, zeigen diese Konnektoren auf die Rebrandly-API. Jeder muss neu ausgerichtet werden. Das ist eine separate Aufgabe von der Linkmigration mit eigenem Karenzfenster. Decken Sie sie nach dem DNS-Wechsel ab, nicht davor.

Tag- und Kategorientaxonomie. Rebrandly unterstützt sowohl freie Tags als auch strukturierte Kategorien. Tags bilden eins-zu-eins auf Elido-Tags ab. Kategorien haben in Elido kein direktes Pendant - die nächstliegende Abbildung ist ein reserviertes Tag-Präfix (cat:campaign, cat:region), das Sie beim Import vergeben. Einigen Sie sich auf das Mapping, bevor Sie das Skript starten, nicht danach.

Pfad A: Domain bleibt, Shortener wechselt

Das ist die saubere Migration. Sie behalten go.acme.com (oder wie auch immer Ihre Branded-Short-Domain heißt). Sie stellen jeden Slug auf Elido unter derselben Domain vorab bereit und schalten dann den CNAME um. Aus Sicht eines Linkklicks ändert sich nichts - der Slug löst auf dieselbe Ziel-URL auf, nur über einen anderen Edge.

Schritt 1: aus Rebrandly exportieren

Laufen Sie über die Rebrandly /v1/links API paginiert. Die Response-Objekte enthalten slashtag, destination, domain.fullName, tags[], category.name und createdAt. Speichern Sie als JSONL.

Zwei Dinge sind sorgfältig zu behandeln. Erstens domain.fullName - wenn Ihr Workspace mehr als eine Domain hat, filtern Sie auf diejenige, die Sie in diesem Durchgang migrieren. Zweitens, die Rebrandly-Preisstufen (abgerufen am 2026-05-12) gaten, wie viele Links und wie viele Custom-Domains pro Konto aktiv sind. Die API gibt alle Links zurück; Ihr Bestand kann Links auf Domains enthalten, die Sie bereits stillgelegt haben. Filtern Sie diese vor dem Import heraus.

Schritt 2: auf Elido vorab bereitstellen

Registrieren Sie die Domain in Ihrem Elido-Workspace über den Custom-Domains-Flow, bevor Sie DNS anfassen. Die Domain muss noch nicht live sein. Elido validiert den Domain-Besitz über einen DNS-TXT-Record; das können Sie erledigen, ohne den bestehenden CNAME zu stören, der auf Rebrandly zeigt.

Sobald die Domain registriert ist, importieren Sie die Links per Bulk. Der Endpunkt POST /v1/links/bulk akzeptiert bis zu 100 Links pro Aufruf und gibt Erfolg/Misserfolg pro Item zurück, sodass eine Slug-Kollision in einer Zeile den Batch nicht abbricht. Übergeben Sie slug explizit, um den Rebrandly-Slashtag zu erhalten. Bilden Sie Rebrandlys tags[] direkt auf Elidos tags[] ab. Übergeben Sie created_at, um den ursprünglichen Erstellzeitstempel für historische Sortierungen zu erhalten.

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rebrandly-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "summer-promo",
        "destination_url": "https://acme.example/summer",
        "tags": ["campaign", "q3", "rebrandly-migrated"],
        "created_at": "2025-07-01T09:00:00Z"
      },
      {
        "slug": "hero-cta",
        "destination_url": "https://acme.example/hero",
        "tags": ["homepage", "rebrandly-migrated"],
        "created_at": "2025-03-15T14:30:00Z"
      }
    ]
  }'

Das rebrandly-migrated-Tag ist für die Analytik-Filterung nach dem Cutover nützlich - Sie können vor-migrierte Links von nativ auf Elido erstellten trennen und Klicktrends über die ersten 30 Tage vergleichen.

Für das Kategorien-Taxonomie-Mapping: Wenn summer-promo in einer Rebrandly-Kategorie namens Campaigns lag, fügen Sie cat:campaigns zum tags-Array hinzu. Es ist semantisch nicht äquivalent, aber es liefert Ihnen einen Filter in Elidos Analytics- und Dashboard-Ansichten. Dokumentieren Sie das Mapping in Ihren Migrationsnotizen.

Machen Sie zuerst einen Trockenlauf. Die meisten Teams fahren den Bulk-Import gegen einen Staging-Workspace oder mit einer kleinen Stichprobe (10-20 Links), bevor sie den vollen Bestand schicken. Die Antwortfläche pro Item im Bulk-Endpunkt zeigt etwaige Slug-Konflikte oder Ziel-Validierungsfehler sauber an, bevor Sie den gesamten Export committen.

Schritt 3: DNS-Cutover

Das ist der Moment. Bevor Sie hier ankommen, verifizieren Sie Folgendes:

• Alle Slugs im Bulk-Import haben Erfolgsstatus zurückgegeben. Keine offenen Fehler.
• Die Domain ist registriert und TLS ist in Ihrem Elido-Workspace bereitgestellt. Testen Sie einen Slug direkt gegen den Elido-Edge, indem Sie temporär einen CNAME auf eine Test-Subdomain setzen, nicht auf Ihre Produktion.
• Die TTL des bestehenden Rebrandly-CNAME wurde abgesenkt. Die Rebrandly-Preisseite (abgerufen am 2026-05-12) zeigt, dass DNS-Konfiguration ab der Free-Stufe verfügbar ist - Sie können die TTL ohne Upgrade absenken. Senken Sie sie mindestens 24 Stunden vor dem Cutover-Fenster auf 300 Sekunden.

Wenn das Fenster sich öffnet, tauschen Sie das CNAME-Ziel:

go.acme.com.  300  IN  CNAME  edge.elido.me.

Elidos Edge nutzt automatisches On-Demand-TLS. Wenn TLS bereits während der Vorvalidierung bereitgestellt wurde (empfohlen), ist die erste Anfrage nach DNS-Propagation schnell. Wenn nicht, wird das Zertifikat bei der ersten Anfrage bereitgestellt - typischerweise 1-3 Sekunden, dann cacht das Zertifikat und nachfolgende Anfragen werden bei p95 unter 15 ms vom EU-Region-Edge bedient.

Verifizieren Sie von mehreren Resolvern, bevor Sie das Change-Fenster schließen. Ein Propagations-Check von Ihrem Schreibtisch bestätigt nur Ihren Resolver. Tools wie dig @8.8.8.8 go.acme.com CNAME und dig @1.1.1.1 go.acme.com CNAME fangen die übliche Divergenz ab.

Pfad B: auch die Domain ändert sich

Manche Teams nehmen die Migration als Gelegenheit, die Branded Domain umzubenennen - von brand.ly (eine von Rebrandly zugewiesene Subdomain) zu etwas, das ihnen vollständig gehört, oder von einer Markendomain zu einer anderen nach einem Rebrand. Andere waren auf Rebrandlys Subdomain (yourname.rebrandly.com) und haben nie eine Custom-Domain eingerichtet.

In beiden Fällen ändert sich der Slug-Raum. Die Frage ist, ob Sie eine 301-Kette von der alten Domain installieren können, um Linkbrüche zu minimieren.

Option B1: 301-Kette von der alten Rebrandly-Domain

Rebrandlys Traffic-Routing-Feature - auf der Pro-Stufe verfügbar - erlaubt es, eine ganze Domain auf eine neue Basis-URL umzuleiten. Wenn Sie die alte Domain besitzen und Traffic weiterleiten wollen, können Sie in Rebrandly einen Wildcard-Redirect einrichten, der alle Anfragen go.old-domain.com/* mit Slug-Match auf go.new-domain.com/* weiterleitet.

RFC 7231 §6.4.2 definiert die Semantik von 301 Moved Permanently: Clients, die einen 301 erhalten, sollen jede gespeicherte URL auf den neuen Standort aktualisieren. In der Praxis bedeutet das, dass bestehende QR-Codes, Druckerzeugnisse und veröffentlichte Links während des Überlappungszeitraums korrekt umgeleitet werden. Das ist das Nächstliegende zu einer transparenten Migration, wenn die Domain sich ändert.

Die Mechanik: Halten Sie die alte Domain während des Überlappungszeitraums auf Rebrandly live, konfiguriert als Pass-Through-Redirector. Fahren Sie die neue Domain ab Tag eins der Migration auf Elido. Nach 30-90 Tagen (je nachdem, wie lange Ihre veröffentlichten Materialien im Umlauf bleiben) nehmen Sie die alte Domain auf Rebrandly außer Betrieb.

Option B2: Slug-Änderung akzeptieren

Wenn die alte Domain eine von Rebrandly zugewiesene Subdomain (yourname.rebrandly.com) war oder eine Domain, über die Sie keine DNS-Kontrolle mehr haben, ist keine 301-Kette verfügbar. Die Links auf der alten Domain funktionieren weiter, solange Rebrandly läuft und Sie das Konto aktiv halten. Traffic auf diesen alten Links wird nicht über Elido geroutet; Sie verlieren die Analytics-Abdeckung dafür.

Der praktische Ansatz: migrieren Sie die Linkliste zu Elido auf einer neuen Domain, erstellen Sie neue Slugs für die Links mit höchstem Traffic und aktualisieren Sie die veröffentlichten Oberflächen, die wichtig sind, und lassen Sie den Long Tail von alten Links mit wenig Traffic auf Rebrandly verfallen. Das migrate-from-bitly-playbook deckt denselben Entscheidungsrahmen für Bitly-Migrationen ab - die Argumentation gilt hier.

Für Teams, die zwischen Option B1 und B2 entscheiden, lautet die Rechnung: wie viele veröffentlichte Oberflächen die alten Links enthalten, wie schwer sie zu aktualisieren sind und wie lange Traffic weiterhin auf diesen Oberflächen ankommt. E-Mail-Archiv-Links mit viel Traffic und Druckerzeugnisse sprechen für B1. Ein paar interne Dokumente sprechen für B2.

Rebrandly-Export: was Sie bekommen und was nicht

Die Rebrandly API (abgerufen am 2026-05-12) exportiert die folgenden Felder pro Link über /v1/links:

• id - Rebrandlys interne Link-ID (nicht zum Import nötig, aber als Idempotenz-Key nützlich)
• slashtag - der zu erhaltende Slug
• destination - die vollständige Ziel-URL inklusive UTM-Parametern
• domain.fullName - der Custom-Domain-Hostname
• tags[] - freie Tags; direkt auf Elido-Tags abbilden
• category.name - Kategoriebezeichnung; manuell auf ein Tag-Präfix abbilden
• createdAt, updatedAt - Zeitstempel; createdAt auf Elidos created_at-Feld übergeben
• clicks.total - Lebenszeit-Klickzahl; nicht in Elidos Analytics importierbar, aber wert, in einem Tag (clicks-baseline-1234) oder in der eigenen Datenebene gespeichert zu werden

Was die API nicht exportiert:

• Rohe Click-Events. Rebrandly stellt keine Pro-Klick-Records bereit - Sie erhalten nur aggregierte Zählungen. Die Analytics-Uhr beginnt auf Elido ab dem Cutover-Tag von neuem.
• Traffic-Routing-Regeln. Wenn Sie bedingte Redirects auf irgendwelchen Links konfiguriert haben (Geräte- oder Geo-Routing), müssen diese Regeln nach dem Import manuell im Smart-Link-Editor von Elido neu angelegt werden. Es gibt keinen Bulk-Import für Routing-Regeln.
• Team-Mitglied-Berechtigungen. Workspace-Zugriff muss auf Elido neu eingeladen werden.

Das Fehlen roher Click-Events ist dieselbe Einschränkung, auf die Sie bei der Migration von Bitly ohne Linkbruch stoßen. Das Muster für den Umgang damit ist dasselbe: Speichern Sie den Rebrandly-Lebenszeit-Zähler, verfolgen Sie Elido-Klicks ab dem Cutover und kombinieren Sie sie beim Reporting historischer Summen.

Webhook-Neuverkabelung: Zapier, Make, Workato

Wenn irgendwelche Ihrer Automationsworkflows Rebrandly-Links erstellen, müssen diese neu ausgerichtet werden: ein CRM-Trigger, der pro Lead einen Tracking-Link erzeugt, ein Zap, der Links aus einem Spreadsheet kürzt, ein Make-Szenario, das QR-Codes für Events erzeugt.

Der Mechanismus unterscheidet sich je nach Plattform. In Zapier finden Sie jeden Zap, der die Rebrandly-App nutzt, und ersetzen den Aktionsschritt entweder durch die Elido-Zapier-App (Verfügbarkeit beim Launch prüfen) oder eine Webhook-Aktion, die POST /v1/links direkt aufruft. In Make und Workato gilt dieselbe Ersetzung.

Zwei Dinge sind hier richtig zu sequenzieren. Erstens: Richten Sie die Automationen nicht neu aus, bevor der DNS-Cutover und der Bulk-Import bestätigt sind. Automationen gegen Elido auszuführen, bevor die Vorbereitstellung abgeschlossen ist, erzeugt doppelte Slug-Konflikte. Zweitens: Fügen Sie den Elido-API-Key vor dem Wechsel in den Credential-Store jeder Automationsplattform ein - machen Sie das im Voraus, nicht während des Cutover-Fensters.

Das Karenzfenster: Für jede Automation, die Links mit geringer Frequenz erzeugt (ein paar pro Woche), ist es risikoarm, sie 1-2 Wochen nach dem DNS-Cutover auf Rebrandly zu lassen. Die von ihr erzeugten Links sind zwar auf der alten Plattform, aber das DNS ist bereits umgelegt, sodass diese Links über Elido aufgelöst werden. Für Hochfrequenz-Automationen, die Dutzende Links pro Tag erzeugen, migrieren Sie sie am Cutover-Tag.

Für die API und verfügbaren SDKs von Elido behandelt die Preisseite die Plan-Limits, und die vollständige API-Referenz liegt unter /help. TypeScript-, Python- und Go-SDKs sind verfügbar.

Validierung vor der Cutover-Ankündigung

Erklären Sie die Migration nicht für abgeschlossen, bevor Sie eine strukturierte Stichprobenprüfung gemacht haben. Zwei Dinge brechen stillschweigend: Ziel-URLs, die beim Export Encoding-Probleme hatten, und Slugs, die beim Bulk-Import kollidierten und übersprungen wurden.

Top-100-Slug-Check

Sortieren Sie Ihre exportierte Linkliste absteigend nach clicks.total. Nehmen Sie die Top 100. Senden Sie für jeden eine HEAD-Anfrage gegen die Elido-gehostete URL und prüfen Sie, dass der Location-Header dem erwarteten Ziel entspricht:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://go.acme.com/summer-promo"

Eine 301-Antwort mit der korrekten Ziel-URL bestätigt, dass der Slug funktioniert. Ein 404 bedeutet entweder, dass der Slug nicht vorab bereitgestellt wurde (Bulk-Import-Antwortprotokoll prüfen), oder es lag ein Case-Sensitivity-Mismatch vor. Rebrandly-Slashtags sind beim Auflösen case-insensitiv; Elido-Slugs sind bei der Erstellung case-sensitiv. Wenn Ihr Export gemischte Slashtags enthält, normalisieren Sie vor dem Import auf Kleinbuchstaben.

30-Tage-Rollback-Plan

Halten Sie das Rebrandly-Konto 30 Tage nach dem DNS-Cutover aktiv. Die DNS-Änderung ist zu jedem Zeitpunkt in diesem Fenster vollständig umkehrbar - zeigen Sie den CNAME wieder auf Rebrandlys Edge und die alten Links funktionieren wieder. Wenn die Analytik nach 30 Tagen keine Anomalie in der Redirect-Erfolgsrate zeigt und der Slug-Check bestanden ist, kann das Rebrandly-Konto sicher heruntergestuft oder gekündigt werden.

Zur Domain: Übertragen Sie den Registrar der Domain während des Migrationsfensters nicht von dort, wo er gerade liegt. Die CNAME-Änderung ist die einzige DNS-Operation, die erforderlich ist. Ein Registrar-Transfer fügt Propagationsrisiko hinzu, das während des Cutovers unnötig ist.

Interner Migrationskontext

Die Mechanik dieser Migration entspricht dem Bitly-Playbook. Die DNS-Muster, das TTL-Timing und der Slug-Erhaltungsansatz sind dieselben. Wenn Sie den Wechsel auf Feature-Ebene bewerten, bevor Sie sich auf Migrationsarbeit festlegen, behandelt der elido-vs-rebrandly-Vergleich Unterschiede beim Preismodell und die EU-Residenz-Lücke im Detail. Die Setup-Dokumentation zu Custom-Domains unter /features/custom-domains deckt die Elido-Seite der DNS-Verifikation und TLS-Bereitstellung ab. Und /pricing hat die aktuellen Stufenlimits - die Vorbereitstellung eines großen Rebrandly-Bestands erfordert den richtigen Plan, bevor Sie mit dem Importieren beginnen.

---

Quellen: Rebrandly API documentation abgerufen am 2026-05-12. Rebrandly pricing page abgerufen am 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.