Nivågradering av kataloger: hva N1 til N5 koster

Det vanligste spørsmålet vi får om datainnhenting — web scraping, som det heter på engelsk — er «hva koster det?».

Svaret avhenger fullstendig av hvordan nettstedet er bygget — og forskjellen mellom det enkleste og det vanskeligste tilfellet er ikke tjue prosent. Den er en tierpotens.

Vi har derfor sluttet å gjette. Vi gjør en nivågradering av katalogen — en skala fra N1 til N5 — og først da sier vi noe om tid og pris. Denne artikkelen er hele skalaen.

---

Kort vei til svaret: vil du bare vite hvilket nivå katalogen deres ligger på, send oss adressen — vi plasserer den og sier hva den koster. Vil du vurdere selv, les videre.

Slik vurderer vi nivået på en katalog

Denne skalaen er destillert fra våre egne oppdrag, ikke hentet fra en standard. Det finnes ingen norm for hvor vanskelig en katalog er å hente, og N1–N5 er ikke et begrep bransjen deler. Det er vår modell, og den er nyttig fordi den er enkel — ikke fordi den er autoritativ.

Noen konkrete forbehold:

• Nivåene er grovkornede med vilje. Et nettsted kan ligge mellom to nivåer, og store kataloger på ulike nivåer i ulike deler
• Tallene fra faktisk kjøring stammer fra ett prosjekt, beskrevet i den forrige artikkelen. Vi har ikke målt tjue nettsteder og regnet snitt
• Skalaen sier noe om teknisk vanskelighetsgrad, ikke om det er lov. Vilkår, databasevern og serverbelastning er en egen vurdering
• Vi anslår fortsatt feil av og til. Da flytter vi nettstedet et nivå

Hvert nivå under tilsvarer noe vi faktisk har møtt, og tegnene er de vi selv bruker før vi priser en jobb.

Et nettsted kan bytte nivå uten forvarsel. Artikkelen gjennomgås derfor på nytt når vi ser at et nettsted har byttet nivå. Sist gjennomgått 14. august 2026.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple.

---

Skalaen på én skjerm — og hva vi ville gjort

Tabellen under er både oppsummeringen av skalaen og anbefalingen vår. Den er ikke en fasit, men hver rad har en grunn — og noen av radene ender i «ikke gjør det».

Hoppet som koster mest ligger mellom N3 og N5, og det er ikke gradvis.

---

N1 — åpen feed

Leverandøren publiserer katalogen som en fil: CSV, XML eller JSON, ofte laget for prissammenlignere eller forhandlere. Ingen jobb utover å lese den — ingen paginering, ingen blokkering, ingen gjetting.

En feed er ganske enkelt hele katalogen samlet i én fil som oppdateres jevnlig. Formatet avgjør hvor mye tolkning som gjenstår: CSV er en tabell med én vare per linje og kolonner adskilt av komma — lettest å lese, dårligst til å beskrive noe som hører sammen, som flere bilder eller varianter. XML merker hvert felt med sitt eget navn og tåler nøstet struktur, og er formatet de fleste prissammenlignere ber om. JSON er det samme prinsippet i en form maskiner leser raskere, og er standarden når dataene kommer fra et API.

Tegn å se etter: en lenke i bunnteksten om «for forhandlere» eller «datafeed». En /feed-, /export– eller /produkter.xml-adresse. Nevner robots.txt en feed-fil, er den ment å leses.

Tid og pris: timer, ikke dager. Det som tar tid er å kartlegge feltene, ikke å hente dem.

En feed som oppdateres nattlig er dessuten det beste utgangspunktet for automatisering: jobben som henter den kan settes på et fast tidspunkt og ellers stå i fred i årevis.

Skal du gjøre bare én ting før du bestiller et oppdrag: spør om det finnes en feed. Mange gir den ut på forespørsel. Da er et N4-prosjekt plutselig et N1-prosjekt.

---

N2 — API med nøkkel

Det finnes et dokumentert API, men du må søke om tilgang: du signerer noe, får en nøkkel, og leser data slik leverandøren har tenkt. Teknisk er dette nesten like enkelt som N1. Forskjellen er kalenderen.

I praksis er det nesten alltid et REST-API du møter: faste adresser du kaller med vanlige HTTP-forespørsler, og som svarer med JSON. Du identifiserer deg med en API-nøkkel — en hemmelig streng som følger med hvert kall og forteller leverandøren hvem som spør. Nøkkelen skal behandles som et passord, ikke som en konfigurasjonsverdi: den hører ikke hjemme i versjonskontroll, og den skal kunne byttes uten at noe annet må bygges om. Det er den samme disiplinen som gjelder for nøklene til en betalingsleverandør i WooCommerce.

To ting følger nesten alltid med et API, og begge påvirker prisen. Paginering betyr at du får noen hundre varer om gangen og må be om neste bunke — enten med et sidetall, eller med markørbasert paginering, der svaret inneholder en markør du sender med i neste kall. Det siste er tryggere når katalogen endrer seg underveis, fordi du verken mister eller dobbelteller varer som flytter på seg. Rate limiting er leverandørens grense for hvor mange kall du får gjøre per minutt. Den avgjør hvor lang tid en full uthenting tar, og den er ikke forhandlingsbar fra din side.

Tegn å se etter: en utviklerside eller et developer.-underdomene. Ruter som svarer 401 eller 403 i stedet for 404 — da finnes ruten, den er bare beskyttet. Den forskjellen er verdt å måle.

Det er verdt å kunne HTTP-statuskodene utenat på dette steget, for de er hele diagnosen: 404 betyr at adressen ikke finnes. 401 betyr at den finnes, men at du ikke har identifisert deg. 403 betyr at du er identifisert, men ikke har lov. 401 og 403 er gode nyheter — de bekrefter at det finnes noe å søke om tilgang til.

Tid og pris: integrasjonen er en kort jobb. Avtalen er flaskehalsen — regn med dager til uker før nøkkelen er i hånden. Samme mønster som når vi kobler på betalingsløsninger for nettbutikk: teknikken tar en dag, avtalen tar lengre tid.

Prisen på et N2-oppdrag bør derfor deles i to: en byggekostnad og en ventetid du ikke kontrollerer.

---

N3 — sitemap pluss server-rendrede sider

Ingen feed og intet API, men to ting stemmer likevel: hver produktside er lesbar i kildekoden, og sitemap.xml gir deg adressene.

Det tekniske navnet på det første er server-side rendering: serveren setter sammen den ferdige HTML-en før den sendes, slik at prisen, tittelen og lagerstatusen står i svaret du får. Motsatsen er sider der serveren sender et nesten tomt skall, og JavaScript i nettleseren bygger innholdet etterpå. Forskjellen er hele grunnen til at N3 er billig og N5 er dyrt.

Det andre — sitemap.xml — er en XML-fil der nettstedet selv lister opp adressene sine, opprinnelig ment for søkemotorer. robots.txt i rota peker som regel på den. Begge filene er laget for å bli lest av maskiner, og de er det første vi henter.

Da er jobben mekanisk: les sitemap, gå gjennom listen, hent hver side. Dette er det vanligste nivået, og der de fleste oppdragene ligger.

Tegn å se etter: /sitemap.xml eller /sitemap_index.xml svarer med XML, og antall <loc>-oppføringer er i samme størrelsesorden som antallet varer nettstedet oppgir. Søker du etter prisen i kildekoden på en produktside, finner du den i selve HTML-en.

Kjører nettstedet WordPress, er det verdt å prøve /wp-json/ før du begynner å lese sider: WordPress har et REST-API innebygd, og på mange WordPress-nettsteder står det åpent uten at noen har tenkt over det. Da faller oppdraget til N2 uten søknad. Dataene du henter ut skal som regel videre inn i en katalog eller en oversikt hos deg selv — det er den jobben vi beskriver under dynamiske nettsider.

Tid og pris: dager. Kjøringen koster nesten ingenting — i vårt prosjekt kostet 1 000 sider ca. 22,80 kroner i 2 002 operasjoner på 5,6 minutter. Det er utviklingen og feltkartleggingen som utgjør regningen, ikke maskintiden.

Et N3-oppdrag lar seg som regel prise fast. Det gjør ikke N5.

---

N4 — delvis server-rendret

Her begynner det å bli ubehagelig. Enkeltproduktsidene er hele og lesbare, som på N3 — men oversiktssidene laster inn resten ved scroll, og sitemap-en er ofte kappet.

Mekanismen bak er som regel lazy-loading: siden sender bare de første tjue-tretti varene, og henter resten etter hvert som du blar. Det er et fornuftig valg for et menneske med en mobil, og et vondt valg for den som skal telle. Er det klassisk paginering i bunnen — side 1, 2, 3 — er du fortsatt på N3, for da kan adressene regnes ut. Er det ingen sidetall, bare mer innhold, er du på N4 eller lavere.

Du kan lese hvert produkt du vet om. Problemet er å få vite om alle.

Dette var nivået i prosjektet vi skrev om sist. Sitemap-en var kappet ved nøyaktig 1 000 adresser, skjevt vektet mot de nyeste varene. Resultatet ble 240 av 1 243 varer — 19 % dekning.

Tegn å se etter: dette er den viktigste testen på hele skalaen. Tell forekomstene av prisfeltet i kildekoden på en oversiktsside, og sammenlign med antallet siden selv påstår. Står det «1 243 varer» øverst mens kildekoden inneholder sytti priser, vet du med én gang hva du har med å gjøre. Tell deretter oppføringene i sitemap-en: et mistenkelig rundt tall — 1 000, 5 000, 50 000 — er en grense, ikke en tilfeldighet.

Tid og pris: dager, som N3, men med en usikkerhet du må prise inn. Du vet ikke før du har kjørt hvor stor andel du får. Derfor selger vi N4-oppdrag med dekningsgraden som leveranse, ikke som løfte.

Det er samme resonnement som ligger bak at vi ikke lover en bestemt ytelsesscore: når tallet avhenger av noe utenfor vår kontroll, er det en måling vi kan levere — ikke en garanti vi kan signere.

---

Vet du ikke hvilket nivå dere står overfor? Det er en kort jobb å finne ut av. Be om en vurdering, så plasserer vi katalogen på skalaen og sier hva neste steg er verdt.

N5 — uendelig scroll uten noe API

Ingen feed, intet API, ingen brukbar sitemap, og oversiktssidene henter alt via JavaScript etter hvert som du blar. Da finnes det bare én vei: kjør en ekte nettleser som blar — en headless nettleser som laster siden på ordentlig og simulerer scrolling til listen er ferdig.

Det virker. Det er bare den dyreste veien, på tre måter samtidig:

• Dyrest å bygge. Scroll, ventetid, lasting som feiler og elementer som flytter seg må alt håndteres
• Dyrest å drifte. En ekte nettleser bruker langt mer maskinkraft per side. Forskjellen mot et N3-oppdrag er ikke prosenter, den er multipler
• Skjørest. Nettstedet endrer en klasse, og jobben knekker. Det er ikke en engangskostnad, det er vedlikehold

En headless nettleser er en vanlig nettleser uten vindu: den laster siden på ordentlig, kjører JavaScript-en, og bygger opp DOM-en — den trestrukturen av elementer nettleseren faktisk viser. Det er DOM-en vi leser fra, ikke HTML-en serveren sendte, fordi de to ikke lenger er det samme. Og jo flere lag med kode nettstedet stabler rundt hvert element, desto tyngre blir det treet å bygge for hver eneste side. Det er den samme kostnaden vi bygger vekk fra på vår egen side ved å sette opp komponenter før sider — bare sett fra motsatt kant.

Tegn å se etter: ingen paginering i bunnen, bare mer innhold når du blar. Nesten ingen produkter i kildekoden. /sitemap.xml gir 404 eller bare kategorisider. Nettverksfanen viser kall mot adresser som er signert eller tidsbegrenset, og rate limiting slår inn tidligere enn du liker.

Tid og pris: uker å bygge, og en løpende driftspost. Et N5-oppdrag skal aldri prises som fastpris uten en vedlikeholdsavtale ved siden av — det er den delen kunder blir overrasket over.

---

Sjekklisten vi bruker før vi priser

I rekkefølge, fordi hvert steg kan avslutte vurderingen.

1. Spør om en feed. Billigste steg som finnes. Får du ja, er du på N1 — og spørsmålet koster én e-post. Vet du ikke hvem du skal spørre, spør oss, vi gjør det ofte
2. Hent /robots.txt. Den peker som regel på sitemap-en, og noen ganger på en eksportfil
3. Hent /sitemap.xml. Finnes den? Er den en indeks? Hvor mange <loc>-oppføringer, og er tallet mistenkelig rundt?
4. Prøv de vanlige API-stiene. /api/, /api/products, /wp-json/, /graphql. Skill 404 fra 401 — det avgjør N2. Får du JSON tilbake, se etter om svaret nevner en markør eller et sidetall; det forteller deg om pagineringen er markørbasert
5. Tell i kildekoden. Antall priser i HTML-en mot antallet siden påstår. Dette skiller N3 fra N4, og det er testen for om siden faktisk bruker server-side rendering
6. Bla med nettverksfanen åpen. Kommer det data inn ved scroll, og fra hvilken adresse? Kommer det JSON, har du kanskje funnet API-et som ikke var dokumentert

Seks steg, ingen kode — og prisen blir et regnestykke, ikke en gjetning. Det er samme framgangsmåte som i prosjektet vi dokumenterte fra ende til annen, bare komprimert til en sjekkliste.

---

Om delvis dekning, ærlig

På N4 og N5 blir dekningen som regel delvis. Det er ikke et unntakstilfelle, det er normalen — og den mest underkommuniserte delen av bransjen.

Delvis dekning er nyttig på én betingelse: at du oppgir nevneren.

240 varer er en påstand. 240 av 1 243 er data. Et prisbilde bygget på 19 % av sortimentet er godt nok til å oppdage bevegelse, men ikke til å hevde noe om hele markedet. Vi skriver derfor alltid dekningsgraden inn i leveransen, også når den ikke kler oss.

Det gjelder like mye når dataene skal videre. Settes uthentingen opp som en jobb som kjører nattlig — det vi kaller automatisering — må nevneren følge med i hver kjøring. Ellers ser en delvis oversikt akkurat like komplett ut som en hel, og det er verre enn ingen oversikt.

---

Hva skalaen egentlig er til for

Poenget er ikke å sortere nettsteder, men å anslå tid og kostnad før du begynner å bygge. Skal du estimere et slikt oppdrag, er nivået den ene opplysningen som virkelig flytter tallet.

Et N3-oppdrag og et N5-oppdrag er ikke samme jobb, og prisen skal ikke være den samme. Behandles de likt, overbetaler kunden for det enkle tilfellet — eller leverandøren taper på det vanskelige og kutter i kvalitet for å ta det igjen. En kartlegging i forkant fjerner begge.

Samme prinsipp ligger under alt vi setter opp av automatisering og dynamiske nettsider: finn ut hva som kreves, før du bygger noe som må vedlikeholdes i årevis.

---

Spørsmål om nivågradering av kataloger

Hvordan vet jeg om et nettsted har et API?

Prøv /api/, /api/products, /wp-json/ og /graphql, og se på svarkoden. 404 betyr at ruten ikke finnes. 401 eller 403 betyr at den finnes, men er beskyttet. Det siste er et godt tegn: da kan du søke om tilgang, og oppdraget faller på N2.

Hva er forskjellen på N3 og N4?

På N3 gir sitemap-en deg alle adressene, og hver produktside er lesbar. På N4 er sidene fortsatt lesbare, men sitemap-en er kappet og oversiktssidene laster inn resten ved scroll. N3 gir nær full dekning. N4 gir delvis dekning.

Hvorfor stopper sitemap.xml på 1 000 adresser?

Fordi noen har satt en grense. I prosjektet vårt var sitemap-en kappet ved nøyaktig 1 000 adresser — et rundt tall er nesten alltid en konfigurasjon, ikke antallet varer.

Hva koster et N5-oppdrag sammenlignet med N3?

Det er ikke en prosentforskjell. N5 krever en ekte nettleser som blar: dyrere å bygge, langt mer maskinkraft per side, og den knekker når nettstedet endrer seg. Regn med uker i stedet for dager, pluss en løpende vedlikeholdspost.

Er delvis dekning verdt noe?

Ja — hvis nevneren følger med. 240 av 1 243 varer er data; 240 varer er en påstand. Et utvalg er nyttig til å oppdage bevegelse, og misvisende hvis mottakeren tror det er alt.

Kan et nettsted bytte nivå?

Ja, uten forvarsel. En sitemap kan utvides, et API kan åpnes eller stenges, en oversiktsside kan legges om til uendelig scroll. En nivåvurdering er ferskvare.

---

Videre lesing om kataloger og uttrekk

• Vi prøvde å hente en hel produktkatalog — prosjektet som ga oss N4 og 19 % dekning
• Betalingsløsning for nettbutikk — teknikken tar en dag, avtalen tar lengre tid
• PayPal, Stripe og kort i WooCommerce — nøkler og hemmeligheter håndtert i praksis
• Hvorfor vi ikke lover deg en score — samme grunn som at vi ikke lover full dekning
• Oxygen 6: komponenter før sider — hvorfor en lett DOM er verdt noe
• Dynamiske nettsider og datakilder — når innholdet skal komme fra et system
• Ett datasett blir til hundrevis av sider — hva dataene skal bli til etterpå
• WordPress-nettsider — der /wp-json/ ofte allerede står åpent
• Automatisering — jobbene som kjører videre etterpå
• Fem feller i Make — det som går galt etter at nivået er satt
• Produktdata ut av en PDF-katalog — samme vurdering, andre kildeformat
• Når AI går i stå og mennesket legger brikken — hvorfor et stoppunkt er verdt mer enn et svar
• Alle artikler i bloggen

Har dere en katalog dere trenger ut av et nettsted? Vi plasserer den på skalaen først, og sier hva den koster etterpå. Ta kontakt for en vurdering.