Jeg ser ofte AEO forklart som et eget fagfelt med en egen verktøykasse. Jeg forklarte det slik selv i den første versjonen av denne artikkelen.
Etter å ha gått gjennom Googles oppdaterte veiledning og den nyeste dokumentasjonen fra Lovable, synes jeg en enklere forklaring er mer nyttig.
AEO står for Answer Engine Optimization, ofte kalt svarmotoroptimalisering på norsk. Det handler om å gjøre innholdet enkelt å forstå og nyttig når en søkemotor eller en AI-tjeneste gir noen et direkte svar.
Hva betyr AEO nå?
Begrepet brukes på flere måter.
Noen bruker AEO om featured snippets og stemmesøk. Lovable bruker det bredere om synlighet i AI-søkemotorer som ChatGPT, Perplexity, Claude og Gemini. Google omtaler AI Overviews og AI Mode som deler av vanlig søk, ikke som et eget optimaliseringsfag.
I praktisk arbeid ville jeg brukt en bred definisjon: Hjelp mennesker og maskiner med å finne et tydelig svar på en side de har tilgang til og kan stole på.
Det betyr som regel å gjøre vanlige ting godt. Siden trenger tekst som kan leses av søkemotorer, nyttige overskrifter, presise metadata, gode interne lenker og nok dokumentasjon til å støtte det du skriver.
Hva lover Google egentlig?
Googles nåværende veiledning er ganske enkel. De samme SEO-prinsippene som gjelder for vanlig søk, gjelder også for AI Overviews og AI Mode. Du trenger ikke et eget AI-schema, en AI-tekstfil eller en ekstra teknisk løsning.
Google sier også at du ikke kan merke en side som et featured snippet. Systemene deres avgjør om en del av siden er et godt svar på et bestemt søk.
Det endrer hvordan jeg tenker på arbeidet. En overskrift formet som et spørsmål kan gjøre siden lettere å lese. Et direkte svar under overskriften kan hjelpe både leseren og søkemotoren med å forstå avsnittet. Ingen av delene er en bryter som slår på et featured snippet.
Den gamle versjonen av artikkelen behandlet de første 40 til 60 ordene som et fast uttrekksvindu. Det ville jeg ikke brukt som regel nå. Svar tidlig, men bruk plassen forklaringen trenger.
Hva kan Lovable sjekke?
Lovables SEO & AI search-gjennomgang dekker mye av det tekniske grunnlaget.
Nye Lovable-prosjekter bruker TanStack Start med server-rendering. Eldre React- og Vite-prosjekter bruker forhåndsrendering på forespørsel for verifiserte søke- og AI-crawlere på publiserte adresser. Målet er det samme: Crawleren skal få det faktiske innholdet på siden, ikke bare et tomt lasteskall.
Gjennomgangen kan blant annet sjekke:
- sidetitler og beskrivelser;
- Open Graph-metadata;
- strukturert data og innstillinger for indeksering;
robots.txtogsitemap.xml;- ytelse, tilgjengelighet og mobilbruk på den publiserte siden;
- Google Search Console når koblingen er aktivert.
Det er nyttig, men verktøyet bestemmer ikke hva siden bør si. Det kan ikke legge til erfaring du ikke har, velge det beste eksemplet eller kontrollere en påstand mot originalkilden for deg.
Hva må du fortsatt skrive selv?
Start med personen som leser siden.
Hvis overskriften spør "Hva er AEO?", bør det første avsnittet svare på spørsmålet med ord en nybegynner forstår. Detaljene kan komme etterpå.
Bruk ordene folk søker etter, men ikke press alle overskrifter inn i et søkeordsmønster. En naturlig overskrift som hjelper leseren, er bedre enn en som bare er skrevet for en crawler.
Gi svaret støtte. Det kan være et ekte eksempel, en test du har kjørt, et skjermbilde eller en lenke til original dokumentasjon. AI-søk har mer å arbeide med når siden inneholder konkret informasjon som kan kontrolleres.
Behold viktig informasjon som tekst. Bilder og video kan støtte forklaringen, men de bør ikke være det eneste stedet svaret finnes.
Koble deretter siden til annet relevant innhold på nettstedet ditt. Interne lenker hjelper leseren videre og gjør det lettere for søkesystemer å forstå hvordan temaene henger sammen.
En praktisk sjekk av én side
Velg en side som skal svare på et tydelig spørsmål, og les den uten å tenke på rangering.
Spør:
- Forstår en ny leser svaret fra den første delen av siden?
- Viser siden hvor de viktigste påstandene kommer fra?
- Ser du hovedinnholdet i sidekilden, eller først etter at JavaScript har kjørt?
- Stemmer tittelen og beskrivelsen med det siden faktisk forklarer?
- Finnes det en nyttig neste side å lenke til?
Kjør deretter Lovables SEO & AI search-gjennomgang. Rett de tekniske funnene som gjelder, publiser siden, og følg utviklingen i Google Search Console. Synlighet i søk er et resultat du må observere, ikke noe et schema kan garantere.
Når hjelper strukturert data?
Strukturert data har fortsatt en oppgave. Det kan beskrive blant annet en artikkel, et produkt, en organisasjon, et arrangement eller en brødsmulesti i et format søkesystemer forstår.
Innholdet bør stemme med det som er synlig på siden. Google anbefaler dette både for vanlig søk og for AI-funksjonene sine.
Rådene rundt FAQ- og HowTo-markup har derimot endret seg.
Google sluttet å vise FAQ-rike resultater 7. mai 2026 og fjernet dokumentasjonen i juni. Google dokumenterer heller ikke lenger HowTo som et støttet rikt søkeresultat. Jeg ville derfor ikke lagt til noen av dem bare for å få mer plass i Googles søkeresultater.
Andre tjenester kan fortsatt lese denne markupen, så det kan finnes gode grunner til å beholde den. Vær bare tydelig på hvorfor den er der.
Et fornuftig sted å begynne
Hvis du vil forbedre én side for AEO, begynn med åpningen.
Skriv et direkte svar som en person forstår. Sørg for at siden kan leses av crawlere. Sjekk tittel, beskrivelse, interne lenker og dokumentasjonen bak påstandene. Bruk deretter Lovables gjennomgang og Search Console til å finne tekniske problemer og se hva som skjer etter publisering.
Det er mindre spennende enn en ny samling optimaliseringstriks. Det ligger også nærmere det Google og Lovable faktisk anbefaler nå.
