Kravspesifikasjon for nettside: slik skriver du en som gir bedre tilbud

En kravspesifikasjon for nettside er et kort beslutningsdokument som beskriver mål, målgruppe, funksjoner, innhold, lovkrav, ytelse, migrering og drift – og hvordan hvert krav skal godkjennes. Målet er ikke å beskrive design, men å gjøre tilbud sammenlignbare og fjerne tvist om hva som faktisk er levert.

De fleste norske SMB-er skriver kravspesifikasjonen sin én gang hvert femte til åttende år, og da under tidspress. Resultatet er ofte en ønskeliste: «moderne design», «god SEO», «enkelt å oppdatere». Slike formuleringer kan ikke prises, kan ikke testes, og kan ikke bestrides når prosjektet nærmer seg lansering. En god kravspesifikasjon for en ny nettside gjør det motsatte – den beskriver hva løsningen skal gjøre, hvor godt den skal gjøre det, og hvordan dere sammen avgjør om kravet er innfridd.

Vi i Box leser en del slike dokumenter i tilbudsrunder, og det vi ser oftest er at 80 % av teksten handler om utseende og 20 % om alt som faktisk koster penger: integrasjoner, innholdsmigrering, redigeringsflyt, ytelse, tilgjengelighet og drift etter lansering. Denne artikkelen snur på det forholdet, og går gjennom punktene vi mener må være med før du sender forespørselen til en nettsideleverandør.

Hva en kravspesifikasjon for nettsider egentlig skal løse

Dokumentet har tre jobber. Den første er å gjøre tilbud sammenlignbare: får du tre tilbud på tre ulike forståelser av oppdraget, sammenligner du epler, pærer og en driftsavtale. Den andre er å tvinge fram interne avklaringer – hvem eier innholdet, hvem godkjenner, hva skjer med de 400 gamle sidene. Den tredje er å være referansepunkt ved uenighet: når leverandøren sier «det var ikke med i omfanget», skal dokumentet svare.

Derfor bør du starte med formålet, ikke funksjonene. Skal nettstedet skaffe flere tilbudsforespørsler, redusere antall support-telefoner, eller rekruttere? Et B2B-nettsted som skal levere kvalifiserte henvendelser stiller helt andre krav enn en ren merkevareside. Vi anbefaler at du skriver ned to–tre målbare forretningsmål med dagens utgangspunkt, og at du tar en nullpunktsmåling av dagens nettsted før prosjektet starter. Uten tallene fra i dag kan ingen dokumentere effekten etterpå.

Fem spørsmål som må besvares på side 1

• Hva er formålet, og hvilke to–tre tall skal endre seg?
• Hvem er brukerne, og hvilke tre oppgaver skal de klare raskt?
• Hva er absolutt tidsfrist, og hva utløser den (messe, navnebytte, avtale som utløper)?
• Hva er ramme for budsjett – investering og årlig drift?
• Hvem hos dere bestemmer, og hvor mye tid kan de faktisk bruke?

Ti krav vi mener må være med

Funksjonelle krav: hva nettstedet skal gjøre

Funksjonelle krav beskriver handlinger. Skriv dem som setninger med subjekt og verb: «En redaktør uten teknisk bakgrunn skal kunne opprette en ny fagartikkel med bilde, forfatter og relaterte lenker uten hjelp fra utvikler.» Da vet leverandøren hva som skal bygges, og du vet hva du skal teste. Punktene under dekker det som typisk utløser mest arbeid – og dermed mest pris.

• Sidetyper og maler: hvor mange unike maler trengs (forside, tjeneste, prosjekt, ansatt, artikkel, kontakt)?
• Redigering og publisering: hvem skal kunne endre hva, og trengs det forhåndsvisning, versjonshistorikk eller godkjenningsflyt i CMS systemet?
• Skjema og konvertering: felt, validering, kvitteringsside, varsling og hvor dataene lagres.
• Integrasjoner: CRM, e-postverktøy, booking, rekrutteringssystem, kart, Vipps eller fakturasystem – med navn på system og versjon.
• Søk, filtrering og språk: trengs bokmål/engelsk, og skal begge versjoner vedlikeholdes av dere?
• Innhold: hvor mange sider skal flyttes, hvor mange skrives på nytt, og hvem skriver dem?
• Sporing og måling: hvilke hendelser skal registreres, og hvilken samtykkeløsning brukes?

Punktet om innhold er det som oftest sprekker. Dersom dere skal levere tekst selv, bør kravspesifikasjonen si eksplisitt når innholdet er klart, i hvilket format, og hva som skjer med tidsplanen hvis fristen glipper. I praksis er det innholdet – ikke koden – som avgjør om lanseringen holder datoen, og det gjelder uansett om dere velger temaet wordpress utvikling eller en annen plattform.

Ikke-funksjonelle krav: hvor godt det skal gjøres

Her ligger forskjellen mellom et billig og et godt prosjekt. Ikke-funksjonelle krav handler om hastighet, tilgjengelighet, sikkerhet, oppetid og vedlikehold. De er lette å hoppe over fordi de ikke synes i en designskisse – og like lette å bli skuffet over etterpå. Vårt råd er å gjøre dem målbare med verktøy dere selv kan kjøre: Lighthouse eller PageSpeed Insights for ytelse, og en tilgjengelighetssjekk mot WCAG-nivå AA.

Etter Lighthouse-optimalisering (bildekomprimering, caching, opprydding i skript) forbedres ytelsesscore hos Box sine kunder typisk fra under 55 til over 80.

Det tallparet er et godt utgangspunkt for et akseptansekriterium: «Forside og de tre viktigste tjenestesidene skal ha Lighthouse-ytelsesscore over 80 på mobil ved lansering, målt i en standard testkjøring.» Da har begge parter noe konkret å forholde seg til. Legg i samme bolk inn krav til responsivt webdesign med navngitte skjermbredder dere faktisk tester på, og krav til nettleserstøtte. «Skal fungere på mobil» er ikke et krav – «skal testes og godkjennes på iPhone og Android i portrettmodus, samt nettbrett» er det.

Lovkrav du ikke kan forhandle bort

Universell utforming av nettsteder rettet mot allmennheten er regulert i norsk rett gjennom forskrift om universell utforming av IKT-løsninger, som stiller krav til at nettløsninger følger WCAG på nivå AA. Standarden utvikler seg: WCAG 2.2 fra W3C inneholder 55 suksesskriterier på nivå A og AA, blant annet nye krav til fokusmarkering, klikkflatestørrelse og innlogging uten hukommelsestest. I tillegg gjelder EUs tilgjengelighetsdirektiv i EU fra 28. juni 2025 og treffer blant annet netthandel og en del digitale tjenester.

For deg som skal skrive kravspesifikasjonen betyr dette to ting. For det første må nivået stå eksplisitt – hvilken WCAG-versjon og hvilket nivå leveransen skal måles mot, og hvem som tester. For det andre må ansvaret fordeles: leverandøren svarer for kode, maler og komponenter, mens dere svarer for at bilder får alt-tekst og at PDF-er er lesbare. Vi har samlet det praktiske i egne gjennomganger av kravene til universell utforming og av hvordan tilgjengelighet løses i praksis på nettsider.

Det andre lovområdet er personvern. Sporing og informasjonskapsler krever i utgangspunktet samtykke fra brukeren, og Datatilsynets veiledning om informasjonskapsler beskriver hva som kreves av informasjon og valgmulighet. Kravspesifikasjonen bør derfor si hvilken samtykkeløsning som skal brukes, at skript ikke skal lastes før samtykke er gitt, og at det skal leveres en oppdatert personvernerklæring knyttet til de faktiske verktøyene på nettstedet. Vi fraråder å skyve dette til etter lansering – da blir det liggende.

Migrering, SEO og AI-svar i søk

Skal du bytte ut et eksisterende nettsted, er migreringskravet det mest verdifulle punktet i hele dokumentet. Det vi ser oftest gå galt er at gamle URL-er forsvinner uten videresending, og at synligheten som er bygget opp over flere år ryker på en uke. Google sin dokumentasjon om nettstedsflytting med URL-endringer beskriver framgangsmåten: kartlegg alle adresser, sett opp permanente 301-videresendinger til nærmeste relevante side, oppdater sitemap og følg med i Search Console etterpå.

Ved plattformbytter med korrekt 301-plan beholder Box sine kunder normalt 90–98 % av organisk trafikk gjennom migreringen.

Formuler det som et krav med ansvar og frist: «Leverandøren skal levere en komplett URL-kartlegging med 301-regler for alle indekserte adresser, godkjent av oppdragsgiver minst to uker før lansering.» Ta også med at gamle sider ikke skal slettes før videresendingene er testet. Det samme gjelder om prosjektet er en redesign av eksisterende nettside der strukturen endres, selv om domenet består.

Søk har dessuten endret seg. Google viser AI-genererte oppsummeringer (AI Overview) over de organiske treffene, og stadig flere brukere får svar i chatbaserte tjenester uten å klikke seg videre. Det stiller krav til at innholdet er maskinlesbart: tydelige overskrifter, faktiske svar høyt på siden, og strukturerte data for bedrift, tjenester, artikler og vanlige spørsmål. Box legger inn strukturerte data og en llms.txt som standard på alle nye nettsider, fordi sider med tydelig maskinlesbar struktur er dem vi ser bli plukket opp av AI-søk først. Skriv det inn som et krav – det koster lite i byggefasen og er tungt å ettermontere.

Hva koster det – og hvordan kravene styrer prisen

Prisen på et nettsideprosjekt følger tre variabler: antall unike maler, antall integrasjoner og mengden innhold som skal flyttes eller skrives. Alt annet er justeringer. Derfor gir en kravspesifikasjon med tallfestede maler og navngitte integrasjoner nesten alltid lavere tilbud enn en vag beskrivelse – leverandøren slipper å prise inn usikkerhet. Vi går nærmere inn på hva ulike ambisjonsnivåer koster i gjennomgangen vår av pris på nettside.

Slik strukturerer du budsjettdelen

• Del opp i basisleveranse og opsjoner, slik at du kan kutte omfang uten å kutte kvalitet.
• Be om pris per ekstra sidemal og per ekstra integrasjon – da kan du regne selv underveis.
• Skill engangskostnad fra årlige kostnader: domene, temaet webhotell, lisenser, sikkerhetsoppdateringer og support.
• Sett av en intern post for innhold, foto og tekst – dette er kostnaden som oftest glemmes.
• Be om timepris og responstid for endringer etter lansering, ikke bare byggeprisen.

Den årlige driften er verdt et eget avsnitt i dokumentet. Krev at tilbudet beskriver hvem som oppdaterer kjerne og utvidelser, hvor ofte det sikkerhetskopieres, hvor lenge kopiene lagres, og hvor raskt et nedetidsvarsel besvares. Vi har beskrevet hva en fornuftig avtale for temaet drift av nettside bør inneholde, og for WordPress-prosjekter spesielt hva som ligger i løpende vedlikehold. En nettside uten driftsavtale er en nettside som blir utdatert i løpet av to år.

Når en detaljert kravspesifikasjon ikke er riktig verktøy

Ikke alle prosjekter trenger et formelt dokument. Skal du lage en enkel bedriftsside på fem–seks sider uten integrasjoner, bruker du fort mer tid på å skrive kravene enn leverandøren bruker på å bygge løsningen. Da holder det med en e-post som beskriver formål, sider, frist og budsjett – og heller en grundig samtale. Det samme gjelder om du bygger selv i en temaet nettsidebygger; da er det dine egne valg som styrer, ikke en kontrakt.

Vi fraråder også tunge kravspesifikasjoner i prosjekter der dere ikke vet hva dere trenger ennå. Hvis målet er å teste om en ny tjeneste selger, er en fokusert temaet landingsside med to ukers leveringstid bedre enn et kravdokument som låser en løsning dere kanskje skroter om et halvår. Et tredje tilfelle er rene kampanjeprosjekter med kort levetid – der er tid til markedet viktigere enn presisjon i omfanget.

Terskelen vår er enkel: fra det øyeblikket prosjektet involverer minst én integrasjon mot et annet system, migrering av eksisterende innhold, eller flere enn to personer som skal godkjenne, lønner det seg å skrive ned kravene. Under det nivået er dokumentet mest byråkrati.

Slik bruker du kravspesifikasjonen i tilbudsrunden

Send samme dokument til alle du ber om tilbud fra, og be om svar i samme struktur: pris per punkt, forutsetninger, og hva leverandøren mener mangler. Det siste spørsmålet er det mest nyttige – svarene avslører hvem som har lest dokumentet og hvem som har limt inn en standardmal. Vi mener også at du bør be om to referanser på tilsvarende prosjekt, gjerne med adresse til nettstedene slik at du kan teste ytelse og tilgjengelighet selv.

Vurderingskriterier vi ville brukt

• Forståelse av formålet, ikke antall sider i tilbudet.
• Hvordan leverandøren håndterer migrering, videresending og måling.
• Hvem som faktisk skal jobbe i prosjektet, og deres tilgjengelighet.
• Eierskap: får dere tilgang til kode, domene og innhold uten bindinger?
• Pris for drift og videreutvikling de neste tre årene, ikke bare byggeprisen.

Til slutt: avtal hvordan endringer håndteres. Alle prosjekter endrer seg underveis, og en kort setning om at endringer utenfor omfanget estimeres skriftlig og godkjennes før arbeid starter, sparer begge parter for ubehagelige samtaler i sluttfasen. Skal du sette i gang med utvikling av nytt nettsted, er det den setningen som holder budsjettet på plass.