Sjekkliste for nettside 2026: hva en moderne bedriftsnettside må klare teknisk, fra Core Web Vitals til llms.txt

En moderne bedriftsnettside skal i 2026 klare fire ting samtidig: være synlig i Google, laste raskt på mobilen, oppfylle norske lovkrav til universell utforming og personvern, og i tillegg være lesbar for KI-agenter som ChatGPT, Perplexity og Googles KI-svar. Denne sjekklisten for nettside samler alt på ett sted, med tydelig markering av hva som er krav og hva som er fint å ha.

Utgangspunktet er den åpne webspesifikasjonen som Yoast-grunnleggeren Joost de Valk lanserte på specification.website: et forsøk på å samle «hva en god nettside faktisk må gjøre» på ett sted, med primærkilde på hvert punkt. Vi har tatt den plattformuavhengige listen hans og lagt på tre lag den bevisst mangler: hva som faktisk gjør størst forskjell for en norsk bedrift, hvilke punkter plattformen din allerede løser for deg, og hvordan de norske lovkravene (universell utforming og GDPR) griper inn.

Hva er specification.website, og hvorfor lytter vi til den?

I femten år har rådene om «hva en nettside burde gjøre» vært spredt over et halvt dusin kilder: WHATWG for HTML, WCAG for tilgjengelighet, IETF for HTTP-headere, schema.org for strukturerte data, pluss web.dev og Google Search Central for resten. Det har manglet én enkelt, meningssterk, plattformuavhengig spesifikasjon. Det er hullet Joost de Valk prøver å fylle.

Spesifikasjonen dekker ti områder: grunnlag, SEO, tilgjengelighet, sikkerhet, well-known-URI-er, agent-readiness, ytelse, personvern, robusthet og internasjonalisering. Hvert punkt har en status og en primærkilde. Den er bygget åpent under MIT-lisens, så hvem som helst kan kontrollere sin egen nettside mot den eller bidra med rettelser.

Vårt standpunkt: det er et utmerket utgangspunkt, men en liste er ikke en strategi. Det som avgjør om en nettside presterer, er kombinasjonen: teknisk bunn, forretningsforståelse for hva kjøperen faktisk trenger, og innhold som både mennesker og maskiner kan sitere. Ren teknikk gir ingen siterbare svar; ren tekst strukturerer ikke for maskiner. Denne guiden er derfor spesifikasjonens liste filtrert gjennom den linsen, for det norske markedet.

Required, recommended, optional, avoid: slik fungerer statusene

Hvert punkt i sjekklisten har én av fire statuser. Det viktigste du tar med deg, er at ikke alt er like viktig: det er forskjell på et ødelagt grunnlag og en manglende bonusfunksjon.

• Required (må): grunnleggende ting som må fungere for at siden skal oppføre seg riktig i nettlesere, søkemotorer og hjelpemidler. Mangler de, er det en feil, ikke en optimalisering.
• Recommended (bør): veletablert praksis som nesten alle seriøse nettsider bør ha. Hit hører det meste av den klassiske SEO-en.
• Optional (kan): tilfører verdi i noen tilfeller, men er ikke nødvendig for alle. Prioriter etter din situasjon.
• Avoid (unngå): mønstre som aktivt skader og bør fjernes. Soft 404-er, tilgjengelighetsoverlegg (overlays) og automatiske geo-omdirigeringer er de tre vanligste fellene; mer om dem lenger ned.

Bruk den interaktive sjekklisten nedenfor til å krysse av for din egen nettside. Den lagrer avkrysningene lokalt i nettleseren, så du kan komme tilbake og fortsette der du slapp.

Sjekkliste for nettside 2026: kryss av med en gang

Her er hele sjekklisten i kortform. Hvert punkt utdypes i avsnittene under, men dette er verktøyet: gå gjennom det, kryss av det du allerede har og noter hullene.

Sjekkliste for nettside 2026

Kryss av det nettsiden din allerede klarer. Avkrysningene lagres i denne nettleseren.

Fullført0 %0 av 39 punkter

• Må
• Anbefales
• Kan
• Unngå

Nullstill

Grunnlaget – HTML, metadata og indeksering0/7

Doctype, korrekt lang-attributt og meta charsetMåViewport-tagg for mobilMåUnik title og metabeskrivelse per sideMåCanonical-tagg som peker ut originalenAnbefalesRobots.txt og meta robots riktig sattMåXML-sitemap sendt inn til GoogleAnbefalesOpen Graph-tagger og faviconAnbefales

Teknisk SEO og strukturerte data0/5

Én h1 per side og logisk overskriftshierarkiAnbefalesRen, lesbar URL-strukturAnbefalesGjennomtenkt internlenking med beskrivende ankertekstAnbefales301-omdirigeringer for permanente flyttingerMå

Ingen soft 404-erUnngå

Strukturerte data (JSON-LD) for bedrift, produkt eller artikkelAnbefales

Ytelse og Core Web Vitals0/6

LCP under 2,5 sekunder på mobilAnbefalesINP under 200 millisekunderAnbefalesCLS under 0,1AnbefalesBildeoptimalisering: WebP/AVIF og lazy loadingAnbefalesCaching og komprimering aktivertAnbefalesFontlasting uten tekstblink eller layouthoppAnbefales

Sikkerhet0/5

HTTPS med gyldig sertifikat på all trafikkMåHSTS-header aktivertAnbefalesContent Security Policy konfigurertAnbefalessecurity.txt på /.well-known/KanPermissions-Policy og sikre cookie-attributterAnbefales

Universell utforming (WCAG)0/4

Tilstrekkelig fargekontrast på tekstMåBeskrivende alt-tekst på bilderMåFull tastaturnavigering og synlig fokusMåSemantisk HTML og skjemaetiketterMå

Ingen tilgjengelighetsoverlegg (overlays)Unngå

Personvern (GDPR)0/4

Tydelig og lett tilgjengelig personvernerklæringMåCookiesamtykke innhentes før sporingMåKartlagte og kontrollerte tredjepartsskriptAnbefalesDataminimering – samle bare det dere brukerAnbefales

Agent-readiness (AI)0/6

Strukturerte data, så agenter kan hente ut faktaAnbefalesStabile URL-er som ikke byttes unødvendigAnbefalesEksplisitt robots-policy for KI-crawlereAnbefalesllms.txt med kart over det viktigste innholdetKanMarkdown-versjon av sidene tilgjengeligKanMCP-server / WebMCP der det tilfører verdiKan

Internasjonalisering (hvis flerspråklig)0/2

hreflang som kobler riktig språkversjon til riktig målgruppeAnbefalesLokalisert title og metabeskrivelseAnbefales

Ingen automatiske geo-omdirigeringerUnngå

42 punkter totalt.

Vil du at vi kjører hele sjekklisten mot nettsiden deres? Ta kontakt

Grunnlaget: HTML, metadata og indeksering

Dette er fundamentet. Får du ikke grunnlaget riktig, spiller ingen annen optimalisering noen rolle, fordi søkemotorer og KI-agenter ikke engang tolker siden riktig.

• Doctype, språk og tegnkoding (må): hver side trenger <!DOCTYPE html>, et korrekt lang-attributt på <html> (for eksempel nb) og <meta charset="utf-8">. Feil språk her gjør at skjermlesere uttaler norsk tekst på engelsk, og at Google kan misforstå målgruppen.
• Viewport for mobil (må): uten <meta name="viewport"> blir siden uleselig på mobil. Det er grunnlaget for all responsiv design.
• Title og metabeskrivelse (må/bør): en unik, beskrivende title-tagg per side og en metabeskrivelse som frister til klikk. De rangerer ikke i seg selv, men de styrer hva folk faktisk ser i søkeresultatet.
• Canonical-tagg (bør): fortell hvilken URL som er originalen, slik at det samme innholdet på flere adresser ikke konkurrerer med seg selv. Avgjørende på nettsider med filtre, kampanjeparametere eller flere språk.
• Robots.txt og meta robots (må): styrer hva som kan crawles og indekseres. En feilplassert noindex kan slette hele synligheten din over natten; det er en av de vanligste årsakene til at en nettside plutselig ikke vises lenger.
• XML-sitemap (bør): et sitemap hjelper søkemotorer med å finne alle viktige sider, særlig på større nettsider med dyp informasjonsarkitektur.
• Open Graph og favicons (bør): styrer hvordan lenken ser ut når noen deler den i sosiale medier og i fanen i nettleseren. Små detaljer som påvirker tilliten.

Hvis nettsiden din allerede har problemer med indeksering eller synlighet, er det her du begynner feilsøkingen. Vi har en egen gjennomgang av de vanligste årsakene i Synlighet på nett: 10 grunner til at nettsiden ikke rangerer; denne sjekklisten er den forebyggende motsvarigheten.

Teknisk SEO og strukturerte data

Når grunnlaget sitter, handler teknisk SEO om å gjøre innholdet lett å forstå og rangere. Det er her de fleste bedrifter har mest å vinne, fordi konkurransen om godt strukturerte sider fortsatt er lav.

• Overskriftshierarki (bør): én <h1> per side, fulgt av logiske <h2> og <h3>. Det hjelper både søkemotorer og KI med å forstå sidens struktur og plukke ut svar.
• Ren URL-struktur (bør): korte, lesbare adresser uten unødvendige parametere. En god URL-struktur signaliserer hierarki og er lettere å lenke til.
• Gjennomtenkt internlenking (bør): lenk mellom relaterte sider med beskrivende ankertekst. Det sprer autoritet og viser hvilke sider som hører sammen.
• Korrekte omdirigeringer (må): bruk 301 for permanente flyttinger. Og unngå soft 404-er: sider som sier «ikke funnet» i teksten, men svarer med statuskode 200. De forvirrer søkemotorer og sløser med crawlbudsjettet. I spesifikasjonen er de uttrykkelig merket som noe å unngå.
• Strukturerte data / schema markup (bør): JSON-LD som beskriver hva siden handler om (bedrift, produkt, artikkel, FAQ). Dette blir bare viktigere i KI-æraen, fordi det lar agenter hente ut fakta uten å gjette. Det er en enkel gevinst, fordi få konkurrenter gjør det ordentlig.

Ytelse og Core Web Vitals

En rask nettside er ikke en luksus; det er et rangeringskriterium og en konverteringsfaktor. Google måler den reelle lasteopplevelsen med Core Web Vitals, og terskelverdiene er konkrete.

Ifølge web.dev er målene: LCP (lastetiden for det største innholdselementet) under 2,5 sekunder, INP (responstid på interaksjon) under 200 millisekunder, og CLS (uventede layoutforskyvninger) under 0,1. Klarer du alle tre på mobil, er ytelsesgrunnlaget godt.

• Bildeoptimalisering (bør): moderne formater (WebP/AVIF), riktige dimensjoner og loading="lazy" på bilder under skjermkanten. Bilder er den vanligste årsaken til trege sider.
• Caching og komprimering (bør): sett fornuftige cache-headere og komprimer svarene. Det gjør gjenbesøk nærmest umiddelbare.
• Gjennomtenkt fontlasting (bør): last skrifttyper slik at teksten vises med en gang i stedet for å blinke eller hoppe. En klassisk kilde til dårlig CLS.
• Mobiltilpasning (må): de fleste besøkene skjer på mobil, og Google indekserer mobilversjonen først. En nettside som bare fungerer på desktop, er i praksis halv.

Sikkerhet: HTTPS, headere og security.txt

Sikkerhet er delvis et spørsmål om tillit og rangering, delvis ren hygiene. Mye av dette er usynlig for den besøkende, men tydelig for nettlesere, søkemotorer og sikkerhetsforskere.

• HTTPS med gyldig sertifikat (må): all trafikk skal gå kryptert. Nettlesere flagger nå usikre sider, og HTTPS er et bekreftet rangeringssignal.
• HSTS (bør): en header som tvinger nettleseren til alltid å bruke HTTPS, selv om noen skriver inn http-adressen.
• Content Security Policy (bør): begrenser hvilke skript som kan kjøres, og beskytter mot en stor klasse angrep. Krever litt finjustering, men er verdt det.
• security.txt (kan): en liten fil på /.well-known/security.txt som forteller hvordan sikkerhetsforskere skal rapportere sårbarheter. Standardisert i RFC 9116, nesten gratis å legge til og et tegn på modenhet. Få nettsider har den, så det er en enkel måte å skille seg ut på.
• Permissions-Policy og cookie-attributter (bør): begrens hvilke nettleser-API-er siden kan bruke, og sett Secure/HttpOnly/SameSite på cookies.

Universell utforming og norske lovkrav (WCAG)

I Norge er universell utforming av IKT et lovkrav for både offentlige og private virksomheter. Likestillings- og diskrimineringsloven § 18 og forskrift om universell utforming av IKT-løsninger krever at nettsider rettet mot allmennheten skal kunne brukes av alle, med WCAG som målestokk. For private virksomheter gjelder WCAG 2.0 nivå A og AA, ifølge Uu-tilsynet, som fører tilsyn med kravene. EUs tilgjengelighetsdirektiv (European Accessibility Act) gjelder i EU fra 28. juni 2025, men i Norge er gjennomføringen forsinket.

• Tilstrekkelig fargekontrast (må): tekst må ha tilstrekkelig kontrast mot bakgrunnen for å være lesbar. En av de vanligste og enkleste manglene å rette.
• Alt-tekst på bilder (må): beskrivende alternativ tekst, slik at skjermlesere kan formidle hva bildet viser.
• Tastaturnavigering og synlig fokus (må): alt skal kunne brukes uten mus, og det skal vises hvor fokuset er.
• Semantisk HTML og skjemaetiketter (må): bruk ekte knapper, lenker og <label> i stedet for klikkbare div-er. Det er grunnlaget for at hjelpemidler skal fungere.
• Unngå tilgjengelighetsoverlegg (unngå): de små widgetene som lover å «gjøre nettsiden tilgjengelig» med én kodelinje. Spesifikasjonen merker dem uttrykkelig som noe å unngå, og vi er enige: de løser sjelden de reelle problemene og kan gjøre opplevelsen dårligere for dem som bruker ekte hjelpemidler. Bygg universell utforming inn i nettsiden i stedet.

Dette avsnittet er en oppsummering; lovkravene og hva de betyr i praksis, går vi grundig gjennom i Universell utforming av nettsider: krav og sjekkliste.

Personvern og cookiesamtykke (GDPR)

Personvern er det andre laget med lovkrav. GDPR har gjeldt lenge, men etterlevelsen er fortsatt ujevn på mange nettsider, særlig rundt cookiesamtykke og tredjepartsskript.

• Personvernerklæring (må): en tydelig, lett tilgjengelig erklæring som beskriver hvilke data dere samler inn og hvorfor.
• Korrekt cookiesamtykke (må): samtykke skal innhentes før ikke-nødvendige cookies og sporing aktiveres, ikke etter. Mange nettsider har et banner som teknisk sett kommer for sent. I Norge stiller ekomloven § 3-15 kravet, og siden 1. januar 2025 skal samtykket oppfylle kravene i GDPR. Dette er et område der slurv faktisk kan koste i form av overtredelsesgebyr.
• Kontroll på tredjepartsskript (bør): hver ekstern tagg (analyse, annonser, chatwidgeter) lekker potensielt data og gjør siden tregere. Kartlegg hva som faktisk trengs.
• Dataminimering (bør): samle bare inn det dere faktisk bruker. Mindre data er mindre risiko.

Agent-readiness: er nettsiden din klar for KI-agenter?

Dette er avsnittet som skiller 2026-sjekklisten fra 2023-sjekklisten. KI-agenter leser den samme HTML-en som nettlesere, men de leser den annerledes: de henter ofte siden uten å kjøre JavaScript, plukker ut hovedinnholdet og ignorerer resten. Sidene som vinner i KI-svar, er de som er lette å hente, lette å tolke og lette å stole på.

Som MCP-byrå for nettsider er dette hjemmebanen vår. Flere av punktene er fortsatt standarder under utvikling, men retningen er tydelig, og det koster lite å være tidlig ute.

• Ren, semantisk HTML og strukturerte data (bør): den samme JSON-LD-en som hjelper Google, hjelper agenter med å hente ut fakta uten å gjette. Dette er det aller viktigste tiltaket for agent-readiness, og det overlapper med vanlig SEO.
• Stabile URL-er (bør): når en agent mellomlagrer et svar, må lenken fortsatt fungere senere. Ikke bytt adresser unødvendig.
• Eksplisitt robots-policy for KI-crawlere (bør): bestem aktivt hvilke KI-roboter som får lese nettsiden din, i stedet for å la det være udefinert.
• llms.txt (kan, under utvikling): en enkel /llms.txt-fil som gir KI-modeller et kuratert kart over det viktigste innholdet ditt, omtrent som et sitemap, men for språkmodeller. Ung standard, men billig å legge til.
• Markdown-versjoner av sidene (kan): å kunne servere et rent markdown-speil av en side gjør den maksimalt lett for agenter å tolke.
• MCP-server og WebMCP (kan, under utvikling): for nettsider som vil eksponere verktøy eller handlinger (bestille, søke, hente data) direkte til KI-agenter. Dette er grenselandet der nettet er på vei, og noe vi bygger sammen med søsterselskapet vårt AI Partner.

Merk at agent-readiness ikke erstatter AEO-strategien; det er det tekniske grunnlaget for den. Hvordan du faktisk blir synlig og sitert i ChatGPT, Perplexity og Googles KI-svar, går vi gjennom i AI SEO 2026.

Internasjonalisering: hvis nettsiden din finnes på flere språk

Dette avsnittet er bare relevant hvis dere har innhold på mer enn ett språk, men da er det desto viktigere, fordi feil oppsatt internasjonalisering kan gjøre at feil språkversjon rangerer i feil land.

• hreflang (bør): fortell Google hvilken språkversjon som hører til hvilken målgruppe, slik at norsktalende får den norske siden og engelsktalende den engelske.
• Lokaliserte metadata (bør): oversett title og metabeskrivelse, ikke bare brødteksten.
• Unngå automatiske geo-omdirigeringer (unngå): ikke tving en besøkende inn i en bestemt språkversjon basert på IP-adresse. Det fanger både brukere og søkemotorer i feil versjon. Tilby et tydelig språkvalg i stedet.

Hvilken plattform tar seg av hva for deg?

Her er poenget spesifikasjonen bevisst hopper over: hvor mye av sjekklisten du faktisk må gjøre selv, avhenger helt av plattformen din. Noen løser grunnlaget for deg, andre gir deg full kontroll, men krever at du gjør jobben. Tabellen nedenfor viser hvor mye innebygd støtte plattformene vi jobber mest med gir; jo flere stjerner, desto mer tas hånd om for deg.

Kort tolkning: Webflow gir et sterkt grunnlag med ren kode, rask hosting og innebygd lokalisering, ideelt for en markedsføringsnettside der du vil eie innholdet uten utviklere. En kodet nettside med headless CMS (Next.js eller Astro) gir maksimal kontroll over ytelse, sikkerhetsheadere og agent-readiness, men forutsetter utviklingskapasitet. Shopify er selvsagt for netthandel og har godt produktskjema innebygd. WordPress kan alt via plugins, men hver plugin er en bit teknisk gjeld og en potensiell sikkerhets- og ytelsesrisiko. Vil du sammenligne plattformene i en kjøpsbeslutning, har vi en fordypning i Hva koster en profesjonell nettside i 2026?.

Hva vi ville prioritert først

En komplett sjekkliste kan føles overveldende. Men ikke alt haster like mye. Hvis vi skulle satt prioriteringsrekkefølgen for en typisk norsk vekstbedrift, ville den sett slik ut.

• Først: grunnlaget og lovkravene. Indeksering, mobiltilpasning, HTTPS, universell utforming og cookiesamtykke. Dette er enten tekniske feil eller juridisk risiko; det skal bare sitte.
• Deretter: teknisk SEO og ytelse. Strukturerte data, rent overskriftshierarki og Core Web Vitals. Det er her synligheten bygges, og konkurransen er lav på en godt strukturert nettside.
• Parallelt: agent-readiness. De strukturerte dataene gjør dobbel nytte, og punktene som fortsatt er under utvikling (llms.txt, MCP), er billige å legge til tidlig.

Og det er her grunnholdningen vår kommer inn: en sjekkliste forteller hva som skal finnes, men ikke hva som er verdt mest for akkurat din virksomhet. Det avgjøres av kombinasjonen: strategi, tekst som folk og KI vil sitere, forretningsforståelse og teknisk bunn under. Vil du at vi kjører sjekklisten mot nettsiden din og peker ut de tre tingene som gir størst effekt? Ta kontakt.