Rebrandly jest zbudowany wokół jednej centralnej abstrakcji: domeny brandowanej. Slashtagi, taksonomie tagów i reguły Traffic Routing wszystkie opierają się na niej. To właśnie ta decyzja projektowa sprawia, że Rebrandly jest spójnym produktem - i to ona sprawia, że migracja z niego różni się od jakiegokolwiek innego przeprowadzki między skracaczami URL.
Wychodząc z Rebrandly, nie migrujesz przede wszystkim linków. Migrujesz domenę. Linki przenoszą się razem z nią, a szczegóły dotyczące ich zachowania zależą prawie wyłącznie od tego, co zdecydujesz się zrobić z domeną.
Ten artykuł omawia dwie realistyczne ścieżki, strukturę eksportu z API Rebrandly, wywołanie importu masowego do Elido oraz proces walidacji przed ogłoszeniem przełączenia.
TL;DR#
- Kluczowa abstrakcja Rebrandly to domena brandowana. Migracja to najpierw przekazanie DNS, a dopiero potem zachowanie linków.
- Ścieżka A: domena pozostaje ta sama, zmienia się tylko skracacz. Wstępnie przygotuj slugi w Elido, przełącz CNAME - gotowe.
- Ścieżka B: zmienia się też domena. Potrzebujesz albo łańcucha 301 ze starej domeny (plan Pro w Rebrandly), albo akceptujesz zmianę sluga na nowej domenie.
- Tagi Rebrandly mapują się bezpośrednio na tagi Elido. Kategorie Rebrandly wymagają ręcznego mapowania - nie mają bezpośredniego odpowiednika.
Co musisz najpierw zinwentaryzować#
Przed podjęciem decyzji o wyborze ścieżki, oceń cztery rzeczy.
Domena lub domeny brandowane. Model workspace Rebrandly pozwala na wiele niestandardowych domen na konto. W workspace agencji lub wielomarkowym każda domena jest osobną jednostką migracji. Wylistuj je przed planowaniem okien przełączenia - jedna domena na noc to bezpieczniejszy harmonogram niż wszystkie naraz.
Aktywne linki. Używaj Rebrandly REST API (dostęp: 2026-05-12) zamiast eksportu CSV dla dużych zasobów. Endpoint /v1/links paginuje parametrami zapytania last i limit i zwraca pełny obiekt linku, w tym slashtag, cel, nazwę domeny, zestaw tagów i createdAt. Eksport CSV z panelu ustawień workspace jest odpowiedni dla poniżej kilkuset linków, ale w przypadku większych eksportów niespójnie obcina pola.
Integracje. Jeśli Twój zespół tworzy linki przez przepływy Zapier, Make lub Workato, te konektory wskazują na API Rebrandly. Każdy musi zostać przekierowany. Jest to osobne zadanie od migracji linków, z własnym oknem karencji. Zajmij się tym po przełączeniu DNS, nie przed.
Taksonomia tagów i kategorii. Rebrandly obsługuje zarówno dowolne tagi, jak i ustrukturyzowane kategorie. Tagi mapują się jeden do jednego na tagi Elido. Kategorie nie mają bezpośredniego odpowiednika w Elido - najbliższe mapowanie to zarezerwowany prefiks tagu (cat:campaign, cat:region), który stosujesz podczas importu. Uzgodnij mapowanie przed uruchomieniem skryptu, nie po.
Ścieżka A: domena pozostaje, skracacz się zmienia#
To czystsza migracja. Zachowujesz go.acme.com (lub jakkolwiek nazywa się Twoja brandowana domena skracająca). Wstępnie przygotowujesz każdy slug w Elido pod tą samą domeną, a następnie przełączasz CNAME. Z perspektywy kliknięcia linku nic się nie zmienia - slug rozwiązuje się do tego samego docelowego URL, tylko przez inny edge.
Krok 1: eksport z Rebrandly#
Paginuj Rebrandly API /v1/links. Obiekty odpowiedzi zawierają slashtag, destination, domain.fullName, tags[], category.name i createdAt. Zapisuj jako JSONL.
Dwie rzeczy wymagają ostrożności. Po pierwsze, domain.fullName - jeśli Twój workspace ma więcej niż jedną domenę, przefiltruj do tej, którą migrujesz w tym przebiegu. Po drugie, poziomy cenowe Rebrandly (dostęp: 2026-05-12) ograniczają liczbę aktywnych linków i niestandardowych domen na konto. API zwraca wszystkie linki bez wyjątku; Twój zasób może obejmować linki na domenach, które już wycofałeś. Wyklucz je przed importem.
Krok 2: wstępne przygotowanie w Elido#
Zarejestruj domenę w swoim workspace Elido przez przepływ niestandardowych domen przed dokonywaniem jakichkolwiek zmian DNS. Domena nie musi jeszcze być aktywna. Elido weryfikuje własność domeny przez rekord TXT DNS; możesz to zakończyć bez zakłócania istniejącego CNAME wskazującego na Rebrandly.
Po zarejestrowaniu domeny importuj masowo linki. Endpoint POST /v1/links/bulk akceptuje do 100 linków na wywołanie i zwraca status powodzenia/niepowodzenia per element, więc konflikt sluga w jednym wierszu nie przerywa całej partii. Podaj slug jawnie, aby zachować slashtag Rebrandly. Mapuj tags[] z Rebrandly bezpośrednio na tags[] Elido. Podaj created_at, aby zachować oryginalny znacznik czasu tworzenia do historycznego sortowania.
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"
}
]
}'
Tag rebrandly-migrated jest przydatny do filtrowania analitycznego po przełączeniu - możesz segmentować linki sprzed migracji od linków tworzonych natywnie w Elido i porównywać trendy kliknięć przez pierwsze 30 dni.
W przypadku mapowania taksonomii kategorii: jeśli summer-promo znajdował się w kategorii Rebrandly o nazwie Campaigns, dodaj cat:campaigns do tablicy tags. Nie jest to semantycznie równoważne, ale daje Ci filtr w widokach analitycznych i dashboardowych Elido. Udokumentuj mapowanie w notatkach migracyjnych.
Najpierw wykonaj dry-run. Większość zespołów uruchamia import masowy na staging workspace lub z małą próbką (10-20 linków) przed wysłaniem pełnego zasobu. Powierzchnia odpowiedzi per element w endpoincie masowym wyraźnie pokaże konflikty slugów lub błędy walidacji celu, zanim zatwierdzisz cały eksport.
Krok 3: przełączenie DNS#
To jest ten moment. Przed dotarciem tutaj sprawdź:
- Wszystkie slugi w imporcie masowym zwróciły status sukcesu. Żadnych niezakończonych niepowodzeń.
- Domena jest zarejestrowana i TLS jest wystawiony w Twoim workspace Elido. Przetestuj jeden slug bezpośrednio na edge Elido, tymczasowo dodając CNAME do testowej subdomeny, nie produkcyjnej.
- Istniejący TTL CNAME Rebrandly został obniżony. Strona cenowa Rebrandly (dostęp: 2026-05-12) pokazuje, że konfiguracja DNS jest dostępna od planu Free wzwyż - możesz obniżyć TTL bez ulepszania. Obniż go do 300 sekund co najmniej 24 godziny przed oknem przełączenia.
Gdy okno się otwiera, zamień cel CNAME:
go.acme.com. 300 IN CNAME edge.elido.me.
Edge Elido używa automatycznego TLS na żądanie. Jeśli TLS był już wystawiony podczas wstępnej walidacji (zalecane), pierwsze żądanie po propagacji DNS jest szybkie. Jeśli nie, certyfikat jest wystawiany przy pierwszym żądaniu - zazwyczaj 1-3 sekundy, a następnie certyfikat jest buforowany i kolejne żądania są obsługiwane z p95 poniżej 15ms z brzegu w regionie UE.
Zweryfikuj z wielu resolverów przed zamknięciem okna zmiany. Sprawdzenie propagacji z biurka potwierdza tylko Twój resolver. Narzędzia takie jak dig @8.8.8.8 go.acme.com CNAME i dig @1.1.1.1 go.acme.com CNAME wychwytują typowe rozbieżności.
Ścieżka B: zmienia się też domena#
Niektóre zespoły traktują migrację jako okazję do zmiany nazwy domeny brandowanej - z brand.ly (subdomeny przypisanej przez Rebrandly) na coś, co w pełni posiadają, lub z jednej domeny brandowej na inną po rebrandingu. Inni byli na subdomenie Rebrandly (yourname.rebrandly.com) i nigdy nie skonfigurowali niestandardowej domeny.
W obu przypadkach przestrzeń slugów się zmienia. Pytanie brzmi, czy możesz zainstalować łańcuch 301 ze starej domeny, aby zminimalizować utratę linków.
Opcja B1: łańcuch 301 ze starej domeny Rebrandly#
Funkcja Traffic Routing Rebrandly - dostępna w planie Pro - pozwala przekierować całą domenę na nowy bazowy URL. Jeśli posiadasz starą domenę i chcesz przekazywać ruch, możesz skonfigurować w Rebrandly przekierowanie wildcard, które przekazuje wszystkie żądania go.old-domain.com/* do go.new-domain.com/* z dopasowaniem slugów.
RFC 7231 §6.4.2 definiuje semantykę 301 Moved Permanently: klienci otrzymujący 301 powinni zaktualizować wszelkie przechowywane URL-e do nowej lokalizacji. W praktyce oznacza to, że istniejące kody QR, materiały drukowane i opublikowane linki będą prawidłowo przekierowywać podczas okresu nakładania się. To najbliższe, co możesz uzyskać od przezroczystej migracji przy zmianie domeny.
Mechanika: utrzymuj starą domenę aktywną na Rebrandly podczas okresu nakładania się, skonfigurowaną jako przekaźnik. Uruchom nową domenę na Elido od pierwszego dnia migracji. Po 30-90 dniach (w zależności od tego, jak długo Twoje opublikowane materiały pozostają w obiegu), wycofaj starą domenę na Rebrandly.
Opcja B2: zaakceptuj zmianę sluga#
Jeśli stara domena była subdomeną przypisaną przez Rebrandly (yourname.rebrandly.com) lub domeną, nad którą nie masz już kontroli DNS, łańcuch 301 nie jest dostępny. Linki na starej domenie będą nadal działać, dopóki Rebrandly działa i utrzymujesz aktywne konto. Ruch na tych starych linkach nie jest kierowany przez Elido; tracisz pokrycie analityczne.
Praktyczne podejście: zmigruj listę linków do Elido na nowej domenie, utwórz nowe slugi dla linków o najwyższym ruchu i zaktualizuj opublikowane powierzchnie, które mają znaczenie, a resztę długiego ogona starych linków o niskim ruchu pozostaw do wygaśnięcia na Rebrandly. migrate-from-bitly-playbook obejmuje ten sam framework decyzyjny dla migracji z Bitly - rozumowanie ma tu zastosowanie.
Dla zespołów wybierających między opcją B1 a B2, rachunek jest następujący: ile opublikowanych powierzchni zawiera stare linki, jak trudno je zaktualizować i jak długo ruch będzie trafiał na te powierzchnie. Linki w archiwach e-mailowych o dużym ruchu i materiały drukowane przemawiają za B1. Kilka wewnętrznych dokumentów przemawia za B2.
Eksport Rebrandly: co dostajesz, a czego nie#
Rebrandly API (dostęp: 2026-05-12) eksportuje następujące pola per link przez /v1/links:
id- wewnętrzne ID linku Rebrandly (nie potrzebne przy imporcie, ale przydatne jako klucz idempotentności)slashtag- slug do zachowaniadestination- pełny docelowy URL, w tym parametry UTMdomain.fullName- nazwa hosta niestandardowej domenytags[]- dowolne tagi; mapuj bezpośrednio na tagi Elidocategory.name- etykieta kategorii; mapuj ręcznie na prefiks tagucreatedAt,updatedAt- znaczniki czasu; podajcreatedAtdo polacreated_atElidoclicks.total- łączna liczba kliknięć dożywotnich; nie można importować do analityki Elido, ale warto przechowywać w tagu (clicks-baseline-1234) lub we własnej warstwie danych
Czego API nie eksportuje:
- Surowych zdarzeń kliknięć. Rebrandly nie udostępnia rekordów per kliknięcie - otrzymujesz tylko zagregowane liczby. Zegar analityczny startuje od zera w Elido od dnia przełączenia.
- Reguł Traffic Routing. Jeśli skonfigurowałeś warunkowe przekierowania na jakichkolwiek linkach (routing według urządzenia lub geolokalizacji), te reguły muszą zostać ręcznie odtworzone w edytorze smart linków Elido po imporcie. Nie ma masowego importu reguł routingu.
- Uprawnień członków zespołu. Dostęp do workspace musi zostać ponownie zaproszony w Elido.
Brak surowych zdarzeń kliknięć to to samo ograniczenie, z którym spotykasz się migrując z Bitly bez przerw w linkach. Wzorzec obsługi jest taki sam: przechowuj dożywotni licznik Rebrandly, śledź kliknięcia Elido od przełączenia do przodu i łącz je przy raportowaniu łącznych danych historycznych.
Przepinanie webhooków: Zapier, Make, Workato#
Jeśli którekolwiek z Twoich przepływów automatyzacji tworzy linki Rebrandly, muszą zostać przepięte: wyzwalacz CRM mintujący link śledzący per prospect, Zap skracający linki z arkusza kalkulacyjnego, scenariusz Make generujący kody QR dla wydarzeń.
Mechanizm różni się w zależności od platformy. W Zapier znajdź każdy Zap używający aplikacji Rebrandly i zastąp krok akcji albo aplikacją Zapier dla Elido (sprawdź dostępność przy uruchomieniu), albo akcją Webhook bezpośrednio wywołującą POST /v1/links. W Make i Workato obowiązuje ta sama zamiana.
Dwie rzeczy należy tu prawidłowo uszeregować. Po pierwsze, nie przepinaj automatyzacji, dopóki przełączenie DNS i masowy import nie zostaną potwierdzone. Uruchomienie automatyzacji na Elido przed zakończeniem wstępnego przygotowania tworzy konflikty duplikatów slugów. Po drugie, dodaj klucz API Elido do magazynu danych uwierzytelniających każdej platformy automatyzacji przed przełączeniem - zrób to z wyprzedzeniem, a nie podczas okna przełączenia.
Okno karencji: dla automatyzacji tworzącej linki z małą częstotliwością (kilka tygodniowo), pozostawienie jej na Rebrandly przez 1-2 tygodnie po przełączeniu DNS jest niskim ryzykiem. Linki, które tworzy, będą na starej platformie, ale DNS jest już przełączony, więc te linki będą rozwiązywać się przez Elido. W przypadku automatyzacji o wysokiej częstotliwości tworzącej dziesiątki linków dziennie, migruj ją w dniu przełączenia.
Aby zapoznać się z API Elido i dostępnymi SDK, strona cennika obejmuje limity planów, a pełna referencja API jest dostępna pod /help. Dostępne są SDK dla TypeScript, Python i Go.
Walidacja przed ogłoszeniem przełączenia#
Nie ogłaszaj zakończenia migracji, dopóki nie wykonasz ustrukturyzowanego wyrywkowego sprawdzenia. Dwie rzeczy psują się cicho: docelowe URL-e, które miały problemy z kodowaniem w eksporcie, oraz slugi, które weszły w konflikt podczas importu masowego i zostały pominięte.
Sprawdzenie top-100 slugów#
Posortuj wyeksportowaną listę linków według clicks.total malejąco. Weź top 100. Dla każdego z nich wyślij żądanie HEAD na URL hostowany przez Elido i sprawdź, czy nagłówek Location pasuje do oczekiwanego celu:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
"https://go.acme.com/summer-promo"
Odpowiedź 301 z prawidłowym docelowym URL potwierdza, że slug działa. 404 oznacza, że albo slug nie był wstępnie przygotowany (sprawdź log odpowiedzi importu masowego), albo wystąpiła niezgodność wielkości liter. Slashtagi Rebrandly są niewrażliwe na wielkość liter przy rozwiązywaniu; slugi Elido są wrażliwe na wielkość liter przy tworzeniu. Jeśli Twój eksport ma slashtagi z mieszaną wielkością liter, znormalizuj je do małych liter przed importem.
30-dniowy plan wycofania#
Utrzymuj konto Rebrandly aktywne przez 30 dni po przełączeniu DNS. Zmiana DNS jest w pełni odwracalna w dowolnym momencie podczas tego okna - wskaż CNAME z powrotem na edge Rebrandly, a stare linki znów działają. Po 30 dniach, jeśli analityka pokazuje zero anomalii w wskaźniku powodzenia przekierowań i sprawdzenie slugów przeszło pomyślnie, konto Rebrandly można bezpiecznie obniżyć lub anulować.
Jeśli chodzi o domenę: nie przenoś domeny od aktualnego rejestratora podczas okna migracji. Zmiana CNAME to jedyna operacja DNS, która jest wymagana. Transfer rejestratora dodaje ryzyko propagacji, które jest zbędne podczas przełączenia.
Kontekst wewnętrzny migracji#
Mechanika tej migracji jest analogiczna do playbooka Bitly. Wzorce DNS, terminy TTL i podejście do zachowania slugów są takie same. Jeśli oceniasz migrację na poziomie funkcji przed podjęciem decyzji o pracy migracyjnej, porównanie elido-vs-rebrandly szczegółowo omawia różnice w modelu cenowym i lukę w zakresie rezydencji danych w UE. Dokumentacja konfiguracji niestandardowych domen pod /features/custom-domains obejmuje stronę Elido w zakresie weryfikacji DNS i wystawiania TLS. A /pricing zawiera aktualne limity planów - wstępne przygotowanie dużego zasobu Rebrandly wymaga odpowiedniego planu przed rozpoczęciem importu.
Cytowania: dokumentacja Rebrandly API dostęp: 2026-05-12. Strona cenowa Rebrandly dostęp: 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie