5 maneiras de usar arquivos de log para SEO com Gerry White

Como você está aproveitando os arquivos de log para melhorar seu SEO?

É sobre isso que vamos falar hoje com um homem com mais de 20 anos de experiência na indústria de SEO, trabalhando em marcas e agências, incluindo BBC, Just Eat e Rise at Seven. Uma recepção calorosa ao podcast In Search SEO, Gerry White.

Neste episódio, Gerry compartilha cinco maneiras de usar arquivos de log para SEO, incluindo:

• Vendo como o Google olha para o seu site
• Parâmetros
• Existem subdomínios consumindo seu orçamento de rastreamento
• Arquivos JavaScript e CSS
• Códigos de resposta

Gerry: Ei, que bom estar aqui.

D: Bom ter você. Você pode encontrar Gerry pesquisando Gerry White no LinkedIn. Então, Gerry, todo SEO deveria usar arquivos de log?

G: Não, sei que soa controverso quando digo que arquivos de log, temos uma grande quantidade de informações. Mas, honestamente, na maioria das vezes são retornos decrescentes. E geralmente você pode encontrar muitas informações antes de entrar nos arquivos de log. O que quero dizer com isso é que, se você der uma olhada nas informações do Google Search Console, há uma grande quantidade de informações lá. Quando estou procurando arquivos de log, é quando primeiro esgotei muitos outros lugares. Eu sempre recomendo rastrear um site usando qualquer coisa como o Screaming Frog ou qualquer outro rastreador de desktop que você tenha e, em seguida, olhar para o Google Search Console antes de começar a olhar para os arquivos de log.

A razão pela qual digo isso, e a razão pela qual pareço quase anti-logfiles quando vou falar sobre como eles são úteis, é o fato de que eles são realmente bastante desafiadores para trabalhar inicialmente. E é preciso um pouco de habilidade, conhecimento e experiência para realmente colocar as mãos neles e até mesmo ter acesso a eles. Mas uma grande coisa sobre hoje é o fato de que agora, na verdade, temos mais acesso aos arquivos de log do que nunca. Inicialmente, quando comecei, não tínhamos o Google Analytics ou qualquer software analítico como temos hoje. A análise do arquivo de log foi como vimos como as pessoas visitaram os sites. Agora, nunca olhamos para os arquivos de log raramente para saber como as pessoas olham para os sites, a menos que estejamos fazendo algo com o InfoSec. Ou estamos fazendo algo para diagnosticar algo realmente estranho e maravilhoso.

Mas, na verdade, na maioria das vezes, temos um software de análise muito melhor. Isso pode mudar porque, na verdade, uma coisa estranha é o fato de que muitos sites não conseguem rastrear quantas pessoas vão para uma página 404, porque na maioria das vezes você nunca clica em aceitar cookies em uma página 404. . De repente, os arquivos de log estão voltando para responder a algumas perguntas muito estranhas como essa.

Mas a principal razão pela qual estou falando sobre arquivos de log hoje é para fins de SEO. Então, sim, se você tem problemas com sites grandes, se você tem um grande site de comércio eletrônico, se você tem um site internacional, multilíngue e enorme com navegação facetada, os arquivos de log são algo que definitivamente deve ser levado em consideração. em conta e definitivamente deve ser analisado o mais rápido possível.

D: Então, hoje, você está compartilhando cinco maneiras pelas quais o SEO deve usar arquivos de log. Começando com o número um, vendo como o Google olha para o seu site.

1. Vendo como o Google olha para o seu site

G: Sim, o Google é bastante imprevisível, quase como uma criança rebelde. É estranho porque, embora eu diga que podemos olhar para sites e usar ferramentas de rastreamento para dar uma olhada em como o Google deveria olhar para o site, muitas vezes ficamos surpresos ao descobrir que o Google ficou obcecado com um conjunto de páginas ou indo por alguma rota estranha em algum lugar. Ou, mais recentemente, tenho trabalhado no ano passado para um supermercado chamado Odor, e uma das coisas que descobrimos foi que o bot do Google tem olhado muito para o tipo de configuração analítica e criando links artificiais a partir dela. O Google está encontrando links quebrados. E por muito tempo, eu estava tentando descobrir por que estava encontrando dezenas de 1000s de 404s que não estavam na página. Mas acontece que ele está olhando para a configuração analítica e criando um link a partir dela. Portanto, estamos analisando o impacto que isso teve. E se estivermos olhando para o fato de que o Google está encontrando todos esses 404s, isso pode não ser um grande problema. Mas agora queremos saber quanto tempo ele está gastando nesses 404s e, se corrigirmos esse pequeno problema, isso significará que o rastreamento do restante do site aumentará de 20 a 30%? Qual é a oportunidade se consertarmos isso aí? Trata-se de ver por que o Google está olhando para o site dessa maneira e o que está descobrindo que realmente não deveria estar.

2. Parâmetros

A outra coisa que muitas vezes olhamos são os parâmetros. Não sei se você sabe, mas o pessoal do SEO sempre liga para a versão canônica da página. O que quero dizer é que geralmente existem várias versões de uma página que às vezes possuem algum tipo de rastreamento interno ou externo. Existem muitas maneiras pelas quais podemos criar um link para uma página e, muitas vezes, um produto, por exemplo, pode estar em vários lugares em um site. Um bom exemplo disso é que trabalhei em um site, que era o Magento. E cada produto parecia estar em cada categoria, então foi incrível quando descobrimos que havia cerca de 20 versões de cada produto, e cada produto era rastreável. A partir daí, sabíamos que o Google também estava gastando muito tempo rastreando o site. E o que é interessante é que, se você remover um produto, o Google vai dizer "Ah, mas eu tenho 19 outras versões deste produto", então vai demorar um pouco para a página real quase desaparecer se você tiver usado um 404 ou algo parecido devido à maneira como o Google funciona. O Google verá que esta é uma versão canônica desta página. Mas se você remover a versão canônica, ela começará a usar versões diferentes. E esse é o tipo de informações que o arquivo de log nos fornece. A capacidade de olharmos para o site da maneira como o Google está.

E também nos permite olhar para coisas como códigos de status. Um ótimo exemplo disso é que há um código de status que diz que não fui modificado. E pela minha vida agora, não consigo pensar no que é, eu deveria ter escrito isso antes deste podcast. Mas, basicamente, o "não fui modificado" melhora enormemente a taxa de rastreamento de um site. E quando descubro que isso era algo que o Google estava respeitando, o que posso fazer é com todas as imagens, todos os produtos , e todos esses pedaços que não são modificados com muita regularidade, se pudermos usar um não modificado, e pudermos melhorar a velocidade de rastreamento do Google, melhorar a eficácia e reduzir a carga no servidor, podemos em seguida, melhore significativamente a maneira como o Google encontra todos os diferentes produtos.

A maneira como o Google vê as coisas, nós queremos, os administradores do servidor querem e todo mundo quer, é que o servidor seja o mais rápido e eficiente possível. Novamente, voltando ao lado dos arquivos de log, hoje em dia, não podíamos usar os arquivos de log de maneira eficaz por muitos anos. Porque com os CDNs, muitas vezes você descobriria que haveria vários lugares nos quais uma página seria acessada. E o CDN geralmente não tinha um arquivo de log próprio. Então, vamos olhar para todos esses lugares diferentes e ver quanta carga há neste servidor e quanta carga há naquele servidor. E tentamos juntar tudo e os arquivos de log estarão em um formato diferente. Agora, com CDNs, podemos realmente começar a entender a eficácia de um CDN. De repente, coisas como PageSpeed ​​são massivamente impactadas e aprimoradas pelo fato de que, se usarmos arquivos de log, podemos começar a entender o fato de que a imagem, por exemplo, por canonização de imagens, portanto, se houver uma imagem sendo usada em várias páginas, como desde que os URLs sejam consistentes, o CDN funciona e o Google o rastreia melhor. Sim, existem muitas maneiras diferentes pelas quais os arquivos de log ajudam a melhorar o PageSpeed, o armazenamento em cache e o atendimento aos usuários e mecanismos de pesquisa com muito mais eficiência.

D: Estou revisando seus cinco pontos que você iria compartilhar. E há diferentes elementos deles que você já compartilhou. Você me lembra alguém a quem posso fazer apenas uma pergunta e eles me dão um episódio de podcast de 15 minutos sem fazer mais perguntas. Portanto, há uma pessoa que provavelmente pode fazer isso, ainda mais do que você. E provavelmente é Duane Forrester. Duane e eu brincamos sobre ele fazer isso, eu apenas fazendo uma pergunta e saindo e deixando-o compartilhar o conteúdo pelo resto do episódio. Mas você falou um pouco sobre parâmetros. Não sei se você tocou no ponto número três, que é descobrir se há subdomínios que estão consumindo orçamento de rastreamento, pois não deveria haver.

3. Existem subdomínios consumindo seu orçamento de rastreamento?

G: Na verdade, isso remonta a Just Eat. A certa altura, descobrimos que o site foi replicado em vários subdomínios diferentes, e todos eles eram rastreáveis. Agora, curiosamente, eles não tinham visibilidade de acordo com ferramentas como o Citrix. E a razão pela qual eles não o fizeram foi porque tudo foi canonizado. Então, quando descobrimos que, embora essas duplicatas estivessem por aí, o Google estava gastando um pouco menos de 60 a 70% de seu orçamento rastreando esses subdomínios. E por causa da maneira como eles não eram armazenados em cache da mesma maneira por causa dos CDNs e outras tecnologias, isso estava criando muitas cargas de servidor. Portanto, foi algo fascinante para nós, porque estávamos apenas ignorando isso como um problema que precisa ser resolvido em algum momento no futuro. Porque sabíamos do problema. Sabíamos que havia um tipo de problema e eu havia falado sobre isso. Mas eu havia diminuído a prioridade até começarmos a olhar para os arquivos de log.

Vimos que o Google está gastando muita energia, tempo e recursos aqui. Quanta carga do servidor está criando? Qual foi o impacto? E não conseguíamos entender o quanto de carga do servidor era devido à maneira como o servidor não era capaz de interpretar as diferentes fontes. Portanto, foi fascinante que, quando obtivemos os arquivos de log, pudéssemos melhorar consideravelmente a confiabilidade do site. Portanto, sabíamos sobre os subdomínios, mas não sabíamos o tamanho do problema até começarmos a examinar os arquivos de log. E então, de repente, vimos que isso precisa ser consertado o mais rápido possível. Foi uma daquelas coisas que a gente soube consertar, foi só priorização. Estava no final da fila e subiu para o número dois.

4. Arquivos JavaScript e CSS

D: Você mencionou a canonização, mas também disse que, especificamente, arquivos JavaScript e CSS podem ser um problema. Por que é que?

G: Uma das coisas que costumamos fazer é quebrar o cache adicionando um parâmetro ao arquivo CSS. A razão pela qual fazemos isso é o que acontece se você usar um CDN ou algo semelhante, é que sempre que você atualiza o CSS, você está criando novas páginas, ou algo assim, então o problema é que você tem um arquivo CSS que é armazenado em cache e novas páginas não poderão usá-lo. E temos longos tempos de cache em todos esses diferentes arquivos JavaScript e CSS. Portanto, dentro da página, assim que adicionarmos algo que precise do JavaScript ou do CSS para ser atualizado, basta alterar um pouco o parâmetro dentro dele. A partir daí, o que tínhamos que garantir era que todos os diferentes servidores estavam usando a mesma versão de parâmetros daqui para frente. E isso foi algo em que, se você está trabalhando em várias equipes diferentes, vários sites diferentes, o melhor JavaScript que alimenta tudo, sempre nos certificamos de que era a versão certa. E os arquivos de log foram uma maneira de garantir que todas as páginas diferentes estivessem consistentemente atingindo a versão correta do JavaScript, porque talvez tivéssemos que atualizar uma chave de API ou algo semelhante. Havia tantas maneiras diferentes em que tínhamos que fazer isso. E isso foi uma tarefa enorme para os desenvolvedores.

Uma das coisas que estávamos olhando nos arquivos de log era se o antigo estava sendo atingido, de onde estava sendo atingido e poderíamos consertá-lo? Também descobrimos que há muitas maneiras diferentes de escrever o caminho para o arquivo JavaScript. Por exemplo, foi em um subdomínio que usamos um nome de host diferente, porque, curiosamente, se você trabalha em vários sites diferentes, geralmente descobre que existem URLs diferentes ou nomes de domínio diferentes que realmente acessam o mesmo servidor. E, frequentemente, se você estiver usando um CDN ou um subdiretório, às vezes pode ser muito inconsistente. E, do ponto de vista do usuário, se você acessar o mesmo arquivo JavaScript de seis ou sete maneiras diferentes em uma jornada, estará carregando-o de seis ou sete maneiras diferentes. E embora isso possa não parecer muito, cumulativamente, adiciona alguns megabytes à sua jornada. E isso, claro, desacelera toda a experiência e torna os servidores menos eficientes. E há muito mais nisso. Portanto, certifique-se de que a versão correta do JavaScript, CSS e outros bits e peças estejam sempre sendo atingidos. E também certifique-se de que não há motivo para o JavaScript ser ocultado com parâmetros ou algo assim. Existem muitas maneiras de criar armadilhas de aranha, que incluem os arquivos JavaScript, onde, por exemplo, algo é marcado nele, onde talvez eles não usem a referência absoluta correta para o JavaScript. Portanto, está localizado em um diretório diferente de outras vezes. É surpreendente todas as maneiras diferentes pelas quais você pode identificar quando o JavaScript está sendo carregado de maneira ligeiramente diferente por várias páginas diferentes. Então, sim, é muito simples. Mas é surpreendentemente caro quando se trata de análise.

5. Códigos de resposta

D: Também garantir que os códigos de resposta sejam entregues da maneira que você deseja. Um exemplo disso é através do TOS às vezes ser visto ou não pelo Google que deveria ou não ser. Então, por que isso aconteceria?

G: Novamente, sempre visitamos as páginas da web usando o mesmo navegador, a mesma tecnologia, a mesma experiência e tudo mais. Eu tento ter certeza de usar outras ferramentas além das que eu costumo usar, já que todo mundo faz uma auditoria do Screaming Frog, então eu tento usar todos os tipos de pedaços. Mas sempre fingimos que somos como um computador. Nunca fingimos que somos o Googlebot, nunca fingimos que somos todas essas coisas diferentes. Então, se você observar como os bots do Google acessam um arquivo específico de um endereço IP diferente... muita tecnologia como CloudFlare, se você fingir que é o Googlebot e tentar acessá-lo usando o Screaming Frog, ele saberá que você é não Googlebot, você é realmente isso. E, portanto, trata você de maneira diferente de como trataria o Googlebot. E com frequência, os servidores são configurados para pré-renderizar coisas para fazer todas as partes. E é apenas garantir que todos recebam o código de resposta correto do servidor naquele ponto.

E parece bastante simples, mas quando você está ampliando internacionalmente… Quando você tem redirecionamentos geográficos, se um usuário ou mecanismo de pesquisa não pode acessar uma página específica porque alguém colocou um redirecionamento geográfico para dizer que se você visitar este site da Espanha, então vá e carregue este subdiretório... Portanto, não pode olhar para as versões raiz ou as versões alternativas. É por isso que coisas como códigos de resposta corretos são absolutamente críticos. E é surpreendente a frequência com que você passa por essas coisas e assume que tudo está configurado corretamente. Porque uma e outra vez, sabemos como deve ser configurado. Damos isso a alguém, alguém interpreta, outra pessoa implementa e outra pessoa passa por isso. E então outra pessoa clica em um botão no CDN, que diz: "Oh, podemos geolocalizar alguém neste local específico". Não é tanto o fato de que qualquer pessoa tenha feito algo errado, mas sim que há algo na cadeia que efetivamente quebrou um pouco.

The Pareto Pickle - Frutas de baixo custo

D: Vamos terminar com o Pareto Pickle. Pareto diz que você pode obter 80% de seus resultados com 20% de seus esforços. Qual atividade de SEO você recomendaria que fornece resultados incríveis para níveis modestos de esforço?

G: O que mais gosto no momento é que tenho um painel muito básico do Google Data Studio, que me permite dar uma olhada no que chamo de fruta mais fácil de encontrar. Agora, todo mundo odeia o bingo da palavra da moda. Mas esta é a minha coisa onde eu olho para as coisas que não estão bem classificadas como deveriam. Eu olho para todas as palavras-chave onde elas estão classificadas para um determinado conjunto de páginas, ou receitas, ou produtos, ou algo assim. Um bom exemplo é que, no momento, estou trabalhando em dezenas de milhares de produtos, vejo todas as páginas com altas impressões, mas pode haver na posição seis e posso trabalhá-las até a posição 3. E nove em cada dez vezes você pode fazer isso apenas certificando-se de que as tags de título melhoraram e os links internos melhoraram. Coisas muito simples para descobrir quais palavras-chave com alto volume de pesquisa podem ser aumentadas um pouco mais para aumentar a taxa de cliques.

D: Eu fui seu anfitrião, David Bain. Você pode encontrar Gerry pesquisando Gerry White no LinkedIn. Gerry, muito obrigado por estar no podcast In Search SEO.

G: O prazer é meu. Obrigado pelo seu tempo.

D: E obrigado por ouvir. Confira todos os episódios anteriores e cadastre-se para um teste gratuito da plataforma Rank Ranger.