
Lista de verificação técnica de SEO
Rastreamento e indexação
O primeiro aspeto a analisar durante a auditoria técnica é a forma como o seu sítio é indexado e rastreado pelos motores de busca. Afinal de contas, se as páginas do seu sítio não puderem ser rastreadas, não serão indexadas (salvo raras excepções). Como consequência, as páginas não representadas no índice não participarão na classificação.
Consulte o Relatório de indexação de páginas na Consola de pesquisa do Google
A forma mais precisa e fiável de analisar a indexação do seu Web site é analisar o Relatório de Indexação de Páginas na Consola de Pesquisa do Google. Consulte o relatório de páginas indexadas e verifique quais as páginas que estão no índice. Veja se existem páginas com opções de filtragem ou ordenação, se existem páginas de teste ou outras páginas que não pretende indexar. Veja também as páginas que foram excluídas. Nem todos os estados no relatório Páginas excluídas são um problema. Não deve concentrar a sua atenção em todas as páginas excluídas, mas apenas naquelas em que o comportamento do Google não corresponde às suas intenções. Na tabela abaixo, pode ver os estados que tendem a exigir atenção e uma análise mais profunda:
Estado | O que significa | O que deve fazer |
---|---|---|
Erro de redireccionamento | O Google não conseguiu seguir o URL devido a problemas de redireccionamento. |
|
Erro do servidor | O servidor devolveu um erro 5xx. |
|
Descoberto – não indexado | O Google conhece a página, mas ainda não a rastreou. Indica problemas com o orçamento de rastreio. |
|
Rastreada – não indexada | O Google visitou a página, mas optou por não a indexar. Normalmente indica uma baixa qualidade da página. |
|
Duplicado sem canónico selecionado pelo utilizador | O Google considera a página como duplicada, mas o utilizador não especificou um canónico. |
|
Duplicado, o Google escolheu um canónico diferente do do utilizador | O Google ignorou o canónico especificado. |
|
404 suave | A página parece “vazia” ou “não encontrada”, mas devolve um estado 200 OK. |
|
Os outros status provavelmente não sinalizam nenhum problema. No entanto, também vale a pena rever estes relatórios para garantir que as páginas não foram removidas, redireccionadas, canonizadas ou bloqueadas da indexação por engano.
Estado | O que significa | O que precisa de saber |
---|---|---|
Página alternativa com etiqueta canónica adequada | O Google reconheceu corretamente a canónica que especificou. |
|
URL bloqueado por robots.txt | O Google não consegue rastrear a página. |
|
URL marcado como “noindex | A página tem a diretiva noindex. |
|
Não encontrado (404) | A página não existe. |
|
Bloqueada devido a pedido não autorizado (401)/ Bloqueada devido a acesso proibido (403) | A página está bloqueada por autorização ou proibida. |
|
Página com redireccionamento | A página redirecciona para outra. |
|
URL bloqueado devido a outro problema 4xx | A página está inacessível devido a um erro 4xx diferente de 404 (por exemplo, 403, 401, 410, etc.). |
|
Na Central de Ajuda do Google, você pode encontrar uma descrição abrangente do relatório de página, incluindo exemplos de problemas e uma explicação detalhada de cada status. O Screaming Frog também pode ajudar na análise de páginas que são indexadas ou excluídas do índice. Para isso, é necessário conectar a API do Google Search Console antes de iniciar o rastreamento do site. Para conectar, vá para Configuração -> Acesso à API -> Google Search Console. Clique em Iniciar sessão com o Google e siga as instruções.

Source: Screaming Frog
Uma vez ligado, active a inspeção de URLs e pode também ativar a opção para ignorar a inspeção de indexação para URLs que não podem ser indexados.

Source: Screaming Frog
Poderá então ver e comparar o estado de cada página de acordo com a Consola de Pesquisa (a forma como o Google a vê) e o seu estado real, conforme determinado durante o processo de rastreio.

Source: Screaming Frog
Tenha em atenção que apenas estão disponíveis 2000 URLs por dia para cada sítio, pelo que este método é mais adequado para sítios pequenos.
Verifique o que está no seu sitemap.xml
O Sitemap.xml é um ficheiro XML que fornece aos rastreadores dos motores de busca uma lista de páginas de um sítio, bem como (opcionalmente) informações sobre a data da última modificação, a frequência de atualização e a prioridade de rastreio recomendada. Normalmente, é colocado na raiz do sítio, por exemplo: https://example.com/sitemap.xml. O Sitemap.xml ajuda os motores de busca a encontrar páginas novas ou actualizadas mais rapidamente. Além disso, a inclusão de uma página neste ficheiro é um dos sinais para determinar a versão canónica de uma página, embora seja um sinal fraco.

Source: e-commerce sport store
O ficheiro sitemap.xml é particularmente útil para:
- novos sítios com poucas ligações externas;
- grandes sítios com muitas páginas;
- sítios com muito conteúdo multimédia;
- sítios de notícias que são actualizados frequentemente.
O Sitemap.xml deve conter todas as páginas que pretende indexar. Pode utilizar o mesmo Screaming Frog ou outros crawlers para analisar as páginas incluídas no Sitemap.xml. No Screaming Frog, o sitemap.xml pode ser verificado separadamente no Modo de lista, ou pode ser incluído em uma verificação regular do site. Para fazer isso, em Configuração -> Aranha -> Rastreamento, ative o rastreamento de sitemap XML e adicione os URLs absolutos dos sitemaps que deseja rastrear. Não é recomendável usar vários serviços on-line para gerar um Sitemap, pois eles podem gerar apenas um sitemap estático que não será atualizado automaticamente. A melhor opção é gerar o sitemap.xml utilizando plug-ins para o CMS em que o sítio está a ser executado ou escrever um script personalizado que gere o sitemap de acordo com condições especificadas e o actualize automaticamente quando são feitas alterações no sítio. Ao gerar o sitemap.xml, certifique-se de que o seu ficheiro está em conformidade com o protocolo sitemap.xml. Para o efeito, pode utilizar vários validadores em linha, como https://www.xml-sitemaps.com/validate-xml-sitemap.html. É necessário incluir todas as etiquetas enumeradas no protocolo? Nem sempre. Por exemplo, o Google considera apenas as tags <loc> e <lastmod>. Certifique-se de que a data na etiqueta <lastmod> é exacta. Se houver tentativas de a manipular, o Google pode ignorar esta etiqueta.
Certifique-se de que não existem erros no ficheiro robots.txt
O ficheiro robots.txt é o primeiro local que um robô de pesquisa procura antes de rastrear um site. Determina quais as secções do site que podem ou não ser rastreadas e, consequentemente, quais as páginas que serão indexadas pelos motores de busca. Deve estar sempre localizado em https://example.com/robots.txt. Este ficheiro é uma ferramenta para gerir o rastreio (não a indexação!) do sítio. Algumas páginas, mesmo que estejam bloqueadas no robots.txt, ainda podem ser indexadas (normalmente se houver ligações internas ou externas para elas). Essas páginas (indexadas apesar de estarem bloqueadas em robots.txt) podem ser vistas na Consola de Pesquisa do Google no relatório “Indexadas, embora bloqueadas por robots.txt”.

Source: Search Console
Eis o que deve ser verificado em relação ao ficheiro robots.txt como parte de uma auditoria técnica de SEO:
- Disponibilidade do ficheiro
O ficheiro deve estar acessível em https://example.com/robots.txt e dar um estado de resposta 200 OK. A sua ausência, erros de transferência ou redireccionamentos (301, 302, 403, 404) podem impedir os motores de busca de compreenderem corretamente as regras de rastreio do sítio.
- Sintaxe e correção
Verificar se a estrutura dos ficheiros segue a norma. Exemplo de um modelo básico:
- User-agent: *
- Não permitir: /admin/
- Permitir: /public/
- Mapa do site: https://example.com/sitemap.xml

Source: nike.com
- Diretivas de não permissão e permissão
Verifique se páginas importantes não são acidentalmente proibidas, por exemplo
- Início (/)
- Cartões de produto (/product/)
- Blogue ou artigos (/blog/, /articles/)
Um erro comum é bloquear imagens, estilos e scripts ao bloquear pastas administrativas. Nesse caso, deve ser especificado que, embora a pasta administrativa esteja bloqueada, alguns tipos de ficheiros devem estar abertos para verificação. Isto acontece frequentemente em sites WordPress quando a pasta com todo o conteúdo do utilizador, Disallow: /Neste caso, apenas os ficheiros de um determinado formato podem ser abertos para verificação:
- Permitir: /wp-content/uploads/*.css
- Permitir: /wp-content/uploads/*.js
- Permitir: /wp-content/uploads/*.jpeg
Para validar o seu robots.txt e testar as diretivas que vai adicionar, pode utilizar esta ferramenta.
- Verificar a compatibilidade com outras diretivas
Os erros ocorrem frequentemente quando o robots.txt entra em conflito com:
- meta tag <meta name=”robots” content=”noindex”>
- canónica
Por exemplo, se uma página estiver aberta em robots.txt mas bloqueada via noindex, será rastreada, mas não entrará no índice. Isto é aceitável, mas é importante que seja feito intencionalmente. Além disso, um problema comum é quando existem outras instruções para os robots no código-fonte e um bloqueio simultâneo da página em robots.txt. Os robots dos motores de busca não analisam as páginas bloqueadas em robots.txt. Não vêem as etiquetas especificadas no código, por exemplo, a canonização. Ou seja, essa canonização simplesmente não será contabilizada.
Verifique a sua ligação interna
Uma das principais tarefas de uma auditoria técnica é garantir que a ligação interna do sítio funciona corretamente. Isto significa que todas as ligações internas devem conduzir a páginas reais e existentes que estejam abertas para indexação, devolvam um código de estado 200 OK, não contenham redireccionamentos e, mais importante, não apontem para páginas com erros 4xx/5xx. À primeira vista, isto pode parecer um pormenor sem importância, mas na prática, mesmo as ligações internas incorrectas podem afetar negativamente:
- A eficiência do rastreamento do site pelos mecanismos de pesquisa,
- A distribuição do peso SEO interno (PageRank),
- a experiência do utilizador.
O primeiro passo na análise é verificar se existem erros em todas as ligações internas. É especialmente importante identificar links quebrados que levam a páginas com erros 404, 410 ou outros (como 403, 500). Abaixo está uma tabela com os principais tipos de erros que podem ocorrer em links internos, seu significado e ações recomendadas para corrigi-los.
Tipo de erro | O que significa | O que fazer |
---|---|---|
404 | Página não encontrada | Remova a ligação ou substitua-a por uma que funcione |
403 | Acesso proibido | Verificar as definições de acesso |
301/302 | Redirecionar | Atualizar a ligação para o URL final |
5xx | Erro do servidor | Verificar o servidor ou o CMS |
Também é importante analisar a profundidade da hierarquia da página, ou seja, determinar a que nível e a quantos cliques da página inicial se encontra o conteúdo principal. É preferível que as páginas importantes não estejam a mais do que o terceiro nível, o que aumenta a sua acessibilidade tanto para os motores de busca como para os utilizadores. Um dos elementos-chave da análise é identificar as páginas “órfãs”, ou seja, aquelas que não têm ligações internas que apontem para elas. Mesmo que estas páginas estejam incluídas no mapa do sítio, a falta de ligações internas torna-as menos acessíveis. Além disso, é importante analisar os textos âncora – as palavras e frases que contêm as ligações. Devem ser relevantes e significativos, uma vez que os textos âncora ajudam os motores de busca a compreender o contexto da hiperligação.
Analisar as estatísticas de rastreio
A análise das estatísticas de rastreio é uma forma de compreender como o Googlebot interage com um sítio: que páginas são rastreadas, com que frequência e como isso afecta a SEO. Estes dados estão disponíveis na Consola de Pesquisa do Google → Definições → Estatísticas de rastreio. Na tabela abaixo, pode ver os problemas mais comuns que pode encontrar neste relatório:
Problema | O que procurar no relatório | Causas possíveis |
---|---|---|
Diminuição acentuada do rastreamento | Menos rastreios por dia | Problemas de acessibilidade, definições incorrectas em robots.txt, bloqueios, erros 5xx |
Muitos erros 4xx e 5xx | Erros nos URLs | Páginas eliminadas, ligações quebradas, problemas no servidor |
Aumento do tempo de resposta | >1 segundo – um sinal de aviso | Problemas de alojamento, sobrecarga do servidor |
Muitos redireccionamentos 3xx | Redireccionamentos em vez de URLs diretos | Redireccionamentos incorrectos, cadeias de redireccionamentos, um grande número de ligações internas com redireccionamentos |
CSS/JS não rastreados | Estão ausentes das estatísticas | Bloqueados por robots.txt |
Além disso, os registos do servidor podem ser analisados. Permitem-lhe ver os pedidos reais dos bots de pesquisa (não só o Googlebot, mas também o Bingbot, o YandexBot e outros), em vez de apenas os dados agregados da Consola de Pesquisa do Google. Este é um método de diagnóstico avançado e “em bruto” que requer uma quantidade significativa de tempo. Para visualizar os dados, pode utilizar ferramentas de código aberto como o GoAccess ou o Screaming Frog Log File Analyser.
Implementar dados estruturados
Os dados estruturados são um formato de marcação especial numa página Web que ajuda os motores de busca a compreender o conteúdo da página de forma mais precisa e profunda. Servem como uma “dica” para o Google e outros motores de busca sobre o que está exatamente na página – um artigo, produto, receita, análise, vídeo, etc. Embora não seja um sinal de classificação oficial, afecta indiretamente as classificações ao melhorar a forma como os motores de busca compreendem a página. A principal norma ou protocolo utilizado para dados estruturados em sítios Web é o Schema.org. Existem outros protocolos, como o OpenGraph, mas este é utilizado para as redes sociais. O Schema.org é um projeto de colaboração entre a Google, a Microsoft, a Yahoo e a Yandex, criado para desenvolver e manter uma norma unificada para dados estruturados na Web. O Schema.org inclui centenas de tipos de entidades, sendo os mais utilizados apresentados na tabela abaixo:
Categoria | Entidade (@type) | Objetivo |
---|---|---|
Conteúdo e páginas | Artigo | Um artigo ou conteúdo noticioso |
Postagem em blogue | Uma publicação de blogue | |
NotíciasArtigo | Um artigo de notícias para o Google News | |
Página de FAQ | Uma página de perguntas frequentes (FAQ) | |
Como fazer | Um guia passo-a-passo | |
Página Web | Informações gerais sobre uma página Web | |
Produtos e ofertas | Produto | Descrição do produto |
Oferta | Oferta de preço | |
AgregadoOferta | Gama de preços para um produto de diferentes vendedores | |
Comentários e classificações | Comentários | Uma avaliação de um produto ou serviço |
Classificação | Uma classificação numérica (frequentemente dentro de uma avaliação) | |
Classificação agregada | Classificação média baseada em várias avaliações | |
Organizações e pessoas | Organização | Uma descrição de uma empresa ou marca |
LocalBusiness | Uma empresa local com informações de contacto e horário | |
Pessoa | Uma pessoa (por exemplo, autor de um artigo, orador, etc.) | |
Eventos | Evento | Um evento online ou offline |
Navegação e estrutura | Lista de navegação | Navegação por listas de navegação |
SiteNavigationElement | Itens do menu principal | |
Multimédia | VideoObjecto | Vídeo com metadados (para excertos de vídeo) |
ImageObject | Imagem com descrição | |
Educação e empregos | Curso | Um curso ou programa de formação online |
Anúncio de emprego | Oferta de emprego (para o Google for Jobs) |
Recomenda-se a implementação de dados estruturados no formato JSON-LD. Este bloco é colocado no <cabeçalho> ou <corpo> do documento HTML, mas não é apresentado ao utilizador – é lido pelos robôs de pesquisa. Todos os principais motores de pesquisa, como o Google, o Bing e o Yahoo, suportam este formato. Um exemplo de código JSON-LD é mostrado abaixo: <script type=”application/ld+json”> { “@context”: “https://schema.org”, “@type”: “Article”, “headline”: “O que é JSON-LD?”, “author”: { “@type”: “Person”, “name”: “John Smith” }, “datePublished”: “2025-12-01” } </script> Ao implementar dados estruturados, siga o protocolo Schema.org e utilize o validador para verificar a correção dos tipos de microdados implementados. Alguns tipos de dados estruturados do protocolo Schema.org também podem ajudar na apresentação de rich snippets nos resultados de pesquisa do Google. Tenha em atenção que os requisitos do Google para dados estruturados para rich snippets diferem ligeiramente da norma Schema.org. Muitas vezes, é necessário especificar mais campos do que os exigidos pelo protocolo Schema.org. Por isso, se quiser obter um Rich Snippet, siga as diretrizes do Google para dados estruturados. Pode verificar a correção da implementação de microdados utilizando o validador de rich snippet. Existem também muitos geradores de microdados, mas estes só podem criar código estático que não será atualizado com as alterações de conteúdo na página. Garantir que as informações nos microdados correspondem ao que é visível para os utilizadores na página faz parte dos requisitos do Google para dados estruturados. Se a política relativa aos dados estruturados for violada, a página pode perder todos os rich snippets e, em alguns casos, sofrer penalizações manuais. Por conseguinte, certifique-se de que os seus microdados são gerados e actualizados automaticamente.
Conteúdo
Como parte de uma auditoria técnica de SEO, é importante avaliar as caraterísticas básicas do conteúdo: desde a estrutura dos títulos e meta tags até à presença de atributos alt para imagens e potenciais páginas duplicadas. Estes elementos afectam diretamente a indexação e a forma como os motores de busca vêem o sítio.
Teste o seu sítio Web para detetar duplicados completos
Os duplicados completos ocorrem quando o conteúdo idêntico está acessível através de diferentes URLs no sítio. As duplicatas podem prejudicar completamente a classificação do seu site. Os tipos mais comuns de duplicatas completas são:
- Acessibilidade via HTTP e HTTPS
- Acessibilidade com e sem WWW
- Acessibilidade com ou sem uma barra no final
- Acessibilidade de URLs em maiúsculas e minúsculas
- A página é acessível com extensões de ficheiro como .html, .htm, .php, .aspx e sem elas
- Parâmetros que não alteram o conteúdo da página, como as etiquetas UTM
- Conteúdo idêntico em URLs diferentes. Por exemplo, um produto é listado em duas categorias, acessíveis através de dois URLs diferentes. Ou a página do produto acessível com e sem a categoria no URL.
- Versões de teste do sítio (domínio DEV utilizado para desenvolvimento).
Para encontrar páginas duplicadas relacionadas com variações de URL, teste os URLs manualmente e verifique o código de resposta do servidor para essas variantes de URL. Pode utilizar qualquer ferramenta para verificar os códigos de resposta do servidor, como https://httpstatus.io/. Introduza as variações de URL e verifique a sua acessibilidade.

Source: httpstatus.io/ website + test of a client’s website
Para corrigir problemas com variações em HTTP/HTTPS, www/sem-www, com/sem barra, maiúsculas/minúsculas e a acessibilidade de páginas com extensões como .html, .htm, .php, .aspx e sem elas, é necessário configurar um redireccionamento 301 para a versão preferida. Quando são encontradas duplicações devido à disponibilidade de conteúdo idêntico, adicionando ou removendo partes do URL (por exemplo, um produto está disponível em duas categorias), é melhor reconsiderar a estrutura do URL e a estrutura do site. Para UTM e outros parâmetros, a canonização também pode ser uma solução. No entanto, é importante notar que o Google trata a etiqueta canónica como uma recomendação, e a decisão final sobre o URL a escolher continua a ser do Google. Se for encontrada uma versão de teste do site no índice do Google, esta deve ser bloqueada da indexação e deve ser enviado um pedido de remoção através da Consola de Pesquisa do Google.
Resolver duplicados de páginas parciais
As duplicações parciais de páginas ocorrem quando duas ou mais páginas do site contêm conteúdo muito semelhante, mas não completamente idêntico. Os tipos mais comuns de duplicatas parciais são:
- Páginas de classificação
- Páginas de filtro
- Páginas de paginação
- Páginas com produtos semelhantes (por exemplo, os produtos diferem apenas na cor)
- Várias versões do site no mesmo idioma, mas para regiões diferentes (por exemplo, três sites em inglês para os EUA, Reino Unido e Austrália).
Naturalmente, cada sítio é único e, durante uma auditoria técnica, poderá identificar outros casos de conteúdo duplicado que exijam soluções específicas. No entanto, os exemplos acima são os mais comuns. As duplicações parciais são normalmente encontradas durante o processo de rastreamento do site por vários rastreadores. Para eliminar os duplicados parciais, não é possível configurar um redireccionamento, uma vez que estas páginas são necessárias para a funcionalidade do sítio. A seguir, discutiremos métodos para lidar com duplicatas parciais.
Ordenar e filtrar páginas
Estas páginas podem ser impedidas de serem rastreadas no ficheiro robots.txt, embora isto possa ser ignorado pelo Google, especialmente se os links apontarem para estas páginas. Isto ajudará a preservar o orçamento de rastreio. Também pode bloqueá-las através da diretiva <meta name=”robots” content=”noindex, nofollow” />, que impedirá que estas páginas sejam indexadas, mas não dirá ao Google que não devem ser rastreadas. A melhor abordagem neste caso é utilizar JavaScript para atualizar o conteúdo da página quando o utilizador aplica a ordenação ou os filtros, sem gerar URLs e ligações adicionais para páginas de filtragem ou ordenação.
Variantes de produtos disponíveis em URLs diferentes
Idealmente, todas as variantes de produtos devem ser combinadas numa página, onde o utilizador pode selecionar a cor ou o tamanho pretendido sem alterar o URL, utilizando JavaScript. No entanto, se for utilizada uma página separada para cada variante, deve ser especificada uma ligação canónica para a página principal do produto. No entanto, como mencionado anteriormente, o Google pode ignorar a canónica definida pelo utilizador.
Páginas de paginação
As páginas de paginação não devem ser impedidas de indexação. Para garantir que o Google considera a primeira página da categoria como a principal:
- Incluir apenas a primeira página no ficheiro sitemap.xml.
- Adicione um link para a página principal da categoria em todas as páginas de paginação.
- Adicione números de página ao título e ao H1 das páginas de paginação. Por exemplo, “Camisas brancas – Página 2”.
Páginas disponíveis num idioma, mas para regiões diferentes
Neste caso, é necessário utilizar atributos Hreflang. São utilizados para indicar aos motores de busca qual o idioma e a versão regional de uma página Web que devem mostrar aos utilizadores com base na sua preferência linguística e localização. Existem várias formas de implementar atributos Hreflang:
- Nos cabeçalhos HTTP
- Através de etiquetas na secção <head>
- Através de etiquetas em sitemap.xml
O método mais fácil de implementar é através de etiquetas na secção <head>. Existem regras que os atributos hreflang implementados através de etiquetas na secção <head> devem cumprir:
-
- O atributo deve ter o seguinte formato: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
- Os códigos da língua e do país devem ser válidos. Para escolher o código válido para cada mutação linguística, consulte esta página.
- Cada versão linguística deve listar-se a si própria e a todas as outras versões linguísticas nos seus atributos hreflang. Isto significa que cada página deve ter o mesmo número de atributos hreflang
- As hiperligações nos atributos hreflang devem ser absolutas e indexáveis.
Um exemplo de código: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />
Verificar se há duplicados nos títulos, h1, h2s e descrições
Embora os títulos, as descrições e os cabeçalhos H1-H6 estejam relacionados com a SEO na página, a sua análise no âmbito de uma auditoria técnica pode ser útil para detetar duplicados. Para os analisar, pode utilizar qualquer rastreador que recolha estas etiquetas. Quando forem encontrados títulos, etiquetas H1-H6 e descrições duplicados, analise os dados da página e identifique a causa da duplicação. Isto pode dever-se à disponibilidade do sítio através de HTTP e HTTPS, à duplicação das principais etiquetas de categoria em páginas de filtro ou simplesmente a um erro humano em que estas etiquetas foram incorretamente preenchidas.
Otimizar os atributos alt das imagens
Os atributos Alt são um atributo HTML utilizado no interior da etiqueta <img> da seguinte forma: <img src=”image.jpg” alt=” Descrição da imagem”>. O seu principal objetivo é fornecer uma descrição de texto do conteúdo da imagem. Este texto é apresentado se a imagem não for carregada e é lido em voz alta pelos leitores de ecrã para ajudar os utilizadores com deficiência visual. Um texto alternativo descritivo e adequado pode ajudar as suas imagens a classificarem-se na pesquisa de imagens e a melhorar a relevância geral da página. Se tiver um Web site com muito conteúdo visual, a otimização dos atributos alternativos é um passo mais importante do que para os Web sites clássicos que dependem de conteúdo de texto. Muitos rastreadores como o Screaming Frog, Ahrefs, SemRush, etc. analisam os atributos alternativos e aí pode obter os dados sobre atributos alternativos em falta ou vazios. Pode ler mais sobre a criação de atributos alternativos descritivos em documentos oficiais do Google.
Velocidade do Web site, mobilidade e facilidade de utilização
Utilizar o protocolo HTTPs
A utilização do protocolo HTTPS seguro é essencial para garantir a segurança da transmissão de dados entre o utilizador e o servidor. Não só aumenta a confiança do utilizador, como também tem um impacto positivo na SEO. Para verificar a existência de HTTPS, basta olhar para a barra de endereços do browser – deverá aparecer um ícone de cadeado. Para uma análise detalhada, pode utilizar o serviço SSL Labs, que fornecerá um relatório completo sobre o estado do certificado SSL e identificará eventuais problemas. É igualmente importante garantir que não existem conteúdos mistos – recursos HTTP em páginas HTTPS. Para esta análise, pode utilizar o relatório HTTPS na Consola de Pesquisa do Google, que mostrará URLs com HTTP e HTTPS.

Source: Search Console
Fonte: Consola de Pesquisa do nosso cliente
Melhorar o Core Web Vitals
Core Web Vitals é um conjunto de métricas proposto pelo Google para avaliar a qualidade da experiência do utilizador num website. Estas métricas centram-se na velocidade de carregamento, interatividade e estabilidade visual do conteúdo da página. Incluem três indicadores-chave:
Métrica | Descrição | Valor ótimo |
---|---|---|
Maior tinta com conteúdo (LCP) | Mede o tempo de carregamento do maior elemento visível na página (por exemplo, imagem ou texto). | Menos de 2,5 segundos |
Atraso da primeira entrada (FID) | Mede o tempo que a página demora a responder à primeira interação do utilizador (por exemplo, clicar num botão ou numa ligação). | Menos de 100 milissegundos |
Deslocação cumulativa da apresentação (CLS) | Avalia a estabilidade visual da página, ou seja, a quantidade de elementos que se movem durante o carregamento da página. | Menos de 0,1 |
Os dados que foram recolhidos de utilizadores reais podem ser visualizados no relatório da Consola de Pesquisa “Core web vitals” (dados agregados) ou em PageSpeed Insights (para testes individuais). Ao trabalhar nos Core Web Vitals, lembre-se de que é necessário definir os problemas que têm uma grande influência nas métricas de CWV. Por exemplo, ao otimizar o LCP, é necessário definir qual dos 4 aspectos (TTFB, Atraso de carregamento, Tempo de carregamento ou Atraso de renderização) contribui mais para a pontuação elevada do LCP. No exemplo abaixo, é visível que não precisamos de nos concentrar na otimização do TTFB ou do Tempo de carregamento. Em vez disso, podemos colocar todas as nossas energias na melhoria do Atraso de Carregamento e, em seguida, do Atraso de Renderização.

Source: pagespeed.web.dev
Fonte: https://pagespeed.web.dev/ – teste do sítio Webnike.com (apenas a título de exemplo). O domínio está desfocado
Certifique-se de que o seu sítio Web é compatível com dispositivos móveis
A compatibilidade com dispositivos móveis tornou-se um fator crucial desde 2018, quando o Google mudou para uma abordagem de indexação mobile-first. Isso significa que o Google agora usa principalmente a versão móvel de um site para classificação e indexação, em vez da versão para desktop. No Google Search Console, você pode testar suas páginas clicando em “Testar URL ao vivo” na ferramenta de inspeção de URL e ver como o Googlebot-Mobile o vê.
Comprimir imagens
A otimização de imagens com o objetivo de as comprimir sem perder qualidade ajuda a acelerar o carregamento do sítio Web, especialmente se houver muito conteúdo gráfico nas páginas. Podem ser utilizadas ferramentas online como o TinyPNG ou o Squoosh para comprimir imagens. Também vale a pena verificar se estão a ser utilizados formatos de imagem modernos, como o WebP, que podem reduzir significativamente o tamanho dos ficheiros.
Utilizar CDN para sítios Web internacionais
A utilização de uma CDN faz sentido se o seu sítio Web servir uma vasta gama de regiões geograficamente distantes. Uma CDN (Content Delivery Network) distribui o conteúdo do sítio por servidores localizados mais perto dos utilizadores, reduzindo a latência durante o carregamento. Pode verificar a utilização de CDN examinando os cabeçalhos de pedidos HTTP nas ferramentas de desenvolvimento do navegador (separador Rede), onde podem aparecer referências ao fornecedor de CDN, como Cloudflare ou Akamai. Existem também ferramentas online para testar a CDN. A configuração da CDN é normalmente efectuada através do painel de alojamento ou do CMS. Utilizar o armazenamento em cache O armazenamento em cache permite que os navegadores e os servidores proxy armazenem cópias de recursos, reduzindo a carga do servidor e acelerando o carregamento em visitas subsequentes. Pode verificar a correção do armazenamento em cache nas ferramentas de desenvolvimento do navegador – na secção Rede, consulte os cabeçalhos Cache-Control, Expires e ETag. O Google PageSpeed Insights também fornece recomendações para o armazenamento em cache. É importante que os recursos estáticos (imagens, scripts, estilos) tenham configurações de cache adequadas e que o servidor tenha as regras correspondentes configuradas (por exemplo, na configuração .htaccess ou nginx). Para verificar o armazenamento em cache, pode utilizar serviços online como o GiftOfSpeed.
Conclusão
A auditoria técnica de um sítio Web não é um procedimento único, mas um processo contínuo que exige uma atenção regular aos factores técnicos que podem ter impacto no seu desempenho e visibilidade. Como cada sítio Web é único, o foco específico e a frequência das verificações variam. Esta lista de verificação para uma auditoria técnica de SEO ajudá-lo-á a garantir que não se esqueceu de nada importante.