Horário de atendimento SEO, 1º de julho de 2022

Este é um resumo das perguntas e respostas mais interessantes do Google SEO Office Hours com John Mueller em 1º de julho de 2022.

PageSpeed ​​Insights ou Google Search Console ‒ qual é mais preciso?

0:44 “Quando verifico minha pontuação no PageSpeed ​​Insights no meu site, vejo um número simples. Por que isso não corresponde ao que vejo no Search Console e no relatório Core Web Vitals? Qual desses números está correto?”

De acordo com John: “[…] Não existe um número correto quando se trata de velocidade – quando se trata de entender o desempenho do seu site para seus usuários. No PageSpeed ​​Insights, por padrão, acredito que mostramos um único número que é uma pontuação de 0 a 100, que se baseia em várias suposições em que assumimos que coisas diferentes são um pouco mais rápidas ou mais lentas para os usuários. E com base nisso, calculamos uma pontuação.

No Search Console, temos as informações do Core Web Vitals , que se baseiam em três números para velocidade, capacidade de resposta e interatividade. E esses números são um pouco diferentes, é claro, porque são três números, não apenas um número. Mas, também, há uma grande diferença na forma como esses números são determinados. Ou seja, há uma diferença entre os chamados dados de campo e dados de laboratório.

Dados de campo são o que os usuários viram quando acessaram seu site. E é isso que usamos no Search Console. Isso é o que usamos para a Pesquisa também. Considerando que os dados de laboratório são uma visão teórica do seu site, onde nossos sistemas têm certas suposições onde eles pensam, bem, o usuário médio provavelmente é assim, usando esse tipo de dispositivo e com esse tipo de conexão, talvez. E com base nessas suposições, estimaremos quais podem ser esses números para um usuário médio. Você pode imaginar que essas estimativas nunca serão 100% corretas.

Da mesma forma, os dados que os usuários viram ‒ que também mudarão com o tempo, onde alguns usuários podem ter uma conexão muito rápida ou um dispositivo rápido, e tudo é rápido em seu site ou quando eles visitam seu site, e outros podem não tem isso. E por isso, essa variação sempre pode resultar em números diferentes.

Nossa recomendação geralmente é usar os dados de campo, os dados que você veria no Search Console, como forma de entender qual é a situação atual do nosso site e, em seguida, usar os dados do laboratório, ou seja, os testes individuais que você pode executar diretamente você mesmo, para otimizar seu site e tentar melhorar as coisas. E quando você estiver muito satisfeito com os dados de laboratório que está obtendo com a nova versão do seu site, com o tempo, poderá coletar os dados de campo, o que acontece automaticamente, e verificar novamente se os usuários os consideram mais rápidos ou mais responsivo, também.

Então, resumindo, novamente, não existe um número correto quando se trata de qualquer uma dessas métricas. […] Mas, em vez disso, há diferentes suposições e diferentes maneiras de coletar dados, e cada uma delas é sutilmente diferente.”

Por que o Googlebot tem dificuldades para indexar páginas baseadas em JavaScript?

4:19 “Temos algumas páginas de clientes usando Next.js sem um arquivo robots.txt ou mapa do site. Teoricamente, o Googlebot pode alcançar todas essas páginas, mas por que apenas a página inicial está sendo indexada? Não há erros ou avisos no Search Console. Por que o Googlebot não encontra as outras páginas?”

John disse: “[…] Next.js é uma estrutura JavaScript, o que significa que a página inteira é gerada com JavaScript. Mas uma resposta geral, também, para todas essas perguntas como, por que o Google não indexa tudo – é importante primeiro dizer que o Googlebot nunca indexará tudo em um site. Eu não acho que aconteça com qualquer site de tamanho não trivial que o Google vá e indexe completamente tudo. Do ponto de vista prático, não é possível indexar tudo em toda a web. Então essa suposição de que a situação ideal é que tudo está indexado ‒ eu deixaria isso de lado e diria que você quer que o Googlebot se concentre nas páginas importantes.

A outra coisa, porém, que ficou um pouco mais clara quando, eu acho, a pessoa entrou em contato comigo no Twitter e me deu um pouco mais de informações sobre seu site, foi que a forma como o site estava gerando links para as outras páginas era de uma forma que o Google não foi capaz de pegar. Então, em particular, com JavaScript, você pode pegar qualquer elemento em uma página HTML e dizer, se alguém clicar nele, então execute este pedaço de JavaScript. E esse pedaço de JavaScript pode ser navegar para uma página diferente, por exemplo. E o Googlebot não clica em todos os elementos para ver o que acontece, mas, em vez disso, procuramos links HTML normais, que é a maneira tradicional e normal de vincular páginas individuais em um site.

E, com esse framework, ele não gerou esses links HTML normais. Portanto, não conseguimos reconhecer que há mais para rastrear, mais páginas para ver. E isso é algo que você pode corrigir na maneira como implementa seu site JavaScript. Temos uma tonelada de informações no site Search Developer Documentation sobre JavaScript e SEO, em particular, sobre o tópico de links, porque isso aparece de vez em quando. Existem muitas maneiras criativas de criar links, e o Googlebot precisa encontrar esses links HTML para que funcione. […]”

E, exceto a documentação oficial do Google, confira o Ultimate Guide to JavaScript SEO em nosso blog. “

Os links para páginas HTTP influenciam o SEO do seu site?

7:35 “Afeta negativamente minha pontuação de SEO se minha página estiver vinculada a um site externo inseguro? Então, em HTTP, não HTTPS.”

John disse: “Primeiro, não temos uma noção de pontuação de SEO, então você não precisa se preocupar com a pontuação de SEO.

Mas, independentemente disso, entendo que a pergunta é como: é ruim se eu linkar para uma página HTTP em vez de uma página HTTPS. E, do nosso ponto de vista, está perfeitamente bem. Se essas páginas estiverem em HTTP, é para isso que você vincularia. Isso é o que os usuários esperariam encontrar. Não há nada contra links para sites como esse. Não há desvantagem para o seu site evitar links para páginas HTTP porque elas são antigas ou grosseiras e não tão legais quanto em HTTPS. Eu não me preocuparia com isso.”

Você deve excluir seu arquivo de rejeição?

10:16 “Nos últimos 15 anos, rejeitei mais de 11.000 links no total. […] Os links que eu rejeitei podem ter sido de sites invadidos ou de conteúdo sem sentido gerado automaticamente. Como o Google agora afirma ter ferramentas melhores para não incluir esses tipos de links invadidos ou com spam em seus algoritmos, devo excluir meu arquivo de rejeição? Existe algum risco ou desvantagem em apenas excluí-lo?”

John respondeu: “[…] Rejeitar links é sempre um desses tópicos complicados, porque parece que o Google provavelmente não está informando todas as informações.

Mas, do nosso ponto de vista, […] trabalhamos muito para evitar levar esses links em consideração. E fazemos isso porque sabemos que a ferramenta Disavow links é uma ferramenta de nicho, e os SEOs sabem disso, mas a pessoa média que administra um site não tem ideia sobre isso. E todos esses links que você mencionou são o tipo de links que qualquer site recebe ao longo dos anos. E nossos sistemas entendem que essas não são coisas que você está tentando fazer para enganar nossos algoritmos.

Então, desse ponto de vista, se você tem certeza de que não há nada em torno de uma ação manual que você teve que resolver em relação a esses links, eu excluiria o arquivo de rejeição e […] deixaria tudo isso de lado. Uma coisa que eu faria pessoalmente é baixá-lo e fazer uma cópia para que você tenha um registro do que excluiu. Mas, caso contrário, se você tiver certeza de que essas são apenas as coisas normais e grosseiras da Internet, eu excluiria e seguiria em frente. Há muito mais para gastar seu tempo quando se trata de sites do que apenas repudiar essas coisas aleatórias que acontecem com qualquer site na web.”

É melhor bloquear o rastreamento com robots.txt ou a metatag robots?

14:19 “O que é melhor: bloquear com robots.txt ou usar a metatag robots na página? Como podemos evitar o rastreamento?”

John: “[…] Fizemos um episódio de podcast recentemente sobre isso também. Então eu verificaria isso. […]

Na prática, há uma diferença sutil aqui onde, se você trabalha com SEO e já trabalhou com mecanismos de busca, provavelmente já entende isso. Mas para as pessoas que são novas na área, às vezes não está claro exatamente onde estão todas essas linhas.

Com o robots.txt, que é o primeiro que você mencionou na pergunta, você pode bloquear o rastreamento. Assim, você pode impedir que o Googlebot veja suas páginas. E com a metatag robots, quando o Googlebot examina suas páginas e vê essa metatag robots, você pode fazer coisas como bloquear a indexação. Na prática, ambos fazem com que suas páginas não apareçam nos resultados da pesquisa, mas são sutilmente diferentes.

Então, se não podemos rastejar, não sabemos o que estamos perdendo. E pode ser que digamos, bem, na verdade, há muitas referências a esta página. Talvez seja útil para algo. Nós não sabemos. E então esse URL pode aparecer nos resultados da pesquisa sem nenhum conteúdo porque não podemos vê-lo. Considerando que com a metatag robots, se pudermos olhar para a página, podemos olhar para a metatag e ver se há um noindex lá, por exemplo. Em seguida, paramos de indexar essa página e a eliminamos completamente dos resultados da pesquisa.

Portanto, se você está tentando bloquear o rastreamento, definitivamente, o robots.txt é o caminho a seguir. Se você não quiser que a página apareça nos resultados da pesquisa, eu escolheria o que for mais fácil de implementar. Em alguns sites, é mais fácil definir uma caixa de seleção dizendo que não quero que esta página seja encontrada na Pesquisa e, em seguida, adiciona uma metatag noindex. Em outros, talvez editar o arquivo robots.txt seja mais fácil. [Isso] depende do que você tem lá.”

Você pode colocar o mesmo URL em vários arquivos de mapa do site?

16:40 “ Existem implicações negativas em ter URLs duplicados com atributos diferentes em seus sitemaps XML? Por exemplo, um URL em um sitemap com uma anotação hreflang e o mesmo URL em outro sitemap sem essa anotação.”

John disse: “[…] Do nosso ponto de vista, isso está perfeitamente bem. […] Isso acontece de vez em quando. Algumas pessoas têm anotações hreflang em arquivos de mapa do site separados especificamente e, em seguida, eles também têm um arquivo de mapa do site normal para tudo. E há alguma sobreposição aí.

Do nosso ponto de vista, processamos esses arquivos de mapa do site da maneira que podemos e levamos todas essas informações em consideração. Não há desvantagem em ter o mesmo URL em vários arquivos de mapa do site.  

A única coisa que eu tomaria cuidado é que você não tenha informações conflitantes nesses arquivos de mapa do site. Então, por exemplo, se com as anotações hreflang, você está dizendo, esta página é para a Alemanha, e então no outro arquivo de mapa do site, você está dizendo, bem, na verdade, esta página também é para a França, […] então nosso sistemas podem ser como, bem, o que está acontecendo aqui? Não sabemos o que fazer com essa mistura de anotações. E então pode acontecer de escolhermos um ou outro.

Da mesma forma, se você diz que esta página foi alterada pela última vez há 20 anos […], e no outro arquivo de mapa do site, você diz, bem, na verdade, foi há cinco minutos. Então nossos sistemas podem olhar para isso e dizer, bem, um de vocês está errado. Não sabemos qual. Talvez sigamos um ou outro. Talvez ignoremos completamente a data da última modificação. Então é isso que se deve ficar atento.

Mas, caso contrário, se forem mencionados vários arquivos de mapa do site e as informações forem consistentes ou funcionarem juntas, talvez um tenha a data da última modificação, o outro tenha as anotações hreflang, tudo bem.”

Como impedir que as páginas de vídeo incorporadas sejam indexadas?

19:00 “Sou responsável por uma plataforma de replay de vídeo, e nossas incorporações às vezes são indexadas individualmente. Como podemos evitar isso?”

John respondeu: “[…] Eu olhei para o site, e estes são iframes que incluem uma página HTML simplificada com um player de vídeo embutido nela.

Do ponto de vista técnico, se uma página tiver conteúdo iframe, veremos essas duas páginas HTML. E é possível que nossos sistemas tenham indexado ambas as páginas HTML porque são páginas HTML separadas. Um está incluído no outro, geralmente, mas teoricamente eles também podem ficar por conta própria.

E há uma maneira de evitar isso, que é uma combinação relativamente nova com metatags de robôs que você pode fazer, que é com a metatag de robôs indexifembedded junto com uma metatag de robôs noindex .

E na versão incorporada, para o arquivo HTML com o vídeo diretamente nele, você adicionaria a combinação de metatags noindex plus indexifembedded robots. E isso significaria que, se encontrássemos essa página individualmente, veríamos que há uma [tag] noindex. Não precisamos indexar isso.

Mas com o indexifembedded, ele nos diz que […] se encontrarmos esta página com o vídeo incorporado no site geral, podemos indexar esse conteúdo de vídeo, o que significa que a página HTML individual não seria indexada. Mas a página HTML com a incorporação, com as informações do vídeo, seria indexada normalmente. Então essa é a configuração que eu usaria lá. E esta é uma metatag de robôs relativamente nova, então é algo que nem todo mundo precisa. Porque essa combinação de conteúdo iframe ou conteúdo incorporado é rara. Mas, para alguns sites, faz sentido fazer assim.”