Migreren van Bitly zonder links te breken: wat verhuist

Ana Kowalska werkt als solutions engineer bij Elido aan migraties. Haar regel: bepaal wat kan verhuizen voordat je bepaalt hoe.

Splits je inventaris in tweeën om van Bitly te migreren zonder links te breken. Links op je eigen domein kunnen verhuizen: je importeert de slugs, wijzigt dan één DNS-record en dezelfde URL's blijven resolven. Links op het gedeelde domein bit.ly kunnen helemaal niet verhuizen, omdat Bitly eigenaar is van die hostnaam. Ze blijven alleen werken zolang Bitly dat toestaat, dus het account dat ze bevat, is wat je behoudt.

Dit bericht is het technische tegenstuk van het migratieprojectplan, dat fasen, eigenaren en de tijdlijn per week behandelt. Hier is de vraag smaller: wat gebeurt er precies met een verzoek om een oude korte link vóór, tijdens en na de cutover, en hoe bewijs je dat vanuit een terminal. Feiten over Bitly komen van de eigen helppagina's van Bitly (bekeken op 2026-10-02). Feiten over Elido komen uit de importer- en redirectcode.

Wat wel en niet kan verhuizen

De korte URL is de eenheid die telt, en een korte URL is een hostnaam plus een slug. Je beheert de bestemming van een link alleen als je zijn hostnaam beheert. Dat geeft drie gevallen, en slechts één ervan is een echte migratie.

Daaruit volgen twee dingen. Ten eerste: volledig van Bitly wegmigreren kan alleen voor links die je vanaf een eigen domein serveert, en daarom is een branded domein instellen voordat je moet vertrekken de goedkoopste verzekering in dit hele onderwerp. Ten tweede is het eerlijke doel voor bit.ly-links niet "verhuizen" maar "stoppen met nieuwe maken". Maak alles nieuws aan op je eigen domein, laat de oude bit.ly-URL's waar ze zijn en houd het Bitly-account aan (zie de sectie over opzeggen hieronder voor wat Bitly zegt dat ermee gebeurt) zolang die URL's in e-mails, pdf's en drukwerk leven.

Hoe redirectcontinuïteit bij de cutover werkt

Continuïteit heeft één vereiste: na de DNS-wijziging moet een verzoek om https://links.yourbrand.com/slug bij een dienst uitkomen die precies die slug al bevat. De import komt dus eerst en de DNS-wijziging daarna, en de import moet slugs exact behouden.

De Bitly-importer van Elido doet dat. Hij neemt een Bitly Generic Access Token, somt je groepen op zodat je er een kunt kiezen, loopt dan GET /v4/groups/{guid}/bitlinks door met 100 links per pagina en maakt elke link op het doeldomein aan met dezelfde slug, bestemming en titel, plus een tag imported:bitly. Bitlinks die in Bitly als verwijderd zijn gemarkeerd, worden overgeslagen, en het token wordt voor de run in het geheugen bewaard in plaats van opgeslagen. Eén job is begrensd op 50.000 links en een budget van 30 minuten; grotere accounts wordt gevraagd contact op te nemen met migratiesupport voor een run in delen.

Vier gedragingen in die code bepalen of een migratie schoon verloopt:

• Eén groep per job. Een Bitly-account kan meerdere groepen bevatten, elk met een eigen domein. Draai één job per groep, anders komt het tweede domein simpelweg nooit aan.
• Slugopzoekingen zijn niet hoofdlettergevoelig. Bitly behandelt bit.ly/CustomWord en bit.ly/customword als verschillende links, wat het helpcentrum van Bitly zelf bevestigt. Elido slaat slugs per domein hoofdletterongevoelig op en behoudt de schrijfwijze die je hebt geïmporteerd. De import behoudt SummerSale zoals geschreven, en een verzoek om /summersale resolvet ook. Het addertje zijn twee Bitly-links die alleen in hoofdletters verschillen: de tweede botst met de eerste.
• De standaard conflictstrategie is suffix. Bij een botsing maakt de importer promo-2 aan, een URL die niemand heeft gedrukt. Kies bij een migratie skip en lees daarna het foutenlogboek, of fail om bij de eerste botsing te stoppen. Een skip wordt vastgelegd met de slug en de reden.
• Slashes aan het einde zijn onschadelijk. De edge routeert op het eerste padsegment en negeert de rest, dus /slug/ resolvet net als /slug. Een + achter een slug opent een previewpagina in plaats van door te sturen, handig als je een link controleert zonder hem te volgen.

De linktabel in een DEMO-werkruimte met voorbeelddata. Slugs in gemengde hoofdletters zoals AFQdo worden opgeslagen zoals geschreven. De cijfers zijn synthetisch, geen klantresultaten.

Uitgewerkt voorbeeld: een hoofdlettersbotsing

Stel dat je export bit.ly/Promo bevat met bestemming /spring en bit.ly/promo met bestemming /autumn. Beide bestaan in Bitly. Op één Elido-domein importeert Promo probleemloos en botst promo. Met suffix krijg je promo-2, en elke gedrukte promo-link stuurt mensen nu naar de lentepagina. Met skip wordt de tweede link gemeld en weggelaten. Dan beslis je bewust: hernoem er een in je bronmateriaal, of geef de tweede een eigen subdomein.

301 vs 302 tijdens de cutover

Bitly documenteert zijn links als 301-redirects (permanent). Elido laat je per link de statuscode kiezen: 301, 302 of 307. Een link zonder expliciete keuze geeft een 302, en de importer stelt er geen in, dus geïmporteerde links beginnen als 302.

Die standaard is de juiste voor het cutovervenster, om een reden die rechtstreeks uit de HTTP-specificatie komt. RFC 9110 zegt dat een 301-respons heuristisch cachebaar is, zodat een browser of proxy hem lang mag bewaren (RFC 9110, sectie 15.4.2). Een 302 wordt standaard niet gecachet (sectie 15.4.3). Schakel je op dag één over op 301 en moet je daarna terugdraaien, dan blijft elke client die het antwoord heeft gecachet naar de oude plek gaan. Daarbovenop stuurt de edge van Elido Cache-Control: private, max-age=0, no-store mee met zijn redirects, dus een 302 ervan wordt bij elke klik opnieuw beoordeeld.

Ik zou niets op dag één naar 301 omzetten. Blijf tijdens de soak-periode op 302 en zet daarna de links waarvan de bestemming nooit verandert, in bulk om naar 301. Voor korte links die naar campagnepagina's wijzen, is het praktische SEO-verschil klein, en 301 vs 302 redirects laat zien waar het wel uitmaakt. De eigen richtlijn van Google over permanente redirects staat in zijn redirectdocumentatie.

Nog een valkuil: een redirect die twee keer doorstuurt. Staat je domein achter een proxy of CDN die HTTPS afdwingt voordat het verzoek de nieuwe dienst bereikt, dan kan een bezoeker twee hops zien. Redirectketens en SEO en de gids voor het oplossen van redirectlussen behandelen hoe je de extra hop opspoort en verwijdert.

TTL en DNS-timing

Een DNS-antwoord mag zo lang worden gecachet als de TTL van het record zegt (RFC 1035, sectie 3.2.1). Dat maakt het verouderde venster in het slechtste geval na een recordwijziging gelijk aan de TTL die het vóór de wijziging had. Een CNAME die op 86400 seconden is blijven staan, kan sommige bezoekers na je omschakeling nog een hele dag naar Bitly blijven sturen.

Als je je domein in Elido registreert, krijg je twee records: een TXT-record op _elido-verify.<hostname> en een CNAME van de hostnaam naar edge.elido.me. Het domein telt als geverifieerd wanneer beide resolven, en de verifier geeft het na 24 uur op als er een ontbreekt. Certificaten worden bij het eerste verzoek aan de hostnaam uitgegeven, dus verwacht dat dat ene verzoek trager is. Dit is een schema dat rekening houdt met de cachewiskunde:

1. Minstens één oude TTL vóór de cutover (D-2 bij een TTL van 24 uur): verlaag de TTL van de CNAME naar 300 seconden. Schrijf het huidige doel op. Het helpcentrum van Bitly documenteert cname.bitly.com voor subdomeinen, maar kopieer de waarde uit je eigen zone, want dat is je rollbackwaarde.
2. D0, wijzigingsvenster: draai de import voor het doeldomein, vervang dan het CNAME-doel en voeg het TXT-record toe.
3. D0, vijf tot tien minuten later: bevestig dat het domein als geverifieerd wordt getoond en voer de controles uit de volgende sectie uit vanaf twee netwerken.
4. D+1 tot D+7: laat de TTL op 300 staan. Herstel pas na de soak-periode een langere TTL.

Een eigen domein met TLS instellen toont de formulieren, en de functiepagina over eigen domeinen beschrijft wat automatisch gaat.

Wil je dat de importer de paginering voor je doet, dan legt de Bitly-migratiepagina de flow uit, van het plakken van een token tot het kiezen van de groep en het domein.

De integratiecatalogus in een DEMO-werkruimte met voorbeelddata. Het filter Migration toont de importers. De werkruimtedata is synthetisch.

Verifieer met curl

Ik vertrouw nooit een groen dashboard. Vraag de echte URL op en lees de headers. Het kost een minuut. Drie controles dekken bijna alles.

Bevestig eerst DNS vanaf een openbare resolver in plaats van die van je kantoor:

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

Bekijk ten tweede één redirect zonder hem te volgen. -I stuurt een HEAD-request; behandelt je tooling HEAD anders, gebruik dan -o /dev/null -D - met GET:

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

Je wilt een 302 (of de status die je hebt gekozen) en een header location: gelijk aan de bestemming in je export. Een 404 betekent dat de slug niet is geïmporteerd; een 200 betekent dat je naar een pagina kijkt, niet naar een redirect.

Laat ten derde elke slug uit je export door een lus lopen en vergelijk de Location met de verwachte bestemming. Exporteer een CSV met twee kolommen (slug,destination) uit je Bitly-export en draai:

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"

Verwacht een paar cosmetische afwijkingen: redirect_url kan een kale https://example.com normaliseren naar https://example.com/. Beschouw die als ruis en repareer de vergelijking, niet de link. Test ook met de hand één slug per actief kanaal (nieuwsbrief, QR, advertentie), met precies de schrijfwijze in hoofdletters die dat kanaal gebruikt. Draai de lus na het eerste uur, de volgende ochtend en een week later.

Beperkingen van analyticsgeschiedenis

Je kunt klikgeschiedenis niet meenemen, en geen enkele importer kan dat veranderen. De API van Bitly documenteert twee klik-endpoints voor een bitlink, GET /v4/bitlinks/{bitlink}/clicks en GET /v4/bitlinks/{bitlink}/clicks/summary, en beide geven aantallen per tijdsbucket terug, geen afzonderlijke gebeurtenissen (bekeken op 2026-10-02). Zonder rijen per klik is er geen manier om referrers, landen of apparaten uit het verleden te reconstrueren.

Wat de Elido-importer meeneemt is de linktabel: slug, bestemming, titel en tags. Aanmaakdatums, QR-ontwerpen en Bitly-campagnes reizen niet mee, en klikken worden geteld vanaf het moment dat verkeer Elido bereikt. Praktische stappen:

• Haal vóór de cutover de teller over de levensduur van elke belangrijke link op en bewaar hem met de datum.
• Exporteer alles wat je voor rapportage nodig hebt uit het dashboard van Bitly zolang het account actief is.
• Behandel de cutoverdatum als een zichtbare breuk in elke grafiek en annoteer hem.

Linkdata exporteren behandelt welke dataklassen mee reizen met een export en hoe je controleert of een export volledig is.

Wat breekt als je Bitly opzegt

Het helpcentrum van Bitly is hier specifiek over, en de volgorde van handelingen doet ertoe (bekeken op 2026-10-02):

• bit.ly-links blijven werken na het verwijderen van het account, en de slugs kunnen niet opnieuw worden gebruikt. Maar je kunt ze niet meer bewerken of doorsturen en je verliest de toegang tot hun statistieken.
• Links op een eigen domein blijven alleen werken zolang je DNS nog naar Bitly wijst. Bitly stopt met het verlengen van het SSL-certificaat, dus bezoekers zien uiteindelijk een waarschuwing "niet veilig". Als je downgradet in plaats van verwijdert, blijven bestaande links werken, maar kun je op dat domein geen nieuwe maken.
• Gratis domeinen worden niet verlengd. Links erop werken totdat de registratie verloopt, wat Bitly op een jaar na uitgifte of laatste verlenging stelt, en daarna breken ze.
• Al het andere verdwijnt met het account: QR-codes die je niet meer kunt bewerken, Bitly Pages en alle rapporten die je niet hebt geëxporteerd.

De regel is botweg. Verplaats eerst DNS, bevestig met de bovenstaande controles en zeg pas daarna op of downgrade. Zeg niet op om de verhuizing te "forceren". De soak-periode uit de playbook bestaat hiervoor, en de uitsplitsing van de prijzen van Bitly helpt je beslissen welk abonnement je aanhoudt zolang oude bit.ly-URL's nog in omloop zijn.

Voor een functievergelijking, zie Elido vs Bitly. Het ontwerp en de limieten van de importer staan in de Bitly-migratie opleveren.

Gerelateerd op de blog

• Bitly-migratieplaybook: van inventaris tot 30 dagen monitoring
• De Bitly-migratie opleveren: één worker, vier limieten
• 301 vs 302 redirects voor korte links
• Een eigen domein met TLS instellen in 5 minuten
• Linkdata exporteren
• Redirectketens en SEO

Bronnen

• Helpcentrum van Bitly: wat er gebeurt na het verwijderen van een account, downgraden, hoofdlettergevoeligheid, SEO en 301, allemaal bekeken op 2026-10-02
• Bitly API-referentie, dev.bitly.com/api-reference, bekeken op 2026-10-02
• Gedrag van de Elido-importer: services/api-core/internal/imports/bitly.go en de edge-redirecthandler, gelezen op 2026-10-02