De onde vem l.facebook.com e por que os cliques chegam como Direct

O que é l.facebook.com?

O Facebook reescreve os links de saída para que todo clique passe por l.facebook.com, o desvio intermediário que a Meta chama de link shim, antes de o navegador chegar à sua página. O blog de engenharia da Meta deu nome à ferramenta em 2012 e a descreveu como um jeito de "to warn people about potentially spammy or malicious links." O hostname é um serviço de redirecionamento e nada além disso. Peça o domínio puro e ele responde HTTP/2 302 com location: https://www.facebook.com/, verificado em 12 de setembro de 2026.

A Meta continua usando o recurso nas próprias propriedades. Todo link de saída no rodapé de developers.facebook.com passa pelo shim, o que permite ler o formato em uma página ao vivo em vez de em uma captura de tela.

Qual é a cara de uma URL de l.facebook.com?

Dois parâmetros de consulta carregam tudo. O destino fica codificado em porcentagem em u, e uma assinatura fica em h:

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

Como a URL de destino completa é codificada em porcentagem dentro de u, a query string dela sobrevive ao desvio. Qualquer utm_source ou utm_campaign que você colocar em um link continua anexado quando o navegador chega.

O parâmetro h não é um hash do destino. Buscar a mesma página da Meta duas vezes em 12 de setembro de 2026 produziu dois valores de h diferentes para o mesmo destino llama.com, o que significa que a assinatura está presa à sessão que renderizou o link, e não à URL. Copie um link com shim para fora do Facebook e cole em outro lugar e ele não resolve: tanto uma requisição l.php assinada quanto uma sem assinatura retornaram HTTP/2 400 com a página genérica "Sorry, something went wrong" do Facebook quando pedidas sem a sessão de origem.

A Meta mantém hostnames paralelos para as outras superfícies dela, e todos se comportam do mesmo jeito.

Por que o Facebook manda os cliques por um shim?

Por duas razões que a Meta declara abertamente, e só uma delas custa algo a você. A primeira é a triagem de malware. A segunda é a restrição deliberada do referrer.

O post da Meta de 2012 "A faster, better link shim" descreve a reformulação que segue em vigor. Em vez de checar um link depois do clique, "we now check every link on the page before it's sent to the browser," e "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." A Meta mediu a economia em "around a second every time they click an external link."

A metade do referrer é dita com a mesma clareza, sob um título chamado 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." Isso não é efeito colateral. É o objetivo do projeto.

O que o link shim faz com o seu referrer?

Ele entrega uma origem no lugar de uma URL. O post da Meta de 2012 diz que a empresa "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." A tag continua na página hoje. Buscar www.facebook.com em 12 de setembro de 2026 retorna isto no head:

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

Essa string tem um detalhe torto. A especificação Referrer Policy do W3C define exatamente nove tokens válidos, e origin-when-crossorigin não é um deles. O token escrito por extenso é origin-when-cross-origin, com um hífen entre cross e origin. A especificação também diz que "unknown policy values will be ignored," e que "the default referrer policy is strict-origin-when-cross-origin."

Os dois caminhos terminam no mesmo lugar para você. Se um navegador aceita a grafia antiga da Meta, as navegações entre origens mandam só a origem. Se um navegador a rejeita e cai no padrão, as navegações entre origens continuam mandando só a origem. De um jeito ou de outro, o cabeçalho Referer que chega ao seu servidor é uma origem pelada como https://l.facebook.com/, nunca o post, o grupo ou o perfil de onde o clique partiu.

O único caso em que você não recebe nada é um rebaixamento de protocolo. Sob strict-origin-when-cross-origin, uma navegação de uma página HTTPS para um destino HTTP "would send no Referer header." Um site que ainda serve HTTP puro perde a atribuição por inteiro.

Por que o tráfego de l.facebook.com chega como Direct na análise?

Porque o cabeçalho Referer não chegou, não porque o Google classifica o hostname errado. É aqui que a maior parte dos conselhos sobre o shim inverte a história.

O Google publica a lista de fontes que mapeia para canais, e l.facebook.com, lm.facebook.com, l.instagram.com e l.messenger.com aparecem todos nela como SOURCE_CATEGORY_SOCIAL. O canal Organic Social do GA4 bate quando a fonte "matches a regex list of social sites" ou a mídia é uma de social, social-network, social-media e similares. Ou seja, um clique que chega com a origem do shim já está classificado como Organic Social. Não há nada a consertar nem exclusão de referência a acrescentar.

O canal Direct tem uma definição bem mais estreita: a fonte bate exatamente com (direct) e a mídia é (not set) ou (none). Nada cai ali por classificação errada. Cai ali quando a tag de análise não tem referrer nem parâmetros de campanha com que trabalhar. Três situações produzem isso:

• Um rebaixamento de protocolo, em que a especificação diz que nenhum Referer é enviado.
• Uma passagem de um navegador dentro do app para o navegador do sistema, em que a nova navegação não é um clique em link e não carrega referrer próprio.
• Um link copiado e colado, que chega sem referrer por definição porque ninguém clicou em nada.

O formato geral desse balde, e o que mais cai nele, está coberto nesta explicação sobre tráfego direto.

Como parar de perder a atribuição?

Marque a URL antes de ela chegar ao editor, porque o shim preserva a query string que ele envolve. O destino é carregado codificado em porcentagem dentro de u, então utm_source=facebook&utm_medium=social&utm_campaign=spring-launch sobrevive ao redirecionamento e chega intacto à sua análise. Os parâmetros de campanha também valem mais que o referrer na correspondência de canais do GA4, o que significa que um link marcado é classificado igual apareça ou não o cabeçalho Referer. As convenções de nomenclatura que mantêm isso consistente entre redes estão trabalhadas neste guia de parâmetros UTM.

Envolver links não é uma esquisitice do Facebook. O X faz o mesmo com o encurtador dele, reescrevendo toda URL publicada em um link t.co, com efeitos próprios sobre o que o seu servidor enxerga. O lado crawler da Meta tem a mesma personalidade dividida: o card de prévia é montado por uma busca separada do crawler facebookexternalhit muito antes de qualquer humano clicar no shim.

Vale manter dois conjuntos de números separados. Impressões, alcance e cliques registrados do lado do Facebook vêm das APIs da própria Meta, que é o que uma ferramenta como o adaptlypost mostra em análise de redes sociais. A sessão que chega ao seu site é outro registro, mantido pela sua própria análise, e o link shim fica na lacuna entre os dois. Marcar a URL é o que fecha essa lacuna.

Perguntas frequentes

Devo adicionar l.facebook.com à minha lista de exclusão de referência?

Não. A lista de fontes publicada pelo Google já mapeia l.facebook.com para SOURCE_CATEGORY_SOCIAL, então o GA4 reporta essas sessões como Organic Social em vez de referência genérica. Excluir o hostname remove o referrer e empurra essas sessões para Direct, que é justamente o resultado que a maioria tenta evitar.

Dá para ver de qual post do Facebook veio um clique?

Pelo referrer, não. O objetivo de projeto declarado pela Meta é "prevent them from reading the full source url," e o cabeçalho que chega ao seu servidor é uma origem como https://l.facebook.com/ sem caminho. Um valor de utm_content único por post é a única forma de diferenciar dois posts.

Por que um link de l.facebook.com colado não funciona?

Porque o parâmetro h é uma assinatura presa à sessão que gerou o link, não ao destino. Pedir l.php fora dessa sessão retornou HTTP/2 400 e a página de erro genérica do Facebook tanto em um teste assinado quanto em um sem assinatura, em 12 de setembro de 2026.

Qual é a diferença entre l.facebook.com e lm.facebook.com?

A superfície que gerou o clique. lm.facebook.com é a contraparte de web mobile, e o hostname puro redireciona para https://m.facebook.com/?_rdr, enquanto l.facebook.com redireciona para https://www.facebook.com/. O Google classifica os dois como fontes sociais.

O link shim apaga os meus parâmetros UTM?

Não. A URL de destino é codificada em porcentagem por inteiro no parâmetro u, query string incluída, então as tags de campanha chegam junto com o visitante. Os parâmetros somem quando um link é redigitado ou encurtado na mão antes da publicação, não no shim.

Todo link do Facebook passa pelo shim?

A descrição da Meta de 2012 diz que os links são triados antes de a página ir para o navegador, e que links suspeitos ganham uma página intersticial de aviso enquanto o resto segue direto para o link. A Meta não publica regra alguma sobre quais links são reescritos para l.php e quais não são, então trate o desvio como presente por padrão e marque os links de acordo.

Por que o Facebook manda um clique por l.facebook.com em vez de linkar direto para a minha página?

A Meta dá dois motivos para esse desvio: checar os links contra malware antes mesmo de o clique chegar ao navegador, e limitar quanto da URL de origem sai do Facebook. A checagem de malware acontece na própria página, antes de qualquer clique. A restrição de referrer é igualmente proposital e aparece sob o próprio título da Meta, Restricting the Referrer.

A checagem de malware no link shim deixa os cliques mais lentos?

A Meta relata o contrário. A reformulação de 2012, que checa os links antes de chegarem ao navegador, economizou cerca de um segundo em cada clique externo frente ao sistema antigo, que checava depois do clique. Links suspeitos ainda recebem a página de aviso intermediária, e todo o resto segue direto para o destino.

Por que duas pessoas recebem valores de h diferentes para o mesmo link com shim?

O parâmetro h não é um hash da URL de destino, é uma assinatura presa à sessão do navegador que gerou o link. Buscar a mesma página da Meta duas vezes em 12 de setembro de 2026 gerou dois valores de h diferentes para o mesmo destino llama.com, o que mostra que o valor depende da sessão, não do link. Um link copiado falha fora dessa sessão mesmo quando o valor de h está recente.

Como ver o destino real de um link l.facebook.com antes de clicar?

O destino fica codificado em percentual dentro do parâmetro u da URL, junto com o resto da query string, incluindo utm_source ou utm_campaign. Decodificar esse parâmetro mostra a página exata para onde o link aponta sem precisar passar pelo shim. O parâmetro h ao lado é só uma assinatura de sessão e não diz nada sobre o destino.