Skal du bestille nettside? 10 feil bedrifter gjør igjen og igjen

Bare rundt 31 % av teknologiprosjektene blir ferdige i tide, innenfor budsjettet og med et resultat som kunden er fornøyd med. De fleste årsakene oppstår før den første kodelinjen — ti vanlige feil og hvordan du unngår dem.

Et nytt nettsted er en av de investeringene som enten kan sette god fart på veksten i bedriften, eller bli en dyr og frustrerende erfaring som ender med et resultat som ikke svarer til forventningene, sprenger budsjettet og må gjøres om igjen etter noen måneder. Tallene fra bransjen er urovekkende — bare rundt 31 % av teknologiprosjektene blir ferdige i tide, innenfor budsjettet og med et resultat som kunden er fornøyd med, og det å bestille nettside er ikke noe unntak, for webutvikling inngår i den samme statistikken: resten av prosjektene, omtrent to tredeler, klassifiseres enten som truet (sprengt budsjett eller frist, redusert omfang) eller som mislykket. De fleste av disse mislykkede prosjektene skyldes likevel verken svakheter ved teknologien eller inkompetente utviklere — de er følger av menneskelige og organisatoriske forhold som oppstår før den første kodelinjen er skrevet, og de lar seg fullt ut unngå når den som bestiller, vet hvilke feil som gjøres oftest og hvordan man kommer utenom dem.

I denne artikkelen går vi gjennom de ti feilene bedrifter og organisasjoner gjør oftest når de bestiller et nytt nettsted, og for hver av dem forklarer vi hvorfor den oppstår, hva den fører til og hva du kan gjøre for å unngå den.

1. Å velge utelukkende på pris

Dette er trolig den vanligste og dyreste feilen av alle — man sammenligner et par tilbud og velger det billigste, i den tro at et nettsted er et nettsted uansett hvem som bygger det, og at forskjellen mellom et tilbud på 500 euro og et på 5 000 euro bare er utviklerens fortjenestemargin. I virkeligheten gjenspeiler denne forskjellen nesten alltid fundamentale ulikheter i kvaliteten på arbeidet, i hvor ryddig koden er, i sikkerhetsnivået, i mulighetene for å vokse videre og i støtten etter levering, og det billigste tilbudet blir ofte den dyreste løsningen på sikt, fordi kode av dårlig kvalitet bygger opp det som kalles teknisk gjeld — en beholdning av problemer som krever stadige rettelser, begrenser videreutviklingen og til slutt tvinger fram en full ombygging.

Lave tilbud skjuler gjerne betydelig risiko: utvikleren kan bruke gratis eller piratkopierte temaer som inneholder sårbarheter eller skjult skadelig kode; koden kan være uoptimalisert og ustrukturert, slik at videre drift og utvidelser blir tunge og dyre; testingen kan bli så mangelfull at feilene først dukker opp etter lansering; og støtten etter levering kan være minimal eller ikke eksistere i det hele tatt, slik at du står alene akkurat når du trenger hjelp mest. Den riktige framgangsmåten er å vurdere tilbudene på verdi framfor pris — gå gjennom utviklerens portefølje, snakk med tidligere kunder, kontroller den tekniske kvaliteten på nettstedene de har laget, og få klarhet i nøyaktig hva som er med i prisen og hva som ikke er det, for det «billige» tilbudet mangler ofte elementer som er standard i det «dyre»: responsivt design, grunnleggende søkemotoroptimalisering, sikkerhetsoppsett eller opplæring av dem som skal redigere innholdet.

Denne forskjellen er verdt å regne helt ferdig, for det billige tilbudet sprekker ikke i tilbudet, men i fakturaen som kommer halvannet år senere. La oss anta at det billige nettstedet holder akkurat så lenge og deretter må bygges om: for utvikling nummer to betaler du full pris — vår WordPress-utvikling starter fra 2 500 € — og oppå det kommer flytting av innholdet, en ny runde med tekster og bilder, og 301-videresendinger fra de gamle adressene, uten hvilke rangeringen du har bygd opp gjennom et år, forsvinner sammen med den gamle adressestrukturen. Besparelsen var altså ingen rabatt, men en utsatt betaling med renter. Og blir nettstedet hacket underveis gjennom et ferdigkjøpt tema eller en utdatert utvidelse, koster gjenopprettingen etter prislisten vår 90 € i timen uten mva. med et minimum på åtte timer — det alene spiser opp mesteparten av det du opprinnelig sparte. Det betyr ikke at et billig nettsted alltid er feil valg: for tre sider som bare skal vise kontaktopplysninger og åpningstider, er en ferdig mal en fornuftig beslutning, og det sier vi også fra om. Feilen begynner der nettstedet er en salgskanal, men kjøpes som et visittkort.

2. Uklart definerte krav og mål

Den nest vanligste feilen er å sette i gang et prosjekt uten klart definerte krav, mål og forventede resultater — man kontakter en utvikler og sier noe i retning av «jeg trenger et moderne og profesjonelt nettsted», uten å kunne formulere konkret hvilke funksjoner nettstedet trenger, hvem målgruppen er, hva de besøkende skal gjøre der og hvordan resultatet skal måles. Slik uklarhet tvinger utvikleren til å gjøre sine egne antakelser om hva kunden vil ha, og disse antakelsene viser seg ofte å være feil, noe som fører til skuffelse på begge sider og til at ferdig arbeid må gjøres om, med ekstra tid og penger som følge. Uklarheten er også den viktigste drivkraften bak omfangsvekst (scope creep) — et fenomen som rammer mer enn halvparten av prosjektene i bransjen, og som betyr at det underveis stadig kommer til nye funksjoner og krav som ikke lå i den opprinnelige planen, med høyere kostnader og ofte betydelig lengre utviklingstid.

Løsningen er å bruke tid og krefter på en kartleggingsfase (discovery phase) før noen som helst utvikling settes i gang — i denne fasen defineres konkrete forretningsmål (for eksempel å øke antallet henvendelser med 30 %, få avvisningsraten under 40 % eller sikre en gjennomsnittlig økt på over tre minutter), det utarbeides brukerprofiler, brukerreisene kartlegges, strukturen på nettstedet og de funksjonelle kravene fastsettes, og det skrives en detaljert kravspesifikasjon som fungerer som referansedokument gjennom hele prosjektet. Et slikt dokument beskytter begge parter — bestilleren vet hva pengene går til, utvikleren vet hva som forventes, og enhver endring som går ut over det som står der, formaliseres som tilleggsarbeid med eget budsjett og egen frist.

Den samme grensen for et RAG-prosjekt beskrives i vår artikkel om RAG på bedriftens egne dokumenter: En pilot trenger en avgrenset dokumentsamling, én brukergruppe og forhåndsdefinerte akseptansekriterier, ikke bare en demonstrasjonschat.

3. Å overvurdere designet og undervurdere teknikken

Den tredje feilen er særlig utbredt blant bedriftseiere: et overdrevet søkelys på det visuelle designet, mens den tekniske siden blir helt ignorert eller undervurdert — man velger utvikler bare ut fra hvor pene nettstedene i porteføljen ser ut, uten å stille spørsmål om kodekvalitet, hastighet, sikkerhetspraksis, muligheter for å vokse eller søkemotoroptimalisering. Visuelt design og teknisk utvikling er to forskjellige fag, og et vakkert nettsted som bruker ti sekunder på å laste, er sårbart for angrep og ikke lar seg finne i søkemotorene, er langt mindre verdt enn et visuelt enklere nettsted som er raskt, sikkert og godt optimalisert.

Undersøkelser viser konsekvent at 53 % av besøkene fra mobil blir avbrutt hvis nettstedet bruker mer enn tre sekunder på å laste, og at ett sekunds forsinkelse i lastetiden kan gi merkbart færre konverteringer, for som studien fra Akamai og SOASTA viser, senker allerede 100 millisekunders forsinkelse konverteringsraten med opptil 7 % — disse tallene betyr at ytelsen påvirker inntektene dine direkte, og at ingen vakker utforming veier opp for feil i den tekniske gjennomføringen. Den riktige framgangsmåten er å vurdere utvikleren ikke bare på hvordan arbeidene ser ut, men også på hvor godt utvikleren klarer å forklare sin egen tekniske tilnærming — hvilken arkitektur som brukes, hvordan hastigheten sikres, hvordan sikkerhetsspørsmålene håndteres, og hvordan nettstedet skal skaleres når bedriften vokser og kravene endrer seg.

4. Å utsette søkemotoroptimalisering til «etterpå»

Søkemotoroptimalisering blir svært ofte oppfattet som noe man kan legge til etter at nettstedet er ferdig, omtrent som å male veggene når huset står, men i virkeligheten er teknisk SEO en grunnleggende del av arkitekturen, og å bygge den inn etter lansering er betydelig dyrere, mer komplisert og mindre virkningsfullt enn å ta den med i utviklingen fra første stund. URL-struktur, sidehierarki, arkitekturen i de interne lenkene, overskriftsstrukturen, strukturerte data (schema markup), bildeoptimalisering, Core Web Vitals og opplevelsen på mobil — alle disse elementene er mye enklere og billigere å gjøre riktig underveis enn å bygge om i et ferdig nettsted.

Google indekserer med mobilversjonen først (mobile-first indexing), og det betyr at det er mobilversjonen av nettstedet ditt Google vurderer og rangerer innholdet ditt etter — er opplevelsen på mobil dårlig, lider rangeringen uansett hvor god skrivebordsversjonen er. Mobilhandelen nådde ifølge Statista rundt 2,07 billioner dollar i 2024, og tall fra Google viser at mobile søk med kjøpshensikt og formuleringen «i nærheten av meg» (near me) mer enn femdoblet seg mellom 2015 og 2017 — optimalisering for mobil er ikke en hyggelig ekstrafunksjon, men en forretningsmessig nødvendighet, særlig for lokale bedrifter som vil ha kunder i sitt eget område. Den riktige framgangsmåten er å føre kravene til søkemotoroptimalisering opp som en obligatorisk del av utviklingen allerede i forespørselen (RFP), ikke som en separat tjeneste med egen faktura. Konkret betyr det at utvikleren fra første stund må planlegge en søkevennlig URL-struktur, sikre et riktig overskriftshierarki (H1, H2, H3), innføre strukturerte data (schema markup), optimalisere bildene med alt-tekster og moderne formater, sette opp XML-nettstedskart og robots.txt, og sørge for at hastigheten holder Core Web Vitals-nivå — i et ferdig nettsted kan de samme endringene kreve en vesentlig ombygging av arkitekturen.

5. Å hoppe over innholdet eller lage det i siste liten

Den femte feilen er en av de vanligste grunnene til at prosjekter blir forsinket — man tror at innholdet er noe som kan «skrives ned» helt til slutt, og retter all oppmerksomhet mot design og funksjonalitet, mens tekster, bilder og andre innholdselementer blir liggende uferdige helt til prosjektets siste dager. Problemet er at designet bygges rundt innholdet og ikke omvendt — er innholdet ikke klart, må designeren jobbe med blindtekst (lorem ipsum), og resultatet er et design som ikke passer til mengden og strukturen i det virkelige innholdet. Når den ekte teksten endelig legges inn, kan uttrykket endre seg kraftig, og sjelden til det bedre.

Forsinket innhold er en av de hyppigst nevnte årsakene til forsinkelser i bransjen, og det er logisk nok, for godt innhold tar tid — tekster skal skrives, stemmes av mot bedriftens tone og budskap og optimaliseres for søk, og bildene skal velges eller lages slik at de passer både merkevaren og designet. Den riktige framgangsmåten er å behandle innholdsarbeidet som en kritisk prosjektfase med egne frister og egne ansvarlige, en fase som starter parallelt med designarbeidet eller til og med før det, ikke som en tilleggsoppgave man tar «når det blir tid». Har bedriften ikke egne folk til å lage innholdet, må det inn i prosjektbudsjettet som en egen post, med en profesjonell tekstforfatter eller innholdsprodusent på laget.

6. Vedlikehold etter lansering som ingen har planlagt

Den sjette feilen henger direkte sammen med vedlikeholdet, som vi allerede har tatt for oss i artikkelen om gjenoppretting av hackede nettsteder — mange tror at et nettsted er et engangsprodukt som bare «virker» når det først er laget, og tenker ikke på hva som skjer etter lansering, når det trengs sikkerhetsoppdateringer, endringer i innholdet, feilrettinger, optimalisering av ytelsen og tilpasning til nye nettleserversjoner og nye enheter. Den holdningen er farlig, for et nettsted uten vedlikehold er et nettsted uten beskyttelse — etter Sucuris tall kjørte mer enn halvparten av de hackede publiseringsløsningene en utdatert programvareversjon i det øyeblikket de ble infisert, og det mye siterte anslaget fra Sophos, som er over ti år gammelt, snakker om rundt 30 000 nye nettsteder hver dag der det oppdages skadelig kode.

Vedlikeholdet må avklares allerede i planleggingen av prosjektet og ikke etter at nettstedet er lansert, for det påvirker både teknologivalget (noen plattformer er enklere å vedlikeholde enn andre), budsjetteringen (driftskostnadene hører hjemme i budsjettet for hele livsløpet til nettstedet) og valget av utvikler (du må finne ut om utvikleren også tilbyr vedlikehold, og på hvilke vilkår). Ideelt sett tas det inn en støtteavtale i kontrakten (SLA — Service Level Agreement) som definerer hvilket vedlikehold som skal utføres, hvor ofte, hvor rask responsen skal være når noe skjer, og hva tjenesten koster.

7. Å gi utvikleren kontroll over domenet og driften

Den sjuende feilen er en av dem som kan få de alvorligste langtidsfølgene, og likevel gjøres den overraskende ofte — bestilleren lar utvikleren registrere domenenavnet og kjøpe driften i utviklerens navn framfor i bedriftens, og mister dermed kontrollen over kritisk viktige digitale eiendeler. Tar samarbeidet med utvikleren slutt av en eller annen grunn — enten det skjer i vennskapelighet eller etter en konflikt — kan bestilleren havne i en situasjon uten tilgang til sitt eget domene, uten mulighet til å flytte nettstedet til en annen server, eller til og med miste domenenavnet fordi utvikleren lar være å fornye registreringen.

Domenenavnet og driftskontoen er bedriftens digitale eiendeler, og de skal eies og kontrolleres av deg, på samme måte som forretningsadressen eller varemerket ditt — du ville ikke latt regnskapsføreren registrere firmaets forretningsadresse i sitt eget navn, og av samme grunn bør du ikke la en utvikler kontrollere din digitale identitet. Den riktige framgangsmåten er å registrere domenenavnet selv hos en pålitelig registrar, kjøpe driften i din egen bedrifts navn eller leie den av en partner som på forespørsel overleverer oppsettet og dataene og gi utvikleren bare den tekniske tilgangen som trengs for å bygge og sette opp nettstedet, ikke den administrative kontrollen over disse ressursene. Det samme gjelder Google Search Console, Google Analytics og andre konti for analyse og markedsføring — de skal opprettes i bedriftens navn, og utvikleren får tilgang med begrensede rettigheter.

8. Å hoppe over testing og kvalitetssikring

Den åttende feilen består i at mange ikke bryr seg nok om testingen og tar imot nettstedet uten en grundig gjennomgang, i tillit til utviklerens forsikring om at «alt virker» — men i virkeligheten er skikkelig testing en sammensatt og tidkrevende prosess som omfatter langt mer enn å klikke seg gjennom noen sider og trykke på et par knapper. Mangelfull kvalitetssikring er en av de vanligste grunnene til at nettsteder viser feil etter lansering, feil som rammer brukeropplevelsen, konverteringene og til og med sikkerheten, og å rette dem i et ferdig nettsted er alltid dyrere og vanskeligere enn om problemene var funnet og løst underveis i utviklingen.

Testingen bør dekke flere dimensjoner: funksjonell testing kontrollerer at alle funksjonene virker som de skal — skjemaer, søk, navigasjon, brukerregistrering, handlekurv og kasse, filtrering og sortering av innhold; kompatibilitetstesting kontrollerer at nettstedet virker riktig i ulike nettlesere (Chrome, Firefox, Safari, Edge), på ulike operativsystemer og på ulike enheter (datamaskiner, nettbrett og mobiler med forskjellige skjermstørrelser); ytelsestesting måler lastetid, svartider og oppførsel under belastning; sikkerhetstesting avdekker mulige sårbarheter som SQL-injeksjoner, muligheter for XSS-angrep og feil i tilgangskontrollen; og tilgjengelighetstesting kontrollerer at nettstedet lar seg bruke av mennesker med ulike funksjonsnedsettelser, i tråd med WCAG-standardene.

Den riktige framgangsmåten er å ta testfasen inn i kontrakten med klart definerte akseptkriterier — det betyr at det står skrevet nøyaktig hva som skal testes, hvilke resultater som er akseptable, og hva prosedyren er dersom testingen avdekker problemer. Bestilleren bør dessuten gjennomføre akseptansetesting selv eller med hjelp fra en uavhengig fagperson framfor å stole fullt og helt på utviklerens egenvurdering, for en utvikler som tester sitt eget arbeid, er som en student som retter sin egen eksamen.

9. Beslutninger tatt i komité uten én ansvarlig

Den niende feilen er organisatorisk, og den er særlig typisk for større bedrifter og organisasjoner, der flere beslutningstakere er involvert i prosjektet — markedsavdelingen, salgsteamet, ledelsen, IT-avdelingen og av og til juristene — og hver av dem deltar i godkjenningen av design og innhold med like stor stemmerett. En slik «design etter komité» ender nesten alltid i et resultat fullt av kompromisser som ingen er fornøyd med, fordi hver beslutningstaker forsøker å presse sine egne prioriteringer og ønsker inn i nettstedet, og sluttresultatet blir overlesset, usammenhengende og ute av takt med forretningsmålene.

Både undersøkelser og erfaringen i bransjen viser konsekvent at prosjekter med én tydelig utpekt beslutningstaker som har fullmakt til å godkjenne design, innhold og funksjonalitet, blir ferdige raskere, holder budsjettet oftere og gir bedre resultater enn de der en gruppe bestemmer. Det betyr ikke at de andre partenes syn er uviktig — det betyr at det må finnes en tydelig prosess der alle kan si sin mening og gi tilbakemelding, men der den endelige avgjørelsen tas av én person som har fullmakten og ansvaret for resultatet. En RACI-matrise (Responsible, Accountable, Consulted, Informed) er et effektivt verktøy for å strukturere en slik prosess — den definerer klart hvem som utfører arbeidet, hvem som tar den endelige avgjørelsen, hvem som skal rådspørres og hvem som skal informeres om beslutningene.

10. Å overse immaterielle rettigheter og kontrakt

Den tiende feilen ligger på den juridiske siden, som mange bestillere, særlig i mindre bedrifter, gjerne overser eller regner som unødvendig byråkrati — de setter i gang samarbeidet med utvikleren uten en formell kontrakt, uten klart definerte immaterielle rettigheter og uten en taushetserklæring (NDA), og det kan skape alvorlige problemer både underveis i prosjektet og etter at det er levert. Uten klart definerte rettigheter kan bestilleren i praksis ende opp uten å eie kildekoden som er betalt for, og utvikleren kan bruke den samme koden hos andre kunder eller til og med nekte å overlevere den dersom samarbeidet tar slutt før tiden.

Kontrakten bør slå tydelig fast at alle immaterielle verdier som skapes i prosjektet — kildekode, designfiler, grafikk, datastrukturer og dokumentasjon — tilhører bestilleren når hele betalingen er mottatt, og at utvikleren ikke har rett til å bruke dem til andre formål uten bestillerens samtykke. Kontrakten må dessuten inneholde en definisjon av omfanget, fristene, betalingsplanen (helst knyttet til leveranser framfor til tid), garantiperioden, taushetsbestemmelsene og reglene for tvisteløsning. En betalingsstruktur som er knyttet til konkrete, godkjente milepæler framfor til rene tidsperioder, motiverer utvikleren til å holde fristene og sørger for at bestilleren bare betaler for arbeid som faktisk er gjort, ikke for et ubestemt tidsforbruk; for større og mer uvanlige prosjekter passer også en modell med tid og materialer med et ukentlig tak, forutsatt at omfang og tak er avtalt skriftlig.

Taushetserklæringen (NDA) er særlig viktig når utvikleren får innsyn i sensitiv forretningsinformasjon underveis — kundedata, forretningsprosesser, prispolitikk eller andre fortrolige opplysninger som kan skade bedriften din dersom de havner hos en konkurrent. Mange tror at en NDA er et verktøy for store konserner, men i virkeligheten er den like viktig for enhver bedrift som deler sensitiv informasjon med eksterne partnere. En godt strukturert kontrakt med tydelige milepæler og akseptkriterier fungerer dessuten som et prosjektstyringsverktøy — den sikrer at begge parter er enige om hva som gjøres, når det skal være ferdig og hva resultatet skal være i hver fase, og den reduserer risikoen for misforståelser og konflikter underveis betraktelig.

Flere feil når du skal bestille nettside

Selv om vi har beskrevet de ti største feilene, finnes det flere svakheter som går igjen og som fortjener en egen omtale, fordi de kan påvirke resultatet av prosjektet merkbart. En av dem er å lene seg for tungt på utviklerens mening i alle spørsmål, også i forretningsstrategien — utvikleren er ekspert på teknologi, men forstår sjelden bransjen din, målgruppen din og dynamikken i markedet ditt like godt som du gjør selv, og delegerer du alle avgjørelser til utvikleren, risikerer du å få et nettsted som er teknisk godt, men forretningsmessig virkningsløst.

En annen feil som går igjen, er å overse universell utforming — mange er ikke engang klar over at nettstedet deres skal kunne brukes av mennesker med funksjonsnedsettelser, og at likestillings- og diskrimineringsloven § 18 og forskrift om universell utforming av IKT-løsninger allerede krever dette av private og offentlige nettløsninger som er hovedløsninger rettet mot brukere, uten nedre grense for antall ansatte. Å bygge dette inn underveis i utviklingen er betydelig enklere og billigere enn å legge det til i et ferdig nettsted, og det utvider publikummet ditt, siden rundt 16 % av verdens befolkning — 1,3 milliarder mennesker — lever med vesentlige funksjonsnedsettelser.

Den tredje tilleggsfeilen er å la være å sette opp analyse og konverteringssporing — mange nettsteder lanseres uten at Google Analytics, Google Search Console eller andre analyseverktøy er konfigurert, og dermed kan bestilleren verken måle hvor godt nettstedet virker, finne problemene eller ta beslutninger om videre optimalisering på grunnlag av data. Analysen skal inn i prosjektomfanget som et obligatorisk krav og ikke som noe man «gjør senere». Uten data handler du i praksis i blinde — du vet ikke hvor mange besøkende nettstedet får, hvor de kommer fra, hvilke sider de ser på, hvor de faller fra, eller om nettstedet i det hele tatt fyller den forretningsfunksjonen det skal.

Den fjerde tilleggsfeilen som fortjener en omtale, er å hoppe over det juridiske — mange nye nettsteder lanseres uten personvernerklæring, melding om informasjonskapsler, brukervilkår eller andre dokumenter som er påbudt etter personvernforordningen (GDPR) og annet regelverk, og den forsømmelsen kan få alvorlige rettslige følger, blant annet gebyrer på inntil 20 millioner euro eller 4 % av bedriftens samlede globale årsomsetning — det høyeste av de to beløpene gjelder. Å oppfylle regelverket er ikke bare et formkrav — det er også et tillitssignal til de besøkende som viser at du tar vernet av opplysningene deres på alvor, og forbrukere legger stadig oftere merke til hvordan bedrifter behandler personopplysningene deres. Et samtykkebanner må derfor testes teknisk, ikke bare være på plass – les guiden vår til teknisk testing av samtykkebannere.