SEO de Imagens

Como otimizar imagens para o Google Imagens, pesquisa visual e páginas mais rápidas — formatos, nomes de arquivo, texto alternativo, carregamento preguiçoso, dados estruturados e sitemaps de imagem.

Publicado pela primeira vez: 25 de jun. de 2026 · Última atualização: 2 de set. de 2026 · Avançado

SEO de imagens é dois trabalhos, não um: ranquear suas imagens no Google Imagens / pesquisa visual (impulsionado por texto alternativo, nomes de arquivo, contexto da página e exclusividade), e manter as páginas rápidas (imagens são geralmente o maior elemento de Core Web Vitals / LCP). Os mitos a abandonar: não há aumento direto de ranqueamento para WebP ou AVIF (Mueller confirmou — a vantagem é a velocidade), você não deve renomear em massa arquivos existentes, e imagens de fundo em CSS não são indexadas. O carregamento nativo loading="lazy" é adequado para imagens abaixo da dobra, mas nunca para sua imagem LCP. O Google indexa <img> (e <picture>), suporta BMP/GIF/JPEG/PNG/WebP/SVG/AVIF e, a partir de maio de 2025, quer que você referencie a mesma imagem no mesmo URL em todos os lugares. Este hub mapeia tudo isso e aponta para o mergulho profundo em texto alternativo.

TL;DR — Image SEO são dois objetivos separados: (1) ranquear na busca de imagens (Google Imagens / Lens / Bing), impulsionado por texto alternativo, nomes de arquivo, contexto da página e exclusividade; e (2) desempenho da página, porque as imagens geralmente são o elemento LCP. O Google indexa <img> (inclusive dentro de <picture>) — não fundos de CSS — e suporta BMP, GIF, JPEG, PNG, WebP, SVG, AVIF. Não há impulso direto de ranqueamento para WebP ou AVIF (Mueller); o benefício é velocidade → Core Web Vitals. Não renomeie em massa arquivos existentes. O loading="lazy" nativo é seguro abaixo da dobra, mas nunca na imagem LCP — essa recebe fetchpriority="high". Desde maio de 2025, referencie a mesma imagem no mesmo URL em todos os lugares. Dados estruturados (ImageObject, matrizes de imagem Product/Article) desbloqueiam resultados ricos; sitemaps de imagem ainda ajudam na descoberta. O texto alternativo tem seu próprio mergulho profundo.

« Evidência desta afirmação Google indexes images referenced with HTML image elements and does not index CSS background images as images. Escopo: Google image discovery and indexing. Confiança: alta · Verificado: Google Search Central: Image SEO Evidência desta afirmação Images can be LCP candidates; the LCP image should be discoverable early and should not be lazy-loaded. Escopo: web.dev LCP image loading guidance. Confiança: alta · Verificado: web.dev: Optimize LCP » (Tradução) (Síntese localizada do trecho dezesseis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Image SEO is two jobs, not one » (Tradução) (Síntese localizada do trecho dezessete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This is the framing I keep coming back to, and almost every “image SEO checklist” blurs it. There are two distinct goals, and they call for different work: » (Tradução) (Síntese localizada do trecho dezoito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  1. Ranqueamento na pesquisa de imagens. Fazer com que suas imagens sejam encontradas no Google Imagens, no Bing Imagens e no Google Lens para consultas específicas de imagens. Isso é impulsionado pelo texto alternativo, nomes de arquivo, texto ao redor da imagem, dados estruturados e exclusividade da imagem.
  2. Desempenho da página. As imagens são quase sempre o elemento mais pesado de uma página — os próprios documentos do Google dizem que as imagens são “frequentemente o maior contribuinte para o tamanho geral da página.” Isso as torna as culpadas usuais por um Largest Contentful Paint (LCP) lento, que alimenta o Core Web Vitals, que é um sinal de ranqueamento na pesquisa web.

Mantenha esses objetivos separados e todo o assunto fica mais claro. Texto alternativo e nomes de arquivo atuam principalmente na pesquisa de imagens. Formato, compressão e estratégia de carregamento atuam no desempenho. Ambos importam; simplesmente não são a mesma alavanca.

«And the volume is real: image and visual search is a meaningful slice of all search activity, and Google Lens has grown fast. Optimized images aren’t just defensive — they’re a traffic source. » (Tradução) (Síntese localizada do trecho vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## How Google discovers and indexes images » (Tradução) (Síntese localizada do trecho vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A few mechanics decide whether your images even make it into the index: » (Tradução) (Síntese localizada do trecho vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  • Apenas <img> em HTML é indexado. Google: “O Google analisa os elementos HTML <img> (mesmo quando estão dentro de outros elementos, como elementos <picture>) em suas páginas para indexar imagens, mas não indexa imagens CSS.” Se uma imagem existe apenas em um background-image CSS, ela fica invisível para a pesquisa de imagens. Coloque qualquer coisa que você queira encontrar em um <img>.
  • Sempre forneça um src de fallback. Ao usar srcset ou <picture>, mantenha um src simples também — “alguns navegadores e rastreadores não entendem” os atributos responsivos, e o src é a rede de segurança na qual o Google confia.
  • Formatos suportados: BMP, GIF, JPEG, PNG, WebP, SVG e AVIF (o suporte a AVIF chegou em agosto de 2024). A extensão do arquivo deve corresponder ao tipo real do arquivo.
  • O contexto ainda importa junto com a marcação. A marcação suportada faz uma imagem ser descoberta; é o texto ao redor da página, legendas, títulos e outros metadados que o Google combina com a própria imagem para entender sobre o que ela é depois de encontrada.
  • Consistência de URL (atualização de maio de 2025). O Google agora recomenda referenciar a mesma imagem com a mesma URL toda vez que ela aparecer. Um porta-voz do Google disse: “Atualizamos as práticas recomendadas de SEO de imagens do Google para esclarecer que as URLs de imagens devem ser referenciadas de forma consistente para facilitar o rastreamento em sites maiores.” Isso é uma questão de eficiência de rastreamento — mesma imagem, mesma URL, para que o Google possa armazenar em cache e reutilizá-la em vez de buscar novamente a mesma imagem em diferentes caminhos de CDN ou strings de consulta.
Evidência desta afirmação Google indexes images referenced with HTML image elements and does not index CSS background images as images. Escopo: Google image discovery and indexing. Confiança: alta · Verificado: Google Search Central: Image SEO

«## File formats: pick for speed, not for an SEO boost » (Tradução) (Síntese localizada do trecho vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Here’s the myth to kill first: there is no direct ranking boost for “next-gen” formats. Mueller confirmed there’s no “SEO boost” for AVIF, and the same logic applies to WebP — “WebP images are fine for Image Search,” but “fine” is not “better.” Google doesn’t reward you for the container. » (Tradução) (Síntese localizada do trecho vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«What modern formats do is shrink your files, which speeds up the page, which helps Core Web Vitals — an indirect benefit. So choose on the merits: » (Tradução) (Síntese localizada do trecho vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  • AVIF — melhor compressão, frequentemente 50%+ menor que JPEG; use fallback.
  • WebP — 25–35% menor que JPEG e suporte quase universal; bom padrão para fotos.
  • JPEG — fallback universal para fotografias.
  • PNG — transparência ou bordas nítidas.
  • SVG — logos e ícones vetoriais.
  • GIF — evite em conteúdo complexo; prefira vídeo ou WebP/AVIF animado.

«The clean implementation is <picture> with <source> elements for the modern formats and a <img src> fallback, so older browsers degrade gracefully and Google still has a src to index. » (Tradução) (Síntese localizada do trecho vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## File names: descriptive for new images, don’t bulk-rename old ones » (Tradução) (Síntese localizada do trecho trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Filenames are a real (if minor) signal. Google’s own best practice is to use short, descriptive names — “the filename can give Google clues about the subject matter of the image” — so golden-retriever-puppy.jpg beats IMG00023.JPG, and anything generic like image1.jpg is a wasted opportunity. » (Tradução) (Síntese localizada do trecho trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«But here’s the nuance that trips people up: don’t go back and rename your existing files. Mueller was clear that bulk renaming “is going to take a lot of time for Google’s systems to see” the new images, and that the effect is “minimal… maybe no visible effect at all” if your alt text and surrounding context are already good. Gary Illyes framed the signal loss from image URL migrations as “in line with web search results, which is a few weeks.” So: descriptive names on new images, yes; a site-wide rename project for marginal benefit and weeks of churn, no. » (Tradução) (Síntese localizada do trecho trinta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Alt text (the short version) » (Tradução) (Síntese localizada do trecho trinta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«I’m not going to repeat the full treatment here because alt text has its own deep dive. The headline: alt text is the most important piece of image metadata, but its real payoff is image search and accessibility — not web-search rankings. Google reads it alongside computer vision and page context, so write for context, don’t keyword-stuff, and use alt="" for purely decorative images. The full rules, quotes, and audit workflow are in my alt text guide. » (Tradução) (Síntese localizada do trecho trinta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Compression, lazy loading, and Core Web Vitals » (Tradução) (Síntese localizada do trecho trinta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Because images usually decide your LCP, this is where image SEO and Core Web Vitals overlap most: » (Tradução) (Síntese localizada do trecho trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  • Comprima tudo. Redimensione as imagens para suas dimensões de exibição e comprima-as. Esta é a maior alavanca de desempenho para a maioria das páginas.
  • O carregamento preguiçoso nativo é seguro — abaixo da dobra. loading="lazy" no <img> é endossado pelo Google e rastreável. As implementações que quebram são as de JavaScript que escondem a URL real em data-src e nunca expõem um src — essas correm o risco de não serem indexadas. Use loading="lazy" nativo ou IntersectionObserver, e certifique-se de que as imagens carreguem quando visíveis, não em um clique ou deslize (“O Google Search não interage com sua página”).
  • Nunca carregue preguiçosamente a imagem LCP. Esta é a regra que as pessoas mais quebram. Sua maior imagem acima da dobra (geralmente o herói) deve carregar ansiosamente — loading="eager" e fetchpriority="high" — não preguiçosamente. Carregar preguiçosamente a imagem LCP pode adicionar centenas de milissegundos ao LCP sem motivo.

«## Responsive images » (Tradução) (Síntese localizada do trecho trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Use srcset + sizes (different resolutions for different viewports) and <picture> (art direction / format switching). Two things to keep straight: » (Tradução) (Síntese localizada do trecho quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  • Sempre inclua um src de fallback. Como acima — rastreadores e navegadores mais antigos precisam dele.
  • Cada candidato precisa ser alcançável. Quaisquer regras de acesso que se aplicam ao seu src de fallback — não bloqueado, não atrás de autenticação, não uma URL morta — se aplicam a cada candidato srcset/<picture> também. Um candidato não descoberto não ajuda mesmo quando o fallback está ok.
  • Mantenha suas URLs consistentes com a página. A URL da imagem que você coloca em um sitemap de imagens deve ser a mesma URL que a página realmente usa. Não sirva uma URL de imagem diferente para mobile do que para desktop — o Google é um rastreador mobile-first, e URLs divergentes causam perda temporária de tráfego de imagem enquanto o Google reconstrói o histórico de ranqueamento para as novas URLs.

Dados estruturados para imagens

Os dados estruturados são o que desbloqueia rich results e selos relacionados a imagens:

  • ImageObject com license habilita o selo de imagem licenciável. Exige contentUrl e ao menos um de creator, creditText, copyrightNotice ou license; acrescente license + acquireLicensePage.
  • Dados estruturados de Product/Article pedem um array de imagens em várias proporções (16:9, 4:3, 1:1).
  • A miniatura é automática, mas primaryImageOfPage, image e og:image influenciam Google Search e Discover.

A marcação elegível não é uma garantia de exibição — o Google ainda decide, página por página, se realmente mostrará o selo, o tratamento da matriz de imagens ou a miniatura que seus dados estruturados tornam possível.

É aqui também que o SEO de imagens se sobrepõe ao tópico mais amplo de dados estruturados — a marcação que alimenta os rich results de produto, artigo e imagem é a mesma maquinaria.

Sitemaps de imagens

Sitemaps de imagens são uma ferramenta de descoberta, mais útil para imagens hospedadas em CDN, grandes galerias e sites com muito JavaScript, onde as imagens podem não ser encontradas por meio do rastreamento normal. Duas observações que pegam as pessoas de surpresa: o Google agora suporta apenas <image:image> e <image:loc> (ele descontinuou <image:caption>, <image:title>, <image:geo_location>, e <image:license> em 6 de maio de 2022 — embora o Bing ainda os use, então mantenha-os se você servir um sitemap para ambos). E os sitemaps de imagens são o único lugar onde você pode usar URLs de domínio cruzado em <image:loc>, o que é útil para hospedagem em CDN (verifique o domínio do CDN no Search Console). A mecânica está no artigo sobre sitemaps de imagens. Nada disso é uma promessa: um sitemap de imagens pode ajudar o Google a descobrir imagens que poderiam passar despercebidas, mas enviar um não garante rastreamento, indexação ou ranqueamento.

«## Discover and large images » (Tradução) (Síntese localizada do trecho quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Para ser elegível para pré-visualizações de imagens em formato grande no Discover e em todas as superfícies do Google, adicione <meta name="robots" content="max-image-preview:large"> e use imagens grandes — com pelo menos 1.200px de largura, alta resolução, idealmente 16:9. O estudo de caso do próprio Google documentou um aumento real de CTR ao habilitar pré-visualizações grandes (um blog de comida com +79% de CTR no Discover; um site de notícias com +30% de CTR / +332% de cliques em seis meses). Esta é uma das poucas mudanças de imagem com ganho diretamente mensurável.

Imagens de banco versus imagens exclusivas

A posição de Mueller merece ser citada diretamente: fotografia de banco “não importa diretamente para a pesquisa na web”, mas “na pesquisa de imagens, se for a mesma imagem usada em muitos lugares, será mais difícil”. E, separadamente: “exclusividade não equivale a maior qualidade” — tirar a foto você mesmo não a ranqueia automaticamente melhor. Então: use imagens de banco livremente se você só se importa com ranqueamentos na web; use imagens exclusivas quando a visibilidade na pesquisa de imagens importar, porque uma imagem única não tem nada com o que competir.

«## Emerging: AI-image labeling (C2PA / IPTC) » (Tradução) (Síntese localizada do trecho cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Worth flagging because it’s new and most guides miss it: Google reads IPTC copyright fields (which can show as attribution credit in Google Images — free brand visibility) and uses IPTC / C2PA metadata to identify AI-generated images, surfacing an “AI generated” label via the “About this image” feature. Camera EXIF (ISO, aperture, GPS) has no documented ranking effect — strip it for performance, but preserve the copyright fields. This space is still evolving. » (Tradução) (Síntese localizada do trecho cinquenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Where to go next » (Tradução) (Síntese localizada do trecho cinquenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This hub is the map. The deep dives and adjacent topics: » (Tradução) (Síntese localizada do trecho cinquenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

  • Texto alternativo — o tratamento completo do atributo alt: por que ele afeta a pesquisa de imagens, não a pesquisa na web; implicações legais e de acessibilidade; regras de redação; imagens decorativas; texto âncora de imagens com link; e auditoria em escala. É o único subtópico profundo o bastante para merecer um artigo próprio.
  • Classificação no Google Imagens — análise aprofundada da visibilidade especificamente no Google Imagens e no Lens: requisitos de indexação, imagens licenciáveis e mitos que páginas bem classificadas ainda repetem.
  • Formatos de imagem — comparação detalhada entre JPEG, PNG, WebP e AVIF: para que cada formato realmente serve e por que trocar de formato não é, por si só, um fator de classificação.
  • Core Web Vitals — aqui fica a metade de desempenho do SEO de imagens. Compressão, LCP e fetchpriority são, na prática, trabalho de Core Web Vitals aplicado a imagens.
  • Dados estruturados — ImageObject, arrays de imagens de Product/Article e controle de miniaturas por og:image fazem parte da história mais ampla de dados estruturados.
  • Sitemaps de imagens — a mecânica de descoberta, as tags descontinuadas pelo Google mas mantidas pelo Bing e URLs de CDN entre domínios.

Adicionar uma nota de especialista

Fixar uma citação de especialista

É uma pessoa nova? Crie o perfil não reivindicado dela em /admin/experts/ → Fixar uma citação de especialista primeiro.