WordPress-outsourcing for SEO-byråer: slik setter du ut utvikling i en fast avtale

Et SEO-byrå selger revisjoner, innholdsstrategi og lenkebygging. Etter revisjonen står det igjen en liste med oppgaver, og en del av dem krever endringer i temaets kode, i utvidelser eller i serveroppsettet. Uten en WordPress-utvikler i teamet blir listen liggende, og kunden spør hvorfor rapporten fra mars fortsatt ikke har gitt resultater i juli. Denne guiden viser hvordan du setter ut dette arbeidet i en fast månedsavtale: hva du gir utvikleren, hvordan du gir tilgang uten å dele kontoer, hva som må stå i avtalen, og hvordan du sjekker at arbeidet faktisk virker.

Delene om opphavsrett og personvern oppsummerer norsk lov og EØS-retten slik vi leste dem 24. oktober 2026. De er ikke individuell juridisk rådgivning for ditt byrå.

#Kort fortalt

• Byrået beholder diagnosen, prioriteringene og kundeforholdet. Utvikleren har ansvaret for gjennomføringen og for at endringen ikke ødelegger produksjonen.
• Tilgang gis til en person, ikke til et firma: egen bruker i Search Console, egen konto i WordPress, egen SSH-nøkkel. Hver av dem kan trekkes tilbake med ett grep.
• I avtalen skriver du en månedlig timegrense, tid til første respons (adskilt fra løsningstid), hvordan større oppgaver prises, white-label og taushetsplikt.
• Kode skrevet av en ekstern utvikler tilhører utvikleren til rettighetene er overdratt ved avtale.
• En utvikler med tilgang til nettsider med personopplysninger er en underdatabehandler, så du trenger kundens tillatelse og en databehandleravtale.
• Effekten måler du per oppgave: tilstand før, dato for endringen, tilstand etter 28 dager med data fra CrUX eller Search Console.

#Ordliste for byråeieren

#Hvilke oppgaver fra SEO-revisjonen krever en WordPress-utvikler

En teknisk revisjon ender som regel med en liste over funn, ikke en liste over personer. Første steg er å fordele hvem som gjør hva. Fordelingen under følger av hvor endringen ligger: i innholdet og innstillingene i kontrollpanelet, eller i koden og på serveren.

Når du sender en sak til utvikleren, viser kolonnen for byrået hva han venter fra deg: en liste over URL-er, data fra Search Console, et kart over videresendinger. En sak uten disse dataene begynner med spørsmål, og spørsmålene spiser timer av pakken. Hvorfor enkle endringer ender med ukers venting, forklarer vi i artikkelen om hvorfor endringer på WordPress-sider tar uker.

#Slik gir du utvikleren tilgang til Search Console uten å dele kontoen

Search Console har fem tilgangsnivåer. Beskrivelsen kommer fra Googles dokumentasjon om brukere og tillatelser (support.google.com).

Utvikleren trenger nesten aldri eierrollen. Full tilgang er nok: han ser alle data, mens det å legge til brukere og endre innstillinger blir hos eierne.

Når samarbeidet avsluttes, er det lett å glemme tokenene. Ifølge den samme siden hos Google mister en fjernet eier tilgangen, men verifiseringstokenene hans blir verken fjernet eller ugyldiggjort. Ligger tokenet (en HTML-fil, en metatagg, en DNS-post) fortsatt på nettsiden eller i domenet, kan personen verifisere eiendommen på nytt. Derfor bør en ekstern utvikler ikke verifisere eiendommen med sin egen konto. Og har han gjort det en gang, fjerner du både brukeren og tokenet hans når dere skilles. Google varsler om dette i panelet: dukker det opp en melding om at brukeren kan få tilgangen tilbake når du fjerner ham, ligger tokenene hans fortsatt der.

Fjernes alle verifiserte eiere, mister de andre brukerne og de delegerte eierne tilgangen etter en overgangsperiode. Den verifiserte eieren bør derfor være kunden, mens byrået og utvikleren bruker tilgang som kunden har kontroll over.

#Hvilken rolle i WordPress en ekstern utvikler bør få

WordPress har seks standardroller. Dokumentasjonen på wordpress.org beskriver dem slik: Superadministrator styrer et multisite-nettverk, Administrator har tilgang til alle administrasjonsfunksjoner på en enkelt side, Redaktør publiserer og forvalter innlegg, også andres, Forfatter publiserer egne innlegg, Bidragsyter skriver, men publiserer ikke, og Abonnent forvalter bare sin egen profil.

På en enkeltinstallasjon er det bare Administrator som blant annet har disse rettighetene: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users og unfiltered_html. I et multisite-nettverk har bare Superadministrator dem. Det betyr at en utvikler som skal oppdatere eller installere utvidelser, trenger administratorrollen i testmiljøet og som regel også i produksjon. Redaktørrollen holder ikke til teknisk arbeid.

Når utviklerens konto er en administratorkonto, blir rutinene rundt den viktige:

• Egen konto for hver person. En felles “byraa-dev” betyr at du ikke vet hvem som endret hva, og at du ikke kan ta tilgangen fra én person uten å bytte passord for alle.
• Filredigering i panelet slått av. Herdingsdokumentasjonen for WordPress (developer.wordpress.org) sier at define( 'DISALLOW_FILE_EDIT', true ); i wp-config.php tilsvarer å ta edit_themes, edit_plugins og edit_files fra alle brukere. Utvikleren bør uansett publisere kode fra et repository, ikke gjennom redigeringsverktøyet i panelet.
• Testmiljø med merket miljøtype. Funksjonen wp_get_environment_type() returnerer local, development, staging eller production, og når ingenting er satt, antar den production (developer.wordpress.org). Settes kopien til staging, kan kode og utvidelser oppføre seg annerledes, for eksempel la være å sende e-post til butikkens kunder.
• SFTP eller SSH i stedet for FTP. Den samme herdingsdokumentasjonen anbefaler SFTP, fordi passord og data krypteres underveis. I praksis fungerer en egen SSH-nøkkel per person best: å trekke tilbake tilgangen betyr å slette én linje i authorized_keys, uten å bytte passord for andre. Om publisering via SSH og Git skriver vi i guiden om moderne WordPress-deployment med SSH og Git.

Kontoene hos vertsleverandøren, domeneregistraren og CDN-en, og lisensene for betalte utvidelser, bør tilhøre kunden eller byrået. Utvikleren får tilgang til dem som bruker, ikke som eier.

#Slik trekker du tilbake tilgangene når samarbeidet slutter

En liste som gjennomføres den dagen avtalen avsluttes, helst skrevet inn i avtalen som en plikt for begge parter:

1. Search Console: fjern brukeren og alle verifiseringstokenene hans (fil, metatagg, DNS-post).
2. WordPress: slett utviklerens kontoer i produksjon og i testmiljøet, og overfør innleggene hans til en annen bruker.
3. Serveren: fjern SSH-nøklene hans fra authorized_keys, SFTP-kontoer og eventuelle databasekontoer.
4. Repository: fjern tilgangen til organisasjonen, deploy-nøkler og hemmeligheter i CI.
5. Vertsleverandør, CDN, DNS-forvaltning, betalingspanel: fjern brukeren, og der kontoen var felles, bytt passord og API-nøkler.
6. Eksterne verktøy: Google Analytics, Tag Manager, overvåking, passordforvalter.
7. Data: skriftlig bekreftelse på at utvikleren har slettet eller levert tilbake kopier av databaser og filer med personopplysninger (et krav i GDPR art. 28 nr. 3 bokstav g, beskrevet lenger ned).

Kan ikke listen gjennomføres på en time, ble tilgangene gitt for bredt eller på felles kontoer.

#Core Web Vitals: hva utvikleren retter, og hva som er vertsleverandørens sak

Grenseverdiene står på web.dev (vitals). De måles på 75. persentil av sidevisningene, separat for mobil og datamaskin.

INP ble et stabilt måltall i Core Web Vitals i 2024 og erstattet FID. Kunderapporter fra før endringen som snakker om FID, beskriver et måltall Google ikke lenger bruker i dette settet.

Ansvarsfordelingen følger av hva hvert måltall består av. LCP omfatter tiden for tilkobling, videresendinger og serverrespons, og først deretter lasting og visning av elementet. En del av den tiden hører til vertsleverandøren, en del til temaet.

En utvikler som svarer “det er vertsleverandørens feil” på hvert svake resultat, viser ingen måling. En god partner deler en høy TTFB opp i PHP, database og nettverk før han peker ut en skyldig. Trenger kunden en egen diagnose før beslutningen om endringer, er det det en Core Web Vitals-revisjon er til for, og selve forbedringene beskrives på siden om hvordan du gjør en WordPress-side raskere. En teknisk gjennomgang av måltallene finner du i den store guiden til WordPress-ytelse: Core Web Vitals, hurtigbuffer og bilder.

#Hva som bør stå i en fast avtale med en WordPress-utvikler

En fast avtale med en utvikler selger to ting: reservert tid og forutsigbar respons. Avtalen bør beskrive begge så tydelig at ingen trenger å gjette hva som var avtalt etter tre måneder.

#Omfang og timer

Den månedlige timegrensen, hvordan timene føres (for eksempel i kvarter), og hva som er med i pakken og hva som ikke er det. Et eksempel på ordlyd:

Oppdragstaker reserverer 24 arbeidstimer for Oppdragsgiver i hver kalendermåned. Timer som ikke brukes i en måned, overføres ikke til senere måneder.

At timer ikke overføres, ser ut som en fordel bare for utvikleren, men det har en begrunnelse på begge sider. Utvikleren sier nei til andre kunder for å holde av tiden til byrået. Hvis timene samlet seg opp uten ende, kunne byrået etter et halvt år kreve flere titalls timer i en og samme uke, noe ingen klarer å levere. Blir timer stadig stående ubrukt, er pakken for stor.

#Responstid og løsningstid

Dette er to forskjellige forpliktelser. Responstid er bekreftelse, første diagnose og plan. Løsningstiden avhenger av årsaken, og den kjenner ingen før diagnosen. Et eksempel på ordlyd:

Responstid betyr bekreftelse på at henvendelsen er mottatt, sammen med en første diagnose og en plan for videre arbeid. Responstiden regnes i arbeidsdager fra mandag til fredag, i arbeidstiden etter sentraleuropeisk tid. Responstiden er ikke en frist for å rette feilen.

Skriv også hva hver prioritet betyr (for eksempel P1: produksjonen eller bestillingene virker ikke; P2: en publisering er blokkert; P3: utvikling og optimalisering), og hvem som setter prioriteten. Uten en definisjon blir hver eneste henvendelse fra kunden en P1.

#Arbeid utenfor arbeidstid

Gjelder SLA-en på arbeidsdager, skriver du rett ut at kvelder, helger og feil utenfor disse timene krever en egen, skriftlig avtale. Et byrå som lover kunden døgnberedskap, men har en utvikler i kontortiden, selger noe det ikke har.

#Større oppgaver utenfor pakken

Migrering, en ny innholdstype eller ombygging av maler får sjelden plass i den månedlige timegrensen. Avtalen bør si at en oppgave over et visst antall timer får eget skriftlig omfang, estimat og godkjenning før oppstart.

#Oppstartsperiode og oppsigelse

I starten av samarbeidet går en del av tiden til å bli kjent med kundenes nettsider, tilganger og byråets prosess. Derfor gir en lengre første periode mening, og deretter en månedlig avtale med en fastsatt oppsigelsestid.

#White-label, taushetsplikt og vern av kundeforholdet

En taushetserklæring signert før navn på kunder og tilganger deles. En regel om at utvikleren bare kommuniserer med sluttkunden når byrået ønsker det. Et forbud mot å gi sluttkunden et eget tilbud under samarbeidet og i en fastsatt periode etterpå.

#Definisjon av en klar henvendelse

Henvendelsen inneholder forventet resultat, URL-er, miljø, data for å gjenskape problemet og et akseptansekriterium. En henvendelse som mangler dette, går tilbake til byrået med spørsmål, og tiden til det enten trekkes fra pakken eller ikke. Også det må skrives ned.

Velger du en partner for hele nettsiden og ikke en timebasert avtale, kan du ha nytte av artikkelen om hvordan du velger et WordPress-byrå. Løpende drift av en enkelt nettside uten videreutvikling beskrives i tilbudet om vedlikehold av WordPress-nettsider.

#Hvem eier opphavsretten til koden som skrives for byråets kunde

I Norge regulerer åndsverkloven (lov 15. juni 2018 nr. 40) hvem som eier koden. Unntaket for arbeidsgivere er smalt. Etter § 71 går opphavsretten til et datamaskinprogram som en arbeidstaker har laget som ledd i arbeidsforholdet eller etter arbeidsgiverens instruks, over til arbeidsgiveren, også retten til å endre og overdra programmet videre, med mindre noe annet er avtalt. En utvikler som fakturerer fra eget firma, er ikke arbeidstaker hos byrået, så paragrafen dekker ham ikke.

Rettighetene går dermed bare over ved avtale, og disse bestemmelsene avgjør hvor langt avtalen rekker:

Vi fant ikke noe lovbestemt krav om skriftlig form i §§ 67 og 68. Likevel bør overdragelsen stå i en signert avtale, fordi det er avtaleteksten som viser hva som “klart” er overdratt etter § 67, og det er den du må kunne vise fram hvis det oppstår tvil. List opp bruken uttrykkelig: å kopiere koden helt eller delvis, endre og tilpasse den, la andre personer gjøre videre endringer, gjøre den tilgjengelig på nett, og overdra rettighetene videre til byråets kunder. Uten den siste delen kan byrået ha rettighetene, men ikke kunne gi dem fra seg. I et løpende samarbeid er det praktisk å la overdragelsen skje periodevis, for eksempel ved hver månedlige akseptanse.

Et eksempel på ordlyd, som byråets advokat bør gå gjennom:

Når akseptprotokollen for en måned er signert, overdrar Oppdragstaker til Oppdragsgiver opphavsretten til koden som er utviklet i den måneden, herunder retten til å fremstille eksemplarer helt eller delvis, endre, tilpasse og videreutvikle koden selv eller ved andre, gjøre den tilgjengelig for allmennheten, også på nett, og retten til å overdra disse rettighetene videre til Oppdragsgivers kunder.

Avtalen omfatter ikke selve WordPress. Det er utgitt under lisensen GPLv2 eller senere, og WordPress.org anser utvidelser og temaer som avledede verk som arver GPL (wordpress.org). Overdragelsen gjelder koden utvikleren har skrevet for byrået. Den koden bør fra første dag ligge i et repository som tilhører byrået eller kunden. Rettigheter på papiret hjelper lite hvis koden bare finnes på utviklerens bærbare maskin.

#Er en ekstern utvikler en databehandler etter GDPR

Nesten alltid, hvis han har tilgang til databaser med personopplysninger: WooCommerce-bestillinger, kontaktskjemaer, brukerkontoer, nyhetsbrevlister. Oppsettet er som regel slik: byråets kunde er behandlingsansvarlig, byrået er databehandler, og utvikleren som byrået setter til å arbeide med disse dataene, er underdatabehandler.

I Norge gjennomfører personopplysningsloven (lov 15. juni 2018 nr. 38) personvernforordningen gjennom EØS-avtalen, og forordningen gjelder som norsk lov. Art. 28 nr. 2 i GDPR (EUR-Lex) sier: “Databehandleren skal ikke engasjere en annen databehandler uten forhåndsgitt spesifikk eller generell skriftlig tillatelse fra den behandlingsansvarlige.” (egen oversettelse) Ved en generell tillatelse informerer byrået kunden om hver planlagt tilføyelse eller utskifting av underdatabehandlere, og kunden kan protestere. Art. 28 nr. 4 krever at underdatabehandleren gjennom en avtale pålegges de samme personvernforpliktelsene som byrået har overfor kunden. Oppfyller ikke utvikleren dem, har byrået fortsatt det fulle ansvaret overfor kunden.

I praksis betyr det tre dokumenter:

1. I byråets avtale med kunden: en tillatelse (spesifikk eller generell) til å bruke underdatabehandlere, med utviklerens navn eller en ordning for å informere kunden.
2. En databehandleravtale mellom byrået og utvikleren som gjentar pliktene i art. 28 nr. 3: behandling bare etter dokumenterte instrukser, taushetsplikt for personer med tilgang, sikkerhetstiltak etter art. 32, bistand ved forespørsler fra de registrerte, sletting eller tilbakelevering av data når tjenesten avsluttes, og tilgang til informasjon for revisjon.
3. En regel for arbeid med data: testmiljø med anonymiserte eller begrensede data, kopi av produksjonsdatabasen bare når oppgaven krever det, og sletting av kopien når saken er lukket.

Et eksempel på ordlyd for en klausul om data i testmiljøet:

Oppdragstaker flytter ikke kopier av produksjonsdatabasen ut av infrastrukturen Oppdragsgiver har angitt. Krever en oppgave arbeid på en kopi av dataene, sletter Oppdragstaker kopien innen 7 dager etter at saken er lukket, og bekrefter dette i saken.

#Slik måler du effekten av utviklerens arbeid i en fast avtale

En timerapport viser hvor mye tid som er brukt. Den viser ikke om kundens nettside fungerer bedre. Målingen må derfor planlegges for hver oppgave, før utvikleren begynner.

For ytelsesoppgaver er feltdata kilden. CrUX API gir et 28 dagers glidende gjennomsnitt av aggregerte måltall og oppdateres daglig rundt kl. 04:00 UTC (developer.chrome.com). Datasettet tar bare med sider som er offentlig synlige og har nok besøk, så en liten underside har kanskje ikke data på URL-nivå, bare for hele domenet. Core Web Vitals-rapporten i Search Console bruker de samme CrUX-dataene, grupperer like URL-er og gir gruppen statusen til det svakeste måltallet. Når en rettelse er lagt ut, starter knappen for å begynne sporingen et vindu på 28 dager: dukker ikke problemet opp i noen URL i løpet av den tiden, regner Google det som løst (support.google.com).

Av dette følger rytmen: måling før, dato for endringen, måling etter minst 28 dager. En rapport etter en uke viser en blanding av gamle og nye sidevisninger.

For SEO-oppgaver (videresendinger, indeksering, strukturerte data) er målingen rapportene i Search Console: indekseringsstatus for de aktuelle URL-ene, forbedringsrapporten for den aktuelle typen strukturerte data, søkeresultatene for en gruppe sider før og etter endringen.

Et enkelt format for månedsrapporten, som byrået kan gi kunden under egen merkevare:

Tallfeltene fylles med data fra verktøyene, ikke med anslag. Kolonnen for målestatus hindrer at du rapporterer en suksess som ennå ikke er synlig.

#Slik kjenner du igjen en dårlig white-label-partner

Varselsignaler når du velger en utvikler eller et firma som skal jobbe under din merkevare:

• Ubegrensede henvendelser for en fast pris. Noen betaler til slutt for at det ikke finnes noen grense: som regel en kø der saken din venter uten frist.
• Ingen skriftlig responstid. “Vi svarer raskt” er ingen forpliktelse. Spør om responstiden for kritisk prioritet og hvilke timer den gjelder i.
• Løfte om løsningstid for alle feil. Ingen kjenner årsaken før diagnosen. En garanti om løsning på to timer uten forbehold betyr at avtalen ikke er gjennomtenkt.
• Timer som overføres uten ende. Høres gunstig ut, men skaper en tidsgjeld partneren ikke kan betale tilbake på en gang.
• Ikke noe testmiljø. En utvikler som legger endringer rett ut i kundens produksjon, flytter risikoen over på byrået ditt.
• Felles kontoer og ett passord for hele teamet. Du kan ikke finne ut hvem som endret hva, eller ta tilgangen fra én person.
• Search Console verifisert med utviklerens egen konto. Når dere skilles, blir tokenene liggende, og med dem muligheten til å komme tilbake.
• Kode bare på serveren, uten byråets eller kundens repository. Rettigheter på papiret hjelper ikke hvis du ikke har koden.
• Ingen databehandleravtale. Spør ikke partneren om personopplysninger, tenker han ikke på ansvaret byrået har for ham overfor kunden.
• En partner som vil ha kontakt med sluttkunden fra første dag. White-label betyr at det er byrået som bestemmer om og når det skjer.

#Slik fungerer Agency Development Desk

Agency Development Desk er vår faste tjeneste for SEO-, merkevare- og designbyråer som ikke har en egen WordPress- og WooCommerce-utvikler. Reglene er de samme som denne guiden beskriver som trygge:

• tre pakker med månedlig timegrense: Desk Flex (10 t), Desk Core (24 t) og Desk Embedded (48 t), hver med skriftlig tid til første respons etter prioritet;
• SLA-en gjelder CET-arbeidsdager, og arbeid på kveld, i helger og ved nødhjelp krever en egen skriftlig avtale;
• respons betyr bekreftelse, første diagnose og plan, ikke en garanti for løsning innen samme tid;
• ubrukte timer overføres ikke til neste måned, fordi kapasiteten var reservert for byrået;
• første periode varer to måneder, deretter løper pakken månedlig med én måneds oppsigelse;
• større sprinter får eget skriftlig omfang, estimat og godkjenning;
• taushetserklæring før tilgangene deles, white-label-arbeid etter byråets prosess og vern av kundeforholdet skrevet inn i avtalen;
• koden ligger i et repository byrået eller kunden kontrollerer, og kontoer og lisenser er ikke avhengige av oss.

Oppgaver tar vi imot som skriftlige saker med forventet resultat, lenker, miljø og akseptansekriterium, uten obligatoriske møter. Prisene på pakkene står på tjenestesiden. For å vurdere om vi passer for dere, holder det med en e-post med hvilke typer kunder dere har, teknisk stack, et eksempel på backlog fra den siste revisjonen og forventet antall timer per måned.