Migrare de la Bitly fără linkuri rupte: ce se mută

Ana Kowalska lucrează la migrări ca solutions engineer la Elido. Regula ei: decide ce se poate muta înainte să decizi cum.

Ca să migrezi de la Bitly fără linkuri rupte, împarte inventarul în două. Linkurile de pe propriul domeniu personalizat se pot muta: imporți slug-urile, apoi schimbi o singură înregistrare DNS, iar aceleași URL-uri continuă să se rezolve. Linkurile de pe domeniul partajat bit.ly nu se pot muta deloc, pentru că Bitly deține acel hostname. Ele funcționează doar cât timp le lasă Bitly, deci contul care le conține este ceea ce păstrezi.

Acest articol este însoțitorul tehnic al planului de proiect al migrării, care acoperă fazele, responsabilii și calendarul pe săptămâni. Aici întrebarea este mai îngustă: ce se întâmplă de fapt cu o cerere pentru un vechi link scurt înainte, în timpul și după comutare și cum o demonstrezi dintr-un terminal. Faptele despre Bitly provin din paginile de ajutor ale Bitly (accesate 2026-10-02). Faptele despre Elido provin din codul importatorului și al redirecționării.

Ce se poate muta și ce nu

URL-ul scurt este unitatea care contează, iar un URL scurt este un hostname plus un slug. Controlezi destinația unui link doar dacă controlezi hostname-ul lui. Rezultă trei cazuri și doar unul este o migrare reală.

Rezultă două consecințe. Prima, migrarea completă de la Bitly este posibilă doar pentru linkurile servite de pe un domeniu pe care îl deții, motiv pentru care configurarea unui domeniu de brand înainte să fie nevoie să pleci este cea mai ieftină asigurare din tot acest subiect. A doua, pentru linkurile bit.ly scopul sincer nu este "mută", ci "nu mai crea altele noi". Creează tot ce este nou pe propriul domeniu, lasă vechile URL-uri bit.ly unde sunt și păstrează contul Bitly (vezi secțiunea despre anulare mai jos pentru ce spune Bitly că li se întâmplă) cât timp acele URL-uri trăiesc în e-mailuri, PDF-uri și materiale tipărite.

Cum funcționează continuitatea redirecționării la comutare

Continuitatea are o singură cerință: după schimbarea DNS, o cerere pentru https://links.yourbrand.com/slug trebuie să ajungă la un serviciu care deține deja exact acel slug. Deci importul vine primul și schimbarea DNS a doua, iar importul trebuie să păstreze slug-urile exact.

Importatorul Bitly al Elido face asta. Primește un Generic Access Token Bitly, îți listează grupurile ca să alegi unul, apoi parcurge GET /v4/groups/{guid}/bitlinks câte 100 de linkuri pe pagină și creează fiecare link pe domeniul țintă cu același slug, aceeași destinație și același titlu, plus un tag imported:bitly. Bitlink-urile marcate ca șterse în Bitly sunt omise, iar tokenul este ținut în memorie pe durata rulării, nu stocat. Un singur job este limitat la 50,000 de linkuri și un buget de 30 de minute; conturile mai mari sunt rugate să contacteze suportul de migrare pentru o rulare pe bucăți.

Patru comportamente din acel cod decid dacă o migrare este curată:

• Un grup per job. Un cont Bitly poate conține mai multe grupuri, fiecare cu propriul domeniu. Rulează un job pe grup, altfel al doilea domeniu pur și simplu nu ajunge niciodată.
• Căutările de slug nu țin cont de majuscule. Bitly tratează bit.ly/CustomWord și bit.ly/customword ca linkuri diferite, ceea ce confirmă și centrul de ajutor Bitly. Elido stochează slug-urile fără sensibilitate la majuscule per domeniu, păstrând totuși forma importată. Importul păstrează SummerSale așa cum este scris, iar o cerere pentru /summersale se rezolvă și ea. Capcana apare la două linkuri Bitly care diferă doar prin majuscule: al doilea intră în coliziune cu primul.
• Strategia implicită de conflict este suffix. La o coliziune importatorul creează promo-2, un URL pe care nu l-a tipărit nimeni. Pentru o migrare, alege skip și citește apoi jurnalul de erori sau fail ca să te oprești la prima coliziune. Un skip este înregistrat cu slug-ul și motivul.
• Slash-urile finale sunt inofensive. Edge-ul rutează după primul segment al căii și ignoră restul, deci /slug/ se rezolvă ca /slug. Adăugarea lui + la un slug deschide o pagină de previzualizare în loc să redirecționeze, ceea ce e util când verifici un link fără să-l urmezi.

Tabelul de linkuri într-un spațiu de lucru DEMO cu date de exemplu. Slug-urile cu majuscule mixte precum AFQdo sunt stocate așa cum sunt scrise. Cifrele sunt sintetice, nu rezultate ale clienților.

Exemplu lucrat: o coliziune de majuscule

Spune că exportul tău conține bit.ly/Promo indicând spre /spring și bit.ly/promo indicând spre /autumn. Ambele există în Bitly. Pe un singur domeniu Elido, Promo se importă curat, iar promo intră în conflict. Cu suffix primești promo-2, iar fiecare link promo tipărit trimite acum oamenii la pagina de primăvară. Cu skip al doilea link este raportat și lăsat deoparte. Apoi decizi deliberat: redenumești unul în materialele tale sursă sau îi dai celui de-al doilea propriul subdomeniu.

301 vs 302 în timpul comutării

Bitly își documentează linkurile ca redirecționări 301 (permanente). Elido te lasă să alegi codul de stare per link: 301, 302 sau 307. Un link fără o alegere explicită returnează un 302, iar importatorul nu setează niciunul, deci linkurile importate pornesc ca 302.

Valoarea implicită este cea potrivită pentru fereastra de comutare, dintr-un motiv care vine direct din specificația HTTP. RFC 9110 spune că un răspuns 301 poate fi memorat euristic în cache, deci un browser sau un proxy îl poate păstra mult timp (RFC 9110, secțiunea 15.4.2). Un 302 nu este ținut în cache implicit (secțiunea 15.4.3). Dacă treci pe 301 în prima zi și apoi ai nevoie de rollback, fiecare client care a ținut răspunsul în cache continuă să meargă la vechiul loc. În plus, edge-ul Elido trimite Cache-Control: private, max-age=0, no-store cu redirecționările lui, deci un 302 de la el este reevaluat la fiecare clic.

Eu nu aș trece nimic pe 301 în prima zi. Rămâi pe 302 pe toată perioada de rodaj, apoi treci în masă pe 301 linkurile ale căror destinații nu se vor schimba niciodată. Pentru linkurile scurte care duc la pagini de campanie, diferența practică de SEO este mică, iar redirecționările 301 vs 302 arată unde contează totuși. Ghidul Google despre redirecționările permanente se află în documentația sa despre redirecționări.

O capcană în plus: o redirecționare care sare de două ori. Dacă domeniul tău se află în spatele unui proxy sau CDN care forțează HTTPS înainte ca cererea să ajungă la noul serviciu, un vizitator poate vedea două hopuri. Lanțurile de redirecționări și SEO și ghidul de depanare a buclelor de redirecționare acoperă cum recunoști și elimini hopul în plus.

TTL și momentul DNS

Un răspuns DNS poate fi ținut în cache atât cât spune TTL-ul înregistrării (RFC 1035, secțiunea 3.2.1). Asta face ca fereastra cea mai proastă de date învechite după schimbarea unei înregistrări să fie egală cu TTL-ul pe care îl avea înainte de schimbare. Un CNAME lăsat la 86400 de secunde poate continua să trimită unii vizitatori la Bitly o zi întreagă după ce l-ai schimbat.

Înregistrarea domeniului în Elido îți dă două înregistrări: un TXT la _elido-verify.<hostname> și un CNAME de la hostname spre edge.elido.me. Domeniul contează ca verificat când ambele se rezolvă, iar verificatorul renunță după 24 de ore dacă lipsește vreuna. Certificatele se emit la prima cerere către hostname, deci te poți aștepta ca acea cerere să fie mai lentă. Iată un program care respectă aritmetica cache-ului:

1. Cu cel puțin un vechi TTL înainte de comutare (D-2 pentru un TTL de 24 de ore): coboară TTL-ul CNAME-ului la 300 de secunde. Notează ținta curentă. Centrul de ajutor Bitly documentează cname.bitly.com pentru subdomenii, dar copiază valoarea din propria zonă, pentru că aceea este valoarea ta de rollback.
2. D0, fereastra de schimbare: rulează importul pe domeniul țintă, apoi înlocuiește ținta CNAME și adaugă înregistrarea TXT.
3. D0, la cinci-zece minute după: confirmă că domeniul apare ca verificat și rulează verificările din secțiunea următoare din două rețele.
4. D+1 până la D+7: lasă TTL-ul la 300. Restabilește un TTL mai lung doar după perioada de rodaj.

Configurarea domeniului personalizat cu TLS arată formularele, iar pagina funcției domenii personalizate descrie ce este automat.

Dacă vrei ca importatorul să facă paginarea pentru tine, pagina de migrare Bitly explică fluxul, de la lipirea unui token până la alegerea grupului și a domeniului.

Catalogul de integrări într-un spațiu de lucru DEMO cu date de exemplu. Filtrul Migrare listează importatoarele. Datele spațiului de lucru sunt sintetice.

Verifică cu curl

Nu mă încred niciodată într-un tablou de bord verde. Cere URL-ul real și citește antetele. Durează un minut. Trei verificări acoperă aproape tot.

Mai întâi, confirmă DNS-ul de la un resolver public, nu de la cel al biroului tău:

dig +short CNAME links.yourbrand.com @1.1.1.1
dig +short TXT _elido-verify.links.yourbrand.com @1.1.1.1

Apoi, uită-te la o redirecționare fără să o urmezi. -I trimite o cerere HEAD; dacă uneltele tale tratează HEAD diferit, folosește în schimb -o /dev/null -D - cu GET:

curl -s -o /dev/null -D - --max-redirs 0 https://links.yourbrand.com/SummerSale

Vrei un 302 (sau statusul pe care l-ai ales) și un antet location: egal cu destinația din exportul tău. Un 404 înseamnă că slug-ul nu a fost importat; un 200 înseamnă că te uiți la o pagină, nu la o redirecționare.

În al treilea rând, rulează fiecare slug din export printr-o buclă și compară Location cu destinația așteptată. Exportă un CSV cu două coloane (slug,destination) din extragerea ta Bitly și rulează:

DOMAIN="links.yourbrand.com"
fail=0
while IFS=, read -r slug dest; do
  out=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' --max-redirs 0 "https://${DOMAIN}/${slug}")
  code=${out%% *}; loc=${out#* }
  case "$code" in 301|302|307) ;; *) echo "BAD STATUS $code $slug"; fail=$((fail+1)); continue;; esac
  [ "$loc" = "$dest" ] || { echo "MISMATCH $slug -> $loc (want $dest)"; fail=$((fail+1)); }
done < slugs.csv
echo "failures: $fail"

Așteaptă-te la câteva nepotriviri cosmetice: redirect_url poate normaliza un https://example.com simplu în https://example.com/. Tratează-le ca zgomot și repară comparația, nu linkul. Testează manual și câte un slug pentru fiecare canal activ (newsletter, QR, reclamă), cu exact scrierea cu majuscule mixte pe care o folosește acel canal. Rulează bucla după prima oră, în dimineața următoare și o săptămână mai târziu.

Limitele istoricului de analiză

Nu poți aduce istoricul de clicuri, iar niciun importator nu poate schimba asta. API-ul Bitly documentează două endpoint-uri de clicuri pentru un bitlink, GET /v4/bitlinks/{bitlink}/clicks și GET /v4/bitlinks/{bitlink}/clicks/summary, iar ambele returnează numărători pe intervale de timp, nu evenimente individuale (accesate 2026-10-02). Fără rânduri per clic nu există cale de a reconstrui sursele de trafic, țările sau dispozitivele din trecut.

Ce preia importatorul Elido este tabelul de linkuri: slug, destinație, titlu și taguri. Datele de creare, designurile QR și campaniile Bitly nu se transferă, iar clicurile se numără din momentul în care traficul ajunge la Elido. Pași practici:

• Înainte de comutare, extrage contorul pe toată durata de viață al fiecărui link important și salvează-l cu data.
• Exportă din tabloul de bord Bitly tot ce îți trebuie pentru raportare cât timp contul este activ.
• Tratează data comutării ca o ruptură vizibilă în fiecare grafic și adnotează-o.

Exportul datelor linkurilor scurte acoperă ce clase de date călătoresc la un export și cum verifici că o extragere este completă.

Ce se strică dacă anulezi Bitly

Centrul de ajutor Bitly este specific în privința asta, iar ordinea operațiunilor contează (accesat 2026-10-02):

• Linkurile bit.ly continuă să funcționeze după ștergerea contului, iar slug-urile nu pot fi refolosite. Dar nu le mai poți edita sau redirecționa și pierzi accesul la metricile lor.
• Linkurile de pe domeniu personalizat funcționează doar cât timp DNS-ul tău încă indică spre Bitly. Bitly încetează să reînnoiască certificatul SSL, deci vizitatorii văd în cele din urmă un avertisment "not secure". Dacă retrogradezi în loc să ștergi, linkurile existente continuă să funcționeze, dar nu mai poți crea altele noi pe acel domeniu.
• Domeniile gratuite nu sunt reînnoite. Linkurile de pe ele funcționează până expiră înregistrarea, pe care Bitly o stabilește la un an de la emitere sau de la ultima reînnoire, apoi se strică.
• Tot restul pleacă odată cu contul: coduri QR pe care nu le mai poți edita, Bitly Pages și orice rapoarte pe care nu le-ai exportat.

Regula este tăioasă. Mută întâi DNS-ul, confirmă cu verificările de mai sus și abia apoi anulează sau retrogradează. Nu anula ca să "forțezi" mutarea. Perioada de rodaj din ghid există din acest motiv, iar detalierea prețurilor Bitly te va ajuta să decizi ce plan să ții cât timp vechile URL-uri bit.ly sunt încă în circulație.

Pentru o comparație de funcții, vezi Elido vs Bitly. Designul și limitele importatorului se află în livrarea migrării Bitly.

Alte articole de pe blog

• Ghid de migrare Bitly: de la inventar la monitorizare 30 de zile
• Livrarea migrării Bitly: un worker, patru limite
• Redirecționări 301 vs 302 pentru linkuri scurte
• Configurează un domeniu personalizat cu TLS în 5 minute
• Exportă datele linkurilor scurte
• Lanțuri de redirecționări și SEO

Surse

• Centrul de ajutor Bitly: ce se întâmplă după ștergerea contului, retrogradare, sensibilitatea la majuscule, SEO și 301, toate accesate 2026-10-02
• Referința API Bitly, dev.bitly.com/api-reference, accesată 2026-10-02
• Comportamentul importatorului Elido: services/api-core/internal/imports/bitly.go și handlerul de redirecționare de la edge, citite 2026-10-02