22 de janeiro de 2019 – Notas do Hangout da Ajuda do Google

Esta semana John está na Big Apple, NYC. Juntou-se à IRL, da esquerda para a direita, por Martin Splitt da equipe de Java Script do Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala e Quason Carter. Esta semana houve algumas ótimas perguntas sobre Cloudfare, The QRG e The New Page Speed ​​Tool. O link para o vídeo e a transcrição completa podem ser encontrados abaixo!

A Cloudflare às vezes bloqueia o Googlebot?

7:58

"Sim, eu não sei como isso é configurado com o Cloudflare no momento, mas eu sei que no passado eles costumavam bloquear pessoas que estavam fingindo o Googlebot. Sapo ou algo assim-- você diz, estou usando o agente de usuário do Googlebot, então eles bloqueariam isso porque poderiam dizer, tipo, que este não é um Googlebot legítimo. Podemos bloquear isso. Mas, na maioria das vezes, acho que eles têm prática suficiente para reconhecer Googlebots normais e permitir que eles rastreiem normalmente."

Resumo: às vezes, ao testar, pode parecer que o Cloudflare está bloqueando o Googlebot. O que provavelmente está acontecendo aqui é que a Cloudflare está bloqueando pessoas que fingem ser o Googlebot. Portanto, se você usar uma ferramenta como o Screaming Frog e escolher o Googlebot como seu user agent, talvez não consiga rastrear sites usando o Cloudflare .

Links artificiais ainda podem prejudicar um site por meio de algoritmos? Em caso afirmativo, o uso da ferramenta de rejeição pode ajudar?

14:01

"Acho que foi uma boa pergunta. Então, do meu ponto de vista, o que eu olharia é, por um lado, definitivamente o caso é onde há uma ação manual. Mas também, os casos em que você também quer ver muitas ações manuais diria, bem, se a equipe de spam da Web analisasse isso agora, eles lhe dariam uma ação manual. Tipos de casos em que você diria, bem, a ação manual é mais uma questão de tempo e não como se fosse baseado em algo que foi feito - eu não sei - onde claramente foi feito alguns anos atrás, e era meio que não. Mas o tipo de coisa em que você olha para isso e digamos, se alguém da equipe de spam da web recebesse isso como uma dica, eles fariam uma ação manual, e esse é definitivamente o tipo de coisa em que eu limparia isso e faria uma rejeição por isso. Sim, eu acho é difícil dizer se existe uma linha do tempo específica. Mas, em geral, se a equipe de spam da Web analisasse isso e dissesse, tipo, as coisas seguiram em frente. Isso foi claramente d um há alguns anos. Não foi totalmente malicioso. Então eles provavelmente não tomariam nenhuma ação manual para isso. "

E eu estou supondo que você provavelmente não pode responder isso, mas existe alguma maneira de-- tipo, digamos que não obtivemos uma ação manual, ou eles não obtiveram uma ação manual. Esses links podem prejudicá-los algoritmicamente? Porque sentimos que estamos vendo algumas melhorias em alguns sites, você sabe, depois de rejeitar. Então, novamente, eu sei que é sempre -- nunca é preto e branco.

Isso definitivamente pode ser o caso. Então é algo em que nossos algoritmos quando olhamos para isso e eles vêem, oh, eles são um monte de links muito ruins aqui, então talvez eles sejam um pouco mais cautelosos com relação aos links em geral para o site. Então, se você limpar isso, então os algoritmos olham para isso e dizem, oh, há-- há meio que-- está tudo bem. Não é ruim.

Resumo: Se você tem links que foram feitos especificamente apenas para SEO e tem muitos deles, eles podem fazer com que os algoritmos do Google desconfiem de todos os seus links. Melhor desmentir para casos como este.

Como os algoritmos do Google medem o EAT dos editores?

33:40

"Eu não sei. Acho que provavelmente é difícil descobrir algoritmicamente. E se houvesse algum tipo de coisa técnica que você deveria fazer, então nós o informaríamos. Então, se houver coisas como marcação de autoria que nós em alguns pontos que achamos que seriam úteis para algo assim, definitivamente traríamos isso para fora. Mas muitas coisas são realmente mais fatores de qualidade suaves que tentamos descobrir, e não é algo técnico que você está fazendo ou não fazendo. É mais, tipo, tentar descobrir como um usuário pode ver isso. Portanto, não há nada específico que eu possa apontar."

Resumo: Existem muitos “fatores de qualidade suaves” que o Google analisa. Veja as coisas da perspectiva de um usuário. Além disso, a marcação de autoria pode ajudar o Google a entender melhor as coisas.

Se algo estiver nas Diretrizes dos avaliadores de qualidade, é razoável supor que o Google deseja que isso seja refletido em seus algoritmos?

34:44

Eu acho que, em geral, é provavelmente uma boa prática apontar para isso. Eu evito tentar focar muito no que o Google pode usar como um fator algorítmico e olhar para isso mais como -- achamos que isso é bom para a web e, portanto, vamos tentar ir nessa direção e fazer essas tipo de coisas. Então, não é como se eu estivesse fazendo um bom site apenas para poder classificar melhor, mas estou fazendo um bom site porque, quando apareço na pesquisa, quero que as pessoas tenham uma boa experiência. E então eles voltarão ao meu site, e talvez eles comprem alguma coisa. Então, essa é a direção que eu veria, não como, tipo, fazer isso para classificar, mas fazer isso para ter um relacionamento saudável e de longo prazo na web.

Resumo: Pense no que é melhor para os usuários. Embora nem tudo o que está no QRG seja refletido atualmente nos algoritmos do Google, todos esses são grandes passos para melhorar a qualidade geral.

Existe esquema para ajudar os sites a aparecerem mais alto nos resultados da pesquisa por voz?

36:10

Não sei. Não consigo pensar em nada de improviso. Portanto, há a marcação falada que você pode usar, o que provavelmente é razoável para-- examinar para ver onde isso pode fazer sentido em uma página. Eu não acho que vamos usar isso em todos os locais ainda.

Resumo: A marcação falada ainda não é usada em todas as localizações geográficas. Mas, este é um bom lugar para começar.

Algumas dicas sobre como ganhar snippets em destaque

38:03

Mas snippets em destaque, em particular, não acho que tenhamos nenhum tipo de marcação específica para isso. Então, isso é algo em que se você tiver um tipo claro de estrutura na página, isso nos ajuda muito. Se pudermos reconhecer tabelas semelhantes em uma página, podemos fazer isso com muito mais facilidade. Considerando que se você usa HTML e CSS sofisticados para fazer com que pareça uma tabela, mas não é realmente uma tabela, então é muito mais difícil para nós retirarmos.

Resumo: não há marcação que você pode adicionar para ganhar um trecho em destaque. Mas, o bom uso de tags h e tabelas HTML normais podem realmente ajudar.

O esquema de localização deve ser adicionado a todas as páginas?

50:47

Resposta 51:42 - Até onde eu sei, é apenas a página inicial. Não sei. Você algum de vocês conhece?

Resposta de Liz 51:4 7 - Deve ser apenas uma página normalmente com organizacional e corporativa. Essa é geralmente a recomendação.

MARTIN SPLITT 52:00 - Eu acho que não importa qual -- não importa tanto quais páginas, assim como não colocar em todas as páginas que você tem, eu acho, é a parte mais importante. Acho que depende de -- se você é um site de notícias, provavelmente faz sentido colocá-lo na página de contato, ou na página sobre, ou algo assim. Considerando que em um site de loja ou restaurante, provavelmente não há problema em colocá-lo na página inicial.

JOÃO 52:20 - Acho que também, neste caso, não importa tanto para nós, porque precisamos encontrá-lo em algum lugar como a página inicial ou a página de contato. Mas se a tivermos em outro lugar, não muda nada para nós. Portanto, a grande coisa a não comparar é a marcação de comentários, onde às vezes vemos pessoas colocando comentários semelhantes em todas as páginas do site com a esperança de obter as estrelas e os resultados de pesquisa para todas as páginas do site. E isso seria ruim para nós. Mas as informações de contato, se você tem isso marcado, é... Não vejo problema nisso.

Resumo: Isso realmente não importa. Deve estar na página de contato e provavelmente na sua página sobre e na página inicial. Ter o esquema de localização em todo o site não é um problema, mas também não é necessário.

Por que a nova ferramenta PageSpeed ​​Insights, baseada no Lighthouse, é muito mais dura ao pontuar sites?

53:05

Marie Haynes: Não é minha pergunta, mas para dar algum contexto, os novos dados do Lighthouse para velocidade de página são muito mais severos do que o Page Speed ​​Insights costumava ser. Então, algo que teve uma pontuação de 80 no Page Speed ​​Insights pode ser um 29 vermelho no Lighthouse. Então essa é uma boa pergunta. Isso pode causar-- porque sabemos que em dispositivos móveis, sites muito lentos podem ser rebaixados. Então, é bom se dissermos, você sabe, se você está no vermelho no teste do Lighthouse, que deveríamos realmente melhorar as coisas porque isso pode causar um rebaixamento ou há um corte?

Resposta 54:07 - Então não temos um mapeamento um-para-um das ferramentas externas e tudo o que usamos para o social. Sim, isso torna muito difícil dizer, mas na pesquisa, tentamos usar uma mistura de dados reais de teste de laboratório, que é como o teste do Lighthouse e os dados de relatório do Chrome UX, onde essencialmente o que que estamos medindo é o que os usuários do site estariam vendo.

MARTIN SPLITT 55:37 - Também é importante ver que o Lighthouse, por exemplo, mede especificamente para uma conexão 3G na extremidade mediana - ou como um telefone de desempenho médio, sim. Então, basicamente, se você estiver usando um Apple McIntosh recente ou um computador Windows rápido recente com uma conexão com fio muito boa ou uma conexão Wi-Fi muito boa em seu escritório, é claro, você verá um tempo de carregamento de dois segundos, mas um usuário real com seu telefone solto provavelmente não está vendo isso. Então, é um desses casos em que nunca é demais tornar seu site mais rápido, mas é muito, muito difícil dizer como seria do ponto de vista interno, pois estamos usando métricas muito específicas que não estão necessariamente mapeando uma para um para o que as ferramentas estão expondo... claro que é importante corrigir isso, porque você não quer que seus usuários esperem em seu site para sempre. Isso vai te machucar. Isso vai prejudicar seus usuários. Isso só vai te machucar na busca. Mas eu não pago -- eu diria apenas olhe para as ferramentas. Se as ferramentas estão dizendo que você está indo bem, então você não deve se preocupar muito com isso. Se as ferramentas estão dizendo que você não está indo muito bem, então eu acho que o tempo gasto para descobrir por que isso diz-- tipo, se o que diz é relevante, é desperdiçado. Você deve sim olhar para tornar o site mais rápido.

O desempenho móvel é um fator muito importante para seus usuários, assim como tudo o mais. Portanto, eu diria que certifique-se de que seu site tenha um bom desempenho em condições do mundo real. Talvez até consiga um telefone barato e experimente o site de vez em quando, e se... isso é algo que eu gosto de fazer, e costumava fazer antes de entrar no Google com a equipe de desenvolvimento com a qual estava trabalhando. Eu estava tipo, olha, você quer usar este site neste telefone? Era como, oh, isso é horrível. Eu estou tipo, mhm, sim, então talvez devêssemos fazer algo sobre isso.

JOHN - No Chrome, você pode configurá-lo e experimentar diferentes velocidades de conexão. Emulador de celular. Eu acho que são coisas muito boas de se ver, e também, tipo, olhar para sua base de usuários. Observe seus dados de análise se você estiver vendo que as pessoas estão usando seu site apenas com um iPhone de última geração, então talvez seja menos problemático do que se você estiver vendo que as pessoas estão se conectando ao seu site a partir de conexões rurais aleatórias, que são lento, e eles têm dispositivos low-end, então talvez seja mais.

Resumo: O Lighthouse mede as velocidades de uma conexão 3G, portanto, a maioria dos sites funcionará muito mais rapidamente do que o exibido aqui na maioria das sessões. Observação: após o término deste hangout, Martin continuou dizendo que é a “primeira pintura de conteúdo” mais importante em relação a possíveis rebaixamentos de classificação.

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.

Vídeo e transcrição completa

Pergunta 1:32 - Eu queria saber se você tem mais alguma orientação ou mais algum ponto de vista sobre testes de uma forma que os SEOs possam usar para serem mais precisos e terem mais confiança em reportar ao negócio. Nós tentamos essa coisa, e isso fez seu impacto. E fizemos isso de uma maneira infalível, mais ou menos da maneira que o Google recomendaria.

Resposta 3:20 - Então, do meu ponto de vista, tento separar as coisas de tipo mais técnico das mudanças de tipo de qualidade. Então, qualquer coisa que seja realmente uma coisa técnica clara, você pode testar se funciona ou não. Não é uma questão de funcionar ou não funcionar, mas muitas dessas coisas técnicas, especialmente quando você está olhando para renderização, ou quando você está olhando para o Google pode realmente indexar esse conteúdo, isso é algo que ou funciona ou não. Onde fica complicado é tudo o que se trata - é indexado, mas como ele aparece nos rankings? E acho que para muito disso, não há uma maneira absoluta de realmente testar isso. Porque se você testar isso em uma situação isolada, como fazer um site de teste, e configurá-lo com as recomendações que tiver, não pode realmente presumir que um site de teste funcionará da mesma maneira que um site normal. Às vezes há coisas simples, como se for um site de teste, então talvez não façamos renderização completa porque achamos que não faz sentido gastar tanto tempo nisso e nisso, porque, tipo, ninguém olha para isso. Ele nunca aparece nos resultados da pesquisa, por que devemos nos preocupar em colocar tantos recursos por trás disso? Considerando que, se você fizesse isso em um site normal, isso funcionaria de maneira muito diferente. Então, isso é algo em que eu realmente não tenho nenhuma orientação clara sobre o que você deve fazer ou o que não deve fazer. Parece mais o tipo de coisa em que você observa as tendências gerais em que vê que o site está aparecendo, as mudanças nas classificações que você vê para essas consultas e tenta aplicar as melhores práticas lá.

Pergunta 5:21 - Então talvez se -- um exemplo concreto talvez você possa usar isso -- talvez isso seja útil, então algo como um teste de tag de título, certo? Se você estivesse fazendo isso-- o que, se alguma coisa, deveríamos procurar? Ou há algo a ser observado para desembaraçar - isso é devido ao nosso teste ou é devido a alguma mudança no servidor, no algoritmo, na dinâmica competitiva? [RISOS] Supondo que estamos fazendo outras coisas para analisar essas externalidades.

Resposta 5:56 - Acho que uma mudança de tag de título é realmente muito complexa do nosso lado, pois há uma interação de o Google usar uma tag de título que você está fornecendo, por um lado, para classificação, por outro outro lado, para mostrar nos resultados da pesquisa. Assim como para computadores e dispositivos móveis, temos uma quantidade diferente de espaço, então podemos mostrar tags de título ligeiramente diferentes. Os usuários podem responder a isso de maneiras diferentes. Então você pode estar classificando da mesma maneira, mas os usuários podem pensar, oh, esta é uma ótima página. Vou mostrá-lo mais alto-- ou vou clicar nele nos resultados da pesquisa porque parece uma ótima página. E então você tem mais tráfego. Mas a classificação é realmente a mesma. Então isso é uma coisa boa? Provavelmente, eu acho. Se você está apenas olhando para o ranking, parece que, bem, você não mudou nada em nada, e acabamos de receber mais tráfego.

Mas isso é algo em que há muitos aspectos diferentes que fluem por aí. Então, isso é algo que eu acho que, como SEO, é útil, por um lado, ter o entendimento técnico do que as coisas aconteceram, mas também ter mais conhecimento de marketing e qualidade de como os usuários reagem à mudança, o que são mudanças de longo prazo que podemos afetar com os usuários, como você pode direcionar isso para garantir que nosso site seja visto como o site mais relevante em situações em que as pessoas estão procurando algo relacionado a isso. E acho que isso é algo muito difícil de testar. É, tipo, mesmo no marketing tradicional, onde eles têm anos e anos de prática, é muito difícil testar, tipo, isso está realmente tendo um grande impacto ou não? É algo em que eles acabam olhando para o quadro geral ou fazendo estudos de usuários, o que você também pode fazer como SEO. Desculpe. [RISADA]

Pergunta 7:58 - Tenho uma pergunta mais direta. Então, vários de nossos sites, você sabe, estão utilizando o Cloudflare, e notamos que eles bloqueiam diretamente o Googlebot, certo? Mas não teve muito impacto em nossos rankings, em nossa visibilidade, etc. Então, tentando descobrir como, tipo, vocês estão usando outro bot para rastrear um índice fora do Googlebot diretamente, e como devemos pensar nisso quando as CDNs estão se esforçando para bloquear o bot?

Resposta 8:33 - Sim, não sei como isso está configurado com o Cloudflare no momento, mas sei que no passado eles costumavam bloquear pessoas que estavam fingindo o Googlebot. Então, se você usa, tipo, seu próprio, eu não sei, Screaming Frog ou algo assim-- você diz, estou usando o agente do usuário do Googlebot, então eles bloqueariam isso porque eles poderiam dizer, tipo, isso não é um agente legítimo Googlebot. Podemos bloquear isso. Mas, na maioria das vezes, acho que eles têm prática suficiente para reconhecer Googlebots normais e permitir que eles rastreiem normalmente.

Pergunta 9:02 - Sim, foi interessante. Porque entrou em contato com vários colegas de outras agências e eles estavam replicando situações semelhantes até mesmo em seu próprio site. Tipo, havia um ticket de suporte no Cloudflare, e isso também estava sendo bloqueado quando eu estava tentando renderizar diretamente do Googlebot ou do smartphone Googlebot.

Resposta 9:21 - OK, sim. Bem, não temos nenhuma solução alternativa. Tipo, se os sites estão nos bloqueando, ficamos meio presos. Mas geralmente se um serviço como o Cloudflare estivesse nos bloqueando por padrão, isso afetaria muitos sites. E nós perceberíamos isso. Provavelmente entraríamos em contato com a Cloudflare sobre algo assim. Pode ser que talvez eles tenham diferentes níveis de serviço. Então é como se você estivesse no nível mais baixo, então é como um serviço gratuito, mas temos um limite com a quantidade de tráfego. Não sei se eles têm algo assim. Isso é algo que eu vi com alguns outros hosters, onde se você tiver uma configuração de hospedagem padrão gratuita, às vezes eles apenas têm um limite de tráfego e bloqueiam as coisas.

MARTIN SPLITT: Você pode não ver isso imediatamente nas estatísticas de sua classificação e outras coisas. Porque basicamente, se temos conteúdo seu, e basicamente, o site não é -- dependendo do que foi bloqueado, neste caso, significa porque eu não vi isso. E administro alguns sites por trás do Cloudflare e não tive nenhum problema. Mas, novamente, não tenho um site gigantesco ou gosto de grandes quantidades de tráfego porque estou no plano gratuito. Isso é-- mas se você não receber um erro do nosso lado, pode ser que estamos mantendo o conteúdo que vimos da última vez. E isso apenas classifica bem, e tudo bem.

Resposta 12:09 - Sim, então acho que o que aconteceria em um caso como o seu é que desaceleraríamos o rastreamento. E tentaríamos manter o conteúdo que podemos buscar mais no índice, e apenas rastrearíamos um pouco mais. Mas isso também significa que, se você fizer alterações em seu site, levará mais tempo para que possamos pegá-las. Se tivermos que rastrear as coisas de forma significativa, como, não sei, AMP, ou você adicionar algo assim em todo o site, tudo isso levará muito mais tempo. Então, se você vê regularmente que não podemos rastrear com um Googlebot normal, isso é algo que eu levo ao host para que possamos ver.

Pergunta 14:01 - Ótimo. Então , eu tenho uma pergunta sobre a ferramenta de rejeição. Então, sempre recebemos pessoas que querem que façamos auditorias de links. E desde o Penguin 4.0, então setembro de 2016, onde Gary Illyes disse, e acho que você disse também, tipo, o Google é muito bom em ignorar links não naturais. Então, meu pensamento na época era, bem, não deveríamos ter que usar a ferramenta de rejeição para pedir ao Google para ignorar links que eles já estão ignorando, a menos que você tenha uma ação manual para links não naturais. Então, nós só o recomendamos para sites que estão ativamente, você sabe, construindo links, tentando manipular coisas, coisas que não são links naturais. Mas eu acho que há muita confusão entre os webmasters porque eu vejo as pessoas o tempo todo, você sabe, cobrando muito dinheiro para auditar-- para rejeitar links que são apenas-- eu sei que eles estão sendo ignorados. Então, eu adoraria se pudéssemos ter um pouco mais de esclarecimento. Então, talvez eu possa dar um exemplo, tipo, se houvesse um empresário que, há alguns anos, contratou uma empresa de SEO, e essa empresa de SEO fez um monte de guest posts apenas para links e, você sabe, coisas que era de qualidade média, se você entende o que quero dizer, não ultra spam, podemos ter certeza de que o Google está ignorando esses links? Ou devemos entrar e repudiar?

Resposta 15:22 - Acho que foi uma boa pergunta. Então, do meu ponto de vista, o que eu olharia é, por um lado, definitivamente o caso é onde há uma ação manual. Mas também, os casos em que você também deseja ver muitas ações manuais diriam, bem, se a equipe de spam da Web analisasse isso agora, eles forneceriam uma ação manual. Tipo dos casos em que você diria, bem, a ação manual é mais uma questão de tempo e não como se fosse baseada em algo que foi feito-- eu não sei-- onde claramente foi feito alguns anos atrás, e era meio que não limítrofe. Mas o tipo de coisa em que você olha para isso e diz, se alguém da equipe de spam na web recebesse isso como uma dica, eles fariam uma ação manual, e esse é definitivamente o tipo de coisa em que eu limparia isso e faria como uma rejeição por isso. Sim, acho difícil dizer se existe uma linha do tempo específica. Mas, em geral, se a equipe do webspam olhasse para isso e dissesse, tipo, as coisas seguiram em frente. Isso foi claramente feito há alguns anos. Não foi totalmente malicioso. Então eles provavelmente não tomariam nenhuma ação manual para isso.

Pergunta 16:43 - E eu estou supondo que você provavelmente não pode responder isso, mas existe alguma maneira de-- tipo, digamos que não obtivemos uma ação manual, ou eles não obtiveram uma ação manual. Esses links podem prejudicá-los algoritmicamente? Porque sentimos que estamos vendo algumas melhorias em alguns sites, você sabe, depois de rejeitar. Então, novamente, eu sei que é sempre -- nunca é preto e branco.

Resposta 17:03 - Isso definitivamente pode ser o caso. Então é algo em que nossos algoritmos quando olhamos para isso e eles vêem, oh, eles são um monte de links muito ruins aqui, então talvez eles sejam um pouco mais cautelosos com relação aos links em geral para o site. Então, se você limpar isso, então os algoritmos olham para isso e dizem, oh, há-- há meio que-- está tudo bem. Não é ruim.

Pergunta 17:24 - Ainda é bom rejeitar basicamente apenas para evitar uma ação manual, correto?

Resposta 17:29 - Acho que se você estiver em um caso em que está realmente claro que a equipe de spam da Web lhe daria uma ação manual com base na situação atual, é isso que eu rejeitaria.

Pergunta 17:37 - Então é bom pensar como no Google -- como se alguém da equipe de spam do Google pensasse, tipo, você sabe, se eles olharem para isso, o que eles fariam se o fizessem?

Resposta 17:47 - Sim.

Pergunta 17:48 - O problema, porém, é que a maioria das pessoas não sabe. Quero dizer, o proprietário médio de uma empresa não sabe quais links a equipe de spam da web usaria -- quer dizer, existem diretrizes, mas é muito -- você sabe, é difícil interpretá-las. Então eu acho-- quero dizer, eu tenho algumas preocupações, mas minha principal preocupação é que há pessoas gastando muito dinheiro em auditorias de links que eu acho que não valem a pena. Por outro lado, podemos não fazer auditorias de links e desautorizar alguns sites que poderiam se beneficiar disso. Então eu adoraria, você sabe, eu acho que o que você disse ajudou muito para que nós -- você sabe, isso é bom.

Resposta 18:22 - Sim, eu acho que para a grande maioria dos sites que meio que tem aquela mistura normal de coisas onde é como se você tivesse seguido alguns maus conselhos no passado, e é como se você tivesse seguido em frente, e as coisas são bem naturais agora, então eles realmente não precisam fazer isso. Esse é o objetivo de tudo isso, e é por isso que a ferramenta de rejeição não é um recurso principal no Search Console. Você meio que procura por isso explicitamente. Isso tudo é feito de propósito porque, para a maioria dos sites, você realmente não precisa se concentrar tanto nos links. O que eu gosto sobre a ferramenta de rejeição, porém, é que se você está preocupado com isso, você ainda pode ir lá e dizer, OK, eu sei que há um punhado de coisas que fizemos alguns anos atrás, e estou muito preocupado com isso. Então repudiá-los, do meu ponto de vista, não é um problema. Eu não sairia e procuraria especificamente por todas essas coisas. Mas se você sabe sobre isso, e você está realmente preocupado com isso, então você pode cuidar disso.

Pergunta 19:27 - Tenho uma pergunta sobre um dos sites de nossos clientes. Então eles têm um clube -- eles têm um clube em três cidades em Nova Gales do Sul. E cada clube tem um subdomínio no site. Agora, quando eles adicionam qualquer página ao site, eles criam a página para cada subdomínio. Então, recentemente, eles adicionaram uma página, que é sobre as atividades do clube, e adicionaram esta página aos seus -- todos os subdomínios. Isso significa que todos os subdomínios têm o mesmo conteúdo, exceto que o título da página é diferente. Porque quando eles adicionam ao -- para Sydney, eles adicionam o nome do local na tag de título. Quando eles adicionam para Newcastle, eles adicionam Newcastle na tag de título, mas o restante do conteúdo da página é o mesmo. Então, será um problema porque eles têm 50 subdomínios e criaram 50 páginas, que têm o mesmo conteúdo, exceto o título?

Resposta 20:36 - Isso soa como algo um pouco ineficiente, eu acho. Então, quero dizer, você já está trazendo isso à tona e meio que dizendo, isso parece algo que poderia ser feito de forma diferente. Acho que se você tem 50 subdomínios com o mesmo conteúdo e está apenas alterando a tag de título, provavelmente não está nos fornecendo muito conteúdo realmente útil. Então, essa é a situação em que eu diria que faz mais sentido combinar as coisas e criar páginas realmente fortes, em vez de diluir as coisas em ainda mais subdomínios.

Pergunta 21:44 - Que tal criar uma página e depois usar a URL canônica para outras páginas de localização. Eu só quero criar uma página, na qual falaremos sobre suas atividades, e usarei o link como uma URL canônica para outras páginas de localização.

Resposta 22:10 - Localização-- sim. Acho que isso pode fazer sentido porque você está combinando as coisas novamente. Então você está fazendo uma página forte em vez de um monte de páginas diluídas.

Pergunta 22:20 - Porque o que acontece quando alguém visita o site, e escolhe a sua localização, automaticamente redireciona essa pessoa para aquele subdomínio para o qual indicou a sua determinada localização. Então, essa é a razão pela qual eles precisam da página nesse subdomínio. Então eu acho que é por isso que se mantivermos uma página e adicionarmos a URL canônica, isso terá -- é a única opção que temos no momento.

Resposta 23:08 - OK, mas acho que se você tem páginas separadas que você precisa ter por motivos técnicos no site, e você coloca canônico, essa é uma boa abordagem.

Pergunta 23:21 - Isso seria como-- como uma empresa que tem várias franquias em locais diferentes que teriam essencialmente o mesmo conteúdo para cada franquia estaria em uma cidade ou município diferente, ou qualquer outra coisa, e tipo de funil isso de seu ponto de vista de volta a uma única página?

Resposta 23:34 - Acho que é sempre um pouco complicado porque você está equilibrando as pessoas que procuram esse tipo de negócio em um local específico com o tipo de página informativa em torno desse negócio diretamente. Então, isso é algo que às vezes faz sentido separar isso para um negócio. Às vezes faz sentido ter informações gerais em um local central e ter apenas como -- como páginas de destino de localização que são mais focadas no endereço, horário de funcionamento, esse tipo de coisa.

Pergunta 24:12 - Sim, eu tenho - eu tenho uma pergunta relacionada ao ponto canônico que você estava fazendo. Essa é uma pergunta que minha equipe e eu temos há vários anos. E ainda não sabemos exatamente a solução. Então, se você está lidando com um grande site de comércio eletrônico com muitos, muitos produtos e muitas, muitas categorias. Digamos que você esteja em uma página de categoria que tenha muitos filtros e facetas diferentes e coisas dessa natureza que alteram um pouco o conteúdo da página, mas talvez não o suficiente para justificar ter seu próprio URL. Mas talvez em alguns casos com certos filtros, justifique ter um URL de site. Então, como você lida com o rastreamento nessa situação? Como funciona uma tag canônica? É uma solução geral criar apenas uma página indexada? Ou você deve olhar, sabe, não indexar certas facetas e filtros, ou usar robôs, ou como você controla isso para grandes sites de comércio eletrônico?

Resposta 24:57 - Isso é complicado. Eu não acho que temos uma orientação muito clara sobre isso no momento. Então, isso é algo em que todos esses diferentes tipos de métodos podem fazer sentido. Em geral, tento evitar usar o robots.txt para isso porque o que pode acontecer é encontrarmos as URLs. Só não sabemos o que está lá. Então, a menos que você esteja realmente vendo problemas que estavam causando muita carga no servidor, eu tento usar coisas como o no index, use o rel canonical. Talvez você use rel no-follow com links internos para afunilar as coisas para deixar um pouco mais claro sobre o que devemos rastrear um índice em vez de usar robots.txt. Mas a decisão sobre quando combinar as coisas em uma página de nível de índice e quando bloqueá-la da indexação, quando guiá-la suavemente para uma URL canônica, isso é realmente complicado às vezes.

Pergunta 25:53 - Porque às vezes os canônicos são ignorados se o conteúdo da página for muito diferente.

Resposta 25:57 - Exatamente. Se o conteúdo for diferente, podemos dizer, bem, são páginas diferentes. Não devemos usar o canônico. Considerando que você pode dizer, bem, isso é realmente algo que eu não quero ter indexado. Talvez um sem índice faça mais sentido do que um canônico. Você também pode combinar os dois. Não recomendamos combiná-los porque é muito complicado para nós dizer, bem, o que você quer dizer? Você está dizendo que são os mesmos, mas um é indexável e o outro não é indexável, então eles não são os mesmos. Mas é algo que eu imagino que ao longo do ano terá alguma orientação clara sobre o que poderia funcionar lá. Mas especialmente com sites de comércio eletrônico realmente grandes, o lado do rastreamento pode ser bastante desafiador.

Pergunta 26:46 - Há um cenário que venho tentando descobrir com alguns dos meus clientes ultimamente. Estamos tentando descobrir por que não podemos descartar essencialmente um site que ainda usa HTTP e parece mais ou menos abandonado porque a página não é atualizada há algum tempo e o conteúdo é antigo, desatualizado e geralmente meio magro, e por isso tenho algumas teorias sobre isso. Parte disso, eu acho, talvez esteja no índice há tanto tempo que vocês meio que têm um fator de confiança construído com eles. E é meio difícil derrubá-los. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Pergunta 42:29 - Era sobre os sites das agências de viagens para viajar. Escolhemos a busca interna para mostrar conteúdo dinâmico, como os 10 hotéis mais baratos da cidade pesquisada, ok? Assim, o quadro da página é carregado em um instante. Mas os 10 resultados de hotéis mais baratos carregam dinamicamente em cerca de 30 segundos desde que a pesquisa foi realizada porque o site tem que realizar essa pesquisa na parte de trás e depois compara e refina os resultados para listar, para o pesquisador, o top 10 mais barato hotéis. Por isso, leva um pouco de tempo para listá-los. Então, agora, o Googlebot vê apenas o plano de fundo da página. Em seguida, esses 10 espaços reservados vazios foram onde os resultados serão carregados um pouco mais tarde após a realização da pesquisa interna. Então, como essa é uma tendência dos sites de viagens trazerem informações o mais atualizadas e precisas possível, estou pensando no que o Google está fazendo sobre isso. Claro, podemos listar algum conteúdo estático nessas páginas como todos os outros sites estão fazendo hoje para o Google, se assim posso dizer. Mas isso meio que anula o propósito do que a maioria dos usuários quer ver agora, fresco e barato.

Resposta 44:00 - Então, se não carregar lá, não podemos indexá-lo. Mas geralmente, é mais uma questão de não conseguirmos processar o JavaScript ou talvez sermos impedidos de acessar o conteúdo lá. Então é algo que você pode fazer de uma maneira que funcione. Não é por design que nunca funcionaria. Então, isso é algo em que você pode se aprofundar nos detalhes usando coisas como o teste de compatibilidade com dispositivos móveis para ver se há erros de JavaScript envolvidos, se as coisas estão bloqueadas e refiná-lo a partir daí. Então não é impossível, mas dá um pouco de trabalho.

Pergunta 44:42 - John, eu me aprofundo nisso para ter certeza de que nada está bloqueado no Google. A única coisa que queremos que o Google faça é esperar um pouco para o conteúdo dinâmico carregar nas páginas, sabe? Este é o próximo passo, se assim posso dizer, porque enquanto esta página não é como uma rolagem sem fim, digamos Facebook, é uma página limitada de 10 resultados. Então é finito. É limitado. A questão é que o Google deveria estar esperando um pouco pelo conteúdo dinâmico. Estou apenas dando um exemplo. Mas tenho certeza de que existem muitos outros exemplos por aí. E porque essa é a tendência das pessoas verem conteúdo dinâmico porque de alguma forma classificam as coisas e o tempo é cada vez menor que elas gastam-- as pessoas gastam cada vez menos tempo nos sites e querem encontrar o mais rápido possível o resultados perfeitos, se assim posso dizer. Eu queria saber se vocês estão olhando para esse aprimoramento.

Resposta 45:55 - Então esperamos um pouco pela renderização. Mas se as pessoas estão impacientes, então isso é um sinal de que você deve ser mais rápido de qualquer maneira. Então, isso é algo em que eu olharia para isso de qualquer maneira. Mas acho que olhando para a captura de tela, todos os itens estavam bloqueados apenas em caixas cinzas. Então isso parece algo que é mais um problema técnico do que apenas um tempo limite, provavelmente.

MARTIN SPLITT : Sim. Eu estava prestes a dizer, tipo, vemos muito conteúdo dinâmico que é indexado sem problemas, mesmo que use JavaScript e outras coisas. Então, se estivermos esgotando o tempo, você pode ter um problema em termos de quanto tempo as pesquisas demoram, e isso também pode refletir em outros lugares. Esperamos um bom tempo para que o conteúdo termine.

Pergunta 46:48 - Você pode - você pode me dar um prazo? Quanto você espera?

MARTIN SPLITT : É muito, muito complicado porque basicamente-- então a coisa é, a razão pela qual não podemos lhe dar um prazo é porque o tempo-- e isso vai soar muito estranho, e tenha paciência comigo por um segundo . O tempo na renderização do Googlebots é especial e não segue necessariamente os princípios de Einstein. [RISOS] Então não posso dizer muito. O que posso dizer é que se a rede está ocupada e a rede é o gargalo, provavelmente estamos esperando, mas esperamos apenas até certo ponto. Então, se você demorar um minuto ou 30 segundos, provavelmente estamos perdendo o tempo no meio. Mas não é difícil - se eu lhe disser 10 segundos, isso pode ou não funcionar. Se eu lhe disser 30 segundos, isso pode ou não funcionar. Então prefiro não dizer um número. O que eu diria, tente colocá-lo o mais rápido possível. E se você não conseguir fazer isso rápido, tente algo como armazenar em cache os resultados da pesquisa para que a pesquisa se torne mais ou menos -- ou a produção dos resultados na página se torne mais e mais -- mais ou menos instantânea. Ou tente a renderização dinâmica do seu lado, que pode ser uma solução alternativa para isso. O que você também pode tentar é tentar colocá-lo no lado do servidor e basicamente tentar gerar o máximo de conteúdo possível na primeira passagem. Isso é algo que também beneficia seus usuários, principalmente se estiverem em redes lentas. Então sim. Desculpe, não tenho uma resposta simples, mas o tempo no Googlebot é divertido.

Resposta 49:29 - Acho que provavelmente depende do que o site realmente faz. Uma das coisas que é complicada com a velocidade na renderização é que podemos armazenar em cache muitas coisas que são enviadas de um servidor mais do que em um navegador, porque podemos usar nosso índice para muitas dessas coisas. Então, às vezes, se o JavaScript estiver armazenado em cache do nosso lado, não precisamos buscá-lo. Então, se você comparar os tempos novamente, não corresponderá ao que o usuário vê. Não corresponderá ao que você vê em webpagetest.org. Então é meio complicado, e para as partes em que sabemos que leva mais tempo, seremos um pouco mais pacientes. Mas fica complicado testar. É por isso que temos todas essas ferramentas de teste agora que mostram o maior número possível de erros para tornar possível descobrir, tipo, não funciona? Às vezes funciona e onde estão às vezes os problemas que surgem?

Pergunta 50:29 - Para sites muito grandes, a ordem dos URLs nos mapas do site XML é importante?

Resposta 50:34 - Não. Não nos importamos. É um arquivo XML. Extraímos todos os dados. Processamos tudo de uma vez.

Pergunta 50:44 - E quanto ao parâmetro de prioridade nos mapas do site?

Resposta 50:47 - Nós não usamos isso. Então, isso é algo que, no começo, pensamos, oh, isso pode ser útil para descobrir com que frequência devemos rastrear páginas. Mas acontece que se você perguntar aos webmasters, eles dizem que tudo é prioridade. É o mais importante. E semelhante também com a frequência de mudança nos mapas do site, onde também notamos que, tipo, as pessoas nos dizem que as coisas estão mudando o tempo todo, mas foi atualizado pela última vez no ano passado. Portanto, se você tiver a frequência de alteração e a data, obteremos essa informação da data de qualquer maneira. Portanto, ignoramos a frequência de mudança.
Pergunta 51:35 - O esquema corporativo deve ser adicionado apenas à página inicial, página de contato ou a todas as páginas?

Resposta 51:42 - Até onde eu sei, é apenas a página inicial. Não sei. Você algum de vocês conhece?

Resposta de Liz 51:4 7 - Deve ser apenas uma página normalmente com organizacional e corporativa. Essa é geralmente a recomendação.

MARTIN SPLITT 52:00 - Eu acho que não importa qual -- não importa tanto quais páginas, assim como não colocar em todas as páginas que você tem, eu acho, é a parte mais importante. Acho que depende de -- se você é um site de notícias, provavelmente faz sentido colocá-lo na página de contato, ou na página sobre, ou algo assim. Considerando que em um site de loja ou restaurante, provavelmente não há problema em colocá-lo na página inicial.

JOÃO 52:20 - Acho que também, neste caso, não importa tanto para nós, porque precisamos encontrá-lo em algum lugar como a página inicial ou a página de contato. Mas se a tivermos em outro lugar, não muda nada para nós. Portanto, a grande coisa a não comparar é a marcação de comentários, onde às vezes vemos pessoas colocando comentários semelhantes em todas as páginas do site com a esperança de obter as estrelas e os resultados de pesquisa para todas as páginas do site. E isso seria ruim para nós. Mas as informações de contato, se você tem isso marcado, é... Não vejo problema nisso.
Pergunta 53:05 - O teste de velocidade do site do Google que estamos usando tem registrado tempos de carregamento de página muito lentos, mas os testes independentes que fizemos com colegas no exterior mostraram um tempo de carregamento de página muito rápido. Essa falsa gravação das medidas do Google afeta a forma como nosso site é classificado no algoritmo do Google?

Marie Haynes: Não é minha pergunta, mas para dar algum contexto, os novos dados do Lighthouse para velocidade de página são muito mais severos do que o Page Speed ​​Insights costumava ser. Então, algo que teve uma pontuação de 80 no Page Speed ​​Insights pode ser um 29 vermelho no Lighthouse. Então essa é uma boa pergunta. Isso pode causar-- porque sabemos que em dispositivos móveis, sites muito lentos podem ser rebaixados. Então, é bom se dissermos, você sabe, se você está no vermelho no teste do Lighthouse, que deveríamos realmente melhorar as coisas porque isso pode causar um rebaixamento ou há um corte?

Resposta 54:07 - Então não temos um mapeamento um-para-um das ferramentas externas e tudo o que usamos para o social. Sim, isso torna muito difícil dizer, mas na pesquisa, tentamos usar uma mistura de dados reais de teste de laboratório, que é como o teste do Lighthouse e os dados de relatório do Chrome UX, onde essencialmente o que que estamos medindo é o que os usuários do site estariam vendo.

MARTIN SPLITT 55:37 - Também é importante ver que o Lighthouse, por exemplo, mede especificamente para uma conexão 3G na extremidade mediana - ou como um telefone de desempenho médio, sim. Então, basicamente, se você estiver usando um Apple McIntosh recente ou um computador Windows rápido recente com uma conexão com fio muito boa ou uma conexão Wi-Fi muito boa em seu escritório, é claro, você verá um tempo de carregamento de dois segundos, mas um usuário real com seu telefone solto provavelmente não está vendo isso. Então, é um desses casos em que nunca é demais tornar seu site mais rápido, mas é muito, muito difícil dizer como seria do ponto de vista interno, pois estamos usando métricas muito específicas que não estão necessariamente mapeando uma para um para o que as ferramentas estão expondo... claro que é importante corrigir isso, porque você não quer que seus usuários esperem em seu site para sempre. Isso vai te machucar. Isso vai prejudicar seus usuários. Isso só vai te machucar na busca. Mas eu não pago -- eu diria apenas olhe para as ferramentas. Se as ferramentas estão dizendo que você está indo bem, então você não deve se preocupar muito com isso. Se as ferramentas estão dizendo que você não está indo muito bem, então eu acho que o tempo gasto para descobrir por que isso diz-- tipo, se o que diz é relevante, é desperdiçado. Você deve sim olhar para tornar o site mais rápido.

O desempenho móvel é um fator muito importante para seus usuários, assim como tudo o mais. Portanto, eu diria que certifique-se de que seu site tenha um bom desempenho em condições do mundo real. Talvez até consiga um telefone barato e experimente o site de vez em quando, e se... isso é algo que eu gosto de fazer, e costumava fazer antes de entrar no Google com a equipe de desenvolvimento com a qual estava trabalhando. Eu estava tipo, olha, você quer usar este site neste telefone? Era como, oh, isso é horrível. Eu estou tipo, mhm, sim, então talvez devêssemos fazer algo sobre isso.

JOHN - No Chrome, você pode configurá-lo e experimentar diferentes velocidades de conexão. Emulador de celular. Eu acho que são coisas muito boas de se ver, e também, tipo, olhar para sua base de usuários. Observe seus dados de análise se você estiver vendo que as pessoas estão usando seu site apenas com um iPhone de última geração, então talvez seja menos problemático do que se você estiver vendo que as pessoas estão se conectando ao seu site a partir de conexões rurais aleatórias, que são lento, e eles têm dispositivos low-end, então talvez seja mais.