8 de março de 2019 – Notas do Hangout da Ajuda do Google

Esta semana, John responde a algumas ótimas perguntas sobre velocidade de página, texto âncora, Java Script. Como sempre, o vídeo completo e a transcrição podem ser encontrados abaixo!

Como o conteúdo traduzido é tratado?

0:33

Eu acho que é bom ter um site combinado como esse. Acho que para os usuários faz sentido fazer com que seja fácil para eles lerem, de modo que, se você fala inglês e acessa seu site, não é como uma mistura de conteúdo em russo, ucraniano e inglês, mas sim todo o conteúdo em inglês. Pode não ser todo o conteúdo que você tem em diferentes idiomas, mas tudo bem. Do ponto de vista de SEO, faz sentido transformar traduções em conteúdo de alta qualidade. Portanto, não apenas usando o Google tradutor para isso. As ferramentas de tradução ainda estão ficando cada vez melhores para isso, mas ainda é se você traduzir manualmente ou pegar a versão do google tradutor e você limpar isso e torná-lo mais legível, então é melhor. Isso é algo que os usuários percebem e também é algo que notamos do ponto de vista algorítmico. Se pudermos dizer que este é realmente um conteúdo de alta qualidade, vamos tratá-lo melhor nos resultados da pesquisa.

Resumo: certifique-se de que seu conteúdo traduzido seja legível em outros idiomas e não apenas traduzido automaticamente com o Google Tradutor. Certifique-se também de que as traduções sejam de alta qualidade e tenham valor para os usuários.

Se meu site está rodando em Javascript e o tempo de indexação é crítico para o conteúdo, como posso saber que vai demorar para ser indexado?

3:10

Então, em geral, a primeira parte está correta. É o caso de tentarmos indexar o conteúdo o mais rápido possível, o que podemos se tivermos uma versão HTML estática, e o próximo passo é tentar renderizar a página como um navegador faria e também escolhemos esse conteúdo e use-o para indexação. Essas duas coisas combinadas geralmente funcionam juntas, mas não é o caso de a versão HTML estática ser atrasada (artificialmente) até que a versão javascript esteja pronta. Desse ponto de vista, para a maioria dos sites, não é crítico que haja essa diferença e não temos nenhum tempo explícito que se aplique ao tempo que leva para começar a renderizar uma página. Isso pode variar dependendo do tipo de página, quando a encontramos, como a encontramos, o que está acontecendo ao redor dessa página. Por exemplo, se pensarmos que isso é algo que é muito rápido para mostrar na pesquisa muito rapidamente, tentaremos renderizá-lo imediatamente. Então é meio difícil levar em conta. Não há um número fixo lá. Em geral, eu usaria isso como uma diretriz aproximada para determinar se você precisa fazer algo com o conteúdo javascript do lado do cliente. Por exemplo, se você tem conteúdo de notícias que precisa ser indexado rapidamente, eu garanto que o Google pode selecionar esse conteúdo o mais rápido possível sem precisar renderizar esse conteúdo separadamente. Para sites de notícias, especialmente nas páginas sobre em sites de notícias onde você vincula a todos os novos artigos, eu realmente me certificaria de que essas páginas funcionem bem puramente com o HTML estático servido aos mecanismos de pesquisa. Então é assim que eu pensaria sobre isso, pensar em quão crítico é que meu conteúdo seja indexado imediatamente e não em termos de quantos minutos isso leva, porque não há um tempo fixo para quanto tempo isso pode levar.

Resumo : para sites javascript, o Google Firsts indexa a página e precisa de tempo para processar o javascript. Não há um tempo fixo de quanto tempo leva. Portanto, se o seu conteúdo precisar de atualização frequente, é melhor veicular uma versão HTML estática da página.

Quais são as principais diferenças entre a ferramenta de inspeção de URL e o teste de compatibilidade com dispositivos móveis, se ambos pegarem páginas do servidor ativo?

9:16

Portanto, a ideia com o teste de compatibilidade com dispositivos móveis é apenas testar se esta versão é compatível com dispositivos móveis, então esse é o foco principal. E a ferramenta de inspeção de URL, a ferramenta de teste ao vivo, serve mais para ver “como essa página se sairia na indexação?”, Ela verifica coisas, eu acho, como o código de resposta sem índice, o tipo de coisas usuais que se aplicariam para saber se pegamos esta página e a colocamos em nosso índice ou não. O teste de compatibilidade com dispositivos móveis é principalmente focado no lado móvel e a ferramenta de inspeção de url é como um grande canivete com diferentes recursos que você pode usar para coisas diferentes.

Resumo : o teste de compatibilidade com dispositivos móveis é ver o desempenho do site em dispositivos móveis, enquanto a ferramenta de inspeção de URL verifica se a indexação está funcionando como deveria, como nenhum código de resposta de índice.

Estou pensando em dividir minhas páginas de produtos no meu site de comércio eletrônico. Atualmente eles são configuráveis ​​em uma página com múltiplas variações mostradas. Quais são suas recomendações?

18:00

Acho que o aspecto que eu examinaria mais é se realmente faz sentido dividir esses produtos em páginas separadas, porque o que você está negociando é uma página de produto bastante forte para esse produto e toda a variação, versus várias páginas que meio que têm que trabalhar por conta própria e ser apoiados por conta própria. Então, em vez de ter uma página realmente forte para “tênis de corrida”, você tem várias páginas que precisam lutar por “tênis azuis”, “tênis vermelhos”, “tênis verdes”. Portanto, se alguém estiver procurando por “tênis de corrida”, essas pequenas páginas não são tão fortes quanto a página de um produto que você tem para esse produto principal. Então meu conselho geral é dizer, se você acha que essas variações são apenas atributos dos produtos principais, em que as pessoas tendem a buscar o conteúdo principal e depois dizer “ah qual cor eu quero, é como se eu tivesse encontrado o produto Eu quero, mas só tenho que escolher a cor que quero.” então eu iria colocá-los em uma página compartilhada. Considerando que se as pessoas estão procurando explicitamente por essa variação e essa variação é realmente única e meio que se destaca por si só e as pessoas não acessam seu site apenas dizendo "Quero tênis de corrida", mas sim "Quero esse tipo específico de corrida sapatos nesta cor” então talvez valha a pena retirar como um produto separado.

Resumo : a menos que as variações do produto se destaquem por conta própria e as pessoas estejam procurando por essa variação específica, é melhor mantê-las todas em uma página forte. Dessa forma, as diferentes variações das páginas do produto não estão competindo entre si.

A velocidade é importante para a versão móvel do seu site?

21:00

Então, a parte boa é que temos muitos fatores de classificação, então você nem sempre precisa fazer tudo perfeito. Mas isso também significa que você se depara com situações como essa em que diz “O Google diz que a velocidade é importante, mas o site principal aqui não é tão rápido, então não deve ser importante”. Para nós, é definitivamente importante, mas isso não significa que se sobreponha a todo o resto. Você pode imaginar que a página mais rápida que você possa imaginar é provavelmente uma página vazia. Mas uma página vazia seria um resultado de pesquisa realmente terrível se você estivesse procurando por algo realmente específico. É muito rápido, mas não há conteúdo para que o usuário não fique feliz. Então, temos que equilibrar todos esses fatores, o conteúdo, os links e todos esses sinais e tentar descobrir como fazer o ranking com base nessa mistura de diferentes fatores que temos. E também faz mudanças ao longo do tempo, pode mudar rapidamente. Por exemplo, se algo é realmente interessante no momento, podemos optar por mostrar sites ligeiramente diferentes, algo que é mais um tópico de pesquisa e perene.

Resumo : A velocidade é apenas um dos fatores de classificação que o Google usa. Só porque os principais sites podem não ser rápidos não significa que não seja importante para o seu site.

Que tipo de marcação de esquema é preferível para o Google, devemos usar JSON ou microdados, formatos micr. Qual é preferível?

22:30

Atualmente, preferimos a marcação JSON-LD. Acho que a maioria dos novos tipos de dados estruturados são lançados primeiro para JSON-LD, então é isso que preferimos.

Resumo: JSON-LD é preferido pelo Google.

Qual a importância do Texto Âncora?

25:10

Então eu acho que antes de tudo, eu não me preocuparia muito com as patentes do Google, nós patenteamos muitas coisas que não necessariamente se aplicam ao que os webmasters precisam fazer. Então, acho interessante ver que nossos engenheiros estão trabalhando, mas isso não significa necessariamente que seremos afetados por isso imediatamente. Com relação ao texto âncora em geral, nós o usamos para texto. É algo que nós pegamos. É uma ótima maneira de nos dar contexto sobre um link. Em particular em seu site, se você tiver um link que diga apenas “clique aqui para obter mais informações”, isso não será muito útil para nós. Onde você tem um link que diz “você pode encontrar mais informações nesta página do produto” e um link com o nome desse produto para essa página, isso nos diz que talvez esta página seja realmente sobre esse produto. Então, eu certamente continuaria a olhar para o seu texto âncora que você usa, especialmente internamente em seu site e tentar ter certeza de que você está fornecendo um texto âncora que é realmente útil e fornece contexto para o que está vinculado na página.

Resumo: o texto âncora é muito importante, pois fornece contexto ao Google sobre o assunto da página. Texto âncora como "Clique aqui para obter mais informações" não fornece muitas informações ao Google, mas Texto âncora como "Você pode encontrar mais informações sobre esta página de produto" informa ao Google que esta página é sobre esta página de produto.

Nossa observação: se você estiver criando seus próprios links, ter muitos links de palavras-chave pode alertar a equipe de spam da web caso você receba uma revisão manual.

Como o Google vê visualmente sua página?

39:00

Nós tentamos olhar para a página visualmente, mas principalmente no que diz respeito ao conteúdo real acima da dobra ou o espaço acima da dobra é apenas um anúncio gigante. É nisso que nos concentramos, também em relação à compatibilidade com dispositivos móveis, tentamos mapear visualmente uma página e ver, é uma página que funcionaria bem em um dispositivo móvel. E para isso temos que mapear a página, tudo bem se alguns elementos estiverem ilegíveis, desde que funcionem em um dispositivo móvel. Se esses links estão lá, eles são do tamanho certo e as pessoas podem clicar neles, então tudo bem. Se você estiver fazendo alguma transformação css sofisticada para transformar isso em texto 3D, isso depende totalmente de você. A parte importante é que o próprio texto seja visível na página e que você não esteja fazendo muitas marcações sofisticadas para dividir esse texto. Então, como exemplo, se você tem um título no sistema antigo em que você tem um layout baseado em tabela e deseja dividir a cura no topo, parece que as pessoas colocam letras individuais em células de tabela individuais e, do nosso ponto de vista, isso torna é praticamente impossível ver que isso é realmente uma palavra porque você está usando marcação para dividi-la em pedaços desconectados. Do ponto de vista da análise da página, isso é realmente complicado.

Resumo: O Google tenta principalmente ver se o conteúdo real está acima da dobra e não apenas um anúncio gigante. Em termos de compatibilidade com dispositivos móveis, o Google tenta entender se os mesmos links estão lá, se tudo está no tamanho certo e se as pessoas podem clicar nesses links. O mais importante é se o próprio texto estiver visível na página.

Você pode trocar um URL com Javascript?

43:00

Sim podemos retirar. A parte importante que eu acho é que a URL precisa ser trocada depois que a página for carregada. Ele não deve ser trocado quando um usuário faz uma ação específica. Por exemplo, se um usuário passar o mouse sobre um link e você usar JavaScript para trocar o URL, isso não seria algo que notamos ou se um usuário clicar em um link e você usar JavaScript para trocar o URL, isso também não seria algo que notamos. Mas se a página carregar e você executar algum JavaScript que limpe o URL para que eles vinculem às versões canônicas apropriadas, está perfeitamente bem e como falamos no início quando se trata de renderização, às vezes isso demora um pouco Tempo. Portanto, não é uma coisa imediata que pegaríamos ou é provável que pegaríamos essas duas versões, tanto o link original que você tinha lá, quanto a versão JavaScript. Portanto, não seria que as versões antigas fossem abandonadas completamente.

Resumo : o Google pode selecionar se um URL foi trocado após o carregamento de uma página. A única coisa que você deve saber é garantir que a URL não seja trocada quando um usuário fizer uma ação específica.

Se você gosta de coisas assim, vai adorar minha newsletter!

Minha equipe e eu relatamos todas as semanas as últimas atualizações de algoritmos do Google, notícias e dicas de SEO.

Pergunta 0:33 - Pergunta sobre tradução. Eu sei que se eu traduzir conteúdo em inglês para russo ou ucraniano, a maioria das pessoas usa apenas a tradução do Google e apenas coloca o conteúdo. Mas é como se 90% dele precise de correção se você o ler como um falante nativo. Estou interessado em dois pontos. Se eu quiser fazer alguma outra versão ou outro idioma para o meu site, como inglês, russo ou ucraniano, tudo bem? Segundo, encontro um artigo interessante sobre o meu nicho e quero traduzi-lo, isso é bom ou não? Preciso torná-lo adaptável para leitores domésticos?

Resposta 1:38 - Acho bom ter um site combinado como esse. Acho que para os usuários faz sentido fazer com que seja fácil para eles lerem, de modo que, se você fala inglês e acessa seu site, não é como uma mistura de conteúdo em russo, ucraniano e inglês, mas sim todo o conteúdo em inglês. Pode não ser todo o conteúdo que você tem em diferentes idiomas, mas tudo bem. Do ponto de vista de SEO, faz sentido transformar traduções em conteúdo de alta qualidade. Portanto, não apenas usando o Google tradutor para isso. As ferramentas de tradução ainda estão ficando cada vez melhores para isso, mas ainda é se você traduzir manualmente ou pegar a versão do google tradutor e você limpar isso e torná-lo mais legível, então é melhor. Isso é algo que os usuários percebem e também é algo que notamos do ponto de vista algorítmico. Se pudermos dizer que este é realmente um conteúdo de alta qualidade, vamos tratá-lo melhor nos resultados da pesquisa.

Pergunta 3:10 - O Google rastreia e indexa o conteúdo em duas etapas. A primeira é a renderização do lado do servidor e a segunda é a renderização do lado do cliente, de acordo com declarações anteriores, pode levar dias ou semanas para que esse processo seja concluído. Para sites que usam Javascript, eles podem enfrentar sérios problemas se a indexação for crítica em termos de tempo. Como posso saber quanto tempo vai demorar?

Resposta 3:46 - Então, em geral, a primeira parte está correta. É o caso de tentarmos indexar o conteúdo o mais rápido possível, o que podemos se tivermos uma versão HTML estática, e o próximo passo é tentar renderizar a página como um navegador faria e também escolhemos esse conteúdo e use-o para indexação. Essas duas coisas combinadas geralmente funcionam juntas, mas não é o caso de a versão HTML estática ser atrasada (artificialmente) até que a versão javascript esteja pronta. Desse ponto de vista, para a maioria dos sites, não é crítico que haja essa diferença e não temos nenhum tempo explícito que se aplique ao tempo que leva para começar a renderizar uma página. Isso pode variar dependendo do tipo de página, quando a encontramos, como a encontramos, o que está acontecendo ao redor dessa página. Por exemplo, se pensarmos que isso é algo que é muito rápido para mostrar na pesquisa muito rapidamente, tentaremos renderizá-lo imediatamente. Então é meio difícil levar em conta. Não há um número fixo lá. Em geral, eu usaria isso como uma diretriz aproximada para determinar se você precisa fazer algo com o conteúdo javascript do lado do cliente. Por exemplo, se você tem conteúdo de notícias que precisa ser indexado rapidamente, eu garanto que o Google pode selecionar esse conteúdo o mais rápido possível sem precisar renderizar esse conteúdo separadamente. Para sites de notícias, especialmente nas páginas sobre em sites de notícias onde você vincula a todos os novos artigos, eu realmente me certificaria de que essas páginas funcionem bem puramente com o HTML estático servido aos mecanismos de pesquisa. Então é assim que eu pensaria sobre isso, pensar em quão crítico é que meu conteúdo seja indexado imediatamente e não em termos de quantos minutos isso leva, porque não há um tempo fixo para quanto tempo isso pode levar.

Pergunta 6:17 - E agora temos uma pergunta gigante e longa sobre entender o tipo de sinalização no console de pesquisa, como quando sinalizamos algo como 'o Google duplicado escolhe um canônico diferente do usuário' ou 'URL enviado duplicado e não selecionado como problemas canônicos .

[User Chimes in] É uma página Javascript. É pré-renderizado, todo o conteúdo está no HTML estático e ainda assim o google ainda está tentando executar a página. E estamos descobrindo neste ambiente de comércio eletrônico que essas páginas de produtos exclusivas com descrições exclusivas e conteúdo significativo estão sendo sinalizadas como Google como conteúdo duplicado. Assumimos que isso se deve a algum tipo de falha de renderização de JavaScript, onde o Googlebot continua vendo a mesma página de erro ou algo assim e, portanto, pensa que são duplicatas - como podemos entender o que é que o serviço de renderização da Web acaba com isso pode resultar em conteúdo que parece duplicado para o bot do Google.

Resposta 7:43 - Eu teria que ver alguns exemplos reais, então se você pudesse me enviar alguns exemplos que seriam muito úteis.

Pergunta 8:00 - O Google está ciente de um problema em andamento?

Resposta 8:00 - Não… Eu ouvi de alguns sites que estavam reclamando disso mais do que outros, então se você enviar alguns exemplos que seriam úteis.

Pergunta 8:24 - Se uma url estiver sinalizada, existe alguma forma de ver alguma coisa sobre a renderização que aconteceu no momento dessa análise. Existe alguma maneira de ver os erros de carregamento de recursos que ocorreram em um que foi indexado? Você não tem essa interface do usuário no console de pesquisa, ou pelo menos não consigo acessá-la. E ou existe algum lugar onde possamos ver como o conteúdo realmente se parece no momento em que o indexador e/ou localizador de detecção de duplicatas o observa?

Resposta 8:41 - Não no momento. Isso é algo que faria muito sentido ter. Para a maioria dos sites não é crítico. Mas no caso como este que seria útil ter.

Pergunta 9.16 - Próxima pergunta. Teste amigável para dispositivos móveis. Você o fez referência algumas vezes para entender como o indexador veria o conteúdo. No entanto, estamos descobrindo que existem muitos outros erros rotulados no carregamento de recursos e a taxa na qual esses erros ocorrem parece variar de domínio para domínio. Então, primeira pergunta, os erros que vemos no teste de compatibilidade com dispositivos móveis são representativos dos erros que o serviço encontraria durante a indexação? Ou existem diferentes alocações de recursos para o teste MF?

Resposta 10:04 - Então, acho que você está se referindo especificamente aos recursos incorporados que são puxados para o teste, certo? Como arquivos JS CSS diferentes respostas desse tipo de coisa? Eu acho que um dos aspectos que é um pouco complicado no momento no sentido de que temos prioridades diferentes para o teste de compatibilidade com dispositivos móveis em comparação com o bot normal do Google. Tentamos obter recursos o mais rápido possível do servidor ativo e, durante a indexação, armazenamos em cache muitos recursos e apenas pegamos a versão em cache da página. Então, o que você pode ver no teste de compatibilidade com dispositivos móveis é que tentamos renderizar esta página o mais rápido possível e podemos obter muitos desses recursos, mas para alguns deles nós essencialmente expiramos com essencialmente a capacidade de fazer isso ao vivo o servidor. Então, isso é em grande parte alguns dos erros que você vê com o teste de compatibilidade com dispositivos móveis. Eu também acredito que na ferramenta de inspeção de url se você usar um teste ao vivo, estamos tentando puxar tudo ao vivo e às vezes isso simplesmente não é possível fazê-lo ao vivo. E para indexação temos muito mais, um pouco mais de tempo, que temos disponível para isso. Então, se percebermos que esses recursos são necessários, nós os extrairemos, os armazenaremos em cache e tentaremos disponibilizá-los para quando tentarmos fazer a renderização. Então, isso é algo em que não precisamos fazer nada ao vivo, então se demorar um pouco mais para fazer isso, seremos pacientes e esperaremos que tudo isso aconteça. Ainda há um aspecto do tempo lá fora que esses recursos são todos de tal forma que não podemos armazená-los (por exemplo, o ID da sessão e todos os URLs JS), então isso faz com que realmente mantenhamos uma versão em cache e reutilizá-lo mais tarde, então esses são aqueles que podemos, não sei, por qualquer motivo, não sermos capazes de buscar para indexação. Resumindo, acho que fica difícil diagnosticar problemas como esse, principalmente se você tiver muitos recursos incorporados. As diretrizes que geralmente recebo da equipe de engenharia é que devemos apenas dizer às pessoas que tenham menos recursos incorporados e elas tendem a não se deparar com esse problema. Isso nem sempre é tão fácil, mas, em geral, o que eu faria é usar o teste de compatibilidade com dispositivos móveis como um guia aproximado, portanto, se funcionar no MTF, você está definitivamente no lado seguro. Se você vir algumas outras coisas expirando com esse outro erro, na maioria das vezes ainda podemos usar isso para indexação.

Pergunta 12:57 - Você tocou nisso, acho que, tangencialmente, devemos estar cientes de qualquer tempo limite rígido ou arbitrário na renderização pelo serviço de renderização da web. Existe alguma clareza sobre qual conteúdo realmente é usado se uma página demorar muito para ser renderizada pelo Googlebot no serviço de renderização? Ele simplesmente desiste e usa o conteúdo html da página que estava lá originalmente? Temos alguma clareza sobre até que ponto no processo de renderização você pode terminar?

Resposta 13:45 - na maioria das vezes, se algo quebrar ou expirar, apenas tiramos um instantâneo ali mesmo. Então, sim... Acho que no seu caso, se você está pré-renderizando o conteúdo, não deve haver problemas porque o conteúdo está lá. O que às vezes vemos com sites de comércio eletrônico ou com sites que usam uma estrutura muito modelada é que nos deparamos com situações em que assumimos que há conteúdo duplicado antes de realmente testarmos as URLs. Então isso pode acontecer se nós, por exemplo, vermos um padrão de url. Se acessarmos um monte de urls com padrões diferentes ou parâmetros diferentes, por exemplo, e virmos que todos esses urls estão levando ao mesmo conteúdo, nosso sistema pode dizer “ok, este parâmetro não é tão relevante para o site depois all” e tendemos a descartar esses urls e diríamos 'este conjunto de urls é provavelmente o mesmo que esse outro conjunto de urls que já rastreamos. Então, em particular, se você tem coisas em algum lugar, vamos ver, um exemplo que eu vi bastante é se você tem muitos sites de comércio eletrônico diferentes e todos eles vendem os mesmos produtos - então todo o caminho depois da parte do produto os urls são os mesmos em um grande número de domínios - então nosso sistema dirá "todos esses urls são os mesmos, todos levam ao mesmo produto", portanto, podemos indexar apenas um desses domínios em vez de todos desses domínios. Não sei se isso se aplicaria ao seu caso, então não sei se isso é útil, mas é uma daquelas coisas em que nossos sistemas tentam otimizar o que encontramos na web e assumimos que outras pessoas cometemos erros também na web e tentamos contornar isso. Vemos que “todas essas pessoas estão criando duplicatas, mas não precisamos rastrear todas essas duplicatas” para que possamos nos concentrar no que achamos que são os URLs reais.

Pergunta 16:22 - Para pegar o teste de compatibilidade com dispositivos móveis e o teste ao vivo na ferramenta de inspeção de url. No teste de compatibilidade com dispositivos móveis, o Googlebot tenta pegar uma página do servidor ativo, então, qual é a diferença da ferramenta de inspeção de URL com esse recurso? Como é diferente renderizar ou buscar as páginas e os recursos

Resposta 17:04 - Então a ideia com o teste de compatibilidade com dispositivos móveis é apenas testar se esta versão é compatível com dispositivos móveis, então esse é o foco principal. E a ferramenta de inspeção de URL, a ferramenta de teste ao vivo, serve mais para ver “como essa página se sairia na indexação?”, Ela verifica coisas, eu acho, como o código de resposta sem índice, o tipo de coisas usuais que se aplicariam para saber se pegamos esta página e a colocamos em nosso índice ou não. O teste de compatibilidade com dispositivos móveis é principalmente focado no lado móvel e a ferramenta de inspeção de url é como um grande canivete com diferentes recursos que você pode usar para coisas diferentes.

Pergunta 18:00 - Em um site de comércio eletrônico de nossos clientes, alguns dos produtos são vendidos como configuráveis, o que significa que várias variações diferentes do produto são exibidas e gerenciadas na mesma página. Estamos pensando em dividir essas páginas para que cada uma tenha sua própria página de produto separada com um novo URL. As avaliações dos clientes seriam então movidas da página antiga para as novas e simples. O fato de a revisão antiga ter uma data mais antiga que a nova data de criação pode ser marcada como black hat SEO?

Resposta 18:37 - Então, não vejo nenhum problema com os comentários, desde que você possa continuar adicionando novos comentários a essas páginas de produtos. Acho que o aspecto que eu examinaria mais é se realmente faz sentido dividir esses produtos em páginas separadas, porque o que você está negociando é uma página de produto bastante forte para esse produto e toda a variação, versus várias páginas que meio que têm que trabalhar por conta própria e ser apoiados por conta própria. Então, em vez de ter uma página realmente forte para “tênis de corrida”, você tem várias páginas que precisam lutar por “tênis azuis”, “tênis vermelhos”, “tênis verdes”. Portanto, se alguém estiver procurando por “tênis de corrida”, essas pequenas páginas não são tão fortes quanto a página de um produto que você tem para esse produto principal. Então meu conselho geral é dizer, se você acha que essas variações são apenas atributos dos produtos principais, em que as pessoas tendem a buscar o conteúdo principal e depois dizer “ah qual cor eu quero, é como se eu tivesse encontrado o produto Eu quero, mas só tenho que escolher a cor que quero.” então eu iria colocá-los em uma página compartilhada. Considerando que se as pessoas estão procurando explicitamente por essa variação e essa variação é realmente única e meio que se destaca por si só e as pessoas não acessam seu site apenas dizendo "Quero tênis de corrida", mas sim "Quero esse tipo específico de corrida sapatos nesta cor” então talvez valha a pena retirar como um produto separado. Então essa é a distinção com a qual eu talvez me preocupasse - eu não me preocuparia tanto com a parte de comentários.

Pergunta 20:36 A nova funcionalidade do esquema de marcação do Search Console permaneceu a mesma da antiga?

Resposta 20:50 Não sei quais são os planos exatos para o novo console de pesquisa em relação aos recursos de dados estruturados, mas planejamos oferecer suporte a todos esses recursos de dados estruturados. Então, o que pode acontecer é que esses recursos acabam no console de pesquisa de uma maneira um pouco diferente.

Pergunta 21:00 E quanto à velocidade para a versão móvel, é crucial ter velocidade na zona verde e se sim, por que muitos dos principais sites ainda são tão lentos?

Resposta 21:20: Então a parte boa é que temos muitos fatores de classificação, então você nem sempre precisa fazer tudo perfeito. Mas isso também significa que você se depara com situações como essa em que diz “O Google diz que a velocidade é importante, mas o site principal aqui não é tão rápido, então não deve ser importante”. Para nós, é definitivamente importante, mas isso não significa que se sobreponha a todo o resto. Você pode imaginar que a página mais rápida que você possa imaginar é provavelmente uma página vazia. Mas uma página vazia seria um resultado de pesquisa realmente terrível se você estivesse procurando por algo realmente específico. É muito rápido, mas não há conteúdo para que o usuário não fique feliz. Então, temos que equilibrar todos esses fatores, o conteúdo, os links e todos esses sinais e tentar descobrir como fazer o ranking com base nessa mistura de diferentes fatores que temos. E também faz mudanças ao longo do tempo, pode mudar rapidamente. Por exemplo, se algo é realmente interessante no momento, podemos optar por mostrar sites ligeiramente diferentes, algo que é mais um tópico de pesquisa e perene.

Pergunta 22:30 Que tipo de marcação de esquema é preferível para o Google, devemos usar JSON ou micro-dados, formatos micr. Qual é preferível?

Resposta 22:48 Atualmente, preferimos a marcação JSON-LD. Acho que a maioria dos novos tipos de dados estruturados são lançados primeiro para JSON-LD, então é isso que preferimos.

Pergunta 23:00 O Google fez alguma atualização pesada em fevereiro ou março?

Resposta: 23:15 Não sei, quero dizer, fazemos atualizações o tempo todo. Não sei o que você consideraria pesado. Provavelmente depende do seu site. Se o seu site foi fortemente afetado por uma dessas atualizações, você provavelmente acha que é muito pesado. Se olharmos para a web como um todo, talvez seja como normalmente as mudanças acontecem.

Pergunta 23:24. O que significa conteúdo fino para sites afiliados?

Resposta 23:34 Conteúdo fino não significa nada diferente para sites afiliados em comparação com quaisquer outros sites. O que vimos, especialmente com sites afiliados, é que existe essa tendência de apenas pegar o conteúdo de um feed porque é muito fácil de fazer. Você pode obter scripts que fazem isso para você rapidamente, é fácil de fazer, você não tem dois para fazer muito trabalho, cria muitas URLs. Mas é claro que para os usuários e para nós não é tão interessante porque você está fornecendo a mesma coisa que todo mundo já tem.

Pergunta 24:40 O conteúdo oculto nas guias é um problema para indexação?

Resposta 24:50 Em geral, não é um problema para indexação. Pode ser um problema para os usuários, portanto, se houver conteúdo lá que você acha que os usuários realmente precisam ver para converter, isso seria um pouco problemático do seu ponto de vista. Com relação à indexação, podemos pegar esse conteúdo e mostrá-lo, então isso é um problema menor.

Pergunta 25:10 O texto âncora ainda é um importante fator de classificação em 2019? Muitas empresas fizeram estudos que apontam que não há correlação. E depois há um link para uma patente do Google.

Resposta 25:30 Então eu acho que antes de tudo, eu não me preocuparia muito com as patentes do Google, nós patenteamos muitas coisas que não necessariamente se aplicam ao que os webmasters precisam fazer. Então, acho interessante ver que nossos engenheiros estão trabalhando, mas isso não significa necessariamente que seremos afetados por isso imediatamente. Com relação ao texto âncora em geral, nós o usamos para texto. É algo que nós pegamos. É uma ótima maneira de nos dar contexto sobre um link. Em particular em seu site, se você tiver um link que diga apenas “clique aqui para obter mais informações”, isso não será muito útil para nós. Onde você tem um link que diz “você pode encontrar mais informações nesta página do produto” e um link com o nome desse produto para essa página, isso nos diz que talvez esta página seja realmente sobre esse produto. Então, eu certamente continuaria a olhar para o seu texto âncora que você usa, especialmente internamente em seu site e tentar ter certeza de que você está fornecendo um texto âncora que é realmente útil e fornece contexto para o que está vinculado na página.

Pergunta 27:00 Você pode nos dizer como funciona o processo DMCA?

Resposta 27:01 Não posso dizer como isso funciona porque não conheço os detalhes sobre isso e também é um processo legal e não posso lhe dar aconselhamento jurídico.

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

Resposta 47:54 - Ambos os métodos funcionam. Portanto, o arquivo de mapa do site nos ajuda a entender melhor as páginas novas e alteradas em um site. Não é um fator de classificação, portanto, você não terá uma classificação mais alta apenas porque possui um arquivo de mapa do site, isso nos ajuda a entender quais dessas páginas estão disponíveis em um site, mas na maioria das vezes, especialmente para sites menores, podemos rastreá-los normalmente também e não há grande diferença em relação a como um site é exibido na pesquisa se pudermos rastreá-lo normalmente ou se o rastrearmos com um arquivo de mapa do site. Portanto, um arquivo de mapa do site definitivamente não é crítico para sites maiores se você estiver alterando partes do conteúdo que às vezes estão um pouco mais baixas no site, obviamente um arquivo de mapa do site nos ajuda a encontrar essas alterações muito mais rapidamente, mas se você está apenas começando um blog, você não precisa necessariamente ter um arquivo de mapa do site.

Pergunta 48:50 - Nós revendemos hotéis na Grécia através do nosso site, desenvolvemos uma boa seção amigável para hotéis, mas também duplicamos o conteúdo e os títulos desses hotéis à medida que incorporamos vídeos do YouTube desses hotéis. Isso é prejudicial para nós?

Resposta 49:10 - Bem, acho que isso remonta às outras perguntas que tivemos sobre conteúdo duplicado. Conteúdo duplicado onde você realmente precisa se concentrar em garantir que você tenha algo único em seu site, se você estiver apenas fornecendo a mesma coisa em muitos sites diferentes, então isso torna muito difícil para nós dizer bem, isso é na verdade, um site que precisamos para mostrar os resultados da pesquisa. Então, isso é algo em que eu recomendaria dar um passo para trás e pensar sobre o que você poderia fazer para garantir que seu site seja realmente único e atraente por si só, em vez de apenas a mesma coisa que todos esses outros sites.

Pergunta 50:00 - Se uma história foi redirecionada porque era de conteúdo fraco e com muitos anos de idade, os efeitos negativos do artigo meio que são encaminhados com o redirecionamento?

Resposta 50:12 - Não, não necessariamente. Então, especialmente quando se trata de conteúdo, analisamos o conteúdo que encontramos na página final em que chegamos. Então, se você removeu conteúdo, se limpou alguma coisa e acho que isso acontece automaticamente. se você redirecionar essa página e o conteúdo antigo não estiver mais lá e só tivermos o novo conteúdo, tudo bem. Então isso não seria algo que seria meio que continuado.

Pergunta 50:45 - É natural que o console de pesquisa relate erros de compatibilidade com dispositivos móveis na subversão de teste de uma página quando associamos a versão compatível com dispositivos móveis de uma página com o ato de link rel alternativo'

Resposta 50:57 - Então geralmente isso significa que não temos uma compreensão clara de quais dessas páginas pertencem umas às outras. Portanto, por um motivo ou outro, indexamos essas páginas individualmente, e não como um par, onde sabemos que essa página para computador pertence a essa página para dispositivos móveis. Então, isso poderia apontar para uma incompatibilidade com a maneira como você configurou o link alternativo ou o link rel canônico nessas páginas. Então, eu meio que observo isso também e a outra coisa, é claro, é que também analisaria o que seria necessário para mudar para um design responsivo, porque especialmente com o primeiro índice móvel, todos esses tipos de problemas em que temos dispositivos móveis separados URLs eles tornam tudo desnecessariamente complicado. Considerando que se você puder mudar para um design responsivo ou um design que use apenas os mesmos URLs para as versões desktop e móvel. Do que você se salva, tem tantos problemas, então, em vez de acompanhar esse tipo de problema, talvez reserve um tempo para dizer, ok, eu deveria investir em um plano para mudar para um design responsivo, para que eu não tenha que me concentrar nesses questões mais no futuro.

Pergunta 1:01:01- É uma boa ideia adicionar um link nofollow ao wikipedia e artigos de ajuda do google como outros links externos? E quanto tempo um bom marcador de dados leva para fazer efeito em uma pesquisa?

Resposta 1:01:16 - Skay então adicionando nofollow aos links da Wikipedia. Eu não acho que isso faça muito sentido, a menos que a Wikipedia esteja pagando você para colocar esses links. Então, eu adicionaria um nofollow aos links que você não deseja associar ao seu site. Mas caso contrário, se for um link normal no conteúdo e eu apenas olharia normalmente, a menos que a Wikipedia esteja pagando por esses links, eu pensaria normalmente, eu acho. E para o marcador de dados, o que acontece é um processo algorítmico que pode demorar um pouco, pois é baseado nas páginas de cache que ele aprende nas páginas de índice do seu site e, obviamente, na marcação que você faz os dados marcador e, em seguida, ele o aplica a novas páginas à medida que as rastreamos e reindexamos em seu site. Então, isso é algo que leva um período de tempo para se aplicar ao conteúdo à medida que o rastreamos e reindexamos em seu site. Portanto, não há um cronograma fixo, às vezes, que é bastante rápido para muitas páginas e, às vezes, pode levar alguns meses para ficar visível. Portanto, não há nenhum tipo de botão instantâneo para isso, leva tempo como qualquer outro dado estruturado que você adicionaria às suas páginas manualmente.

Pergunta 1:02:58 - O Google está ciente e anunciando uma mudança substancial na forma como o conteúdo duplicado começou a ser tratado por volta do final de novembro, início de dezembro do ano passado? Ou houve uma mudança substancial na maneira como o serviço de renderização da Web lida com seus negócios ou a relação entre renderização da Web e indexação versus indexação rastreada nesse período, porque nada mudou em nosso sistema e vimos, como eu disse, problemas substanciais a partir de então em particular, não apenas para nós mesmos, mas também notamos várias outras observações desse tipo de problema no mesmo período?

Resposta - 1:03:47 - Onde algo substancial mudou lá. A única coisa que acho que aconteceu por volta do outono é que começamos a adicionar esse recurso ao console de pesquisa para destacar esses problemas e acho que também foi onde comecei a ver mais desses relatórios, uma vez que o destacamos para usuários que, ei, estamos descartando esses URLs e como se houvesse um gráfico deles porque achamos que todos estão duplicados, e é claro que todos estão tipo, oh, isso é um novo problema, mas em grande parte basicamente sempre foi como que nós nunca falamos sobre isso no console de busca. Então, não sei exatamente quando começamos a lançar esse recurso no console de pesquisa, mas provavelmente no segundo semestre do ano passado, algo por volta dessa época.