Migra de TinyURL: dos caminos y lo que cada uno preserva

Migrar de Bitly tiene un playbook bien rodado: exportación API, CSV, importación masiva, cutover de DNS. La guía de migración de Bitly cubre cada paso. TinyURL es diferente - no más difícil, pero diferente de una manera que cambia cómo planificas. La distinción que más importa es si tienes una cuenta TinyURL Pro. Esa única variable bifurca la migración en dos procedimientos casi no relacionados.

Este artículo recorre ambos caminos y es honesto sobre lo que no sobrevive a la mudanza.

TL;DR#

• Si tienes una cuenta TinyURL Pro, la API de TinyURL te permite enumerar y exportar tus enlaces. El CSV incluye slug, destino y conteos de clic de 30 días. Puedes importar a Elido limpiamente.
• Si no tienes una cuenta - has estado publicando enlaces tinyurl.com/<slug> a lo largo de los años - no hay exportación. Reconstruyes el mapa rastreando tus propias superficies publicadas.
• En ninguno de los casos puedes preservar los slugs originales de tinyurl.com en tu workspace de Elido. TinyURL posee el dominio. Generarás nuevos slugs en tu propio dominio corto de marca.
• La nota del realista: la mayoría de usuarios de TinyURL están en el plan gratuito. Para ellos, la migración es menos sobre portabilidad de datos y más sobre actualizar cada lugar donde aparece un enlace de TinyURL.

Qué hace diferente la migración de TinyURL respecto a Bitly#

La diferencia estructural clave es el dominio. Los usuarios de Bitly en planes de pago a menudo están en un dominio de marca personalizado - links.yourbrand.com - que ellos poseen. Cuando migran, el registro DNS para ese dominio se mueve para apuntar al edge de Elido, y cada slug existente continúa funcionando. El espacio de slug es suyo.

Los usuarios del plan gratuito de TinyURL están en tinyurl.com. No poseen ese dominio, y no pueden instalar una redirección 301 en él. Cuando dejan TinyURL, los enlaces antiguos no los siguen. Permanecen vivos en tinyurl.com durante el tiempo que TinyURL siga funcionando, pero el equipo que migra no tiene control sobre ellos, ni capacidad de interceptar clics, ni cadena 301 que instalar.

TinyURL Pro ofrece dominios personalizados de marca por 9,99 $/mes (consultado el 2026-05-12). Si has estado en Pro y usando tu propio dominio, el camino de migración está mucho más cerca del escenario de Bitly: verifica el dominio en Elido, pre-aprovisiona los slugs, luego cambia el CNAME de DNS. La documentación de dominios personalizados cubre el lado de Elido de ese cutover.

La otra diferencia estructural es el log de auditoría. TinyURL tiene visibilidad limitada de datos históricos incluso en Pro. La comparación elido-vs-tinyurl cubre la brecha completa de funciones. Para la planificación de migración, la implicación práctica es que no podrás reconstruir un historial completo de clics. No lo presupuestes.

Camino A: tienes una cuenta TinyURL Pro#

TinyURL Pro expone una API en https://tinyurl.com/app/dev (consultada el 2026-05-12). La API soporta creación y recuperación de alias. La enumeración funciona a través de llamadas GET paginadas que devuelven tus enlaces en lotes.

Los pasos:

1. Genera tu token API desde la configuración de la app TinyURL.
2. Enumera todos los alias, paginando hasta completar. TinyURL aplica límites de tasa; la documentación de la API especifica el techo de peticiones por minuto. Construye un manejador de backoff antes de empezar - un 429 a mitad de la exportación es molesto pero no destruye datos si has estado escribiendo resultados a disco incrementalmente.
3. Para cada alias, recopila el slug, la URL de destino y el conteo de clic de 30 días. La API de TinyURL no expone eventos de clic en bruto o timeseries históricas. Obtienes un agregado.
4. Escribe un CSV plano: una fila por enlace, columnas slug,target_url,clicks_30d.
5. Ordena por clicks_30d descendente. El top 1% de enlaces por volumen de clic suele ser la fracción que realmente importa para campañas en curso o contenido publicado. Prioriza esos para validación y actualizaciones de superficie. La cola larga de enlaces con cero clics puede importarse pero rara vez necesita atención humana.

Una vez que tengas el CSV, la importación a Elido sigue la misma forma que cualquier otra migración masiva. La mecánica detallada de importación masiva está en el playbook de migración de Bitly - la forma de la API y la llamada del SDK de TypeScript son idénticas; solo difieren los datos fuente.

La cadena 301 para dominios de marca en Pro#

Si tu cuenta TinyURL Pro usó un dominio personalizado de marca, puedes llevar ese dominio a Elido. Regístralo en tu workspace de Elido vía el flujo de dominios personalizados, pre-aprovisiona todos los slugs, luego cambia el CNAME:

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

La semántica HTTP 301 aplica aquí: una vez que el CNAME resuelve al edge de Elido, los navegadores y bots que sigan los enlaces antiguos recibirán una respuesta 301 Moved Permanently de Elido apuntando a la URL de destino. No se requiere un salto de redirección a través de TinyURL porque el espacio de slug estaba en tu dominio, no en tinyurl.com. Ese es el camino limpio.

El estándar relevante es el RFC 7231 §6.4.2, que define la semántica 301 Moved Permanently. El cliente que recibe un 301 debería actualizar cualquier URL almacenada a la nueva ubicación. En la práctica, los clientes de email y las plataformas sociales varían en cuán agresivamente siguen esto - pero la redirección en sí es fiable para navegadores web y para bots que respetan la especificación HTTP.

Camino B: sin cuenta, solo enlaces publicados#

Este es el escenario más común. Tienes una cuenta gratuita de TinyURL o ninguna cuenta, y tienes una colección de enlaces tinyurl.com/<slug> publicados a través de tu archivo de newsletter, publicaciones sociales, materiales impresos o documentación. No tienes acceso a la API ni mecanismo de exportación. Los enlaces existen; no tienes una lista de ellos.

La única forma de construir el inventario es buscar tus propias superficies publicadas.

Encontrando los enlaces#

Trabaja a través de cada superficie sistemáticamente:

• Archivo de email/newsletter: busca en el archivo de tu plataforma de email por tinyurl.com. La mayoría de plataformas te permiten buscar a través de campañas enviadas. Exporta las coincidencias.
• Redes sociales: busca en tus publicaciones de Twitter/X, LinkedIn y Facebook por enlaces tinyurl.com. La mayoría de plataformas tienen una exportación de contenido a nivel de cuenta. Descárgala y haz grep.
• Sitio web y documentación: ejecuta una búsqueda en el sitio o un crawl. grep -r "tinyurl.com" ./content en un repo de sitio estático lleva segundos.
• Enlaces de seguimiento de plataformas de anuncios: comprueba los enlaces etiquetados con UTM en Google Ads, Meta Ads Manager o donde sea que hayas ejecutado campañas pagadas.

Una vez que tengas la lista de valores tinyurl.com/<slug>, necesitas las URLs de destino. Si creaste los enlaces tú mismo y puedes recordar el destino, genial. Si no: sigue cada enlace manualmente o con un script que emita una petición HEAD y lea el encabezado Location. La redirección de TinyURL en sí es públicamente accesible - no necesitas una cuenta para resolver a dónde va un enlace 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

Esto te da el CSV slug,target_url que necesitas para importar. Nota que importarás con nuevos slugs en tu propio dominio - más sobre eso abajo.

Acepta lo que no puedes recuperar#

Para enlaces publicados en contextos a los que ya no tienes acceso - una cuenta social de un trabajo que dejaste, una publicación de comunidad en una plataforma que eliminaste - no hay camino de recuperación. Esos enlaces antiguos de tinyurl.com continuarán funcionando mientras TinyURL siga operativo, pero no tienes capacidad de actualizarlos, redirigirlos a través de Elido o observar quién hace clic en ellos. Acepta esto y sigue adelante. Migrar lo que puedes encontrar es la decisión correcta; la perfección no es alcanzable aquí.

Importando a Elido#

Independientemente del camino que generó tu CSV, la llamada de importación es la misma. La distinción clave es lo que pones en el campo slug.

Si tienes un dominio personalizado de marca: puedes intentar preservar slugs del Camino A. Registra tu dominio en Elido primero, luego pasa slug explícitamente en el cuerpo de importación masiva. La forma de la llamada:

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

El domain_id debe referirse a un dominio ya registrado y verificado en tu workspace. El endpoint acepta hasta 100 enlaces por llamada y devuelve éxito/fallo por elemento - un conflicto de slug en una fila no aborta el lote.

Si estabas en tinyurl.com/ sin dominio personalizado: omite el campo slug o pasa null. Elido generará un slug para cada enlace. Acepta el cambio de slug. Los enlaces antiguos de tinyurl.com no redirigen a tus nuevos enlaces de Elido - no hay cadena 301 que puedas instalar porque no posees tinyurl.com. La única forma de reconectar el tráfico es actualizar cada superficie publicada que contenga el enlace antiguo. Ese es el trabajo.

La limitación de la cadena 301 para enlaces sin marca#

Esto merece una declaración directa. La guía migrate-from-bitly-without-breaking-links cubre el patrón de puente 301 en detalle para migraciones de Bitly. Ese patrón asume que controlas el dominio originario. Para enlaces tinyurl.com, no lo haces.

No hay mecanismo que TinyURL exponga para instalar una redirección desde un tinyurl.com/<slug> existente a un nuevo destino. El enlace continúa resolviendo a donde fue apuntado cuando lo creaste. Si quieres que el tráfico que iba a tinyurl.com/abc123 aterrice en su lugar en tu nuevo enlace de Elido, tienes dos opciones:

1. Actualiza cada superficie publicada para usar el nuevo enlace de Elido. Este es el enfoque correcto.
2. Deja el enlace de TinyURL apuntando al destino y deja que Elido maneje solo enlaces futuros. Aceptable si los enlaces antiguos se usan con poca frecuencia y no son críticos para el negocio.

La opción 2 no es realmente "migración" - es coexistencia. Para la mayoría de equipos, la combinación de ambas tiene sentido: migra la creación de nuevos enlaces a Elido completamente, actualiza las superficies antiguas de mayor tráfico, y deja que la cola larga de enlaces antiguos de TinyURL con cero clics decaiga sin esfuerzo.

Validación#

Después de la importación, comprueba que lo que importa esté funcionando realmente.

Toma tu CSV ordenado y saca las 50 filas principales por volumen de clic (del Camino A) o por fecha de publicación y tamaño de audiencia (del Camino B, donde estás estimando importancia). Para cada uno de esos enlaces:

1. Si estabas en un dominio personalizado de marca y preservaste slugs: prueba que https://short.yourbrand.com/<slug> resuelva al destino correcto. El panel de Elido muestra estado 200 vs. error. Alternativamente, ejecuta una comprobación curl:

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

2. Si generaste nuevos slugs: verifica que las URLs de destino en el panel de Elido coincidan con tu CSV fuente. La respuesta de importación incluye éxito/fallo por elemento; revisa el log de fallos antes de cerrar la migración.

3. Comprueba tus envíos de newsletter recientes de alta apertura y publicaciones sociales recientes. Si contienen enlaces de TinyURL y los has actualizado a enlaces de Elido, verifica que los enlaces actualizados funcionen. Si no los has actualizado - anótalos explícitamente. Esos son los enlaces con mayor probabilidad de tener tráfico de clic activo que estás dejando fuera de tu analítica.

Para cualquier superficie que hayas actualizado, confirma que la actualización realmente alcanzó la versión publicada. Una newsletter reprogramada con enlaces antiguos, un tuit editado, un artículo de ayuda cacheado por un CDN - estos son los lugares donde la actualización no aterriza inmediatamente.

La nota del realista sobre los slugs que no puedes mantener#

La versión franca: si estabas en el plan gratuito de TinyURL y publicando enlaces tinyurl.com/<slug>, no estás migrando un espacio de slug. Estás migrando una lista de URLs de destino y empezando de nuevo en Elido con nuevos slugs en tu propio dominio. Los enlaces antiguos de tinyurl.com existen a perpetuidad en la infraestructura de TinyURL. No puedes actualizarlos, redirigirlos o extraer analítica de ellos después de dejar de usar la cuenta.

Esto no es un fallo del proceso de migración. Es la expectativa correcta. El plan gratuito de TinyURL nunca fue una plataforma de gestión de enlaces - fue una utilidad de acortamiento. Dejarlo significa aceptar que el trabajo que pusiste en él es en gran medida irrecuperable desde una perspectiva de portabilidad de slug.

Lo que ganas es lo que viene después: enlaces cortos de marca en un dominio que posees, analítica de clic que no se detiene en una ventana de 30 días, y un modelo de precios que escala sin sorprenderte. El trabajo de migración es un coste único. La herramienta mejorada es continua.

Si estás evaluando si Elido es el destino correcto antes de comprometerte al trabajo de migración, la comparación elido-vs-tinyurl cubre la brecha de funciones y cumplimiento en detalle.

Citaciones: Documentación de la API de desarrollador de TinyURL consultada el 2026-05-12. Página de precios de TinyURL consultada el 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.