Relanceringstjekliste for onlinebutikker, booking- og virksomhedshjemmesider

Skal du til at relancere din hjemmeside? Tillykke med, at du har fundet denne artikel. De følgende udførelser kan muligvis være en afgørende faktor for dig, så din relancering lykkes, og du opnår et fantastisk resultat. For det sker ikke altid. Jeg er ejer af et bureau og vil afsløre præcist det, der sætter dig i stand til at tvinge typer som mig til at levere en ekstraordinært god arbejde og undgå typiske fejl i forbindelse med relanceringer. Men lad os starte helt forfra.

En hjemmesiderelancering er omdesign og revision af en eksisterende hjemmeside. Her kan både design, indhold og teknik ændres. Formålet med en hjemmesiderelancering er at forbedre hjemmesiden og tilpasse den til aktuelle krav.

Visse eksterne triggere får virksomheder til at erklære målet om "relancering": Den nyansatte medarbejder bringer fantastiske ideer med, en ny chef kommer og vil også gerne gøre digitalt rent, konkurrenten har en ny hjemmeside, eller omsætningen falder. Måske kan chefskones også ikke lide den gamle side, eller Generation Z synes ikke, at siden er "lit" nok. Du kender det måske. Selvom det er tid til en ny hjemmeside igen, ligesom personlige meninger ikke er grund nok til en relancering.

Der er dog nogle bedre grunde til, at virksomheder eller organisationer ønsker at gennemføre en hjemmesiderelancering. De væsentligste er:

• Udateret design og/eller rebranding: En forældet hjemmeside kan give indtryk af, at virksomheden ikke følger med tiden eller ikke længere er aktiv. Et frisk, moderne design skal derfor forbedre virksomhedens image. Selv hvis mærkeidentitet eller virksomhedens identitet ændrer sig, ønskes en relancering af hjemmesiden ofte for at afspejle den nye brandbesked.
• Bedre brugeroplevelse: Hvis brugervenligheden på en hjemmeside er dårlig, kan dette føre til en høj afvisningsfrekvens. En relancering kan derfor tjene til at forbedre brugeroplevelsen og gøre hjemmesiden nemmere at navigere.
• Mobiloptimering: Da flere og flere mennesker tilgår hjemmesider via mobile enheder, er det vigtigt at sikre, at hjemmesiden fungerer godt på forskellige skærmstørrelser og enheder.
• Søgemaskineoptimering (SEO): En forældet hjemmeside kan have problemer med SEO-ydelsen. En relancering giver mulighed for at foretage SEO-venlige ændringer for at forbedre synligheden i søgemaskinerne.
• Opdatering af indhold: Hvis informationer, tjenester eller produkter i en virksomhed ændres, skal hjemmesiden opdateres for at afspejle disse ændringer.
• Forbedringer af sikkerheden: Ældre hjemmesider er ofte mere sårbare over for sikkerhedsrisici. En relancering kan tjene til at forbedre hjemmesidens sikkerhed og beskytte den mod cyberangreb.
• Opdatering af teknologi: Brug af forældet teknologi kan påvirke ydelsen af en hjemmeside. En relancering kan give mulighed for at skifte til moderne webteknologier og platforme.
• Tilgængelighed for alle: Forbedring af tilgængeligheden er et vigtigt anliggende for mange hjemmesider, for at sikre, at de er tilgængelige for personer med handicap.
• Konkurrenceevne: For at holde trit med konkurrencen er det vigtigt at have en moderne og effektiv hjemmeside. En relancering kan bidrage til at opretholde eller forbedre konkurrenceevnen.
• Analysens forbedringer: Ved at implementere bedre analyseværktøjer og indsamle data kan virksomheder bedre forstå og optimere ydelsen af deres hjemmeside.
• Overensstemmelse med lovmæssige krav: Love og regler om datasikkerhed, tilgængelighed og sikkerhed ændres regelmæssigt. En relancering kan være nødvendig for at sikre, at hjemmesiden overholder disse krav.

Disse grunde kan opstå individuelt eller i kombination og variere afhængigt af virksomhedens mål og behov. En hjemmesiderelancering er ofte en strategisk beslutning for at forbedre online-tilstedeværelsen og opnå virksomhedens mål. Når du ser på punkterne ovenfor hver for sig, bliver det tydeligt, at de fleste grunde kan gennemføres med mindre sprint og slet ikke kræver en stor relancering.

Lad os derfor skelne mellem, hvad en relancering er, og hvad den ikke er: Et nyt design med den eksisterende tekniske base er mere en ansigtsløftning. Relanceringen sker først, når formålet med relanceringen indebærer en reel ændring i brugeroplevelsen, funktionaliteten og på den tekniske base.

En relancering bør altid begrundes ud fra fakta (f.eks. teknologien står i stampe og kan ikke opdateres længere), nøgletal samt måle- og sammenligningsdata.

Dette er mit første råd her på stedet, som jeg gerne vil give: Evolution før revolution! Undgå en relancering, så længe det er muligt, og forsøg at gennemføre alle punkter, der hidtil er blevet nævnt til en relancering, individuelt eller inkrementelt. Forbedr én ting, gå live med den, evaluér, hvad der sker, tilpas igen, eller gå videre til det næste punkt. Det bedste eksempel er Amazon, som virkelig kun ændrer og forbedrer minimalt og har undladt store relanceringstiltag i mange år.

En relancering udgør altid en stor risiko for din synlighed på Google. Alle har øje for forbedringerne, men få tænker på risikoen. Selvfølgelig bliver brugergrænsefladen bedre, den positive brugeroplevelse stiger, og teknisk er man igen up to date. Alligevel: Hvis din virksomhedssucces afhænger af stærk organisk synlighed, er en relancering det sidste middel, der kan anvendes, og kun bør besluttes, når din smerte er stor nok på grund af en kombination af de nævnte grunde, der ikke længere kan løses i separate sprints. Hvorfor? Se her, hvad der skete med online-synligheden efter relanceringerne af disse fire hjemmesider:

Planlæg din relancering omhyggeligt og sikre en succesfuld realisering med en tjekliste. Sæt dig især to mål: at bevare din online synlighed og finde muligheder under relanceringen for at skabe et fundament for en øget online synlighed. Det er netop derfor, denne artikel er her, for at give dig en relanceringsguide, så dine risici ved relanceringen holdes på et minimum, og du virkelig opnår et ekstraordinært godt arbejdsresultat med potentiale for bæredygtige, organiske SEO-successer.

Relanceringens køreplan

Planlægning af en hjemmeside-relancering bør udføres omhyggeligt. Det er vigtigt at overveje følgende trin:

• Analyse af den eksisterende hjemmeside og dokumentation af nulstillingspunktet: Start med at analysere den eksisterende hjemmeside for at identificere styrker og svagheder.
• Fastlæggelse af mål: Målene for hjemmeside-relanceringen bør defineres klart. Dette inkluderer forbedring af konverteringsraten, øget besøgstal eller skift til et nyt CMS med forbedret indholdsstyring og vedligeholdelse.
• Udvikling af et koncept: På baggrund af analysen, målene og en konkurrentanalyse, bør der udvikles et koncept for hjemmeside-relanceringen. Konceptet bør omfatte: Design, indhold, teknologi og SEO/markedsføring.
• Implementering: Konceptet bliver herefter implementeret. Dette inkluderer udviklingen af designet, oprettelse/tilpasning af indhold og implementeringen af tekniske ændringer.
• Test: Den nye hjemmeside bør testes grundigt inden offentliggørelse for at sikre, at den fungerer fejlfrit. Dette inkluderer også en defineret tjekliste.
• Offentliggørelse: Den nye hjemmeside bliver derefter offentliggjort. Og den bliver fortsat testet, evalueret og tilpasset live.

Fastlæggelse af mål og strategi for relanceringen

Præcisér hvilke mål relanceringen sigter mod. Mål kan være (udover de nævnte grunde): 

• Forbedring af brugeroplevelsen
• Forøgelse af overskueligheden
• Udvidelse af indholdsudbuddet
• Modernisering af designet
• Øgning af omsætning og gennemsnitlig ordreværdi 
• Skift til et andet CMS med lettere indholdsstyring og teknisk vedligeholdelse
• Fremadskuende lettere udvidelsesmuligheder og bevarelse af mulighed for opdateringer.

Forslag: Efter de første opstartsmøder i teamet som virksomhed - inden samtalerne med gennemførende bureauer går i gang - bør hver projektmedarbejder skrive målene for jeres relancering på en seddel eller indtaste dem i sit kommunikationsværktøj (f.eks. Slack). Når alle samtidig viser deres nævnte mål, vil du blive overrasket over, hvor forskellige meningerne er, selvom målene allerede var blevet drøftet mundtligt på møderne tidligere. Derfor er det vigtigt at fastholde målene skriftligt. Når du kender dine mål præcist, kan du allerede i en tidlig fase afprøve UI-prototypen for at se, om de er blevet indarbejdet konceptuelt.

Et kravspecifikation giver klarhed om relanceringsordren

Agenturet har brug for en omfattende projektbeskrivelse fra kunden for at kunne udarbejde et tilbud. Virksomheder har ofte et Word-dokument eller en PDF klar, hvor planerne er mere eller mindre detaljerede skitseret. Der er så spørgeskemaer eller der afholdes workshops, hvor agenturet bedre kan fremhæve kundens smertepunkter for at kunne afgive et tilbud. Ved større projekter udarbejdes der en kravspecifikation. Jo mere detaljeret, desto bedre. 

En kravspecifikation er et dokument, der spiller en afgørende rolle ved en hjemmeside-relancering. Det tjener til at nedskrive krav, mål og forventninger til relanceringen skriftligt. En veludarbejdet kravspecifikation hjælper med at sikre, at alle involverede - uanset om det er udviklingsteamet, designteamet eller kunden - har en klar forståelse af, hvad der skal opnås under relanceringen. Det er også udgangspunktet for et veldokumenteret og forpligtende tilbud fra det gennemførende bureau. Her er informationer og elementer, der normalt kan findes i en kravspecifikation til en hjemmeside-relancering:

• Mål og formål: En beskrivelse af hovedmålene for relanceringen, f.eks. forbedring af brugeroplevelsen, øget synlighed i søgemaskinerne eller skift af CMS med opdatering af designet.
• Projektomfang: En klar definition af, hvad der er inkluderet i relanceringen, og hvad der ikke er det. Dette kan omfatte antallet af sider, integration af tredjeparts værktøjer eller revision af indhold.
• Designkrav: Information om den ønskede visuelle udformning af hjemmesiden, herunder layouter og overholdelse af virksomhedens designretningslinjer for farver, skrifttyper og billeder.
• Funktionalitetskrav: En opdeling af ønskede funktioner og interaktioner på hjemmesiden, såsom kontaktformularer, søgefunktioner, e-handelsfunktioner osv.
• Tekniske krav: Specifikationer for de teknologier, der skal anvendes under relanceringen, f.eks. valg af et content management system (CMS) eller implementering af visse funktioner. Ligeledes inkluderer det brugen af moderne billede- og grafikformater (WebP, AVIF, SVG).
• Manuelle og automatiske sikkerhedskopierings- og revisionsprocedurer af indholdsredigeringer.
• Indholdskrav: Klare retningslinjer for revision, opdatering eller oprettelse af indhold, herunder tekst, billeder, videoer og andre medier. Håndtering af metadata og strukturerede data.
• SEO-krav: mere om dette i næste sektion.
• Tidsplan og milepæle: En tidsplan, der fastlægger de planlagte start- og slutdatoer for relanceringen samt vigtige milepæle.
• Budget: Oplysninger om budgettet til relanceringen, herunder omkostninger til design, udvikling, hosting og eventuelle tredjeparts tjenester.
• Kvalitetssikring med testværktøjer: Beskrivelse af test og kvalitetskontrolprocedurer, der skal udføres under relanceringen for at sikre, at hjemmesiden fungerer fejlfrit.
• Vedligeholdelses- og supportkrav: Krav til løbende vedligeholdelse og support af hjemmesiden efter relanceringen.

En godt struktureret kravspecifikation er afgørende for at undgå misforståelser, styre projektet effektivt og sikre, at alle interessenters forventninger opfyldes. Det fungerer som retningslinje og reference-dokument for hele projektteamet og bidrager til at sikre succesen med hjemmeside-genstarten. 

Da vi planlagde genstarten af TutKit.com med en komplet skift fra CodIgniter til Laravel-frameworket, indeholdt vores kravspecifikation 220 sider - (ikke) et fristende udsyn for et bureau at komme igennem.

Bemærk: Koncept, design, funktion og anvendt teknologi behandles ikke detaljeret i min artikel. Den nye hjemmeside vil helt sikkert være smuk. Den største fare ved genstarten ligger faktisk i en forringelse af den tekniske brugeroplevelse og OnPage-kvaliteten på grund af manglende 301-redirects m.m., hvilket kan føre til et tab af placering og synlighed. For at forhindre dette, vil der især blive fokuseret på at sikre projektets succes set fra brugeroplevelses- og SEO-perspektiv.

Definition af SEO-kravene til den nye hjemmeside

Kundens briefing eller en mere omfattende kravspecifikation regulerer allerede, hvad der ønskes i form af design, indhold, funktionalitet og teknologi, og danner grundlag for, at et bureau kan udarbejde en kalkulation.

For Genstarts-Kontrollisten til sikring af projektsuccessen skal der ses på de enkelte passager fra et SEO-perspektiv. Der opstår specifikke SEO-krav gennem f.eks.:

• en ændring af URL-strukturen (URL Redirect Map!) og ændrede linkstier
• en ændring af navigationen (vigtigt på grund af intern linkning og linkhierarki)
• ændrede teknologier (CMS, JavaScript-framework, server, …)
• ændrede indhold (potentielt tab af synlighed for sider, der rangerer godt)

Sider rangerer godt på Google på grund af deres indholdsmæssige relevans, derfor er det vigtigt at spørge, om eksisterende indhold ændres eller slås sammen, om indhold fjernes eller tilføjes? Ændres den indholdsmæssige struktur af kategorier eller sider? Fra disse punkter skal der udledes SEO-krav, der skal medtages i genstartskontrollisten.

Bliver metadata fra de gamle indhold også overført, og ændrer de sig? Hvordan udføres indholdsplejen af redaktøren, og er sidernes indhold knyttet til strukturerede data?

Bliver de eksisterende eller nye billeder gemt i moderne billedformater til hjemmesider (WebP/Avif), og bliver der lagt vægt på billed-SEO med talende URLs med små bogstaver, så i stedet for 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Det bør også sikres, at billedfiler er knyttet til strukturerede data (ImageObject) og <meta>-thumbnails sendes til Google for at øge sandsynligheden for, at billedet integreres i søgeresultaterne og vises på Google Billeder.

I denne sammenhæng er det også interessant at overveje, hvordan brugersignaler kan forbedres. Så på indholdssider kunne der indlejres billedvideoer, forklarende videoer og hjælpevideoer. Hvis en bruger, der kommer fra Google til landingssiden, klikker på videoen og ser den, øges opholdstiden (godt brugersignal), og tilbagevenden til SERP-raten forbedres ligeledes (godt brugersignal). 

Det bør også undersøges, hvordan indholdsektioner integreres på siderne, der lever op til Googles krav til Hjælpsomt Indhold og til E-A-T-princippet.

For Google er "Hjælpsomt Indhold" indhold, der er relevant og nyttigt for brugerne. Det besvarer brugernes spørgsmål omfattende og informativt, tilbyder løsninger på problemer og giver en merværdi, der er ud over blot reklamebeskeder.

Her er nogle eksempler på hjælpsomt indhold:

• Guides og vejledninger: Dette indhold hjælper brugerne med at lære nye opgaver eller løse eksisterende problemer.
• Anmeldelser og sammenligninger: Dette indhold hjælper brugerne med at træffe valg af det rigtige produkt eller den rette service.
• Nyheder og opdateringer: Dette indhold holder brugerne informeret om aktuelle begivenheder og trends.
• Infografikker og diagrammer: Dette indhold kan hjælpe med at visualisere komplekse data og informationer.
• Blogindlæg og artikler: Dette indhold giver et dybere indblik i et bestemt emne.

Google bruger forskellige signaler til at genkende hjælpsomt indhold. Dette inkluderer bl.a.:

• Brugeradfærd: Google observerer, hvordan brugerne interagerer med indhold, f.eks. hvor længe de bliver på en side, hvor ofte de deler den, og hvor ofte de bedømmer den.
• Kvalitetssignaler: Google vurderer kvaliteten af indhold ud fra faktorer som relevans, fuldstændighed og aktualitet.
• Feedback fra brugere: Google tager også højde for brugerfeedback, f.eks. vurderinger og kommentarer.
• Ved at tage højde for disse signaler kan webstedsadministratorer øge chancerne for, at deres indhold bliver betragtet som hjælpsomt.

EEAT-princippet er en koncept udviklet af Google, der evaluerer kvaliteten af hjemmesider og webindhold. Det står for Ekspertise, Oplevelse, Autoritet og Tillid, også Ekspertise, Erfaring, Autoritet og Tillidsværdighed.

• Ekspertise henviser til viden og erfaring hos personerne, der skaber indholdet. Google vurderer ekspertisen ud fra faktorer som uddannelse, erhvervserfaring og udmærkelser.
• Oplevelse bekræftes, når indholdet også er udviklet med en vis erfaring, f.eks. baseret på den faktiske brug af et produkt, besøg på et sted eller beskrivelse af oplevet af en person.
• Autoritet refererer til omdømme og ry af en hjemmeside eller webindhold. Google vurderer autoriteten ud fra faktorer som backlinks, aktivitet på sociale medier og brugerevalueringer.
• Tillid refererer til pålidelighed og troværdighed af en hjemmeside eller webindhold. Google vurderer tilliden ud fra faktorer som privatliv, sikkerhed og gennemsigtighed.

Hvilke SEO-krav har eksisterende og nye funktioner vedrørende frontend og backend? Her handler det om for eksempel:

• Indekserbarhed (relevant indhold skal også være synligt og indekserbart uden JavaScript)
• Tydelighed om formålet med hjemmesiden og klarhed omkring call-to-action (det ønskede adfærd fra målkunden på siderne)
• Undgåelse af duplikeret indhold f.eks. gennem automatiserede kategoriesider eller sidenkopier af variationsartikler
• Sikring af en høj PageSpeed ved at undgå for mange JavaScript- og CSS-filer, bruge moderne billedeformater (WebP/AVIF)

Disse SEO-krav bør inkluderes i projektbeskrivelsen eller kravspecifikationen, men bør også indgå via en checkliste relateret til testværktøjer eller som en IST-SOLL-sammenligning i kvalitetssikringen af projektet samt yderligere som en acceptkriterium for agenturprestationen. Mere om dette nedenfor.

Afklaring af interne og eksterne projektdeltagere

Bestem projektdeltagerne - her set fra kundens eller hjemmesideindehavers perspektiv:

• Hvem er ansvarlig for projektledelse og træffer de endelige beslutninger?
• Hvem er ansvarlig for koordinering og kommunikation med agenturet eller kunden?
• Hvem står for intern projektledelse?
• Hvem forbereder internt indhold og assistance til agenturet?
• Hvem implementerer brugeroplevelsesdesignet?
• Hvem står for udviklingen?
• Hvem rapporterer fra agenturet til kunden med fastsatte intervaller?
• Hvem tager sig af testning og kvalitetssikring fra agentur- eller kundesiden?
• Bliver der tilkaldt en ekstern konsulent (f.eks. for SEO eller juridiske krav)?
• Hvem godkender opgaverne? Hvem afslutter opgaverne i billetsystemet efter udførelsen?
• Hvem skal informeres på hvilket tidspunkt (medarbejdere, kunder, partnere, reklamekampagneadministratorer, ...)?

Ved valg af eksterne projektpartnere er fire punkter essentielle

1. Har agenturet realiseret et eller flere projekter af denne art tidligere? Findes der referencer? Findes der kundeudsagn, og ville et feedbackmøde med kunder hos agenturet være muligt - hvilket er anbefalelsesværdigt ved større individualiserede udviklinger?
   
2. Opfylder tilbuddet og den tekniske implementering (CMS/Shopsystem/Framework) allerede alle krav, der er relateret til relanceringen? Er der individuelle funktioner eller krav, som stadig skal programmeres (også via plugin eller moduler)? Er der tjenester i tilbuddet, der er udeladt eller reserveret til senere, men som er afgørende for projektsuccesen? Det er vigtigt, at der ikke kommer nye problemer til, der er større end årsagen til relanceringen.
   
3. Passer det udførende agentur eller leverandør både med hensyn til teamets størrelse, den regionale placering og medarbejderfluktuationen (evt. identificeret via Kununu-evalueringer) også bæredygtigt til virksomheden for yderligere support?
   
4. Er der mulighed for direkte kontakt til det udførende designteam og udviklingsteamet? Det er fornuftigt at møde det faktiske team hos agenturet. De glade og de storslåede salgsfolk får kontrakten og er senere ikke længere ansvarlige. Derfor bør der også aftales direkte kontakt med det udførende team.

Fire tips til din egen beskyttelse i denne forbindelse

1. Som kunde bør du være opmærksom på det teknologivalg, som agenturet anvender. Det, der står i tilbuddet, kan du prøve at google “CMS + ulemper” eller “CMS + erfaringer”. Du bør vide, hvad du præcist går ind til. Det er en fornuftigt at satse på Open Source-løsninger. Jeg er klar over, at det ikke altid er muligt. Det er bedst at sikre sig, at der er et stort udviklerfællesskab for den anvendte teknologi, så du ikke ender med at have en agenturejet løsning, som kun dit agentur kan håndtere, hvilket senere kan placere dig i en vanskelig situation.
   
2. Sørg også for at du får ubegrænsede rettigheder til brug og redigering af agenturleverancen, så du altid har ret til at kunne videreudvikle hjemmesiden internt eller eksternt. En sådan klausul bør indgå i kontrakten.
   
3. Hvis din virksomhed er teknisk afstemt og har systemadministratorer, softwareudviklere eller lignende i teamet, er det fornuftigt selv at oprette GIT til versionsstyring og JIRA (eller et lignende værktøj) til projektstyring eller billetsystem i din egen konto. Så giver I agenturet fulde adgangsrettigheder, og arbejdet kan starte. Jo større et projekt er, desto mere tøft og smertefuldt kan det blive. Det er godt at have kontrol over de afgørende adgange og konti. Jeg er dog klar over, at denne anbefaling rent fagligt set kun kan følges af få kunder.
   
4. Nogle gange tilbyder agenturer direkte hosting til kunderne. Vi er ikke fans af dette, da det både øger afhængigheden i kundeforholdet og fordi vi mener, at webhostingsselskaber er de bedste til webhosting, da det er deres ekspertise. Vi har selv tidligere opsat og administreret servere og brugt masser af ressourcer. Nu kører vores systemer på skyservere fra en af de store webhostere i Tyskland, og vi er tilfredse. Ved webhosting skal du sørge for, at der allerede er serverbaserede backupper inkluderet i pakken, som kan gendannes med få klik.

Fastlæggelse af tidsramme og lanceringstermin

En relancering gennemføres i flere projektspurter. Disse kan ifølge vores agenturerfaring være:

• Nuværende tilstand protokoleres (via testværktøjer, men også skriftligt med indtryk af, hvad der fungerer godt fra kundesiden, og hvor der er behov for forbedringer)
• Forskningsfase med konkurrenceanalyse og søgning efter løsninger/inspiration
• Wireframe koncept
• Design af brugergrænsefladedesign
• Frontend- og backend-udvikling
• Migration af data eller indholdsimport (automatisk/manuelt)
• Strukturelle og indholdsmæssige indholdsforbedringer (tekst og billede) & SEO-spor

Projektspurter overlapper, da nye projektdeltagere bliver aktive i løbet af bearbejdningen.

Det er vigtigt at definere den tidsramme for individuelle projektspurter og afstemme med de involverede. 

Opretter agenturet en egen Slack-kanal til hurtigere kommunikation for kunden til projektet, hvis det er større?

Et tip på dette tidspunkt: Det er godt, hvis agenturet allerede arbejder med klikbare prototyper i en meget tidlig fase, så det vil sige allerede under wireframekonceptet og især ved præsentationen og testningen af brugergrænsefladedesignet. På den måde får kunderne en bedre fornemmelse af oplevelsen på hjemmesiden. Enkle JPG- eller PNG-filer som layoutforslag er ikke længere tidssvarende. Det skal være klikbare prototyper, der udarbejdes med Sketch, Figma, Adobe XD eller et andet professionelt værktøj.

Ændringer er lette at implementere på dette tidlige stadie. Når funktioner og sektioner på en hjemmeside allerede er udviklet, bliver ændringer meget mere tidskrævende og kan føre til efterforhandling, hvilket absolut ikke er attraktivt.

Her kan man se, hvordan en sådan prototype for det mobile brugergrænsefladedesign med klikstier ser ud i et overblik:

Det skal afklares, fra hvilket tidspunkt løbende tests fra kundesiden er mulige. Udviklere bør teste deres lokale arbejde selv efter sammensmeltning til stage-systemet. Det lyder banalt, men enhver, der samarbejder med udviklere, vil straks forstå, hvad jeg mener. Herefter skal den, der er ansvarlig for agenturets kvalitetssikring, teste billetten eller funktionen. Først derefter frigives billetten til kundetest. Kunden bør aldrig føle sig som alfa-tester, men finde et system, der allerede er testet af fire øjne. Agenturet er alfa-tester, kunden er beta-tester! Er der overhovedet adgang til agenturets billetsystem?

Det bør også skriftligt defineres, at agenturrapporter til kunden skal sendes med en bestemt frekvens. For eksempel kunne der sendes en rapport via e-mail hver fredag om den aktuelle status, nødvendige tilbagemeldingsløkker eller hjælp anmodninger. Dette er også et tip fra vores agenturefaring: Det er godt ikke at forlade kunden i uvished inden weekenden. Det vil kun føre til dårlige idéer. Det er bedre at informere godt om, hvad der er sket, og hvad der står foran i den følgende uge. Gennemsigtighed hjælper alle med at forblive positivt engageret i sagen.

Launchdatoen bør også fastlægges. Ifølge Parkinsons lov udvider arbejde sig til at udfylde den tilgængelige tid til udførelse. Med andre ord, jo mere tid der er til rådighed for udførelse af en opgave, desto mere tid vil blive brugt, uanset den faktiske kompleksitet eller arbejdsindsats. Den planlagte færdiggørelse skal også inkluderes i aftalen. Overholdes datoen ikke, kan der endda være en kontraktsstraf i kontrakten. Som retningslinje gælder det, at kontraktsstraffe på 0,2 % af ordrebeløbet pr. arbejdsdag i forsinkelsen og maksimalt 5 % af ordrebeløbet er effektive. Kontraktsstraffen behøver ikke nødvendigvis gøres gældende over for kunden, men giver dig mulighed for at få agenturet til at imødekomme nogle ekstra ønsker som kompensation.

Vigtigt: Ingen lancering på en fredag. Heller ikke mellem helligdage eller i virksomhedens hovedforretningstid. Vi anbefaler faktisk ved store relanceringer nattetimerne fra søndag til mandag, især hvis IP-adressen ændres, så DNS-indstillingerne stadig opdateres hos de fleste udbydere mandag, ofte allerede sent mandag formiddag, hvis DNS-posten blev justeret om natten. Der er faktisk stadig 4,5 arbejdsdage til live-testning og fejlrettelser, hvis der opstår fejl.

Protokol af dit websteds nuværende tilstand

Status quo skal registreres før arbejdet påbegyndes. I den nuværende tilstand registreres, hvordan de tekniske måleresultater er for parametrene. Til højre kan du indtaste målværdierne:

I listen finder du som SEO-værktøj det af os ofte anvendte Seobility til check af OnPage-faktorer, et for eksempel SEO-træning, som jeg også har offentliggjort. Der er mange tilsvarende værktøjer som Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog osv. Med SEO-værktøjet handler det især om at identificere og rette de typiske OnPage-fejl. Her fokuserer Seobility på de tre kerneområder: Teknologi & Meta, Struktur og Indhold. Du finder det på lignende vis hos de andre SEO-værktøjer. Det er vigtigt, at der altid udføres en fuld gennemgang, så ALLE sider crawles og ikke kun startsiden, og dels at du angiver en score eller fejlrate for den aktuelle tilstand og den målsatte værdi, der bør opnås efter optimering. Hos Seobility er en værdi på 90 eller højere ønskværdig. Ligeledes finder du også alternative værktøjer til andre formål. Det afgørende er, at der overhovedet anvendes et værktøj for at sikre fremragende data.

Dette er eksempelvis vores aktuelle værdi for OnPage-kvalitet:

Usersignalerne kan statistisk registreres med målinger fra Google Analytics 4, f.eks. brugerflugt, sider/bruger, tid brugt osv. Hvis Google Analytics eller et andet analyseværktøj bruges i overensstemmelse med databeskyttelsesreglerne, bør disse data også tages i betragtning ved registreringen af den aktuelle tilstand. 

Der bør også oprettes en backlink-liste, som f.eks. gratis kan genereres her: https://www.seobility.net/de/backlinkcheck/

Derudover skal den gamle sitemap.xml sikres, ligesom der skal tages full-backup af siden. Alle relevante sider bør også overføres som en liste til et Google Sheet, som danner udgangspunkt for URL-redirect-map. En sådan CSV-liste kan let eksporteres gennem et SEO-værktøj som Seobility. I URL-redirect-mappen er alle relevante sider og tilknyttede sider via eksterne backlinks (se backlinklisten) taget i betragtning, som senere skal omdirigeres på grund af ændrede sidens URL'er. Fjernede URL'er skal omdirigere til de nye, tilsvarende gamle URL'er. Det er vigtigt at forhindre omdirigeringskæder! De gamle, eksisterende omdirigeringer skal direkte omdirigere til den nye slut-URL. Ligeledes skal der tages hensyn til PDF-filer og billeder, hvor der findes links, så de også omdirigeres korrekt og ikke ender som en 404-forbindelse.

Omdirigeringerne oprettes som 301-omdirigeringer baseret på URL-redirect-mappen i .htaccess, via omdirigeringskort via Vhost-konfiguration eller en database-løsning. Kunden bør kunne vedligeholde disse selv. Det er også vigtigt at sikre, at omdirigeringerne er permanente.

Det anbefales også at sikre hver side med en fuld side-skærmdump. Det er dels en sikring af den gamle beholdning, hvis der opstår spørgsmål efter lanceringen, om indholdstyper ikke blev overført osv.

På baggrund af de eksisterende sider, funktioner og indhold og baseret på måleresultaterne kan der identificeres, hvad der allerede fungerer godt, og hvad der identificeres som et område, hvor der er potentiale for optimering, som skal forbedres gennem relanceringen.

Checkliste: Før relancering

Så snart brugergrænsefladedesignet er godkendt, og bureauet arbejder i udviklingssprint, bliver følgende checkliste relevant, som kronologisk frem til relanceringsdagen opregner de væsentlige punkter:

1. Dev-miljøet med adgang til alle interessenter er tilgængeligt til test
2. Dev-miljøet kører på noindex
3. Tilgængelighed for testværktøjer på Dev-miljøet (IP-fritagelse eller http-login) er konfigureret
4. Dev-miljøets konfiguration svarer helst til live-systemets konfiguration
5. Dev-miljøets sidesstruktur svarer til den senere live-sides struktur
6. Dataoverførslen af gammeldata er afsluttet
7. Indholdstilpasninger er foretaget
8. Billede-SEO er implementeret
9. 301-omdirigeringer baseret på URL-redirect-mappen er oprettet 
10. OnPage-check med Seobility er foretaget, fejl er rettet, målværdier er nået
11. Open-Graph-data er valide
12. Strukturerede data er valide
13. Pagespeed-test for alle sidetyper er gennemført, målværdier er nået
14. Content-Cookie-Policy fungerer
15. Sikkerhedshoveder er implementeret
16. Tilgængeligheden er god, målværdier er nået
17. Hreflang er valide (på flersprogede sider)
18. Juridiske tekster (vilkår, imprint, fortrydelseserklæring, databeskyttelse) er opdaterede, GDPR-konformitet foreligger
19. Opdatering af CMS, frameworks, anvendte plugins og moduler til den nyeste version er foretaget
20. Endelig browser- og enhedsoversigtsfunktionstest viste ingen fejl
21. Endelig status og lanceringstidspunkt er angivet 
22. Full-backup er oprettet

Brugen af strukturerede data (Schema-Markup), jf. punkt 12 på listen, tages stadig alt for lidt hensyn til. Bliv fortrolig med emnet og læs, hvad Google siger om markeringen for strukturerede data i Google-søgningen. Google vil i stigende grad vægte valide data hårdere i SGE, dvs. søgeresultaterne oprettet af AI. Også på grund af Googles Helpful Content-opdatering skal indhold i højere grad verificeres gennem ekspertise, erfaring, autoritet og troværdighed. Strukturerede data er en del af løsningen på at forenkle denne validering for Google. Efter implementering af strukturerede data skal du bruge Schema-Markup-Validator, men tjek også dine sider med Structured Data Linter, som også anbefales og linkes af Google i PageSpeed Insights. Her får du mere omfattende oplysninger om kodefejl i forbindelse med anvendelsen af strukturerede data.

Ved punkt 16 dukker "Tilgængelighed" nu for første gang op i denne artikel. Allerede i PageSpeed Insights har tilgængelighed sit eget område, og grønne tal ønskes der. Testen, om en side er tilgængelig eller ej, bør så udføres ud over PageSpeed Insights, også via https://www.accessibilitychecker.org og/eller https://wave.webaim.org. Især når en relancering er forestående, bør dette punkt obligatorisk tages i betragtning, da det med tilgængelighedsloven for hjemmesider fra 2025 alligevel bliver aktuelt. Test med et sådant værktøj ikke kun forsiden, men alle sidelayouts - det samme gælder for PageSpeed-tests!

I forbindelse med en relancering opstår der også ofte tilpasninger og "opdateringer af juridiske tekster". Det er vigtigt at tænke på dette i god tid, og teksterne bør eventuelt leveres af en specialistadvokat eller via juridiske generatorer. Der bør også tænkes på databehandlingsaftaler, hvis f.eks. en ny webhost bruges, eller hvis nyhedsbrevsservicen ændres. 

Punkt 18 med opdateringen af CMS, anvendte JavaScript-biblioteker, installerede moduler og plugins bliver lige så undervurderet som vigtigt. En relancering kan trække ud over flere måneder og længere. På WordPress-systemet er det nemt at se, om der allerede er mange opdateringer tilgængelige før relanceringen. Kunder bør sikre sig, at de nyeste versioner anvendes ved lanceringen.  

Ved "ændringer af eksterne tjenester" kommer der yderligere opgaver til, som også bør nævnes på tjeklisten, f.eks. ved ændring af nyhedsbrevsservicen: 

• Dataimport af nyhedsbrevskontaktoplysninger til nyhedsbrevstjenesten
• Integration af nyhedsbrevstjenesten på hjemmesiden på tilmeldingssiden
• Databehandlingsaftale
• Oprettelse af nye mailskabeloner
• og så videre 

I hele udviklingsforløbet udføres selvfølgelig løbende tests af funktionerne osv. Det er fornuftigt at lave en meget detaljeret tjekliste til testene, så der ikke glemmes noget. Det er ikke tilstrækkeligt, at både det udførende bureau og kunden bare klikker lidt rundt. Efter vores relancering af TutKit.com havde vores godkendelsestjekliste sikkert 1.000 linjer. Og sådan gør vi det stadig: efter vigtige større opdateringer gennemgår vi ca. 70 interaktioner via tjekliste for Chrome, Safari og Android.

Tjekliste: Relancering-dagen og dagene efter

Relancering-dagen er kommet, og det er hverken en fredag eller en dag mellem helligdagene. Den nye hjemmeside går live, DNS-indstillingerne er tilpasset. Nu er det tid til at starte forfra med at kontrollere og evaluere alt. Gennemgå følgende: 

1. tjekke robots.txt, at robotter ikke er blokeret 
2. Live-miljøet kører på index, follow.  
3. Canonical-tags er korrekt indstillet
4. Kontroller sidekoden for absolutte stier (linkstier fra testmiljøet på livesiden)
5. Omdirigering fra http til https med/uden www til destinationsiden på startsiden og undersider fungerer
6. Test omdirigeringer via URL-redirect-kort, samt for eksistensen af omdirigeringskæder
7. OnPage-kontrol af livesiden med Seobility for teknik & meta, struktur og indhold … især kontrollér de Noindex-sider, der genereres via Seobility
8. Open-Graph-data er gyldige
9. Strukturerede data er gyldige
10. Kontrol af Pagespeed for alle sidetyper er udført, målværdierne er nået
11. Cookie-politik med samtykke-cookieværktøj fungerer, som det skal
12. Sikkerhedshoveder er konfigureret
13. Tilgængelighed er til stede
14. Kontrollér Hreflang ved flersprogede hjemmesider (https://app.sistrix.com/de/hreflang-validator)
15. Endelig browser- og enhedsovergribende funktionskontrol har ikke afsløret fejl
16. Indsend ny sitemap.xml via Google Search Console
17. Ajourfør nye destinationsider på Google Ads-kampagner
18. Ved visse domæneændringer skal der også tænkes på links i sociale medier, e-mailsignaturer osv.

Vi bruger i vores udviklingsmiljø Mailhog til at teste e-mails lokalt. I sådanne tilfælde er det vigtigt, at de korrekte SMTP-data for "E-mailmodtagelse i live-systemet" er indtastet, så e-mailsene også kommer frem, hvor de skal.

Ligeledes er det vigtigt at sikre, at der i udviklingssystemet er implementeret "sandbox" hos betalingsudbydere som PayPal, mens den korrekte forbindelse naturligvis skal etableres i live-systemet.

I dagene efter gælder det især om at følge Google Search Console. Det mest interessante er selvfølgelig, hvordan dine placeringer ændrer sig. Fokuser især på uventede ændringer og fejlmeddelelser:

1. Crawling: Værtstatus ... Hentning af robots.txt, DNS-opløsning, Serverforbindelse
2. Crawling-statistik ... Forespørgsler, Downloadstørrelse, gennemsnitlig responstid
3. Klik på i SERP'er
4. Impressioner i SERP'er
5. Gennemsnitlig CTR i SERP'er
6. Gennemsnitlig SERP-position
7. Beståelse af Core Web Vitals

Først og fremmest advarer Google Search Console dig om fejl som f.eks. URL-fejl, Href-Lang-fejl, sideindeksering med spredt indexeret/ikke indexet. Hvis en side ikke er indexeret, skal der være en grund til det (omdirigering, noindex)...). Der kan du også se dupliceret indhold eller andre problemer. Hvis Search Console rapporterer fejl med strukturerede data eller Core Web Vitals, bør du undersøge det nærmere. Først gennem live-data vil du f.eks. opdage, at dine sider, på trods af en høj PageSpeed, kan have problemer med Core Web Vitals på grund af f.eks. CLS-fejl. Her kan du se tydeligt, hvilke ændringer der er mulige på dit websted:

Du kan straks få vist de dårlige URL'er eller dem, der skal optimeres. Tag en URL, og lav en PageSpeed-test af den ved hjælp af PageSpeed Insights. Her vil du modtage henvisninger til, hvorfor Core Web Vitals ikke opfyldes, og hvad du kan gøre for at rette fejlene. Klik på den lille pil nedad for yderligere oplysninger. Disse anbefalinger kan normalt kun implementeres af udviklere. Det er dog vigtigt, at du er i stand til at identificere problemerne for at kunne tackle dem med din agentur.

Evaluer også dine data fra dine analyseværktøjer, f.eks. Google Analytics 4. Hold også øje med måleindikatorerne, som du kan indsamle systematisk, f.eks. reservationer, konverteringsrate, indkøbskurvens størrelse, køb/salg pr. dag, antal tilmeldinger til nyhedsbrevet, kontaktforspørgsler, downloads af bestemt indhold eller antal visninger på videoer.

Crawling-statistikkerne i Google Search Console er afgørende for kontrollerne i de følgende dage. Du finder dem via indstillingerne til venstre i menuen. Der bør være mere crawl-aktivitet synlig. Hvis ikke, er der crawl-fejl til stede?

Værtstatus viser dig straks fejl, f.eks. som det ses her efter en relancering, hvor crawling-forespørgsler til robots.txt mislykkedes, og hvor serverforbindelsen også gentagne gange blev afbrudt:

Det er også interessant, hvad crawling-statistikken viser. Efter en relancering sker der normalt en stigning i crawling-forespørgslerne. Her kan du også se, om der stadig er 404-sider, som bliver crawlet. Hvis nogle af dem ikke passer ind, så drøft dem med udviklerne.

Du kan se, om din server, din PageSpeed og din kode er relativt gode, hvis din side-responstid er under 400. Jo tættere den kommer på 1000 ms, jo mere anbefalelsesværdig er en PageSpeed-optimering, f.eks. ved at reducere databaseforespørgsler og forstærke serverkapaciteten (f.eks. mere CPU-kraft, opdatering til den nyeste serversoftware, skift til HTTP2 eller HTTP3 (ved brug af Nginx)).

Perspektivisk vil crawl-budgettet for enkelte websteder sandsynligvis blive begrænset på grund af det stigende antal (KI-)indhold på websteder, hvorfor en god værdi for sidenes responstid bør sigtes efter, så bots kan crawl så meget som muligt på dine sider inden for den tilgængelige tid.

Relanceringscheckliste til download

De indlejrede checklister til relancering er også tilgængelige som en PDF-fil til download her. Hent dem og sikre dig projektsucces!

Bekendelser fra en agenturejer

Seo-kravene i checklisten kunne også have detaljerede instruktioner, f.eks. om at overholde overskriftsstrukturen fra H1 til H6 og så videre. Fastlæggelse af målværdier i testværktøjerne forkorter heldigvis hele relanceringchecklisten indholdsmæssigt, da opnåelse af topværdierne i testværktøjerne kun kan opnås gennem overholdelse af ren kode, brugen af moderne teknologi, overholdelse af SEO-OnPage-faktorer osv. Ellers ville de nyeste webstandarder og tekniske samt SEO-krav skulle formuleres yderst detaljeret i kravspecifikationen, hvilket kunderne slet ikke fagligt er i stand til. Hvis agenturer skal opnå høje værdier i testværktøjerne, har de intet andet valg end at arbejde efter Best-Practice - også en ny erfaring for agenturer :-)

Det er tid til en bekendelse. Definitionen af SEO-kravene samt den checklistebaserede tilgang med sikringen og opnåelsen af målværdier i forskellige testværktøjer repræsenterer et ideal, som sjældent findes i virkeligheden. Det afhænger af:

• kundens budgetbegrænsninger
• agenturs profitoptimeringsinteresser
• begrænsninger på grund af de anvendte teknologier
• og desværre også: uvidenhed og inkompetence på begge sider

Jeg kan ikke bebrejde kunden. De leder jo netop efter professionel hjælp, og næsten enhver digital agentur skriver på deres hjemmeside og i deres White Papers, at søgemaskineoptimering er en af deres kernekompetencer. Der er altid også referencer, der viser, at synligheden online er steget med faktor 3, 5 eller 10 efter en relancering. Men at gå fra 10 besøgende om dagen til 100 er en stigning på 1000 procent, men det er stadig ikke nødvendigvis en succes. Mange søgemaskinesuccesser skyldes, at konkurrenterne digitalt set er markant svagere.

Agenturer fortsætter med at udføre middelmådig arbejde med forældede metoder, fordi de stadig ikke bruger moderne værktøjer til kvalitetssikring, selvom de praler af deres SEO-ekspertise i deres indlæg, referencer, best practices osv. Måske er sådanne agenturer videnskæmper, men også udførelsesdværge. Det lyder hårdt, men det er blot reglen. Helt ærligt. Se nærmere på det! Tag ovenstående tjekliste og indtast den bedste agentur fra dit område, deres URL i de nævnte værktøjer. Og tag så det nyeste website-referencen, du kan finde fra agenturet, og gentag processen. Hvilke resultater vil du se? Netop dem, du kan forvente i et samarbejde. Du kan også teste vores egne referencer på samme måde og se, at selv i vores kunde projekter opnår vi ikke altid topresultater. Denne workflow med fokus på data-drevet kvalitetssikring er også vokset hos os projekt for projekt og har især etableret sig gennem vores arbejde på TutKit.com. 

Disse undersøgelser kan udføres med næsten enhver agentur, fordi kun få arbejder virkelig data-drevet med kvalitetssikring, fordi ingen har egne projekter på markedet i årevis og er nødt til at måle sig med internationale spillere i den hårde konkurrence om online synlighed, og fordi det er ligegyldigt for agenturerne, om et projekt lykkes eller ej, så længe agentur regningen betales, og kunderne kan fejre de flotte (men kvalitativt middelmådige) hjemmesider i deres indlæg og med priser. Den særlige ironi i dette er, at ofte klarer netop SEO-agenturerne sig dårligst i testværktøjerne med deres egne hjemmesider, da de ofte kun har én metode til rådighed ... en indholdspakke til hjemmesiden baseret på kundens søgeord. Der mangler ofte kompetente udviklere til de andre tekniske krav.

Det er også en fordel, hvis agenturet er et andet sted, og man ikke løber ind i kunden under indkøb i byggemarkedet som ansvarlig medarbejder for agenturet, der har ansvaret for et synlighedsfald i to-cifret procent efter relanceringen. Men disse synlighedsfald tjekker kunderne næsten aldrig, for selvom de alle har en cookie-samtykkeboks, analyserer få virkelig tallene og udleder handlingsplaner. I tvivlstilfælde er det bare at øge annonceudgifterne. Heldigvis ved kunderne heller ikke, at dagens organiske rangering i høj grad afhænger af tekniske parametre, bruger signaler og (stadig) backlinks på grund af det overflod af indholdsmæssigt stærkt opstillende hjemmesider fra et teknisk synspunkt, som kunderne heldigvis heller ikke er klar over. Og med AI tekstværktøjer vil hjemmesiderne snart opgraderes indholdsmæssigt i en aldrig set mængde og kvalitet, og vi vil snart kunne byde mange nye hjemmesider fra udlandet velkommen til vores sprog i SERPerne, for takket være AI oversættelsesværktøjer bliver det stadig nemmere at oversætte online butikker, portaler, SAAS og andre hjemmesider og angribe det digitale hjemmemarked. Vi skal forberede os på hård konkurrence. Det begynder nu …

Konklusion om den data-drevne hjemmeside-relanceringstjekliste

En sådan data-drevet tjekliste er en af de få effektive måder at tvinge agenturer til at udføre godt arbejde. Det anbefales endda at gøre opnåelsen af bestemt værdier i testværktøjerne til et acceptkriterie. Det bør være aftalt kontrakten, at en del af betalingen kun må faktureres fire uger efter relanceringen, hvis alle de vigtige data er tilgængelige, og at de høje værdier bekræftes (såsom Core Web Vitals og de validerede produktsnitser efter skema-markeringen i søgekonsollen). Ved hjælp af denne arbejdsgang - som beskrevet i dette indlæg - vil dit synlighedstab efter en relancering med kraftige indholdsmæssige, strukturelle og tekniske ændringer forblive begrænset, og du vil skabe grundlaget for, at Google snart vil rangere din hjemmeside eller online butik højere.

Hvis artiklen var interessant for dig, kan du med glæde tjekke nogle flere af vores indhold: