Migrare da TinyURL: due percorsi e cosa preserva ciascuno

La migrazione da Bitly ha un playbook consolidato: export API, CSV, importazione in blocco, cambio DNS. La guida alla migrazione da Bitly copre ogni fase. TinyURL è diverso - non più difficile, ma diverso in un modo che cambia come si pianifica. La distinzione che conta di più è se hai un account TinyURL Pro. Quella singola variabile sdoppia la migrazione in due procedure quasi non correlate.

Questo post illustra entrambi i percorsi ed è onesto riguardo a ciò che non sopravvive al passaggio.

TL;DR#

• Se hai un account TinyURL Pro, l'API TinyURL ti permette di enumerare ed esportare i tuoi link. Il CSV include slug, destinazione e conteggi dei clic negli ultimi 30 giorni. Puoi importare su Elido in modo pulito.
• Se non hai un account - hai semplicemente pubblicato link tinyurl.com/<slug> nel corso degli anni - non c'è export. Ricostruisci la mappa eseguendo lo scraping delle tue superfici pubblicate.
• In nessuno dei due casi puoi preservare gli slug originali tinyurl.com nel tuo workspace Elido. TinyURL possiede il dominio. Genererai nuovi slug sul tuo dominio abbreviato brandizzato.
• La nota realistica: la maggior parte degli utenti TinyURL è sul tier gratuito. Per loro, la migrazione riguarda meno la portabilità dei dati e più l'aggiornamento di ogni posto in cui appare un link TinyURL.

Cosa rende la migrazione da TinyURL diversa da Bitly#

La differenza strutturale principale è il dominio. Gli utenti Bitly con piani a pagamento spesso utilizzano un dominio brandizzato personalizzato - links.tuobrand.com - che possiedono. Quando migrano, il record DNS per quel dominio si sposta per puntare all'edge di Elido, e ogni slug esistente continua a funzionare. Lo spazio degli slug è loro.

Gli utenti del tier gratuito di TinyURL sono su tinyurl.com. Non possiedono quel dominio e non possono installarci un redirect 301. Quando lasciano TinyURL, i vecchi link non li seguono. Rimangono attivi su tinyurl.com finché TinyURL funziona, ma il team che migra non ha alcun controllo su di essi, nessuna possibilità di intercettare i clic e nessuna catena 301 da mettere in atto.

TinyURL Pro offre domini brandizzati personalizzati a $9,99/mese (acceduta il 2026-05-12). Se sei stato su Pro e usi il tuo dominio, il percorso di migrazione è molto più simile allo scenario Bitly: verifica il dominio in Elido, pre-provisiona gli slug, poi cambia il CNAME DNS. La documentazione dei domini personalizzati copre il lato Elido di quel cambio.

L'altra differenza strutturale è il log di audit. TinyURL ha una visibilità limitata sui dati storici anche su Pro. Il confronto elido-vs-tinyurl copre il gap completo di funzionalità. Per la pianificazione della migrazione, l'implicazione pratica è che non sarai in grado di ricostruire una cronologia completa dei clic. Non pianificarci sopra.

Percorso A: hai un account TinyURL Pro#

TinyURL Pro espone un'API su https://tinyurl.com/app/dev (acceduta il 2026-05-12). L'API supporta la creazione e il recupero di alias. L'enumerazione funziona tramite chiamate GET paginate che restituiscono i tuoi link in batch.

Le fasi:

1. Genera il tuo token API dalle impostazioni dell'app TinyURL.
2. Enumera tutti gli alias, paginando fino al completamento. TinyURL applica limiti di frequenza; la documentazione dell'API specifica il limite di richieste al minuto. Costruisci un gestore di backoff prima di iniziare - un 429 a metà export è fastidioso ma non distruttivo per i dati se hai scritto i risultati su disco in modo incrementale.
3. Per ogni alias, raccogli lo slug, l'URL di destinazione e il conteggio dei clic degli ultimi 30 giorni. L'API di TinyURL non espone eventi di clic grezzi o serie temporali storiche. Ottieni un aggregato.
4. Scrivi un CSV flat: una riga per link, colonne slug,target_url,clicks_30d.
5. Ordina per clicks_30d in ordine decrescente. Il top 1% dei link per volume di clic è tipicamente la frazione che conta davvero per le campagne in corso o i contenuti pubblicati. Dai priorità a queste per la validazione e gli aggiornamenti delle superfici. La lunga coda dei link con zero clic può essere importata ma raramente necessita di attenzione umana.

Una volta che hai il CSV, l'importazione su Elido segue la stessa struttura di qualsiasi altra migrazione in blocco. Le meccaniche dettagliate dell'importazione in blocco si trovano nel playbook di migrazione da Bitly - la struttura dell'API e la chiamata TypeScript SDK sono identiche; cambia solo il dato sorgente.

La catena 301 per i domini brandizzati su Pro#

Se il tuo account TinyURL Pro utilizzava un dominio brandizzato personalizzato, puoi portare quel dominio su Elido. Registralo nel tuo workspace Elido tramite il flusso dei domini personalizzati, pre-provisiona tutti gli slug, poi cambia il CNAME:

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

La semantica HTTP 301 si applica qui: una volta che il CNAME si risolve all'edge di Elido, browser e bot che seguono i vecchi link riceveranno una risposta 301 Moved Permanently da Elido che punta all'URL di destinazione. Non è necessario alcun hop di redirect tramite TinyURL perché lo spazio degli slug era sul tuo dominio, non su tinyurl.com. Questo è il percorso pulito.

Lo standard rilevante è la RFC 7231 §6.4.2, che definisce la semantica del 301 Moved Permanently. Il client che riceve un 301 dovrebbe aggiornare qualsiasi URL memorizzato alla nuova posizione. In pratica, i client email e le piattaforme social variano in quanto aggressivamente seguano questo - ma il redirect stesso è affidabile per i browser web e per i bot che rispettano le specifiche HTTP.

Percorso B: nessun account, solo link pubblicati#

Questo è lo scenario più comune. Hai un account TinyURL gratuito o nessun account, e hai una raccolta di link tinyurl.com/<slug> pubblicati nel tuo archivio newsletter, post social, materiali stampati o documentazione. Non hai accesso alle API e nessun meccanismo di export. I link esistono; non hai un elenco di essi.

L'unico modo per costruire l'inventario è cercare nelle tue superfici pubblicate.

Trovare i link#

Lavora sistematicamente su ogni superficie:

• Archivio email/newsletter: cerca nell'archivio della tua piattaforma email per tinyurl.com. La maggior parte delle piattaforme ti permette di cercare nelle campagne inviate. Esporta le corrispondenze.
• Social media: cerca nei tuoi post Twitter/X, LinkedIn e Facebook per i link tinyurl.com. La maggior parte delle piattaforme ha un export del contenuto a livello di account. Scaricalo e usa grep.
• Sito web e documentazione: esegui una ricerca del sito o una scansione. grep -r "tinyurl.com" ./content su un repo di siti statici richiede pochi secondi.
• Link di tracciamento delle piattaforme pubblicitarie: controlla i link taggati con UTM in Google Ads, Meta Ads Manager o ovunque tu abbia gestito campagne a pagamento.

Una volta che hai l'elenco dei valori tinyurl.com/<slug>, hai bisogno degli URL di destinazione. Se hai creato i link tu stesso e riesci a ricordare la destinazione, ottimo. In caso contrario: segui ogni link manualmente o con uno script che emette una richiesta HEAD e legge l'header Location. Il redirect TinyURL stesso è accessibile pubblicamente - non hai bisogno di un account per risolvere dove va un link tinyurl.com.

# Risolvi in blocco le destinazioni TinyURL da un file di slug (uno per riga)
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

Questo ti fornisce il CSV slug,target_url necessario per l'importazione. Nota che importerai con nuovi slug sul tuo dominio - ne parliamo più avanti.

Accetta ciò che non puoi recuperare#

Per i link pubblicati in contesti a cui non hai più accesso - l'account social di un lavoro passato, un post in una community su una piattaforma che hai eliminato - non c'è percorso di recupero. Quei vecchi link tinyurl.com continueranno a funzionare finché TinyURL rimarrà operativo, ma non hai la possibilità di aggiornarli, reindirizzarli tramite Elido o osservare chi li clicca dopo aver smesso di usare l'account. Accettalo e vai avanti. Migrare ciò che riesci a trovare è la scelta giusta; la perfezione non è raggiungibile qui.

Importazione su Elido#

Indipendentemente dal percorso che ha generato il tuo CSV, la chiamata di importazione è la stessa. La distinzione chiave è cosa metti nel campo slug.

Se hai un dominio brandizzato personalizzato: puoi tentare di preservare gli slug dal Percorso A. Registra prima il tuo dominio in Elido, poi passa slug esplicitamente nel corpo dell'importazione in blocco. La struttura della chiamata:

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"]
      }
    ]
  }'

Il domain_id deve fare riferimento a un dominio già registrato e verificato nel tuo workspace. L'endpoint accetta fino a 100 link per chiamata e restituisce lo stato di successo/fallimento per elemento - un conflitto di slug su una riga non interrompe il batch.

Se eri su tinyurl.com/ senza dominio personalizzato: ometti il campo slug o passa null. Elido genererà uno slug per ogni link. Accetta il cambio di slug. I vecchi link tinyurl.com non si reindirizzano ai tuoi nuovi link Elido - non c'è una catena 301 che puoi installare perché non possiedi tinyurl.com. L'unico modo per riconnettere il traffico è aggiornare ogni superficie pubblicata che contiene il vecchio link. Questo è il lavoro.

La limitazione della catena 301 per i link non brandizzati#

Questo merita una dichiarazione diretta. La guida migrate-from-bitly-without-breaking-links copre in dettaglio il pattern del bridge 301 per le migrazioni Bitly. Quel pattern presuppone che tu controlli il dominio di origine. Per i link tinyurl.com, non è così.

Non esiste alcun meccanismo che TinyURL esponga per installare un redirect da un tinyurl.com/<slug> esistente verso una nuova destinazione. Il link continua a risolversi ovunque puntasse quando lo hai creato. Se vuoi che il traffico che andava su tinyurl.com/abc123 atterri invece sul tuo nuovo link Elido, hai due opzioni:

1. Aggiorna ogni superficie pubblicata per usare il nuovo link Elido. Questo è l'approccio corretto.
2. Lascia il link TinyURL che punta alla destinazione e lascia che Elido gestisca solo i link futuri. Accettabile se i vecchi link sono usati raramente e non sono business-critical.

L'opzione 2 non è una vera "migrazione" - è coesistenza. Per la maggior parte dei team, la combinazione di entrambe ha senso: migra completamente la creazione di nuovi link su Elido, aggiorna le superfici più trafficate, e lascia che la lunga coda di vecchi link TinyURL a zero clic decada senza sforzo.

Validazione#

Dopo l'importazione, verifica che ciò che conta funzioni davvero.

Prendi il tuo CSV ordinato e preleva le 50 righe principali per volume di clic (dal Percorso A) o per data di pubblicazione e dimensione del pubblico (dal Percorso B, dove stai stimando l'importanza). Per ognuno di questi link:

1. Se eri su un dominio brandizzato personalizzato e hai preservato gli slug: verifica che https://short.tuobrand.com/<slug> si risolva alla destinazione corretta. La dashboard di Elido mostra lo stato 200 vs. errore. In alternativa, esegui un controllo curl:

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

2. Se hai generato nuovi slug: verifica che gli URL di destinazione nella dashboard di Elido corrispondano al tuo CSV sorgente. La risposta di importazione include lo stato di successo/fallimento per elemento; esamina il log dei fallimenti prima di chiudere la migrazione.

3. Controlla i tuoi invii di newsletter più recenti con alto tasso di apertura e i post social recenti. Se contengono link TinyURL e li hai aggiornati a link Elido, verifica che i link aggiornati funzionino. Se non li hai aggiornati - annotali esplicitamente. Questi sono i link più probabili ad avere traffico di clic attivo che stai lasciando fuori dai tuoi analytics.

Per qualsiasi superficie che hai aggiornato, conferma che l'aggiornamento abbia effettivamente raggiunto la versione pubblicata. Una newsletter riprogrammata con vecchi link, un tweet modificato, un articolo di help messo in cache da una CDN - questi sono i luoghi dove l'aggiornamento non arriva immediatamente.

La nota realistica sugli slug che non puoi mantenere#

La versione diretta: se eri sul tier gratuito di TinyURL e pubblicavi link tinyurl.com/<slug>, non stai migrando uno spazio di slug. Stai migrando un elenco di URL di destinazione e ripartendo da zero su Elido con nuovi slug sul tuo dominio. I vecchi link tinyurl.com esistono in perpetuo sull'infrastruttura di TinyURL. Non puoi aggiornarli, reindirizzarli o estrarne analytics dopo aver smesso di usare l'account.

Questa non è una mancanza del processo di migrazione. È l'aspettativa corretta. Il tier gratuito di TinyURL non è mai stato una piattaforma di gestione dei link - era un'utility di abbreviazione. Lasciarlo significa accettare che il lavoro che hai investito sia in gran parte irrecuperabile dal punto di vista della portabilità degli slug.

Quello che guadagni è ciò che viene dopo: link abbreviati brandizzati su un dominio che possiedi, click analytics che non si fermano a una finestra di 30 giorni e un modello di prezzo che scala senza sorprese. Il lavoro di migrazione è un costo una tantum. Il miglioramento degli strumenti è continuo.

Se stai valutando se Elido è la destinazione giusta prima di impegnarti nel lavoro di migrazione, il confronto elido-vs-tinyurl copre in dettaglio il gap di funzionalità e conformità.

Citazioni: Documentazione API sviluppatori TinyURL acceduta il 2026-05-12. Pagina dei prezzi TinyURL acceduta il 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.