Etter audit av 50+ norske nettsider er det de samme ti feilene vi finner igjen og igjen. Her er hva de er, hvorfor de skader AI-synlighet, og hvordan vi fikser dem.
Kort fortalt: De ti vanligste AEO-feilene vi finner på norske nettsider er: manglende llms.txt, blokkering av AI-bots i robots.txt, 307-redirect mellom apex og www, canonical som peker til ikke-eksisterende domene, manglende schema.org, ingen FAQ-markup, ingen sameAs til Brønnøysund, ulik info mellom GBP og nettside, manglende Quick Answer-blokker, og statiske HTML-mangler på SPA-er. Alle ti er enkle å fikse på under en uke samlet.
Etter å ha auditert 50+ norske nettsider gjennom vår AEO-grunnmurprosess, er det slående hvor like feilene er. De fleste byråer leverer en nettside som rangerer akseptabelt i klassisk Google-søk, men som ikke siteres i ChatGPT, Gemini, Perplexity eller Google AI Overviews — fordi de ikke har bygget for det.
Her er ti feilene vi finner igjen og igjen, rangert etter hvor stor effekt det har når vi fikser dem.
Sjansen for at en nettside vi auditer har llms.txt: under fem prosent.
llms.txt er en åpen standard som beskriver bedriften din i et format AI-modeller leser direkte. Det er en kort markdown-fil ved roten av domenet som inneholder firmainformasjon, tjenester, kontakt og lenker til viktige sider. ChatGPT, Claude og Perplexity har alle annonsert at de planlegger å bruke standarden aktivt.
Hvorfor det skader: Uten llms.txt må AI-modeller skrape hele nettsiden og gjette hvem du er. Med llms.txt har du fortalt dem nøyaktig.
Hvordan vi fikser det: Vi skriver en strukturert llms.txt for hver kunde, typisk 200-400 linjer, plassert på https://kundens-domene.no/llms.txt. Tid: 30-45 minutter per kunde.
Vi har sett robots.txt-filer som eksplisitt blokkerer GPTBot, ClaudeBot, CCBot og Bytespider. Ofte er det WordPress-plugins eller eldre konfigurasjon som er ansvarlig — ikke en bevisst beslutning.
Hvorfor det skader: Hvis AI-modellenes crawlere ikke får lov å lese nettsiden din, kan de heller ikke sitere den. Det er som å sette opp et «no entry»-skilt og lure på hvorfor ingen kommer inn.
Hvordan vi fikser det: Vi går gjennom robots.txt og fjerner blokkering for 11+ AI-bots. Samtidig legger vi til en Sitemap:-referanse hvis den mangler. Tid: 10 minutter.
Dette er en av de mest skadelige tekniske feilene, og den er nesten alltid usynlig for kunden. Når brukeren skriver kundens-domene.no i nettleseren, blir de redirected til www.kundens-domene.no — men med statuskode 307 (Temporary Redirect) i stedet for 301 (Permanent Redirect).
Hvorfor det skader: 307 forteller Google «behold begge URL-er i indeksen, dette kan flippes tilbake.» Resultatet: nettsiden din indekseres på to URL-er som splitter alle SEO-signaler. Verre: schema.org-data på den ene varianten blir koblet til en annen entitet enn det canonical-link sier.
Hvordan vi fikser det: I Vercel Dashboard endrer vi redirect-type fra Temporary til Permanent. Det kan ikke gjøres via vercel.json — Vercel sin Domain-config overrider den. Tid: 5 minutter, men må gjøres manuelt i UI-en.
Vi så dette på en kunde-nettside i fjor: live på kunden.vercel.app, men <link rel="canonical"> pekte til kundensbedriftnavn.no — som aldri var registrert. Google indekserte siden på Vercel-domenet og koblet den til en URL som returnerte 404.
Det er typisk en Lovable-arv. Maler pre-fyller canonical med tiltenkt produksjonsdomene, og noen ganger glemmer utvikleren å oppdatere det når DNS aldri ble satt opp.
Hvorfor det skader: Alt indekserings-arbeid blir koblet til en URL som ikke finnes. Du «eksisterer» i Googles indeks, men ingen kan klikke seg dit.
Hvordan vi fikser det: Vi gjør curl-test av canonical-URL-en på hver kundeside vi auditer. Hvis den returnerer NXDOMAIN, korrigerer vi canonical til den faktiske live-URL-en og åpner en sak for DNS-setup om aktuelt. Tid: 15-30 minutter.
Det vanligste vi ser: én LocalBusiness-blokk med navn, adresse og telefon — og ingenting annet. Ingen Organization, ingen WebSite, ingen Service per tjeneste, ingen FAQPage, ingen Person.
Hvorfor det skader: AI-modeller bygger interne entitetsgrafer fra schema.org. En isolert LocalBusiness uten kobling til Organization eller Person blir behandlet som en svak noden. Konkurrenter med komplette grafer prioriteres.
Hvordan vi fikser det: Vi implementerer vår syv-typer-grunnmur (se vår recipe for schema.org for norske bedrifter). Tid: 6-8 timer per kunde-prosjekt, inkludert datainnsamling.
De fleste norske nettsider har en FAQ-seksjon nederst på forsiden. Den er kjekk for brukere, men ikke maskin-leselig fordi den ikke har FAQPage-schema rundt seg.
Hvorfor det skader: FAQ-spørsmål er det formatet AI-modeller siterer aller oftest. ChatGPT trekker gjerne ut hele Q&A-par direkte hvis spørsmålet matcher det brukeren spurte om. Uten schema er det bare tekst — AI-en må gjette hva som er spørsmål og hva som er svar.
Hvordan vi fikser det: Vi pakker eksisterende FAQ-seksjoner i FAQPage-schema og typisk omformer 3-7 av spørsmålene så de matcher faktiske buyer-intent-søk. Tid: 1-2 timer per side.
sameAs-arrayet i Organization-schemaet er det som forteller AI-modeller at du er en ekte, verifisert norsk bedrift. Pekene som teller mest:
brreg.no/enhet/<orgnr>)proff.no/selskap/...)1881.no/...)Vi finner ofte at sameAs er tomt, eller bare inneholder LinkedIn og Facebook. Det er ikke nok.
Hvorfor det skader: AI-modeller validerer entiteter ved å sjekke om de finnes flere uavhengige steder. Hvis du bare finnes på din egen nettside og Facebook, ser du ut som en hjemmelaget side, ikke en juridisk bedrift.
Hvordan vi fikser det: Vi slår opp orgnr i Brønnøysund (5 min), finner Proff-side (gratis automatisk-oppretting) og 1881-oppføring (gratis registrering), og legger alle inn i sameAs. Tid: 15-30 minutter per kunde.
Klassisk eksempel: GBP sier åpningstid 09:00-17:00, nettsidens schema sier 10:00-19:00, og kontakt-siden sier 08:00-16:00. Hver kilde har sin egen versjon.
Hvorfor det skader: Google er nå begynt å straffe inkonsistens mellom GBP og strukturert data på nettsiden. Det er et ranking-signal. Verre: når noen spør ChatGPT om åpningstider, vil modellen ofte velge en av kildene tilfeldig — og du får forskjellige svar fra forskjellige brukere.
Hvordan vi fikser det: Vi standardiserer på én sannhetskilde (typisk schema.org via openingHoursSpecification) og oppdaterer GBP til å matche. Vi setter også en månedlig påminnelse om å synkronisere ved sesongendringer (sommertid, julestengt). Tid: 30 minutter første gang, deretter løpende.
74 prosent av AI-citations kommer fra «Top N»-format-innhold ifølge industri-data fra 2026. Hvis pillar-sidene dine bare er prosa-tekst uten nummererte eller punkterte sammendrag tidlig på siden, går du glipp av tre fjerdedeler av citation-potensialet ditt.
Hvorfor det skader: AI-modeller foretrekker å sitere strukturert innhold de kan klippe ut og presentere uten omskriving. En lang prosa-tekst krever omskriving og er risikabel — en topp-fem-liste er enkel å sitere.
Hvordan vi fikser det: Vi legger til en «Kort fortalt»-blokk på toppen av hver pillar-side med 4-5 nummererte punkter som hvert er en konkret påstand. Vi bygger også på ItemList-schema rundt blokken så AI-en ser strukturen tydelig. Tid: 30-60 minutter per side.
Dette er den mest tekniske feilen, og den rammer omtrent halvparten av kundene vi auditer — særlig de som har fått siden bygget i Lovable eller andre AI-byggere som leverer en ren SPA.
Symptomet: hver URL på nettsiden returnerer den samme HTML-shellet med tom <div id="root"> til en JavaScript-bunt lastes ned og renderes. Til googlebot kjører JS, ser hver URL identisk ut — og blir flagget som Soft 404.
Hvorfor det skader: Du blir ikke indeksert. Vi har sett kunder med 30 sider i sitemap der bare forsiden er indeksert i Google fordi alle andre sider får Soft 404-verdikt.
Hvordan vi fikser det: Vi bygger en prerender-script som etter Vite-build genererer en statisk HTML-fil per rute med rute-spesifikk title, meta, canonical, schema.org og minimal H1+intro. Vercel serverer den statiske HTML-en før den faller tilbake til SPA-rewrite. Tid: 4-6 timer å sette opp første gang, deretter automatisk.
De ti feilene over er ikke teoretiske. De er det vi finner igjen og igjen, på nettsider bygget av norske og internasjonale byråer like ofte. Hver enkelt feil er relativt enkel å fikse — det er bare det at det krever at noen vet hva de skal lete etter.
I sum: en typisk audit avdekker mellom seks og åtte av disse ti feilene. Total fiks-tid er typisk 20-30 timer fordelt over en uke, og resultatet er at nettsiden går fra «usynlig for AI» til «aktivt sitert i månedlig rapportering».
Hvis du vil teste din egen nettside mot disse ti feilene, har vi laget sjekksynlighet.no som kjører ti tekniske AEO-sjekker på 30 sekunder. Du får en score og en topp-5-liste av hva som mangler — uten registrering eller forpliktelse.
Hvis du vil ha jobben gjort, gir vi gratis estimat. Den tekniske grunnmuren er typisk en engangsleveranse på 6-10 timer for en SMB, og blir vedlikeholdt via våre månedlige SEO/AEO-abonnement.