Navegação agêntica: quando o portfólio precisa ser legível para a IA
Publicado em
Rodei o Lighthouse no meu portfólio e encontrei uma categoria nova com nota crítica: navegação agêntica. O que ela avalia, o que faltava no meu site e por que isso muda o design.
Tenho o hábito de rodar o Lighthouse nos meus projetos de tempos em tempos. É a ferramenta do Google que dá notas de performance, acessibilidade, boas práticas e SEO. Da última vez, no meu próprio portfólio, apareceu uma categoria que eu nunca tinha visto: Navegação agêntica.
A nota era 29 no celular e 66 no computador. Um item novo, vermelho, justo no site que apresenta o meu trabalho. Fui entender o que era.
O que é navegação agêntica
"Agente" é o nome que se dá às IAs que não só respondem perguntas, mas agem: abrem sites, leem páginas, comparam informações, preenchem formulários e resumem o que encontraram para alguém. Pense num recrutador que pede a um assistente "analise o portfólio desta pessoa e me diga com que tipo de produto ela já trabalhou". Quem visita o site, nesse caso, é o agente.
A diferença importante para quem faz design: um agente não vê a interface como nós. Ele não interpreta um ícone de três tracinhos como menu, nem entende que um texto grande e em negrito é o título da página. Ele lê a estrutura: os nomes dos elementos, a hierarquia do conteúdo, o que é link e o que é botão, o que é imagem decorativa e o que é informação.
É a mesma camada que tecnologias assistivas, como os leitores de tela, usam há anos. A acessibilidade que muitas vezes tratamos como item de checklist passa a ser a porta de entrada do seu produto para uma nova categoria de visitantes.
Como a nota é formada
Hoje, o Lighthouse considera três critérios, com o mesmo peso, na navegação agêntica:
A estrutura da página faz sentido para uma máquina? Todo botão tem nome, todo controle diz o que faz?
Existe um llms.txt? É um arquivo simples, em texto, que funciona como uma apresentação do site para modelos de linguagem: quem é, do que se trata e quais são as páginas principais.
O layout é estável durante o carregamento? Elementos que "pulam" de lugar atrapalham tanto a pessoa quanto o agente que tenta clicar em algo.
O próprio Google avisa que a categoria ainda está em desenvolvimento.
Mesmo assim, os três critérios apontam para fundamentos que já valem hoje.
O que encontrei no meu portfólio
Um botão sem nome
No celular, o menu abre por um botão com ícone de hambúrguer. Visualmente, zero dúvida. Na estrutura da página, porém, era um botão sem nome nenhum, uma caixa muda.
É um caso clássico de affordance visual sem affordance semântica. Desenhamos o ícone, o estado de hover, o estado aberto, e esquecemos de dizer, em texto, o que aquele controle faz. No desktop o problema não aparecia porque o menu completo fica visível, e isso explica a diferença de nota entre as versões.
Revisando o resto do site com esse olhar, encontrei outros casos parecidos:
Links que se comportavam como botões. O "Ver projeto" abria o site do case, mas estava construído como um botão. Para um agente, não havia destino a seguir.
A troca de idioma era uma ação, e não um caminho. A versão em inglês existia, mas não era "descobrível".
O carrossel de logos de clientes repetia a lista para criar o efeito de rolagem infinita. Para quem lê a estrutura, eram 14 clientes em vez de 7.
Imagens clicáveis sem indicação de que eram clicáveis nem do que acontecia ao clicar.
Um cartão de visita que não existia
Eu não tinha llms.txt. E havia um detalhe curioso: ao acessar o endereço onde o arquivo deveria estar, o site devolvia a própria página inicial. Para o teste, era como pedir um documento e receber um folder de outra coisa.
Gosto de pensar no llms.txt como um briefing do site para a IA: um resumo de quem sou e do que faço, a lista de projetos com cliente, ano e habilidades, as páginas institucionais e os artigos. É conteúdo, não código, e escrevê-lo bem é um exercício de arquitetura de informação.
Um layout que pulava
A home mostrava um skeleton enquanto carregava os textos. A intenção era boa, mas as proporções do skeleton não batiam com o conteúdo real: quando o texto chegava, os botões desciam. Os logos do carrossel também não tinham espaço reservado e empurravam o conteúdo ao aparecer.
É um lembrete de que skeleton é design. Ele precisa ter a forma do que vai substituir, senão vira fonte de instabilidade.
O problema que o relatório não mostrava
Corrigidos os três pontos, fiz uma pergunta que o Lighthouse não responde: o que um robô que não executa JavaScript enxerga no meu site?
Meu portfólio é uma aplicação React, construída com ajuda do Lovable. Nesse tipo de site, o conteúdo é "montado" no navegador depois que a página abre. Para uma pessoa, tudo aparece normalmente. Muitos robôs de IA e de redes sociais, porém, só leem a página no estado em que ela chega do servidor, sem montar nada.
O que eles recebiam era uma página vazia, com o título "Projeto Web Base" e a imagem de compartilhamento do template original. Nenhum projeto, nenhum cliente, nenhum contato. Era como ter uma vitrine bem montada, mas com a porta de serviço dando para uma sala sem nada.
Isso afetava inclusive o preview dos links compartilhados no LinkedIn e no WhatsApp, justamente onde um portfólio mais circula.
O que mudou
Com a ajuda de uma IA de código para a implementação, fizemos as mudanças sem alterar o visual do site e sem quebrar meu fluxo de edição no Lovable:
Na interface
Todo botão que é só ícone ganhou um nome descritivo ("Abrir menu", "Fechar", "Próxima imagem").
O que leva a outro lugar virou link de verdade; o que executa uma ação continuou botão.
A troca de idioma virou um caminho real para a versão em inglês.
A repetição do carrossel de logos ficou invisível para quem lê a estrutura.
A home passou a exibir o conteúdo desde o primeiro instante, sem o skeleton desproporcional, e as imagens ganharam espaço reservado.
Os selos coloridos de categoria, que usavam cores claras demais para leitura, passaram a ajustar o tom do texto automaticamente para atingir o contraste mínimo recomendado, sem perder a cor de cada categoria.
Na camada que a IA lê
O site ganhou um llms.txt gerado automaticamente a partir do conteúdo, sempre atualizado quando publico um projeto ou artigo.
Robôs e agentes passaram a receber cada página já pronta, com o mesmo conteúdo que as pessoas veem: textos, projetos, clientes, anos e habilidades.
Cada página ganhou título e descrição próprios, que também aparecem nos previews de compartilhamento.
Entraram dados estruturados: uma espécie de ficha técnica invisível que diz explicitamente "esta é a página de perfil de Angelo Rosa, Product Designer" ou "este é um case de design".
Um mapa do site, as versões em português e inglês sinalizadas entre si e uma página de "não encontrado" que informa o erro corretamente.
No peso das páginas
Nesse processo, descobri que as capas dos cases eram imagens de mais de 1 MB exibidas em cards de 400 pixels. Com a otimização automática, cada capa caiu de até 1,3 MB para cerca de 16 KB, sem perda visível. Uma página leve é boa para quem acessa pelo celular e também para um agente com tempo limitado para ler o site.
O resultado
Navegação agêntica: de 29 (celular) e 66 (computador) para 100 nas páginas testadas.
Acessibilidade: de 90 para 100 na home mobile.
Robôs sem JavaScript: passaram de uma página vazia para o portfólio completo.
Mais do que as notas, o site passou a comunicar a mesma coisa para os dois públicos: pessoas e agentes.
O que isso muda no nosso trabalho
Saio desse processo com algumas convicções que valem para qualquer produto digital, não só para portfólios.
Projetamos para dois públicos. A interface visual continua sendo para pessoas. Mas existe uma segunda interface, a estrutural, que sempre existiu para tecnologias assistivas e agora é lida também por agentes. Ela merece o mesmo cuidado.
Nome acessível é parte do componente. No design system, um botão só de ícone deveria vir com o campo "rótulo" especificado, do mesmo jeito que especificamos tamanho e estado. Se o handoff não diz o nome do botão, alguém vai deixá-lo em branco.
Link e botão não são a mesma coisa. Visualmente podem ser idênticos, mas semanticamente um leva a um lugar e o outro executa uma ação. Essa distinção precisa estar clara no design, não só no código.
Estados de carregamento precisam de proporção. Skeleton, placeholder e espaço reservado para imagem são decisões de design que afetam a estabilidade da tela.
Metadado também é UX writing. O título da página, a descrição que aparece no compartilhamento e o resumo no llms.txt são conteúdo, e são muitas vezes o primeiro contato de alguém, ou de algo, com o seu trabalho.
Ferramentas de IA para construir exigem revisão de fundamentos. Criar um site com IA é rápido e poderoso, mas o resultado herda escolhas de template: o título padrão, o componente sem rótulo, a página que só existe depois do JavaScript. Vale revisar com o mesmo rigor que aplicamos a qualquer entrega.
A navegação agêntica ainda está em evolução, mas o recado já está dado: nossos produtos agora também são lidos por agentes. E, curiosamente, a melhor forma de se preparar para isso é voltar ao básico que a acessibilidade sempre defendeu.