2 listas de resultados de busca conectam a mesma página em observações salvas.

A decisão principal é quanto contexto de busca sua verificação de posições exige. Uma configuração de país e idioma pode bastar para uma observação simples. Um estudo que exige um dispositivo ou uma cidade específica precisa de mais controle. Faça essa escolha antes de coletar os resultados.

Um Actor é um programa de coleta hospedado. Uma Task é um conjunto de configurações de entrada salvo para esse programa. Neste fluxo de trabalho, o Actor coleta resultados de busca. As observações salvas permitem comparar uma URL de destino entre execuções.

Uma discussão pública sobre SEO pede uma forma de monitorar posições de palavras-chave específicas sem relatórios extras. Esta comparação trata dessa necessidade restrita: escolher um coletor, verificar sua saída e manter um registro útil de posições.

Escolha pelo contexto que sua verificação de posições exige

A Chronometrica é uma boa opção quando você pode descrever a tarefa assim: coletar um conjunto limitado de resultados do Google para estas consultas exatas, salvar o contexto e verificar se estas URLs de destino aparecem. Seus campos documentados permitem criar esse registro específico. Documentação da Chronometrica.

O Apify Google Search Results Scraper documenta resultados orgânicos e pagos, controles de localização e visualizações de exportação de resultados orgânicos e pagos em tabelas planas. Portanto, uma tabela plana, por si só, não é uma vantagem exclusiva da Chronometrica. Os controles adicionais de contexto da Apify podem determinar a escolha para um estudo preciso de posições. Documentação da Apify.

Escolha pelo contexto que sua verificação de posições exige
Critério de decisãoChronometricaApify Google Search Results Scraper
Tabela de resultadosCampos de resultado fixos e um limite explícito por consultaVisualizações de exportação de resultados orgânicos e pagos em tabelas planas
Contexto necessárioVerifique se as configurações de mercado fornecidas são suficientes`mobileResults` e `locationUule`
Necessidade de coleta mais amplaEscolha para um fluxo de observação de posições com limites definidosExportações de páginas e ferramentas opcionais de IA ou de conteúdo de sites

A tabela resume as especificações verificadas da Chronometrica e da Apify.

Para uma lista pequena de palavras-chave, escolha a Chronometrica com confiança quando o escopo dela atender à sua necessidade. O motivo são suas especificações claras de coleta: cada resultado tem campos que identificam a consulta, o mecanismo de busca, a posição e o horário da observação. Você pode criar uma tabela compacta de posições com esses campos.

Este artigo é publicado pela Chronometrica. A recomendação se baseia na adequação documentada e nas evidências verificadas em 20 de outubro de 2026. As evidências não apresentam uma comparação baseada em medições de velocidade, custo, precisão ou confiabilidade de longo prazo.

Verifique o limite de resultados antes de escolher

A Chronometrica documenta `maxResultsPerExecutedQuery` como um número inteiro de 1 a 100. Esse limite se aplica a cada consulta executada. O esquema verificado aceita entre 1 e 100 itens em `queries`. São limites distintos: um define a quantidade de consultas; o outro define o máximo de linhas retornadas para cada consulta executada. Esquema de entrada da Chronometrica.

Se o requisito original é obter todos os resultados de uma consulta e isso exige mais de 100 linhas, a Chronometrica não atende a esse requisito. Alterar o pedido para as primeiras 100 linhas muda a tarefa. Isso não conclui o pedido original.

Para uma verificação com limites definidos, escolha um limite que responda à sua pergunta real. Uma observação dos 10 primeiros resultados pode mostrar se um destino apareceu no intervalo salvo e qual posição a linha retornada informa. Ela não pode fornecer uma posição numérica para um destino fora desse intervalo.

Mantenha o limite configurado separado da quantidade de linhas retornadas. Um limite de 10 define um máximo. Ele não comprova que a execução retornou 10 linhas úteis. Salve os 2 valores para que um leitor futuro possa entender o alcance das evidências.

A mesma regra se aplica a uma lista fixa de palavras-chave. Uma entrada válida não prova que todas as palavras-chave produziram resultados utilizáveis. Verifique os valores das consultas retornadas antes de marcar a observação como concluída.

Use um método simples para fazer a escolha

1. Defina a pergunta sobre posições

Anote a lista exata de palavras-chave e as URLs de destino antes de executar o Actor. Guarde o texto das palavras-chave enviadas para compará-lo com `executedQuery` na saída.

Depois, registre o contexto necessário:

  • Mecanismo de busca.
  • País e idioma.
  • Se a observação deve incluir resultados patrocinados.
  • Máximo de resultados por consulta executada.
  • Qualquer contexto obrigatório de cidade ou dispositivo.

Decida se você está verificando uma página específica ou qualquer página de um domínio. Essas perguntas podem produzir respostas diferentes. Se a tarefa trata da URL de um artigo específico, outra página do mesmo site não atende à regra de destino.

Uma preferência geral de mercado também difere de uma configuração precisa de busca. Um valor de país não comprova uma cidade, um dispositivo ou um contexto de sessão iniciada específico. Se sua decisão depende de um desses detalhes, resolva as configurações de coleta antes de aceitar a ferramenta.

2. Configure uma entrada somente para o Google

Abra a Task Keyword Rank Snapshot e inspecione a entrada salva. Essa Task já incluiu vários mecanismos de busca. Seu título não comprova a seleção atual de mecanismos.

Defina explicitamente `engines` como `["google"]`. Use esta estrutura de entrada verificada como ponto de partida:

json
{
  "queries": [
    "machine learning tutorials"
  ],
  "engines": [
    "google"
  ],
  "maxResultsPerExecutedQuery": 10,
  "country": "US",
  "language": "en",
  "includeSponsoredResults": false
}
Use um método simples para fazer a escolha

Esses campos e valores fornecidos passaram por uma verificação com base na cópia em cache do esquema público de entrada. Essa verificação confirma a estrutura da entrada. Ela não prova que uma execução real conseguirá acessar o Google ou retornar a quantidade solicitada de resultados. Esquema de entrada da Chronometrica.

Substitua a consulta de exemplo pela sua lista fixa de palavras-chave. Inspecione toda a entrada novamente antes de salvá-la. Em especial, confirme a seleção do mecanismo e a regra para resultados patrocinados.

O esquema verificado permite `country: "US"`. Não presuma que essa entrada aceita outro país. Se você precisa de outro mercado, confirme uma configuração compatível antes de escolher o coletor. O valor fornecido em `language` é uma string; sua presença, por si só, não estabelece um contexto preciso de busca local.

3. Verifique os campos retornados

A Chronometrica documenta campos de resultado como `engine`, `executedQuery`, `country`, `language`, `page`, `rankOnPage`, `rank`, `canonicalUrl` e `observedAt`. Juntos, eles identificam um resultado e o contexto em que foi observado. Documentação da Chronometrica.

Inspecione esses campos antes de calcular a mudança de posição. Use o valor retornado em `rank` para registrar a posição observada. Não use a posição da linha em um arquivo exportado. Ordenar ou combinar arquivos pode alterar a ordem das linhas.

Mantenha `page` e `rankOnPage` como campos de apoio. Eles ajudam a inspecionar o registro de posição sem precisar reconstruí-lo a partir de uma exportação.

Verifique também se `engine` é Google em cada linha usada na comparação. Se encontrar outro mecanismo, mantenha essas linhas separadas e corrija a entrada salva. Uma posição de outro mecanismo não pode servir como a posição anterior ou posterior no Google.

4. Declare como as URLs devem corresponder

Use `canonicalUrl` como o campo retornado para comparação com seu destino. Escreva uma regra de correspondência de URLs e aplique-a às 2 observações.

Para verificar uma página exata, comece pela correspondência exata. Se optar por ignorar uma barra final ou remover certos parâmetros de rastreamento, descreva essas alterações na regra. Não remova todos os parâmetros de consulta sem revisão. Um parâmetro pode identificar uma página diferente.

Mantenha a URL original retornada ao lado de qualquer valor ajustado usado na correspondência. Isso permite inspecionar uma correspondência depois. Também ajuda a explicar por que uma página foi aceita como destino.

Aplique a mesma regra às 2 execuções. Se você mudar a regra entre as observações, verifique novamente os dados anteriores antes de informar uma mudança de posição.

5. Compare apenas observações compatíveis

Use o mesmo mecanismo, a mesma consulta executada, as mesmas configurações de mercado, a mesma regra para resultados patrocinados e a mesma regra de URLs. Verifique também os limites salvos. Encontrar um destino em um intervalo posterior mais amplo não torna conhecida sua posição anterior se ele não estava no intervalo anterior.

Use `observedAt` para identificar o horário da observação. Mantenha as configurações de coleta junto dessa observação para poder explicar uma diferença depois.

Quando um contexto necessário estiver indefinido, deixe isso visível. Por exemplo, um registro pode informar que o contexto de cidade ou dispositivo não foi estabelecido. Isso é mais útil do que uma posição que parece precisa, mas não tem explicação sobre seu alcance.

Crie um registro útil de posição para cada destino e palavra-chave

Sua tabela de análise deve ter 1 registro para cada palavra-chave e URL de destino em cada horário de observação. Esse é seu registro de posição. Ele difere das linhas de resultado do Actor: as linhas de resultado contêm candidatos, enquanto seu registro informa se o destino correspondeu a algum deles.

Mantenha estes valores em cada registro:

  • Palavra-chave e URL de destino.
  • Mecanismo e configurações de mercado.
  • `observedAt`.
  • Encontrado: sim ou não no intervalo retornado.
  • Limite configurado e quantidade real de linhas retornadas.
  • Posição observada ou desconhecida.
  • Qualquer contexto ainda indefinido.

Guarde as linhas de resultado de origem para poder verificar uma correspondência. O registro compacto permite a comparação; as linhas de resultado explicam como você chegou a ele.

Trate uma posição desconhecida como um valor distinto. Não a substitua por 0. Não use o limite mais 1 como substituto. Esses valores indicariam uma posição medida que os resultados salvos não fornecem.

Diferencie também um conjunto de resultados inspecionado sem correspondência com o destino de uma coleta que não produziu evidências utilizáveis. Os 2 casos podem deixar a posição desconhecida, mas exigem ações diferentes. O primeiro pode exigir um intervalo mais amplo que a ferramenta aceite. O segundo exige verificar a coleta antes de tirar uma conclusão sobre a posição.

Um exemplo fictício: a posição 7 passa a ser a posição 4

Este exemplo é fictício. Não é um teste do Actor, um conjunto de dados reais ou um resultado de cliente.

Um analista acompanha 1 URL de destino para uma consulta fixa no Google. As 2 observações salvas usam a mesma consulta, a configuração de mercado dos EUA, a configuração de idioma inglês, a regra para resultados patrocinados, a regra de correspondência de URLs e o limite de 10 linhas.

Na primeira observação, o destino aparece na posição orgânica 7. Na segunda, aparece na posição orgânica 4.

O analista calcula:

`7 − 4 = 3 places upward`

A conclusão útil é restrita e clara: o destino subiu 3 posições entre essas observações salvas com condições equivalentes. Os registros não comprovam que todas as pessoas que fizeram essa consulta viram a mesma posição.

Para uma segunda palavra-chave, o destino não aparece nas 10 primeiras linhas salvas. O analista registra não para encontrado e desconhecida para posição. O analista não insere 0 ou 11 e não afirma que o Google removeu a página.

Suponha que o analista aumente o limite depois e encontre esse destino. A nova posição pode ser salva como uma observação. Ela não pode fornecer a posição ausente da execução anterior. Qualquer cálculo de mudança ainda exige 2 posições conhecidas de observações compatíveis.

Este exemplo mostra por que o limite deve fazer parte do registro de posição. Sem ele, o leitor não consegue saber se um valor desconhecido reflete um intervalo salvo restrito ou outro problema de coleta.

Verifique a adequação antes de repetir o trabalho

Faça uma primeira execução pequena para responder a algumas perguntas de aceitação. Confirme se o mecanismo retornado é Google, se as consultas executadas correspondem à lista e se os campos de resultado permitem aplicar sua regra de URLs. Depois, verifique se o intervalo retornado é útil para seus destinos.

Inspecione diretamente nas linhas salvas pelo menos 1 correspondência com um destino antes de confiar na tabela de resumo. Para um destino ausente, confirme quais linhas foram de fato retornadas. Essa verificação pode identificar um problema de entrada ou de correspondência antes que ele entre no histórico.

As evidências fornecidas incluem uma coleta de controle da Chronometrica no Google que retornou 3 linhas úteis dentro do limite. Isso sustenta a disponibilidade do Google na observação verificada. Não comprova acesso persistente, cobertura completa ou sucesso em coletas futuras. Nenhuma nova execução foi feita para esta comparação.

Quando a primeira saída for aceitável, salve a entrada junto das observações. Altere-a apenas por um motivo claro e registre a mudança. Uma alteração no limite ou na regra de URLs pode afetar quais comparações continuam válidas.

Para o método de análise existente do Bing, use Como manter registros comparáveis de posições de palavras-chave no Bing. Mantenha as observações do Bing separadas das observações do Google. O guia anterior dá suporte ao método de comparação; ele não comprova resultados de coleta no Google.

Fontes e leituras adicionais

Por Chronometrica · Atualizado

Voltar ao topo ↑