Relaunch-checklista för onlinebutiker, boknings- & företagswebbplatser.

Det är dags för en omarbetning hos dig? Grattis, att du har hittat den här artikeln. Följande förklaringar kan vara en avgörande faktor för dig, för att din omarbetning ska lyckas och du ska uppnå ett fantastiskt resultat. För det händer inte alltid. Jag är byråägare och avslöjar exakt det som gör det möjligt för dig att tvinga typer som mig att göra enastående arbete och undvika vanliga misstag vid omarbetningar. Men låt oss börja från början.

En webbplatsomarbetning är omgestaltning och omarbetning av en befintlig webbplats. Designen, innehållet och tekniken kan alla ändras. Målet med en webbplatsomarbetning är att förbättra webbplatsen och anpassa den till aktuella krav.

Vissa externa utlösare gör att företag bestämmer sig för att utföra en omarbetning: Den nyanställde medarbetaren kommer med fantastiska idéer, en ny chef kommer och vill också sopa digitalt rent, konkurrenten har en ny webbplats eller intäkterna minskar. Kanske gillar inte chefens fru den gamla sidan heller eller Generation Z tycker att webbplatsen inte är tillräckligt "lit". Du kanske känner igen det. Även att det är dags för en ny webbplats igen, är inte heller som personliga åsikter en anledning till omarbetning.

Det finns dock några bättre skäl till varför företag eller organisationer vill genomföra en webbplatsomarbetning. De viktigaste bland dem är:

• Föråldrad design och/eller omdesign: En föråldrad webbplats kan ge intrycket att företaget inte hänger med i tiden eller inte är aktivt längre. En fräsch, modern design bör således förbättra bilden. Även om varumärkesbilden eller företagsidentiteten förändras, önskas ofta en omarbetning av webbplatsen för att återspegla det nya varumärkesbudskapet.
• Bättre användarupplevelse: Om användarvänligheten på en webbplats är dålig kan detta leda till en hög avvisningsfrekvens. En omarbetning kan tjäna till att förbättra användarupplevelsen och göra webbplatsen lättare att navigera på.
• Mobiloptimering: Eftersom allt fler människor använder mobila enheter för att komma åt webbplatser är det viktigt att se till att webbplatsen fungerar bra på olika skärmstorlekar och enheter.
• Sökoptimering (SEO): En föråldrad webbplats kan ha problem med SEO-prestandan. En omarbetning ger möjlighet att göra SEO-vänliga ändringar för att förbättra synligheten i sökmotorerna.
• Aktualisering av innehåll: Om företagets information, tjänster eller produkter förändras måste webbplatsen uppdateras för att reflektera dessa ändringar.
• Säkerhetsförbättringar: Äldre webbplatser är ofta mer sårbara för säkerhetsrisker. En omarbetning kan tjäna till att förbättra webbplatsens säkerhet och skydda den mot cyberattacker.
• Teknisk uppdatering: Användning av föråldrad teknik kan påverka en webbarts prestanda. En omarbetning kan erbjuda möjligheten att övergå till moderna webbtekniker och plattformar.
• Tillgänglighet: Förbättring av tillgängligheten är en viktig fråga för många webbplatser för att säkerställa att de är tillgängliga för personer med funktionsnedsättningar.
• Konkurrensförmåga: För att hålla jämna steg med konkurrensen är det viktigt att ha en modern och effektiv webbplats. En omarbetning kan bidra till att behålla eller öka konkurrensförmågan.
• Analysförbättringar: Genom att implementera bättre analysverktyg och samla in data kan företag förstå och optimera sin webbplatens prestanda bättre.
• Uppfyllande av lagkrav: Lagar och regler inom dataskydd, tillgänglighet och säkerhet förändras regelbundet. En omarbetning kan vara nödvändig för att säkerställa att webbplatsen uppfyller dessa krav.

Dessa skäl kan förekomma var för sig eller i kombination och variera beroende på företagets mål och behov. En webbplatsomarbetning är ofta ett strategiskt beslut för att förbättra närvaron på webben och uppnå företagets mål. Om du tittar på punkterna ovan individuellt blir det tydligt att de flesta skälen kan implementeras med mindre steg och inte kräver en stor omarbetning.

Låt oss därför skilja på vad en omarbetning är och vad den inte är: En ny design med befintlig teknisk grund är snarare en uppdatering av utseendet. Omarbetningen sker först när syftet med omarbetningen resulterar i en verklig förändring i användarupplevelsen, i funktionaliteten och på den tekniska grunden. 

En omarbetning ska alltid motiveras genom fakta (till exempel att tekniken är i återvändsgränd och inte kan uppdateras längre), nyckeltal samt mät- och jämförelsedata.

Detta är mitt första råd som jag vill ge här: Evolution före revolution! Undvik en omarbetning så länge som möjligt och försök att genomföra alla punkter som hittills har tagits upp för en omarbetning individuellt eller inkrementellt. Förbättra en sak, sätt den i drift, utvärdera vad som händer, justera igen eller gå vidare till nästa punkt. Bästa exemplet är Amazon, som verkligen bara gör minimala förändringar och förbättringar och har avstått från stora omarbetningsåtgärder i många år.

En omarbetning utgör alltid en stor risk för din synlighet på Google. Alla har förbättringarna i åtanke, men få har risken. Visst, användargränssnittet blir bättre, den positiva användarupplevelsen ökar, tekniskt är man uppdaterad igen. Men ändå: Om din företagssuccé beror på stark organisk synlighet är en omarbetning det sista botemedlet och bör endast beslutas om din smärta är tillräckligt stor på grund av en kombination av ovanstående skäl som inte kan hanteras i enskilda sprintar längre. Varför? Titta här på vad som hände efter omarbetningarna av dessa fyra webbplatser med deras online-synlighet:

Planera din relaunch noggrant och säkra den framgångsrika genomförandet med en checklista. Framför allt sätt också upp de två målen att behålla din online-synlighet och å andra sidan hitta möjligheter att inom ramen för relanchen skapa grunden för att öka online-synligheten. Precis för detta ändamål finns den här artikeln, för att ge dig en relaunch-guide, så att dina risker vid relaunchen begränsas och du verkligen får ett enastående arbetsresultat med potential för hållbara, organiska SEO-framgångar.

En relaunch-reseplan

Planeringen av en webbplatsrelaunch bör göras noggrant. Det är viktigt att ta hänsyn till följande steg:

• Analys av befintlig webbplats och dokumentation av nuläge: Först bör den befintliga webbplatsen analyseras för att identifiera styrkor och svagheter.
• Fastställande av mål: Målen för webbplatsrelanchen bör tydligt definieras. Det kan inkludera förbättring av konverteringsgraden, ökningen av besökarantalet eller övergången till ett nytt CMS med förbättrad innehållshantering och underhåll.
• Utveckling av ett koncept: Baserat på analysen och målen samt en konkurrentanalys bör ett koncept för webbplatsrelanchen utvecklas. Konceptet bör omfatta följande aspekter: design, innehåll, teknik och SEO/marknadsföring.
• Genomförande: Konceptet implementeras sedan. Det inkluderar utveckling av design, skapande/justering av innehåll och genomförande av tekniska förändringar.
• Testa: Den nya webbplatsen bör noggrant testas innan publicering för att säkerställa att den fungerar felfritt. Det inkluderar även en definierad checklista.
• Publicering: Den nya webbplatsen publiceras sedan. Den fortsätter att testas, utvärderas och anpassas live.

Fastställande av målen och strategin för relanchen

Bestäm exakt vilka mål relanchen syftar till. Målen kan inkludera (förutom de nämnda orsakerna): 

• Förbättring av användarupplevelsen
• Ökning av överskådligheten
• Utökning av innehållsutbudet
• Modernisering av designen
• Ökning av intäkterna och kundkorgens storlek 
• Övergång till ett annat CMS med enklare innehållshantering och teknisk underhållbarhet
• perspektivisk enklare utvecklingsbarhet och behållande av uppdaterbarhet.

Förslag: Efter de första kick-off-mötena i teamet som ett företag - innan samtal med verkställande byråer påbörjas - ska varje projektmedarbetare skriva ner målen för er relanch på en lapp eller i sin inmatningsruta i ert kommunikationsverktyg (t.ex. Slack). Om alla sedan samtidigt visar sina nämnda mål blir du förvånad över hur olika åsikterna går isär, även om målet redan tidigare diskuterades verbalt på mötena. Det är därför viktigt att även skriftligen fastställa målen. När du känner till dina mål exakt kan du i en tidig fas redan kontrollera om de har beaktats konceptuellt i UI-prototypen.

En kravspecifikation skapar klarhet om relaunch-uppdraget

Byrån behöver en omfattande projektbeskrivning från kunden för att kunna göra en offert. Företag har vanligtvis en Word-dokument eller en PDF redo, där projektet skisseras mer eller mindre detaljerat. Det finns sedan frågeformulär eller workshops där byråerna bättre kan identifiera kundens smärtor för att kunna lämna en offert. För större projekt skapas en kravspecifikation. Ju mer detaljerad, desto bättre. 

En kravspecifikation är ett dokument som spelar en avgörande roll vid en webbplatsrelaunch. Det syftar till att skriftligt dokumentera kraven, målen och förväntningarna på relanchen. En välarbetad kravspecifikation hjälper till att säkerställa att alla parter - vare sig det är utvecklingsteamet, designteamet eller kunden - har en klar förståelse för vad som ska uppnås under relanchen. Det är även en utgångspunkt för ett väl kalkylerat och bindande erbjudande från verkställande byrå. Här är information och element som vanligtvis kan ingå i en kravspecifikation för en webbplatsrelaunch:

• Mål och syfte: En beskrivning av huvudmålen för relanchen, t.ex. förbättring av användarupplevelsen, ökning av synligheten i sökmotorer eller övergång till CMS med uppdatering av designen.
• Projektomfattning: En tydlig definition av vad som ingår och inte ingår i relanchen. Det kan inkludera antal sidor, integrering av tredjepartsverktyg eller omarbetning av innehåll.
• Designkrav: Information om önskad visuell design av webbplatsen, inklusive layouter och överensstämmelse med företags designriktlinjer för färger, typsnitt och bilder.
• Funktionalitetskrav: En uppdelning av önskade funktioner och interaktioner på webbplatsen, som kontaktformulär, sökfunktioner, e-handelsfunktioner osv.
• Tekniska krav: Specifikationer för teknikerna som ska användas under relanchen, som valet av ett innehållshanteringsystem (CMS) eller implementering av vissa funktioner. Även användningen av moderna bild- och grafikformat (WebP, AVIF, SVG) ingår.
• Manuella och automatiserade säkerhetskopior och revisioner av innehållsredigeringar.
• Innehållskrav: Tydliga instruktioner för översyn, uppdatering eller nyproduktion av innehåll, inklusive texter, bilder, videoklipp och annat medieinnehåll. Hantering av metataggar och strukturerad data.
• SEO-krav: mer om detta i nästa innehållsområde.
• Tidplan och milstolpar: En tidplan som anger planerade start- och färdigställandedatum för relanchen samt viktiga milstolpar 
• Budget: Information om budgeten för relanchen, inklusive kostnaderna för design, utveckling, hosting och eventuella tjänster från tredje part.
• Kvalitetssäkring med testverktyg: Beskrivning av test och kvalitetskontrollförfaranden som ska genomföras under relanchen för att säkerställa att webbplatsen fungerar felfritt.
• Krav på underhåll och support: Krav på kontinuerligt underhåll och support för webbplatsen efter relanchen.

En välstrukturerad kravspecifikation är avgörande för att undvika missförstånd, effektivt styra projektet och säkerställa att förväntningarna hos alla intressenter uppfylls. Den fungerar som riktlinje och referensdokument för hela projektteamet och bidrar till att säkerställa framgången med webbplatsoptimeringen 

När vi planerade omstarten av TutKit.com med en komplett bytet från CodIgniter till Laravel, omfattade vår kravspecifikation 220 sidor – (inte) en lockande utsikt för ett företag att ta sig igenom.

Notera: Min artikel kommer inte att gå in detaljerat på koncept, design, funktion och använda teknik. Den nya webbplatsen kommer säkert att vara snygg. Den största risken med en omstart ligger faktiskt i en försämring av den tekniska användarupplevelsen och kvaliteten på sidan genom uteblivna 301-redirects osv., vilket sedan leder till förlust av ranking och synlighet. För att förhindra detta kommer fokus främst att ligga på att säkra projektframgången utifrån användarupplevelse och SEO-perspektiv.

Definition av SEO-kraven för den nya webbplatsen

Beställarens brief eller en mer detaljerad kravspecifikation reglerar redan vad som är önskvärt när det gäller design, innehåll, funktion och teknik och utgör grunden för att ett företag kan göra en kalkyl.

För omstartskontrollistan för att säkra projektframgång måste SEO-perspektivet beaktas i de olika avsnitten. Specifika SEO-krav uppstår till exempel genom:

• en förändrande URL-struktur (URL-omdirigeringar!) och förändrade länkvägar
• en förändrande navigering (viktigt för interna länkar och länkhierarki)
• förändrade teknologier (CMS, JavaScript-ramverk, server, …)
• förändrat innehåll (möjlig synlighetsförlust på bra rankade sidor)

Sidor rankas väl på Google på grund av deras innehållsmässig relevans, vilket gör det viktigt att fråga om befintligt innehåll förändras eller slås samman, om innehåll försvinner och/eller nytt innehåll läggs till? Förändras den innehållsmässiga strukturen på kategorier eller sidor? SEO-krav måste härledas från dessa punkter och inkluderas i omstartskontrollistan.

Överförs metadata från gamla innehåll och ändras den? Hur sköts innehållsunderhållet av redaktören och är sidinnehållet kopplat till strukturerade data?

Lagras befintliga eller nya bilder i moderna bildformat för webbplatser (WebP/Avif) och övervägs bild-SEO med talande URL:er med små bokstäver, så att det istället för 1234.jpg blir hotel-ostsee-warnemuende_suite-nachtigall.avif.

Samma sak gäller för att bilddata ska överlämnas med strukturerade data (ImageObject) och <meta>-thumbnails till Google för att öka chansen att bilden bäddas in i sökresultaten och syns hos Google Bilder.

Det är också intressant att undersöka hur användarsignaler kan förbättras. På innehållssidor kan till exempel bildvideor, förklarande och hjälpvideor bäddas in. Om en användare som kommer från Google till landningssidan klickar på videon och tittar på den, ökar vistelsetiden (positiv användarsignal), återvändandehastigheten till SERP förbättras också (positiv användarsignal).

Det bör också undersökas hur innehållssektioner kan integreras på sidorna för att uppfylla Googles krav på Hjälpsamt innehåll och för E-A-T-principen.

För Google är "Hjälpsamt innehåll" sådant innehåll som är relevant och användbart för användarna. Det besvarar användarnas frågor genomgående och informativt, erbjuder lösningar på problem och ger ett värde som går utöver rent reklambudskap.

Här är några exempel på hjälpsamt innehåll:

• Guider och instruktioner: Dessa innehåll hjälper användarna att lära sig nya uppgifter eller lösa befintliga problem.
• Recensioner och jämförelser: Dessa innehåll hjälper användarna att välja rätt produkt eller tjänst.
• Nyheter och uppdateringar: Dessa innehåll håller användarna uppdaterade om aktuella händelser och trender.
• Infografik och diagram: Dessa innehåll kan hjälpa till att visualisera komplexa data och information.
• Blogginlägg och artiklar: Dessa innehåll ger en djupare insikt i ett specifikt ämne.

Google använder olika signaler för att identifiera hjälpsamt innehåll. Det inkluderar bland annat:

• Användarbeteende: Google observerar hur användare interagerar med innehåll, t.ex. hur länge de stannar på en sida, hur ofta de delar den och hur ofta de betygsätter den.
• Kvalitetssignaler: Google bedömer kvaliteten på innehållet baserat på faktorer som relevans, fullständighet och aktualitet.
• Feedback från användare: Google tar också hänsyn till användarfeedback, som betyg och kommentarer.
• Genom att ta hänsyn till dessa signaler kan webbplatsägare öka chanserna att deras innehåll bedöms som hjälpsamt.

EEAT-principen är en koncept utvecklat av Google som utvärderar kvaliteten på webbplatser och webbinnehåll. Det står för Expertis, Erfarenhet, Auktoritet och Förtroende, alltså Expertis, Erfarenhet, Auktoritet och Pålitlighet.

• Expertis hänvisar till kunskapen och erfarenheten hos personerna som skapar innehållet. Google utvärderar kompetensen baserat på faktorer som utbildning, yrkeserfarenhet och utmärkelser.
• Erfarenhet bekräftas när innehållet också har skapats med viss erfarenhet, t.ex. baserat på faktisk användning av en produkt, faktiskt besök på en plats eller beskrivning av upplevt av en person.
• Auktoritet hänvisar till ryktet och ryktet för en webbplats eller webbinnehåll. Google utvärderar auktoriteten baserat på faktorer som bakåtlänkar, aktiviteter i sociala medier och användarrecensioner.
• Förtroende hänvisar till pålitligheten och trovärdigheten hos en webbplats eller webbinnehåll. Google utvärderar förtroendet baserat på faktorer som integritet, säkerhet och transparens.

Vilka SEO-krav har befintliga och nya funktioner med avseende på frontend och backend? Här handlar det om exempelvis:  

• Genomförbart (relevanta innehåll måste vara synliga och genombart även utan JavaScript)
• Klart mål för webbplatsen och tydlighet gällande call-to-action (önskad interaktion från målkunden på sidorna)
• Undvikande av duplicerat innehåll genom t.ex. automatiskt skapade kategorisidor eller sidkopior av varianter av artiklar
• Säkerställa hög sidhastighet genom att undvika för många JavaScript- och CSS-filer, genom användning av moderna bildformat (WebP/AVIF)

Dessa SEO-krav bör ingå i projektspecifikationen eller kravspecifikationen, men bör också inkluderas i en checklistan för testverktyg eller som en IST-SOLL-jämförelse i projektets kvalitetssäkring samt ytterligare som ett godkännandekriterium för byråns prestation. Mer om detta nedan.

Fastställande av interna och externa projektdeltagare

Bestäm projektdeltagarna - här sett från kundens eller webbplatsägarens synvinkel: 

• Vem ansvarar för projektledning och fattar de slutgiltiga besluten? 
• Vem är ansvarig för samordning och kommunikation med byrån eller med kunden? 
• Vem tar över det interna projektledandet?
• Vem förbereder innehållet internt och stöder byrån?
• Vem implementerar användarupplevelse-designen? 
• Vem utför utvecklingen? 
• Vem rapporterar byråsidan till kunden med vilka beslutade intervaller?
• Vem utför testning och kvalitetssäkring på byråsidan/kundsidan?
• Konsulteras en extern konsult (t.ex. för SEO eller juridiska krav)?
• Vem godkänner uppgifter? Vem granskar uppgifterna i ticketsystemet efter bearbetning?
• Vilka personer behöver informeras vid vilken tidpunkt (anställda, kunder, partners, annonskampanjförvaltare, …) 

Fyra viktiga punkter vid val av externa projektutförare

1. Har byrån genomfört ett eller flera projekt av denna typ? Finns det referenser? Finns det kundutlåtanden och skulle också ett feedbackmöte med kunder hos byrån vara möjligt - vilket är rekommenderat vid stora individuella utvecklingar?
   
2. Uppfyller erbjudandet och den tekniska utförandet (CMS/eshop/framework) redan alla krav som är relaterade till relanschen? Finns det individuella funktioner eller krav som fortfarande måste programmeras (också via plugin eller modul)? Är vissa tjänster i erbjudandet uteslutna eller förbokade för en senare tidpunkt, men som är avgörande för projektsframgången? Det är viktigt att inga nya problem uppstår som är större än den faktiska orsaken till relansen.
   
3. Passar den implementerande byrån eller leverantören både till teamets storlek och den geografiska positionen samt personalomsättningen (som eventuellt kan fastställas via Kununu-recensioner) hållbart med företaget för fortsatt support?
   
4. Är en direkt kontakt möjlig med det implementerande design- och utvecklingsteamet? Det är klokt att träffa det faktiska byråteamet. De glada och himmelsblå säljproffsen tar hem uppdragen och är senare inte längre ansvariga. Därför bör också en direkt kontakt med det implementerande teamet avtalas.

Fyra tips för egen säkerhet i detta sammanhang

1. Som kund skulle jag noggrant övervaka byråns använda teknologi. Vad som nämns i erbjudandet, det är bra att googla med "CMS + nackdelar" eller "CMS + erfarenheter". Du bör veta vad du ger dig in på. Det är bra att satsa på öppen källkodslösningar. Jag förstår att det inte alltid är möjligt. Se till att det finns en så stor användargrupp för den använda tekniken som möjligt, så att du inte slutar med en byråspecifik lösning som bara byrån kan hantera, vilket på ett sätt senare kan sätta dig i stora problem.
   
2. Se även till att du får de obegränsade användnings- och redigeringsrätterna för byråns arbete, så att du alltid har rätt att kunna utveckla webbplatsen internt eller externt. En sådan klausul bör ingå i entreprenadavtalet.
   
3. Om ditt företag är något tekniskt präglat och ni har systemadministratörer, mjukvaruutvecklare eller liknande i teamet, är det bra att själv installera GIT för versionshantering och JIRA (eller ett liknande verktyg) för projektledning eller ticketsystemet i en egen databas. Sedan ger du byrån full åtkomst och arbetet kan börja. Ju större ett projekt är, desto tuffare och smärtsammare kan det bli. Då är det bra om du har kontroll över de viktiga tillgångarna och kontona. Jag förstår dock att denna rekommendation endast kan följas rent yrkesmässigt av få kunder.
   
4. Det händer ibland att byråer erbjuder hosting direkt till kunder. Vi själva är inte särskilt förtjusta i det, dels för att det ökar beroendet i kundrelationen, dels för att vi anser att webbhotellföretag är bäst lämpade för webbhoting eftersom de är specialiserade på det. Vi har själva ställt upp och hanterat servrar och förbrukat mycket personella och tidsmässiga resurser. Vi ångrade oss. Nu körs våra system på molnserver hos en av de stora webbhotellföretagen i Tyskland och vi är nöjda. Se i alla fall till att serverbaserade backuppaket ingår, som kan återställas med några klickar.

Fastställande av tidsram och lanseringsdatum

En omarbetning genomförs i flera projektsteg. Enligt vår byråerfarenhet kan dessa vara:

• Nuvarande situation protokollförs (via testverktyg, men också skriftligt med intryck av vad som fungerar bra på kundsidan och var förbättringar behövs)
• Researchfas med konkurrensanalys och forskning om lösningar/inspiration
• Wireframe-koncept
• Design av användargränssnittet
• Frontend- och backend-utveckling
• Migration av data eller innehållsimport (automatiserad/manuell)
• strukturella och innehållsmässiga optimeringar av innehållet (text och bild) & SEO-steg

Projektstegen överlappar varandra, eftersom nya projektmedlemmar blir aktiva under arbetets gång.

Det är viktigt att definiera tidsramen för enskilda projektsteg och komma överens med de berörda personerna.

Inrättar byrån en egen Slack-kanal för snabbare kommunikation med kunden för projektet, om det är större?

Ett tips på den här punkten: Det är bra om byrån redan i en mycket tidig fas arbetar med klickbara prototyper, alltså redan i wireframe-konceptet och särskilt vid presentationen och granskningen av användargränssnittsdesignen. På så sätt får kunderna en bättre känsla för upplevelsen av webbplatsen. Enkla JPG- eller PNG-filer som layoutförslag är inte längre tidsenliga idag. Det bör vara klickbara prototyper som utvecklas med Sketch, Figma, Adobe XD eller annan professionell mjukvara.

I detta tidiga skede är ändringar lättare att genomföra. När funktioner och sektioner på en webbplats redan har utvecklats, är ändringar mycket mer krävande och kan eventuellt leda till efterförhandlingar, som definitivt inte är särskilt sexiga.

Här syns en gång hur en prototyp för mobildesign av användargränssnittet med klickvägar ser ut i överblick:

Frågan att besvara är när löpande tester från kundsidan är möjliga. Utvecklare bör också testa sina lokala arbeten efter fusion i stegsystemet. Det låter banalt, men alla som samarbetar med utvecklare förstår omedelbart vad jag menar. Därefter bör den som är ansvarig för byråns kvalitetssäkring testa biljetten eller funktionen. Först då frigörs biljetten för kundens testning. Kunden bör aldrig känna sig som en alfa-testare, utan bör redan hitta ett system testat med fyra ögon. Byrån är alfatestaren, kunden är betatestaren! Finns det ens tillgång till byråns biljettsystem?

Dessutom bör det skriftligen definieras att byråns rapporter till kunden måste ske med en viss frekvens. Till exempel kan det vara en rapport via e-post varje fredag om den aktuella statusen för arbetet, nödvändiga återkopplingsloopar eller arbetsförfrågningar. Det är också ett tips från vår byråerfarenhet: Det är bra att inte lämna en kund osäker inför helgen. Då kommer hen bara på dumma idéer. Det är bättre att informera väl om vad som har hänt och vad som står på agendan för kommande vecka. Transparens hjälper så att alla kan fortsätta med en god känsla i arbetet.

Lanseringsdatumet bör också fastställas. Enligt Parkinsons lag utvidgar sig arbete så att det fyller den tillgängliga tiden för dess utförande. Med andra ord, ju mer tid som finns tillgänglig för att slutföra en uppgift, desto mer tid tar det att slutföra den, oavsett uppgiftens faktiska komplexitet eller arbetsinsats. Planerad färdigställande bör också ingå i avtalet. Att misslyckas med deadline kan till och med åtföljas av en konventionalstraff i avtalet. Som riktlinje gäller att konventionalstraff på 0,2 % av uppdragssumman per arbetsdag för dröjsmål och högst 5 % av uppdragssumman är effektiva. Konventionalstraff behöver inte nödvändigtvis göras gällande gentemot kunden, men ger dig utrymme att åt byrån locka fram några extra önskemål som kompensation.

Viktigt: Ingen lansering på fredagar. Inte heller mellan helgdagar eller under företagets huvudarbetstid. Vi rekommenderar faktiskt att vid omfattande omarbetningar genomföra lanseringen under nattetimmarna från söndag till måndag, särskilt om IP-adressen ändras, så att DNS-inställningarna fortfarande uppdateras hos de flesta leverantörer på måndag, vilket ofta redan sker på sena förmiddagen om DNS-posten justerades under nattetimmarna. På så sätt finns det faktiskt 4,5 arbetsdagar kvar för live-testning och buggfixning vid eventuella fel.

Dokumentation av din webbplats aktuella status

Läget måste dokumenteras innan arbetet påbörjas. I aktuellt läge dokumenteras de tekniska mätvärdena för parametrarna. Till höger kan du fylla i måluppgifterna:

I listan hittar du som SEO-verktyg det av oss oftast använda Seobility för att kontrollera OnPage-faktorer, inklusive en SEO-träning som jag också publicerat. Det finns många motsvarigheter som t.ex. Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog osv. När det gäller SEO-verktyget handlar det framför allt om att identifiera och åtgärda de vanliga OnPage-felen. Här är de tre kärnområdena Teknik & Meta, Struktur och Innehåll, som Seobility bygger sina utvärderingar på. Du hittar det på ett liknande sätt även i de andra SEO-verktygen. Det är viktigt å ena sidan att alltid göra en fullständig kontroll, dvs. att ALLA sidor krypas och inte bara startsidan, samt å andra sidan att ange en poäng eller felvärde för nuvarande status och målvärdet som ska uppnås efter optimeringen. Med Seobility är en värde på 90 eller högre önskvärt. På samma sätt hittar du även alternativa verktyg för andra ändamål. Det är avgörande att åtminstone ett verktyg används för att säkerställa utmärkta data.

Detta är exempelvis vår nuvarande värdering av OnPage-kvaliteten:

Usersignaler kan statistiskt samlas in med mätvärden från Google Analytics 4 såsom Rebouncefrekvens, Sidor/Besökare, Sessionstid etc. Förutsatt att Google Analytics eller ett annat analysverktyg används i enlighet med dataskyddsförordningen, bör dessa data också beaktas i loggningen av nuvarande status.

En backlink-lista bör också skapas, som exempelvis kan genereras gratis här: https://www.seobility.net/de/backlinkcheck/

Dessutom bör den gamla sitemap.xml säkras, liksom en fullständig säkerhetskopia av webbplatsen. Alla relevanta sidor bör också överföras som en lista till ett Google Sheet, som utgör utgångspunkten för URL-omdirigeringskartan. En sådan CSV-lista kan enkelt exporteras med ett SEO-verktyg som Seobility. I URL-omdirigeringskartan beaktas alla relevanta sidor och länkade sidor via externa backlinks (se Backlink-listan) som senare måste omdirigeras på grund av förändrade sid-URL:er. Borttagna URL:er bör omdirigeras till de nya, motsvarande gamla URL:erna. Det är viktigt att förhindra vidarebefodringskedjor! De gamla, fortfarande existerande vidarebefodringarna bör direkt omdirigeras till den nya slut-URL:en. På samma sätt bör även PDF-filer och bilder beaktas, som länkar finns till, så att de också korrekt omdirigeras och inte blir till en 404-länk.

Omdirigeringar skapas som 301-omdirigeringar baserade på URL-omdirigeringskartan i .htaccess, via omdirigeringskartor via Vhost-konfiguration eller en databaslösning. Klienten bör kunna underhålla dessa själv. Det ska också säkerställas att omdirigeringarna är permanenta.

Det är också rekommenderat att säkerhetskopiera varje sidtyp med en helb ildsskärmdump. Det är å ena sidan en säkerhetskopia av befintlig information, om det efter lanseringen uppst&raring;r frågor om innehållstyper inte har överförts osv.

Med hjälp av befintliga sidor, funktioner och innehåll och baserat på mätresultaten kan namn identifieras, vad som redan fungerar bra och vilket område som identifieras som där potential för optimering finns, vilket bör förbättras genom omstarten.

Kontrollista: Före omstarten

Så snart användargränssnittsdesignen har godkänts och byrån befinner sig i utvecklingsfasen blir följande kontrollista relevant, som kronologiskt listar de väsentliga punkterna fram till omstartsdagen:

1. Dev-miljön med åtkomst för alla inblandade är tillgänglig för testning
2. Dev-miljön körs på noindex
3. Åtkomst till testverktyg på Dev-miljön (IP-åtkomst eller http-inloggning) är konfigurerad
4. Konfigurationen av Dev-miljön motsvarar i största möjliga mån den i det aktuella systemet
5. Sidstrukturen på Dev-miljön motsvarar den framtida liveloopsidan
6. Dataöverföringen av äldre data har genomförts
7. Innehållsanpassningar har genomförts
8. Bilder-SEO har implementerats
9. 301-omdirigeringar baserade på URL-omdirigeringskartan är konfigurerade
10. OnPage-kontroll med Seobility har genomförts, fel har åtgärdats, målvärden har uppnåtts
11. Open-Graph-data är giltiga
12. Strukturerade data är giltiga
13. Pagespeed-översyn för alla sidtyper har genomförts, målvärden har uppnåtts
14. Innehåll-cookiepolicy fungerar
15. Säkerhetsrubriker är konfigurerade
16. Tillgänglighet är given, målvärden har uppnåtts
17. Hreflang är giltiga (på flerspråkiga sidor)
18. Rättsliga texter (villkor, imprint, återkallelse, dataskydd) har uppdaterats, DSGVO-konformitet är given
19. Uppdatering av CMS, ramverk, använda tillägg och moduler till den senaste versionen har genomförts
20. Slutlig test av funktionalitet över webbläsare och enheter har inte visat några fel
21. Slutstatus och lanseringsdatum är känt
22. Fullständig backup har skapats

Användandet av strukturerade data (Schema-Markup) - se punkterna 12 i listan - beaktas fortfarande alltför lite idag. Bekanta dig med ämnet och läs vad Google säger om markup för strukturerade data i Google-sökningen. Google kommer allt mer att väga valid data tyngre inom ramen för SGE, dvs. den sökmotorresultat som skapas av AI. Även Googles Helpful Content Update innebär att innehåll i högre grad verifieras genom expertis, erfarenhet, auktoritet och trovärdighet. Strukturerade data är en del av lösningen för att förenkla denna validering för Google. Efter integrering av strukturerade data, använd Schema-Markup-Validator, men kontrollera också dina sidor med Structured Data Linter, vilket även rekommenderas och länkas från Google i PageSpeed Insights. Där får du mer utförlig information om kodfel i samband med din användning av strukturerade data.

I punkt 16 dyker nu för första gången Tillgänglighet upp i den här artikeln. Redan i PageSpeed Insights har tillgängligheten en egen sektion och gröna siffror är önskvärda där. Testet om en sida är tillgänglig eller inte bör då göras inte bara genom PageSpeed Insights utan även via https://www.accessibilitychecker.org och/eller https://wave.webaim.org. Särskilt när det nu är dags för en omstart, bör denna punkt obligatoriskt beaktas, eftersom tillgänglighetsstärkningslagen för webbplatser blir aktuell från 2025. Kontrollera inte bara startsidan med ett sådant verktyg, utan varje sidotyp - samma gäller för PageSpeed-testerna!

Inom ramen för en omstart resulterar det ofta också i justeringar och Uppdateringar av juridiska texter. Det är viktigt att tänka på detta i god tid, så att texterna eventuellt kan tillhandahållas via en specialistadvokat eller via juridikgeneratorer. Även avtalsförvaltningsavtal bör tänkas på, om till exempel en ny webbhotell används eller nyhetsbrevstjänsten ändras.

Punkt 18 med uppdatering av CMS, använda JavaScript-bibliotek, installerade moduler och tillägg är lika underskattade som viktiga. En omstart kan ta flera månader och längre tid. Med WordPress-systemet är det lätt att se om det kanske redan finns många uppdateringar tillgängliga före omstartsdatumet. Kunden bör se till att de använder de senaste versionerna vid lanseringen.

Vid förändrade externa tjänster tillkommer ytterligare uppgifter som också bör namnges på kontrollistan, såsom vid ändring av nyhetsbrevstjänsten:

• Dataimport av nyhetsbrevskontaktdatabaser till den nya nyhetsbrevstjänsten
• Anslutning till nyhetsbrevstjänsten på webbplatsen vid registreringsformuläret
• Personuppgiftsbiträdesavtal
• Skapande av nya utskicksmallar
• och så vidare

Under hela utvecklingsprocessen sker löpande tester av funktionerna osv. Det är smart att göra en mycket detaljerad kontrollista för testerna så ingenting glöms bort. Det räcker inte att bara klicka runt lite, varken som genomförande byrå eller som kund. Efter vår omstart av TutKit.com hade vår godkännandekontrollista över 1 000 rader. Och så håller vi på än idag: efter viktiga stora uppdateringar kontrollerar vi cirka 70 interaktioner via checklistan för Chrome, Safari och Android.

Kontrollista: Omstartsdagen och de kommande dagarna

Omstartsdagen har kommit och det är inte en fredag och inte heller en dag mellan helgdagar. Den nya webbplatsen går live, DNS-inställningarna är justerade. Nu gäller det att börja om från början och utvärdera allt på nytt. Kontrollera följande:

1. kontrollera robots.txt så att robots inte blockeras
2. Live-miljön körs på index, följ 
3. Kanoniska taggar är korrekt inställda
4. Kontrollera källkoden för absoluta sökvägar (Länksökvägar för testmiljön på live-sidan)
5. Vidarebefordran från http till https med/utan www till målsidan på startsidan och undersidorna fungerar
6. Testa vidarebefordringar med URL-redirect-kartan, även förekomsten av omdirigeringar i kedjor
7. OnPage-kontroll av livssidan med Seobility för teknik & meta, struktur och innehåll ... speciellt att kontrollera sidor med noindex som genereras av Seobility
8. Open Graph-data är giltiga
9. Strukturerade data är giltiga
10. PageSpeed är kontrollerad för alla sidtyper, målvärdena är uppnådda
11. Cookie-policy med samtyckescookie-verktyg fungerar som det ska
12. Säkerhetsinställningar är konfigurerade
13. Tillgängligheten är tillgodosedd
14. Kontrollera Hreflang på flerspråkiga webbplatser (https://app.sistrix.com/de/hreflang-validator)
15. Slutlig test av funktioner över webbläsare och enheter visade inga fel
16. Skicka in ny sitemap.xml till Google Search Console
17. Uppdatera nya målsidor i Google Ads-kampanjer
18. Vid vissa ändringar av domännamn, tänk på länkar i sociala medier, e-postsignaturer osv.

Vi använder Mailhog i vår Dev-miljö för att testa e-poster lokalt. I sådana fall är det viktigt att de riktiga SMTP-data för Emottagande av e-post i livsystemet är inställda så att e-posterna når dit de ska.

Det är också viktigt att se till att Betalningsleverantörer som Paypal i Dev-systemet har Sandbox implementerat, medan den korrekta anslutningen måste göras i livsystemet.

Under de kommande dagarna är det viktigt att främst övervaka Google Search Console. Det mest intressanta är naturligtvis hur dina rankningar förändras. Fokusera särskilt på oväntade förändringar och felmeddelanden:

1. Crawling: Värdsstatus ... Hämtar robots.txt, DNS-upplösning, Serveranslutning
2. Crawling-statistik ... Begäranden, Hämtstorlek, genomsnittlig svarstid
3. Klickar i SERPs
4. Intryck i SERPs
5. Genomsnittlig CTR i SERPs
6. Genomsnittlig SERP-position
7. Uppfyllande av Core Web Vitals 

Framför allt kommer Google Search Console att visa fel såsom t.ex. URL-fel, hreflang-fel, sidindexering med spread indexierad/ ej indexierad. För ej indexierad måste det finnas en anledning (omdirigering, noindex)... Där kan du också se duplicerat innehåll eller andra problem. Om Search Console rapporterar problem med strukturerade data eller Core Web Vitals, undersök detta. Först genom live-data kommer du t.ex. att upptäcka att dina sidor har problem med Core Web Vitals trots en hög PageSpeed på grund av t.ex. CLS-fel. Här kan du tydligt se vilka förändringar som är möjliga på webbplatsen:

Du kan direkt visa de dåliga eller de URL:er som behöver optimeras. Ta en URL och utför en PageSpeed-test med den på PageSpeed Insights. Där får du sedan anvisningar om varför Core Web Vitals inte uppfylls och vad du kan göra för att åtgärda felen. Klicka på den lilla pilen nedåt för mer information. Vanligtvis kan dessa rekommendationer endast genomföras av utvecklare. Det är dock viktigt att kunna identifiera problemen för att sedan ta itu med dem med hjälp av ditt företag.

Analysera även dina data från dina analysverktyg, såsom t.ex. Google Analytics 4. Håll även koll på de mätpunkter du kan samla in systematiskt, exempelvis bokningar, konverteringsfrekvens, varukorgens värde, inköp/försäljning per dag, antal nyhetsbrev-anmälningar, förfrågningar om kontakt, nedladdningar av specifikt innehåll eller visningar av videor. 

Crawling-statistiken i Google Search Console är grundläggande för kontroller under de följande dagarna. Du hittar dessa via inställningarna till vänster i menyn. Det borde vara mer Crawl-aktivitet synlig direkt. Om inte, finns det Crawl-fel?

Värdsstatus gör direkt synliga fel för dig, som här efter en publiktgöring, då crawl-begäranden om robots.txt har misslyckats och även serveranslutningen har avbrutits delvis om och om igen:

Också intressant är vad Crawling-statistiken säger. Efter en publikering sker vanligtvis en ökning av Crawl-begäranden. Där kan du också se om det fortfarande finns 404-sidor som crawlas. Om vissa inte passar in, diskutera dessa med utvecklarna.

Du kan se om din server, din PageSpeed och din kod är relativt bra om din sidresponstid är under 400. Ju närmare denna närmar sig 1000 ms, desto rekommenderad är en PageSpeed-optimering, t.ex. genom att minska databasbegäranden och förstärka serverkraften (t.ex. mer beräkningskraft, uppdatering till senaste serverprogramvaran, omvandling till HTTP2 eller HTTP3 (med Nginx)).

Perspektiviskt kommer crawl-budgetet för enskilda webbplatser förmodligen att begränsas av allt fler (AI-) innehåll på webbplatser, varför det också här är önskvärt med en bra svarsidstid för sidorna, så att båtarna kan kryssa på dina sidor så mycket som möjligt inom den tillgängliga tiden.

Lanseringskontrollista för nedladdning

De inbäddade checklistorna för omlansering finns också som PDF-fil för nedladdning här. Ladda ner dem och säkerställ därmed din projekts framgång!

Företagarens bekännelser

SEO-kraven i kontrollistan skulle också kunna få detaljerade instruktioner som att observera rubrikstrukturen från H1 till H6 och så vidare. Att fastställa målvärden i testverktygen förkortar till synes hela relanseringskontrollistan innehållsmässigt, eftersom att uppnå toppresultat av testverktygen som nämns i kontrollistan endast kan uppnås genom att följa ren kod, användning av modern teknik, beaktande av SEO-OnPage-faktorer osv. Annars måste de senaste webbstandarderna och tekniska och SEO-kraven formuleras i lastenhet väldigt detaljerat, vilket kunder rent fackligt inte är kapabla till. Om byråerna måste uppnå höga värden i testverktygen, kan de inte göra något annat än att arbeta enligt bästa praxis - även för byråerna en ny erfarenhet :-)

Det är dags för ett erkännande. Definieringen av SEO-kraven samt det checklista-liknande tillvägagångssättet med att säkra och uppnå de målvärden som definieras i olika testverktyg utgör en idealbild, som i verkligheten sällan återfinns. Det beror på:

• kundbegränsningar
• byråsidiga vinstoptimeringsintressen
• begränsningar genom de använda teknologierna
• och tyvärr också: okunnighet och inkompetens på båda sidor

Jag kan inte klandra kunden. De söker ju professionell hjälp och nästan varje digital byrå skriver på sin webbplats och i sina whitepapers att sökmotoroptimering är en av deras kärnkompetenser. Det finns alltid referenser som visar att online-synligheten har ökat med en faktor på 3, 5 eller 10 efter en relansering. Även om det är en ökning med 1000 procent att gå från 10 besökare till 100 per dag, så är det inte nödvändigtvis en framgång. Många sökmotorsframgångar beror på att konkurrenterna helt enkelt är mycket svagare digitalt.

Byråer fortsätter att göra medelmåttigt arbete med föråldrade metoder, eftersom de ännu inte använder moderna verktyg för kvalitetssäkring, även om de stoltserar med att ha SEO-kompetens i sina inlägg, referenser, bästa praxis etc. Kanske är sådana byråer kunskapsjättar, men också utföringsdvärgar. Det låter hårt, men det är bara regeln. Helt ärligt. Kolla in det noggrant! Använd checklistan ovan och mata in den bästa byrån i regionen, där du kommer ifrån, tillsammans med deras URL, i de nämnda verktygen. Och sedan tar du den senaste webbplatsreferensen som du hittar från byrån och gör om det. Vilka resultat kommer du att se? Precis de resultat du kan förvänta dig i ett samarbete. Du kan också granska våra egna referenser på detta sätt och upptäcker att vi inte alltid uppnår toppresultat hos alla våra kundprojekt. En sådan arbetsprocess med inställningen till datadriven kvalitetssäkring har också bara växt fram hos oss från projekt till projekt och har etablerats främst genom vårt arbete på TutKit.com. 

Du kan göra sådana kontroller med nästan alla byråer, eftersom bara ett fåtal verkligen arbetar datadrivet inom kvalitetssäkring, eftersom ingen har hållit sig med egna projekt på marknaden under flera år och mäta sig i den tuffa konkurrensen om online-synlighet med internationella aktörer, och eftersom byråer nästan lämnar det utan betydelse om ett projekt lyckas eller inte, så länge byrån betalar räkningen och kunderna kan fira de vackra (men kvalitativt medelmåttiga) webbplatserna på sina inlägg och med utmärkelser. Den särskilda ironin i detta: Enligt de nämnda testverktygen presterar ofta just SEO-byråerna sämst med sina egna webbplatser, eftersom de ofta, som ett ensidigt trick, bara har en metod på lager … ett innehållspaket utökat med kundens nyckelord för webbplatsen. De saknar ofta helt enkelt kompetenta utvecklare för de övriga tekniska kraven.

En fördel är också om byrån finns på en annan plats och du inte stöter på kunden när hen handlar på varuhuset som ansvarig från byrån, som enkelt har ett synlighetsminskning i tvåsiffrigt procentantal att svara för efter en relansering. Men kunder kollar knappt synlighetsminskningar, eftersom alla har en cookie consent-banner, men få verkligen analyserar siffrorna och extraherar handlingsåtgärder. Om du är osäker måste annonseringskostnaderna helt enkelt ökas. Det är bra att idag det organiska rankingen till stor del beror på överflödet av webbplatser som är jämförbara bra innehållsmässigt, framför allt på tekniska parametrar, användarsignaler och (fortfarande) bakåtlänkar, vet lyckligtvis inte kunderna. Och genom AI-textverktyg kommer webbplatserna innehållsmässigt att öka i en aldrig tidigare skådad kvantitet och kvalitet, och snart kommer vi att kunna välkomna många nya webbplatser från utlandet på vårt språk i sökresultatsidorna, eftersom AI-översättningsverktyg gör det allt lättare att översätta onlinebutiker, portaler, SaaS:er och andra webbplatser och ge sig på den digitala hemmamarknaden. Vi kan förbereda oss på en hård konkurrens. Det har bara börjat …

Slutsats om datadriven webbplatsrelanseringschecklista

En sådan datadriven checklista är en av de få effektiva sätten att tvinga byråerna att leverera bra arbete. Det är till och med att rekommendera att göra uppnåendet av vissa värden i testverktygen till en godkännanderegel. Det bör regleras i kontraktet att en delbetalning endast får faktureras fyra veckor efter relanseringen om alla viktiga data finns tillgängliga och bekräftar att toppvärdena klaras (såsom Core Web Vitals och de validerade produktsnutorna enligt schema-markup i Search Console). Med hjälp av den här arbetsprocessen – som beskrivs i det här inlägget – kommer ditt synlighetsförlust efter en relansering med kraftiga innehållsmässiga, strukturella och tekniska förändringar att förbli begränsad och du skapar grunden för att Google snart kommer att ranka din webbplats eller onlinebutik högre.

Om artikeln var intressant för dig, ta gärna också en titt på våra andra innehåll: