Migracja z TinyURL: dwie ścieżki i co każda z nich zachowuje

Migracja z Bitly ma dobrze opracowany playbook: eksport API, CSV, import masowy, przełączenie DNS. Przewodnik migracyjny z Bitly obejmuje każdy krok. TinyURL jest inny - nie trudniejszy, ale różni się w sposób, który zmienia planowanie. Kluczowe rozróżnienie to to, czy posiadasz konto TinyURL Pro. Ta jedna zmienna rozwidla migrację na dwie niemal zupełnie odrębne procedury.

Ten artykuł omawia obie ścieżki i uczciwie mówi o tym, co nie przeżywa przeprowadzki.

TL;DR#

• Jeśli masz konto TinyURL Pro, TinyURL API pozwala wyliczyć i wyeksportować Twoje linki. CSV zawiera slug, cel i liczbę kliknięć z 30 dni. Możesz czysto zaimportować do Elido.
• Jeśli nie masz konta - przez lata po prostu publikowałeś linki tinyurl.com/<slug> - nie ma eksportu. Odtwarzasz mapę, przeszukując własne opublikowane powierzchnie.
• W żadnym przypadku nie możesz zachować oryginalnych slugów tinyurl.com w swoim workspace Elido. TinyURL jest właścicielem tej domeny. Wygenerujesz nowe slugi na własnej brandowanej domenie skracającej.
• Realistyczna uwaga: większość użytkowników TinyURL jest na darmowym planie. Dla nich migracja to mniej kwestia przenośności danych, a bardziej aktualizacja każdego miejsca, gdzie pojawia się link TinyURL.

Co sprawia, że migracja z TinyURL różni się od Bitly#

Kluczowa różnica strukturalna to domena. Użytkownicy Bitly na płatnych planach często korzystają z niestandardowej domeny brandowanej - links.yourbrand.com - którą posiadają. Gdy migrują, rekord DNS dla tej domeny jest przestawiany na edge Elido i każdy istniejący slug nadal działa. Przestrzeń slugów należy do nich.

Użytkownicy darmowego planu TinyURL są na tinyurl.com. Nie są właścicielami tej domeny i nie mogą zainstalować na niej przekierowania 301. Gdy opuszczają TinyURL, stare linki nie podążają za nimi. Pozostają aktywne pod tinyurl.com tak długo, jak TinyURL działa, ale migrujący zespół nie ma nad nimi żadnej kontroli, żadnej możliwości przechwycenia kliknięć ani łańcucha 301 do wdrożenia.

TinyURL Pro oferuje niestandardowe domeny brandowane za $9.99/miesiąc (dostęp: 2026-05-12). Jeśli byłeś na Pro i używałeś własnej domeny, ścieżka migracyjna jest znacznie bliższa scenariuszowi Bitly: zweryfikuj domenę w Elido, wstępnie przygotuj slugi, a następnie przełącz CNAME DNS. Dokumentacja niestandardowych domen obejmuje stronę Elido w tym przełączeniu.

Inna różnica strukturalna to log audytu. TinyURL ma ograniczoną widoczność danych historycznych nawet na Pro. Porównanie elido-vs-tinyurl obejmuje pełną lukę funkcjonalną. Na potrzeby planowania migracji praktyczna implikacja jest taka, że nie będziesz w stanie zrekonstruować kompletnej historii kliknięć. Nie planuj budżetu na to.

Ścieżka A: masz konto TinyURL Pro#

TinyURL Pro udostępnia API pod https://tinyurl.com/app/dev (dostęp: 2026-05-12). API obsługuje tworzenie i pobieranie aliasów. Wyliczanie działa przez paginowane wywołania GET zwracające Twoje linki partiami.

Kroki:

1. Wygeneruj token API z ustawień aplikacji TinyURL.
2. Wylistuj wszystkie aliasy, paginując do końca. TinyURL stosuje limity żądań; dokumentacja API określa pułap żądań na minutę. Zbuduj handler backoffu przed rozpoczęciem - 429 w środku eksportu jest irytujące, ale nie niszczy danych, jeśli przyrostowo zapisywałeś wyniki na dysku.
3. Dla każdego aliasu zbierz slug, docelowy URL i liczbę kliknięć z 30 dni. API TinyURL nie udostępnia surowych zdarzeń kliknięć ani historycznych szeregów czasowych. Otrzymujesz agregat.
4. Zapisz płaski CSV: jeden wiersz na link, kolumny slug,target_url,clicks_30d.
5. Posortuj według clicks_30d malejąco. Top 1% linków według wolumenu kliknięć to zazwyczaj ułamek, który faktycznie ma znaczenie dla trwających kampanii lub opublikowanych treści. Priorytetyzuj je pod kątem walidacji i aktualizacji powierzchni. Długi ogon linków z zerowymi kliknięciami można importować, ale rzadko wymaga ludzkiej uwagi.

Gdy masz CSV, import do Elido ma ten sam kształt co każda inna migracja masowa. Szczegółowa mechanika importu masowego jest w playbooku migracyjnym z Bitly - kształt API i wywołanie TypeScript SDK są identyczne; różnią się tylko dane źródłowe.

Łańcuch 301 dla domen brandowanych w Pro#

Jeśli Twoje konto TinyURL Pro używało niestandardowej domeny brandowanej, możesz przenieść tę domenę do Elido. Zarejestruj ją w swoim workspace Elido przez przepływ niestandardowych domen, wstępnie przygotuj wszystkie slugi, a następnie zmień CNAME:

short.yourbrand.com.  300  IN  CNAME  edge.elido.me.

Tutaj mają zastosowanie semantyki HTTP 301: gdy CNAME rozwiązuje się na edge Elido, przeglądarki i boty podążające za starymi linkami otrzymają odpowiedź 301 Moved Permanently z Elido wskazującą na docelowy URL. Nie jest wymagane żadne przekierowanie przez TinyURL, ponieważ przestrzeń slugów była na Twojej domenie, a nie na tinyurl.com. To jest czysta ścieżka.

Odpowiedni standard to RFC 7231 §6.4.2, który definiuje semantykę 301 Moved Permanently. Klient otrzymujący 301 powinien zaktualizować wszelkie przechowywane URL-e do nowej lokalizacji. W praktyce klienci e-mailowi i platformy społecznościowe różnią się stopniem agresywności w podążaniu za tym - ale samo przekierowanie jest niezawodne dla przeglądarek internetowych i botów respektujących specyfikację HTTP.

Ścieżka B: brak konta, tylko opublikowane linki#

To częstszy scenariusz. Masz darmowe konto TinyURL lub nie masz konta i masz zbiór linków tinyurl.com/<slug> opublikowanych w archiwum newslettera, postach społecznościowych, materiałach drukowanych lub dokumentacji. Nie masz dostępu do API ani mechanizmu eksportu. Linki istnieją; nie masz ich listy.

Jedynym sposobem na zbudowanie inwentarza jest przeszukanie własnych opublikowanych powierzchni.

Znajdowanie linków#

Przechodź przez każdą powierzchnię systematycznie:

• Archiwum e-mail/newsletter: wyszukaj w archiwum swojej platformy e-mailowej tinyurl.com. Większość platform pozwala na wyszukiwanie w wysłanych kampaniach. Wyeksportuj dopasowania.
• Media społecznościowe: przeszukaj posty na Twitter/X, LinkedIn i Facebook pod kątem linków tinyurl.com. Większość platform ma eksport treści na poziomie konta. Pobierz go i przeszukaj grepe'm.
• Strona internetowa i dokumentacja: uruchom wyszukiwanie po stronie lub crawl. grep -r "tinyurl.com" ./content na repozytorium statycznej strony zajmuje sekundy.
• Linki śledzące platform reklamowych: sprawdź linki tagowane UTM w Google Ads, Meta Ads Manager lub wszędzie tam, gdzie prowadziłeś płatne kampanie.

Gdy masz listę wartości tinyurl.com/<slug>, potrzebujesz docelowych URL-i. Jeśli sam tworzyłeś linki i możesz sobie przypomnieć cel - świetnie. Jeśli nie: podążaj za każdym linkiem ręcznie lub za pomocą skryptu wysyłającego żądanie HEAD i odczytującego nagłówek Location. Samo przekierowanie TinyURL jest publicznie dostępne - nie potrzebujesz konta, żeby sprawdzić, dokąd prowadzi link tinyurl.com.

# Bulk-resolve TinyURL destinations from a file of slugs (one per line)
while IFS= read -r slug; do
  dest=$(curl -s -o /dev/null -w "%{redirect_url}" \
    -L --max-redirs 0 "https://tinyurl.com/${slug}" 2>/dev/null || echo "FAILED")
  echo "${slug},${dest}"
done < tinyurl-slugs.txt > slug-target-map.csv

Daje Ci to CSV slug,target_url potrzebny do importu. Pamiętaj, że będziesz importować z nowymi slugami na własnej domenie - więcej na ten temat poniżej.

Zaakceptuj to, czego nie możesz odzyskać#

W przypadku linków opublikowanych w kontekstach, do których nie masz już dostępu - konto społecznościowe poprzedniego miejsca pracy, które opuściłeś, post w społeczności na platformie, którą usunąłeś - nie ma ścieżki odzyskiwania. Te stare linki tinyurl.com będą nadal działać tak długo, jak TinyURL pozostaje aktywny, ale nie masz możliwości ich aktualizacji, przekierowywania przez Elido ani pobierania z nich analityki po zaprzestaniu korzystania z konta. Zaakceptuj to i idź dalej. Migracja tego, co możesz znaleźć, jest właściwym wyborem; perfekcja nie jest tu osiągalna.

Import do Elido#

Niezależnie od tego, która ścieżka wygenerowała Twój CSV, wywołanie importu jest takie samo. Kluczowe rozróżnienie to to, co umieszczasz w polu slug.

Jeśli masz niestandardową domenę brandowaną: możesz próbować zachować slugi ze Ścieżki A. Najpierw zarejestruj swoją domenę w Elido, a następnie przekaż slug jawnie w treści importu masowego. Kształt wywołania:

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: tinyurl-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "original-slug",
        "destination_url": "https://your-long-destination.com/path",
        "tags": ["tinyurl-migrated"]
      }
    ]
  }'

domain_id musi odwoływać się do domeny już zarejestrowanej i zweryfikowanej w Twoim workspace. Endpoint akceptuje do 100 linków na wywołanie i zwraca status powodzenia/niepowodzenia per element - konflikt sluga w jednym wierszu nie przerywa całej partii.

Jeśli byłeś na tinyurl.com/ bez niestandardowej domeny: pomiń pole slug lub podaj null. Elido wygeneruje slug dla każdego linku. Zaakceptuj zmianę sluga. Stare linki tinyurl.com nie przekierowują do Twoich nowych linków Elido - nie ma łańcucha 301, który możesz zainstalować, ponieważ nie jesteś właścicielem tinyurl.com. Jedynym sposobem na przywrócenie ruchu jest aktualizacja każdej opublikowanej powierzchni zawierającej stary link. To jest właśnie ta praca.

Ograniczenie łańcucha 301 dla linków bez własnej domeny#

To zasługuje na bezpośrednie stwierdzenie. Przewodnik migrate-from-bitly-without-breaking-links szczegółowo omawia wzorzec mostu 301 dla migracji z Bitly. Ten wzorzec zakłada, że kontrolujesz domenę źródłową. W przypadku linków tinyurl.com tak nie jest.

Nie istnieje żaden mechanizm udostępniany przez TinyURL, który pozwalałby zainstalować przekierowanie z istniejącego tinyurl.com/<slug> na nowy cel. Link nadal rozwiązuje się tam, gdzie był skierowany w momencie tworzenia. Jeśli chcesz, żeby ruch idący do tinyurl.com/abc123 trafił zamiast tego na Twój nowy link Elido, masz dwie opcje:

1. Zaktualizuj każdą opublikowaną powierzchnię, aby używała nowego linku Elido. To jest właściwe podejście.
2. Pozostaw link TinyURL wskazujący na cel i pozwól Elido obsługiwać tylko przyszłe linki. Akceptowalne, jeśli stare linki są rzadko używane i niekrytyczne dla biznesu.

Opcja 2 to nie jest właściwa "migracja" - to współistnienie. Dla większości zespołów sensowne jest połączenie obu: pełna migracja nowego tworzenia linków do Elido, aktualizacja najważniejszych starych powierzchni o dużym ruchu i bezwysiłkowe wygasanie długiego ogona starych linków TinyURL z zerowymi kliknięciami.

Walidacja#

Po imporcie sprawdź, czy to, co ma znaczenie, faktycznie działa.

Weź swój posortowany CSV i wyciągnij top 50 wierszy według wolumenu kliknięć (ze Ścieżki A) lub według daty publikacji i wielkości odbiorców (ze Ścieżki B, gdzie szacujesz ważność). Dla każdego z tych linków:

1. Jeśli byłeś na niestandardowej domenie brandowanej i zachowałeś slugi: przetestuj, czy https://short.yourbrand.com/<slug> rozwiązuje się do właściwego celu. Dashboard Elido pokazuje status 200 lub błąd. Alternatywnie uruchom sprawdzenie curl:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://short.yourbrand.com/your-slug"

2. Jeśli wygenerowałeś nowe slugi: sprawdź, czy docelowe URL-e w dashboardzie Elido pasują do Twojego źródłowego CSV. Odpowiedź importu zawiera status powodzenia/niepowodzenia per element; przejrzyj log niepowodzeń przed zamknięciem migracji.

3. Sprawdź najnowsze wysyłki newsletterów o wysokim współczynniku otwarć i ostatnie posty społecznościowe. Jeśli zawierają linki TinyURL i zaktualizowałeś je na linki Elido, sprawdź, czy zaktualizowane linki działają. Jeśli ich nie zaktualizowałeś - zanotuj je wyraźnie. To linki najprawdopodobniej mające aktywny ruch kliknięć, który pozostawiasz poza swoją analityką.

Dla każdej powierzchni, którą zaktualizowałeś, potwierdź, że aktualizacja faktycznie dotarła do opublikowanej wersji. Newsletter przełożony ze starymi linkami, edytowany tweet, artykuł pomocy buforowany przez CDN - to miejsca, w których aktualizacja nie dociera od razu.

Realistyczna uwaga o slugach, których nie możesz zachować#

Wersja bezpośrednia: jeśli byłeś na darmowym planie TinyURL i publikowałeś linki tinyurl.com/<slug>, nie migrujesz przestrzeni slugów. Migrujesz listę docelowych URL-i i zaczynasz od nowa w Elido z nowymi slugami na własnej domenie. Stare linki tinyurl.com istnieją bezterminowo w infrastrukturze TinyURL. Nie możesz ich aktualizować, przekierowywać ani pobierać z nich analityki po zaprzestaniu korzystania z konta.

To nie jest porażka procesu migracyjnego. To właściwe oczekiwanie. Darmowy plan TinyURL nigdy nie był platformą do zarządzania linkami - był narzędziem do skracania. Wyjście z niego oznacza zaakceptowanie, że praca włożona w niego jest w dużej mierze nieodwracalna z punktu widzenia przenośności slugów.

To, co zyskujesz, to to, co przychodzi po: brandowane krótkie linki na domenie, którą posiadasz, analitykę kliknięć nieograniczoną do okna 30-dniowego i model cenowy skalujący się bez niespodzianek. Praca migracyjna to jednorazowy koszt. Ulepszone narzędzia to korzyść ciągła.

Jeśli oceniasz, czy Elido jest właściwym celem przed podjęciem pracy migracyjnej, porównanie elido-vs-tinyurl szczegółowo omawia lukę funkcjonalną i compliance.

Cytowania: dokumentacja TinyURL developer API dostęp: 2026-05-12. Strona cenowa TinyURL dostęp: 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.