Migrare da TinyURL: cosa si sposta, cosa resta, cosa si rompe

Per migrare da TinyURL, per prima cosa dividi i tuoi link in due gruppi: i link su un dominio tuo e i link su tinyurl.com. Il primo gruppo si sposta senza problemi, perché cambi un solo record DNS e i vecchi URL continuano a funzionare. Il secondo gruppo non puoi reindirizzarlo affatto, perché il dominio è di TinyURL. Puoi copiare le destinazioni in Elido, ma ogni posto in cui è stato pubblicato un link tinyurl.com/xxxx va aggiornato a mano.

La seconda cosa da sapere prima di iniziare: al momento il modo affidabile per migrare è un file. Esporta con la chiamata documentata GET /urls/available di TinyURL, riduci il risultato a destination, slug, title e caricalo con l'import in blocco di Elido. Elido include anche un importer TinyURL con un clic, ma chiama un endpoint che non è nell'API pubblicata di TinyURL, quindi lo consideriamo non verificato finché non arriverà la correzione prevista. Questa guida copre entrambe le strade e l'intero percorso: dall'export agli analytics, con cutover e rollback nel mezzo. I fatti su TinyURL provengono dal suo blog e dalla sua OpenAPI spec, consultati il 2026-10-01 e il 2026-10-02.

Per un verdetto funzione per funzione sull'opportunità di cambiare, leggi Elido vs TinyURL o la rassegna più ampia delle alternative a TinyURL.

Quali link TinyURL possono spostarsi

La proprietà dell'hostname decide tutto. Un link breve è due cose: un hostname e un codice. Puoi portare un codice ovunque, ma puoi far continuare a funzionare un link solo se controlli l'hostname.

La versione onesta per le prime due righe: quando smetti di pagare TinyURL, quei link continuano a risolversi finché TinyURL li mantiene, e tu non hai modo di vedere i clic, modificarli o reindirizzarli. Alcuni team li lasciano com'è di proposito. Penso sia la scelta giusta per i link vecchi e a basso traffico.

Passaggio 1: esporta i tuoi link TinyURL

TinyURL ti dà un solo modo documentato per elencare i tuoi link: l'API. La sua OpenAPI spec (consultata il 2026-10-02) definisce l'elenco come GET /urls/{type}, dove type è available o archived, con datetime facoltativi from e to e un filtro search che accetta un prefisso alias: o tag:. La chiamata richiede un bearer token. Anche l'articolo di TinyURL sull'elenco dei link descrive lo stesso endpoint e dice che il tipo è l'unico input obbligatorio.

Conta altrettanto ciò che la spec non ti dà. Non definisce parametri page o per_page né rate limit. Quindi, per un account grande, restringi ogni richiesta con finestre from/to (un mese alla volta, ad esempio) e scrivi ogni risposta su disco prima di fare qualsiasi altra cosa:

# One window at a time; inspect the first response by hand before scripting further
curl -s -H "Authorization: Bearer $TINYURL_TOKEN" \
  "https://api.tinyurl.com/urls/available?from=2025-01-01T00:00:00Z&to=2025-02-01T00:00:00Z" \
  > tinyurl-2025-01.json

Non abbiamo verificato la forma della risposta reale (la spec non chiarisce se contenga una lista o un singolo oggetto), quindi apri un file e guardalo prima di scrivere un parser. Esegui la stessa chiamata su /urls/archived se vuoi anche i link archiviati.

Tre limiti plasmano il resto del piano:

• Nessun account, nessun elenco. TinyURL dichiara che i link creati senza accedere non possono essere gestiti né eliminati. Non esiste un record per utente, quindi non c'è nulla da esportare.
• Il piano gratuito è in sola lettura. Secondo la pagina del piano gratuito di TinyURL, modifica ed eliminazione dei link, analytics dei clic, domini personalizzati e creazione in blocco stanno tutti dietro i piani a pagamento.
• Gli analytics non sono nell'elenco. La cronologia dei clic è a tuo carico. Fanne uno screenshot o estraila in un report da TinyURL prima di disdire. Non abbiamo trovato un pulsante di export CSV documentato nel centro assistenza di TinyURL, quindi questa guida non ne promette uno.

Passaggio 2: mappa i dati TinyURL su un file che Elido accetta

Qualunque cosa tu abbia estratto da TinyURL, riducila agli stessi tre campi:

• L'URL lungo di TinyURL diventa destination (la destinazione del link).
• L'alias di TinyURL diventa slug. Lascialo vuoto per i link su tinyurl.com per cui vuoi codici nuovi.
• Il titolo o la descrizione di TinyURL diventa title.

TinyURL li chiama alias, Elido li chiama slug. Sono la stessa cosa: i caratteri dopo l'host. Se il dominio di destinazione è vuoto, gli alias passano invariati.

La pagina dei link di Elido ha una scheda in blocco e una scheda CSV, ed entrambe leggono righe nella forma url, slug, title. Nella scheda CSV la prima riga viene scartata se non contiene un URL http(s)://, quindi una riga di intestazione è sicura. Le righe che iniziano con # vengono ignorate nella casella di incolla. Gli slug personalizzati sono lettere, numeri e trattini, quindi controlla gli alias con altri caratteri prima di caricare; le righe che falliscono vengono elencate con un motivo.

destination,slug,title
https://acme.com/spring-sale,spring-sale,Spring Sale
https://acme.com/pricing,,Pricing page

Se hai usato i tag di TinyURL, conservali. Non entrano nel CSV a tre colonne, ma la strada API qui sotto li accetta.

Passaggio 3: importa in Elido

Ci sono due strade. Quella con il file funziona oggi. L'importer integrato esiste ma non è verificato.

La strada affidabile: CSV, incolla in blocco o API bulk

Le schede bulk e CSV della dashboard elaborano fino a 100 link per batch, quindi dividi un file più grande in blocchi. La pagina di aiuto sull'import in blocco illustra il modulo, e la guida all'import in blocco da Google Sheets è utile se hai ripulito l'export in un foglio di calcolo.

L'API del workspace accetta la stessa struttura in JSON. POST /v1/workspaces/{workspace_id}/links/bulk accetta un domain_id e fino a 100 links, ciascuno con destination_url e facoltativamente slug, title e tags. Ogni riga viene elaborata da sola, quindi una riga errata non fa fallire il batch, e la risposta indica quali righe sono andate in errore. Aggiungi tu un tag come imported:tinyurl per poter filtrare il batch in seguito. API e SDK ha le librerie client.

L'importer TinyURL integrato e il suo bug noto

Elido ha un importer TinyURL con un clic, descritto nella pagina migra da TinyURL. Incolli un token API di TinyURL, scegli il dominio Elido su cui devono arrivare i link e una strategia di conflitto. Il problema è la prima chiamata HTTP. Il worker costruisce questa richiesta:

GET https://api.tinyurl.com/aliases?page=1&per_page=100
Authorization: Bearer <token>

e si aspetta in risposta {"data": [{alias, url, title, tags}], "meta": {"total", "has_more"}}. La spec di TinyURL non ha un percorso /aliases; le operazioni sugli alias stanno sotto /alias/{domain}/{alias}, e l'elenco è /urls/{type}. Quindi quel contratto di paginazione non è mai stato preso da TinyURL. Il nostro unit test serve una risposta scritta a mano nella forma presunta e passa, il che dimostra che il parser corrisponde alla nostra ipotesi e nulla su TinyURL. Non l'abbiamo eseguito su un account reale, perché serve un token di un piano a pagamento. Non pianificare ancora una migrazione basandoti su di esso.

La correzione è prevista: passare a /urls/available (con /urls/archived dietro un flag), scorrere le finestre from/to, fare il parsing in modo difensivo e testare su una risposta reale catturata. Dopo, paginazione e limite reale per richiesta vanno rimisurati su un account reale, dato che la spec non fornisce né l'una né l'altro.

La pagina delle integrazioni in un workspace DEMO con dati sintetici. La migrazione da TinyURL si avvia da qui.

Cosa fa l'importer una volta ottenuta una pagina

Tutto ciò che viene dopo la chiamata HTTP non dipende dalla questione dell'endpoint, e questa parte possiamo affermarla dal codice.

• Avvio. POST con token, target_domain_id e conflict_strategy facoltativo. L'handler rifiuta un token vuoto, un dominio mancante e qualsiasi strategia diversa da suffix, skip, fail, poi risponde 202 con il job ed esegue il worker in background, staccato dalla richiesta.
• Per ogni link. Una riga senza URL o senza alias conta come fallita con un motivo. Altrimenti l'alias diventa lo slug, destinazione e titolo vengono copiati (titolo troncato a 200 caratteri) e i tag vengono copiati con imported:tinyurl aggiunto.
• Avanzamento. I contatori vengono scritti sulla riga del job ogni 50 link. Per ogni job vengono registrate al massimo 1.000 righe di errore.
• Errori di autenticazione e di rate. Un 401 o 403 fa fallire il job con un messaggio "check the bearer token", e un 429 lo fa fallire come rate-limited. Non ci sono retry né backoff: il job si ferma.

Il token passa dal corpo della richiesta al job in background e da nessun'altra parte. La riga del job non registra alcun token, e nulla è cifrato a riposo perché nulla viene memorizzato. Il corpo della richiesta viene letto con un limite di 4 KB. Il codice non convalida il token né controlla il piano prima di partire, quindi un token errato compare come job fallito dopo la prima richiesta, non come errore del modulo. Le versioni precedenti della nostra documentazione descrivevano un controllo preliminare su un endpoint dei domini; quel passaggio non esiste nel codice, e nemmeno la spec di TinyURL ha un percorso simile.

Regole sui conflitti e limiti

Prima di ogni inserimento il worker fa una ricerca indicizzata per la coppia dominio e slug:

• suffix (predefinita) prova alias-2, alias-3, fino a alias-50, e fa fallire la riga se sono tutti occupati.
• skip lascia stare il link Elido esistente e registra la riga sorgente.
• fail fa fallire il job al primo conflitto.

Ogni esecuzione è limitata a 50.000 link e 30 minuti. Due comportamenti vale la pena conoscerli. Quando si raggiunge il tetto di 50.000, il ciclo si ferma semplicemente e il job si completa; non fallisce, quindi confronta i conteggi finali con il totale della sorgente. Quando il budget di 30 minuti si esaurisce, il job viene segnato come fallito con il numero di link importati fino a quel momento.

L'elenco dei link in un workspace DEMO. I link importati hanno il tag imported:tinyurl, così puoi filtrare un batch per la revisione.

Testare l'importer in sicurezza

Quando l'endpoint verrà corretto, o se provi l'importer prima di allora, fallo in piccolo. Crea un workspace usa e getta, aggiungi un dominio vuoto ed esegui prima il job con la strategia fail. Un dominio vuoto significa nessun conflitto, quindi qualsiasi errore è un problema di parsing o di autenticazione, non una collisione. Poi confronta tre numeri: il conteggio sorgente in TinyURL, il total che il job riporta e i contatori importati più saltati più falliti. Dato che il worker prende meta.total dalla risposta che si aspetta, uno scarto tra total e il tuo conteggio reale è il primo segnale che la forma della risposta differisce da quella presunta dal parser. Filtra per imported:tinyurl, apri dieci link a caso e controlla destinazione, slug e titolo rispetto a TinyURL.

Avviare un nuovo workspace Elido per questo richiede un paio di minuti; crea un account gratuito e aggiungi prima il tuo dominio, così è pronto quando l'import finisce.

Passaggio 4: fai il cutover del dominio personalizzato

Se usi un hostname brandizzato su TinyURL, sei nel caso facile. La configurazione del dominio brandizzato di TinyURL è un CNAME o una modifica DNS simile su un dominio che già possiedi, quindi la stessa leva funziona al contrario. Nota che l'importer non crea il dominio per te né legge un campo domain di TinyURL. L'hostname brandizzato è un passaggio a sé.

L'ordine conta, perché il DNS è l'ultimo passaggio e l'unico che i visitatori percepiscono:

1. Abbassa il TTL del record con un giorno di anticipo, così il passaggio sarà rapido.
2. Aggiungi l'hostname a Elido in Domini e lascia che si verifichi. La guida aggiungere un dominio ha i record esatti, e la risoluzione dei problemi di verifica DNS copre gli errori di battitura dietro la maggior parte degli stati "Pending" bloccati.
3. Importa gli alias su quell'hostname mentre i visitatori raggiungono ancora TinyURL.
4. Controlla a campione gli slug importati rispetto al comportamento precedente dell'hostname in produzione.
5. Cambia il record DNS. Da quel momento l'hostname si risolve su Elido e ogni vecchio URL su di esso lo segue.

Tieni l'hostname solo DNS, senza proxy CDN davanti, perché l'emissione del certificato può fallire dietro uno. La configurazione completa è in domini personalizzati per link brevi e nella pagina della funzione domini personalizzati.

Passaggio 5: mantieni intatti i tuoi redirect 301

Sul tuo dominio l'URL non cambia, quindi non c'è nulla da colmare: lo stesso percorso ora risponde da Elido. Quello che proteggi è la semantica del redirect. I codici di stato dei redirect sono definiti in RFC 9110; un redirect permanente dice a browser e motori di ricerca che la destinazione è stabile, e passare link di lunga data a temporaneo cambia il modo in cui vengono messi in cache e accreditati. Leggi 301 vs 302 per il lato SEO e cache.

Per i link tinyurl.com non c'è alcun 301 che puoi aggiungere, perché il redirect è di TinyURL. Il massimo che puoi fare è assicurarti che la destinazione dietro il vecchio link resti viva e sostituire il link ovunque tu possa arrivare. Il playbook di migrazione da Bitly mostra come funziona un ponte 301 quando il vecchio hostname è tuo.

Passaggio 6: verifica la migrazione

La migrazione è finita quando ogni posizionamento di un link punta a qualcosa che controlli. Usa questa lista in ordine.

1. Blocca i nuovi link in TinyURL. Da ora crea tutto ciò che è nuovo in Elido.
2. Archivia i file di export di TinyURL e tutti i report, con la data.
3. Filtra il batch importato in Elido con il tag imported:tinyurl.
4. Confronta i conteggi. Importati più saltati più falliti devono essere uguali al numero di righe della sorgente.
5. Correggi i fallimenti. Ogni riga fallita ha un motivo, di solito un URL non valido o un carattere errato nello slug.
6. Testa i link principali. Prendi i tuoi 50 link più importanti e richiedili uno per uno:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://go.yourbrand.com/spring-sale

7. Confronta destinazione e sorgente per quei 50. Verifica che l'URL finale coincida, inclusi i parametri UTM.
8. Ritesta dopo il DNS da una rete che non abbia messo in cache il vecchio record.
9. Aggiorna i posizionamenti tinyurl.com. Cerca tinyurl.com negli archivi email, nelle bio social, sulle piattaforme pubblicitarie e nella stampa, e sostituisci ciò che puoi.

Per le superfici che non puoi raggiungere, accetta la perdita. I vecchi QR code stampati e i post dimenticati continueranno a puntare a TinyURL, e questo vale per ogni migrazione tra shortener. Migrare da Bitly senza rompere i link ha una verifica più rigorosa se la vuoi.

Passaggio 7: pianifica il rollback

Tieni TinyURL per un mese se puoi, e cerca i ritardatari prima di disdire un piano a pagamento. Finché TinyURL serve ancora i link del tuo hostname brandizzato, il rollback è una modifica DNS di ritorno al vecchio record, e il TTL basso lo rende rapido.

Dentro Elido, il tag imported:tinyurl è la maniglia per annullare un batch: filtra, poi modifica in blocco o elimina. Se un'esecuzione dell'importer muore a metà (un deploy o un crash la ferma, e un controllo ogni cinque minuti porta a failed i job senza progresso da 30 minuti), non c'è un cursore salvato, quindi riavvii il job. Rieseguire è sicuro con suffix o skip, ma suffix creerà copie -2 dei link che la prima esecuzione ha già scritto, quindi per una nuova esecuzione preferisci skip.

Passaggio 8: imposta le aspettative sugli analytics

La cronologia dei clic non passa con nessuna delle due strade. L'importer legge solo i campi del link, e un CSV non ha una colonna dei clic. I nuovi clic contano dal momento in cui un link è attivo in Elido, il che per un dominio personalizzato significa dalla modifica DNS. Aspettati una breve finestra in cui alcuni visitatori raggiungono ancora TinyURL da record in cache.

Restano indietro anche stile dei QR e template, oltre a tutto ciò che è stato creato senza account. Se tracci campagne, porta con te ora le tue convenzioni UTM; i parametri UTM spiegati è un buon ripasso.

Cosa guadagni spostandoti

Te ne vai con link su un hostname che possiedi, quindi la prossima migrazione, se ci sarà, sarà una modifica DNS invece di un progetto. Ottieni anche analytics che partono dal cutover e un tag su cui fare query. La pagina dei prezzi elenca i piani, e Elido vs TinyURL ha il confronto diretto. Per la questione più ampia di cos'altro considerare, il post sulle alternative a TinyURL mette a confronto il panorama.

Correlati sul blog

• Elido vs TinyURL
• Alternative a TinyURL
• Bitly vs TinyURL
• Migrare da Bitly: il playbook
• Importare link brevi in blocco da Google Sheets
• Domini personalizzati per link brevi