Relansjeringssjekkliste for nettbutikker, bestillings- og bedriftsnettsider.

Skal du gjøre en relansering? Gratulerer med at du har funnet denne artikkelen. De følgende uttalelsene kan være en avgjørende faktor for at relanseringen din blir vellykket og at du oppnår et fantastisk resultat. For det skjer ikke alltid. Jeg er byråeier og vil avsløre nøyaktig hva som setter deg i stand til å tvinge typer som meg til ekstremt godt arbeid og til å unngå typiske feil ved relanseringer. Men la oss begynne helt fra begynnelsen.

En nettside-relansering er nydesign og revisjon av en eksisterende nettside. Både design, innhold og teknologi kan endres. Målet med en nettside-relansering er å forbedre nettsiden og tilpasse den til dagens krav.

Spesifikke ytre utløsere får bedrifter til å erklære målet om "relansering": Den nylig ansatte medarbeideren bringer med seg flotte ideer, en ny sjef kommer og vil også gjøre en digital opprydding, konkurrenten har en ny nettside, eller omsetningen synker. Kanskje liker heller ikke sjefens kone den gamle siden, eller generasjon Z synes nettsiden ikke er "lit" nok. Du kjenner kanskje til det. Å si at det igjen er tid for en ny nettside, er like lite som personlige meninger en grunn til en relansering.

Det er imidlertid noen bedre grunner til at bedrifter eller organisasjoner ønsker å gjennomføre en nettside-relansering. De viktigste blant disse er:

• Utdatert design og/eller rebranding: En forældet nettside kan gi inntrykk av at bedriften ikke henger med i tiden eller ikke er lenger aktiv. Dermed kan et friskt, moderne design forbedre bedriftens image. Selv om merkevareimagen eller bedriftsidentiteten endres, er en relansering av nettsiden ofte ønsket for å gjenspeile den nye merkevaremeldingen.
• Bedre brukeropplevelse: Hvis nettstedets brukervennlighet er dårlig, kan dette føre til høy avvisningsprosent. En relansering kan bidra til å forbedre brukeropplevelsen og gjøre nettsiden enklere å navigere på.
• Mobiloptimalisering: Ettersom stadig flere mennesker får tilgang til nettsteder via mobile enheter, er det viktig å sikre at nettsiden fungerer godt på ulike skjermstørrelser og enheter.
• Søkemotoroptimalisering (SEO): En utdatert nettside kan ha problemer med SEO-ytelsen. En relansering gir muligheten til å gjøre SEO-vennlige endringer for å forbedre synligheten i søkemotorer.
• Oppdatering av innhold: Hvis informasjon, tjenester eller produkter i en bedrift endrer seg, må nettsiden oppdateres for å gjenspeile disse endringene.
• Forbedring av sikkerhet: Eldre nettsteder er ofte mer sårbare for sikkerhetsrisikoer. En relansering kan bidra til å forbedre nettsidens sikkerhet og beskytte mot cyberangrep.
• Teknologisk oppdatering: Bruk av utdaterte teknologier kan påvirke ytelsen til en nettside. En relansering kan gi muligheten til å oppgradere til moderne webteknologier og -plattformer.
• Tilgjengelighet: For mange nettsteder er forbedring av tilgjengeligheten et viktig mål for å sikre at de er tilgjengelige for personer med nedsatt funksjonsevne.
• Konkurranse: For å holde følge med konkurrentene er det viktig å ha en moderne og effektiv nettside. En relansering kan bidra til å opprettholde eller forbedre konkurransedyktigheten.
• Analytiske forbedringer: Ved implementering av bedre analyseverktøy og innsamling av data kan bedrifter bedre forstå og optimere nettstedsytelsen.
• Overholdelse av juridiske krav: Lover og forskrifter innen personvern, tilgjengelighet og sikkerhet endres jevnlig. En relansering kan være nødvendig for å sikre at nettsiden oppfyller disse kravene.

Disse grunnene kan opptre hver for seg eller i kombinasjon, og varierer avhengig av bedriftens mål og behov. En nettside-relansering er ofte en strategisk beslutning for å forbedre nettstedets synlighet og oppnå bedriftens mål. Ved å se på punktene ovenfor hver for seg, blir det tydelig at de fleste grunnene kan implementeres med mindre sprinter og ikke nødvendiggjør en stor relansering.

La oss derfor skille hva en relansering er og hva den ikke er: Et nytt design med eksisterende teknisk grunnlag er heller et ansiktsløft. Relanseringen foreligger når målet med relanseringen fører til en virkelig endring i brukeropplevelsen, funksjonaliteten og teknologien.

En relansering bør alltid begrunnes med fakta (f.eks. teknologien er i en stillstand og kan ikke oppdateres lenger), nøkkeltall samt måle- og sammenligningsdata.

Dette er mitt første anbefaling her: Evolution før Revolusjon! Unngå en relansering så lenge som mulig, og prøv å implementere alle punktene som tidligere ble fremmet for en relansering individuelt eller inkrementelt. Forbedre en ting, sett den i live, evaluer hva som skjer, tilpass igjen, eller gå videre til neste punkt. Det beste eksempelet er Amazon, som virkelig bare endrer seg og forbedrer seg minimalt og har unngått store relanseringsendringer i mange år.

En relansering utgjør alltid en stor risiko for synligheten din på Google. Alle ser forbedringene, men få ser risikoen. Selvfølgelig blir grensesnittet bedre, den positive brukeropplevelsen øker, og du er teknisk oppdatert igjen. Likevel: Avhenger bedriftssuksessen din av sterk organisk synlighet, er en relansering det siste virkemidlet og bør bare bestemmes når smerten din er stor nok gjennom en kombinasjon av de nevnte grunnene, som ikke lenger kan løses individuelt i små sprinter. Hvorfor? Se her hva som skjedde med synligheten på Google etter relanseringene av disse fire nettstedene:

Planlegg relanseringen nøye og sikre en vellykket gjennomføring ved å bruke en sjekkliste. Sett deg spesielt de to målene, å opprettholde synligheten din på nettet og å finne muligheter for å skape et grunnlag for å øke synligheten på nettet i forbindelse med relanseringen. Nettopp derfor er denne artikkelen her, for å gi deg en relanseringsguide, slik at risikoene dine ved relansering begrenses og du virkelig oppnår et ekstraordinært godt arbeidsresultat med potensial for bærekraftige, organisk SEO-suksesser.

Relanseringsplan

Planleggingen av en nettside-relansering bør utføres nøye. Det er viktig å ta hensyn til følgende steg:

• Analyse av eksisterende nettside og dokumentasjon av nåværende tilstand: Først bør den eksisterende nettsiden analyseres for å identifisere styrker og svakheter.
• Fastsettelse av mål: Målene for nettside-relanseringen bør defineres klart. Dette inkluderer for eksempel forbedring av konverteringsfrekvensen, økning av besøkstallene eller byttet til et nytt CMS med forbedret innholdshåndtering og vedlikehold.
• Utvikling av konsept: Basert på analysen, målene og en konkurranseanalyse bør det utvikles et konsept for nettside-relanseringen. Konseptet bør omfatte aspektene: Design, innhold, teknologi og SEO/markedsføring.
• Gjennomføring: Konseptet gjennomføres. Dette involverer utvikling av design, oppretting/tilpasning av innhold og implementering av tekniske endringer.
• Testing: Den nye nettsiden bør testes grundig før lansering, for å sikre feilfri funksjonalitet. Dette inkluderer også en definert sjekkliste.
• Lansering: Den nye nettsiden publiseres så. Deretter fortsetter den å testes live, evalueres og tilpasses.

Bestemmelse av mål og strategi for relanseringen

Bestem nøyaktig hvilke mål relanseringen skal ha. Mål kan være (i tillegg til de nevnte grunnene): 

• Forbedring av brukeropplevelsen
• Økning av oversikt
• Utvidelse av innholdstilbudet
• Modernisering av designet
• Økning av inntektene og handlekurvverdien 
• Bytte til et annet CMS med enklere innholdshåndtering og teknisk vedlikehold
• Fremtidig enklere utvidelsesmuligheter og opprettholdelse av oppdateringsvennlighet.

Forslag: Etter de første kick-off-møtene i teamet som et selskap - før man går videre til samtaler med de utførende byråene - bør enhver prosjektdeltaker skrive ned målene for relanseringen på et ark eller i sitt inntastingsverktøy i deres kommunikasjonsverktøy (f.eks. Slack). Når alle deretter viser frem målene samtidig, vil du bli overrasket over hvor forskjellige meninger kan være, selv om målet allerede ble diskutert verbalt under møtene. Derfor er det viktig å også fikse målene skriftlig. Når du kjenner målene dine nøyaktig, kan du allerede i en tidlig fase vurdere om de har blitt konseptuelt tatt hensyn til i UI-prototypen.

Et kravsdokument gir klarhet i relanseringsoppdraget

Byrået trenger en omfattende prosjektbeskrivelse fra kunden for å kunne lage et tilbud. Bedrifter har vanligvis et Word-dokument eller en PDF klart, hvor prosjektet er skissert mer eller mindre detaljert. Det gjennomføres deretter spørreskjemaer eller workshops, der byråene bedre kan identifisere kundens smertepunkter for å kunne gi et tilbud. For større prosjekter utarbeides et kravsdokument. Jo mer detaljert, jo bedre.

Et kravsdokument er et dokument som spiller en avgjørende rolle i forbindelse med en nettside-relansering. Det brukes til å skriftlig fastsette kravene, målene og forventningene til relanseringen. Et godt utarbeidet kravsdokument hjelper til med å sikre at alle involverte - enten det er utviklingsteamet, design-teamet eller kunden - har en klar forståelse av hva som skal oppnås under relanseringen. Det er også en startpunkt for et godt beregnet og bindende tilbud fra det utførende byrået. Her er informasjon og elementer som vanligvis kan inkluderes i et kravsdokument for en nettside-relansering:

• Mål og formål: En beskrivelse av hovedmålene for relanseringen, f.eks., forbedring av brukeropplevelsen, økning av synligheten i søkemotorer eller byttet av CMS med oppdatering av designet.
• Prosjektomfang: En tydelig definisjon av hva som er inkludert og hva som ikke er innenfor rammen av relanseringen. Dette kan inkludere antall sider, integrasjon av tredjepartsverktøy eller revisjon av innhold.
• Designkrav: Informasjon om ønsket visuell utforming av nettsiden, inkludert layouter og overholdelse av bedriftens designretningslinjer for farger, skrifter og bilder.
• Funksjonskrav: En oppsummering av ønskede funksjoner og interaksjoner på nettsiden, som f.eks. kontaktskjemaer, søkefunksjoner, e-handelsfunksjoner osv.
• Tekniske krav: Spesifikasjoner for teknologiene som skal brukes under relanseringen, som valg av et innholdshåndteringssystem (CMS) eller implementering av spesifikke funksjoner. Bruken av moderne bilde- og grafikkformater som WebP, AVIF, SVG er også inkludert.
• Manuelle og automatiske sikkerhetskopier og revisjoner av innholdsredigeringer.
• Innholdskrav: Tydelige retningslinjer for revisjon, oppdatering eller nyopprettelse av innhold, inkludert tekst, bilder, videoer og andre medier. Håndtering av metainformasjon og strukturerte data.
• SEO-krav: mer om dette i neste del.
• Tidslinje og milepæler: En tidsplan som fastsetter planlagte start- og ferdigstillelsesdatoer for relanseringen, samt viktige milepæler.
• Budsjett: Informasjon om budsjettet for relanseringen, inkludert kostnader for design, utvikling, hosting og eventuelle tredjeparts tjenester.
• Kvalitetssikring med testverktøy: Beskrivelse av tester og kvalitetskontrollprosedyrer som skal gjennomføres under relanseringen for å sikre at nettsiden fungerer feilfritt.
• Vedlikeholds- og supportkrav: Krav til løpende vedlikehold og støtte for nettsiden etter relanseringen.

En godt strukturert kravspesifikasjon er avgjørende for å unngå misforståelser, effektivt styre prosjektet og sikre at forventningene til alle interessenter blir oppfylt. Den fungerer som retningslinje og referansedokument for hele prosjektteamet og bidrar til å sikre suksessen med nettstedsrelanseringen. 

Da vi planla relanseringen av TutKit.com med en fullstendig overgang fra CodIgniter til Laravel-rammeverket, omfattet kravspesifikasjonen vår 220 sider - (ikke) en fristende utsikt for et byrå å måtte jobbe seg gjennom.

Merknad: Konsept, design, funksjon og teknologi som brukes vil ikke bli detaljert behandlet i artikkelen min. Det nye nettstedet vil sikkert være vakkert. Den største faren ved en relansering ligger faktisk i en forverring av den tekniske brukeropplevelsen og kvaliteten på siden på grunn av manglende 301-videresending osv., noe som kan føre til et tap av rangering og synlighet. For å hindre dette, vil det i det følgende først og fremst være fokus på sikring av prosjektsuksess fra et brukeropplevelses- og SEO-perspektiv.

Definisjon av SEO-kravene for det nye nettstedet

Kundeopplysningene eller en omfattende kravspesifikasjon regulerer allerede hva som er ønsket når det gjelder design, innhold, funksjonalitet og teknologi, og er grunnlaget for et byrå kan legge opp en kalkyle.

For relanseringskontrolliste for sikring av prosjektsuksess, må vi se på de enkelte delene fra et SEO-perspektiv. Det oppstår spesifikke SEO-krav på grunn av for eksempel:

• endring av URL-struktur (URL-videresendingskart!) og endring av lenkestier
• endring av navigasjonen (viktig på grunn av intern lenking og lenkehierarki)
• endring av teknologier (CMS, JavaScript-rammeverk, server, osv.)
• endring av innhold (potensiell synlighetstap av godt rangerende sider)

Sider rangerer høyt på Google på grunn av deres innholdsmessige relevans, derfor er det viktig å spørre om det eksisterende innholdet endrer seg eller slås sammen, om innhold forsvinner og/eller nytt innhold legges til? Endrer innholdsmessig struktur av kategorier eller sider? SEO-krav må avledes fra disse punktene og inkluderes i relanseringskontrollisten.

Blir metadataene av de gamle innholdene også overført og endrer seg? Hvordan utføres innholdsadministrasjonen av redaktøren og er sidens innhold knyttet til strukturerte data?

Blir de eksisterende eller nye bildene lagt inn på moderne bildeformater for nettsteder (WebP/Avif) og blir det tatt hensyn til bildesøkoptimalisering med talende URL-er i små bokstaver, altså istedenfor 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Det er også viktig å sørge for at bildefilene er strukturert gjennom data (ImageObject) og <meta>-miniatyrbilder blir sendt til Google, for å øke sannsynligheten for å inkludere bilder i søkeresultatene og oppføringen på Google Bilder.

Også interessant i denne sammenheng er spørsmålet om hvordan brukersignalene kan forbedres. På innholdssider kan bildervideoer, forklaringer og hjelpevideoer integreres. Når en bruker som kommer fra Google til landingsiden klikker på videoen og ser på den, øker oppholdstiden (godt brukersignal), tilbake-til-SERP-rate forbedres også (godt brukersignal). 

Det bør også undersøkes hvordan innholdseksjonene kan integreres på sidene for å oppfylle Googles krav til nyttig innhold og for E-A-T-prinsippet.

For Google er "nyttig innhold" innhold som er relevant og nyttig for brukerne. Det besvarer brukernes spørsmål grundig og informativt, tilbyr løsninger på problemer og gir en merverdi som går utover bare reklamebudskap.

Her er noen eksempler på nyttig innhold:

• Opplæringsguider og veiledninger: Dette innholdet hjelper brukerne med å lære nye oppgaver eller løse eksisterende problemer.
• Anmeldelser og sammenligninger: Dette innholdet hjelper brukerne med å velge riktig produkt eller tjeneste.
• Nyheter og oppdateringer: Dette innholdet holder brukerne oppdatert om aktuelle hendelser og trender.
• Infografikk og diagrammer: Dette innholdet kan hjelpe med å visualisere komplekse data og informasjon.
• Blogginnlegg og artikler: Dette innholdet gir en dypere innsikt i et spesifikt emne.

Google bruker ulike signaler for å identifisere nyttig innhold. Dette inkluderer blant annet:

• Brukeradferd: Google observerer hvordan brukerne samhandler med innhold, for eksempel hvor lenge de blir på en side, hvor ofte de deler den og hvor ofte de vurderer den.
• Kvalitetssignaler: Google vurderer kvaliteten på innhold basert på faktorer som relevans, fullstendighet og aktualitet.
• Tilbakemeldinger fra brukere: Google tar også hensyn til tilbakemeldinger fra brukerne, for eksempel vurderinger og kommentarer.
• Ved å ta hensyn til disse signalene, kan nettstedeiere øke sjansene for at innholdet deres blir ansett som nyttig.

EEAT-prinsippet er et konsept utviklet av Google som evaluerer kvaliteten på nettsteder og webinnhold. Det står for Ekspertise, Erfaring, Autoritet og Troverdighet, altså Ekspertise, Erfaring, Autoritet og Troverdighet.

• Ekspertise refererer til kunnskapen og erfaringen til personene som skaper innholdet. Google vurderer ekspertisen basert på faktorer som utdanning, yrkeserfaring og utmerkelser.
• Erfaring blir bekreftet når innholdet også er skapt med en viss erfaring, for eksempel basert på faktisk bruk av et produkt, faktisk besøk på et sted eller beskrivelse av opplevelser av en person.
• Autoritet refererer til omdømmet til et nettsted eller webinnhold. Google vurderer autoriteten basert på faktorer som tilbakekoblinger, aktiviteter i sosiale medier og brukervurderinger.
• Troverdighet handler om påliteligheten og troverdigheten til et nettsted eller webinnhold. Google vurderer troverdigheten basert på faktorer som personvern, sikkerhet og gjennomsiktighet.

Hvilke SEO-krav har eksisterende og nye Funksjoner med hensyn til front- og backend? Her er noen eksempler:

• Gjennomtrengelighet (relevant innhold må være synlig og gjennomtrengelig også uten JavaScript)
• Tydelighet på nettstedets mål og tydelighet om handlingsoppfordringen (ønsket atferd fra målgruppen på sidene)
• Unngå duplisert innhold ved for eksempel automatiske opprettede kategorisider eller sidekopier på grunn av variantartikler
• Sikre en høy hastighet på siden ved å unngå for mange JavaScript- og CSS-filer, ved å bruke moderne bildeformater (WebP/AVIF)

Disse SEO-kravene bør inkluderes i prosjektbeskrivelsen eller i kravspesifikasjonen, men også gjennom en testverktøybasert sjekkliste eller som en IST-SOLL-sammenligning i prosjektkvalitetssikring og i tillegg som en akseptansekriterium for byråets ytelse. Mer om dette nedenfor.

Fastsettelse av interne og eksterne prosjektdeltakere

Bestem prosjektdeltakerne - her sett fra kundens eller nettsideeierens synspunkt:

• Hvem har ansvar for prosjektledelsen og tar de endelige beslutningene?
• Hvem er ansvarlig for koordinering og kommunikasjon med byrået eller med kunden?
• Hvem tar seg av intern prosjektledelse?
• Hvem forbereder internt innhold og bidrar til byrået?
• Hvem implementerer brukeropplevelsesdesignet?
• Hvem implementerer utviklingen?
• Hvem rapporterer fra byrået til kunden i gitte intervaller?
• Hvem utfører test og kvalitetssikring på byråsiden/kundesiden?
• Er en ekstern konsulent involvert (for eksempel for SEO eller juridiske krav)?
• Hvem godkjenner oppgavene? Hvem tar imot oppgavene i billettsystemet etter at de er fullført?
• Hvem må varsles på hvilket tidspunkt (ansatte, kunder, partnere, Annonsenkampanje-forvalter, …)?

Ved valg av eksterne prosjektledere er fire punkter viktige

1. Har byrået gjennomført ett eller flere prosjekter av denne typen? Finnes det referanser? Finnes det kundevurderinger og ville et tilbakemeldingsintervju med byråets kunder være mulig - noe som er anbefalt for store individuelle utviklinger?
   
2. Oppfyller byråets tilbud og tekniske implementasjon (CMS/Shopsystem/Framework) allerede alle krav knyttet til relansering? Finnes det individuelle funksjoner eller krav som må programmeres ytterligere (også via plugin eller moduler)? Er det spesifikke tjenester som er utelatt eller planlagt for senere, men som er avgjørende for prosjektsuksessen? Det er viktig at ingen nye problemer oppstår som er større enn hovedårsaken til relanseringen.
   
3. Passer det utførende byrået eller leverandøren både i størrelsen på teamet og den geografiske plasseringen og (på Kununu-vurderinger eventuelt identifiserbare) personellfluktuasjonen også bærekraftig for selskapet for videre oppfølging?
   
4. Er en direkte kontakt til det utførende design- og utviklingsteamet mulig? Det er fornuftig å bli kjent med det faktiske, byråside prosjektteamet. De godt humørøyde og rosende salgsproffene kan sikre avtalen og være ikke lenger ansvarlige senere. Derfor bør også direkte kontakt med det utførende teamet avtales.

Fem tips til egen sikkerhet i denne sammenhengen

1. Som kunde ville jeg nøye overvåke teknologien byrået bruker. Det som står i tilbudet, bør rett og slett googles med "CMS + Ulemper" eller "CMS + Erfaringer". Du bør vite nøyaktig hva du går inn for. Det er fornuftig å satse på åpen kildekode-løsninger. Jeg er klar over at det ikke alltid er mulig. Sørg helst for at det er et så stort utviklerfellesskap for den anvendte teknologien, slik at du ikke ender opp med en agenturspesifikk løsning som bare byrået kan jobbe med, noe som senere kan sette deg i betydelige bindende situasjoner.
   
2. Sørg også for at du får ubegrensede bruks- og redigeringsrettigheter til byråets tjenester, slik at du alltid har rett til å utvikle websiden internt eller eksternt. En slik paragraf bør være en del av utarbeidelseskontrakten.
   
3. Hvis selskapet ditt er teknisk orientert og har systemadministratorer, programvareutviklere eller lignende i teamet, kan det være lurt å sette opp GIT for versjonskontroll og JIRA (eller et lignende verktøy) for prosjektledelse eller billettsystem på egen hånd i en egen konto. Deretter gir du byrået full tilgang og arbeidet kan begynne. Jo større et prosjekt er, desto tøffere og smertefullere kan det bli. Da er det bra at du har kontroll over de viktige tilgangene og kontoene. Jeg er klar over at denne anbefalingen rent faglig sett kan bli fulgt av få kunder.
   
4. Sometimes agencies offer hosting services directly to clients. We are not fans of this because on one hand, it increases dependence in the client relationship, and on the other hand, we believe that web hosts are best suited for web hosting as they are specialized in it. We have set up servers for ourselves and spent a lot of human and time resources, only to go back on it. Now our systems run on cloud servers from one of the major web hosts in Germany and we are happy. When it comes to web hosting, always make sure that server-side backups are included in the package and can be easily restored with a few clicks.

Bestemmelse av tidsramme og lanseringstidspunkt

En relansering utføres i flere prosjektsprinter. Disse kan ifølge vår byråerfaring være som følger:

• Nåværende tilstand protokolleres (via testverktøy, men også skriftlig med inntrykk av hva som fungerer bra fra kundens side og hvor forbedringer er nødvendige)
• Forskningsfase med konkurranseanalyse og søk etter løsninger/inspirasjon
• Wireframe konseptualisering
• Design av brukergrensesnitt
• Front-end- og back-end-utvikling
• Dataoverføring eller innholdsimport (automatisert/manuelt)
• Strukturelle og innholdsmessige optimaliseringer av innhold (tekst og bilde) & SEO-sprinter

Prosjektsprinter overlapper hverandre, fordi nye prosjektdeltakere blir aktive i løpet av arbeidet.

Det er viktig å definere tidsrammen for enkeltprosjektsprinter og samkjøre den med deltakerne. 

Når byrået oppretter en Slack-kanal for kunden for prosjektet, hvis det er stort, for raskere kommunikasjon?

Et tips på dette stadiet: Det er bra hvis byrået allerede på et veldig tidlig tidspunkt jobber med klikkbare prototyper, altså allerede i wireframe-konseptualisering og spesielt ved presentasjonen og testing av brukergrensesnittsdesignet. Slik får kundene en bedre følelse for opplevelsen av nettstedet. Enkle JPG- eller PNG-filer som layoutforslag er ikke lenger moderne. Det bør være klikkbare prototyper som er utarbeidet med Sketch, Figma, Adobe XD eller et annet profesjonelt verktøy.

Endringer er enkle å gjøre på dette tidlige stadiet. Når funksjoner og seksjoner på en nettside allerede er utviklet, er endringer mye mer tidkrevende og kan føre til reforhandlinger, som ikke er spesielt attraktive.

Her er det en illustrasjon av hvordan en slik prototype ser ut for design av det mobile brukergrensesnittet med oversikt over klikkbanene:

Spørsmålet som må avklares, er når løpende tester fra kundens side er mulige. Utviklerne bør også teste arbeidene lokalt etter innføring i stadiet. Det høres banalt ut, men alle som samarbeider med utviklere, skjønner umiddelbart hva jeg mener. Deretter bør den som er ansvarlig for kvalitetssikring på byråsiden teste billetten eller funksjonen. Først da blir billetten frigjort for testing for kunden. Kunden bør aldri føle seg som en alfa-tester, men heller finne et system som allerede er testet av fire øyne. Byrået er alfatesteren, mens kunden er betatesteren! Er det i det hele tatt tilgang til byråets billettsystem?

Også bør det skriftlig defineres at byråsiderapporter til kunden skal leveres med en bestemt frekvens. For eksempel kan det være en rapport via e-post hver fredag om den nåværende statusen på arbeidene, nødvendige tilbakemeldingsløkker eller behov for assistanse. Dette er også et tips fra vår byråerfaring: Det er bra å ikke la kunden være usikker ved helgen. Da kan han bare få dårlige ideer. Det er bedre å informere godt om hva som har skjedd og hva som står for tur i den påfølgende uken. Gjennomsiktighet hjelper, slik at alle kan være involvert med en god følelse om saken.

Lanseringstidspunktet bør også fastsettes. I henhold til Parkinsons lov utvider arbeidet seg til å fylle den tilgjengelige tiden for utførelse. Med andre ord, jo mer tid som står til rådighet for utførelsen av en oppgave, desto mer tid vil den ta, uavhengig av den faktiske kompleksiteten eller arbeidsinnsatsen. Planlagt ferdigstilling skal også være en del av avtalen. Å bryte fristen kunne til og med bli pålagt en kontraktsstraff i avtalen. Retningslinjen er at kontraktsstraffer på 0,2 % av kontraktsbeløpet per arbeidsdag for forsinkelsen og maksimalt 5 % av kontraktsbeløpet er effektive. Kontraktsstraffen trenger ikke nødvendigvis fremmes fra kundens side, men gir deg spillerom til å avtale noen ekstra ønsker som kompensasjon til byrået.

Viktig: Ingen lansering på fredag. Heller ikke mellom helligdager eller i virksomhetens hovedtid. Vi anbefaler faktisk å gjøre store relanseringer på nattetimene fra søndag til mandag, spesielt hvis IP-adressen endres, slik at DNS-innstillingene hos de fleste leverandørene fortsatt blir oppdatert på mandag, noe som ofte skjer tidlig mandag formiddag hvis DNS-oppføringen ble endret i nattetimene. Så det er faktisk 4,5 arbeidsdager igjen til live-testing og feilretting av eventuelle feil.

Protokoll av din nåværende nettsides tilstand

Den nåværende statusen må registreres før arbeidene starter. I den nåværende tilstanden registreres hvordan de tekniske måleresultatene er for parameterne. På høyre side kan du fylle inn målverdiene:

I listen finner du som SEO-verktøy det vi ofte bruker, Seobility, for å sjekke OnPage-faktorer, som jeg også har publisert en SEO-trening om. Det er mange alternativer som for eksempel Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog osv. Når det gjelder SEO-verktøyet, handler det hovedsakelig om å identifisere og fikse typiske OnPage-feil. Her fokuserer Seobility på de tre hovedområdene Teknologi & Meta, Struktur og Innhold. Du finner det på samme måte i andre SEO-verktøy. Det er viktig dels at en full sjekk gjennomføres, med andre ord at ALLE sider blir crawlet og ikke bare startsiden, og dels at du noterer en score eller feilverdi for nå-situasjonen og den ønskede verdien som skal oppnås etter optimaliseringen. Hos Seobility er en verdi på 90 eller høyere ønskelig. Du finner også alternative verktøy for andre formål. Det viktige er å faktisk bruke et verktøy for å sikre utmerkede data.

Dette er for eksempel vår nåværende verdi for kvaliteten på OnPage:

De brukersignalene kan statistisk måles med verktøy fra Google Analytics 4, som for eksempel Bouncerate, Sider/Besøkende, Oppholdstid osv. Dersom Google Analytics eller et annet analyseverktøy brukes i samsvar med dataregler, bør disse dataene også tas med i loggføringen av nå-situasjonen. 

Det bør også opprettes en tilbakekoblingsliste, som for eksempel kan genereres gratis her: https://www.seobility.net/de/backlinkcheck/

Videre bør den gamle sitemap.xml sikres, samt en Full-Backup av siden. Alle relevante sider bør også overføres til en Google-arkliste, som danner grunnlaget for URL-Redirect-Map. En slik CSV-liste kan enkelt eksporteres via et SEO-verktøy som Seobility. I URL-Redirect-Mapen er alle relevante sider og lenkede sider via eksterne tilbakekoblinger (se tilbakekoblingslisten) tatt med, som senere må omdirigeres på grunn av endrede side-URLer. Uteblivende URLer må omdirigeres til de nye URLene tilsvarende de gamle. Det er viktig å forhindre omdirigeringskjeder! De gamle, fortsatt eksisterende omdirigeringene må lede direkte til den nye slutten-URLen. På samme måte bør det også tas hensyn til PDF-filer og bilder som det er lenker til, slik at de også omdirigeres korrekt og ikke ender opp som en 404-link.

Omdirigeringene settes opp som 301-omdirigeringer basert på URL-Redirect-Map i .htaccess, via Redirect-Maps via Vhost-konfigurasjon eller en database-løsning. Kunden bør kunne administrere dette selv. Det er også viktig å sørge for at omdirigeringene er varige.

Det anbefales også å sikre hver sidetype med en Fullpage-skjermskudd. Dette er dels en sikring av nåværende innhold i tilfelle det oppstår spørsmål etter lanseringen om at innholdstypene ikke ble overført osv.

Basert på eksisterende sider, funksjoner og innhold og resultatene fra målingene kan det identifiseres hva som allerede fungerer bra og hva som er identifisert som et område med potensial for optimalisering, som bør forbedres gjennom relanseringen.

Checkliste: Før relansering

Så snart brukergrensesnittet er bekreftet og byrået er i utviklingssprinten, blir følgende sjekkliste relevant, som lister opp de viktige punktene kronologisk frem til relanseringsdagen:

1. Dev-miljøet med tilgang for alle involverte er tilgjengelig for testing
2. Dev-miljøet kjører på noindex
3. Tilgang til testverktøy på Dev-miljøet (IP-godkjenning eller http-innlogging) er konfigurert
4. Konfigurasjonen av Dev-miljøet samsvarer så godt som mulig med live-systemet
5. Sidestrukturen på Dev-miljøet samsvarer med den fremtidige live-siden
6. Dataoverføring av tidligere data er gjennomført
7. Innholdsjusteringer er gjort
8. Bilde-SEO er gjennomført
9. 301-omdirigeringer basert på URL-Redirect-Mapen er satt opp 
10. OnPage-sjekk med Seobility er gjort, feil er rettet og målene er nådd
11. Open-Graph-dataene er gyldige
12. Strukturerte data er gyldige
13. Sjekk av sidetilkoblinger for alle sidetyper er gjort, målene er nådd
14. Content-Cookie-Policy fungerer
15. Sikkerhetsheadere er satt opp
16. Tilgjengelighet er gitt, målene er nådd
17. Hreflang er gyldige (for flerspråklige sider)
18. Juridiske tekster (vilkår og betingelser, avtrykk, angrerett, personvern) er oppdatert, GDPR-konformitet er gitt
19. Oppdatering av CMS, rammeverk, brukte plugins og moduler til nyeste versjon er gjort
20. Endelig nettleser- og enhetsovergripende funksjonstest avdekket ingen feil
21. Endelig status og lanseringsdato er kunngjort 
22. Fullstendig sikkerhetskopi er opprettet

Bruken av strukturerte data (Schema-Markup) - se punkt 12 på listen - blir fremdeles altfor lite vektlagt i dag. Bli kjent med emnet og les hva Google sier om Markup for strukturerte data i Google-søk. Google vil i økende grad legge vekt på gyldige data innenfor rammen av EAH, altså søkeresultater som er laget av AI. Også med Googles Helpful Content-oppdatering, kreves det at innhold er mye bedre verifisert ved hjelp av ekspertise, erfaring, autoritet og troverdighet. Strukturerte data er en del av løsningen for å forenkle denne valideringen for Google. Når strukturerte data er implementert, bruk Schema-Markup-Validator, men sjekk også sidene dine med Structed Data Linter, som Google også anbefaler og lenker til i PageSpeed Insights. Her får du mer omfattende informasjon om kodeskjær i forbindelse med bruk av strukturerte data.

Ved punkt 16 dukker begrepet Tilgjengelighet nå opp for første gang i denne artikkelen. Allerede i PageSpeed Insights har tilgjengelighet et eget område, og grønne tall der er ønskelig. Testen av om en side er tilgjengelig eller ikke, bør gjøres i tillegg til PageSpeed Insights også via https://www.accessibilitychecker.org og/eller https://wave.webaim.org. Spesielt når en relansering er på trappene, bør dette punktet obligatorisk tas med, siden tilgjengelighetsstyrkelsesloven for nettsteder blir aktuell fra 2025. Sjekk med et slikt verktøy ikke bare start­siden, men også hver sidetype – det samme gjelder for PageSpeed-testene!

I forbindelse med en relansering kommer det ofte også til tilpasninger og Oppdateringer av juridiske tekster. Dette bør tenkes på tidlig, og tekster bør eventuelt leveres av en spesialisert advokat eller via juridiske generatorer. Det bør også tas hensyn til databehandlingsavtaler, hvis for eksempel en ny webhost brukes eller nyhetsbrevtjenesten endres. 

Punkt 18 med oppdatering av CMS, brukte JavaScript-biblioteker, installerte moduler og tillegg er like undervurdert som viktig. En relansering kan ta flere måneder og lenger tid. Med WordPress-systemet er det enkelt å se om det kanskje allerede er mange tilgjengelige oppdateringer før relanseringsdagen. Kundene bør forsikre seg om at de nyeste versjonene brukes ved lanseringen.  

Ved endringer i eksterne tjenester kommer det til flere oppgaver som bør nevnes i sjekklisten, for eksempel ved endring av nyhetsbrevtjenesten: 

• Dataimport av nyhetsbrevkontakter til den nye NL-tjenesten
• Tilkobling til nyhetsbrevtjenesten på nettsiden ved registreringsskjemaet
• Databehandlingsavtale
• Opprettelse av nye utsendelsesskabeloner
• og så videre 

I løpet av hele utviklingsprosessen gjennomføres naturligvis kontinuerlige tester av funksjoner osv. Det er fornuftig å lage en svært detaljert sjekkliste for testene, slik at ingenting blir glemt. Det er ikke nok å bare klikke litt rundt, verken for det utførende byrået eller for kunden. Etter relanseringen av TutKit.com hadde sjekklisten vår for godkjenning sikkert 1 000 linjer. Og vi opprettholder fortsatt dette: etter viktige større oppdateringer sjekker vi ca. 70 interaksjoner via sjekklisten for Chrome, Safari og Android.

Sjekkliste: Relanseringsdagen og dagene som følger

Relasjoneringsdagen har kommet og det er ikke en fredag eller en dag mellom høytidene. Den nye nettsiden går live, DNS-innstillingene er justert. Nå gjelder det å sjekke alt på nytt og evaluere. Sjekk følgende: 

1. Sjekk robots.txt for å sikre at roboter ikke er blokkert 
2. Live-miljøet kjører med index, follow.  
3. Canoniske tags er riktig satt
4. Sjekk kildekoden til sidene for absolutte stier (lenkestier fra testmiljøet til live-siden)
5. Videresending fra http til https med/uten www til destinasjonssiden fungerer
6. Test videresendinger via URL-omdirigeringskartet, samt tilstedeværelse av videreseingskjeder
7. OnPage-sjekk av live-siden med Seobility for teknikk & meta, struktur og innhold ... spesielt sjekk side ikke indeksert via Seobility
8. Open Graph-data er gyldige
9. Strukturerte data er gyldige
10. Pagespeed-sjekk for alle sidetyper er utført, målene er nådd
11. Cookie-policy med samtykkeinformasjon fungerer som den skal
12. Sikkerhetsheadere er satt opp
13. Tilgjengelighet er gitt
14. Sjekk hreflang for flerspråklige nettsider (https://app.sistrix.com/de/hreflang-validator)
15. Definitiv nettleser- og enhetsovergripende funksjonstest ga ingen feil
16. Send inn den nye sitemap.xml til Google Search Console
17. Oppdater nye destinasjonssider for Google Ads-kampanjer
18. Ved visse domeneendringer, husk å oppdatere lenker i sosiale medier, e-postsignaturer osv.

Vi bruker Mailhog i utviklingsmiljøet vårt for å teste e-poster lokalt. I slike tilfeller er det viktig at riktige SMTP-data for mottak av e-post på live-systemet er satt opp, slik at e-postene går dit de skal.

Det må også tas hensyn til at med Betalingstjenester som Paypal i utviklingssystemet er Sandbox implementert, mens den riktige forbindelsen må etableres i live-systemet.

I dagene som følger er det viktig å overvåke Google Search Console spesielt. Det mest interessante er selvfølgelig hvordan rangeringene endrer seg. Fokuser spesielt på uventede endringer og feilmeldinger:

1. Crawling: Vertsstatus ... Henting av robots.txt, DNS-oppløsning, servertilkobling
2. Crawling-statistikk ... Forespørsler, nedlastingsstørrelse, gjennomsnittlig responstid
3. Klikk i SERP-ene
4. Impresjoner i SERP-ene
5. Gjennomsnittlig CTR i SERP-ene
6. Gjennomsnittlig SERP-posisjon
7. Bestått Core Web Vitals

Framfor alt advarer Google Search Console deg om feil som f.eks. URL-feil, Href-språkfeil, sidendeksantering med spredte indekserte/ikke-indekserte. For ikke-indekserte må det være en grunn (omdirigering, noindex)...). Der kan du også se duplikatinnhold eller andre problemer. Hvis Search Console rapporterer problemer med strukturerte data eller Core Web Vitals, må du undersøke nærmere. Bare ved å analysere live-data vil du for eksempel oppdage at sidene dine til tross for høy PageSpeed har problemer med Core Web Vitals på grunn av for eksempel CLS-feil. Her kan du tydelig se hvilke endringer som er mulige på nettsiden:

Du kan direkte se de dårlige eller optimale URL-ene. Ta en URL og gjør en PageSpeed-test med den på PageSpeed Insights. Der vil du få informasjon om hvorfor Core Web Vitals ikke oppfylles og hva du kan gjøre for å løse feilene. Klikk på den lille pilen nederst til høyre for detaljert informasjon. Disse anbefalingene kan vanligvis bare implementeres av utviklere. Det er imidlertid viktig at du er i stand til å identifisere problemene for deretter å ta dem opp med byrået ditt.

Analysér også dataene fra analyseverktøyene dine, for eksempel Google Analytics 4. Hold også et øye med de metrikker du kan registrere på systemnivå, for eksempel bestillinger, konverteringsrate, handlekurvverdi, kjøp/omsetning per dag, nyhetsbrevabonnementer, kontaktforespørsler, nedlastinger av bestemte innhold eller videovisninger.

Crawling-statistikkene i Google Search Console er avgjørende for sjekkene de kommende dagene. Du finner dem via innstillingene til venstre i menyen. Du bør kunne se mer Crawl-aktivitet umiddelbart. Hvis ikke, er det Crawl-feil til stede?

Vertsstatusen viser deg direkte feil, som for eksempel synlig etter en relansering, da forespørsler til robots.txt mislyktes og servertilkoblingen delvis avbrøt kontakten gjentatte ganger:

Også interessant er hva Crawling-statistikken sier. Etter en relansering er det vanligvis en vekst i Crawling-forespørsler. Der kan du også se om det fortsatt er 404-sider som krysses. Hvis noen av dem ikke passer inn, diskuter dem med utviklerne.

Du kan se om serveren din, PageSpeed-en din og koden din er relativt gode hvis responstiden på sidene dine er under 400 ms. Jo nærmere dette tallet kommer 1000 ms, desto mer anbefales det å optimalisere PageSpeed-en, for eksempel ved å redusere databaseforespørsler og styrke serverkraften (for eksempel mer beregningskraft, oppdatering til nyeste serverprogramvare, bytte til HTTP2 eller HTTP3 (med Nginx)).

På sikt vil Crawl-budsjettet for enkelte nettsteder sannsynligvis bli begrenset av stadig mer (AI-)innhold på nettsteder, så det er viktig å strebe etter en god respons- og svartid for sidene slik at robotene kan crawle så mye som mulig på nettstedene dine i den tilgjengelige tiden.

Relanserings-sjekkliste for nedlasting

De innleste sjekklistene for relansering er også tilgjengelige som PDF-filer for nedlasting her. Last dem ned og bruk dem til å sikre prosjektsuksessen din!

Bekjennelser fra en byråeier

SEO-kravene i sjekklisten kan også få detaljerte instruksjoner som å følge overskriftsstrukturen fra H1 til H6 osv. Den fastsettelse av målverdier i testverktøyene forkorter heldigvis hele relanseringssjekklisten innholdsmessig, fordi oppnåelsen av toppverdiene i testverktøyene nevnt i sjekklisten kun kan oppnås ved å overholde ren kode, bruk av moderne teknologi, hensyntakelse av SEO OnPage-faktorer osv. Ellers måtte de nyeste webstandarder og tekniske samt SEO-kravene formuleres ekstremt detaljert i prosjektbeskrivelsen, noe som kundene faglig sett ikke er i stand til. Hvis byråene trenger å oppnå høye verdier i testverktøyene, har de ikke annet valg enn å jobbe etter Best Practice - også en ny erfaring for byråene :-)

Det er på tide med en bekjennelse. Definisjonen av SEO-kravene samt en sjekklisteaktig tilnærming sammen med sikringen og den forpliktende oppnåelsen av målverdiene i ulike testverktøy representerer et ideal som sjelden oppnås i virkeligheten. Dette avhenger av:

• kundeside budsjettbegrensninger
• byråside fortjenestemaksimeringsinteresser
• begrensninger på grunn av de brukte teknologiene
• og dessverre også: uvitenhet og inkompetanse på begge sider

Jeg kan ikke klandre kundene. De leter jo aktivt etter profesjonell hjelp, og nesten alle digitale byråer skriver på nettsidene sine og i hvitbøkene at søkemotoroptimalisering er en av deres kjernekompetanser. Det er alltid referanser som viser at online-synligheten har økt med en faktor på 3, 5 eller 10 etter relanseringen. Men at antall besøkende øker fra 10 til 100 per dag utgjør en 1000 % økning, men det betyr ikke nødvendigvis suksess. Mange søkemotorresultater avhenger av at konkurrentene digitalt sett er mye svakere.

Byråer fortsetter å gjøre middelmådig arbeid med utdaterte metoder fordi de fremdeles ikke bruker moderne verktøy for kvalitetssikring, til tross for at det storslått sies i postene, referansene, beste praksiser osv. at de har SEO-kompetanse. Kanskje er slike byråer kunnskapsrike når det gjelder detaljer, men når det kommer til utførelse er de svake. Det høres strengt ut, men det er bare virkeligheten. Ta deg gjerne tid til å se nærmere på det! Bruk sjekklisten ovenfor og sett den beste byrået i regionen du kommer fra inn i de nevnte verktøyene sammen med nettadressen deres. Deretter tar du den nyeste nettsidereferansen du finner fra byrået, og gjentar prosessen. Hvilke resultater vil du se? Akkurat de du kan forvente i et samarbeid. Du kan også bruke våre egne referanser på samme måte og du vil oppdage at vi heller ikke oppnår toppverdiene overalt i kundeprosjektene våre. En slik arbeidsflyt med en holdning til datastyrt kvalitetssikring har utviklet seg hos oss fra prosjekt til prosjekt og har spesielt etablert seg gjennom arbeidet vårt på TutKit.com. 

Du kan gjøre slike undersøkelser med nesten hvilket som helst byrå, fordi få virkelig jobber datastyrt med kvalitetssikring, fordi ingen har egne prosjekter på markedet i flere år og konkurrerer i den harde kampen om online-synlighet med internasjonale aktører, og fordi byråene nesten ikke bryr seg om et prosjekt lykkes eller ikke, så lenge byråregningen blir betalt og kundene kan feire de vakre (men kvalitetsmessig gjennomsnittlige) nettsidene i innleggene sine og med priser. Den spesielle ironien her er: Etter de nevnte testverktøyene presterer ofte SEO-byråene overraskende dårlig med sine egne nettsider, fordi de ofte, som en One-Trick-Pony, kun har en metode … en innholdspakke utviklet for kundenes nøkkelord på nettstedet. For de andre tekniske kravene mangler ofte kompetente utviklere helt enkelt.

En fordel er også hvis byrået er et annet sted slik at du ikke møter kunden mens han handler i byggevarehuset som ansvarlig byråmedarbeider, som bare har ansvaret for et synlighetsfall med tosifret prosentandel etter en relansering. Men kunder sjekker sjelden dette synlighetsfallet, for selv om alle har en informasjonskapsel for samtykke, analyserer få virkelig tallene og trekker ut handlingspunkter. Hvis du er i tvil, må du bare øke AdSpend. Heldigvis er det mange kunder som ikke vet at rangeringen i organiske søk i dag primært avhenger av tekniske parametere, brukersignaler og (fortsatt) tilbakekoblinger på grunn av et overflod av nettsteder som er like godt plassert hva gjelder innhold. Og med AI-tekstverktøy vil nettstedene snart heve seg kvalitetsmessig og i en aldri sett mengde, og snart vil vi kunne ønske mange nye nettsteder fra utlandet velkommen på vårt lokale språk i søkeresultatene, for AI-oversetterverktøy vil gjøre det stadig lettere å oversette nettbutikker, portaler, SAAS og andre nettsteder og angripe det digitale hjemmemarkedet. Vi må forberede oss på hard konkurranse. Det begynner nå …

Konklusjon om datastyrt nettsiderelansjekkliste

En datastyrt sjekkliste er en av de få effektive måtene å tvinge byråer til å gjøre et grundig arbeid. Det anbefales faktisk å gjøre oppnåelse av visse verdier i testverktøyene til godkjennelseskriterium. Det bør reguleres kontraktsmessig at en del av beløpet ikke kan faktureres før fire uker etter relanseringen, dersom alle viktige data er tilgjengelige og at beståelsen av toppverdiene bekreftes (som f.eks. Core Web Vitals og validerte produktsnutter etter Schema Markup i Search Console). Ved hjelp av denne arbeidsflyten - som beskrevet i dette innlegget - vil synlighetstapet ditt etter en relansering med store innholds-, strukturelle- og tekniske endringer være begrenset, og du legger grunnlaget for at Google snart vil rangere nettstedet ditt eller nettbutikken din høyere.

Hvis artikkelen var interessant for deg, må du gjerne sjekke ut flere av innholdene våre: