Google Lens og multimodal AI-søk: optimalisere bilder i WordPress og WooCommerce

Måten brukere søker etter produkter på nettet gjennomgår en markant overgang fra tradisjonelle tekstspørringer til rike multimodale henvendelser. Forbrukere og bedriftskunder retter i økende grad mobilkameraet mot tekniske komponenter, maskindeler eller emballasjer for å identifisere varer, sammenligne priser og finne forhandlere via Google Lens, ChatGPT Vision eller Bing Visual Search. Samtidig benytter autonome KI-systemer nettbutikkens bildemateriale som et primært datagrunnlag for å lese av mål, spesifikasjoner og godkjenninger direkte fra pikslene.

For utviklere og nettbutikkeiere som drifter WordPress og WooCommerce betyr dette at mediehåndteringen må moderniseres. Utdaterte rutiner som baserer seg på ukomprimerte JPEG-filer og overfladiske alt-tekster strekker ikke lenger til for å oppnå synlighet i neste generasjons visuelle handleflater.

#Den økende rollen til visuelt søk og multimodale modeller

Fremveksten av ledende multimodale modeller som Google Gemini og OpenAI GPT-4o har endret hvordan søkeroboter tolker visuelle ressurser. Tidligere var søkemotorene avhengige av teksten rundt bildet, filnavnet og enkle metatagger. I dag gjennomfører visuelle søkemotorer avansert pikselanalyse i sanntid:

• Visuelle vektorelementer (Visual Embeddings): Bildemodellene oversetter former, konturer og overflateteksturer til høydimensjonale vektorer, og sammenligner dem mot milliarder av registrerte vareprøver.
• Optisk tegngjenkjenning (OCR): Tekst på typeskilt, tekniske datablad, ingredienslister og produktesker leses ut automatisk og gjøres søkbar.
• Samsvar mellom tekst og bilde: Googles retningslinjer for forhandleroppføringer krever at bildene viser det merkede innholdet, så et bilde som motsier produktdataene er et regelbrudd i tillegg til et matcheproblem.

Dersom en WooCommerce-butikk mangler skarpe, høyoppløselige fotografier med gode kontraster, vil ikke KI-assistentene klare å koble varene mot brukernes kamerasøk.

#Hva Google Lens gjør med et produktbilde

Google beskriver Lens som en måte å søke med kameraet, et bilde eller en skjermdump på når noe er vanskelig å beskrive med ord (Google Lens). For netthandel sier den samme siden at Lens finner ut hvem som lager en vare, hva den koster og hvor den kan kjøpes, og den lister opp rundt 35 land der disse handleresultatene er tilgjengelige. Lens oversetter også tekst fra kameraet på over 100 språk, den samme tekstlesingen som fanger opp etiketter og typeskilt på produktbilder.

I oktober 2024 opplyste Google at Lens håndterer nesten 20 milliarder visuelle søk i måneden, og lanserte en produktresultatside med anmeldelser, priser fra flere forhandlere og kjøpssteder (Google, 3. oktober 2024). Ifølge innlegget identifiserer Lens den fotograferte varen med KI-modeller og Shopping Graph, som omfatter mer enn 45 milliarder produkter. Det finnes ingen egen Lens-innsending for nettbutikker: et produkt når den resultatsiden gjennom data Google allerede har om det, altså Merchant Center-feeden og selve produktsiden. Google publiserer ingen Lens-veiledning for nettstedseiere, så de praktiske verktøyene er de dokumenterte: retningslinjene for Google Bilder, strukturerte produktdata og bildekravene i Merchant Center, som beskrives nedenfor.

#Hvordan Google leser et bilde på en WordPress-side

Googles veiledning for bilde-SEO lister opp signalene Google henter fra siden (Google Search Central, beste praksis for bilder). Støttede formater er BMP, GIF, JPEG, PNG, WebP, SVG og AVIF, og filendelsen bør stemme med filtypen. Alt-teksten omtales som det viktigste attributtet for bildemetadata, og veiledningen fraråder å fylle den med søkeord. Googles eget eksempel går fra manglende alt, via alt="puppy", til alt="Dalmatian puppy playing fetch". Filnavn bør være korte og beskrivende, så my-new-black-kitten.jpg er bedre enn IMG00023.JPG. En regel for nytt filnavn i opplastingsflyten lønner seg, fordi filer fra kameraer og leverandører sjelden kommer med nyttige navn.

Konteksten teller like mye som filen. Google henter informasjon om motivet i et bilde fra innholdet på siden, også bildetekster og bildetitler, og anbefaler å plassere bilder nær relevant tekst. Bilder som legges inn via CSS, blir ikke indeksert, og det utelukker produktbilder som sidebyggere eller karusellutvidelser setter inn som background-image. Med responsiv markering anbefaler Google å alltid beholde en reserve-URL i src-attributtet ved siden av srcset eller <picture>; WordPress legger allerede til srcset og sizes på bilder i innholdet uten å fjerne src (wp_image_add_srcset_and_sizes). Bildekart kan inneholde <image:loc>-URL-er på andre domener, noe som betyr noe når mediebiblioteket leveres fra et CDN-vertsnavn. For å angi hvilket bilde som representerer en side, viser veiledningen til primaryImageOfPage, mainEntityOfPage eller metataggen og:image.

#Moderne bildebehandling i WordPress: libvips og AVIF

I mange år har standardinstallasjoner av WordPress benyttet PHP-biblioteket GD (Graphics Draw) for å generere bildestørrelser. I store nettbutikker med titusenvis av varelinjer fører dette til høyt minneforbruk og langsom bildebehandling, noe som har tvunget mange over på eldre formater.

En moderne teknisk plattform kan ta i bruk libvips (via bindingen php-vips eller eksterne bakgrunnsprosesser med Sharp). Prosjektet beskriver libvips som et behovsstyrt, horisontalt trådet bibliotek som er raskt og bruker lite minne sammenlignet med lignende biblioteker (libvips). Det gjør massekonvertering av en stor katalog til AVIF praktisk gjennomførbar:

<?php
/**
 * Stromningsbasert bildekonvertering til AVIF med libvips i WordPress
 */
declare(strict_types=1);

namespace WPPoland\MediaArchitectureNO;

use Jcupitt\Vips\Image;
use WP_Error;

class ModernImageProcessor
{
    private const KVALITET_AVIF = 68; // Balansert forhold mellom filstoerrelse og bildekvalitet

    public function genererAvifVariant(string $kildeSti, string $maalSti): bool
    {
        if (!file_exists($kildeSti)) {
            return false;
        }

        try {
            // Sekvensiell lesing av bildepiksler uten a overbelaste minnet
            $bilde = Image::newFromFile($kildeSti, ['access' => 'sequential']);

            // Lagring til AVIF med bevaring av viktige IPTC-data
            $bilde->writeToFile($maalSti, [
                'Q'           => self::KVALITET_AVIF,
                'compression' => 'av1',
                'strip'       => false, // Bevar IPTC-opphavsrett og vareidentifikatorer
            ]);

            return true;
        } catch (\Throwable $e) {
            error_log(sprintf('Kunne ikke generere AVIF for %s: %s', $kildeSti, $e->getMessage()));
            return false;
        }
    }
}

AVIF gir som regel mindre filer enn JPEG ved sammenlignbar bildekvalitet, og holder kanter og trykt tekst rene ved moderat komprimering. Mål besparelsen på din egen katalog før du bestemmer deg: produktbilder på hvit bakgrunn komprimeres helt annerledes enn miljøbilder, og etiketter som skal være lesbare trenger høyere kvalitet enn en jevn bakgrunn.

#Hvordan WordPress 6.5 håndterer opplasting av AVIF

AVIF-støtte kom inn i WordPress-kjernen i versjon 6.5, og den avhenger av bildebiblioteket på serveren: Imagick eller GD må støtte formatet (kunngjøring fra WordPress-kjerneteamet). Kunngjøringen forklarer hvordan du sjekker i WordPress-kontrollpanelet om serveren oppgir AVIF blant de støttede formatene. Gjør den det, lastes AVIF-filer opp og genererer mellomstørrelser på samme måte som JPEG eller PNG. Konvertering av andre formater er valgfritt og går via filteret image_editor_output_format; eksemplet i kunngjøringen kobler image/jpeg til image/avif.

Én begrensning hører hjemme i enhver AVIF-plan for en nettbutikk. Bildeattributtet i Merchant Center godtar JPEG, WebP, PNG, GIF, BMP og TIFF (Merchant Center, bildelenke), og AVIF står ikke på listen. En butikk som konverterer hver opplasting til AVIF og sletter originalene, har ingen fil igjen til feeden. Behold en JPEG- eller WebP-original av hvert produktbilde, eller generer en for feeden, og lever AVIF til nettlesere via <picture>.

Les mer om hvordan du knytter nettbutikken sammen med sentrale forretningssystemer i vår guide om woocommerce erp integrasjon.

#Semantisk merking med Schema.org og ImageObject

For at søkemotorer og KI-agenter skal forstå hvilket bilde som tilhører hvilken vare, må nettsidene inneholde strukturerte data i JSON-LD-format. I stedet for en enkel liste med URL-er bør man definere fullstendige ImageObject-oppføringer:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://industributikk.no/produkt/kuleventil-syrefast-dn50/#product",
      "name": "Kuleventil i syrefast stal DN50 PN40",
      "sku": "VALV-SS-DN50",
      "image": [
        {
          "@type": "ImageObject",
          "@id": "https://industributikk.no/media/kuleventil-dn50-hoved.avif",
          "contentUrl": "https://industributikk.no/media/kuleventil-dn50-hoved.avif",
          "url": "https://industributikk.no/media/kuleventil-dn50-hoved.avif",
          "width": "2400",
          "height": "2400",
          "encodingFormat": "image/avif",
          "caption": "Syrefast kuleventil DN50 sett fra siden med handtak",
          "representativeOfPage": true,
          "creditText": "WPPoland Testlaboratorium",
          "copyrightNotice": "Alle rettigheter forbeholdt 2026",
          "license": "https://industributikk.no/lisensvilkaar-bilder"
        },
        {
          "@type": "ImageObject",
          "@id": "https://industributikk.no/media/kuleventil-dn50-typeskilt.avif",
          "contentUrl": "https://industributikk.no/media/kuleventil-dn50-typeskilt.avif",
          "url": "https://industributikk.no/media/kuleventil-dn50-typeskilt.avif",
          "width": "2000",
          "height": "1500",
          "encodingFormat": "image/avif",
          "caption": "Naerbilde av typeskilt med serienummer og trykklasse PN40",
          "representativeOfPage": false
        }
      ]
    }
  ]
}

representativeOfPage er en schema.org-egenskap som markerer produktets hovedbilde. Googles bildeveiledning nevner primaryImageOfPage, mainEntityOfPage og og:image som måter å angi et foretrukket bilde på, og for forhandleroppføringer krever Google image og anbefaler flere høyoppløselige filer (minst 50 000 piksler, bredde ganger høyde) i forholdene 16x9, 4x3 og 1x1 (Google Search Central, forhandleroppføringer). Google dokumenterer ikke at Lens legger ekstra vekt på noen av disse egenskapene, så de fungerer som tydelig merking. Et nærbilde av typeskiltet med en presis caption gir både lesere og tekstlesende systemer spesifikasjonen i ren tekst ved siden av bildet.

For å verifisere at nettbutikken er skjermet mot uautorisert tilgang, anbefaler vi en grundig sikkerhetsrevisjon for wordpress.

#Responsiv picture-oppbygning og optimalisering av LCP

En av de største utfordringene i nettbutikker er å levere skarpe detaljbilder uten at det går ut over kravene til Core Web Vitals (Largest Contentful Paint under 2,5 sekunder).

Løsningen er å benytte det semantiske <picture>-elementet med formatforhandling og tilpassede srcset- og sizes-attributter:

<!-- Responsivt picture-element for hovedproduktbilde -->
<picture class="woocommerce-product-hero-picture">
  <!-- Prioritert AVIF-format -->
  <source
    type="image/avif"
    srcset="/media/ventil-dn50-600.avif 600w,
            /media/ventil-dn50-1200.avif 1200w,
            /media/ventil-dn50-2400.avif 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- WebP-reserve for eldre nettlesere -->
  <source
    type="image/webp"
    srcset="/media/ventil-dn50-600.webp 600w,
            /media/ventil-dn50-1200.webp 1200w,
            /media/ventil-dn50-2400.webp 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Standard JPEG som siste fallback -->
  <img
    src="/media/ventil-dn50-1200.jpg"
    alt="Kuleventil DN50 i syrefast stal sett fra siden"
    width="1200"
    height="1200"
    loading="eager"
    fetchpriority="high"
    decoding="async"
    class="object-cover w-full h-auto"
  />
</picture>

Viktige prinsipper:

1. fetchpriority="high" og loading="eager" på hovedbildet: Dette sørger for at nettleseren prioriterer bildet foran tunge skript.
2. Forhåndslasting i <head>: En tagg som <link rel="preload" as="image" type="image/avif" href="..." imagesrcset="..." imagesizes="..."> lar nettleseren be om hovedbildet før stilarkene er lest inn.
3. Faste mål for width og height: Dette forhindrer uønsket forskyvning av innholdet (Cumulative Layout Shift, CLS).

#Bevaring av IPTC-metadata og personvernhensyn

Mange optimaliseringsutvidelser i WordPress sletter alle metadata ukritisk for å spare noen få kilobyte. Da forsvinner feltene for fotograf og opphavsrett sammen med de private dataene.

Man bør skille tydelig mellom ulike typer metadata:

• Data som skal slettes: Nøyaktige GPS-koordinater, kameraets serienummer og teknisk programvareinformasjon bør renses av hensyn til personvern og sikkerhet.
• Data som skal bevares: Standardiserte IPTC-felter som By-line (fotograf), Copyright Notice (rettighetshaver), Headline (tittel) og Object Name (varenummer/SKU).

Google Bilder kan vise fotograf, kreditering og lisensdata fra disse feltene, som beskrevet i neste avsnitt. Google sier ikke at IPTC-data påvirker rangeringen, så grunnen til å beholde dem er kreditering og rettigheter.

#Hvilke bildelisensfelt Google Bilder leser

Google dokumenterer to måter å knytte rettighetsinformasjon til et bilde på: IPTC-fotometadata innebygd i filen, eller strukturerte data av typen ImageObject på siden (Google Search Central, metadata for bildelisenser). Fra filen leser Google Web Statement of Rights, Licensor URL, Creator, Credit Line og Copyright Notice. Web Statement of Rights er påkrevd for lisensmerket i Google Bilder, og de fire andre er anbefalt.

I strukturerte data er contentUrl påkrevd fordi Google bruker den til å avgjøre hvilket bilde metadataene gjelder. I tillegg må minst én av egenskapene creator, creditText, copyrightNotice eller license være med, og så snart én er satt, anbefaler testen for rike resultater de tre andre. license trengs for lisensmerket, og acquireLicensePage peker til en side som forklarer hvordan bildet kan lisensieres. Google legger til at det ikke garanterer at disse metadataene vises i søkeresultatene, og siden sier ingenting om rangering. Fyll ut feltene for egne produktbilder som et tiltak for rettigheter og kreditering. I den eldre IIM-kodingen er Credit Line felt 2:110 og Copyright Notice felt 2:116.

#Hva WordPress-kjernen gjør med IPTC og EXIF ved opplasting

WordPress leser IPTC-felt selv når et bilde lastes opp. wp_read_image_metadata() henter kreditering fra IPTC Credit (2#110) med Creator (2#080) som reserve, opphavsrett fra 2#116, bildetekst fra Description (2#120), tittel fra Headline (2#105) eller Title (2#005) og opprettelsestidspunkt fra 2#055 og 2#060 (WordPress utviklerreferanse). Siden versjon 4.4 får filteret wp_read_image_metadata den rå IPTC-tabellen, og siden 5.0 også EXIF-tabellen, så en utvidelse kan hente et ekstra felt som produsentens delenummer uten å lese filen på nytt.

Hva som overlever i de genererte størrelsene, avhenger av bildeeditoren. Med Imagick kaller thumbnail_image() metoden strip_meta(), som fjerner alle profiler unntatt icc, icm, iptc, exif og xmp (WP_Image_Editor_Imagick::strip_meta). EXIF står på den beskyttede listen, så GPS-koordinater fra et mobilbilde kan bli liggende i nedskalerte kopier. Hvis posisjonsdata må bort, fjern dem før opplasting eller i et eget steg, og kontroller en generert størrelse med exiftool i stedet for å stole på en innstilling i en utvidelse.

#Krav til produktfeeder i Google Merchant Center

Google Merchant Center henter hovedbildet fra image_link og opptil 10 ekstra visninger fra additional_image_link (bildelenke, ekstra bildelenke). De dokumenterte kravene:

1. Størrelse: Google anbefaler bilder på rundt 1500 x 1500 piksler eller mer og har varslet et minimum på 500 x 500 piksler for alle produkter fra 31. januar 2027. Filene kan ikke være større enn 16 MB eller 64 megapiksler.
2. Formater: JPEG, WebP, PNG, GIF, BMP og TIFF, med en filendelse som stemmer med formatet. AVIF står ikke på listen.
3. Komposisjon: Produktet skal fylle minst 75 % og høyst 90 % av bildet, uten rammer, reklameelementer, vannmerker eller påklistrede logoer.
4. Genererte bilder: Bilder laget med generativ KI må ha metadata som sier det, og innebygde tagger som IPTC DigitalSourceType skal ikke fjernes.
5. Tilgang: robots.txt må tillate både Googlebot og Googlebot-Image, og bilde-URL-er bør ikke ha parametere som endres ved hver feedinnsending.

Ekstra bildelenker er stedet for andre vinkler og bilder i bruk som viser størrelsen på produktet.

Når høyoppløselige filer leveres fra et CDN-vertsnavn optimalisert for hurtigbuffer, havner ikke crawlerforespørsler mot store kataloger hos PHP-opprinnelsesserveren.

#Bildebehandling i kantskyen og hodeløs WordPress

For store nettbutikker med mange besøkende kan dynamisk bildegenerering på WordPress-serveren føre til unødig belastning. Et vanlig mønster er å flytte disse oppgavene ut i kanten av nettverket med Cloudflare Images, Fastly eller egne mikrotjenester.

Fordeler med kantskymodellen:

• Sanntidstilpasning: Originalfilene oppbevares trygt i skylagring, mens kantskyservere genererer AVIF-filer i riktig størrelse på millisekunder.
• Skjerming av hovedserveren: Crawlerforespørsler etter mediefiler besvares fra hurtigbufferen i kanten, så statiske bilder starter ingen PHP-prosess.
• Forbehold om metadata: Cloudflares metadata-valg gjelder bare JPEG-utdata. copyright (standard) beholder bare EXIF-taggen for opphavsrett, keep bevarer det meste av EXIF inkludert GPS-posisjon, og for alle andre utdataformater, også WebP og PNG, forkastes alle metadata (Cloudflare Images). En AVIF-variant laget i kanten har ingen IPTC-kreditering, så lisensdataene må også ligge i sidens strukturerte data.
• Rask levering i hodeløse oppsett: Frakoblede løsninger med Astro eller Next.js henter optimaliserte bilder direkte uten å belaste WordPress-basen.
• Båndbreddeinnsparing: Automatisk formatforhandling sikrer at eldre enheter får WebP mens moderne enheter mottar AVIF med minimal nyttelast.
• Umiddelbar sletting ved bildebytte: Ved oppdatering av produktbilder sendes en tømmingsforespørsel via API direkte til kantskyen, slik at nye bilder vises umiddelbart for alle brukere.

Lær mer om våre leveranser innen headless wordpress.

#Automatisert kvalitetskontroll og fargeromshåndtering

Et ofte oversett problem i nettbutikker er fargerommet i bildene. Originalfotografier leveres ofte i Adobe RGB eller Display P3. Hvis disse konverteres uten fargestyring, kan fargene bli blasse eller feilaktige i nettleseren og ikke lenger stemme med det fysiske produktet.

En profesjonell arbeidsflyt tvinger frem konvertering til standard sRGB og tester bildekvaliteten automatisk:

<?php
/**
 * Integrasjonstest for sRGB-fargerom og bildeopploesning
 */
declare(strict_types=1);

namespace WPPoland\Tests\MediaNO;

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

class ImageFidelityValidationTest extends TestCase
{
    public function testFargeromKonvertertTilSrgb(): void
    {
        $testBildeSti = __DIR__ . '/fixtures/vareproeve.avif';
        $bilde = Image::newFromFile($testBildeSti);

        // Verifiserer at bildet benytter standard sRGB-fargerom
        $this->assertEquals('srgb', $bilde->interpretation, 'Alle bilder for Google Shopping ma vaere i sRGB.');
    }

    public function testMinimumsOpploesningForGoogleLens(): void
    {
        $testBildeSti = __DIR__ . '/fixtures/vareproeve.avif';
        $bilde = Image::newFromFile($testBildeSti);

        $lengsteSide = max($bilde->width, $bilde->height);
        $this->assertGreaterThanOrEqual(1500, $lengsteSide, 'Bildet ma ha minst 1500 piksler for palitelig OCR.');
    }

    public function testUnngaaDupliserteBilderMedPerseptuellHash(): void
    {
        $hashBeregner = new \WPPoland\MediaNO\PerceptualHashValidator();
        $testBilde1 = __DIR__ . '/fixtures/vareproeve.avif';
        $testBilde2 = __DIR__ . '/fixtures/vareproeve-kopi.avif';

        $erUnikt = $hashBeregner->compareDifference($testBilde1, $testBilde2);
        $this->assertFalse($erUnikt, 'Bilder med identisk perseptuell hash ma avvises for a unngaa indekseringskonflikter.');
    }
}

Denne kvalitetssikringen forhindrer at uskarpe bilder, feilaktige farger eller unødvendige duplikater havner i feeden til Google Merchant Center.

#Teknisk sjekkliste for Google Lens og visuell SEO

Gå gjennom følgende punkter før du ruller ut oppdaterte bilder i butikken:

1. Riktig MIME-type: Kontroller at serveren sender ut AVIF-filer med Content-Type: image/avif.
2. Fungerende reserver: Påse at <picture>-elementet har gode WebP- eller JPEG-alternativer for eldre klienter.
3. Prioritering av LCP: Sjekk at hovedbildet har fetchpriority="high" og ikke forsinkes av loading="lazy".
4. Validering av Schema.org: Bekreft i testen for rike resultater at Product har image, og at ImageObject-noder med lisensdata har contentUrl.
5. Bevaring av IPTC-data: Sjekk at bildekomprimeringen ikke fjerner informasjon om opphavsrett og varenummer.
6. Feedbilder: Verifiser at bildene i feeden er JPEG, WebP eller PNG, rundt 1500 x 1500 piksler, og minst 500 x 500 piksler før kravet fra 31. januar 2027.
7. Skarpe typeskilt: Sørg for at serienumre og etiketter er lette å lese for OCR-algoritmer.
8. Gode cache-regler: Sett lang levetid (Cache-Control: public, max-age=31536000, immutable) på alle optimaliserte medier.
9. Sikring av opplastingsmappen: Blokker kjøring av PHP-skript i /wp-content/uploads/ for å hindre angrep.
10. Automatisk bildekart: Generer og oppdater et eget XML-bildekart med <image:image>-tagger som sendes inn til Google Search Console og Bing Webmaster Tools.

Visuelt søk belønner det samme grunnarbeidet som bilde-SEO: crawlbare filer i støttede formater, tydelig merking og en ren feed. Ta gjerne kontakt med oss via vår kontaktside for en gjennomgang av din løsning.