De dónde sale l.facebook.com y por qué los clics llegan como Direct

¿Qué es l.facebook.com?

Facebook reescribe los enlaces salientes para que cada clic pase por l.facebook.com, el salto intermedio que Meta llama link shim, antes de que el navegador llegue a tu página. El blog de ingeniería de Meta nombró la herramienta en 2012 y la describió como una forma de "to warn people about potentially spammy or malicious links." El hostname es un servicio de redirección y nada más. Pide el dominio a secas y responde HTTP/2 302 con location: https://www.facebook.com/, comprobado el 12 de septiembre de 2026.

Meta lo sigue usando en sus propias propiedades. Todos los enlaces salientes del pie de developers.facebook.com pasan por el shim, y eso permite leer el formato en una página en vivo en lugar de en una captura.

¿Qué aspecto tiene una URL de l.facebook.com?

Dos parámetros de consulta lo llevan todo. El destino va codificado en porcentaje dentro de u, y una firma va en h:

https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.llama.com%2F&h=AUCy45wK_2QEcW5a...

Como la URL de destino completa va codificada en porcentaje dentro de u, su propia cadena de consulta sobrevive al salto. Cualquier utm_source o utm_campaign que pongas en un enlace sigue ahí cuando el navegador aterriza.

El parámetro h no es un hash del destino. Pedir la misma página de Meta dos veces el 12 de septiembre de 2026 produjo dos valores de h distintos para el mismo destino llama.com, lo que significa que la firma está atada a la sesión que renderizó el enlace y no a la URL. Copia un enlace con shim fuera de Facebook y pégalo en otro sitio y no resuelve: tanto una petición l.php firmada como una sin firmar devolvieron HTTP/2 400 con la página genérica "Sorry, something went wrong" de Facebook cuando se pidieron sin la sesión de origen.

Meta mantiene hostnames paralelos para sus otras superficies, y todos se comportan igual.

¿Por qué Facebook enruta los clics por un shim?

Por dos razones que Meta declara sin rodeos, y solo una te cuesta algo. La primera es el filtrado de malware. La segunda es la restricción deliberada del referrer.

La entrada de 2012 de Meta "A faster, better link shim" describe el rediseño que sigue vigente. En lugar de revisar un enlace después del clic, "we now check every link on the page before it's sent to the browser," y "if we find a link to be suspicious, we use the old interstitial warning page; otherwise we allow the user through to the link itself." Meta midió el ahorro en "around a second every time they click an external link."

La mitad del referrer se declara con la misma claridad, bajo un apartado llamado Restricting the Referrer: "We still need to let the websites you navigate to know the traffic is from Facebook, but we also want to prevent them from reading the full source url. Otherwise, they could know where on the site you were when you clicked their link." Eso no es un efecto secundario. Es el objetivo de diseño.

¿Qué le hace el link shim a tu referrer?

Te entrega un origen en lugar de una URL. La entrada de 2012 de Meta dice que ha "taken advantage of a new feature called the meta referrer," que "allows us to specify how much of the source url to share with the external site via the Referer header." La etiqueta sigue hoy en la página. Pedir www.facebook.com el 12 de septiembre de 2026 devuelve esto en el head:

<meta name="referrer" content="origin-when-crossorigin" id="meta_referrer">

Esa cadena tiene una arruga. La especificación Referrer Policy del W3C define exactamente nueve tokens válidos, y origin-when-crossorigin no es uno de ellos. El token escrito entero es origin-when-cross-origin, con un guion entre cross y origin. La especificación también dice que "unknown policy values will be ignored," y que "the default referrer policy is strict-origin-when-cross-origin."

Los dos caminos acaban en el mismo sitio para ti. Si un navegador acepta la grafía heredada de Meta, las navegaciones entre orígenes envían solo el origen. Si un navegador la rechaza y recurre al valor por defecto, las navegaciones entre orígenes siguen enviando solo el origen. En cualquier caso, la cabecera Referer que llega a tu servidor es un origen pelado como https://l.facebook.com/, nunca la publicación, el grupo o el perfil donde empezó el clic.

El único caso en el que no recibes nada es una degradación de protocolo. Bajo strict-origin-when-cross-origin, una navegación de una página HTTPS a un destino HTTP "would send no Referer header." Un sitio que aún sirve HTTP plano pierde la atribución por completo.

¿Por qué el tráfico de l.facebook.com llega como Direct en analítica?

Porque la cabecera Referer no llegó, no porque Google etiquete mal el hostname. Aquí es donde la mayoría de los consejos sobre el shim lo cuentan al revés.

Google publica la lista de fuentes que asigna a canales, y l.facebook.com, lm.facebook.com, l.instagram.com y l.messenger.com aparecen todos en ella como SOURCE_CATEGORY_SOCIAL. El canal Organic Social de GA4 coincide cuando la fuente "matches a regex list of social sites" o el medio es uno de social, social-network, social-media y similares. Así que un clic que llega con el origen del shim ya está clasificado como Organic Social. No hay nada que arreglar ni exclusión de referencia que añadir.

El canal Direct tiene una definición mucho más estrecha: la fuente coincide exactamente con (direct) y el medio es (not set) o (none). Ahí no aterriza nada por mala clasificación. Aterriza cuando la etiqueta de analítica no tiene referrer ni parámetros de campaña con los que trabajar. Tres situaciones lo producen:

• Una degradación de protocolo, donde la especificación dice que no se envía ningún Referer.
• Un traspaso de un navegador dentro de la app al navegador del sistema, donde la nueva navegación no es un clic en un enlace y no lleva referrer propio.
• Un enlace copiado y pegado, que llega sin referrer por definición porque nadie hizo clic en nada.

La forma general de este cajón, y qué más cae dentro, la cubre esta explicación sobre el tráfico directo.

¿Cómo dejas de perder la atribución?

Etiqueta la URL antes de que llegue al compositor, porque el shim conserva la cadena de consulta que envuelve. El destino viaja codificado en porcentaje dentro de u, así que utm_source=facebook&utm_medium=social&utm_campaign=spring-launch sobrevive a la redirección y llega intacto a tu analítica. Los parámetros de campaña además pesan más que el referrer en la asignación de canales de GA4, lo que significa que un enlace etiquetado se clasifica igual aparezca o no la cabecera Referer. Las convenciones de nombres que mantienen esto coherente entre redes se trabajan en esta guía de parámetros UTM.

El envoltorio de enlaces no es una rareza de Facebook. X hace lo mismo con su propio acortador y reescribe cada URL publicada en un enlace t.co, con sus propios efectos sobre lo que ve tu servidor. El lado del rastreador de Meta tiene la misma doble personalidad: la tarjeta de vista previa la construye una petición aparte del rastreador facebookexternalhit mucho antes de que alguien pulse el shim.

Conviene mantener separados dos conjuntos de números. Las impresiones, el alcance y los clics registrados del lado de Facebook vienen de las propias APIs de Meta, que es lo que una herramienta como adaptlypost muestra en analítica de redes sociales. La sesión que aterriza en tu sitio es otro registro distinto que lleva tu propia analítica, y el link shim se sienta en el hueco entre ambos. Etiquetar la URL es lo que lo cierra.

Preguntas frecuentes

¿Debo añadir l.facebook.com a mi lista de exclusión de referencias?

No. La lista de fuentes publicada por Google ya asigna l.facebook.com a SOURCE_CATEGORY_SOCIAL, así que GA4 informa esas sesiones como Organic Social y no como una referencia genérica. Excluir el hostname elimina el referrer y empuja esas sesiones a Direct, que es justo el resultado que casi todo el mundo intenta evitar.

¿Puedo ver de qué publicación de Facebook vino un clic?

Del referrer no. El objetivo de diseño que Meta declara es "prevent them from reading the full source url," y la cabecera que llega a tu servidor es un origen como https://l.facebook.com/ sin ruta. Un valor de utm_content único por publicación es la única forma de distinguir dos publicaciones.

¿Por qué no funciona un enlace de l.facebook.com pegado?

Porque el parámetro h es una firma atada a la sesión que generó el enlace, no al destino. Pedir l.php fuera de esa sesión devolvió HTTP/2 400 y la página de error genérica de Facebook tanto en una prueba firmada como en una sin firmar el 12 de septiembre de 2026.

¿Cuál es la diferencia entre l.facebook.com y lm.facebook.com?

La superficie que generó el clic. lm.facebook.com es la contraparte de web móvil, y el hostname a secas redirige a https://m.facebook.com/?_rdr mientras que l.facebook.com redirige a https://www.facebook.com/. Google clasifica ambos como fuentes sociales.

¿El link shim borra mis parámetros UTM?

No. La URL de destino se codifica en porcentaje entera dentro del parámetro u, cadena de consulta incluida, así que las etiquetas de campaña llegan con el visitante. Los parámetros se pierden cuando un enlace se reescribe a mano o se acorta antes de publicarlo, no en el shim.

¿Todos los enlaces de Facebook pasan por el shim?

La descripción de Meta de 2012 dice que los enlaces se revisan antes de enviar la página al navegador, y que los sospechosos reciben una página intersticial de aviso mientras el resto pasa directo al enlace. Meta no publica ninguna regla sobre qué enlaces se reescriben a l.php y cuáles no, así que da el salto por presente por defecto y etiqueta en consecuencia.

¿Por qué Facebook enruta un clic por l.facebook.com en lugar de enlazar directo a mi página?

Meta da dos razones para el salto: revisar los enlaces en busca de malware antes de que el clic llegue siquiera al navegador, y limitar cuánto de la URL de origen sale de Facebook. La revisión de malware ocurre en la propia página, antes de cualquier clic. La restricción del referrer es igual de deliberada y aparece bajo el propio encabezado de Meta, Restricting the Referrer.

¿La revisión de malware en el link shim hace más lentos los clics?

Meta reporta lo contrario. El rediseño de 2012, que revisa los enlaces antes de que lleguen al navegador, ahorró cerca de un segundo por cada clic externo frente al sistema anterior, que revisaba después del clic. Los enlaces sospechosos siguen recibiendo la página de advertencia intermedia, y todo lo demás pasa directo al destino.

¿Por qué dos personas obtienen valores h distintos para el mismo enlace con shim?

El parámetro h no es un hash de la URL de destino, es una firma ligada a la sesión del navegador que generó el enlace. Pedir la misma página de Meta dos veces el 12 de septiembre de 2026 produjo dos valores h distintos para el mismo destino llama.com, lo que muestra que el valor depende de la sesión y no del enlace. Un enlace copiado falla fuera de esa sesión incluso cuando su valor h es reciente.

¿Cómo veo el destino real de un enlace de l.facebook.com antes de hacer clic?

El destino está codificado en porcentaje dentro del parámetro u de la URL, junto con el resto de la cadena de consulta, incluidos utm_source o utm_campaign. Decodificar ese parámetro muestra la página exacta a la que apunta el enlace sin pasar por el shim. El parámetro h que va al lado es solo una firma de sesión y no dice nada del destino.