Migrar do TinyURL: dois caminhos e o que cada um preserva

Migrar do Bitly tem um guia bem estabelecido: exportação de API, CSV, importação em massa, transição de DNS. O guia de migração do Bitly cobre cada passo. O TinyURL é diferente - não mais difícil, mas diferente de uma forma que muda o modo como planeia. A distinção que mais importa é se tem uma conta TinyURL Pro. Essa variável única divide a migração em dois procedimentos quase sem relação.

Este artigo percorre ambos os caminhos e é honesto sobre o que não sobrevive à mudança.

Resumo#

• Se tem uma conta TinyURL Pro, a API do TinyURL permite-lhe enumerar e exportar os seus links. O CSV inclui slug, destino e contagens de cliques de 30 dias. Pode importar para o Elido de forma limpa.
• Se não tem uma conta - apenas publicou links tinyurl.com/<slug> ao longo dos anos - não há exportação. Reconstrói o mapa pesquisando as suas próprias superfícies publicadas.
• Em nenhum dos casos consegue preservar os slugs originais de tinyurl.com no seu workspace do Elido. O TinyURL é proprietário do domínio. Vai gerar novos slugs no seu próprio domínio curto com marca.
• A nota realista: a maioria dos utilizadores do TinyURL está no plano gratuito. Para eles, a migração é menos sobre portabilidade de dados e mais sobre atualizar cada lugar onde um link do TinyURL aparece.

O que torna a migração do TinyURL diferente da do Bitly#

A diferença estrutural fundamental é o domínio. Os utilizadores do Bitly nos planos pagos costumam estar num domínio com marca personalizada - links.suamarca.com - que lhes pertence. Quando migram, o registo DNS desse domínio passa a apontar para o edge do Elido, e todos os slugs existentes continuam a funcionar. O espaço de slugs é deles.

Os utilizadores do plano gratuito do TinyURL estão em tinyurl.com. Não são proprietários desse domínio e não podem instalar um redirecionamento 301 nele. Quando saem do TinyURL, os links antigos não os acompanham. Ficam ativos em tinyurl.com enquanto o TinyURL funcionar, mas a equipa que migra não tem controlo sobre eles, não tem capacidade de interceptar cliques e não tem nenhuma cadeia de 301 para instalar.

O TinyURL Pro oferece domínios com marca personalizados por $9.99/mês (acedida em 2026-05-12). Se esteve no Pro a usar o seu próprio domínio, o caminho de migração é muito mais próximo do cenário Bitly: verifique o domínio no Elido, pré-provisione os slugs, depois mude o CNAME de DNS. A documentação de domínios personalizados cobre o lado Elido dessa transição.

A outra diferença estrutural é o registo de auditoria. O TinyURL tem visibilidade limitada de dados históricos mesmo no Pro. A comparação elido-vs-tinyurl cobre a diferença completa de funcionalidades. Para o planeamento da migração, a implicação prática é que não conseguirá reconstruir um histórico de cliques completo. Não o inclua no orçamento.

Caminho A: tem uma conta TinyURL Pro#

O TinyURL Pro expõe uma API em https://tinyurl.com/app/dev (acedida em 2026-05-12). A API suporta criação e recuperação de aliases. A enumeração funciona através de chamadas GET paginadas que devolvem os seus links em lotes.

Os passos:

1. Gere o seu token de API a partir das definições da aplicação TinyURL.
2. Enumere todos os aliases, paginando até ao fim. O TinyURL aplica limites de taxa; a documentação da API especifica o limite de pedidos por minuto. Implemente um handler de backoff antes de começar - um 429 a meio da exportação é incómodo mas não destrói dados se estiver a escrever resultados para disco de forma incremental.
3. Para cada alias, recolha o slug, o URL de destino e a contagem de cliques de 30 dias. A API do TinyURL não expõe eventos de clique brutos nem séries temporais históricas. Obtém um agregado.
4. Escreva um CSV simples: uma linha por link, colunas slug,target_url,clicks_30d.
5. Ordene por clicks_30d de forma descendente. Os top 1% de links por volume de cliques é tipicamente a fração que realmente importa para campanhas em curso ou conteúdo publicado. Priorize-os para validação e atualizações de superfícies. A cauda longa de links com zero cliques pode ser importada, mas raramente precisa de atenção humana.

Depois de ter o CSV, a importação para o Elido segue a mesma forma que qualquer outra migração em massa. A mecânica detalhada de importação em massa está no guia de migração do Bitly - o formato da API e a chamada do SDK TypeScript são idênticos; apenas os dados de origem diferem.

A cadeia de 301 para domínios com marca no Pro#

Se a sua conta TinyURL Pro usou um domínio com marca personalizada, pode transferir esse domínio para o Elido. Registe-o no seu workspace do Elido através do fluxo de domínios personalizados, pré-provisione todos os slugs, depois altere o CNAME:

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

A semântica HTTP 301 aplica-se aqui: assim que o CNAME resolver para o edge do Elido, os browsers e bots que seguirem os links antigos receberão uma resposta 301 Moved Permanently do Elido apontando para o URL de destino. Não é necessário nenhum salto de redirecionamento pelo TinyURL porque o espaço de slugs estava no seu domínio, não em tinyurl.com. Este é o caminho limpo.

O standard relevante é o RFC 7231 §6.4.2, que define a semântica do 301 Moved Permanently. O cliente que recebe um 301 deve atualizar qualquer URL armazenado para a nova localização. Na prática, os clientes de e-mail e as plataformas sociais variam na agressividade com que seguem isto - mas o redirecionamento em si é fiável para browsers web e bots que respeitam a especificação HTTP.

Caminho B: sem conta, apenas links publicados#

Este é o cenário mais comum. Tem uma conta gratuita do TinyURL ou nenhuma conta, e tem uma coleção de links tinyurl.com/<slug> publicados no seu arquivo de newsletter, publicações sociais, materiais impressos ou documentação. Não tem acesso à API nem mecanismo de exportação. Os links existem; não tem uma lista deles.

A única forma de construir o inventário é pesquisar as suas próprias superfícies publicadas.

Encontrar os links#

Percorra cada superfície de forma sistemática:

• Arquivo de e-mail/newsletter: pesquise no arquivo da sua plataforma de e-mail por tinyurl.com. A maioria das plataformas permite pesquisar em campanhas enviadas. Exporte as correspondências.
• Redes sociais: pesquise nas suas publicações do Twitter/X, LinkedIn e Facebook por links tinyurl.com. A maioria das plataformas tem uma exportação de conteúdo ao nível da conta. Descarregue-a e use grep.
• Website e documentação: execute uma pesquisa de site ou crawl. grep -r "tinyurl.com" ./content num repositório de site estático demora segundos.
• Links de rastreamento de plataformas de anúncios: verifique os links marcados com UTM no Google Ads, Meta Ads Manager ou onde quer que tenha executado campanhas pagas.

Depois de ter a lista de valores tinyurl.com/<slug>, precisa dos URLs de destino. Se criou os links e consegue lembrar-se do destino, ótimo. Se não: siga cada link manualmente ou com um script que emita um pedido HEAD e leia o cabeçalho Location. O próprio redirecionamento do TinyURL é publicamente acessível - não precisa de uma conta para resolver para onde aponta um link tinyurl.com.

# Resolver em massa os destinos do TinyURL a partir de um ficheiro de slugs (um por linha)
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

Isto dá-lhe o CSV slug,target_url de que precisa para importação. Note que vai importar com novos slugs no seu próprio domínio - mais sobre isso abaixo.

Aceitar o que não consegue recuperar#

Para links publicados em contextos a que já não tem acesso - uma conta social de um trabalho anterior, uma publicação numa comunidade numa plataforma que apagou - não há caminho de recuperação. Esses links antigos de tinyurl.com continuarão a funcionar enquanto o TinyURL estiver operacional, mas não tem capacidade de os atualizar, redirecionar pelo Elido ou obter análises deles depois de parar de usar a conta. Aceite isto e avance. Migrar o que consegue encontrar é a decisão correta; a perfeição não é alcançável aqui.

Importar para o Elido#

Independentemente do caminho que gerou o seu CSV, a chamada de importação é a mesma. A distinção fundamental é o que coloca no campo slug.

Se tem um domínio com marca personalizada: pode tentar preservar os slugs do Caminho A. Registe primeiro o seu domínio no Elido, depois passe slug explicitamente no corpo da importação em massa. O formato da chamada:

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": "slug-original",
        "destination_url": "https://seu-destino-longo.com/caminho",
        "tags": ["tinyurl-migrated"]
      }
    ]
  }'

O domain_id deve referir-se a um domínio já registado e verificado no seu workspace. O endpoint aceita até 100 links por chamada e devolve o estado de sucesso/falha por item - um conflito de slug numa linha não aborta o lote.

Se estava em tinyurl.com/ sem domínio personalizado: omita o campo slug ou passe null. O Elido gerará um slug para cada link. Aceite a mudança de slug. Os links antigos de tinyurl.com não redirecionam para os seus novos links do Elido - não há nenhuma cadeia de 301 que possa instalar porque não é proprietário de tinyurl.com. A única forma de reconectar o tráfego é atualizar cada superfície publicada que contém o link antigo. Esse é o trabalho.

A limitação da cadeia de 301 para links sem marca#

Isto merece uma declaração direta. O guia migrar do Bitly sem quebrar links cobre o padrão de ponte 301 em detalhe para migrações do Bitly. Esse padrão assume que controla o domínio de origem. Para links tinyurl.com, não controla.

Não há nenhum mecanismo que o TinyURL exponha para instalar um redirecionamento de um tinyurl.com/<slug> existente para um novo destino. O link continua a resolver para onde apontava quando foi criado. Se quiser que o tráfego que ia para tinyurl.com/abc123 aterresse no seu novo link do Elido, tem duas opções:

1. Atualizar cada superfície publicada para usar o novo link do Elido. Esta é a abordagem correta.
2. Deixar o link do TinyURL a apontar para o destino e deixar o Elido tratar apenas os links futuros. Aceitável se os links antigos são usados raramente e não são críticos para o negócio.

A opção 2 não é realmente uma "migração" - é coexistência. Para a maioria das equipas, a combinação de ambas faz sentido: migrar a criação de novos links para o Elido completamente, atualizar as superfícies antigas de maior tráfego e deixar a cauda longa de links antigos do TinyURL com zero cliques decair sem esforço.

Validação#

Após a importação, verifique que o que importa está realmente a funcionar.

Pegue no seu CSV ordenado e extraia as 50 primeiras linhas por volume de cliques (do Caminho A) ou por data de publicação e tamanho de audiência (do Caminho B, onde está a estimar a importância). Para cada um desses links:

1. Se estava num domínio com marca personalizada e preservou slugs: teste que https://short.suamarca.com/<slug> resolve para o destino correto. O dashboard do Elido mostra o estado 200 vs. erro. Em alternativa, execute uma verificação curl:

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

2. Se gerou novos slugs: verifique que os URLs de destino no dashboard do Elido correspondem ao seu CSV de origem. A resposta de importação inclui sucesso/falha por item; reveja o log de falhas antes de fechar a migração.

3. Verifique os seus envios de newsletter com maior taxa de abertura mais recentes e as publicações sociais recentes. Se contiverem links do TinyURL e os atualizou para links do Elido, verifique que os links atualizados funcionam. Se não os atualizou - note-os explicitamente. Esses são os links com maior probabilidade de ter tráfego de cliques ativo que está a deixar fora das suas análises.

Para qualquer superfície que atualizou, confirme que a atualização chegou efetivamente à versão publicada. Uma newsletter reagendada com links antigos, um tweet editado, um artigo de ajuda em cache por uma CDN - estes são os locais onde a atualização não chega imediatamente.

A nota realista sobre slugs que não consegue guardar#

A versão direta: se estava no plano gratuito do TinyURL a publicar links tinyurl.com/<slug>, não está a migrar um espaço de slugs. Está a migrar uma lista de URLs de destino e a começar do zero no Elido com novos slugs no seu próprio domínio. Os links antigos de tinyurl.com existem em perpetuidade na infraestrutura do TinyURL. Não os consegue atualizar, redirecionar, nem obter análises deles depois de parar de usar a conta.

Isto não é uma falha do processo de migração. É a expectativa correta. O plano gratuito do TinyURL nunca foi uma plataforma de gestão de links - era um utilitário de encurtamento. Sair dele significa aceitar que o trabalho que lhe dedicou é em grande parte irrecuperável do ponto de vista da portabilidade de slugs.

O que ganha é o que vem a seguir: links curtos com marca num domínio que lhe pertence, análises de cliques que não param numa janela de 30 dias, e um modelo de preços que escala sem surpresas. O trabalho de migração é um custo único. As ferramentas melhoradas são contínuas.

Se está a avaliar se o Elido é o destino certo antes de se comprometer com o trabalho de migração, a comparação elido-vs-tinyurl cobre a diferença de funcionalidades e conformidade em detalhe.

Citações: Documentação da API de programadores do TinyURL acedida em 2026-05-12. Página de preços do TinyURL acedida em 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.