SEO de imagens: alt text, formato, tamanho e nome de arquivo

Imagem é a maior parte do peso de quase toda página de e-commerce e, ao mesmo tempo, uma das menos cuidadas. O lojista sobe a foto do fornecedor, o tema monta a galeria, o campo de texto alternativo fica vazio e ninguém volta ao assunto até o relatório de velocidade apontar vermelho. O resultado aparece em dois lugares: no Google Imagens, que deixa de entender o que a foto mostra, e nas métricas de experiência, que pioram a cada megabyte desnecessário.

Este guia cobre o que a documentação oficial diz sobre SEO de imagens e o que é apenas convenção de mercado. Você vai ver como escrever o alt text, nomear arquivos, escolher o formato, definir tamanhos, usar lazy loading sem prejudicar o carregamento principal e preparar a imagem para o feed do Merchant Center. Onde não existe regra oficial, o texto avisa.

Uma nota de método: as afirmações sobre o Google vêm da documentação do Google Search Central, do web.dev e do MDN. Números de exemplo são hipotéticos e servem para mostrar a conta. Recomendações de rotina são da Analytikos.

O que o Google realmente lê numa imagem

Segundo as boas práticas de imagens do Google Search Central, o rastreador lê o atributo src de uma tag img padrão e não indexa imagens de fundo definidas em CSS. Isso já elimina um erro comum: galerias de produto montadas como background-image ficam invisíveis para o Google Imagens.

O Google aceita BMP, GIF, JPEG, PNG, WebP, SVG e AVIF no src, e pede que a extensão do arquivo seja coerente com o formato real. Imagens responsivas, com srcset, sizes e picture, também funcionam, desde que exista um src de reserva.

Alt text: como escrever para pessoas e para o Google

A documentação do Google é direta: o alt text é o atributo mais importante para fornecer metadados a uma imagem. A progressão do exemplo oficial vai de nenhum alt, passa por uma palavra e chega a uma descrição específica. O princípio é descrever a imagem no contexto da página e evitar listas de palavras-chave, que o Google trata como spam.

A acessibilidade oferece o critério de decisão. O guia de decisão do W3C separa quatro casos: imagem decorativa recebe alt vazio; imagem informativa recebe uma descrição breve; imagem funcional, dentro de link ou botão, recebe um texto que informa o destino ou a ação; imagem de texto leva esse texto no alt quando ele não aparece em outro lugar.

Sobre tamanho do texto: o Google não define um limite de caracteres. A Shopify informa que o campo aceita até 512 caracteres e recomenda 125 ou menos, conforme a ajuda oficial de alt text da Shopify. Trate 125 como orientação de plataforma, não como regra de busca.

Nome do arquivo e URL

O Google recomenda nomes curtos e descritivos e desaconselha nomes genéricos como image1.jpg ou códigos de câmera. Em sites localizados, traduza o nome e codifique caracteres especiais na URL. Não há medição pública do peso do nome de arquivo no ranqueamento, então a razão prática é organização e contexto, não um ganho de posição prometido.

Um padrão simples para lojas: produto, variação e ângulo, separados por hífens, como tenis-corrida-azul-lateral.jpg. A documentação lida não confirma se hífen ou sublinhado é melhor, portanto a escolha é de convenção interna. O importante é manter a mesma URL para a mesma imagem e evitar parâmetros dinâmicos, como carimbo de data ou identificador de sessão, o que também vale para o feed do Merchant Center.

Formato: JPEG, PNG, WebP, AVIF e SVG

A orientação do web.dev em como escolher o formato de imagem é que WebP e AVIF geralmente comprimem melhor que os formatos antigos e devem ser usados quando possível. Ambos suportam transparência e animação e funcionam nos navegadores modernos. O WebP sem perdas pode ser mais eficiente que o PNG, e o SVG serve para logos, ícones e formas simples. Para animações, a página desaconselha o GIF e recomenda vídeo.

A documentação não traz percentuais de economia. Por isso, o exemplo a seguir é hipotético: uma foto de 400 KB em JPEG que vira 280 KB em WebP e 220 KB em AVIF economiza 120 KB e 180 KB por imagem. Em uma categoria com 24 produtos, são 24 × 120 = 2.880 KB e 24 × 180 = 4.320 KB a menos. Meça com as suas próprias fotos antes de prometer números.

Quem acompanha novos formatos pode ler também por que o JPEG XL não é suportado no Google Imagens e no Discover, um bom lembrete de que suporte do navegador não é suporte da busca.

Tamanho, dimensões e imagens responsivas

Há três tamanhos diferentes e eles costumam ser confundidos: as dimensões em pixels, o peso do arquivo e o tamanho exibido na tela. O Google não define um peso ideal. A Nuvemshop orienta 1024 x 1024 px como mínimo recomendado e peso entre 100 e 600 KB, segundo a Central de Atendimento da Nuvemshop. A Shopify informa limite de 20 MB e 5000 x 5000 px, e que 2048 x 2048 px costuma exibir melhor em imagens quadradas, de acordo com a ajuda de tipos de mídia da Shopify.

Para entregar o arquivo certo a cada tela, use srcset e sizes. O guia do MDN sobre imagens responsivas mostra um caso em que uma tela de 480 px carrega a versão de 63 KB em vez da de 800 px com 128 KB. Use picture quando precisar de recortes diferentes por tela (direção de arte), e mantenha sempre o img com src e alt dentro dele.

A conta bruta mostra por que a densidade importa: uma imagem de 100 x 100 px CSS ocupa 40.000 bytes sem compressão a 1x (100 × 100 × 4 bytes) e 160.000 bytes a 2x (200 × 200 × 4). Quanto maior a densidade, mais a compressão e o formato fazem diferença.

Core Web Vitals: width, height, lazy loading e fetchpriority

Imagem pesa em dois indicadores. O LCP (Largest Contentful Paint, o tempo até o maior elemento aparecer) é considerado bom com 2,5 segundos ou menos em pelo menos 75% das visitas, segundo o web.dev em otimização do LCP. O CLS (Cumulative Layout Shift, a instabilidade visual) é bom com 0,1 ou menos, conforme a página de otimização do CLS.

• width e height em todas as imagens. O navegador calcula a proporção e reserva o espaço antes de baixar o arquivo, o que reduz o CLS mesmo com CSS de largura 100%.
• Nunca aplique lazy loading à imagem do LCP. O web.dev afirma que isso sempre gera atraso desnecessário. Use loading=”lazy” só em imagens fora da primeira tela.
• fetchpriority=”high” na imagem provável de LCP. Uma ou duas imagens com alta prioridade é o limite razoável; mais que isso anula o efeito.
• A imagem do LCP no HTML inicial. Imagem inserida por JavaScript, por data-src ou como fundo CSS não é encontrada cedo pelo navegador.

Do ponto de vista de busca, o Google orienta em conteúdo com lazy loading que o carregamento adiado precise revelar todo o conteúdo relevante quando ele entra na tela, sem depender de clique ou rolagem manual, e que o resultado seja testado com a Inspeção de URL do Search Console. O mesmo cuidado vale para as páginas de categoria, que concentram dezenas de fotos.

Dados estruturados, sitemap e controle de indexação

Na marcação de produto, a documentação de listagens de comerciante lista image como propriedade obrigatória. As URLs precisam ser rastreáveis e indexáveis, a imagem deve representar o produto e estar em formato aceito. Para melhores resultados, o Google recomenda várias imagens de alta resolução, com no mínimo 50 mil pixels (largura × altura), nas proporções 16×9, 4×3 e 1×1. O detalhamento do preenchimento está no guia de SEO para página de produto.

O sitemap de imagens é opcional. Pela documentação de sitemap de imagens, cada URL aceita até 1.000 tags de imagem, imagens em CDN são aceitas se o domínio estiver verificado no Search Console, e o robots.txt não pode bloquear o que você quer indexar. Para o sitemap de páginas, veja o guia de sitemap XML e robots.txt.

Para retirar uma imagem da busca, a documentação da meta tag robots indica o cabeçalho X-Robots-Tag com noindex, porque imagem não tem HTML. A URL não pode estar bloqueada no robots.txt, senão a regra não é lida.

Imagem para o feed do Merchant Center

A foto que vai para o Google Shopping segue regras próprias. A página de especificação de dados do produto aceita JPEG, WebP, PNG, GIF, BMP e TIFF, com extensão coerente ao formato, no máximo 16 MB e 64 megapixels, e URL de até 2.000 caracteres compatível com ASCII. O mínimo informado é 500 x 500 px e o recomendado é 1500 x 1500 px ou mais. Conforme a mesma página, o produto deve ocupar de 75% a 90% da imagem.

São proibidos textos promocionais (chamada para ação, preço, frete), códigos de barras e QR, marca d’água, símbolo de copyright, logos adicionados em pós-produção, placeholders, imagens com borda e produtos que não são vendidos junto. Como o AVIF não consta na lista, mantenha o feed em JPEG, WebP ou PNG, mesmo que o site use AVIF.

Erros comuns

Os erros abaixo aparecem em auditorias de lojas de todos os tamanhos. Para cada um, o texto mostra por que acontece, qual o efeito e como corrigir.

Erros de marcação e de contexto

Erros de desempenho

Erros de feed e de infraestrutura

Checklist de SEO de imagens

• Fotos de produto em img com src no HTML, sem depender de CSS ou script.
• Alt descritivo e único por foto; alt vazio apenas em decorativas.
• Nome de arquivo curto e descritivo, sem códigos de câmera.
• Formato moderno com reserva em JPEG; feed do Merchant Center em JPEG, WebP ou PNG.
• Dimensões declaradas (width e height) em todas as imagens.
• Imagem do LCP sem lazy loading e com fetchpriority alto; demais abaixo da dobra com lazy.
• srcset e sizes com versões de mesma proporção.
• Product com várias imagens, em 16×9, 4×3 e 1×1, acima de 50 mil pixels.
• Feed sem texto promocional, marca d’água ou borda.
• CDN verificada no Search Console e robots.txt liberando o rastreamento.

Um exemplo de conta para priorizar: uma categoria com 24 fotos de 400 KB soma 24 × 400 = 9.600 KB, ou cerca de 9,4 MB, só de imagens. Com lazy loading nas fotos fora da primeira tela, se oito imagens são carregadas de início, o carregamento inicial cai para 8 × 400 = 3.200 KB. Os números são hipotéticos, mas a lógica vale para qualquer catálogo.

Conteúdos Relacionados

• SEO para página de produto
• SEO para página de categoria
• Sitemap XML e robots.txt: o guia básico