Ana Kowalska jest inżynierem rozwiązań w Elido i przeprowadziła kilkanaście projektów migracyjnych przez przełączenie z Bitly. Uważa, że większości problemów można uniknąć, przeprowadzając audyt przed migracją, a nie po niej.
Artykuł migrate-from-bitly-playbook omawia strategiczną całość: sprawdź co masz, wyeksportuj, zaimportuj, przełącz DNS. To właściwe miejsce na start, jeśli nigdy wcześniej nie migrowałeś z Bitly.
Ten artykuł jest inny. Skupia się na tym, co się psuje - konkretnych trybach awarii, które pojawiają się po tym, jak plan koncepcyjny jest gotowy i naprawdę uruchamiasz migrację na danych produkcyjnych. Siedem z nich pojawia się regularnie, a wszystkich siedmiu można zapobiec, jeśli wiesz, czego szukać.
TL;DR#
- Slugi Bitly są wrażliwe na wielkość liter; wiele platform przekierowań takie nie jest.
bit.ly/AbCdibit.ly/abcdto różne linki w Bitly i będą zachowywać się inaczej, jeśli skrypt migracyjny zamieni slugi na małe litery podczas importu. - Luki w TTL DNS powodują przerwy w przekierowaniach nawet po przełączeniu CNAME. Obniż TTL do 60 sekund co najmniej 24 godziny przed przełączeniem, nie pięć minut wcześniej.
- Webhooki wskazujące na endpointy
api-ssl.bitly.comprzestają działać w momencie anulowania lub dezaktywacji konta Bitly. Przepnij wszystkich konsumentów downstream przed zmianą statusu konta. - Deeplinki z segmentami ścieżki (
bit.ly/app/account/settings) kolidują z regułami routingu Elido, które również dopasowują się do prefiksu ścieżki. Audytuj slugi deeplinków oddzielnie od standardowych slugów przekierowań.
Siedem rzeczy, które naprawdę się psują#
Zanim omówimy narzędzia, warto mieć przed sobą taksonomię awarii. Większość postmortemów migracyjnych wskazuje na jeden z poniższych problemów:
1. Wrażliwość slugów na wielkość liter. Bitly zachowuje wielkość liter w slugach - bit.ly/SummerSale i bit.ly/summersale to odrębne linki. Jeśli skrypt importu normalizuje slugi do małych liter (częste domyślne zachowanie bibliotek obsługujących URL-e), cicho tworzysz zły slug i wariant z wielkimi literami zwraca 404. Dotyczy to kampanii e-mailowych, w których slug był osadzony z mieszaną wielkością liter.
2. Zachowanie końcowego ukośnika. bit.ly/campaign/ i bit.ly/campaign są w routerze Bitly obsługiwane jako ten sam link. Niektóre platformy traktują wariant z końcowym ukośnikiem jako odrębną ścieżkę. Jeśli workspace w Elido jest poprzedzony odwrotnym proxy z włączoną ścisłą normalizacją URL, żądanie z końcowym ukośnikiem może rozwiązać się inaczej niż kanoniczny slug.
3. Zachowanie ciągu zapytania. Jeśli docelowy URL linku Bitly już zawiera parametry zapytania - https://acme.example/landing?source=bitly - a kliknięcie przynosi również parametry UTM dołączone w momencie udostępnienia, musisz sprawdzić, czy scalanie docelowych wartości zachowuje się identycznie w Elido. Domyślne zachowanie Bitly dla dołączonych UTM polega na scalaniu ich z istniejącym ciągiem zapytania. Przetestuj to jawnie dla każdego linku, którego docelowy URL już zawiera parametry.
4. Dołączanie UTM na poziomie platformy. Wariant Enterprise Bitly obsługuje dołączanie UTM na poziomie workspace: do każdego wychodzącego przekierowania jest dodawany UTM, niezależnie od tego, co zawiera oryginalny docelowy URL. Jeśli miałeś to włączone w Bitly i nie udokumentowałeś tego, możesz mieć analitykę zależną od UTM-ów, których Elido jeszcze nie dołącza. Sprawdź ustawienia workspace w Bitly pod kątem reguł auto-dołączania przed eksportem. Odpowiednikiem w Elido są szablony UTM na poziomie workspace lub kampanii - strona funkcji custom domains opisuje, gdzie znajduje się ta konfiguracja.
5. Luka TTL DNS. To najczęstsza przyczyna przerwy w przekierowaniach podczas przełączania. Resolvery DNS buforują stary CNAME przez czas trwania aktualnego TTL. Jeśli Twój TTL wynosił 86400 sekund przez dwa lata, zmiana go na 300 sekund pięć minut przed przełączeniem rekordu A oznacza, że większość resolverów nadal przechowuje stary rekord przez kolejne 23 godziny i 55 minut. Przełączenie nie jest natychmiastowe - propaguje się.
6. Przepinanie webhooków. Każdy system konsumujący zdarzenia webhooków Bitly - potoki analityczne, zadania wzbogacania CRM, atrybucja zamówień Shopify - jest skierowany na URL endpointu Bitly. Ten endpoint przestaje działać, gdy anulujesz lub obniżysz konto Bitly poniżej tier obsługującego webhooki. Konfiguracja webhooków Bitly znajduje się na poziomie konta i nie jest eksportowana razem z danymi linków. Każdy konsument musi zostać zinwentaryzowany i ręcznie przepięty.
7. Kolizje ścieżek deeplinków. Mobilne deeplinki często używają ścieżki krótkiego URL do kodowania stanu nawigacji aplikacji - bit.ly/app/profile/edit może mapować się na cel taki jak yourapp://profile/edit. Gdy migrujesz te slugi do Elido, slug app/profile/edit zawiera ukośniki. Router Elido może traktować ścieżki oddzielone ukośnikami inaczej niż nieprzezroczystą obsługę slugów przez Bitly. Sprawdź, czy slugi deeplinków z segmentami ścieżki są tworzone z dokładnym ciągiem slug, a nie reinterpretowane jako zagnieżdżone ścieżki.
Audyt przedmigracyjny: segmentacja według poziomu ryzyka#
Bitly API (dostęp: 2026-05-12) udostępnia liczbę kliknięć na link przez GET /v4/bitlink/{bitlink}/clicks/summary. Zanim cokolwiek wyeksportujesz i zaimportujesz, użyj tego do segmentacji swojego zasobu.
Praktyczna segmentacja:
- Tier "musi działać" (górne 1%): linki z ≥10× medianową liczbą kliknięć w ciągu ostatnich 30 dni. Są aktywne w e-mailach, materiałach drukowanych, stronach docelowych płatnych reklam. Wymagają ręcznej weryfikacji po przełączeniu, nie tylko automatycznych sprawdzeń.
- Tier monitorowany (kolejne 9%): linki z ponadmedianowym wolumenem kliknięć. Wystarczy automatyczna weryfikacja 301, ale oznacz każdy, który rozwiązuje się nieoczekiwanie.
- Tier masowy (pozostałe 90%): slugi o niskim lub zerowym ruchu. Weryfikuj programowo; zaakceptuj mały wskaźnik błędów i naprawiaj na podstawie raportów.
Wyeksportuj 30-dniowe podsumowanie kliknięć na link podczas etapu inwentaryzacji. Zwykła pętla paginacji przez referencję Bitly API (dostęp: 2026-05-12) dostarcza te dane; pole link_clicks w endpoincie bitlinków grupy jest licznikiem dożywotnim, który jest mniej precyzyjny, ale wystarczający do trylażu:
# 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
Posortuj wynik według link_clicks malejąco. Górne 1% to Twój tier "musi działać". Wyeksportuj ich slugi do osobnego pliku przed uruchomieniem importu masowego.
Zachowanie slugów: ważne wywołanie importu#
Endpoint masowego importu Elido pod POST /v1/links/bulk akceptuje pole slug dla każdego linku. Jeśli nie ustawisz go jawnie, Elido generuje nowy losowy slug - co jest nieprawidłowym zachowaniem przy migracji. Zawsze podawaj slug źródłowy.
# 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"]
}
]
}'
Dwie rzeczy do zauważenia w tym wywołaniu. Po pierwsze, wartości slugów to "SummerSale" i "AbCd" - mieszana wielkość liter zachowana dokładnie tak, jak pojawiała się w Bitly. Nie zamieniaj ich na małe litery. Po drugie, nagłówek Idempotency-Key oznacza, że możesz bezpiecznie ponownie uruchomić częściową partię; Elido zwraca istniejący link zamiast tworzyć duplikat. To właściwy wzorzec dla migracji, która może wymagać wznowienia.
Dla tiera "musi działać" uruchamiaj import interaktywnie per link zamiast w partii i weryfikuj każdy przed kontynuacją. Dla tiera masowego, batchuj po 100 wywołań i przetwarzaj tablicę błędów w odpowiedzi, aby wychwycić slugi, które weszły w konflikt lub nie powiodły się.
Przełączenie DNS bez przerwy#
Przełączenie DNS to moment, w którym ruch na żywo się zmienia. Wykonane prawidłowo, użytkownicy nie doświadczają żadnych przerw. Wykonane przy nieaktualnym TTL, przerwa trwa godziny, a nie minuty.
Kolejność ma znaczenie. Zobacz poniższy diagram osi czasu.
Oś czasu w szczegółach:
T−7 dni: Obniż TTL rekordu CNAME lub A do 60 sekund. To krytyczny krok, który większość zespołów pomija. RFC 1034 §3.6 (IETF datatracker, sekcja dotycząca buforowania rekordów zasobów) definiuje TTL jako maksymalny czas buforowania, przez który resolver może przechowywać rekord. Jeśli Twój aktualny TTL wynosi 86400 (jeden dzień), jego zmiana wchodzi w życie dopiero po wygaśnięciu aktualnie buforowanej wersji. Musisz obniżyć TTL co najmniej jeden pełny okres bieżącego TTL przed przełączeniem. Tydzień to bezpieczne minimum; 24 godziny to absolutne minimum.
T−1 godzina: Sprawdź, czy niski TTL się spropagował. Użyj narzędzia takiego jak dig @8.8.8.8 links.yourbrand.com +ttl z co najmniej trzech różnych endpointów resolverów. Raportowany TTL powinien zbliżać się do 60 sekund.
T−0: Zmień cel CNAME z edge Bitly na edge Elido. Po stronie Elido domena powinna być już zarejestrowana i zweryfikowana w Twoim workspace - nie przełączaj DNS przed gotowością edge Elido do przyjęcia ruchu. Pierwsze żądanie po propagacji wyzwala wystawienie certyfikatu przez automatyczny TLS na żądanie, co zajmuje około 2-3 sekundy dla tego jednego żądania. Kolejne żądania trafiają w cache i rozwiązują się w jednostkowych milisekundach na brzegu w regionie UE.
T+5 minut: Wykonaj wyrywkowe sprawdzenie z drugiej sieci (użyj mobilnego hotspotu, aby ominąć cache resolvera biurowego). curl -sI https://links.yourbrand.com/any-known-slug powinien zwrócić 301 Moved Permanently wskazujący na oczekiwany cel, widoczny po nagłówkach edge Elido.
T+1 godzina: Przywróć TTL do normalnej wartości operacyjnej (300 lub 3600 sekund). Utrzymywanie TTL na poziomie 60 sekund w nieskończoność dodaje obciążenie infrastrukturze Twojego dostawcy DNS i resolverów.
T+24 godziny: Uruchom pełny audyt slugów (patrz następna sekcja).
Zgodnie z RFC 7231 §6.4.2, odpowiedź 301 Moved Permanently może być buforowana przez pośredników w nieskończoność, chyba że jawny nagłówek cache-control to nadpisuje. Oznacza to, że każdy klient, który trafił stary cel Bitly podczas luki TTL, mógł buforować 301 wskazujący na infrastrukturę Bitly. Te buforowane przekierowania rozwiązują się prawidłowo, dopóki infrastruktura Bitly działa - dlatego ważne jest 30-dniowe okno nakładania się kont Bitly.
Audyt łańcucha 301: nocna weryfikacja skryptami#
Po przełączeniu uruchom nocną pętlę weryfikacyjną dla tiera "musi działać". Celem jest wychwycenie każdego sluga, który zmienił zachowanie - zwraca nieoczekiwany cel, zwraca 404 lub ma łańcuch przekierowań dłuższy niż dwa skoki.
# 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
Uruchamiaj to dla tiera "musi działać" (zwykle 50–200 slugów dla większości zespołów) co noc przez pierwsze dwa tygodnie po przełączeniu. Przekieruj wyjście do swojego kanału alertów. Jeśli FAIL jest niezerowy, chcesz, żeby człowiek zajrzał w to przed porannym szczytem ruchu.
Flaga --max-redirs 0 jest celowa: chcesz przekierowania Elido, a nie końcowego celu. Jeśli Status to 200 zamiast 301, coś po stronie Elido serwuje cel bezpośrednio zamiast przekierowywać, co oznacza, że slug rozwiązał się do linku skonfigurowanego jako bezpośrednie przepuszczenie. Warto to zbadać.
Dla tiera monitorowanego uruchamiaj lżejsze tygodniowe skanowanie. Dla tiera masowego polegaj na raportach błędów z systemów downstream - uszkodzone linki w e-mailach generują zmiany wskaźnika odrzuceń, które Twoja platforma e-mailowa wyświetli na powierzchnię.
Przepinanie webhooków#
Webhooki Bitly są udokumentowane w referencji Bitly API (dostęp: 2026-05-12) w sekcji Webhooks. Każdy webhook jest wyzwalany przy zdarzeniach kliknięć i zawiera pola bitlink, referrer i user-agent. Typowi konsumenci:
- Shopify: aplikacje atrybucji śledzące, który krótki link doprowadził do konwersji. Skonfigurowane w panelu administracyjnym aplikacji Shopify, wskazujące na endpoint zewnętrzny wywołujący weryfikację webhooków Bitly.
- Stripe: niektóre potoki atrybucji rozliczeniowej tagują przychodzące rejestracje próbne danymi UTM z oryginalnego krótkiego linku, pozyskanymi przez webhook Bitly.
- Slack: boty wydajności linków, które publikują podsumowania kliknięć na kanale
#marketing. - Niestandardowe potoki ETL: każdy potok hurtowni danych, który pobiera zdarzenia kliknięć Bitly do wzbogacania lub łączeń atrybucji.
Lista kontrolna migracji webhooków:
- Wyeksportuj konfigurację webhooków Bitly przed jakimikolwiek zmianami na koncie. Bitly API
GET /v4/workspaces/{workspace_guid}/webhookszwraca listę. Zapisz ją do pliku. - Dla każdego konsumenta zidentyfikuj URL endpointu odbierającego zdarzenia Bitly i sekret używany do weryfikacji HMAC.
- Skonfiguruj odpowiedni endpoint webhooków Elido. Payloady webhooków Elido mają inny schemat niż Bitly - pola są podobne, ale nie identyczne. Dostosuj handler konsumenta do akceptowania nowego schematu.
- Uruchamiaj oba webhooki równolegle podczas okna nakładania się. Skonfiguruj Elido do wysyłania webhooków od dnia przełączenia, utrzymując aktywny webhook Bitly. Twój konsument otrzyma dwa zdarzenia na kliknięcie podczas nakładania się - deduplikuj po krótkim URL + znacznik czasu lub zaakceptuj podwójne liczenie podczas okna nakładania się jako znany artefakt.
- Po 72 godzinach potwierdzonych dostaw webhooków Elido usuń konfigurację webhooków Bitly z każdego konsumenta.
Okno karencji rotacji sekretów to okres nakładania się. Nie rotuj sekretu webhooków Elido, dopóki każdy konsument nie zostanie zweryfikowany. Rotacja sekretu przed aktualizacją jednego konsumenta oznacza, że ten konsument cicho porzuca zdarzenia bez błędu - sprawdzenie HMAC nie powiodzi się i większość handlerów webhooków odrzuca payloady z nieprawidłowym podpisem bez alertowania.
Plan wycofania: utrzymuj Bitly przez 30 dni#
Procedura wycofania jest prosta: cofnij CNAME DNS do celu Bitly. Ponieważ wcześniej zmniejszyłeś TTL, a rekord DNS nadal ma 60 sekund (do czasu jego przywrócenia), cofnięcie DNS propaguje się w mniej niż dwie minuty.
Przygotuj polecenie wycofania przed rozpoczęciem:
# 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"}]
}
}]
}'
Przechowuj to w pliku na laptopie i w wspólnym miejscu runbooka przed przełączeniem. Najgorszym momentem na pisanie poleceń infrastrukturalnych jest aktywny incydent.
Utrzymuj konto Bitly aktywne i na płatnym planie zapewniającym rozwiązywanie linków przez 30 dni po przełączeniu. migrate-from-bitly-playbook rekomenduje 90 dni; 30 to praktyczne minimum dla zespołów potrzebujących kontrolować koszty. Przez 30-dniowe okno każdy ruch nadal rozwiązujący się przez Bitly (buforowane przekierowania, stare linki bit.ly w materiałach drukowanych) nadal działa. Po 30 dniach oceń pozostały ruch Bitly w swojej analityce i zdecyduj, czy go przedłużyć.
Co monitorować podczas 30-dniowego okna:
- Wskaźnik błędów Elido na Twojej niestandardowej domenie (zwracaj uwagę na nieoczekiwane 404 w logu dostępu).
- Wszelkie skoki ruchu do Bitly (dashboard Bitly pokazuje ruch; skok może oznaczać, że buforowane przekierowanie wciąż rozwiązuje się przez Bitly dla sluga o dużym wolumenie).
- Wskaźniki błędów konsumentów webhooków dla tych, których przepiąłeś.
Audyt po migracji: co logować#
Po 30-dniowym oknie uruchom końcowy pass audytu. Co należy do logu audytu:
| Sprawdzenie | Metoda | Kryterium zaliczenia |
|---|---|---|
| Liczba slugów się zgadza | wc -l bitly-export.jsonl vs. liczba API Elido | W granicach 1% (uwzględnij celowo porzucone zarchiwizowane linki) |
| Sprawdzenie 301 dla tiera "musi działać" | Nocny skrypt audytu | Zero awarii przez 7 kolejnych dni |
| Uzgodnienie wolumenu kliknięć | Porównaj łączną liczbę kliknięć Elido za 30 dni z 30-dniową sumą Bitly z tego samego okresu rok temu | W granicach oczekiwanej sezonowej wariancji |
| Potwierdzenie konsumenta webhooków | Sprawdź, czy każdy konsument otrzymuje zdarzenia Elido i przetwarza je poprawnie | Brak cichych porzuceń przez 7 dni |
| Przywrócony TTL DNS | dig +ttl links.yourbrand.com | TTL przy wartości operacyjnej (300+ sekund) |
Zaloguj to w tabeli audytu swojego zespołu. Jeśli Twój workspace jest na planie Business lub Enterprise, log audytu Elido rejestruje wszystkie operacje API podczas importu i jest dostępny przez API. Pobierz rekordy partii importu i przechowaj migawkę obok tej tabeli.
Częste pułapki: trzy wzorce z praktyki#
Marka e-commerce z obszaru DACH, która straciła tydzień atrybucji e-mailowej. Retailer w Niemczech prowadził kampanię newsletterową z użyciem slugów Bitly z UTM dołączonymi per subskrybent w czasie wysyłki. Skrypt migracyjny normalizował wszystkie slugi do małych liter przed importem do Elido. Po przełączeniu platforma e-mailowa generowała linki z oryginalnymi slugami w mieszanej wielkości liter. Te linki zwracały 404 z Elido, ponieważ wielkość liter w slugu nie pasowała. Rozwiązaniem było ponowne uruchomienie importu z zachowaniem wielkości liter, ale do tego czasu siedem dni ruchu e-mailowego wylądowało na stronach 404. Atrybucja była nieodwracalna dla tej kohorty. Lekcja: przetestuj jeden aktywny link z każdego aktywnego kanału przed ogłoszeniem zakończenia migracji.
Startup SaaS, który potroił przekierowania użytkowników mobilnych. Zespół wzrostowy miał niestandardową domenę Bitly poprzedzoną przez Cloudflare w trybie proxy (pomarańczowa chmurka). Po przełączeniu użytkownicy mobilni otrzymywali trzy przekierowania: Cloudflare → edge Elido → cel. Dodatkowy skok wynikał z reguły Cloudflare Page Rule przepisującej HTTP na HTTPS przed przekazaniem do Elido, a następnie Elido wystawiało własny 301. iOS Safari buforował pośrednie przekierowanie Cloudflare jako stałe przez 30 dni. Rozwiązaniem było ustawienie rekordu Cloudflare na szarą chmurę (tylko DNS) i usunięcie kolidującej reguły Page Rule. Buforowane przekierowania w Safari naturalnie wygasły po 30 dniach. Zweryfikuj tryb proxy CDN przed przełączeniem, a nie po nim.
Agencja, która przeoczyła grupę Bitly. Agencja zarządzała trzema markami klientów w ramach jednego konta Bitly, każdą w innej grupie Bitly z własną niestandardową domeną. Skrypt migracyjny zapytał tylko o domyślną grupę - tę, pod którą został utworzony token użytkownika API. Dwie domeny klientów migrowały bez problemów. Trzecia, w grupie dodatkowej, nigdy nie została wyeksportowana. Po przełączeniu wyszła kampania e-mailowa na premierę produktu wskazująca na niezmigrowaną domenę niestandardową. Domena nadal miała CNAME Bitly przy pełnym TTL i Bitly serwował linki poprawnie - ale okno przełączenia dla tej domeny zostało ogłoszone jako zakończone. Pośpiech był pełną re-migracją pod presją czasu. Lekcja: wylistuj wszystkie grupy przez GET /v4/user/groups przed rozpoczęciem jakiegokolwiek kroku eksportu. Sprawdź, czy token ma dostęp do każdej grupy.
Co dalej#
migrate-from-bitly-playbook obejmuje pełną strategiczną sekwencję dla zespołów zaczynających od zera planowanie migracji. Ten artykuł jest towarzyszem tryb awarii - użyj ich razem.
Po stronie produktu, do którego migrowałeś, strona solutions/marketers obejmuje funkcje atrybucji i śledzenia kampanii, do których dostępu stara się uzyskać większość projektów migracyjnych. Strona /compare/vs-bitly to referencja parytetu funkcji, jeśli wciąż potwierdzasz, że zmiana jest tego warta.
Jeśli oceniasz Elido obok Rebrandly lub Short.io, porównanie elido-vs-bitly obejmuje trade-offy cenowe i funkcjonalne przy czterech wolumenach ruchu. Strona funkcji niestandardowych domen szczegółowo dokumentuje mechanikę weryfikacji DNS i wystawiania TLS - warto przeczytać przed oknem przełączenia DNS.
Awarie migracyjne są prawie zawsze do uniknięcia. Skrypt audytu, dyscyplina TTL i inwentaryzacja webhooków wymagają dwóch godzin pracy przed przełączeniem. Oszczędzają dni reagowania na incydenty po nim.
Cytowania i źródła
- Bitly API Reference - dev.bitly.com/api-reference, dostęp: 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, dostęp: 2026-05-12
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