¿Qué es un Deep Link?

El término deep link nació en el mundo web y designa un enlace que apunta a una página interna concreta de un sitio, como la ficha de un producto, en vez de dirigir a la portada. Es el uso original de la palabra y sigue vigente cuando se habla de estructura de enlazado.

Con la llegada de las apps móviles, el término ganó un segundo significado, hoy el más habitual: un deep link de app es un enlace especial que abre directamente una pantalla o un contenido concreto dentro de una aplicación, en lugar de limitarse a lanzarla en su pantalla de inicio. Un enlace a un producto en la app de una tienda que abre justo esa ficha, no el catálogo general, es un ejemplo típico.

En ambos casos la idea de fondo es la misma: saltarse el punto de entrada genérico y llevar al usuario directamente a lo que buscaba. En el sitio web, esa profundidad de navegación suele quedar reflejada en el breadcrumb de la página; en búsqueda orgánica, es habitual que Google enlace directamente a esa página interna en vez de a la home.

En el fondo, un deferred deep link resuelve un problema de coordinación entre instalar la app y llegar al contenido correcto: sin la app instalada, ningún enlace puede abrirla, así que el sistema pasa primero por la tienda y solo después recupera el destino original. Muchas campañas envuelven este proceso con un acortador de URL propio, que además sirve para medir de dónde viene cada instalación.

Un deep link de app necesita un método para que el sistema operativo sepa qué aplicación debe abrir. El más antiguo son los custom URI schemes, direcciones con un prefijo propio como miapp://producto/123, que el sistema asocia a la app durante la instalación. Funcionan, pero tienen un problema: si dos apps distintas registran el mismo esquema, no hay forma fiable de saber cuál debe abrirse, y si la app no está instalada, el enlace simplemente falla sin avisar.

Los estándares actuales resuelven eso con enlaces HTTPS normales en vez de esquemas propios. En iOS se llaman Universal Links, en Android App Links, y ambos funcionan igual: la app publica un archivo de verificación en su dominio, apple-app-site-association o assetlinks.json, que demuestra al sistema operativo que el propietario del dominio y el de la app son la misma entidad. Con esa verificación, el mismo enlace abre la app si está instalada y cae de forma natural en el navegador si no lo está.

El caso del deferred deep link añade una pieza más: como la app todavía no existe en el dispositivo, ningún esquema ni verificación puede actuar. La solución habitual pasa por un SDK de atribución de terceros, que guarda a qué contenido quería llegar el usuario durante todo el trayecto de la customer journey, desde el clic en el anuncio hasta el primer arranque de la app ya instalada, y entonces abre esa pantalla en lugar de la de bienvenida genérica.

En el sitio web, una estructura de enlazado interno que lleve con claridad a las páginas profundas facilita que un crawler las encuentre y las indexe, en lugar de rastrear solo la portada y las categorías principales. Es una de las razones por las que el SEO técnico sigue prestando atención a algo tan antiguo como un enlace bien apuntado.

En el mundo de las apps, la importancia es sobre todo de conversión y de medición. Una campaña que lleva directo a la ficha de un producto en la app, en vez de abrir solo la pantalla de inicio, reduce los pasos entre el clic y la compra, y eso se nota en la tasa de conversión de la campaña. El deferred deep link, además, es lo que permite medir con precisión qué anuncio generó cada instalación, algo imposible de saber si el enlace solo abriera la app de forma genérica.

Google, por su parte, puede rastrear e indexar contenido de apps a través de deep links correctamente configurados, mostrándolo en resultados de búsqueda móviles cuando el usuario ya tiene la app instalada.

• Usa siempre Universal Links o App Links en vez de custom URI schemes para los enlaces nuevos: son más seguros y no dependen de que ninguna otra app registre el mismo prefijo.
• Verifica el archivo apple-app-site-association o assetlinks.json después de cada cambio de dominio o de certificado; un fallo ahí rompe la verificación sin ningún aviso visible.
• Define un comportamiento de repliegue claro (fallback) para cuando el usuario abre el enlace sin la app instalada, en vez de dejar que falle en silencio.
• Prueba cada deep link en los dos escenarios reales: con la app instalada y sin ella, no solo desde el navegador de escritorio.
• Si usas un SDK de atribución para deferred deep links, revisa qué datos envía a terceros antes de integrarlo, no solo si funciona.
• En el sitio web, enlaza internamente hacia las páginas profundas con texto ancla descriptivo, no solo desde el menú principal.

• No configurar una página de error clara cuando el deep link apunta a un contenido que ya no existe: el usuario se encuentra con un status code 400 o una pantalla en blanco sin explicación.
• Seguir usando solo custom URI schemes en 2026, cuando Universal Links y App Links ya son el estándar recomendado por Apple y Google.
• Olvidar volver a subir el archivo de verificación tras migrar de dominio o de hosting, lo que rompe todos los deep links de golpe.
• Confundir un deep link roto con un problema de la app: casi siempre el fallo está en la verificación del dominio o en el propio enlace, no en el código de la pantalla de destino.
• No medir por separado las instalaciones que vienen de un deferred deep link, perdiendo así qué campaña las generó de verdad.