Como fazer com que os agentes de IA encontrem o seu catálogo

Cada vez mais gente começa a sua compra a perguntar a um assistente em vez de escrever num motor de pesquisa. «Onde compro uma frigideira de ferro de 28 cm que não seja caríssima?». O assistente responde, e nessa resposta saem umas lojas e não saem outras.

Este artigo é sobre o que é preciso para estar entre as que saem. E começa com um aviso que quase ninguém põe: isto está por medir.

Primeiro, a honestidade

Não há números fiáveis sobre quanta venda vem hoje de assistentes de IA. Os que circulam saem quase sempre de empresas que vendem alguma coisa relacionada, sem metodologia publicada. Nós também não os temos.

O que se pode afirmar sem inventar nada é mais modesto e mais útil: as três camadas que fazem falta para que um agente possa usar o seu catálogo são as mesmas que o SEO clássico pede há anos, e quase nenhuma loja as tem bem. Portanto o trabalho paga-se mesmo que a promessa dos agentes demore.

Com isto à frente, vamos lá.

Camada 1: que o consigam ler

Parece o básico e é onde falha mais gente.

Veja o seu robots.txt. Muitas lojas bloquearam na altura os robôs de IA, às vezes por decisão e às vezes porque vinha num modelo. É uma decisão legítima, mas convém que seja uma decisão: se os bloquear, não vai sair, e pronto. Os robôs dos assistentes identificam-se com nome próprio e podem ser permitidos ou negados um a um.

Confirme que o seu conteúdo está no HTML. Se o preço, o stock ou a descrição só aparecem depois de correr o JavaScript, há agentes que não os vão ver. O teste são dez segundos: abra uma ficha de produto, veja o código-fonte e procure o preço. Se não estiver lá, tem um problema que também tem com o Google.

E veja se a sua protecção anti-robôs não está demasiado entusiasta. É fácil acabar a bloquear tudo o que não pareça um navegador, e aí caem coisas que queria deixar passar.

Camada 2: que o entendam

Que o leiam não chega: é preciso dizer-lhes o que vende num formato que não se tenha de adivinhar.

Dados estruturados de produto. É o que de facto se usa hoje, e é o mesmo que o Google pede há anos: nome, preço, moeda, disponibilidade, código de produto, marca. Se a sua plataforma já os emite, confirme de vez em quando: partem-se com as mudanças de modelo e ninguém dá por isso.

Os dois campos que mais se esquecem são os que aqui mais valem: a disponibilidade, porque um agente que recomenda algo esgotado deixa de recomendar aquela loja, e o código de produto, porque é o que permite saber que a sua frigideira e a de outra loja são a mesma frigideira.

Um ficheiro llms.txt. É um ficheiro de texto na raiz do seu domínio que resume o que é e a que páginas ir. É uma convenção recente e a sua adopção real não está demonstrada: dizemo-lo claramente. Dito isto, custa uma tarde e não parte nada, por isso a relação entre o que custa e o que pode dar é boa. Nós publicamos o nosso em findalo.io/llms.txt, caso queira copiar a estrutura.

O que o de uma loja deve levar: o que vende e a quem, como está organizado o catálogo, onde estão as condições de envio e devolução, e a que páginas ir para cada coisa. Sem marketing. Um ficheiro com adjectivos é um ficheiro inútil.

Camada 3: que possam responder com os seus dados

Aqui é onde está a acontecer o interessante e onde quase ninguém fez nada.

Um agente que ajuda a comprar precisa de coisas concretas: saber se há stock agora, que tamanhos restam, quanto custa o envio para um sítio. Isso não está numa página de marketing; está na sua loja, e é preciso poder perguntar-lho.

As três peças que já pode preparar hoje:

• Um feed de produto correcto e actualizado. O mesmo que usa para os comparadores. Se já o tem bem, tem metade.
• Páginas de condições que se possam ler. Envios, prazos, devoluções, garantia. Em texto, não numa imagem nem num PDF. São as perguntas que mais recebe qualquer assistente de compra.
• Uma pesquisa interna que funcione. Soa interesseiro e não é: quando um agente chega à sua loja e quer encontrar algo concreto, usa a sua pesquisa. Se a sua pesquisa não encontra, o agente conclui que não o tem.

O que fazemos nós com isto

Duas coisas, e nenhuma é magia.

A primeira, no nosso próprio site: publicamos llms.txt e uma versão longa com os factos concentrados num só ficheiro, para que um modelo que nos cite o faça com dados correctos e não com o que deduziu de uma página de preços.

A segunda, no produto: a pesquisa pode configurar-se a partir de um agente. Sinónimos, regras, relevância, desenho. O agente propõe alterações e uma pessoa aprova-as no painel, ou aplica-as ele próprio se o comerciante o tiver activado, sempre com volta atrás. A lógica é a mesma deste artigo: se a sua equipa vai trabalhar com assistentes, as ferramentas têm de se deixar manobrar por eles.

Como medir se alguma coisa disto serve

Sem medição, tudo o anterior é fé. Duas coisas que pode ver desde já:

• Visitas que chegam de assistentes. Aparecem na sua análise como referência dos domínios deles. Hoje costuma ser pouco; o que importa é a tendência, não o número deste mês.
• Pergunte-lhes o senhor. Pegue em dois ou três assistentes e faça-lhes a pergunta que faria um cliente seu. Sai? Sai a sua concorrência? O que dizem de si está correcto? É um método rudimentar e é muitíssimo melhor do que nada.

Se o descreverem mal, quase sempre é a camada 2: há alguma coisa no seu site a dizer algo que já não é verdade.

Por onde começar

Se só for fazer uma coisa este mês, que seja confirmar que o preço e a disponibilidade estão no HTML das suas fichas e nos dados estruturados. Isso serve-lhe para o Google, para os comparadores, para os agentes e para a sua própria pesquisa.

Se for fazer duas, escreva o llms.txt.

E se lhe sobrar uma tarde, arranje a sua pesquisa interna: é a que vai usar tudo o que chegar, humano ou não. Temos quinze verificações para saber em que estado está.