Ana Kowalska ist Solutions Engineer bei Elido und hat ein Dutzend Migrationsprojekte durch den Bitly-Cutover begleitet. Sie ist der Meinung, dass der grosste Teil des Schmerzes vermeidbar ist, wenn man vor dem Umzug auditiert statt danach.
Das migrate-from-bitly-playbook deckt den strategischen Bogen ab: pruefen, was vorhanden ist, exportieren, importieren, DNS umstellen. Dieser Beitrag ist der richtige Ausgangspunkt, wenn Sie noch nie eine Bitly-Migration durchgefuehrt haben.
Dieser Beitrag ist anders. Er konzentriert sich darauf, was kaputtgeht - auf die spezifischen Fehlermuster, die auftauchen, nachdem der konzeptionelle Plan steht und Sie die Migration tatsaechlich gegen Produktivdaten fahren. Sieben davon treten wiederholt auf, und alle sieben sind vermeidbar, wenn man weiss, worauf zu achten ist.
TL;DR#
- Bitly-Slugs sind case-sensitive; viele Redirect-Plattformen sind es nicht.
bit.ly/AbCdundbit.ly/abcdsind in Bitly unterschiedliche Links und verhalten sich unterschiedlich, wenn Ihr Migrationsskript Slugs beim Import in Kleinbuchstaben umwandelt. - DNS-TTL-Luecken verursachen eine Redirect-Luecke, selbst nachdem der CNAME umgeschaltet wurde. Senken Sie die TTL mindestens 24 Stunden vor dem Cutover auf 60 Sekunden, nicht fuenf Minuten vorher.
- Webhooks, die auf
api-ssl.bitly.com-Endpunkte zeigen, hoeren in dem Moment auf zu feuern, in dem Sie das Bitly-Konto kuendigen oder deaktivieren. Verkabeln Sie jeden nachgelagerten Konsumenten neu, bevor Sie den Kontostatus anruehren. - Deeplinks mit Pfadsegmenten (
bit.ly/app/account/settings) kollidieren mit allen Elido-Routing-Regeln, die ebenfalls auf Pfadpraefixe matchen. Auditieren Sie Deeplink-Slugs getrennt von normalen Redirect-Slugs.
Die sieben Dinge, die tatsaechlich kaputtgehen#
Vor jeder Werkzeugdiskussion hilft es, die Fehler-Taxonomie vor sich zu haben. Die meisten Migrations-Post-Mortems verweisen auf eines davon:
1. Slug-Gross-/Kleinschreibung. Bitly bewahrt die Gross-/Kleinschreibung in Slugs - bit.ly/SummerSale und bit.ly/summersale sind unterschiedliche Links. Wenn Ihr Import-Skript Slugs auf Kleinbuchstaben normalisiert (eine gaengige Voreinstellung in URL-Handling-Bibliotheken), erzeugen Sie stillschweigend den falschen Slug und die Variante mit Grossbuchstaben liefert 404. Davon sind E-Mail-Kampagnen betroffen, in denen der Slug in gemischter Gross-/Kleinschreibung eingebettet wurde.
2. Verhalten beim abschliessenden Schraegstrich. bit.ly/campaign/ und bit.ly/campaign werden im Bitly-Router als derselbe Link behandelt. Manche Plattformen behandeln die Variante mit abschliessendem Schraegstrich als eigenen Pfad. Wenn Ihr Elido-Workspace hinter einem Reverse-Proxy mit strikter URL-Normalisierung sitzt, kann eine Anfrage mit abschliessendem Schraegstrich anders aufgeloest werden als der kanonische Slug.
3. Erhaltung des Query-Strings. Wenn die Ziel-URL eines Bitly-Links bereits Query-Parameter enthaelt - https://acme.example/landing?source=bitly - und der Klick zusaetzlich UTM-Parameter mitbringt, die zum Zeitpunkt des Teilens angehaengt wurden, muessen Sie pruefen, ob das Zusammenfuehren am Ziel in Elido identisch funktioniert. Das Standardverhalten von Bitly fuer angehaengte UTMs ist, sie in den bestehenden Query-String zu mergen. Testen Sie dies explizit fuer jeden Link, dessen Ziel-URL bereits Parameter traegt.
4. UTM-Anhaengen auf Plattformebene. Der Enterprise-Tarif von Bitly unterstuetzt UTM-Anhaengen auf Workspace-Ebene: jedem ausgehenden Redirect wird unabhaengig vom Inhalt der urspruenglichen Ziel-URL ein UTM angehaengt. Wenn Sie dies in Bitly aktiviert hatten und nicht dokumentierten, koennen Analytics-Reports von UTMs abhaengen, die Elido noch nicht anhaengt. Pruefen Sie vor dem Export Ihre Workspace-Einstellungen in Bitly auf Auto-Append-Regeln. Das Pendant in Elido sind UTM-Templates auf Workspace- oder Kampagnenebene - die Seite zum Custom-Domains-Feature zeigt, wo diese Konfiguration sitzt.
5. DNS-TTL-Luecke. Das ist die haeufigste Ursache fuer eine Redirect-Luecke beim Cutover. DNS-Resolver cachen den alten CNAME fuer die Dauer der aktuellen TTL. Wenn Ihre TTL seit zwei Jahren bei 86400 Sekunden steht und Sie sie fuenf Minuten vor dem Umlegen des A-Records auf 300 Sekunden aendern, halten die meisten Resolver den alten Record immer noch fuer weitere 23 Stunden und 55 Minuten. Der Cutover ist nicht sofortig; er propagiert.
6. Webhook-Neuverkabelung. Jedes System, das Bitly-Webhook-Events konsumiert - Analytics-Pipelines, CRM-Anreicherungsjobs, Shopify-Bestellzuordnung - feuert gegen die Bitly-Endpunkt-URL. Dieser Endpunkt wird dunkel, wenn Sie das Bitly-Konto kuendigen oder unter die Stufe herabstufen, die Webhooks unterstuetzt. Die Webhook-Konfiguration von Bitly liegt auf Kontoebene und wird nicht mit den Linkdaten exportiert. Jeder Konsument muss manuell inventarisiert und neu ausgerichtet werden.
7. Pfadkollisionen bei Deeplinks. Mobile Deeplinks nutzen oft den Short-URL-Pfad, um den Navigationszustand der App zu kodieren - bit.ly/app/profile/edit koennte auf ein Ziel wie yourapp://profile/edit abbilden. Wenn Sie diese Slugs zu Elido migrieren, enthaelt der Slug app/profile/edit Schraegstriche. Der Router von Elido kann durch Schraegstriche getrennte Pfade anders behandeln als die opake Slug-Behandlung von Bitly. Stellen Sie sicher, dass Deeplink-Slugs mit Pfadsegmenten mit der exakten Slug-Zeichenkette angelegt werden und nicht als verschachtelte Pfade neu interpretiert werden.
Pre-Migration-Audit: nach Risikostufen segmentieren#
Die Bitly API (abgerufen am 2026-05-12) liefert Klickzahlen pro Link ueber GET /v4/bitlink/{bitlink}/clicks/summary. Bevor Sie irgendetwas exportieren und importieren, nutzen Sie das, um Ihren Bestand zu segmentieren.
Die praktische Segmentierung:
- Must-not-break-Stufe (oberstes 1 %): Links mit >=10x dem Median der Klicks in den letzten 30 Tagen. Diese sind in E-Mails, Druckerzeugnissen und bezahlten Anzeigen-Landingpages live. Sie brauchen nach dem Cutover manuelle Verifikation, nicht nur automatisierte Pruefungen.
- Monitor-Stufe (die naechsten 9 %): Links mit Klickvolumen ueber dem Median. Automatisierte 301-Verifikation reicht aus, aber markieren Sie alles, was sich unerwartet aufloest.
- Bulk-Stufe (verbleibende 90 %): Slugs mit wenig oder gar keinem Traffic. Programmgesteuert verifizieren; eine kleine Fehlerquote akzeptieren und bei Meldung korrigieren.
Exportieren Sie waehrend des Inventarisierungsschritts eine 30-Tage-Klickzusammenfassung pro Link. Eine einfache Paginierungsschleife gegen die Bitly API-Referenz (abgerufen am 2026-05-12) liefert diese Daten; das Feld link_clicks im Group-Bitlinks-Endpunkt ist der Lebenszeit-Zaehler, der groeber, aber fuer die Triage ausreichend ist:
# Paginate all links in a Bitly group and write to JSONL
NEXT_URL="https://api-ssl.bitly.com/v4/groups/${GROUP_GUID}/bitlinks?size=100"
while [ -n "$NEXT_URL" ]; do
RESP=$(curl -s -H "Authorization: Bearer ${BITLY_TOKEN}" "$NEXT_URL")
echo "$RESP" | jq -c '.links[]' >> bitly-links.jsonl
NEXT_URL=$(echo "$RESP" | jq -r '.pagination.next // empty')
done
Sortieren Sie die Ausgabe absteigend nach link_clicks. Das oberste 1 % ist Ihre Must-not-break-Stufe. Exportieren Sie deren Slugs in eine separate Datei, bevor Sie den Bulk-Import starten.
Slug-Erhaltung: der Import-Call, auf den es ankommt#
Der Bulk-Import-Endpunkt von Elido unter POST /v1/links/bulk akzeptiert ein slug-Feld pro Link. Wenn Sie es nicht explizit setzen, generiert Elido einen neuen zufaelligen Slug - das ist das falsche Verhalten fuer eine Migration. Uebergeben Sie immer den Quell-Slug.
# Bulk import with slug preservation - 100 links per call
curl -s -X POST "https://api.elido.app/v1/links/bulk" \
-H "Authorization: Bearer ${ELIDO_API_KEY}" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: mig-batch-$(date +%s)" \
-d '{
"workspace_id": "'"${WORKSPACE_ID}"'",
"domain_id": "'"${DOMAIN_ID}"'",
"links": [
{
"slug": "SummerSale",
"destination_url": "https://acme.example/summer",
"tags": ["bitly-migrated", "campaign-summer"]
},
{
"slug": "AbCd",
"destination_url": "https://acme.example/landing",
"tags": ["bitly-migrated"]
}
]
}'
Zwei Dinge sind in diesem Call zu beachten. Erstens: Die Slug-Werte sind "SummerSale" und "AbCd" - gemischte Gross-/Kleinschreibung exakt so erhalten wie in Bitly. Wandeln Sie sie nicht in Kleinbuchstaben um. Zweitens bedeutet der Idempotency-Key-Header, dass Sie einen teilweisen Batch sicher erneut ausfuehren koennen; Elido gibt den existierenden Link zurueck, statt ein Duplikat anzulegen. Das ist das korrekte Muster fuer eine Migration, die moeglicherweise fortgesetzt werden muss.
Fuehren Sie fuer die Must-not-break-Stufe den Import interaktiv pro Link statt im Batch aus und verifizieren Sie jeden Link, bevor Sie weitermachen. Fuer die Bulk-Stufe batchen Sie 100 pro Call und verarbeiten das Error-Array in der Antwort, um Slugs zu erkennen, die kollidiert sind oder fehlgeschlagen sind.
DNS-Cutover ohne Luecke#
Der DNS-Cutover ist der Moment, in dem der Live-Traffic umschwenkt. Korrekt ausgefuehrt erleben die Nutzer keine Unterbrechung. Mit einer veralteten TTL gibt es eine Luecke, die in Stunden gemessen wird, nicht in Minuten.
Die Reihenfolge ist entscheidend. Siehe das Zeitlinien-Diagramm unten.
Die Zeitlinie im Detail:
T-7 Tage: Senken Sie die TTL auf dem CNAME- oder A-Record auf 60 Sekunden. Das ist der kritische Schritt, den die meisten Teams uebersehen. RFC 1034 §3.6 (IETF datatracker, Abschnitt zum Caching von Resource Records) definiert TTL als maximale Cache-Dauer, die ein Resolver den Record halten darf. Wenn Ihre aktuelle TTL 86400 (ein Tag) betraegt, wird die Aenderung erst wirksam, nachdem die aktuell gecachte Version abgelaufen ist. Sie muessen die TTL mindestens eine volle aktuelle TTL-Periode vor dem Cutover senken. Eine Woche ist sicher; 24 Stunden sind das Minimum.
T-1 Stunde: Pruefen Sie, dass die niedrige TTL propagiert ist. Nutzen Sie ein Tool wie dig @8.8.8.8 links.yourbrand.com +ttl von mindestens drei verschiedenen Resolver-Endpunkten. Die gemeldete TTL sollte nahe 60 Sekunden liegen.
T-0: Tauschen Sie das CNAME-Ziel von Bitlys Edge auf Elidos Edge. Auf Elidos Seite sollte die Domain bereits in Ihrem Workspace registriert und verifiziert sein - schalten Sie DNS nicht um, bevor Elidos Edge bereit ist, den Traffic anzunehmen. Die erste Anfrage nach der Propagation loest die automatische On-Demand-TLS-Zertifikatsausstellung aus, die fuer diese eine Anfrage etwa 2-3 Sekunden dauert. Nachfolgende Anfragen treffen den Cache und werden am EU-Region-Edge in einstelligen Millisekunden aufgeloest.
T+5 Minuten: Fuehren Sie einen Stichproben-Check von einem zweiten Netzwerk aus durch (nutzen Sie einen Mobile-Hotspot, um den Cache des Buero-Resolvers zu umgehen). curl -sI https://links.yourbrand.com/any-known-slug sollte ein 301 Moved Permanently zurueckgeben, das auf das erwartete Ziel zeigt und aus Elidos Edge-Headern stammt.
T+1 Stunde: Stellen Sie die TTL auf ihren normalen Betriebswert (300 oder 3600 Sekunden) zurueck. Die TTL dauerhaft bei 60 Sekunden zu halten, belastet Ihren DNS-Provider und die Resolver-Infrastruktur.
T+24 Stunden: Fuehren Sie das vollstaendige Slug-Audit aus (siehe naechster Abschnitt).
Gemaess RFC 7231 §6.4.2 darf eine 301 Moved Permanently-Antwort von Zwischenstationen unbegrenzt gecacht werden, sofern kein expliziter Cache-Control-Header dies ueberschreibt. Das bedeutet: Jeder Client, der waehrend der TTL-Luecke das alte Bitly-Ziel getroffen hat, kann einen 301 gecacht haben, der auf Bitlys Infrastruktur zeigt. Diese gecachten Redirects funktionieren korrekt, solange Bitlys Infrastruktur lebt - deshalb ist das 30-taegige Bitly-Konto-Ueberlappungsfenster wichtig.
Das 301-Chain-Audit: skriptgesteuerte naechtliche Verifikation#
Fahren Sie nach dem Cutover eine naechtliche Verifikationsschleife ueber Ihre Must-not-break-Stufe. Ziel ist es, jeden Slug zu erwischen, dessen Verhalten sich geaendert hat - sei es, dass er ein unerwartetes Ziel zurueckgibt, einen 404 liefert oder eine Redirect-Kette laenger als zwei Hops aufbaut.
# Verify top slugs resolve correctly via Elido
# top-slugs.txt: one slug per line, no protocol prefix
DOMAIN="links.yourbrand.com"
FAIL=0
while IFS= read -r slug; do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
--max-redirs 0 \
"https://${DOMAIN}/${slug}")
LOCATION=$(curl -s -I --max-redirs 0 \
"https://${DOMAIN}/${slug}" \
| grep -i '^location:' | tr -d '\r' | cut -d' ' -f2)
if [ "$STATUS" != "301" ]; then
echo "FAIL [$STATUS] $slug → expected 301"
FAIL=$((FAIL + 1))
else
echo "OK [301] $slug → $LOCATION"
fi
done < top-slugs.txt
echo "---"
echo "Failures: $FAIL"
exit $FAIL
Fahren Sie dies gegen die Must-not-break-Stufe (typischerweise 50-200 Slugs fuer die meisten Teams) jede Nacht waehrend der ersten zwei Wochen nach dem Cutover. Leiten Sie die Ausgabe in Ihren Alerting-Kanal. Wenn FAIL ungleich Null ist, soll sich ein Mensch das ansehen, bevor der Morgen-Traffic Spitzen erreicht.
Das Flag --max-redirs 0 ist Absicht: Sie wollen Elidos Redirect, nicht das Endziel. Wenn der Status 200 statt 301 lautet, liefert etwas auf Elidos Seite das Ziel direkt aus, statt umzuleiten - das bedeutet, dass der Slug auf einen Link aufgeloest wurde, der als direkter Pass-Through konfiguriert ist. Das ist eine Untersuchung wert.
Fuehren Sie fuer die Monitor-Stufe einen leichteren woechentlichen Scan aus. Verlassen Sie sich fuer die Bulk-Stufe auf Fehlermeldungen aus nachgelagerten Systemen - kaputte Links in E-Mails erzeugen Aenderungen bei der Bounce-Rate, die Ihre E-Mail-Plattform an die Oberflaeche bringt.
Webhook-Neuverkabelung#
Bitly-Webhooks sind unter der Bitly API-Referenz (abgerufen am 2026-05-12) im Webhooks-Abschnitt dokumentiert. Jeder Webhook feuert bei Click-Events und enthaelt die Felder bitlink, referrer und user-agent. Gaengige Konsumenten:
- Shopify: Attributions-Apps, die nachverfolgen, welcher Short-Link eine Conversion verursacht hat. Konfiguriert im Admin-Panel der Shopify-App, mit Verweis auf einen Drittanbieter-Endpunkt, der Bitlys Webhook-Verifikation aufruft.
- Stripe: Manche Billing-Attributions-Pipelines markieren eingehende Trial-Anmeldungen mit den UTM-Daten des urspruenglichen Short-Links, bezogen ueber den Bitly-Webhook.
- Slack: Link-Performance-Bots, die Klickzusammenfassungen in einen
#marketing-Kanal posten. - Eigene ETL-Pipelines: jede Data-Warehouse-Pipeline, die Bitly-Click-Events fuer Anreicherung oder Attributions-Joins aufnimmt.
Die Migrations-Checkliste fuer Webhooks:
- Exportieren Sie Ihre Bitly-Webhook-Konfiguration, bevor Sie irgendwelche Kontoaenderungen vornehmen. Die Bitly-API
GET /v4/workspaces/{workspace_guid}/webhooksliefert die Liste. Speichern Sie sie in einer Datei. - Identifizieren Sie pro Konsumenten die Endpunkt-URL, die Bitly-Events empfaengt, sowie das Secret fuer die HMAC-Verifikation.
- Richten Sie den entsprechenden Elido-Webhook-Endpunkt ein. Elidos Webhook-Payloads haben ein anderes Schema als die von Bitly - die Felder sind aehnlich, aber nicht identisch. Passen Sie den Handler des Konsumenten an das neue Schema an.
- Lassen Sie beide Webhooks waehrend des Ueberlappungsfensters parallel laufen. Konfigurieren Sie Elido so, dass es ab dem Cutover-Tag Webhooks feuert, und halten Sie gleichzeitig den Bitly-Webhook aktiv. Ihr Konsument erhaelt waehrend der Ueberlappung zwei Events pro Klick - dedup-en Sie ueber Short-URL + Zeitstempel oder akzeptieren Sie Doppelzaehlung waehrend des Ueberlappungsfensters als bekanntes Artefakt.
- Entfernen Sie nach 72 Stunden bestaetigter Elido-Webhook-Zustellung die Bitly-Webhook-Konfiguration aus jedem Konsumenten.
Das Karenzfenster fuer die Secret-Rotation ist der Ueberlappungszeitraum. Rotieren Sie das Elido-Webhook-Secret erst, wenn jeder Konsument verifiziert wurde. Das Secret zu rotieren, bevor ein Konsument aktualisiert ist, fuehrt dazu, dass dieser Konsument Events stillschweigend verwirft, ohne einen Fehler - die HMAC-Pruefung schlaegt fehl, und die meisten Webhook-Handler verwerfen Payloads mit ungueltiger Signatur, ohne zu alarmieren.
Rollback-Plan: Bitly 30 Tage am Leben halten#
Die Rollback-Prozedur ist einfach: setzen Sie den DNS-CNAME auf das Bitly-Ziel zurueck. Da Sie die TTL-Absenkung vorbereitet haben und der DNS-Record noch bei 60 Sekunden steht (bis Sie ihn wiederherstellen), propagiert ein DNS-Rollback in unter zwei Minuten.
Halten Sie den Rollback-Befehl bereit, bevor Sie starten:
# Rollback script - run this to revert DNS to Bitly (adapt for your DNS provider)
# Route 53 example using AWS CLI
aws route53 change-resource-record-sets \
--hosted-zone-id "${HOSTED_ZONE_ID}" \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "links.yourbrand.com",
"Type": "CNAME",
"TTL": 60,
"ResourceRecords": [{"Value": "cname.bitly.com"}]
}
}]
}'
Halten Sie dies in einer Datei auf Ihrem Laptop und an einem gemeinsam genutzten Runbook-Ort vor dem Cutover bereit. Der schlechteste Moment, um Infrastrukturbefehle zu schreiben, ist waehrend eines aktiven Vorfalls.
Halten Sie das Bitly-Konto aktiv und auf einem kostenpflichtigen Plan, der die Linkaufloesung 30 Tage nach dem Cutover sicherstellt. Das migrate-from-bitly-playbook empfiehlt 90 Tage; 30 sind das praktische Minimum fuer Teams, die Kosten kontrollieren muessen. Waehrend des 30-Tage-Fensters funktioniert jeglicher Traffic, der noch ueber Bitly aufgeloest wird (gecachte Redirects, alte bit.ly-Links in Druckerzeugnissen), weiterhin. Werten Sie nach 30 Tagen den verbleibenden Bitly-Traffic in Ihrer Analyse aus und entscheiden Sie, ob verlaengert werden soll.
Was waehrend des 30-Tage-Fensters zu ueberwachen ist:
- Elidos Fehlerrate auf Ihrer Custom-Domain (achten Sie auf unerwartete 404s im Access-Log).
- Spitzen im Traffic zu Bitly (das Bitly-Dashboard zeigt Traffic an; eine Spitze kann bedeuten, dass ein gecachter Redirect noch immer ueber Bitly fuer einen High-Volume-Slug aufgeloest wird).
- Fehlerraten der Webhook-Konsumenten fuer alle Konsumenten, die Sie neu verkabelt haben.
Post-Migration-Audit: was zu protokollieren ist#
Fuehren Sie nach dem 30-Tage-Fenster einen finalen Audit-Durchlauf durch. Was ins Audit-Log gehoert:
| Pruefung | Methode | Bestehenskriterium |
|---|---|---|
| Slug-Anzahl stimmt ueberein | wc -l bitly-export.jsonl vs. Elido-API-Zaehlung | innerhalb von 1 % (bewusst entfernte archivierte Links beruecksichtigt) |
| Must-not-break-Stufe 301-Check | Naechtliches Audit-Skript | Null Fehlschlaege ueber 7 aufeinanderfolgende Tage |
| Klickvolumen-Abgleich | Elido-30-Tage-Klicksumme vs. Bitly-30-Tage-Summe aus gleichem Zeitraum im Vorjahr | innerhalb erwarteter saisonaler Schwankung |
| Webhook-Konsumenten-Bestaetigung | Pruefen, dass jeder Konsument Elido-Events empfaengt und korrekt verarbeitet | keine stillen Verluste fuer 7 Tage |
| DNS-TTL wiederhergestellt | dig +ttl links.yourbrand.com | TTL auf Betriebswert (300+ Sekunden) |
Protokollieren Sie dies in der Audit-Tabelle Ihres Teams. Wenn Ihr Workspace auf einem Business- oder Enterprise-Plan liegt, erfasst Elidos Audit-Log alle API-Operationen waehrend des Imports und ist ueber die API abfragbar. Ziehen Sie die Import-Batch-Datensaetze und speichern Sie einen Snapshot neben dieser Tabelle.
Haeufige Stolperfallen: drei Muster aus der Praxis#
Die DACH-E-Commerce-Marke, die eine Woche E-Mail-Attribution verlor. Ein Haendler in Deutschland fuhr eine Newsletter-Kampagne mit Bitly-Slugs und je Abonnent angehaengten UTMs zum Versandzeitpunkt. Das Migrationsskript normalisierte alle Slugs auf Kleinbuchstaben, bevor sie in Elido importiert wurden. Nach dem Cutover erzeugte die E-Mail-Plattform Links mit den urspruenglichen, gemischten Slugs. Diese Links lieferten 404 von Elido, weil die Slug-Schreibweise nicht uebereinstimmte. Die Loesung war, den Import mit Schreibweisen-erhaltenden Slugs erneut zu fahren, aber bis dahin waren sieben Tage E-Mail-Traffic auf 404s gelandet. Die Attribution war fuer diese Kohorte nicht mehr rekonstruierbar. Die Lehre: testen Sie einen Live-Link aus jedem aktiven Kanal, bevor Sie die Migration fuer abgeschlossen erklaeren.
Das SaaS-Startup, das mobile Nutzer dreifach weiterleitete. Ein Growth-Team hatte eine Bitly-Custom-Domain im Proxy-Modus (orange-cloud) vor Cloudflare. Nach dem Cutover bekamen mobile Nutzer drei Redirects: Cloudflare → Elido Edge → Ziel. Der zusaetzliche Hop kam von einer Cloudflare-Page-Rule, die HTTP zu HTTPS umschrieb, bevor sie an Elido uebergab, woraufhin Elido seinen eigenen 301 ausstellte. iOS Safari cachte den zwischengeschalteten Cloudflare-Redirect 30 Tage lang als permanenten Redirect. Die Loesung war, den Cloudflare-Record auf grey-cloud (nur DNS) zu setzen und die konfliktierende Page-Rule zu entfernen. Die in Safari gecachten Redirects brauchten 30 Tage, bis sie auf natuerlichem Weg abliefen. Pruefen Sie Ihren CDN-Proxy-Modus vor dem Cutover, nicht danach.
Die Agentur, die eine Bitly-Gruppe uebersah. Eine Agentur managte drei Kundenmarken unter einem einzigen Bitly-Konto, jede unter einer anderen Bitly-Gruppe mit eigener Custom-Domain. Das Migrationsskript fragte nur die Default-Gruppe ab - diejenige, unter der der API-Benutzer-Token erstellt worden war. Zwei Kundendomains wurden sauber migriert. Die dritte, unter einer Sekundaergruppe, wurde nie exportiert. Nach dem Cutover ging eine Produkteinfuehrungs-E-Mail-Kampagne raus, die auf die nicht migrierte Custom-Domain zeigte. Die Domain hatte den Bitly-CNAME immer noch mit voller TTL, und Bitly lieferte die Links korrekt aus - aber das Cutover-Fenster fuer diese Domain war fuer abgeschlossen erklaert worden. Es folgte eine komplette Neumigration unter Termindruck. Die Lehre: zaehlen Sie vor jedem Exportschritt alle Gruppen ueber GET /v4/user/groups auf. Pruefen Sie, dass der Token Zugriff auf jede Gruppe hat.
Wie es weitergeht#
Das migrate-from-bitly-playbook deckt die vollstaendige strategische Sequenz fuer Teams ab, die bei der Migrationsplanung bei Null anfangen. Dieser Beitrag ist der Fehlermodi-Begleiter - verwenden Sie sie zusammen.
Fuer die Produktseite dessen, wohin Sie migrieren, behandelt die Seite solutions/marketers die Attributions- und Kampagnen-Tracking-Funktionen, auf die die meisten Migrationsprojekte abzielen. Die Seite /compare/vs-bitly ist die Feature-Paritaets-Referenz, falls Sie noch bestaetigen, ob der Wechsel sich lohnt.
Wenn Sie Elido neben Rebrandly oder Short.io evaluieren, behandelt der elido-vs-bitly-Vergleich Preis- und Feature-Abwaegungen bei vier Traffic-Volumina. Die Custom-Domains-Feature-Seite dokumentiert die Mechanik der DNS-Verifikation und TLS-Bereitstellung im Detail - lesenswert vor Ihrem DNS-Cutover-Fenster.
Migrationsfehler sind fast immer vermeidbar. Das Audit-Skript, die TTL-Disziplin und das Webhook-Inventar erfordern zwei Stunden Arbeit vor dem Cutover. Sie sparen Tage Incident-Response danach.
Quellen und Zitate
- Bitly API Reference - dev.bitly.com/api-reference, abgerufen am 2026-05-12
- RFC 1034 - Domain Names: Concepts and Facilities, §3.6 (resource record caching) - datatracker.ietf.org/doc/html/rfc1034
- RFC 7231 §6.4.2 - HTTP/1.1 Semantics and Content: 301 Moved Permanently - datatracker.ietf.org/doc/html/rfc7231#section-6.4.2
- Bitly API - Groups and Bitlinks endpoints - dev.bitly.com/api-reference, abgerufen am 2026-05-12
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag