Horário de atendimento SEO, 4 de março de 2022
Publicados: 2022-03-22Este é um resumo das perguntas e respostas mais interessantes do Google SEO Office Hours com John Mueller em 4 de março de 2022.
Testando a marcação de esquema no validador do schema.org vs. no Google Search Console
7:41 “John, então minha primeira pergunta é, o Google Search Console está lançando um erro […] no elemento de dados estruturado necessário. Mas quando eu verifico o mesmo em validator.schema.org, ele não mostra nenhum aviso ou erro. Portanto, a primeira pergunta é: é o site certo para verificar a implementação de AMP de uma página da Web? […]“
John respondeu: “ Sim, então essas ferramentas de teste são para propósitos ligeiramente diferentes. Provavelmente é por isso que você está vendo essa diferença. A ferramenta de teste no schema.org é mais sobre como entender a marcação do schema.org em geral, como em geral, com base nos requisitos que o schema.org possui. E a ferramenta de teste no Search Console é focada exclusivamente no que podemos extrair dos dados estruturados e usar para mostrar no recurso de pesquisa. Portanto, está realmente focado na parte de pesquisa dessa história. E na Pesquisa, usamos apenas uma pequena parte da marcação schema.org. E, às vezes, temos requisitos ligeiramente diferentes que talvez exigimos um elemento específico mais do que a marcação base schema.org exigiria. E é muitas vezes por isso que você vê essa diferença. E o validador do schema.org é para a marcação teórica, e o validador do Google é realmente para o lado prático da Pesquisa do Google. “
9:20 “[…] Basicamente, não é um erro. É um aviso no Search Console. E quando eu verifico os detalhes no Search Console, ele apenas diz que você não está fazendo certo. Então, haverá uma maneira possível [para corrigir o problema] ou minha equipe de desenvolvimento deve descobrir isso?
John explicou: “Sim, se for um aviso, então eu não me preocuparia com isso. É basicamente apenas dizer que você poderia ter feito algo diferente. […]. O que eu faria se você quiser descobrir qual é exatamente a diferença é verificar novamente a documentação em developers.google.com para Pesquisa, onde temos todos os dados estruturados documentados e todos os campos obrigatórios e recomendados. E provavelmente um dos campos recomendados ou opcionais é o que está acionando esse aviso.”
Motivos pelos quais uma página pode ser rastreada, mas não indexada
14:11 “ Qual é a possível razão pela qual […] certas páginas não foram indexadas, mesmo tendo sido rastreadas várias vezes? ”
João respondeu: “ Pode acontecer. Eu diria que não é tão frequente porque, geralmente, quando decidimos rastrear algo, também ficamos muito felizes em ir indexá-lo. Mas pode acontecer de rastrearmos uma página e, no final, decidirmos, na verdade, que não precisamos indexá-la.
[…] algumas situações comuns em que isso pode acontecer, que talvez não se apliquem no seu caso, é se houver um código de erro na página. Temos que rastreá-lo primeiro e, em seguida, vemos o código de erro. Se houver um noindex na página, também precisamos rastreá-lo primeiro e, em seguida, veremos o noindex. Se a página for uma duplicata completa de outra coisa que já vimos, então a rastreamos, vemos que é uma duplicata, mas focamos na página principal novamente. Então, essas são as situações normais em que rastreamos algo e não o indexamos. Mas também pode acontecer de rastrearmos algo e, quando chegarmos à indexação, decidirmos, ah, bem, na verdade, queremos obter outra coisa do site. ”
15:41 “[…] que outros fatores [além dos já mencionados] podem fazer com que o Googlebot decida, ah, não queremos indexá-lo no final?”
John disse: “Não sei de imediato. Acho que a qualidade geral do site definitivamente desempenha um papel nisso, mas geralmente, se não estivermos convencidos sobre a qualidade do site, provavelmente não rastrearíamos a página em primeiro lugar. Então essa é, eu acho, uma situação complicada. E se você procurar no Search Console, acho que, praticamente para todos os sites, você terá o agrupamento de descobertos, mas não indexados e também rastreados e não indexados. Isso é, eu acho, bastante comum em todos os sites.”
A pessoa que fez a pergunta queria saber se há algo mais que eles deveriam analisar, exceto qualidade da página e problemas técnicos. John recomendou que eles não se concentrassem muito em uma página: “ Também acho importante não focar demais nessa página específica. Então, se você tem certeza de que, do ponto de vista técnico, está tudo bem, eu não assumiria que a qualidade dessa página específica é um problema, mas sim a qualidade percebida dessa parte do site ou do próprio site inteiro. Esse é o tipo de lugar onde eu tentaria ver o que você pode fazer para melhorar as coisas, não apenas aquela página individual que não foi indexada, mas qual é a imagem maior em torno dessa página. ”
A remoção de listagens de produtos em um site de comércio eletrônico pode colocá-lo em desvantagem?
21:48 “ Então, administramos um site de comércio eletrônico e agora estamos em um estágio em que queremos fazer grandes atualizações em nossas páginas de categorias. […] em um rascunho, queremos nos livrar das listagens de produtos. Então você tem as listagens de produtos com a busca facetada, onde você pode filtrar pelos produtos que procura. […] quando removemos toda a lista de produtos das páginas de categorias, teríamos uma desvantagem nos rankings porque, primeiro, todos os outros concorrentes têm esses tipos de listas de produtos? E segundo, meu palpite é que esse é um elemento tão estabelecido para páginas de comércio eletrônico que os usuários esperam […] ter algum tipo de visão geral de todos os produtos e os filtros permitem que eles pesquisem os produtos que desejam. ”
John respondeu: “ Eu não veria nenhum problema do ponto de vista de SEO. Eu acho que há coisas diferentes que você gostaria de observar, […] para que ainda possamos encontrar todos os produtos individuais que temos links limpos lá. Mas se você está apenas redesenhando esta página de categoria e fazendo com que pareça mais uma página informativa, eu não esperaria nenhum problema com isso. Também acho que não fazemos nada de especial com esses tipos de páginas de categoria na Pesquisa, então, desse ponto de vista, você está apenas alterando o design, essencialmente.
Acho que seria diferente se fosse uma página de produto e você a alterasse completamente porque tentamos reconhecer as páginas de produtos e descobrir onde está o preço, onde está a disponibilidade , esse tipo de coisa. E se você fez com que parecesse completamente diferente […], posso imaginar que isso afeta a forma como selecionamos as páginas do produto e se podemos exibi-lo nos resultados da Pesquisa de produtos ou não. Mas as páginas de categorias, que eu saiba, não fazemos nada de especial com elas. Então, se você escondê-los, essencialmente, e se certificar de que ainda podemos encontrar os links para os produtos […], você pode fazer isso. Mas se você quiser torná-los mais úteis fornecendo mais informações sobre eles, acho que é uma boa ideia.”
No final da pergunta, John acrescentou que é importante verificar as mudanças na perspectiva do usuário : “[…] você mencionou 'os usuários ficariam confusos'. Eu verificaria isso duas vezes. Então, do lado do SEO, acho que está perfeitamente bem, mas do lado do usuário, provavelmente é algo que você gostaria de testar primeiro.”
A importância da estrutura de links internos
25:18 “ Se você tiver dados estruturados para configuração de breadcrumbs, os links internos ainda são importantes para SEO?”
John respondeu: “Sim, absolutamente. É algo em que links internos são supercríticos para SEO. Acho que é uma das maiores coisas que você pode fazer em um site para guiar o Google e guiar os visitantes para as páginas que você considera importantes. E o que você acha que é importante depende totalmente de você. Você pode decidir tornar as coisas importantes onde você ganha mais dinheiro, ou você pode tornar as coisas importantes onde você é o concorrente mais forte, ou talvez você seja o concorrente mais fraco. Com links internos, você pode realmente focar as coisas nessas direções e nessas partes do seu site. E isso não é algo que você pode simplesmente substituir por dados estruturados.
Então, só porque há dados estruturados em uma página em algum lugar, eu não veria isso como um substituto para links internos normais. Mesmo que nos dados estruturados você também forneça URLs, não usamos esses URLs da mesma forma que usaríamos links internos normais em uma página. Portanto, definitivamente não é o caso que as anotações hreflang substituem os links entre as versões do país ou as anotações breadcrumb substituem os links entre os diferentes níveis de um site. Você realmente deve ter links HTML normais entre as diferentes partes do seu site. E, idealmente, você não deve ter apenas um conjunto básico de links, mas sim, você deve olhar para ele de forma estratégica e pensar sobre o que mais lhe interessa, e como você pode destacar isso com seu link interno? ”

Vários esquemas de produtos na página de listagem de produtos
29:50 “ Para uma página de listagem de produtos, podemos implementar vários esquemas de produtos na página de listagem de produtos? ”
John disse: " Do nosso ponto de vista da política, acho que você não deveria fazer isso, pelo menos na última vez que verifiquei as políticas sobre dados estruturados, porque para dados estruturados de produtos, realmente queremos que isso se aplique ao principal elemento da página. E se você tiver vários produtos em uma página, não é que um deles seja o elemento principal da página. Portanto, desse ponto de vista, você não deve usar vários elementos de dados estruturados de produtos em uma página de categoria […]. ”
Seus rankings podem sofrer se você criar páginas em vários idiomas?
30:30 “ Existe uma prática recomendada para páginas com idioma misto usado? Por exemplo, nossa escola internacional no Japão atende famílias japonesas e não japonesas, mas mantemos a maioria das informações em nossa página inicial em inglês. Também adicionamos suporte na página em japonês. […] Como nossa comunicação na vida real é uma linguagem mista, ter a página inicial refletindo isso parecia mais natural. Somos punidos na pesquisa se uma página for um idioma intencionalmente misturado?”
John respondeu: “Eu não diria necessariamente que uma página é punida em um caso como esse. Mas tentamos entender qual é o idioma principal de uma página, e isso nos ajuda a entender para que tipo de consultas poderíamos mostrar esta página. Então isso, eu acho, é meio complicado em um caso como esse.
Também podemos entender quando há vários idiomas em uma página. Apenas torna muito mais fácil para nós realmente deixarmos claro que, se alguém estiver pesquisando em inglês, esta é a página certa para mostrar a eles. Então eu poderia imaginar algo como uma home page, talvez faça sentido ter essa mistura ou uma pequena mistura. Se você tiver uma página inicial como inglês primário, talvez inclua alguns elementos em japonês. Se você tiver outra versão que seja principalmente japonesa, com alguns elementos em inglês, tudo bem. Mas nos ajuda a realmente entender que, na maioria das vezes, esta é uma página em inglês. E se alguém estiver pesquisando em inglês por um tipo específico de escola internacional no Japão, faz sentido dizermos, bem, aqui está um conteúdo em inglês que sabemos que atende às suas necessidades e que corresponde às consultas que você nos deu. Então, desse ponto de vista, eu não diria necessariamente que a página é punida, mas torna muito mais difícil para nossos sistemas descobrir como classificar essa página corretamente.
Uma das coisas em que você pode pensar aqui é procurar no Search Console quais consultas estão indo para seu site ou para sua página inicial. E pense em quais dessas consultas podem ser afetadas se o Google não entender o idioma corretamente. E pode ser que, se a maioria das pessoas estiver pesquisando seu nome ou a marca de sua escola, essencialmente, provavelmente isso não será afetado. Por outro lado, se a maioria das pessoas estiver pesquisando por consultas mais amplas, consultas mais genéricas, quase como uma frase que corresponderia a algo em sua página inicial, eu poderia imaginar que seria um pouco mais difícil para você aparecer nos resultados de pesquisa para , só porque não temos certeza se sua página inicial está realmente nesse idioma dessa consulta […].
Uma coisa que você também pode fazer, […] é tornar sua página inicial uma versão bilíngue […], mas criar páginas separadas adicionalmente para o idioma individual para que, se alguém estiver procurando por informações longas sobre uma escola internacional isso, eles ainda podem encontrar aquelas páginas em inglês puro ou principalmente em inglês e, a partir daí, fazer a transição para o resto do seu site […].
Diferenças de conteúdo entre as versões móvel e desktop
34:20 “ Se houver uma diferença entre o conteúdo na versão mobile e desktop, isso significa que o Google punirá o site e afetará a classificação do site, ou significa simplesmente que o Googlebot pode encontrá-lo na versão mobile, mas ganhou não ser capaz de classificar? ”
John disse: “ Então, na maioria das vezes, mudamos a maior parte de nossa indexação para a indexação mobile-first, o que significa que só olharíamos para a versão mobile de um site em um caso como esse. Então, essencialmente, se houver algo um pouco diferente na versão para desktop de um site, na maioria das vezes, nem usaríamos isso para a Pesquisa. Então, não é que puniríamos um site por causa de uma diferença, mas sim, apenas olhamos para uma versão do site e nem sabemos o que está na outra versão para tratá-la de maneira diferente .
E para o punhado de sites que ainda estão na indexação de desktop, isso se aplica ao contrário. Claro, se houver […] algo na versão móvel que não está na versão desktop, e você está sendo indexado pelo rastreador de desktop, então não veríamos isso. Rastreamos a versão alternativa de tempos em tempos, mas não a rastreamos para coletar mais informações, mas apenas para confirmar se existe essa conexão entre o URL para computador e o URL para dispositivos móveis. ”
Você pode hospedar seu sitemap em uma nuvem?
46:20 “ Temos uma página realmente enorme com milhões de URLs, e […] os sitemaps estão sendo renovados. E nossa equipe de TI está pensando em armazenar […] os novos arquivos de mapa do site em nosso serviço de nuvem. Isso significa de example.com/sitemaps para cloud.com/sitemaps. E estamos nos perguntando, isso é um problema se armazenarmos os mapas do site na nuvem? E se isso não for um problema, devemos também criar um redirecionamento permanente para a URL antiga deste exemplo.com/sitemap, ou como devemos planejar a mudança? ”
John disse: “ É definitivamente possível hospedar o arquivo de mapa do site em outro lugar. Existem duas maneiras que você pode fazer isso. Uma é se você tiver esses dois domínios verificados no Search Console, isso funcionará. A outra maneira é se você enviá-lo com o arquivo robots.txt, onde você especifica 'sitemap:' e, em seguida, o URL do sitemap. Isso também pode ir para um domínio diferente. […] Eu também redirecionaria o arquivo de mapa do site antigo para o novo local apenas para ficar limpo, mas provavelmente mesmo se você apenas excluir o URL do mapa do site antigo e certificar-se de enviar o novo corretamente, isso deve funcionar.
O que pode ser um pouco complicado é que não sei como o Search Console mostraria isso diretamente na interface do usuário, em particular, se o arquivo de mapa do site estiver em um local diferente, se o Search Console mostrar as informações do mapa do site no relatório de indexação, por exemplo. Mas isso é um problema de reportagem. Isso não é algo que depende da funcionalidade do arquivo de mapa do site. É realmente apenas que o Search Console não mostra isso corretamente. E, novamente, talvez sim. Só não tenho 100% de certeza. ”
O histórico de um domínio pode afetar seu site?
49:40 “[…] Então [durante o SEO Office Hours anterior ] fizemos essa pergunta sobre domínio com histórico como provedor de serviços de acompanhantes. […] o domínio tem uma longa história porque o primeiro instantâneo desse site é de 1997. […] relançámos o nosso site em junho do ano passado […]. E o principal problema que estamos tendo é […] que ainda estamos sendo sinalizados [como conteúdo adulto]. E, além disso, temos esse problema […] – rastreado, atualmente não indexado. E estamos tentando entender se o histórico do domínio pode realmente afetar que estamos tendo problemas com a indexação. […] acreditamos que o conteúdo que estamos publicando é de boa qualidade. Está internamente vinculado e tentamos construir um site de qualidade. Onde nós lutamos no momento é o desempenho da página, então está em andamento no momento para otimizar para isso. Mas usamos prerender.io , então o que mostramos para o Google já é uma versão pré-renderizada. Então, quando se trata da nossa pontuação do Lighthouse, tudo é bom. […] O que podemos melhorar ou buscar para entender por que não estamos sendo indexados? Fico feliz em compartilhar o URL também. “
John ofereceu que ele poderia dar uma olhada no URL mais tarde, e então ele respondeu: “ Geralmente, o lado da indexação das coisas não estaria relacionado se havia conteúdo adulto no site antes.
O lado da indexação pode ser afetado se o conteúdo que estava lá antes fosse muito spam. Então, isso pode ser algo em que, do ponto de vista da indexação, demore um pouco para descobrir, oh, esse novo site na verdade não é spam.
Mas se fosse apenas que havia conteúdo adulto lá antes, eu poderia imaginar que talvez nossos filtros SafeSearch sejam um pouco lentos em reconhecer isso. Eu sei que tomamos algumas medidas para tornar isso mais rápido […], ou talvez haja algo mais no SafeSearch que esteja travando.
O lado do SafeSearch é algo que você pode verificar se fizer uma consulta no site e, em seguida, ativar e desativar o SafeSearch. Você deve ser capaz de ver se algo do SafeSearch está acontecendo ou não. Você não vê isso com relação à indexação, no entanto. Mas posso dar uma olhada nisso depois, e podemos ver se há algo super óbvio que posso informar a você. ”
