MCP com Chrome: Automação com IA · Capítulo 12 de 16 · 31 min
Descobrir o que a IA não vê na página que você vê
Os principais rastreadores de IA não executam JavaScript, então parte do que você vê na tela nem chega até eles.
Este capítulo faz parte do curso gratuito MCP com Chrome: Automação com IA.
O que é: Toda página tem duas versões: o HTML que o servidor entrega antes de qualquer script, e o que aparece na tela depois de o JavaScript rodar. Os robôs que alimentam os assistentes de IA leem só a primeira. Por que importa: Se o que vende (preço, proposta de valor, prova social) só nasce depois do script, o motor de resposta recebe uma página quase vazia e não cita a sua marca, por mais conteúdo que você publique. É invisibilidade estrutural, anterior a qualquer discussão sobre o texto. A sua decisão: Se a entrega no servidor entra na fila antes de gastar em mais conteúdo, ou se o time segue escrevendo para robôs que não enxergam o texto. O que delegar: A comparação entre as duas versões, página por página, e a fila de migração. O passo a passo para operar vem logo abaixo.
Glossário rápido
HTML bruto vs. DOM
HTML bruto é o documento que o servidor devolve na resposta, antes de qualquer script; o DOM é a página já montada no navegador depois de o JavaScript rodar. É a diferença entre a planta que chega pelo correio e a casa construída: quem não executa o script fica só com a planta.
Renderização no servidor (SSR)
Montar o conteúdo no servidor e entregá-lo pronto dentro do HTML, em vez de deixar o navegador construí-lo com JavaScript. Garante que preço, texto e prova social cheguem a quem não renderiza. É servir o prato pronto, não mandar os ingredientes com a receita.
O site ranqueia razoavelmente no buscador tradicional e nenhum assistente o cita. Você já publicou mais conteúdo, reescreveu títulos, ajustou textos, e a agulha não se moveu. A conclusão fácil é culpar o volume ou a concorrência. A explicação provável é bem mais concreta: parte do que você vê na tela não existe no arquivo que o rastreador recebe.
Existem duas versões da sua página. A primeira é o HTML que o servidor devolve na resposta HTTP, antes de qualquer script rodar. A segunda é o DOM, o documento já montado no navegador depois que o JavaScript executou. Quando o conteúdo nasce no cliente, as duas versões são radicalmente diferentes, e você só olha para a segunda.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
A análise da Vercel sobre centenas de milhões de requisições não encontrou evidência de execução de JavaScript pelo GPTBot. O ClaudeBot chega a baixar arquivos de script em parte das requisições, e não os executa. A lista de agentes que não renderizam inclui GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent e Bytespider.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Uma confirmação de junho de 2026 mantém o quadro de pé: os grandes rastreadores de IA seguem sem executar JavaScript, e a recomendação deste módulo continua inteira. A exceção que vale conhecer é o Google-Extended, o agente ligado ao Gemini, que herda a renderização do Googlebot e chega a enxergar o DOM. Projetar a entrega para quem não renderiza é a aposta mais segura, porque atende os dois grupos de uma vez.
Isso explica a assimetria que parecia inexplicável. Uma landing construída como aplicação de página única pode aparecer bem no buscador, que renderiza, e ao mesmo tempo ser invisível para o motor de resposta, que não renderiza. O sintoma é o mesmo (ninguém cita você) e a causa mora na entrega, antes de qualquer discussão sobre o texto.
1. capturar curl na URL => HTML exatamente como o servidor entrega
2. capturar agente no navegador => DOM depois do JavaScript rodar
3. subtrair DOM menos HTML => inventário do que é invisível
o que sobra na subtração
e a sua fila de trabalhoComece pelo lado barato. O comando abaixo não abre navegador, não executa nada, e por isso enxerga exatamente o que um rastreador sem renderização enxerga.
# 1. Baixa o HTML como o servidor entrega. -s silencia o progresso, -L segue redirecionamento.
# Nenhum script roda aqui: e esse o ponto.
curl -sL "https://exemplo.com.br/sua-pagina" -o bruto.html
# 2. Quanto veio? Uma pagina de conteudo que chega com poucos milhares de bytes
# e sinal forte de que o texto nasce no cliente.
wc -c bruto.html
# 3. A sua frase de valor esta no que o servidor entregou?
# Sem saida na tela = a frase nao esta no HTML inicial.
grep -io "sua frase de valor aqui" bruto.html
# 4. Existe bloco de dados estruturados ja no HTML inicial?
grep -o "application/ld+json" bruto.html | wc -lNo Windows, o equivalente em PowerShell é Invoke-WebRequest -Uri "https://exemplo.com.br/sua-pagina" -UseBasicParsing -OutFile bruto.html. O parâmetro -UseBasicParsing importa: ele devolve a resposta crua, sem tentar montar um documento. Se você abrir o arquivo salvo no navegador, o JavaScript volta a rodar e você perde justamente a evidência que foi buscar.
// compara-bruto.mjs | uso: node compara-bruto.mjs https://exemplo.com.br/sua-pagina
// Requer Node 18 ou superior (fetch nativo). Nao executa o JavaScript da pagina,
// que e exatamente o comportamento que queremos reproduzir.
const url = process.argv[2];
if (!url) {
console.error("Uso: node compara-bruto.mjs <url>");
process.exit(1);
}
const resp = await fetch(url, { redirect: "follow" });
const html = await resp.text();
// Remove script, style e todas as tags: sobra o texto que existe ANTES de qualquer JS.
const texto = html
.replace(/<script[\s\S]*?<\/script>/gi, " ")
.replace(/<style[\s\S]*?<\/style>/gi, " ")
.replace(/<[^>]+>/g, " ")
.replace(/\s+/g, " ")
.trim();
// Blocos de dados estruturados presentes no HTML inicial.
const ldjson = html.match(/<script[^>]+application\/ld\+json[^>]*>/gi) || [];
console.log("status HTTP:", resp.status);
console.log("bytes de HTML:", html.length);
console.log("caracteres de texto no HTML bruto:", texto.length);
console.log("blocos ld+json no HTML bruto:", ldjson.length);
console.log("--- primeiros 600 caracteres de texto ---");
console.log(texto.slice(0, 600));Agora o outro lado. Com o navegador dirigido pelo agente (o assistente de IA que opera o navegador por você), a página já carregou e o JavaScript já rodou. A função abaixo devolve os mesmos indicadores medidos no DOM, para você comparar número com número em vez de palpite com palpite.
// Executado pelo agente na pagina ja carregada (evaluate_script do chrome-devtools MCP).
// Devolve o lado DIREITO do quadro: o que existe DEPOIS do JavaScript rodar.
() => {
const texto = document.body.innerText.replace(/\s+/g, " ").trim();
const blocos = Array.from(
document.querySelectorAll('script[type="application/ld+json"]')
);
return {
caracteresDeTexto: texto.length,
blocosLdJson: blocos.length,
// @type declarado em cada bloco, para conferir contra o que veio no HTML bruto
tiposDeclarados: blocos.map((b) => {
try {
const j = JSON.parse(b.textContent || "{}");
return j["@type"] || "(sem @type)";
} catch {
return "(JSON invalido)";
}
}),
h1: document.querySelector("h1")?.innerText?.trim() || null,
precoVisivel: /R\$\s?\d/.test(texto),
};
}Auditar apenas o DOM renderizado aprova páginas que os motores de resposta recebem vazias. É por isso que boa parte das auditorias automatizadas de mercado passa longe do problema: elas rodam dentro de um navegador, e dentro de um navegador está tudo lá. A auditoria só vale quando alguém compara as duas versões.
Com os dois números na mão, o entregável é um quadro de duas colunas por página. Anote o que existe no HTML bruto, o que só aparece no DOM, e marque com asterisco todo item de valor comercial que caiu na segunda coluna.
PÁGINA: /planos HTML BRUTO DOM RENDERIZADO ------------------------------------- -------------- ---------------- H1 e título da oferta presente presente Parágrafo de proposta de valor AUSENTE (*) presente Tabela de preços e condições AUSENTE (*) presente Depoimentos / prova social AUSENTE (*) presente Respostas do bloco de FAQ AUSENTE (*) presente Dados estruturados (ld+json) AUSENTE (*) 1 bloco, FAQPage Rodapé institucional presente presente bytes de HTML .......... 8.412 texto no HTML bruto .... 214 caracteres texto no DOM ........... 6.930 caracteres (*) precisa migrar para renderização no servidor
Se a coluna do HTML bruto tem 214 caracteres e a do DOM tem 6.930, o motor de resposta recebe 3% da sua página. Nenhuma reescrita de texto conserta isso, porque o texto reescrito também vai nascer no cliente. A correção pertence à engenharia de entrega.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Com dados estruturados, redobre o cuidado, porque aqui moram dois erros diferentes. O primeiro é o mesmo dos textos: um bloco de dados estruturados injetado por script existe para quem renderiza e não existe para quem não renderiza. Rode a mesma comparação nele.
O segundo erro é confundir validar sintaxe com validar elegibilidade a resultado enriquecido. São coisas distintas. Um validador de terceiro dizendo que o JSON está bem formado não é veredito do Google sobre exibição de resultado enriquecido. Não existe servidor MCP oficial do Google nem do schema.org para essa validação; o que há são implementações comunitárias, úteis como apoio e não como autoridade.
Escolha as três páginas por relevância comercial, não por facilidade. Pelo menos uma precisa ter conteúdo dinâmico (listagem, filtro, catálogo, preço vindo de API), que é onde a diferença costuma ser brutal. Uma página institucional estática vai passar no teste e não ensina nada.
A tradução para a fila de engenharia é curta. Conteúdo que precisa ser citado tem de estar na resposta do servidor. Renderização no servidor, geração estática ou pré-renderização resolvem, e a escolha entre elas depende de com que frequência o conteúdo muda. Qualquer uma delas vem antes de reescrever texto, publicar mais páginas ou mexer em arquivo de curadoria para agentes.
Se o item não está no HTML que o servidor entrega, ele não existe para quem não executa JavaScript. Antes de qualquer tática de conteúdo, garanta a entrega. Tática aplicada sobre conteúdo invisível multiplica zero.
1. conteúdo principal no HTML inicial (bloqueia tudo o mais) 2. dados estruturados no HTML inicial (junto com o conteúdo que descrevem) 3. conferir sintaxe do ld+json (sintaxe != elegibilidade) 4. só então: reescrita, volume, curadoria
Guia prático: coletar dados de concorrentes respeitando robots.txt e termos de uso
A mesma comparação entre HTML bruto e DOM serve para monitorar a oferta da concorrência: preço, título da landing, chamada para ação, prova social. O agente faz isso bem e rápido, e é exatamente por isso que precisa de limite escrito. Coleta abusiva vira bloqueio de IP, problema jurídico e, quando junta dado pessoal, incidente de privacidade.
Monitoramento semanal de três concorrentes, dentro das regras
Seis passos. Escreva as respostas dos dois primeiros antes de ligar qualquer ferramenta.
Passo 1: Leia o robots.txt de cada domínio e anote as regras para o agente de usuário que você vai usar
O padrão do arquivo está no RFC 9309. Se o caminho que você quer ler está em Disallow, a coleta automatizada daquele caminho para aqui.
Deu certo quando: Uma tabela com domínio, caminho desejado e permitido ou não.
Erro comum: Ler só a linha User-agent: * e ignorar regras específicas mais abaixo.
Passo 2: Leia os termos de uso do site e procure cláusulas sobre acesso automatizado
Se os termos proíbem robôs ou extração, a decisão sai do time de marketing e vai para o jurídico, mesmo com robots.txt liberado.
Deu certo quando: Uma linha por concorrente: termos permitem, proíbem ou são omissos, com o trecho copiado.
Erro comum: Tratar robots.txt liberado como autorização contratual.
Passo 3: Use perfil isolado, deslogado, e só páginas públicas
Nada de entrar com conta de teste na área logada do concorrente. Com a extensão do Claude, a coleta de imagens de rosto e a quebra de captcha são proibidas por produto.
Deu certo quando: Nenhum cookie de sessão no perfil usado na coleta.
Erro comum: Rodar a coleta no Chrome pessoal, com a sua conta de anúncios aberta em outra aba.
Passo 4: Defina o ritmo: uma página por vez, com intervalo, e uma rodada por semana
Monitorar oferta não pede tempo real. Poucas páginas, sempre as mesmas, comparadas semana a semana, rendem mais leitura e menos risco.
Deu certo quando: A coleta inteira cabe em poucos minutos e não gera bloqueio.
Erro comum: Pedir ao agente para "varrer o site todo".
Passo 5: Colete só dados comerciais públicos e salve HTML bruto e snapshot com data
Preço, plano, título, chamada principal, garantia. Comentários de clientes com nome e foto são dado pessoal sob a LGPD; fora da coleta.
Deu certo quando: Uma pasta por semana com o HTML bruto, o snapshot em texto e um resumo de mudanças.
Erro comum: Guardar captura de tela inteira com depoimentos e rostos de clientes do concorrente.
Passo 6: Desligue as ferramentas que a página oferece ao agente
Em coleta de terceiros, suba o Playwright MCP com --no-webmcp, como mostrado em "Barrar o ataque que chega pela ferramenta que você instalou". A página do concorrente não deve ditar ferramentas ao seu agente.
Deu certo quando: A lista de ferramentas do agente é a mesma antes e depois de abrir o site.
Erro comum: Deixar o agente obedecer a texto da página do concorrente; instruções embutidas em página são justamente o vetor de injeção indireta.
No fim você tem: Um relatório semanal de mudanças na oferta dos concorrentes, com fonte e horário de cada dado e a autorização de coleta documentada.
Faça a tarefa do módulo em até uma semana, seguindo os quatro passos abaixo, e confira no fim se cada item de valor comercial tem a coluna marcada:
- Escolha três páginas comercialmente relevantes, sendo pelo menos uma de conteúdo dinâmico.
- Monte para cada uma o quadro de duas colunas, com os números de bytes e de caracteres medidos, não estimados.
- Marque todo item de valor comercial que apareça só na coluna do DOM.
- Escreva, para o item mais crítico, uma frase de consequência prática caso ele não migre.
Critério de sucesso observável: o quadro está preenchido para as três páginas, com números medidos nas duas colunas, e você aponta pelo menos um item que precisa migrar para a renderização no servidor, explicando a consequência prática de não migrar. Se a segunda coluna vier vazia em alguma página, prove: mostre o trecho do conteúdo principal presente no HTML bruto, com o comando que você usou para extraí-lo.
A decisão que sobe até você é de sequência de investimento. Enquanto o conteúdo que vende nascer no cliente, cada real gasto em mais texto, mais páginas ou curadoria para agentes se multiplica por zero na leitura do motor de resposta. Coloque a renderização no servidor à frente na fila e trate a presença no HTML inicial como pré-requisito de qualquer meta de citação em IA, não como refinamento posterior.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- Diagnostique em que etapa a busca perde a sua páginasugerido pelo grafoApresenta os conceitos “Answer engine”, “Renderização” e “Robots.txt”, usados em “Descobrir o que a IA não vê na página que você vê”.
- O que é JavaScriptsugerido pelo grafoApresenta o conceito “JavaScript”, usado em “Descobrir o que a IA não vê na página que você vê”.
- Montar vídeo em HTML com HyperFrames e escolher entre ele e o Remotionsugerido pelo grafoApresenta o conceito “HTML”, usado em “Descobrir o que a IA não vê na página que você vê”.
- CursoMCP para quem decidesugerido pelo grafo7 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “MCP para quem decide”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Autoridade Temática e SEO de EntidadesO trecho que a IA consegue usar sozinhoExaminar conexões de O trecho que a IA consegue usar sozinho
- SEO ProgramáticoMedir o template contra as melhores páginas do assuntoExaminar conexões de Medir o template contra as melhores páginas do assunto
- GEO e Knowledge GraphVibe coding: o site que a IA escreve e o robô de IA não lêExaminar conexões de Vibe coding: o site que a IA escreve e o robô de IA não lê
- Frontends com VibecodingPublicar conteúdo encontrável em vários idiomasExaminar conexões de Publicar conteúdo encontrável em vários idiomas
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.