Horário de Atendimento SEO – 8 de outubro de 2021

Este é um resumo das perguntas e respostas mais interessantes do Google SEO Office Hours com John Mueller em 8 de outubro de 2021.

O número de páginas indexadas versus autoridade do site

03:52 “Então você recomendou várias vezes no passado que sites grandes […] foquem em um conjunto menor de páginas […]. O site em que estou trabalhando agora, temos […] tipo 1.000 páginas que não recebem nenhum tráfego, que são antigas, então tenho recomendado removê-las. Mas há uma pergunta que nossa equipe de desenvolvimento tem de que eles estavam com a impressão de que quanto mais páginas o Google indexava do seu site, maior autoridade ele atribui ao site e são reticentes em remover quaisquer páginas. Você poderia lançar alguma luz sobre isso?”

Como John disse: “Definitivamente, não é o caso que, se você tiver mais páginas indexadas, achamos que seu site é melhor. […] Às vezes, faz sentido ter muitas páginas indexadas. Às vezes, são páginas úteis para serem indexadas assim. Mas não é um sinal de qualidade em relação a quantas páginas são indexadas. E especialmente se você estiver falando de […] 1.000, 2.000, 5.000 páginas, esse é um número bem baixo para nossos sistemas em geral. E não é que diríamos que 5.000 páginas são melhores que 1.000 páginas. Para nós, é como, bem, é um pequeno site, e nos contentamos com o que podemos extrair lá. E, claro, site pequeno é relativo. Não é como dizer que é um site irrelevante. Pode ser pequeno, mas ainda pode ser muito útil [...]”.

Avaliando o objetivo principal de um site

10:03 “Na última vez, falamos sobre alguns problemas com o site […] – é um site de comércio eletrônico onde temos material informativo e material transacional. […] Seu conselho foi separar um pouco esse conteúdo em páginas orientadas a transações e páginas orientadas a informações. Então eu tenho outra pergunta sobre isso. Se você tem, digamos, um site de comércio eletrônico, e você tem um blog enorme, ou uma revista, ou algo assim onde você tem um monte de material informativo, mas é uma seção antiga. E, por outro lado, você tem todas essas páginas de produtos, categorias e assim por diante. Então, esse enorme bloco com material puramente informativo daria a todo o site um toque ou caráter informativo para que o Google dissesse, ah, não temos certeza se isso é […] algo em que as pessoas podem obter informações em vez de comprar coisas, ou é essa avaliação feita em uma base por página?”

John disse: “[…] Meu entendimento é que isso é mais uma coisa no nível da página. […] Muitos sites têm apenas uma mistura de diferentes tipos de conteúdo. E então você tenta descobrir quais dessas páginas correspondem à intenção do pesquisador e tenta classificá-las adequadamente. […]

Quero dizer, você vê isso com frequência em sites de notícias. […] Eles têm os eventos recentes, mas também têm seções para eventos mais antigos que aconteceram, ou […] para outros grandes eventos, eles meio que têm uma seção de arquivo isolada. E essas são intenções muito diferentes, se você quer algo realmente agora que está acontecendo ou se você quer algum tipo de pesquisa informativa, conteúdo do tipo evergreen.

[…] Nós meio que temos que olhar para ele em uma base por página , e não dizer, oh, este é um site de pesquisa porque há algum conteúdo de pesquisa aqui”.

Redirecionamento de links

13:21 “Estamos vendo que as pessoas estão linkando […] nossa, digamos, subcategoria de páginas. E o problema é que […] nosso conteúdo vem e vai, o que significa que, às vezes, há mais conteúdo aparecendo em algumas categorias. Às vezes, o conteúdo é excluído. E assim subcategorias podem ser criadas e podem desaparecer também. E estamos vendo um monte de referências de backlinks porque estão linkando para subcategorias que não existem mais. Minha pergunta aqui é: tudo bem redirecionar […] esses links para a categoria pai. E se fizermos isso, como faremos isso – com 302, por exemplo? Como um redirecionamento temporário, porque no futuro essa subcategoria pode voltar a ser preenchida com conteúdo, […] não é um redirecionamento permanente”.

John respondeu: “Então, se virmos isso acontecendo em uma escala maior que você redireciona para o nível pai, provavelmente veríamos isso como um soft 404. […] E em vez de um código 404, você está redirecionando, e talvez seja melhor para os usuários, mas nós vemos isso como um 404. […] Se fizer sentido do ponto de vista do usuário para redirecionar, então eu iria em frente.

[…] Com relação ao 301 ou 302, acho que não importa lá, porque ou veríamos isso como um 404 suave, ou veríamos como uma questão de canonização. Se for um soft 404, o código não importa. Se for uma pergunta de canonização, tudo se resume a qual URL mostramos nos resultados da pesquisa. E geralmente, o de nível superior terá sinais mais fortes de qualquer maneira, e nos concentraremos no de nível superior. Então não importa se é um 301 ou um 302 nesse caso.

[…] Se o virmos como um soft 404, […] diminuiríamos o rastreamento desse URL específico porque não há nada aqui […]. Se o vemos como um redirecionamento […], não precisamos rastreá-lo todos os dias, pois nos concentramos no URL principal. Então, acho que em ambos os casos, diminuiríamos o rastreamento desse URL até obtermos novos sinais que nos informassem, na verdade, que talvez isso seja algo novo novamente. […] Isso seria como um link interno, ou arquivo de mapa do site […]. E esse seria o sinal mais forte para rastejarmos novamente. Mas acho que a desaceleração do rastreamento seria semelhante em todos esses casos.

[…] Acho que [atualizar] os mapas do site por si só provavelmente não é suficiente. Eu realmente me certificaria de que a ligação interna também seja clara ”.

Recuperação de atualizações principais

18:34 “Então, cerca de um ano atrás, vimos uma diminuição significativa no tráfego. Após a auditoria, […] todos os sinais apontavam para o site com problemas de qualidade do site. Conseguimos resolver esses problemas até fevereiro deste ano. E na atualização principal de junho, vimos alguns aumentos. Mas ainda não está no nível em que estávamos antes da queda de cerca de um ano atrás. Então, minha pergunta é sobre os problemas de qualidade do site, se esse for o caso, essa é a recuperação que podemos esperar ou podemos esperar mais recuperação se acharmos que resolvemos todos os problemas identificados […]?”

John disse: “[…] Não é tanto que consideremos isso como uma situação em que você tem que consertar alguma coisa. Mas, em vez disso, […] se você trabalhar para melhorar a relevância do seu site, […] você terá um site melhor. Então não é que [...] vamos mudar para o estado anterior. […] Não é o mesmo ou comparável a antes, então seria meio complicado esperar que ele mude para o estado que era antes […].

[…] Com as atualizações principais, não focamos apenas em questões individuais, mas sim na relevância do site como um todo . E isso pode incluir coisas como a usabilidade e os anúncios em uma página, mas é essencialmente o site em geral. E geralmente, isso também significa o foco do conteúdo, a maneira como você está apresentando as coisas, a maneira como você está deixando claro para os usuários o que está por trás do conteúdo, como quais são as fontes […] . Se você realmente deseja que o Google veja seu site como algo significativamente melhor, provavelmente também precisará trabalhar no lado do conteúdo .

[…] Pense em onde pode haver conteúdo de baixa qualidade, onde os usuários podem ficar confusos quando acessam meu site. E essa confusão é algo que podemos resolver com questões técnicas, com mudanças de UX? Ou realmente temos que mudar parte do conteúdo que apresentamos?”

Links em postagens de convidados

28:24 “[…] Se [um site tem] um guest post, e o Google não sabe se é pago ou não, como o Google irá determinar que [eles devem] pegar este link ou gravar este link? Qual é a resposta para que estejamos seguros de todos os ângulos?”

De acordo com John, “[…] Nossa orientação para links e guest posts é que eles não devem ser seguidos . […] Eu realmente tomaria cuidado para ter certeza de que os links são no-follow para que você promova a conscientização, você esteja falando sobre o que você está fazendo, você esteja fazendo isso para que os usuários possam ir para o seu página. Mas, essencialmente, é um anúncio para o seu negócio. Então, desse ponto de vista, eu apenas os faria no-follow”.

Preço do produto como fator de classificação

32:25 “Se houver dois sites de comércio eletrônico concorrentes que vendem exatamente o mesmo produto – um site oferece o produto por US$ 500, o outro por US$ 100, todos os sinais de SEO são iguais. O site mais barato teria uma chance melhor de classificação porque há uma diferença de preço para o mesmo produto?”.

John disse: “Então, puramente do ponto de vista da pesquisa na web, não. Não é o caso de tentarmos reconhecer um preço em uma página e usá-lo como um fator de classificação. Portanto, não é o caso de dizermos que vamos pegar o mais barato e classificá-lo mais alto […].

No entanto, muitos desses produtos também acabam nos resultados da pesquisa de produtos, o que pode ser porque você enviou um feed ou porque reconhecemos as informações do produto nessas páginas. E os resultados da pesquisa de produtos, não sei como eles são ordenados. Pode ser que levem em conta o preço ou coisas como disponibilidade [...].

Portanto, do ponto de vista da pesquisa na web, não levamos em consideração o preço. Do ponto de vista da pesquisa de produtos, é possível . E a parte complicada, eu acho, como um SEO é que esses diferentes aspectos da pesquisa geralmente são combinados em uma página de resultados de pesquisa, onde você verá resultados normais da Web e talvez veja alguns resultados de produtos ao lado, ou talvez você verá uma mistura disso […]”.

Movendo URLs entre sitemaps

34:04 “Se tivermos 200 arquivos de sitemap e 20% a 30% dos URLs pulam de um arquivo para outro toda semana, quão ruim pode ser? Ou devemos manter estritamente nossos URLs no mesmo arquivo para sempre?”

“[…] Nossa recomendação geralmente é manter a mesma URL no mesmo arquivo de mapa do site . A principal razão para isso é que processamos arquivos de mapa do site em taxas diferentes. Portanto, se você mover um URL de um arquivo de mapa de site para outro, pode ser que tenhamos o mesmo URL em nossos sistemas de vários arquivos de mapa de site. E se você tiver informações diferentes para este URL – como datas de alteração diferentes, por exemplo – então não saberíamos qual atributo usar de fato.

Então, desse ponto de vista, se você o tiver sempre no mesmo arquivo de mapa do site, é muito mais fácil para nós dizermos, ah, temos as informações para esse URL aqui e podemos confiar nessas informações porque elas estão apenas lá. Então, isso é algo em que eu tento evitar […] esses URLs embaralhando aleatoriamente. Mas, ao mesmo tempo, geralmente não interromperá o processamento do seu arquivo de mapa do site. E definitivamente não terá um efeito de classificação em seu site. Portanto, não há nada em nosso sistema de mapa do site que mapeie a qualidade de um site ”.

Conteúdo multirregional

38:13 “Trabalho na vertical de notícias. Minha equipe está procurando expandir nossa presença internacional e trabalhou para configurar subdiretórios multirregionais. Na maioria das vezes, as páginas nas diferentes edições multirregionais terão a mesma aparência. Páginas iniciais e de seção, como política ou estilo de vida, terão conteúdo semelhante, menos algumas peças exclusivas da região.

Os artigos são complicados. Não há muito que possamos diferenciar nos subdiretórios multirregionais fora dos módulos com links relacionados, o que nos deixa preocupados com problemas de conteúdo duplicado. Como o Google lida com conteúdo duplicado no espaço de notícias? […] O conteúdo permanece o mesmo, mas os elementos do template são diferentes. Deve haver apenas um canônico em todos os sites multirregionais?”

A resposta de John foi: “[…] Parece que são regiões diferentes dentro do mesmo país, e é o mesmo conteúdo linguístico. […] Se são países diferentes, então você tem o aspecto de segmentação geográfica, que desempenha um papel se forem idiomas diferentes. Então, se você está trabalhando, digamos, na Europa, e está cobrindo a Alemanha, a França e a Itália, ou algo assim, você também tem idiomas diferentes.

[…] Mas se você está falando dentro do mesmo país, mesmo conteúdo de idioma, então […] é um pouco mais fácil porque você não precisa se preocupar com todas essas conexões técnicas. Mas, por outro lado, os problemas de conteúdo duplicado são muito mais visíveis. E quando se trata de conteúdo duplicado, o aspecto complicado em sites como esses é que você basicamente acaba competindo consigo mesmo. E se você tiver um artigo de notícias publicado em cinco ou seis sites regionais diferentes, todos esses sites regionais diferentes tentarão classificar exatamente o mesmo artigo. E isso pode resultar em que o artigo não seja classificado tão bem quanto poderia.

Então, por causa disso, eu recomendaria tentar encontrar URLs canônicos para esses artigos individuais para que você possa realmente dizer 'bem, eu tenho este artigo em meus cinco sites regionais, mas esta é a minha versão preferida que eu quero ver em procurar'. E então podemos concentrar toda a nossa energia, todos os nossos sinais, naquela versão preferida, e podemos tentar classificá-la um pouco melhor. Não precisa ser sempre a mesma versão. Então, definitivamente pode ser o caso de você ter um artigo de notícias que está dentro de uma região meio que canônico, um artigo de notícias diferente é mais canônico para outra região. Como você escolhe qual região você escolhe como canônica é totalmente com você. […] Normalmente, você tentaria descobrir onde é o mais relevante, e escolheria aquele como a versão canônica. Então isso é para os próprios artigos individuais.

Para as categorias, as seções e as páginas iniciais, parece que seria algo em que o conteúdo é mais exclusivo e mais específico para as regiões individuais. E por causa disso, eu tentaria manter esses níveis de índice separados. Portanto, se você tiver cinco sites regionais diferentes, sua página inicial, suas seções de categoria, todos eles serão indexados individualmente. E os próprios artigos de notícias seriam mapeados para uma dessas diferentes regiões. Então esse é o tipo de abordagem que nós recomendamos lá […].

E essa abordagem também […] funciona em diferentes nomes de domínio. Portanto, se você tiver domínios diferentes para regiões individuais, mas tudo fizer parte do mesmo grupo de notícias, ainda poderá fazer essa mudança canônica nas diferentes versões. Se você estiver fazendo isso dentro do mesmo domínio com subdiretórios, tudo bem também”.

Redirecionamento em uma mudança de site

44:34 “Qual é o melhor curso de ação a tomar quando você precisa redirecionar 301 todos os URLs para um novo conjunto de URLs? O número de páginas será superior a um milhão e você deseja minimizar o efeito sandbox? Se houver um efeito sandbox, quanto tempo pode durar? Perderíamos uma classificação que talvez nunca mais recuperássemos? Planejamos fazer um redirecionamento um para um e solicitamos redirecionamentos em lote, mas isso não é uma possibilidade, então páginas, imagens, URLs etc. teriam que virar ao mesmo tempo”.

Como John disse: “Para mim, isso soa como uma situação tradicional de mudança de site. Você muda de um domínio para outro e redireciona todos os URLs do seu site antigo para um novo, e nós temos que lidar com isso […]. Definitivamente, não há nada definido como um efeito sandbox do nosso lado quando se trata de mudança de site . Portanto, se você precisar fazer uma mudança de site, faça uma mudança de site e redirecione todas as suas páginas. Muitas vezes, a abordagem mais fácil é redirecionar todas as páginas de uma só vez. Nossos sistemas também estão um pouco sintonizados com isso para tentar reconhecer isso. Então , quando vemos que um site começa a redirecionar todas as páginas para um site diferente, tentaremos reprocessá-lo um pouco mais rápido para que possamos processar essa mudança de site o mais rápido possível. E definitivamente não é o caso de dizermos, ah, eles estão fazendo uma mudança de site, portanto, vamos desacelerar as coisas […]”.

API e orçamento de rastreamento

46:13 “Eu tenho um site que se conecta a APIs no lado do cliente para obter dados. Esses URLs estão sendo incluídos no orçamento de rastreamento? Se você não permitir esses URLs, […] isso criaria algum problema?”

“[…] Se essas APIs forem incluídas quando uma página for renderizada, sim, elas serão incluídas no rastreamento e contarão para o seu orçamento de rastreamento essencialmente porque temos que rastrear esses URLs para renderizar a página. Você pode bloqueá-los pelo robots.txt se preferir que eles não sejam rastreados ou não sejam usados ​​durante a renderização. Totalmente até você, se você preferir fazer isso. Especialmente se você tiver uma API que é meio cara de manter ou consome muitos recursos, às vezes isso faz sentido.

A parte complicada, eu acho, é que se você não permitir o rastreamento do seu endpoint da API, não poderemos usar nenhum dado sobre os retornos da API para indexação. Portanto, se o conteúdo da sua página vier exclusivamente da API e você não permitir o rastreamento da API, não teremos esse contato. […] Se a API apenas faz algo complementar à página, como talvez desenhar um mapa ou […] um gráfico de uma tabela numérica que você tem em uma página, […] então talvez não importe se esse conteúdo é 'não incluído na indexação. A outra coisa é que, às vezes, não é trivial como uma página funciona quando a API está bloqueada. Em particular, se você usar JavaScript e as chamadas de API forem bloqueadas por causa do robots.txt, você terá que lidar com essa exceção de alguma forma. E dependendo de como você incorpora o JavaScript na página, o que você faz com a API, você precisa ter certeza de que ainda funciona. Portanto, se essa chamada de API não funcionar e o restante da renderização da página for interrompido completamente, não poderemos indexar muito porque não há mais nada para renderizar.

No entanto, se a chamada da API for interrompida e ainda pudermos indexar o restante da sua página, isso poderá ser perfeitamente adequado. […] Acho que é mais complicado se você executar uma API para outras pessoas, porque se você não permitir o rastreamento, você terá esse efeito de segunda ordem de que o site de outra pessoa pode depender da sua API. E dependendo do que sua API faz, de repente, o site deles não tem conteúdo indexável. E eles podem nem perceber porque não estavam cientes de que, de repente, você adicionou uma proibição lá. E isso pode causar efeitos indiretos [...]”.

JavaScript e cache do Google

49:36 “Então, existem duas páginas que se originam do mesmo domínio. A URL é um pouco diferente, que faz parte da mesma estrutura de diretórios. E […] eles são gerados pelo NextJS. Portanto, o NextJS é uma estrutura de reação renderizada no lado do servidor. E eles estão sendo indexados, mas vejo uma página no cache do Google e a segunda página não está no cache do Google. E eu vejo o mesmo padrão independente de como eu gero a página [...]. A maioria das minhas páginas está no cache do Google, mas agora estou preocupado porque estou migrando da minha pilha de tecnologia baseada em Java, que gera todas essas páginas, para o Google NextJS. […] Quando eu estava depurando, descobri que isso também é um problema com a pilha Java mais antiga que estávamos usando.

Então a questão tem duas partes. Basicamente, por que esse comportamento? E a segunda é, esse comportamento afetará minha classificação? Eu vejo essas páginas aparecendo nos resultados de pesquisa que não estão no cache do Google”.

John respondeu: “[…] As páginas de cache são completamente separadas do que indexamos. Portanto , se houver uma página de cache ou não, isso não importa para a classificação, não importa para a indexação . Às vezes, existem razões técnicas pelas quais não temos uma página de cache. Às vezes, simplesmente não temos uma página de cache para URLs individuais. A outra coisa é que, se a página estiver usando uma estrutura JavaScript, se o JavaScript é executado ou não em uma página de cache às vezes é complicado, porque a página de cache está hospedada em um domínio do Google. Dependendo do tipo de JavaScript que você possui, de onde ele puxa os arquivos JavaScript, às vezes, o JavaScript não pode ser executado no domínio do Google.

[…] A página de cache não é a página renderizada. É essencialmente apenas o arquivo HTML que solicitamos e uma cópia dele. E se o arquivo HTML mostrar algo, tudo bem. Se ele usa JavaScript e o JavaScript não é executado porque é uma página de cache, tudo bem. Você simplesmente não o vê na página de cache. Portanto, se a página de cache não aparecer, eu não me preocuparia com isso. Isso não é sinal de qualquer problema. E muitas vezes, […] você não pode controlar se há uma página de cache ou não. Eu simplesmente ignoraria isso”.

https://www.youtube.com/watch?v=Vd0rEQrwHDc