One click at a time

Technical SEO Exam III

Maratona de Certificação
Technical SEO Exam III

Hora do treinamento!
 One click at a time

Desempenho da Web (continuação)

Noções Básicas de Velocidade do Site: Client-side
 Otimizações de desempenho - Client Side
Vamos começar com uma solicitação HTTP. O que acontece quando você acessa o site no seu
navegador? Muitos componentes diferentes serão baixados em segundo plano - imagens, arquivos ССS,
JS e outros. A grande quantidade deles aumentou significativamente ao longo dos anos, à medida que
os sites se tornaram mais complexos. Em média, temos 300kb de código JS que é usado em todas as
páginas e até 6 arquivos ССS diferentes por URL. O que é realmente muito.

A maneira mais fácil de corrigir isso é pensar em como reduzir o grande número dessas coisas,
mesclando, excluindo etc. Você não precisaria de 6 arquivos CCS diferentes; você certamente preferiria
ter 1 ou talvez 2.

Um dos conceitos comuns que devem ser aplicados aqui é a minificação de arquivos, o que significa
reduzir os arquivos CCS e JS, por exemplo. Encurta variáveis e remove quebras de linha desnecessárias.
 Otimizações de desempenho - Client Side

Você precisa decidir, realmente precisa solicitar os arquivos ao acessar a página ou pode fazê-lo em
segundo plano? Pense em solicitações assíncronas e se você pode usá-las para beneficiar seu
desempenho. Quando você solicita um arquivo JS, por exemplo, ele impede que a renderização ocorra e
o navegador não pinta algo na tela.

Você poderia dizer ao navegador para processar JS em segundo plano (o que chamamos de
assíncrono), mas não espere que ele volte. Esse é um conceito usado pelo Google para o Google
Analytics. A idéia é disparar o JS, mas não necessariamente esperar que eles voltem.
Lembrar:

01 Em primeiro lugar, para reduzir o número de solicitações, tente fazer as restantes o

menor possível.

Em seguida, pense sobre quais você pode executar de forma assíncrona para
02 impedir o bloqueio da renderização.
 Otimizações de desempenho - Client Side

As imagens representam aproximadamente 60% de todo o tráfego da web. O problema é que muitas
vezes as imagens não são otimizadas. Essas imagens têm metadados que normalmente não são
compactados adequadamente e, às vezes, são do tipo de arquivo errado. A regra geral para imagens é
colocá-las em uma compactação adequada. Existem boas ferramentas, como tinyPNG e tinyJPG , nas
quais você pode otimizar suas imagens gratuitamente e cortar todo esse tamanho de arquivo
desnecessário.

No entanto, jpg, gif, png não são os formatos mais modernos. Anos atrás, o Google iniciou o webP. A
ideia era criar um formato que faça tudo de uma vez. É muito eficiente, menor que os outros, mantendo
todos os recursos dos formatos mencionados anteriormente. Geralmente funciona bem, mas ainda não
é amplamente suportado e, no momento, apenas o Chrome pode gerar webPs.
 Otimizações de desempenho - Client Side

A solução alternativa seria usar algo como uma CDN de imagem, por exemplo, cloudinary. Com o
cloudinary, eles criam tipos de arquivos modernos como webP e jpg-xr para você, em segundo plano.
Eles os colocam no servidor e, quando alguém está acessando seu site, eles tentam entender se o
dispositivo (nesse caso, o Chrome) ofereceria suporte ao webP e, em seguida, veicular dinamicamente o
novo formato/arquivo. Se fosse o navegador Edge da Microsoft, eles mostram jpeg-xr.

A otimização de imagem e, em particular, os formatos modernos são ótimos e realmente úteis se você
tiver um site com imagens pesadas, como galerias de fotos ou páginas de listagem de produtos com
muitas imagens. A otimização da imagem pode fazer uma enorme diferença e economias de até 80% se
tornam facilmente alcançáveis. Mas certifique-se de acertar o básico. Investigue o tipo de imagem que
você está usando, se estiver compactado corretamente, mas também veja os formatos novos e
modernos.
Escolha uma abordagem de otimização ineficaz.
Escolha uma abordagem de otimização ineficaz.
Usando imagens de boa resolução e tamanho real

As imagens em tamanho real têm metadados que

normalmente não são compactados corretamente.
Noções Básicas de Velocidade do Site: Server-side
 Otimizações de desempenho - Server Side

Outra coisa sobre a qual precisamos falar é o backend ou o lado do servidor - essencialmente sua
infraestrutura. A otimização do desempenho também depende muito de quais sistemas você está
executando, como eles estão interconectados etc.

Para profissionais de marketing menos técnicos, é particularmente importante entender que a

otimização não deve ser feita apenas no front-end, como abordado anteriormente, mas também no
back-end. Portanto, você também precisa envolver sua TI e garantir que eles tenham tópicos de
otimização de desempenho em seu radar.
Algumas perguntas para você começar e coisas que você precisa entender:

Quais servidores da Web você está usando e eles são os mais adequados para o que você
01 deseja alcançar? Por exemplo, o Apache é totalmente diferente do nginx.

Como é o seu banco de dados e sua estrutura para lidar com as consultas que eles precisam
02 responder?

03 Você está executando um banco de dados MySQL e está usando algum tipo de cache?

Ou você está executando totalmente o HTTPS? Em seguida, você deve ativar o grampeamento
04 OSCP.

Tem certeza de que está aproveitando o cache do navegador corretamente? Você já considerou
05 o cache do EDGE?
 Otimizações de desempenho - Server Side

Se você tiver muitas imagens e outros arquivos estáticos, considere usar uma CDN ou pelo menos um
servidor de ativos altamente otimizado. Um servidor de ativos geralmente deve ser sem cookies e
otimizado para fornecer estatísticas o mais rápido possível - para que o nginx possa ser um bom ponto
de partida. Geralmente, uma CDN como o Cloudflare seria uma abordagem muito boa para descarregar
arquivos estáticos que você possui no servidor de aplicativos.

Ter arquivos estáticos no servidor de aplicativos geralmente é muito mais lento do que colocá-los na
CDN. Isso também ajuda os visitantes internacionais, pois as CDNs geralmente distribuem de pontos
muito diferentes do mundo. A latência para seus usuários diminui significativamente.
 Otimizações de desempenho - Server Side

Isso está relacionado a algo chamado Time to First Byte (ou TTFB). Ele mede a capacidade de resposta
de um servidor da Web: a quantidade de tempo entre a criação de uma conexão e o download do
conteúdo de uma página da Web e o envio de volta.

O Google diz que não o está usando nos rankings de busca em si, mas ainda é importante.
Se a latência for super alta, nada vai acontecer e as pessoas simplesmente vão embora -
porque seu site não responde. Sem chance de permanecerem para sempre - o TTFB importa!
 Otimizações de desempenho - Server Side

Uma das ferramentas realmente legais e gratuitas está disponível em keycdn.com. Eles têm uma
ferramenta de teste TTFB global, que verifica o desempenho do seu site em 14 locais diferente
ao redor do mundo de uma. Eles medem o tempo de DNS, TTFB e handshakes. Se você olhar para os
números médios e conseguir gerenciar abaixo de 200 milissegundos, isso seria bom. 500 ms já é muito
longo, 1 segundo ou mais está ruim.

Otimizar o TTFB é algo que você, como SEO, nem sempre pode fazer por si mesma(o). Geralmente,
é relacionado à infraestrutura ou ao servidor; portanto, converse com a equipe de TI se seus números
forem ruins.
 Otimizações de desempenho - Server Side

Você precisa ter certeza de que o cache funciona bem. Certifique-se de enviar os cabeçalhos de
armazenamento em cache adequados e de aproveitar o fato de que, para a segunda solicitação, a
maioria das solicitações de imagens, СSS, JS etc, será armazenada localmente no navegador.

Uma boa abordagem é utilizar o Webpagetest.org e ver se as regras de cache estão eficientes e bem
configuradas. Se alguma imagem não for armazenada em cache por pelo menos alguns dias, isso
deverá ser alterado mais cedo ou mais tarde.
 Otimizações de desempenho - Server Side

Outro conceito poderoso para tornar os sites mais rápidos é considerar a pré-busca e a renderização. É
especialmente verdade se você depende de solicitações ou conteúdos de terceiros. Você solicita dados
de uma CDN ou subdomínio, por exemplo? Você pode buscar previamente a pesquisa de DNS nesse
host de terceiros. Basicamente, em segundo plano, ele garante que o endereço IP do host já tenha sido
resolvido; portanto, quando a primeira solicitação for encerrada, ele será mais rápido, pois o navegador
não precisará aguardar a execução da pesquisa de DNS.

Se você der um passo adiante e estiver executando o HTTPS, poderá não apenas buscar previamente,
mas também conectar-se, o que cuida do handshake de certificado e do processo de validação. A idéia é
estar ciente de onde os dados vêm e fazer todo o tipo de trabalho necessário em segundo plano para
acelerar as coisas quando você estiver solicitando dados pela primeira vez.
Escolha uma declaração incorreta sobre TTFB:
Escolha uma declaração incorreta sobre TTFB:
 TTFB não é uma empresa que oferece serviços CDN. Mais uma coisa a saber sobre o TTFB
é que, se a latência for super alta, as pessoas simplesmente sairão porque seu site não responde.
HTTPS, SSL e HTTP/2
 HTTPS e HTTP/2
Obviamente, também precisamos falar sobre HTTPS ao cobrir o desempenho de sites. Não porque isso
tenha algo a ver diretamente com a otimização do desempenho, mas porque é necessário, no nível do
navegador, servir páginas que estão em execução no novo protocolo HTTP/2. Ou o contrário - se você
usa HTTPs, quase não há razão para não aproveitar o novo protocolo HTTP/2.

HTTPS é algo que o Google defendia fortemente no passado. As estatísticas mais recentes do SEMrush
Sensor dizem que 60% ou mais de todos os resultados para consultas de palavras-chave de alto volume
no TOP-3 já foram movidos para execução em HTTPS.

Obviamente, isso depende da indústria; certamente o financiamento é diferente da publicação, mas,

ainda assim, o HTTPS era algo sobre o qual o Google tem falado muito. Isso chegou ao ponto de
dizerem que esse é um fator de classificação ou, pelo menos, eles dão um pequeno impulso às páginas
que foram realmente transferidas para HTTPs. O Google afirma oficialmente que algo é realmente um
fator de classificação, que raramente aconteceu no passado.
 HTTPS e HTTP / 2

Uma coisa realmente importante é que, ao mudar para HTTPs, você também deve começar a
implementar uma implementação do HTTP2 imediatamente - já que o design do HTTPS é ainda mais
lento que o HTTP. Os principais motivos são a validação de certificado e o handshake para estabelecer
uma conexão segura - o que acontecerá desde o início.

Ele adiciona alguns milissegundos por design e não há nada que você possa fazer sobre isso. Em vez
disso, você deve informar sua equipe de TI adequadamente e garantir que eles implementem o HTTP2
desde o início. Para o pessoal de TI, realmente não é muito trabalho. O servidor faz tudo e existe esse
fallback padrão de qualquer maneira. Portanto, é principalmente uma questão de ativá-lo - mas faz muito
sentido, pois o protocolo é muito mais rápido!
 HTTPS e HTTP / 2

A outra grande coisa que aconteceu foi quando o Google mudou a maneira como lidava com sites não
seguros no Chrome. Anteriormente, o Google começava a sinalizar os campos de formulário que
estavam em URLs HTTP, mas estavam recebendo dados de certa forma confidenciais, como dados
pessoais de usuários, dados de cartão de crédito, etc. Agora, o Google está mudando o comportamento
do Chrome novamente. Eles começarão a sinalizar cada URL HTTP único como não seguro.

Você realmente não quer gastar tempo explicando aos seus usuários por que o Google acha que seu
site não é seguro - isso claramente será um fator de conversão. E, na pior das hipóteses, poderia ir tão
longe que o Google também refletisse isso nos resultados de pesquisa; ou no futuro talvez apenas os
resultados HTTPs sejam mostrados?
 HTTPS e HTTP / 2

O bom é que os HTTPs são relativamente fáceis de implementar. Além disso, o trabalho de migração
envolvido, devido à alteração do protocolo, é relativamente direto da perspectiva de SEO. Se você fizer o
que é certo e seguir as melhores práticas, não deverá esperar perdas significativas.
Uma coisa realmente importante é que, ao mudar para HTTPs, você também deve começar a
implementar uma implementação do HTTP2 imediatamente - já que o design do HTTPS é ainda mais
lento que o HTTP.
 HTTPS e HTTP / 2

Os principais motivos são a validação de certificado e o handshake para estabelecer uma conexão
segura - o que acontecerá desde o início. Ele adiciona alguns milissegundos por design e não há nada
que você possa fazer sobre isso. Em vez disso, você deve informar sua equipe de TI adequadamente e
garantir que eles implementem o HTTP2 desde o início. Para o pessoal de TI, realmente não é muito
trabalho. O servidor faz tudo e existe esse fallback padrão de qualquer maneira. Portanto, é
principalmente uma questão de ativá-lo - mas faz muito sentido, pois o protocolo é muito mais rápido!
 HTTPS e HTTP / 2

Há algumas coisas que mudaram em relação às melhores práticas de como implementar a otimização
de desempenho para HTTP2. O principal fator é que o HTTP2 funciona usando fluxos em vez de com
solicitações únicas.

No HTTP1.1, solicitamos diferentes arquivos CSS, JS etc., e todos voltaram um por um. Com o HTTP2,
o servidor abre um fluxo, e esse fluxo pode manipular vários arquivos com diferentes prioridades ao
mesmo tempo.

O HTTP2 também apresenta alguns novos recursos, como envio de servidor. Existem algumas coisas
no plano de fundo das quais é preciso estar ciente para se beneficiar totalmente.
 HTTPS e HTTP / 2

Existem algumas coisas muito antigas, como sprites CSS - nesses casos, é questionável se elas ainda
fazem sentido agora ou não. Definitivamente não perca tempo construindo-os. Você também deve se
livrar do sharding de domínio - vários subdomínios que permitem mais solicitações paralelas ao mesmo
tempo - isso realmente não funciona com o HTTP2.

O Googlebot ainda está rastreando usando o antigo protocolo HTTP1.1, lembre-se disso. Há muitas
discussões sobre quando isso vai mudar. A data de lançamento ainda não está confirmada. Com o
fallback integrado de HTTP2 para 1.1. no entanto, isso realmente não importa. Se você ainda não migrou
para o HTTPS, certifique-se de fazê-lo e também introduza o HTTP2 imediatamente. Se você já está no
HTTPS, verifique se o HTTP2 está sendo executado em segundo plano.
Se você estiver migrando seu site para HTTPS em um futuro próximo ou tiver
acabado de mudar para ele, use o relatório de implementação HTTPS na
ferramenta SEMrush Site Audit. Usando o relatório, você descobrirá:

01 Se seus certificados de segurança são atuais e registrados para corrigir nomes.

Se o seu servidor suportar os protocolos de segurança necessários e se eles estão

02 atualizados.

03 Se o seu site contiver elementos que não sejam protegidos com HTTPS.
Escolha três respostas. Por que é altamente recomendável
implementar o HTTP / 2 ao mudar para HTTPS?
Escolha três respostas. Por que é altamente recomendável
implementar o HTTP / 2 ao mudar para HTTPS?
As métricas existentes refletem como o carregamento
da página se sente para um usuário real.
Otimização avançada da velocidade do site:
imagens, fontes personalizadas, CRP
 Medições e otimizações realizadas
que vão muito além do básico

Uma das grandes coisas que aconteceu no ano passado é que passamos de uma única métrica, como a
pontuação do PageSpeed Insights do Google, para algo muito mais complexo, mas também mais
reflexivo de como o carregamento da página se sente para um usuário real. Portanto, a ideia é traduzir
diferentes estágios e experiências do usuário em métricas de desempenho múltiplo.

A maneira mais fácil de visualizar isso é acessar as Ferramentas do desenvolvedor do Chrome. Há uma
seção no desempenho e, em seguida, você seleciona o perfil da guia. Nesta seção, você pode ver todos
os tempos de pintura gravados e procurá-los como imagens independentes. Você pode rolar pela linha
do tempo e entender como o site fica a cada milissegundo - muito legal.
A equipe do Google Chrome fez muitos esforços para introduzir
métricas que fazem a diferença e refletem a jornada do usuário:

Eles introduziram o Time To First Paint, que é o ponto em que o navegador começa a
01 renderizar algo, o primeiro bit de conteúdo na tela.

02 Hora da primeira pintura com conteúdo marca o momento em que o navegador renderiza o
primeiro bit de conteúdo do DOM, como texto, imagem, etc.

A Primeira Pintura Significativa (o elemento herói) é a pintura após a qual ocorreu a maior
03 alteração de layout acima da dobra e seu elemento mais importante é visível.
 Medições e otimizações realizadas
que vão muito além do básico

Se você quiser dimensionar um pouco mais e obter dados do mundo real, use o Performance Observer no
Chrome. É uma extensão do seu snippet normal do Google Analytics. Você acabou de integrar o snippet
do Google Analytics como de costume e, com algumas linhas de código JS adicionais, registra o
Performance Observer. O próprio Performance Observer controla os tempos de pintura mencionados
anteriormente; e as armazena como métricas personalizadas no seu Google Analytics.

Você pode detalhá-lo por URL e ver as métricas médias de tempo de pintura para cada URL. No momento,
isso só funciona no Chrome, mas ainda oferece uma perspectiva muito boa sobre a rapidez com que seu
site está funcionando no mundo real com base em usuários reais. Dá pra fazer também pelo Google Tag
Manager.
 Medições e otimizações realizadas
que vão muito além do básico

Recentemente, o Google introduziu uma nova métrica chamada First Input Delay (FID) , que mede o tempo
desde que um usuário interage com seu site (ou seja, quando ele clica em um link, toca em um botão ou
usa um controle personalizado baseado em JavaScript) até o momento em que o navegador
é capaz de responder a essa interação. Estamos caminhando para avaliar coisas que afetam o
comportamento do mundo real de como os usuários interagem com seu site.

O rastreamento do FID é o mesmo dos tempos de pintura. Você usa o Google Analytics e estende o
snippet adequadamente para que o JS possa gravar tudo. Tudo isso é útil se você deseja otimizar seu
caminho crítico de renderização - e absolutamente deveria, porque é uma estratégia super poderosa.
 Como otimizar seu CRP
Simplificando, quando o navegador solicita um site, ele precisa criar um Modelo de Objeto CSS que seja
um "mapa" de informações da folha de estilo, que será anexado aos elementos e tags encontrados na
marcação de uma página da web.

De uma perspectiva de renderização, o navegador primeiro pega o HTML e cria o DOM e, em seguida, o
navegador pega CSS e cria o modelo de objeto CSS mencionado anteriormente. O próximo passo é
combinar o DOM e o CSSOM para criar a chamada árvore de renderização. Somente então o navegador
pode exibir a página da web no navegador. Se arquivos CSS externos estiverem envolvidos, o navegador
precisará aguardar até que o download ocorra - o que pode levar algum tempo, dependendo de quão
otimizados eles são.
 Otimizando seu CRP (caminho crítico de renderização)

Se você deseja acelerar esse processo, pode usar a ferramenta gratuita no Github, chamada Critical. Ele
renderiza seu site em diferentes resoluções, para que você possa tomar as cinco principais resoluções do
Analytics e criar dois arquivos CSS, um que contém o CSS necessário para a sua visão crítica e outro para
tudo o que estiver abaixo da dobra.

Do ponto de vista da implementação, você incorporaria seu CSS crítico diretamente na marcação, mas
também carregaria um CSS não crítico de forma assíncrona e o aplicaria assim que terminasse de
carregar com uma diretiva rel = "preload", que impede a navegador de bloquear.
 Otimizando seu CRP (caminho crítico de renderização)

Você pode fazer isso, pois o CSS não crítico não

é necessário quando o site começa a renderizar;
é usado apenas quando as pessoas começam a
rolar para baixo - portanto, ele será aplicado
somente quando o carregamento for concluído.

Essa é de longe a maneira mais rápida de

otimizar um caminho de renderização crítico
sem precisar alinhar todo o CSS,o que dificultaria
a manutenção.
Qual métrica de desempenho não existe?
Qual métrica de desempenho não existe?
As métricas existentes refletem como o carregamento
da página se sente para um usuário real.
 One click at a time

Tecnologia
Dados Estruturados / schema.org
 Dados Estruturados

A pesquisa por voz está ganhando cada vez mais participação de mercado e o RankBrain se torna mais
influente no algoritmo de pesquisa principal do Google. Isso traz à tona a necessidade de colocar uma
página baseado em contexto, isso é cada vez mais importante para melhorar a visibilidade da pesquisa e os
resultados de SEO.

A marcação de dados é especialmente importante para Hummingbird e RankBrain. Ela ajuda aos
mecanismos de pesquisa interpretarem o contexto de uma consulta/trecho de sua página e determinará
a qualidade de um resultado da pesquisa. O esquema pode fornecer contexto para uma página da Web
ambígua. Não é certo que ele influencie diretamente no rankeamento, mas por conta do destaque que
ele dá ao resultado, com certeza ajuda a aumentar a taxa de cliques (CTR) da busca orgânica.
Marcação de Produtos e Categorias
Marcação de Produtos e Categorias
Marcação de Artigos
Marcação de Vídeos
 Assistente de Marcação do Google

https://www.google.com/webmasters/markup-helper/u/0/
Qual é o tipo mais relevante de marcação estruturada
para os mecanismos de pesquisa?
Qual é o tipo mais relevante de marcação estruturada
para os mecanismos de pesquisa?
 Schema.org

Schema.org é um ótimo instrumento onde Google,

Bing e Yandex estão envolvidos.
Accelerated Mobile Pages (AMP)
 AMP
A estrutura do Google para obter melhor desempenho é chamada AMP, páginas móveis aceleradas. É
como um HTML muito simples para obter o máximo desempenho, consistindo apenas em texto e
imagens. Tudo o resto é limitado; você não pode usar CSS externo, JS externo (exceto JS assíncrono) e,
claro, sem flash ou java.

Geralmente, ele é otimizado para menor uso da CPU e da memória, consumindo menos largura de banda
e, como resultado, é menos agressivo em termos de duração da bateria. Em última análise, é suposto
levar a uma melhor experiência do usuário devido ao seu carregamento quase instantâneo.

Em comparação com o HTML comum, também é importante entender que o CSS só pode ser
incorporado como não-bloqueador e que existem limitações em termos de tamanho. Além disso, existem
requisitos diferentes para atributos padrão - por exemplo, com imagens que você precisa especificar
largura e altura, o que não é o caso da marcação HTML regular. Esses atributos eram opcionais.
 AMP
Existem duas maneiras gerais de construí-lo.

1) Você cria uma cópia do seu artigo / página da web regular e cria uma versão AMP adicional.
Nesse caso, você precisa adicionar rel-amphtml e rel-canonical para criar uma conexão entre os
dois URLs.
2) Outra maneira seria usar o AMP completo, o que significa que você tem apenas um URL individual.
Mas, nesse caso, você precisaria implementar o AMP como sua estrutura autônoma - para que não
houvesse duplicação de URL, mas você seria totalmente dependente do padrão e da estrutura do
Google.

Nos dois casos, é necessário reescrever seu HTML, pois as tags HTML padrão não são mais
suportadas. A biblioteca Javascript AMP, por exemplo, transforma o em uma imagem regular em
segundo plano. Sempre que você cria o AMP, despeje esses URLs na ferramenta de validação do Google
para garantir que suas páginas estão sendo validadas corretamente. Caso contrário, não há chance de
uma página AMP ser mostrada nos resultados da pesquisa, no carrossel da caixa de notícias etc.
Antes de decidir implementar o AMP ou não, lembre-se de algumas coisas:

O AMP impulsiona a discussão e a inovação, levando as pessoas a levar mais a

01 sério a necessidade de sites de carregamento rápido. Portanto, torna-se
essencialmente um "tópico da agenda".

Permite colaboração. Diferentes equipes/partes interessadas (precisam)

02 considerar cuidadosamente as métricas de desempenho, devido às limitações e
restrições que acompanham o AMP.
Antes de decidir implementar o AMP ou não, lembre-se de algumas coisas:

Isso criará trabalho adicional - a conversão de sites existentes em AMP não é uma
cópia idêntica, você precisa reescrever o HTML e criar um novo CSS. Você não
03 pode confiar no JS; isso leva ao fato de que a quantidade de testes que precisa ser
feita nos sites convertidos em AMP é muito exigente e não é fácil corresponder ao
site comum e ao site AMP.

Também pode aumentar os custos de manutenção para você. Estender os

04 recursos do CMS para gerenciar o conteúdo AMP é caro, e o trabalho adicional de
manutenção e desenvolvimento (TI, editorial etc.) aumentará ainda mais os custos.
Antes de decidir implementar o AMP ou não, lembre-se de algumas coisas:

Isso pode afetar o rastreamento, dependendo do tipo de configuração que você

escolher. Se você adicionar um URL AMP, ele será essencialmente outro URL para
05 cada URL que você já possui. O Google agora precisa rastrear muito mais e,
eventualmente, suas páginas muito importantes serão rastreadas com menos
frequência.

Do ponto de vista do desempenho, a mágica do AMP é a busca e a renderização.

Há ~ 1 segundo avg. diferença da pré-renderização vs. carga direta de qualquer
06 AMP. Essa é a velocidade que você não consegue compensar e o tempo de
carregamento percebido para um usuário é ainda maior.
Antes de decidir implementar o AMP ou não, lembre-se de algumas coisas:

O uso do AMP não deve ser uma desculpa para ter um site de carregamento lento.
07 Invista na sua propriedade para se tornar o melhor da categoria, antes mesmo de
pensar em usar o AMP.

Se você gosta de publicar, precisa estar no Carousel - sem dúvida. É aqui que
quase todo o tráfego de publicação é. No momento, você só pode entrar no
08 Carousel, se tiver AMP. Portanto, não estou dizendo que não use AMP, apenas
certifique-se de olhar para a foto maior.
Antes de decidir implementar o AMP ou não, lembre-se de algumas coisas:

No entanto, se você observar as métricas regulares de desempenho e excluir o

09 mecanismo de pré-carregamento, um site comum poderá ser tão rápido quanto
uma versão AMP. Sites responsivos como o GUARDIAN no Reino Unido fazem isso
muito bem, e a ZEIT na Alemanha também. Suas ofertas responsivas - se você
remover o efeito de pré-carregamento - são mais rápidas que as respectivas
versões AMP.

Lembre-se de que o AMP não é a única solução, você pode

criar facilmente sites de carregamento rápido sem o AMP.
Se você optou pelo AMP, há várias verificações úteis no relatório de
Problemas de auditoria do site do SEMrush que podem ajudá-lo a verificar
o quão bem você implementou o AMP em todo o site. Basicamente, eles
ajudarão você a garantir que:

01 Não há problemas de HTML AMP no seu site

02 Todas as páginas AMP têm uma etiqueta canônica

03 Seu site está livre de problemas de estilo, layout e modelo de AMP

O que é AMP?
O que é AMP?
 Accelerated mobile pages

AMP significa páginas para celular aceleradas e é uma estrutura

do Google para melhor desempenho em dispositivos móveis.
Noções básicas de JavaScript SEO
 Introdução - Javascript SEO

Atualmente, mais de 97% de todos os sites estão usando algum tipo de JavaScript. Isso significa que o
rastreador regular do Google não consegue ver o que está acontecendo nessas áreas porque o Javascript
é executado no lado do cliente. Se você for ao navegador, as alterações estão acontecendo no navegador
e não no lado do servidor. Então, o Google perde tudo isso.

Essencialmente, no passado, quando você olhou para a marcação HTML, viu o que o rastreador viu. Agora
é totalmente diferente. Se você olhar para um site que está usando uma estrutura JS do lado do cliente,
verá apenas algumas coisas muito enigmáticas, não o conteúdo real em si. Se você renderizou o site, por
outro lado, o conteúdo seria injetado dinamicamente. É com isso que o Google se preocupa - que eles
acabem perdendo conteúdo importante na web.
 Introdução - Javascript SEO
Atualmente, ainda temos esse rastreamento clássico antigo. Com base nisso, temos uma primeira onda
instantânea de indexação com base nos dados de rastreamento clássicos. À medida que mais recursos
são disponibilizados, o Google começa a renderizar o mesmo site e a adicionar mais dados extraídos do
processo de renderização. O Google basicamente pega as informações adicionais e as adiciona aos
dados iniciais que eles estão coletando.

Então, em poucas palavras, isso significa que eles ainda fazem o rastreamento baseado em texto
à moda antiga. Além disso, eles têm essa nova e bela renderização JS para ver o que está acontecendo
lá também, como se houvesse algo "escondido" lá que eles poderiam ter perdido com o rastreamento
inicial. O processo tem várias etapas e essa segunda onda é mais lenta, o que acaba levando à indexação
atrasada. O cenário ideal seria que o conteúdo principal e todos os links críticos estivessem disponíveis
diretamente na fonte HTML. Rel = Canonical e rel = ampHTML etc também devem estar na marcação,
para garantir que o Google a pegue imediatamente. JS deve e pode aprimorar ainda mais a
funcionalidade de uma página, mas não a substitui.
 Javascript SEO na prática
Os algoritmos do Google tentam detectar se um recurso é necessário do ponto de vista de
01 renderização. Caso contrário, provavelmente não será buscado pelo Googlebot.

Embora o tempo limite exato não esteja especificado, diz-se que o Google não pode esperar
02 mais de 5 segundos para que um script seja executado.

Se o seu site for lento, o Google poderá ter problemas relacionados à renderização do seu
03 conteúdo - isso também pode atrasar o processo de rastreamento.

Use o teste amigável do Google Mobile - ele pode mostrar o DOM renderizado + os erros que o
04 Google encontrou ao renderizar sua página.

Não use o cache para sites JS. O que você vê ao clicar no cache é como o SEU navegador
05 interpreta o HTML "coletado" pelo Googlebot. Não está totalmente relacionado à forma como o
Google processou sua página.
 Javascript SEO na prática
Geralmente, verifique se os recursos internos e externos necessários para a renderização não
06 estão bloqueados para o Googlebot.

JS em SEO é um alvo em movimento, portanto, lembre-se de que as coisas mudam

07 diariamente.
Lembre-se de que o Googlebot não é um usuário real; portanto, você pode assumir que ele não
08 clica, não preenche formulários. Visite novamente os eventos “onclick”, por exemplo, mostre
mais CTAs, menus, etc.

Quando você quiser usar tags canônicas, verifique se elas são colocadas em tags HTML /
09 X-robots simples. As tags canônicas injetadas por JavaScript são consideradas menos
confiáveis e as chances são de que o Google as ignore.
Verdadeiro ou falso? O fato de um site funcionar em seu navegador
não significa que o Google o entenda da mesma maneira.
Verdadeiro ou falso? O fato de um site funcionar em seu navegador
não significa que o Google o entenda da mesma maneira.
 VERDADEIRO

O Google agora está usando uma versão muito antiga

do Chrome, Chrome 41, para renderizar seu site.
Introdução a indexação Google’s Mobile First
 Introdução - Google’s Mobile First Indexing
O Google Mobile First Indexing é sobre o Google preferir
organizar o conteúdo entre dispositivos de uma maneira que
possa ser facilmente consultada e exibida em vários
dispositivos diferentes. Tudo isso para evitar uma experiência
ruim do usuário ao ver a página preparada para outro formato.

Existem grandes desafios para o Google em relação à primeira

indexação móvel. O Google nunca teve que trocar um índice
inteiro por algo novo, e fazê-lo sem experimentação seria
impossível. Os sites não devem sofrer danos ou perder
significativamente no processo. Portanto, serão realizadas
experiências de indexação em larga escala. Foi o que Gary
Illyes disse na SMX em Seattle no ano passado.
Introdução - Google’s Mobile First Indexing

A paridade de site e conteúdo é absolutamente crucial.

Verifique se o desktop e o celular estão sincronizados em
relação ao conteúdo e às anotações, bem como às diretrizes
de indexação, etc. Se você possui um site móvel separado,
verifique se ele possui todas as regras de indexação, mas
também abrange coisas simples, como garantir que as
imagens estejam disponíveis. , que possui rel-canonicals,
hreflang e tudo mais presente.

Tudo isso é muito mais fácil se você estiver em um site

responsivo, pois nesse caso é a mesma marcação e você
não precisa fazer as coisas duas vezes.
Algumas dicas para mobile first index:

Verifique se o site é compatível com dispositivos móveis. Teste fácil: verifique você
01 mesmo usando o Chrome DevTools (Ctrl + Shift + I) incorporado. Em seguida, você
pode mudar para responsivo e verá se seu site está bom.

Se for responsivo, você geralmente deve estar pronto. Se você estiver em exibição
dinâmica, Incluir a variável: cabeçalho HTTP do agente do usuário.
02 Identifique e entregue a versão da web relevante para o agente do usuário certo.
Se você possui um site para celular independente, implemente tags alternativas e
canônicas entre URLs para celular e para computador.
Algumas dicas para mobile first index:

Não impeça o acesso usando intersticiais. Existem sobreposições/pop-ups

03 malucos que afetariam negativamente a experiência do usuário?
Nesse caso, isso pode causar problemas na primeira indexação móvel.

Faça uma verificação completa da integridade do site e foque nos problemas

móveis. O SEMrush Site Audit e o DeepCrawl têm relatórios detalhados que
04 mostram se tudo está sendo correspondido corretamente e assegura que nada
está faltando.
Algumas dicas para mobile first index:

Verifique todos os relatórios do GSC, revise o relatório de usabilidade em

05 dispositivos móveis. Também cartões ricos e outros como serão apresentados
no celular.

Preste muita atenção à saída renderizada. Você pode usar o Screamingfrog

06 para simular o Googlebot para smartphones com renderização JS.
Algumas dicas para mobile first index:

07 Verifique GSC buscar e renderizar. Use-o não apenas no desktop,

mas também no smartphone bot.

Revise suas palavras-chave e a segmentação por palavras-chave.

08 As palavras-chave ainda são as corretas? As pessoas estão procurando algo
diferente se estiverem em uma jornada móvel?
Escolha uma declaração incorreta em relação à paridade de conteúdo:
Escolha uma declaração incorreta em relação à paridade de conteúdo:
A disponibilidade de todas as imagens em uma versão
móvel não tem conexão com a paridade de conteúdo

Se você tiver um site móvel

separado, certifique-se de
que ele cobre coisas simples,
como garantir que as
imagens estejam disponíveis
e que haja rel-canonicals,
hreflang e tudo o mais
presente.
 One click at a time

Arquivos de Log
Introdução à Auditoria de Arquivo de Log
 Auditoria de Arquivo de Log

Os arquivos de log geralmente são armazenados em

um servidor da web e, simplesmente falando, contém
um histórico de todos os acessos de uma pessoa ou
rastreador ao seu site. Eles podem lhe dar uma idéia
de como os rastreadores de mecanismos de pesquisa
estão lidando com seu site.

Somente arquivos de log de acesso podem mostrar

como o rastreador de um mecanismo de pesquisa
está se comportando no seu site; todas as
ferramentas de rastreamento estão simplesmente
tentando simular seu comportamento.
Por que você deveria se importar?

Eles podem ajudar você a entender as prioridades de rastreamento. Você pode ver
01 quais páginas são priorizadas pelos mecanismos de pesquisa e, portanto, devem
ser consideradas as mais importantes.

Em segundo lugar, eles podem ajudar a evitar o rastreamento reduzido. O Google

02 pode reduzir seu comportamento / frequência de rastreamento e, eventualmente,
classificá-lo como um nível mais baixo se você veicular constantemente um
grande número de erros.
Por que você deveria se importar?

Você quer entender questões globais. Você deseja identificar quaisquer

03 deficiências de rastreamento (como hierarquia ou estrutura de links internos) com
possíveis implicações em todo o site.

Você também deseja garantir o rastreamento adequado. Você deseja garantir que
04 o Google esteja rastreando tudo o que é importante: classificando principalmente
conteúdos relevantes, mas também itens antigos e novos.
Por que você deveria se importar?

O último objetivo é garantir a vinculação adequada. Você deseja garantir que

05 qualquer valor ganho no link seja sempre transmitido usando links e / ou
redirecionamentos adequados.

As características de um arquivo de log são relativamente simples; é apenas um arquivo de texto.

O conteúdo e a estrutura dos arquivos de log podem variar e dependem do servidor da Web
(Apache, NGINX, IIS etc.), cache e sua configuração. Certifique-se de identificar qual configuração
você está executando e como as coisas parecem da perspectiva da infraestrutura.
Geralmente, um arquivo de log contém:

01 O IP do servidor / nome do host

02 O registro de data e hora da solicitação

03 O método da solicitação (geralmente GET / POST)

04 A URL da solicitação

05 Código de status HTTP (tudo está bem para 200 ou 301 para redirecionamento)

Além disso, os arquivos de log armazenam o agente do usuário. O agente do usuário ajuda a
06 entender se a solicitação realmente veio do rastreador ou não.
 Auditoria de Arquivo de Log
Ao trabalhar com dados do arquivo de log, você precisa
fazer as perguntas certas. Os dados do arquivo de log
podem ser bastante impressionantes, porque você pode
fazer muitas coisas diferentes; verifique se você tem suas
perguntas preparadas.

Os dados do arquivo de log podem ser muito diferentes

dos dados do Google Analytics, por exemplo.

Embora os arquivos de registro sejam informações

diretas do servidor, o Google Analytics usa o código do
cliente. Como os conjuntos de dados são provenientes de
duas fontes diferentes, eles podem ser diferentes.
 Erros no Servidor

Ao solicitar acesso a um arquivo de log, lembre-se de que você não precisa de nenhuma informação
pessoal; portanto, quando você fala com sua TI ou com um cliente, não precisa se preocupar. É
essencialmente apenas sobre as solicitações do rastreador do Google ou Bing. Não há necessidade de
dados do usuário (sistema operacional, navegador, número de telefone, nomes de usuário etc.). Não é
relevante.

Além disso, você precisa estar ciente de como a infraestrutura do servidor está configurada. Se você
estiver executando um servidor de cache ou um proxy e / ou uma CDN que cria logs em outro local,
também precisaremos desses logs para obter uma imagem completa.
Verdadeiro ou falso? Os dados do arquivo de log
são iguais aos dados do Google Analytics.
Verdadeiro ou falso? Os dados do arquivo de log
são iguais aos dados do Google Analytics.
 Falso

Os dados vêm de diferentes origens (servidor vs. lado do cliente)

para que possam ser diferentes.
Ferramentas de Auditoria de Arquivo de Log e
Suas Diferenças
 Auditoria de Log - Sites pequenos e de médio porte
Os arquivos de log geralmente são enormes
e não faz muito sentido abrir-los em um editor
de textos comum. Uma das melhores maneiras -
especialmente da perspectiva de SEO - é usar
o Screamingfrog Log File Analyzer.

É uma ferramenta de auditoria de arquivos de log

baseada em desktop, no nível iniciante, com
alguns relatórios predefinidos muito úteis. Possui
uma interface simples, na qual você pode
pesquisar diferentes relatórios, entender os
eventos e o comportamento do rastreamento, ver
códigos de resposta etc.
Auditoria de Log - Sites pequenos e de médio porte

Outra solução é o Elastic Stack - anteriormente conhecido como ELK. Consiste em 3 ferramentas
diferentes:

● Elasticsearch: mecanismo de pesquisa e análise,

● Logstash: pipeline de processamento de dados do lado do servidor,
● Kibana: visualização de dados (tabelas, gráficos, etc.)

O melhor de tudo isso é que ele é de código aberto e, portanto, livre para usar. Por outro lado,
você deve configurá-lo e executá-lo em sua própria infraestrutura de servidor. Portanto, ele precisa
de recursos de TI.
 Auditoria de Log - Outras Ferramentas

Outras soluções SaaS são logrunner.io, logz.io e Loggly. Eles são todos baseados no ELK, mas
focados na auditoria baseada em SEO; portanto, eles têm painéis nos quais você pode, por exemplo,
ver o comportamento do rastreamento ao longo do tempo ou códigos de resposta por rastreador, etc.

A beleza das soluções SaaS é que elas são quase em tempo real. Você canaliza seus arquivos de log
no sistema e, rapidamente, pode ver o que está acontecendo no seu site.

A vantagem da solução SaaS é a possibilidade de compartilhar relatórios com uma equipe ou com
um cliente. Se você estiver fazendo migrações, isso facilita as coisas porque você vê todos os
eventos que podem acontecer em tempo real.
Quais são as principais vantagens das ferramentas SaaS
sobre as versões de desktop? Escolha 3 respostas.
Quais são as principais vantagens das ferramentas SaaS
sobre as versões de desktop? Escolha 3 respostas.
 As soluções SaaS oferecem a possibilidade de compartilhar relatórios
com uma equipe ou cliente, trabalhar em tempo real e fornecer escala ilimitada.
Relatório de Auditoria de arquivos de log
Auditoria de Log - Sites pequenos e de médio porte

Uma das coisas mais óbvias que você pode fazer com base nos dados do arquivo de log é tentar
detectar anomalias dentro de um período de tempo. Para isso, você precisa de dados do arquivo de
log que remontam alguns dias ou até meses. Você pode ver picos no comportamento do
rastreamento, por exemplo, o Googlebot estava rastreando muito agressivamente por 1 ou 2 dias
específicos.

Ou, por exemplo, se você deseja ser encontrado na China, mas isso não parece estar acontecendo
e você vê nos arquivos de log que o Baidu não rastreia seu site, isso indica que você tem um
problema.
Auditoria de Log - Sites pequenos e de médio porte

Obviamente, você também pode dividi-lo apenas nos bots que estão acessando o site. Você pode ter
uma idéia de que outros tipos de rastreadores estão chegando e processando dados do seu site. Um
dos casos de uso atualizados seria o comutador do Google MFI, onde você pode ver se o robô do
smartphone do Google ultrapassou a área de trabalho do Googlebot em termos de volume de
rastreamento.

Você pode entender quais são as principais páginas rastreadas pelo Googlebot e verificar se elas
coincidem com os URLs mais importantes dos seus domínios. Você também pode detalhar as
solicitações de rastreamento e os códigos de status por diretório para entender o quão bem as
páginas são rastreadas e se isso acontece regularmente ou com grandes atrasos, ou não.
Auditoria de Log - Sites pequenos e de médio porte

Além disso, é super importante entender os erros de rastreamento. Existem duas categorias
diferentes que você deve procurar especialmente. O primeiro são os erros 4xx e o segundo 5xx.
Avalie cada url e se estão retornando o código que deveriam, no caso dos erros 5xx analisar junto ao
TI a estrutura do servidor se está adequada.

Outra coisa importante é identificar os principais e piores URLs e pastas rastreados. As páginas e
pastas altamente rastreadas podem ser usadas para links internos adicionais (adicionar hubs de
link). Áreas com rastreamento baixo precisam ser vinculadas com mais destaque. Ele reflete em que
os robôs do Google gastam seu tempo. Assim é possível estabelecer links internos para novos itens
de conteúdo para indexá-los mais cedo ou mais tarde. Além disso, ao entender quais são as piores
páginas rastreadas, você pode priorizá-las e dar-lhes mais atenção.
Auditoria de Log - Sites pequenos e de médio porte

Outro grande ponto para a qual você pode usar arquivos de log é entender que tipo de desperdício
de rastreamento está acontecendo. Geralmente, isso é causado por parâmetros de URL que ficaram
loucos. Se você não possui um gerenciamento adequado de parâmetros de URL, os parâmetros de
rastreamento (por exemplo) geralmente podem ser adicionados aleatoriamente a todo e qualquer URL.
Também pode causar conteúdo duplicado e vários outros problemas,
e não apenas o rastreamento.

A maior parte desse desperdício é causada por parâmetros ruins. É altamente recomendável configurar
o rastreamento do comportamento dos parâmetros o tempo todo e observar constantemente novos
parâmetros, bem como aumentar significativamente o rastreamento dos já conhecidos. Você pode
remover no GSC em: Ferramentas e relatórios legados > Parâmetros de URL.
Auditoria de Log - Sites pequenos e de médio porte
 A identificação dos URLs e pastas principais / menos rastreadas mostra quais páginas
e pastas com rastreamento muito alto podem ser usadas para links internos adicionais.
 A identificação dos URLs e pastas principais / menos rastreadas mostra quais páginas
e pastas com rastreamento muito alto podem ser usadas para links internos adicionais.
 VERDADEIRO

Também mostra quais áreas menos rastreadas precisam

ser vinculadas com mais destaque.
Sobrepondo Dados de Rastreio e de Log
para Obter Melhores Resultados
 Sobreposição de dados para insights

Para que sua análise de arquivos de log não fique limitada, sempre que possível, combine os dados
do arquivo de log com a entrada de outras fontes de dados. Você pode coletar dados do Google
Analytics ou GSC - ou de todas essas fontes de uma só vez. Outra maneira fácil seria utilizar o mapa
do site XML e sobrepor os dados dos arquivos de log.

Muitas coisas podem ser feitas sobrepondo fontes de dados diferentes, mas a abordagem geral é
criar essa análise de lacunas e tentar entender as principais diferenças. É algo que você fez
corretamente? todos os rastreadores se comportam da mesma maneira? - ou o Googlebot se
comporta de maneira diferente do que você esperava? A comparação das simulações de
rastreamento com os dados do arquivo de log é super poderosa - e depois de identificar as
diferenças, você pode agir imediatamente.
Como sobrepor dados para uma análise assertiva:

Uma das coisas mais fáceis que você poderia fazer seria sobrepor seu mapa do
site com seus arquivos de log. Eventualmente, você verá que os dados podem
01 indicar uma falta de links internos na arquitetura do site, porque, se a arquitetura
do site estiver funcionando corretamente, todos as URLs incluídos no mapa do site
também deverão ter sido rastreados. Caso contrário, há algo errado.

Se você tiver dados de um rastreamento da Web, ele poderá descobrir uma URL
definido como noindex - por qualquer motivo. Se você sobrepor esse URL aos
dados do seu arquivo de log, verá que esse URL noindex é rastreada com muita
02 frequência. Nesse caso, configurar o noindex talvez não fosse a melhor ideia,
certo? A sobreposição de dados do arquivo de log com outras fontes também
pode ajudar a revelar erros e pode atuar como uma rotina de manutenção.
Como sobrepor dados para uma análise assertiva:

Observe suas páginas indexáveis e veja se elas realmente estão sendo rastreadas
ou não e, em caso afirmativo, com que frequência. Esse pode ser um ótimo ponto
de partida para entender se eles precisam de melhorias ou se você deve
03 reconsiderar a indexação todos juntos - talvez eles não sejam bons o suficiente?
Ou você pode querer consolidá-los com outros conteúdos do seu site e se livrar
dessa URL completamente do índice. De um modo geral, se o Google não
rastreá-los, haverá uma razão para isso; e você precisa descobrir e agir de acordo.

Observe se todas as suas páginas não indexáveis, não necessariamente apenas os

meta-robôs noindex. Mas também as que contêm uma tag canônica referenciando
uma URL ou páginas alternativas bloqueadas no robots.txt, ainda estão sendo
04 rastreadas. É uma ótima maneira de entender se o Google considera suas dicas e
diretrizes corretamente. Se não for esse o caso, você precisará melhorar os URLs
relevantes.
A combinação de ferramentas como GSC, arquivos de log ou um sitemap XML
pode ser útil na definição e correção de erros na não indexação?
A combinação de ferramentas como GSC, arquivos de log ou um sitemap XML
pode ser útil na definição e correção de erros na não indexação?
 VERDADEIRO

A sobreposição de dados do arquivo de log com outras fontes pode

ajudar a revelar erros e pode atuar como uma rotina de manutenção.
 One click at a time

Hora do jogo!
● Você terá 20 perguntas para responder.

● Você tem permissão para 27 minutos para o

exame.

● Para passar no exame, você precisa de 70%.