Jeg heter Mariusz Szatkowski og har jobbet med WordPress siden 2006. Når en WordPress-nettside har vokst fast i et gammelt tema, en sidebygger eller en PHP-versjon som ikke lenger får oppdateringer, bygger jeg den om. Designet leverer du, jeg gjør resten av den tekniske jobben: tema, innholdsflytting, viderekoblinger, ytelse og tilgjengelighet i koden.
Hvem jeg er
WPPoland er navnet på arbeidet mitt som selvstendig WordPress-utvikler i Gdynia i Polen. Jeg jobber alene, uten team og uten underleverandører, så koden du får er skrevet av meg, og tilgangene dine går ikke videre til noen andre.
Hva jeg gjør
Jeg bygger designet ditt som et responsivt WordPress-tema, flytter sider, innlegg, produkter og medier, lager et kart over gamle og nye URL-er med 301-viderekoblinger, og retter ytelse og universell utforming i koden. Grafisk design, wireframes, tekster og merkevare leverer du eller designeren din.
Hvor jeg jobber
På avstand fra Gdynia, i samme tidssone som Norge. Vi kommuniserer på e-post, i skriftlige dokumenter og i Git-repositoriet, slik at alle beslutninger kan leses igjen senere.
Pris
Ombygginger prises individuelt etter omfang. Du sender en brief og får et skriftlig tilbud med forutsetninger. Vedlikeholdsprisene står på prissiden.
Når lønner det seg å bygge om nettsiden?
En ombygging må flytte noe du kan måle: lastetid hos ekte besøkende, hvor lett redaksjonen publiserer, om nettstedet tåler neste PHP-oppgradering, eller hvor mange som fullfører et skjema eller en bestilling. “Det ser gammeldags ut” alene er en svak grunn, fordi en ny utgave uten plan for URL-ene kan koste deg søkesynlighet du har brukt år på å bygge.
To grunner holder nesten alltid. Den første er at virksomheten har endret seg, med nye tjenester, ny målgruppe eller ny merkevare, og den gamle strukturen bærer det ikke. Da kommer det nye designet fra deg eller byrået ditt, og jeg bygger det. Den andre er at det tekniske grunnlaget har råtnet: WordPress-kjernen er flere hovedversjoner bak, PHP står på 7.x, hver side er et tre av shortcodes fra Elementor eller Divi, og temaet har ingen barnetema. Da betaler du for teknisk gjeld hver gang noe skal endres.
Redesign, modernisering eller ny nettside?
Tre ulike prosjekter havner ofte under samme ord. Valget styrer omfang og risiko, så det lønner seg å finne det faktiske problemet først.
| Redesign | Teknisk modernisering | Helt ny nettside | |
|---|---|---|---|
| Når | Utseendet passer ikke lenger merkevaren, men nettstedet fungerer | Treghet, utdatert PHP, forlatte utvidelser, sidebygger som låser innholdet | Ny forretningsmodell, nye tjenester eller ny merkevare |
| Design | Kommer fra deg eller designeren din | Beholdes, eller kommer fra deg | Kommer fra deg eller designeren din |
| Hva jeg gjør | Bygger det nye designet som tema | Bytter tema, PHP, utvidelser, hosting og arbeidsflyt | Bygger nytt tema og ny struktur |
| Innhold | Blir som det er | Blir, ryddes og flyttes | Skrives på nytt av deg |
| URL-er | Uendret | Uendret, eller 301-kart | Ny struktur med fullt 301-kart |
| Risiko for søkesynlighet | Lav | Middels, styrt | Høyest, krever migreringsplan |
I praksis blander de fleste prosjektene redesign og modernisering. Et nytt utseende på gammel infrastruktur løser ikke treghet, og et nytt teknisk grunnlag uten nytt oppsett endrer sjelden hvordan besøkende bruker siden. Peker diagnosen mot en helt ny nettside, se utvikling av WordPress-nettsider og butikker.
Tegn på at lapping ikke lenger holder
- PHP kan ikke oppgraderes. Temaet eller en utvidelse feiler på PHP 8, og webhotellet har varslet om slutt på den gamle versjonen.
- Sidebyggeren eier innholdet. Hver side er lagret som shortcodes; utløper lisensen eller knekker utvidelsen, vises klammeparenteser i stedet for tekst.
- Ytelsen er dårlig hos ekte besøkende. Feltdata i Search Console viser LCP over 2,5 sekunder eller INP over 200 millisekunder, og ingen hurtigbufferutvidelse flytter tallene.
- For mange utvidelser. Flere titalls aktive utvidelser, noen uten oppdateringer på flere år, og hver kjerneoppdatering blir en risikovurdering.
- Tilgjengelighetsfeil sitter i temaet. Tastaturnavigasjon, fokusmarkering, skjemaetiketter og kontrast er feil i malene, ikke i enkeltsider.
Grenseverdiene for LCP, INP og CLS er Googles egne, beskrevet på web.dev.
Slik jobber jeg
- Gjennomgang av dagens nettsted. Maler, innholdstyper, utvidelser, integrasjoner, URL-er og feltdata for ytelse. Funnene får du skriftlig.
- Designet fra deg. En Figma-fil, eller regnearkmalen min der du markerer hvilke elementer som skal stå på hver visning. Uten design starter jeg ikke byggingen.
- URL-kart. Alle gamle adresser i et regneark med ny adresse ved siden av, laget før første linje kode.
- Tema og blokker. Blokktema med theme.json og mønstre for innholdstypene dine, i Git, med testmiljø du kan se.
- Innholdsflytting. Med skript, ikke for hånd: sider, innlegg, egendefinerte felt, produkter, medier og alt-tekster, kontrollert rad for rad etterpå.
- Testing. Tastatur og skjermleser, automatisk sjekk med axe-core, ytelse, skjemaer og integrasjoner.
- Lansering. Viderekoblingene går live samtidig med nettstedet, nytt nettstedskart sendes til Search Console, og jeg følger med på 404-feil etterpå.
Til redaksjonen skriver jeg en kort brukerveiledning for de vanligste oppgavene.
Alt på én gang eller gradvis?
Å bytte hele nettstedet på én dag er enklest å planlegge, og det er der de fleste ombygginger går over tid og budsjett: innholdsflyttingen tar lenger tid enn ventet, og alt henger på ett testmiljø. Har du tid, er gradvis modernisering som regel tryggere. Først topptekst og navigasjon, deretter tjeneste- eller produktsider, så bloggen, og kassen til slutt fordi inntektene ligger der. Hver del går live og får ekte trafikk før neste starter.
Alt på én gang er riktig i to tilfeller: ved en ny merkevare, der hver side må endres samtidig, og når koden er så sammenvevd at hver endring berører alt. Da er det ofte billigere å bygge nytt enn å refaktorere.
Hva kan gå galt under en ombygging?
Viderekoblingskartet. Et nettsted med tusen URL-er trenger tusen rader som kobler gammel adresse til ny. Hver rad som mangler blir en 404. Norske adresser med æ, ø og å kan ligge lagret både prosentkodet og omskrevet til ASCII, så kartet må dekke begge formene.
Interne lenker. Gamle innlegg lenker fortsatt til gamle adresser. Viderekoblingen fanger trafikken, men lenkene bør skrives om direkte i databasen, slik at ingen side går via en viderekobling.
Integrasjoner. Et CRM som venter et bestemt feltnavn, et analyseskript bundet til en gammel skjema-ID, hendelser som lytter på klasser som ikke finnes lenger. Jeg lister hver integrasjon før byggingen og tester den i testmiljøet.
Data som forsvinner i flyttingen. Egendefinerte felt som ikke mappes, innholdstyper som ikke var med i eksporten, bilder som mister alt-teksten. Derfor sammenligner jeg innholdet før og etter, ikke bare med stikkprøver.
Søkesynlighet på norsk. Titler, metabeskrivelser og overskrifter som har rangert på norske søkeord i årevis, skal flyttes med, ikke skrives om i farten. Har nettstedet flere språk, settes hreflang opp i testmiljøet og kontrolleres før lansering.
Universell utforming: hva norsk lov krever
Likestillings- og diskrimineringsloven § 18 gir både offentlige og private virksomheter plikt til universell utforming av IKT-løsninger som er rettet mot eller stilt til rådighet for brukere. Detaljkravene står i forskrift om universell utforming av IKT-løsninger: private virksomheters nettløsninger skal etter § 4 minst følge WCAG 2.0 på nivå A og AA, med unntak for suksesskriteriene 1.2.3, 1.2.4 og 1.2.5. For offentlige virksomheter viser § 4b til EN 301 549 V3.2.1. Digitaliseringsdirektoratet fører tilsyn etter lovens § 36.
Selger du til forbrukere i EU-land, gjelder i tillegg de nasjonale reglene som gjennomfører tilgjengelighetsdirektivet (EU) 2019/882, som har vært gjeldende i medlemslandene fra 28. juni 2025.
En ombygging er det billigste tidspunktet å rette dette på, fordi feilene oftest sitter i malene. Jeg bygger temaet etter WCAG 2.2 AA, som dekker kravene over: semantisk HTML, full tastaturbetjening med synlig fokus, etiketter på alle skjemafelt, kontrast på minst 4,5:1 for brødtekst og ARIA bare der HTML ikke strekker til. Innholdet, som alt-tekster og tekstalternativer til video, er redaksjonens ansvar; jeg sørger for at feltene finnes.
Hvordan beholde søkeplasseringene
- URL-er: beholdes der det går; der de må endres, får hver gammel adresse sin egen 301-viderekobling, ikke en samlekobling til forsiden.
- Metadata: titler, metabeskrivelser, kanoniske adresser og strukturerte data flyttes med innholdet.
- Interne lenker: skrives om i databasen til nye adresser.
- Etter lansering: nytt XML-nettstedskart sendes til Search Console, og 404-rapporten og indekseringen følges de første ukene.
Googles egen veiledning om 301-viderekoblinger ved flytting er grunnlaget for oppsettet.
Sjekk selv før du bestiller
Klarhetsrevisjonen for redesign er en sjekkliste med ti spørsmål om ytelse, søkesynlighet, tilgjengelighet, sikkerhet, innhold og infrastruktur. Den gir deg et grunnlag for briefen og viser hva som haster og hva som kan vente.
Etter lanseringen
Vil du at jeg tar driften etterpå, omfatter vedlikeholdet oppetidsovervåking hvert 1. til 5. minutt, sikkerhetskopier som oppbevares i minst 30 dager i EU-land, og oppdateringer som jeg tester i testmiljøet før de går til produksjon. Før jeg får tilgang til personopplysninger, signerer vi en databehandleravtale etter GDPR artikkel 28. Døgnvakt og garanterte responstider tilbyr jeg ikke.
Send en brief via kontaktsiden med adressen til nettstedet og hva som skal endres, så får du spørsmålene mine og deretter et skriftlig tilbud.
