Agentes de IA para SEO em Produção: Arquitetura, Casos Reais e Como Medir o que Funcionou

Um agente de SEO só está pronto para operar quando você consegue explicar por que ele propôs uma mudança, impedir uma execução inválida e verificar o que aconteceu depois. A recomendação é apenas o começo.

No guia de SEO Specialist, o fluxo vai do crawl ao relatório. Aqui, avanço para o ciclo que começa quando alguém pergunta: “posso aplicar isso em centenas de páginas?”

Vamos estudar casos públicos, desenhar uma arquitetura e executar um laboratório de links internos. Ao final, você terá uma proposta revisável, uma aplicação idempotente — repetir a mesma operação não duplica o efeito — e uma reversão que respeita edições posteriores.

Pré-requisitos: entender ferramentas de agentes, ler Python e conhecer o básico de rastreamento e indexação. O laboratório usa Python 3.10+ e biblioteca padrão. Os dados e as decisões da demonstração são sintéticos; os casos empresariais são atribuídos às fontes originais.

A unidade de trabalho é uma hipótese verificável

Imagine um portal com milhares de artigos. Uma rotina detecta páginas com tráfego em queda. O agente sugere atualizar títulos, acrescentar conteúdo e criar links internos.

A lista parece útil, mas ainda não permite uma decisão. A queda aconteceu em qual país? Em consultas de marca ou genéricas? O conteúdo foi alterado? A página continua elegível para indexação? O período recente está completo? Existe uma hipótese que conecte o problema à intervenção?

Eu organizaria cada oportunidade como um pequeno dossiê:

Observe a diferença de responsabilidade. O modelo pode formular a hipótese e escolher qual evidência consultar. O executor precisa verificar se a mudança corresponde ao que foi aprovado. A análise posterior decide se há evidência suficiente para expandir a intervenção.

Essa divisão aparece em três camadas: observação, decisão e execução. Cada uma produz um artefato que a próxima consegue verificar.

Caso Pinterest: onde os agentes entram no sistema

Em um preprint de fevereiro de 2026, pesquisadores do Pinterest descrevem um sistema de aquisição que combina modelos de visão e linguagem, coleções temáticas, recuperação semântica e links internos. O componente de agentes investiga tendências com LangGraph, ferramentas de consulta e memória de curto e longo prazo. Os autores relatam 20% de crescimento no tráfego orgânico para o sistema completo. Estudo original, resumo e seção 3.1.2.

O caso tem uma fronteira importante: esse número não isola a contribuição dos agentes. O trabalho inclui várias intervenções e avaliações. Também não disponibiliza, nesse relato, um pacote completo para reproduzir a operação do Pinterest. É um estudo da própria equipe, não uma auditoria independente.

O aprendizado que aproveito é arquitetural: a geração de candidatos passa por recuperação e validação antes de alimentar páginas. No nosso exemplo, isso inspira exigir evidências de origem e destino antes de aceitar um link. A implementação abaixo é nossa proposta didática, não uma reprodução do código do Pinterest.

Caso SearchPilot: conteúdo e entrega técnica no mesmo teste

Em junho de 2026, a SearchPilot publicou um experimento em páginas de destinos de um cliente de viagens não identificado. As páginas tinham pouco conteúdo exclusivo e dependiam de renderização JavaScript. A intervenção adicionou conteúdo gerado por IA, disponível tanto no cliente quanto no HTML servido. O resultado divulgado foi um aumento estimado de 18% nas sessões orgânicas. Caso original.

O teste avalia o pacote de mudanças. Ele não separa quanto veio do texto adicional e quanto veio da forma de entrega. Tampouco documenta uma arquitetura de agentes autônomos.

Para o nosso sistema, a consequência prática é exigir uma verificação do artefato entregue: salvar conteúdo no CMS não prova que o HTML acessível ao crawler contém esse conteúdo. A etapa de aplicação deve devolver a versão publicada; a verificação deve consultar o resultado e registrar divergências.

Caso SearchPilot: o mesmo tipo de mudança diverge por mercado

Em um teste de reescrita com IA divulgado em 2023, a SearchPilot encontrou ganho estimado de 12,6% nos EUA, enquanto a Austrália apresentou resultado inconclusivo. A empresa recomendou implementar a mudança no primeiro mercado e continuar investigando o segundo. O cliente de viagens não foi identificado. Caso original.

Isso sustenta uma regra operacional que adotarei: a autorização para expandir uma mudança pertence ao segmento avaliado. Um resultado favorável em um país não libera automaticamente todas as traduções ou categorias.

Também precisamos de um estado explícito para “ainda não sabemos”. Um executor que só oferece success e failure incentiva decisões prematuras. Na avaliação de SEO, inconclusive deve ser um resultado legítimo, com motivo e próxima data de revisão.

Links internos: medir também quem aponta

Outro experimento da SearchPilot aumentou de dois para quatro os links de artigos relacionados em um hub de conteúdo. O ganho combinado estimado foi de 11%, mas não atingiu o intervalo convencional de 95% de confiança. As páginas doadoras apresentaram resultado positivo; nas receptoras, não houve efeito detectável. Caso e metodologia.

Esse detalhe influencia o desenho do nosso agente: registrar tanto a página que recebe a edição quanto a que recebe o link. Medir só o destino pode deixar parte do efeito fora da análise. E copiar “quatro links” como regra universal ignora o contexto e a incerteza do teste.

Arquitetura: do sinal à alteração rastreável

A arquitetura de referência tem um caminho principal e dois relógios. No primeiro, decisões e verificações técnicas acontecem em segundos ou minutos. No segundo, rastreamento, indexação e resultados orgânicos exigem observação posterior.

Inventário e métricas → investigação → proposta → validação → aprovação → aplicação → verificação técnica → avaliação orgânica.

Começaria com um agente e ferramentas pequenas. Separaria investigadores por especialidade somente se os dados, permissões ou avaliações exigissem essa divisão. Mais agentes significam mais contratos, custo e pontos de falha para operar.

MCP pode expor ferramentas, mas não substitui o armazenamento de propostas ou uma fila de execução. A durabilidade pertence ao sistema que guarda os trabalhos. Essa separação é aprofundada no guia de filas, retries e idempotência.

O que o modelo pode fazer

No laboratório, o modelo — ou o simulador que ocupa sua interface — só escolhe entre quatro ações:

• list_pages: descobrir as URLs do inventário permitido;
• get_page: consultar uma página e receber uma identificação da evidência;
• propose_link: propor um link com origem, destino, bloco, âncora e justificativa;
• stop: encerrar a investigação sem mudança.

Aplicar, aprovar e reverter são operações fora dessa interface. Um texto malicioso encontrado em uma página não ganha uma ferramenta de publicação por convencer o modelo a pedi-la.

Essa fronteira reduz o efeito de instruções indevidas no conteúdo, mas não garante relevância semântica. Um modelo ainda pode sugerir um link tecnicamente válido e editorialmente ruim. A revisão e a avaliação existem para detectar isso.

Dados de SEO: registre também o que você não sabe

Antes de sofisticar o raciocínio, estabeleça a qualidade das entradas. Um relatório de busca, um crawl recente e uma inspeção de indexação respondem a perguntas diferentes.

Search Console: desempenho com limites de cobertura

A Search Analytics API oferece cliques, impressões, CTR e posição agrupados por dimensões. A documentação permite paginação com startRow e até 25.000 linhas por requisição, mas avisa que a API retorna as principais linhas e não garante todas elas. Datas usam o horário do Pacífico; dataState: "final" seleciona dados finalizados. Referência oficial.

Uma requisição de referência para desempenho diário por página seria:

{
  "startDate": "2026-08-01",
  "endDate": "2026-08-28",
  "dimensions": ["date", "page"],
  "type": "web",
  "dataState": "final",
  "rowLimit": 25000,
  "startRow": 0
}

Trate isso como contrato para um coletor autenticado; o laboratório local não chama essa API. Guarde os parâmetros junto ao resultado. Para investigar país, dispositivo ou consulta, faça extrações segmentadas e registre a cobertura. Ausência de uma linha não deve virar automaticamente “zero demanda”.

Na minha proposta, uma coleta incompleta permite produzir um diagnóstico com ressalva, mas bloqueia uma conclusão numérica que dependa daquela cobertura. “Não coletado”, “não disponível” e “observado como zero” precisam continuar distintos no banco.

Inspeção de URL e crawl são observações diferentes

A URL Inspection API consulta informações sobre a versão indexada; não executa um teste ao vivo nem solicita indexação. Assim, uma inspeção histórica não prova que a versão que você acabou de publicar já foi processada. Documentação oficial.

Para verificar a alteração imediata, leia o HTML entregue, o status HTTP, a canonical e as diretivas pertinentes. Para observar o que o mecanismo de busca conhece, registre a inspeção separadamente. Um campo único chamado seo_ok apaga essa diferença.

Crawler com escopo explícito

Em um serviço real, o coletor deve limitar domínio, caminhos, redirecionamentos, tamanho de resposta, tempo e concorrência. Resolver uma URL sugerida pelo modelo exige controles de rede contra acesso a destinos internos, inclusive após redirects e resolução DNS.

O exemplo evita esse problema por construção: só lê duas URLs que já estão no banco e não possui cliente HTTP. Isso é uma restrição do laboratório, não uma implementação de crawler seguro. Ao adicionar rede, o controle de destino precisa existir na camada que realmente estabelece a conexão.

Laboratório: um link, uma proposta, um recibo

Os arquivos completos estão disponíveis para baixar:

• Pacote completo — código, testes e instruções (.zip)
• Executor e armazenamento — seo_agent.py
• Simulador de decisões — demo_model.py
• Testes de falha — test_seo_agent.py

Salve os três na mesma pasta. O simulador não é um LLM: ele percorre decisões predefinidas para tornar os testes reproduzíveis. O laboratório demonstra o contrato de execução; não demonstra capacidade de raciocínio de um modelo nem ganho orgânico.

Se baixar o pacote completo, extraia-o e abra um terminal na pasta seo-agent-lab. Use um banco novo para uma experiência nova; repetir init preserva os documentos existentes e não renova snapshots expirados.

Inicialize um CMS local de demonstração

O SQLite representa um inventário e um CMS simplificado. Cada documento tem blocos de texto, metadados de elegibilidade, revisão e data de coleta. Os links são anotações sobre intervalos de texto; o renderizador escapa o conteúdo ao produzir HTML.

python3 -B seo_agent.py --db seo-lab.db init
python3 -B seo_agent.py --db seo-lab.db run \
  --run-id investigacao-001 \
  --model-command python3 -B demo_model.py

A primeira execução consulta o inventário, lê as duas páginas e cria uma proposta pendente. A saída contém proposal_id, uma identificação derivada do conteúdo da proposta, e status: "pending".

O caso sintético é simples: um guia contém o trecho “observabilidade de agentes”; outra página aprofunda esse assunto. A ação candidata é transformar aquele trecho em link. Nenhuma página externa é lida ou modificada.

Exija evidências antes de aceitar a proposta

A proposta contém sete campos. A justificativa é curta e revisável; o registro guarda chamadas e resultados de ferramentas, sem exigir a exposição de raciocínio interno do modelo.

{
  "source": "https://example.com/guia/",
  "target": "https://example.com/observabilidade/",
  "block_id": "p1",
  "anchor": "observabilidade de agentes",
  "reason": "O trecho menciona o assunto aprofundado no destino.",
  "source_evidence": "HASH_RETORNADO_POR_GET_PAGE",
  "target_evidence": "HASH_RETORNADO_POR_GET_PAGE"
}

Os valores HASH_RETORNADO_POR_GET_PAGE são marcadores explicativos; o programa usa os hashes efetivamente retornados pelas ferramentas. Um hash identifica o snapshot. Ele não certifica que a fonte está correta ou que a justificativa faz sentido.

O executor valida fatos que consegue decidir sem inferência:

1. origem e destino pertencem ao inventário e são diferentes;
2. ambas as páginas têm HTTPS, domínio permitido, status 200, canonical própria e elegibilidade registrada;
3. os snapshots não têm mais de 24 horas nem data futura;
4. os hashes ainda correspondem aos documentos consultados;
5. o bloco existe e a âncora aparece exatamente uma vez;
6. não existe link anterior para o destino nem anotação no bloco escolhido.

O limite de 24 horas é política ilustrativa, não recomendação universal de SEO. Um catálogo com alterações frequentes pode exigir validade muito menor. O laboratório aceita somente um link por bloco para evitar fingir que um substituidor de strings resolve edição de HTML arbitrário.

Leia, aprove e aplique a versão exata

Copie o identificador retornado para a variável abaixo. A revisão mostra o payload completo antes de aprová-lo.

PROPOSAL_ID='cole-aqui-o-proposal_id-retornado'
python3 -B seo_agent.py --db seo-lab.db review "$PROPOSAL_ID"
python3 -B seo_agent.py --db seo-lab.db approve "$PROPOSAL_ID" \
  --reviewer editor-local
python3 -B seo_agent.py --db seo-lab.db apply "$PROPOSAL_ID"
python3 -B seo_agent.py --db seo-lab.db render \
  https://example.com/guia/ > depois.html

Abra depois.html para inspecionar o link. O arquivo contém uma representação local do documento, não uma publicação em example.com.

O nome editor-local é um registro de intenção para a demonstração. Ele não autentica ninguém. Em produção, aprovação precisa usar a identidade autenticada do revisor, controle de acesso e associação ao identificador imutável da proposta. O agente não deve ter as mesmas credenciais do aprovador.

A versão mudou? Refaça a investigação

Entre a proposta e a aplicação, um editor pode reescrever a origem; o destino pode ganhar noindex; o snapshot pode expirar. Por isso, a aplicação repete a validação dentro da transação de escrita.

O trecho central do executor é:

with self.db:
    self.db.execute('BEGIN IMMEDIATE')
    row = self.proposal(proposal_id)
    if row['state'] == 'applied':
        return 'already_applied'
    if row['state'] != 'approved':
        raise ValueError('Aprovação explícita necessária')
    payload = json.loads(row['payload'])
    source = self.validate(payload)

Na sequência, a mesma transação grava a nova versão do documento e o recibo da alteração. Repetir apply retorna already_applied. Uma revisão crescente evita confundir uma versão antiga com uma edição nova que coincidentemente recuperou o mesmo texto.

Esse exemplo consegue atomicidade porque o CMS simulado e o ledger estão no mesmo SQLite. Em um CMS remoto, duas escritas separadas não herdam essa garantia. Você precisará de comparação de versão, chave de idempotência suportada pelo destino ou reconciliação após resultado incerto.

Se a API do CMS der timeout depois de salvar, não assuma que falhou. Leia a versão e o conteúdo atuais antes de repetir. Um recibo com unknown é mais útil que uma segunda edição feita às cegas.

Reverter também exige precondição

python3 -B seo_agent.py --db seo-lab.db rollback "$PROPOSAL_ID"

A reversão restaura o conteúdo anterior somente se a versão atual corresponder ao documento aplicado. Se houver edição posterior, o programa interrompe e pede revisão manual. Isso evita desfazer trabalho legítimo de outra pessoa.

Em produção, prefira reverter o patch específico quando o CMS oferecer esse recurso, mantendo a mesma proteção contra conflito. E lembre: restaurar HTML não garante restaurar imediatamente a posição ou o tráfego anteriores. A reversão técnica encerra um efeito de escrita, não rebobina o mecanismo de busca.

Conectando um modelo real sem entregar o executor a ele

O parâmetro --model-command recebe um programa escolhido pelo operador. Esse adaptador lê um JSON pela entrada padrão e devolve outro com tool e args. O executor usa uma lista de argumentos, sem shell intermediário.

Para conectar um provedor, implemente um adaptador que:

1. leia a instrução, o catálogo de ferramentas e o histórico;
2. envie instruções e conteúdo de páginas em papéis separados;
3. peça uma única chamada estruturada compatível com o catálogo;
4. normalize a resposta para {"tool": "get_page", "args": {"url": "..."}};
5. escreva apenas o JSON na saída padrão e mantenha credenciais fora do histórico.

O programa limita a investigação a oito decisões persistidas. O subprocesso tem timeout de 30 segundos por chamada. Falhas de transporte ou JSON interrompem a execução; uma nova chamada com o mesmo run-id retoma o histórico gravado. Ferramentas não permitidas e propostas inválidas consomem orçamento e geram observações de erro.

A retomada assume um worker por investigação. Não há lease distribuído nem cobrança de tokens no laboratório. Uma queda após o provedor responder e antes do checkpoint pode repetir a inferência e seu custo. Por isso, limite de passos não substitui teto financeiro, controle de saída ou limite de tempo total.

O adaptador é um componente confiável da aplicação, não um sandbox. Execute-o com permissões restritas e ambiente mínimo em produção. O código fornecido valida a passagem para as ferramentas; ele não isola um executável malicioso configurado pelo operador.

Contratos pequenos facilitam trocar o modelo

A saída propose_link não contém SQL, HTML ou um comando para o CMS. Ela descreve uma intenção limitada. Isso permite comparar modelos sobre a mesma tarefa, mantendo idênticas as regras de aplicação.

Se o modelo quiser inventar uma ferramenta chamada publish_all, a investigação registra erro. Se pedir propose_link com um destino inexistente, a validação rejeita. Se escolher uma relação semântica fraca entre páginas existentes, o validador técnico pode aceitar — esse é o ponto em que uma avaliação editorial precisa atuar.

Separar essas falhas ajuda a diagnosticar uma troca de modelo: aumentou a qualidade das hipóteses ou apenas caiu o número de erros de formato?

Teste falhas antes de avaliar crescimento

Rode a suíte local:

python3 -B -m unittest discover -s . -p 'test_seo_agent.py' -v

Os testes cobrem aplicação sem aprovação, replay, reversão, edição posterior, destino inelegível, evidência antiga, âncora ausente ou ambígua, URL externa, orçamento, retomada e escape de conteúdo.

Um teste particularmente útil injeta erro na gravação do recibo depois da tentativa de atualizar o documento. A transação deve desfazer ambas as alterações. Esse cenário verifica uma propriedade do sistema que costuma ficar escondida no caminho feliz.

O Google recomenda links rastreáveis com elemento <a> e href, além de âncoras descritivas e contextuais. Isso orienta nossa verificação do HTML e a rubrica editorial. Não implica uma quantidade ideal universal de links. Boas práticas oficiais.

Avalie o agente e o SEO em dois relógios

O primeiro relógio mede se a operação funcionou como projetada. O segundo mede efeitos externos que o executor não controla. Misturar os dois cria relatórios em que “100 alterações publicadas” vira sinônimo de sucesso.

Relógio operacional: execução e qualidade editorial

Monte um conjunto de oportunidades revisado por pessoas que conhecem o conteúdo. Inclua candidatos bons, páginas sem relação, âncoras ambíguas, destinos desatualizados e casos em que a resposta correta é não propor nada.

Minha rubrica teria quatro perguntas:

• A evidência citada existe e corresponde à versão avaliada?
• O destino aprofunda o assunto indicado pela âncora?
• A inserção preserva a leitura e evita uma recomendação enganosa?
• A investigação soube encerrar quando não encontrou oportunidade suficiente?

Meça precisão das propostas: propostas consideradas úteis divididas pelas propostas avaliadas. Meça cobertura separadamente, porque o agente que nunca sugere nada pode evitar erros sem entregar valor. Registre também tempo de revisão, custo e razões de rejeição.

A taxa de aprovação do editor é um indicador de utilidade, mas não uma verdade absoluta: revisores podem discordar ou aprovar com pressa. Use uma amostra com revisão independente para calibrar a rubrica antes de transformar essa taxa em meta.

Relógio orgânico: desenho do experimento

Defina intervenção, páginas, segmento, métrica principal e critério de encerramento antes do lançamento. Para links internos, considere efeitos sobre origem e destino e possíveis conexões com o grupo de controle. Um controle que recebe novos links da variante pode deixar de representar uma situação sem tratamento.

O Google orienta investigar quedas considerando problemas técnicos, atualizações, sazonalidade e mudanças no interesse de busca. Essa variedade de causas torna insuficiente atribuir uma variação inteira à última edição. Guia de investigação de quedas.

Uma comparação ilustrativa ajuda a perceber o problema:

Tratamento: 1.000 → 1.200 cliques (+20%)
Controle:  2.000 → 2.200 cliques (+10%)

Razão de variações:
(1.200 / 1.000) / (2.200 / 2.000) - 1 ≈ 9,1%

Os números são sintéticos. A conta ajusta um crescimento comum, mas não constitui por si só um estimador causal validado. Ela não modela incerteza, dependência temporal, diferenças prévias entre grupos ou interferência entre páginas.

Um teste operacional precisa de comparabilidade anterior, volume suficiente, análise adequada e registro de mudanças concorrentes. Evite encerrar no primeiro dia favorável. Para sites pequenos, talvez a evidência permaneça descritiva: isso ainda pode orientar trabalho, desde que a conclusão respeite esse limite.

Critérios de decisão

Segurança técnica pode justificar uma interrupção imediata. Uma oscilação diária de tráfego exige outro tipo de evidência. Codifique políticas distintas para essas decisões.

Custos, observabilidade e limites de autonomia

Uma execução barata que gera duas horas de revisão pode ser cara para a operação. Eu acompanharia o custo total por proposta útil:

custo por proposta útil =
(coleta + inferência + execução + revisão humana) / propostas úteis

Essa métrica ainda não representa retorno financeiro. Para estimar retorno, conecte resultados a conversões ou valor de negócio com a atribuição disponível. Não transforme cliques em receita usando um multiplicador inventado.

O registro mínimo de uma execução deveria incluir run_id, ferramenta, latência, resultado, versão da política, versão do adaptador, consumo reportado pelo provedor, proposta, revisor e recibo. Registre identificadores e evidências necessárias; remova credenciais e minimize dados de consultas que possam ser sensíveis.

No laboratório, o histórico SQLite guarda decisões, resultados e identificações das propostas. Instrumentação de latência, tokens, alertas, retenção e acesso ao banco são extensões de produção. O guia de observabilidade aprofunda essa camada.

Uma política de autonomia que cabe em uma tabela

As políticas de spam do Google incluem abuso de conteúdo em escala: produzir muitas páginas principalmente para manipular rankings, sem ajudar usuários. A regra não depende de a produção ser humana ou automatizada. Política oficial.

A pergunta editorial deve acompanhar cada proposta: o que esta alteração ajuda o visitante a encontrar ou entender? Uma resposta específica é um critério melhor de revisão que “o agente deu uma nota alta”.

O que falta para operar em um site real

O laboratório entrega uma fronteira testável entre investigação e escrita. Para levá-lo a produção, estas são as próximas responsabilidades concretas:

• Coleta real: autenticação de leitura, inventário autorizado, cobertura, cache e renovação de snapshots.
• Modelo real: adaptador com schema, limite de saída, custo por execução e avaliação em conjunto rotulado.
• CMS real: edição por bloco ou AST, versão esperada, idempotência e reconciliação de timeouts.
• Identidade: separação entre investigador, aprovador e executor; trilha de auditoria protegida.
• Concorrência: lease por trabalho, restrição de mudanças simultâneas por documento e fila de falhas.
• Experimentos: segmentação, coleta histórica, acompanhamento de recrawl e análise de incerteza.

Não é necessário implementar tudo para experimentar localmente. É necessário reconhecer essas fronteiras antes de autorizar um agente a escrever no site. O artigo de Graph Engineering ajuda a transformar essas responsabilidades em estados e transições explícitos.

Comece por uma alteração que você consiga explicar

Escolha uma classe de intervenção, reúna evidências e faça o agente preparar propostas pequenas. Rode os testes de falha. Revise o HTML resultante. Depois organize a medição orgânica com um segmento e uma hipótese definidos.

Minha recomendação é começar com links internos em um conjunto limitado de páginas, porque o objeto da revisão é concreto: um trecho, um destino e uma versão. A quantidade autorizada deve seguir a capacidade de revisão e o desenho da avaliação, não uma meta de volume gerada pelo modelo.

O sistema amadurece quando você consegue responder: qual evidência sustentou esta alteração, quem a aprovou, qual versão foi aplicada, o que aconteceu depois e quais conclusões os dados ainda não permitem. Esse é o ciclo que transforma uma boa sugestão de SEO em uma operação que merece confiança.

Fontes e limites da evidência

Fontes consultadas em 14 de setembro de 2026. Casos empresariais são relatos das respectivas equipes; números não são resultados deste laboratório nem promessas de desempenho.

• Pinterest — estudo técnico, versão 1: sistema de aquisição com agentes e componentes de recuperação; resultados agregados.
• SearchPilot — conteúdo em páginas de destinos, 2026: intervenção combinando conteúdo e entrega no HTML.
• SearchPilot — reescrita em dois mercados, 2023: resultados distintos entre segmentos.
• SearchPilot — links de artigos relacionados, 2021: análise de origem, destino e resultado combinado.
• Search Analytics API e URL Inspection API: contratos e limites das fontes de dados.
• Google — links rastreáveis, investigação de quedas e políticas de spam: referências para implementação e avaliação.