Google Lens e pesquisa IA multimodal: como otimizar imagens no WordPress e WooCommerce

O paradigma operacional da pesquisa digital contemporânea está a afastar-se rapidamente das consultas exclusivamente baseadas em texto para abraçar interações visuais e multimodais. Compradores profissionais e particulares apontam quotidianamente as câmaras dos seus dispositivos móveis para componentes mecânicos industriais, peças de substituição ou amostras de matérias-primas com o intuito de identificar artigos, analisar preços e encontrar fornecedores através do Google Lens, do ChatGPT Vision ou do Bing Visual Search. Simultaneamente, os agentes autónomos de compras e os motores de busca inteligentes analisam as fotografias de comércio eletrónico não como elementos meramente decorativos, mas como fontes primárias de informação factual relativas a dimensões, fichas técnicas e certificações industriais.

Para programadores de software e gestores técnicos que mantêm plataformas baseadas em WordPress e WooCommerce, este cenário exige uma revisão profunda dos processos de ingestão, transformação e entrega de multimédia. Métodos ultrapassados que se limitam ao carregamento de ficheiros JPEG desprovidos de tratamento avançado e ao preenchimento elementar da etiqueta alt revelam-se inoperantes para garantir relevância nos novos ecossistemas de compras.

#A expansão da pesquisa visual e o papel dos modelos multimodais de inteligência artificial

A consolidação de modelos multimodais de referência como o Google Gemini e o OpenAI GPT-4o alterou substancialmente a forma como os rastreadores web inspecionam o conteúdo de uma página. No passado, um motor de busca dependia quase em exclusivo do texto circundante, do nome do ficheiro e de metadados genéricos. Atualmente, os sistemas de visão computacional executam análises sofisticadas a nível do píxel em tempo real:

• Vetores de características visuais (Visual Embeddings): Os modelos mapeiam formas geométricas, silhuetas e texturas de materiais em espaços vetoriais multidimensionais, executando comparações quase instantâneas com milhares de milhões de referências de produtos catalogadas.
• Reconhecimento ótico de caracteres integrado (OCR): Textos impressos em placas de identificação de motores elétricos, rótulos de embalagens industriais ou esquemas de ligação são extraídos autonomamente e convertidos em dados pesquisáveis de elevada fiabilidade.
• Coerência entre imagem e texto: As diretrizes da Google para fichas de comerciante exigem que as imagens representem o conteúdo marcado, por isso uma fotografia que contradiz os dados do produto é um problema de políticas além de um problema de correspondência.

Caso uma loja online comercialize componentes de precisão ou artigos de consumo sem fotografias de alta nitidez e contraste apropriado, os agentes de inteligência artificial não conseguirão associar os produtos às pesquisas visuais dos utilizadores.

#O que o Google Lens faz com a fotografia de um produto

A Google apresenta o Lens como uma forma de pesquisar com a câmara, uma imagem ou uma captura de ecrã quando algo é difícil de descrever por palavras (Google Lens). Para compras, a mesma página indica que o Lens descobre quem fabrica um artigo, quanto custa e onde o comprar, e enumera cerca de 35 países onde esses resultados de compras estão disponíveis. O Lens também traduz texto a partir da câmara em mais de 100 idiomas, a mesma leitura de texto que capta rótulos e placas nas fotografias de produto.

Em outubro de 2024 a Google comunicou que o Lens processa quase 20 mil milhões de pesquisas visuais por mês e apresentou uma página de resultados de produto com avaliações, preços de vários retalhistas e locais de compra (Google, 3 de outubro de 2024). Segundo a publicação, o Lens identifica o artigo fotografado com modelos de IA e com o Shopping Graph, que abrange mais de 45 mil milhões de produtos. Não existe uma submissão própria ao Lens para uma loja: um produto chega a essa página de resultados através dos dados que a Google já tem sobre ele, ou seja, o feed do Merchant Center e a própria página de produto. A Google não publica um guia do Lens para proprietários de sites, por isso as alavancas práticas são as documentadas: as diretrizes do Google Imagens, os dados estruturados de produto e os requisitos de imagem do Merchant Center tratados mais abaixo.

#Como a Google lê uma imagem numa página WordPress

O guia de SEO de imagens da Google enumera os sinais que retira da página (Google Search Central, práticas recomendadas de SEO para imagens). Os formatos suportados são BMP, GIF, JPEG, PNG, WebP, SVG e AVIF, e a extensão do ficheiro deve corresponder ao tipo. O texto alternativo é apontado como o atributo mais importante para os metadados de uma imagem, e o guia desaconselha enchê-lo de palavras-chave. O exemplo da Google passa de nenhum alt, para alt="puppy", para alt="Dalmatian puppy playing fetch". Os nomes de ficheiro devem ser curtos e descritivos, pelo que my-new-black-kitten.jpg é melhor do que IMG00023.JPG; vale a pena definir uma regra de renomeação no fluxo de carregamento, porque os ficheiros de câmaras e fornecedores raramente chegam com nomes úteis.

O contexto conta tanto como o ficheiro. A Google extrai informação sobre o tema de uma imagem a partir do conteúdo da página, incluindo legendas e títulos de imagem, e recomenda colocar as imagens perto de texto relevante. As imagens definidas por CSS não são indexadas, o que exclui fotografias de produto inseridas como background-image por construtores de páginas ou plugins de carrossel. Com marcação responsiva, a Google recomenda manter sempre um URL de recurso no atributo src ao lado de srcset ou <picture>; o WordPress já acrescenta srcset e sizes às imagens do conteúdo sem retirar o src (wp_image_add_srcset_and_sizes). Os sitemaps de imagens podem incluir URLs <image:loc> de outros domínios, o que importa quando a biblioteca multimédia é servida a partir de um nome de anfitrião de CDN. Para indicar que imagem representa uma página, o guia remete para primaryImageOfPage, mainEntityOfPage ou a meta tag og:image.

#Arquitetura moderna de processamento gráfico no WordPress: libvips e AVIF

Durante mais de uma década, a arquitetura padrão do WordPress assentou na biblioteca GD (Graphics Draw) em PHP para gerar miniaturas e variações dimensionais. Num catálogo extenso de WooCommerce com dezenas de milhares de referências, a GD provoca picos brutais de consumo de memória RAM e tempos de geração morosos, o que levou muitos lojistas a manter formatos antiquados como JPEG ou PNG.

Uma arquitetura preparada para grandes volumes pode adotar a biblioteca libvips (através do binding php-vips ou de tarefas desacopladas em Node.js com o motor Sharp). O projeto descreve a libvips como uma biblioteca de processamento sob demanda e com threads em paralelo, rápida e com pouco consumo de memória em comparação com bibliotecas semelhantes (libvips), o que torna viável a conversão em massa de um catálogo grande para AVIF:

<?php
/**
 * Conversao de imagens em fluxo continuo para o formato AVIF com libvips no WordPress
 */
declare(strict_types=1);

namespace WPPoland\MediaArchitecturePT;

use Jcupitt\Vips\Image;
use WP_Error;

class ProcessadorImagensModerno
{
    private const QUALIDADE_AVIF = 68; // Equilibrio ideal entre peso de ficheiro e fidelidade de detalhe

    public function gerarVarianteAvif(string $caminhoOrigem, string $caminhoDestino): bool
    {
        if (!file_exists($caminhoOrigem)) {
            return false;
        }

        try {
            // Leitura sequencial de pixeis sem sobrecarregar a memoria RAM do servidor
            $imagem = Image::newFromFile($caminhoOrigem, ['access' => 'sequential']);

            // Gravacao em contentor AVIF preservando metadados IPTC essenciais
            $imagem->writeToFile($caminhoDestino, [
                'Q'           => self::QUALIDADE_AVIF,
                'compression' => 'av1',
                'strip'       => false, // Conserva creditos de autoria e direitos de propriedade
            ]);

            return true;
        } catch (\Throwable $e) {
            error_log(sprintf('Falha na geracao AVIF para %s: %s', $caminhoOrigem, $e->getMessage()));
            return false;
        }
    }
}

O AVIF costuma gerar ficheiros mais pequenos do que o JPEG com qualidade visual comparável e mantém nítidos os contornos e o texto impresso com compressão moderada. Meça a poupança no seu próprio catálogo antes de decidir: fotografias de produto em fundo branco comprimem-se de forma muito diferente de fotografias de ambiente, e os rótulos que têm de continuar legíveis precisam de uma qualidade mais alta do que um fundo liso.

#Como o WordPress 6.5 trata o carregamento de imagens AVIF

O suporte de AVIF chegou ao núcleo do WordPress na versão 6.5 e depende da biblioteca de imagens do servidor: o Imagick ou a GD têm de suportar o formato (anúncio do núcleo do WordPress). O anúncio explica como confirmar no painel do WordPress se o servidor inclui AVIF entre os formatos suportados. Nesse caso, os ficheiros AVIF são carregados e geram tamanhos intermédios como um JPEG ou um PNG. Converter outros formatos é opcional, através do filtro image_editor_output_format; o exemplo do anúncio associa image/jpeg a image/avif.

Há um limite que qualquer plano AVIF de uma loja tem de considerar. O atributo de imagem do Merchant Center aceita JPEG, WebP, PNG, GIF, BMP e TIFF (link de imagem do Merchant Center), e o AVIF não consta da lista. Uma loja que converte cada carregamento para AVIF e apaga os originais fica sem ficheiro para o feed. Guarde um original JPEG ou WebP de cada imagem de produto, ou gere um para o feed, e sirva AVIF aos navegadores através de <picture>.

Para compreender como ligar repositórios de produtos e catálogos volumosos aos sistemas de gestão empresarial, explore o nosso guia sobre integração woocommerce erp.

#Modelação semântica Schema.org com ImageObject e representativeOfPage

Para que os rastreadores web e os agentes de IA atribuam com certeza uma fotografia a uma ficha técnica de produto, os documentos HTML devem disponibilizar metadados estruturados em formato JSON-LD. Em vez de declarar um array básico de URLs de imagens dentro do esquema Product, os programadores devem estruturar entidades ImageObject completas:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://loja-industrial.pt/produtos/valvula-esfera-inox-dn50/#product",
      "name": "Valvula de Esfera em Aco Inoxidavel DN50 PN40",
      "sku": "VALV-SS-DN50",
      "image": [
        {
          "@type": "ImageObject",
          "@id": "https://loja-industrial.pt/media/valvula-dn50-principal.avif",
          "contentUrl": "https://loja-industrial.pt/media/valvula-dn50-principal.avif",
          "url": "https://loja-industrial.pt/media/valvula-dn50-principal.avif",
          "width": "2400",
          "height": "2400",
          "encodingFormat": "image/avif",
          "caption": "Valvula de esfera industrial em inox DN50 vista lateral com alavanca de acionamento",
          "representativeOfPage": true,
          "creditText": "Laboratorio de Testes WPPoland",
          "copyrightNotice": "Todos os direitos reservados 2026",
          "license": "https://loja-industrial.pt/termos-licenciamento-imagens"
        },
        {
          "@type": "ImageObject",
          "@id": "https://loja-industrial.pt/media/valvula-dn50-placa-caracteristicas.avif",
          "contentUrl": "https://loja-industrial.pt/media/valvula-dn50-placa-caracteristicas.avif",
          "url": "https://loja-industrial.pt/media/valvula-dn50-placa-caracteristicas.avif",
          "width": "2000",
          "height": "1500",
          "encodingFormat": "image/avif",
          "caption": "Pormenor da placa de caracteristicas com indicacao de numero de serie e pressao nominal PN40",
          "representativeOfPage": false
        }
      ]
    }
  ]
}

representativeOfPage é uma propriedade do schema.org que marca a imagem principal do produto. O guia de imagens da Google cita primaryImageOfPage, mainEntityOfPage e og:image como formas de indicar a imagem preferida, e para fichas de comerciante exige image e recomenda vários ficheiros de alta resolução (pelo menos 50 000 píxeis, largura vezes altura) nas proporções 16x9, 4x3 e 1x1 (Google Search Central, fichas de comerciante). A Google não documenta que o Lens dê mais peso a alguma destas propriedades, por isso trate-as como uma identificação clara. Incluir uma imagem de pormenor da placa de características com uma descrição textual (caption) rigorosa dá a leitores e a sistemas de leitura de texto a especificação em texto simples ao lado da imagem.

Para certificar que os canais de carregamento de ficheiros se encontram protegidos contra intrusões maliciosas, agende uma auditoria de segurança em wordpress.

#Elementos semânticos picture e otimização do Largest Contentful Paint

O maior desafio da engenharia de desempenho em comércio eletrónico reside em conciliar fotografias de elevadíssima definição com os critérios rigorosos dos Core Web Vitals da Google, nomeadamente a métrica de Largest Contentful Paint (LCP abaixo dos 2,5 segundos).

Uma implementação de frontend moderna recorre ao elemento semântico <picture>, combinando negociação dinâmica de formatos, conjuntos de resoluções em srcset e dimensionamento em sizes:

<!-- Marcacao picture de alto rendimento para a imagem principal do produto -->
<picture class="woocommerce-product-hero-picture">
  <!-- Fluxo AVIF de ultima geracao com compressao superior -->
  <source
    type="image/avif"
    srcset="/media/valvula-dn50-600.avif 600w,
            /media/valvula-dn50-1200.avif 1200w,
            /media/valvula-dn50-2400.avif 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Alternativa WebP para dispositivos anteriores -->
  <source
    type="image/webp"
    srcset="/media/valvula-dn50-600.webp 600w,
            /media/valvula-dn50-1200.webp 1200w,
            /media/valvula-dn50-2400.webp 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Recurso base JPEG para retrocompatibilidade -->
  <img
    src="/media/valvula-dn50-1200.jpg"
    alt="Valvula de esfera em aco inoxidavel DN50 vista lateral"
    width="1200"
    height="1200"
    loading="eager"
    fetchpriority="high"
    decoding="async"
    class="object-cover w-full h-auto"
  />
</picture>

Princípios operacionais indispensáveis:

1. Atributos fetchpriority="high" e loading="eager" na imagem principal: Isto instrui o navegador a priorizar a alocação de largura de banda antes da execução de scripts pesados em JavaScript.
2. Pré-carregamento no elemento <head>: A injeção da diretiva <link rel="preload" as="image" type="image/avif" href="..." imagesrcset="..." imagesizes="..."> permite ao navegador pedir a imagem principal antes de analisar as folhas de estilo.
3. Declaração explícita de width e height: Definir antecipadamente as proporções evita variações cumulativas de layout (Cumulative Layout Shift - CLS) durante a renderização assíncrona.

#Preservação de metadados IPTC vs segurança e privacidade

Muitos plugins de otimização de imagens no WordPress eliminam indiscriminadamente todos os cabeçalhos EXIF e IPTC com o intuito de poupar alguns bytes. Isso remove os campos de autoria e copyright juntamente com os dados privados.

É crucial estabelecer uma segregação cuidada dos tipos de metadados:

• Dados a eliminar (Privacidade e vulnerabilidades): Coordenadas GPS de geolocalização pessoal, números de série de máquinas fotográficas e assinaturas de software de edição gráfica devem ser eliminados na totalidade.
• Dados a conservar (atribuição e direitos de autor): Campos normalizados IPTC como By-line (autor da fotografia), Copyright Notice (titular dos direitos), Headline (título do elemento) e Object Name (identificador ou SKU do produto).

O Google Imagens pode mostrar o autor, o crédito e os dados de licença a partir destes campos, como se descreve na secção seguinte. A Google não afirma que os dados IPTC influenciem o posicionamento, por isso a razão para os manter é a atribuição e os direitos.

#Que campos de licença de imagem o Google Imagens lê

A Google documenta duas formas de associar informação de direitos a uma imagem: metadados IPTC incorporados no ficheiro ou dados estruturados ImageObject na página (Google Search Central, metadados de licença de imagens). No ficheiro, a Google lê Web Statement of Rights, Licensor URL, Creator, Credit Line e Copyright Notice. O Web Statement of Rights é obrigatório para o selo de imagem licenciável no Google Imagens, e os outros quatro são recomendados.

Nos dados estruturados, contentUrl é obrigatório porque a Google o usa para decidir a que imagem se aplicam os metadados. Ao lado dele tem de existir pelo menos uma das propriedades creator, creditText, copyrightNotice ou license, e assim que uma está presente o teste de resultados enriquecidos recomenda as outras três. license é necessária para o selo de licença, e acquireLicensePage aponta para uma página que explica como licenciar a imagem. A Google acrescenta que não garante que estes metadados apareçam nos resultados de pesquisa, e a página nada diz sobre posicionamento. Preencha estes campos na fotografia de produto original como medida de direitos e atribuição. Na codificação IIM antiga, Credit Line é o campo 2:110 e Copyright Notice o 2:116.

#O que o núcleo do WordPress faz com IPTC e EXIF no carregamento

O WordPress lê ele próprio os campos IPTC quando uma imagem é carregada. wp_read_image_metadata() retira o crédito de IPTC Credit (2#110), com Creator (2#080) como alternativa, o copyright de 2#116, a legenda de Description (2#120), o título de Headline (2#105) ou Title (2#005) e a data de criação de 2#055 e 2#060 (referência para programadores do WordPress). Desde a versão 4.4 o filtro wp_read_image_metadata recebe o array IPTC em bruto, e desde a 5.0 também o array EXIF, pelo que um plugin pode mapear um campo adicional, como a referência do fabricante, sem voltar a analisar o ficheiro.

O que sobrevive nos tamanhos gerados depende do editor de imagens. Com o Imagick, thumbnail_image() chama strip_meta(), que remove todos os perfis exceto icc, icm, iptc, exif e xmp (WP_Image_Editor_Imagick::strip_meta). O EXIF está nessa lista protegida, por isso as coordenadas GPS de uma fotografia tirada com o telemóvel podem continuar nas cópias redimensionadas. Se os dados de localização têm de desaparecer, remova-os antes do carregamento ou num passo dedicado, e verifique um tamanho gerado com exiftool em vez de confiar na opção de um plugin.

#Requisitos do Google Merchant Center para feeds de produtos visuais

O Google Merchant Center retira a imagem principal de image_link e até 10 vistas adicionais de additional_image_link (link de imagem, link de imagem adicional). Os requisitos documentados:

1. Dimensão: a Google recomenda imagens de cerca de 1500 x 1500 píxeis ou mais e anunciou um mínimo de 500 x 500 píxeis para todos os produtos a partir de 31 de janeiro de 2027. Os ficheiros não podem exceder 16 MB nem 64 megapíxeis.
2. Formatos: JPEG, WebP, PNG, GIF, BMP e TIFF, com uma extensão que corresponda ao formato. O AVIF não consta da lista.
3. Composição: o produto deve ocupar não menos de 75% e não mais de 90% da imagem, sem molduras, elementos promocionais, marcas de água ou logótipos sobrepostos.
4. Imagens geradas: as imagens criadas com IA generativa têm de conter metadados que o indiquem, e etiquetas incorporadas como IPTC DigitalSourceType não podem ser removidas.
5. Acesso: o robots.txt tem de permitir o Googlebot e o Googlebot-Image, e os URLs das imagens não devem ter parâmetros que mudem a cada envio do feed.

As imagens adicionais são o lugar para ângulos alternativos e fotografias em utilização que mostrem a escala do produto.

Servir os ficheiros de alta resolução a partir de um nome de anfitrião de CDN otimizado para cache afasta os pedidos dos rastreadores ao catálogo do servidor PHP de origem.

#Transformação gráfica na borda da rede e headless WordPress

Em plataformas empresariais de grande tráfego, efetuar o redimensionamento dinâmico de milhares de imagens no servidor principal de WordPress provoca uma sobrecarga severa de processamento. Um padrão comum consiste em transferir esta responsabilidade para os nós de borda da CDN com Cloudflare Images, Fastly Image Optimization ou serviços dedicados em Bun/Sharp.

Principais vantagens da abordagem na borda da rede:

• Síntese sob demanda: Os ficheiros originais de resolução máxima permanecem alojados com segurança em armazenamento de objetos (como S3 ou R2), enquanto os servidores periféricos produzem cópias AVIF ajustadas ao dispositivo do visitante em milissegundos.
• Proteção do servidor de origem: Os pedidos de multimédia dos rastreadores são respondidos pela cache da borda, sem iniciar processos PHP na loja online.
• Ressalva sobre metadados: a opção metadata da Cloudflare aplica-se apenas à saída JPEG. copyright (o valor por omissão) mantém só a etiqueta EXIF de copyright, keep preserva quase todo o EXIF, incluindo a localização GPS, e em qualquer outro formato de saída, WebP e PNG incluídos, todos os metadados são descartados (Cloudflare Images). Uma variante AVIF gerada na borda não leva crédito IPTC, por isso os dados de licença também têm de estar nos dados estruturados da página.
• Total sintonia com arquiteturas headless: Ambientes desacoplados baseados em Astro ou Next.js geram código HTML perfeitamente otimizado, alimentando-se diretamente das imagens fornecidas pela CDN.

Saiba como desenvolvemos plataformas robustas e escaláveis conhecendo a nossa oferta em headless wordpress.

#Controlo automatizado de qualidade e gestão de espaços de cor

Uma lacuna técnica frequente nas lojas online reside na gestão inadequada do perfil de cor dos ficheiros enviados. Os fotógrafos profissionais gravam frequentemente matrizes de imagem no espaço alargado Adobe RGB ou Display P3. Se estas fotografias forem comprimidas sem conversão prévia, as cores surgem desbotadas nos navegadores e deixam de corresponder ao produto real.

Uma cadeia de processamento rigorosa assegura a conversão obrigatória para o perfil sRGB e valida os parâmetros através de testes automatizados:

<?php
/**
 * Testes de integracao para calibracao de espaco de cor sRGB e resolucao
 */
declare(strict_types=1);

namespace WPPoland\Tests\MediaPT;

use PHPUnit\Framework\TestCase;
use Jcupitt\Vips\Image;

class ValidacaoFidelidadeImagemTest extends TestCase
{
    public function testConversaoPerfilCorSrgb(): void
    {
        $caminhoFicheiro = __DIR__ . '/fixtures/amostra-produto.avif';
        $imagem = Image::newFromFile($caminhoFicheiro);

        // Confirma que a imagem adota o espaco de cor sRGB padronizado
        $this->assertEquals('srgb', $imagem->interpretation, 'Todas as imagens de catalogo devem utilizar o perfil sRGB.');
    }

    public function testResolucaoMinimaParaGoogleLens(): void
    {
        $caminhoFicheiro = __DIR__ . '/fixtures/amostra-produto.avif';
        $imagem = Image::newFromFile($caminhoFicheiro);

        $maiorDimensao = max($imagem->width, $imagem->height);
        $this->assertGreaterThanOrEqual(1500, $maiorDimensao, 'A dimensao maxima deve atingir no minimo 1500 pixeis para OCR.');
    }

    public function testDetecaoDuplicadosComHashPercetual(): void
    {
        $validadorHash = new \WPPoland\MediaPT\ValidadorHashPercetual();
        $imagemA = __DIR__ . '/fixtures/amostra-produto.avif';
        $imagemB = __DIR__ . '/fixtures/amostra-produto-copia.avif';

        $resultadoDiferenca = $validadorHash->compararDiferenca($imagemA, $imagemB);
        $this->assertFalse($resultadoDiferenca, 'Imagens com conteudo percetual idêntico devem ser consolidadas.');
    }
}

Este patamar de verificação em pipelines de integração contínua (CI) impede que fotografias com desvios cromáticos ou resoluções deficientes sejam transmitidas ao Google Merchant Center.

#Lista de verificação técnica para auditorias de Google Lens e SEO visual

Antes de lançar as suas melhorias de SEO visual no WordPress e WooCommerce, verifique os seguintes aspetos fundamentais:

1. Validação de MIME-Type do AVIF: Confirme que os servidores remetem os ficheiros com o cabeçalho HTTP Content-Type: image/avif.
2. Integridade dos recursos de reserva: Assegure-se de que o elemento <picture> dispõe de alternativas fiáveis em WebP ou JPEG para navegadores antigos.
3. Afinação de prioridade LCP: Assegure que a imagem principal de topo está munida de fetchpriority="high" e isenta de loading="lazy".
4. Conformidade de Schema.org: Valide no teste de resultados enriquecidos da Google se Product tem image e se os nós ImageObject com dados de licença incluem contentUrl.
5. Salvaguarda de dados IPTC: Certifique-se de que a cadeia de compressão não descarta créditos de autoria nem referências de catálogo.
6. Imagens do feed: Comprove que os endereços em image_link apontam para ficheiros JPEG, WebP ou PNG de cerca de 1500 x 1500 píxeis, e de pelo menos 500 x 500 píxeis antes do requisito de 31 de janeiro de 2027.
7. Legibilidade ótica de etiquetas: Verifique que os textos gravados em placas técnicas permanecem totalmente nítidos para ferramentas de OCR.
8. Política de cache prolongada: Aplique cabeçalhos de expiração alargados (Cache-Control: public, max-age=31536000, immutable) em todos os recursos estáticos.
9. Blindagem de pastas de multimédia: Interdite a execução direta de ficheiros e scripts em PHP dentro do diretório /wp-content/uploads/.
10. Mapa de imagens automatizado: Publique um sitemap XML dedicado com etiquetas <image:image> e submeta-o no Google Search Console e no Bing Webmaster Tools.

A pesquisa visual recompensa o mesmo trabalho de base que o SEO de imagens: ficheiros rastreáveis em formatos suportados, marcação clara e um feed limpo. Se pretende preparar a sua loja, entre em contacto connosco através da nossa página de contacto.