Checklista inför lansering av hemsida: vad ni måste kontrollera innan ni går live

En kund ville nyligen lansera sin nya hemsida en fredag eftermiddag, eftersom vd:n skulle presentera den på en konferens redan påföljande måndag. Vi körde igenom checklistan vi alltid använder inför lansering och hittade tre problem på tjugo minuter: kontaktformuläret gick fortfarande till en utvecklares testinkorg, robots.txt-filen från staging-miljön hade följt med av misstag och blockerade hela sajten för sökmotorer, och de gamla blogg-URL:erna – som hade år av bakåtlänkar och ranking bakom sig – saknade omdirigeringar helt. Inget av detta hade synts vid en snabb koll av startsidan. Allt hade tyst kostat kunden leads, trafik och ranking från och med sekunden sajten gick live.

Så ser det oftast ut vid lanseringar: det som går sönder är sällan sådant man lägger märke till om man bara klickar runt lite på sajten. Det är sådant ingen kontrollerar om det inte finns en checklista som tvingar fram det. Här är checklistan vi faktiskt använder, uppdelad i kategorier och skriven så att ni kan beta av den punkt för punkt istället för att försöka hålla allt i huvudet på en gång.

Tekniska och funktionella kontroller

Börja här, för ett trasigt funktion är den mest synliga typen av fel – besökare stöter på det direkt, och det underminerar förtroendet för allt annat på sajten.

• Alla länkar på alla sidor fungerar – inga döda interna länkar, inga trasiga ankarlänkar och inga länkar som av misstag pekar mot staging- eller localhost-adresser från utvecklingen
• Alla formulär går att skicka in och hamnar faktiskt där de ska (testa med en riktig inskickning, inte bara en visuell koll av formuläret)
• Autosvar och bekräftelsemejl som triggas av formulär skickas korrekt och hamnar inte i skräpposten
• En anpassad 404-sida finns, är formgiven i linje med resten av sajten och erbjuder en väg vidare (sökruta, länkar till viktiga sidor, navigering) – inte ett kalt serverfel
• Favicon är inställd och visas korrekt i webbläsarflikar och bokmärken
• SSL-certifikatet är aktivt och giltigt, och sajten laddas på https:// utan varningar i webbläsaren – kontrollera detta på den faktiska livedomänen, inte bara i staging-miljön
• HTTP omdirigeras automatiskt till HTTPS, och www- respektive icke-www-versionen pekar mot en och samma version istället för att båda fungerar som separata URL:er
• Mobilanpassningen är testad på riktiga enheter, inte bara genom att dra i kanten på ett skrivbordsfönster – det visar varken rätt storlek på klickytor, hur mobilens tangentbord beter sig eller hur formulär faktiskt ser ut på en telefon
• Sajten är testad i de webbläsare er faktiska målgrupp använder, inte bara den ni själva utvecklar i
• Kontaktuppgifter, telefonnummer och adresser på sajten stämmer och är aktuella
• Test över flera enheter inkluderar surfplattor om er trafikstatistik visar att det är ett relevant format

Säkerheten kring en lansering förtjänar ett eget avsnitt utöver det som får plats här – sådant som backup-rutiner, brandväggsregler och de specifika attackvektorer som riktar sig mot nyss lanserade sajter. Vi går igenom det mer på djupet i vår guide om grundläggande webbplatssäkerhet; se punkterna ovan som minimikravet för lanseringsdagen, inte hela bilden av ett komplett säkerhetsupplägg.

SEO-grunderna

SEO-misstag vid lansering hör till de dyraste att rätta till i efterhand, eftersom sökmotorerna redan hunnit indexera – eller misslyckats med att indexera – den version av sajten de först hittade.

• Varje sida har en unik och beskrivande title-tagg och metabeskrivning – inga sidor med kvarglömda standardtexter från CMS:et eller dubblerade titlar på sajten
• XML-sitemapen är genererad, korrekt och inskickad till Google Search Console (och Bing Webmaster Tools, om den trafiken spelar roll för er)
• robots.txt är korrekt konfigurerad och blockerar inte sajten. Det här är ett av de vanligaste och dyraste misstagen som görs vid lansering: en kvarglömd rad med "Disallow: /" från staging-miljön säger tyst åt sökmotorerna att inte crawla någonting alls, och en sajt kan ligga osynlig för Google i veckor innan någon ens märker att trafiken uteblir. Kontrollera filen direkt på livedomänen, både före och efter lansering.
• Inga kvarglömda "noindex"-taggar finns på sidor som ska vara sökbara – dessa läggs ofta till under utvecklingen för att hålla staging-sidor borta från sökresultaten och glöms sedan kvar när sajten går live
• Om det rör sig om en omdesign eller migrering: 301-omdirigeringar är på plats från varje gammal URL som hade trafik, ranking eller bakåtlänkar till sin nya motsvarighet – en kartlagd lista från gammal till ny URL, inte en generell omdirigering till startsidan
• Canonical-taggar är korrekt inställda, särskilt om det finns risk för duplicerat innehåll (parametriserade URL:er, filtrerade kategorisidor och liknande)
• Strukturerad data (schema-markup), där det används, validerar utan fel
• Analys- och konverteringsspårning är installerad och verifierad före lansering, inte kontrollerad för första gången efteråt – skicka in en riktig testinskickning eller ett testköp och bekräfta att det syns i både analysverktyget och annonsplattformarna innan sajten räknas som live. Spårningsluckor som upptäcks efter lansering innebär permanent förlorad data för den perioden – den går inte att fånga in i efterhand.

Juridik och regelefterlevnad

De här punkterna är lätta att nedprioritera under lanseringsstress, men de innebär en verklig juridisk och förtroenderelaterad risk – särskilt för sajter med besökare inom EU. I Sverige är det Integritetsskyddsmyndigheten (IMY) som är tillsynsmyndighet för GDPR och som kan agera om något brister.

• Integritetspolicyn är publicerad, korrekt och beskriver vad sajten faktiskt gör med besökarnas data – inte en generisk mall som hänvisar till verktyg eller databehandling som sajten inte ens använder
• Cookiebannern fungerar som den ska: den blockerar icke nödvändiga kakor och spårningsskript tills samtycke lämnats, och visar inte bara en banner medan allt annat laddas i bakgrunden ändå
• Allmänna villkor är publicerade om sajten innefattar köp, användarkonton eller användargenererat innehåll
• Grundläggande tillgänglighetskontroller är gjorda: tillräcklig färgkontrast, tangentbordsnavigering fungerar för interaktiva element, formulärfält har korrekta etiketter och bilder har relevant alt-text (mer om det nedan)
• Om verksamheten är verksam inom en reglerad bransch finns nödvändiga upplysningar eller licensuppgifter på plats och är aktuella

Innehållskvalitet

Innehållsproblem är de som en vanlig besökare lättast upptäcker, vilket gör dem extra skadliga för trovärdigheten även när de är små.

• En dedikerad korrekturläsning av varje sida – inte bara de sidor teamet tittar mest på, eftersom det ofta är de "tråkiga" sidorna som sidfoten, juridiska sidor och äldre blogginlägg där stavfel ligger kvar obemärkt
• All platshållartext och lorem ipsum är helt borttagen – kolla särskilt sidor med mindre trafik, bekräftelsemeddelanden i formulär och felmeddelanden, där sådan text oftast blir kvar
• Alla bilder har riktig, beskrivande alt-text – inte tomma fält och inte bara filnamnet (som "IMG_4821.jpg"). Tom eller filnamnsbaserad alt-text missar både tillgänglighet och SEO på samma gång, eftersom det varken ger skärmläsaranvändare något användbart eller ger sökmotorerna någon signal om vad bilden föreställer.
• Rubriker används i logisk ordning (H1, sedan H2:or, sedan H3:or under dem) istället för att bara vara visuellt formgivna utan rätt struktur under ytan
• Eventuell prissättning, datum eller tillgänglighetsinformation på sajten stämmer per lanseringsdagen
• Författarnamn, datum och bylines på blogginnehåll är korrekta och inte kvarlämnade platshållarvärden

Prestanda

En långsam sajt gör att allt annat ni fixat på listan spelar mindre roll – besökare studsar iväg innan de ens hinner se det polerade innehållet eller de fungerande formulären.

• Sidhastigheten är testad på både dator och mobil med ett verktyg som Google PageSpeed Insights eller GTmetrix – på livedomänen, inte på staging
• Bilderna är korrekt komprimerade och levereras i moderna format (WebP där det stöds) istället för att laddas upp i full kamera- eller designfilsupplösning
• Oanvända skript, plugins eller spårningstaggar från utvecklingen är borttagna istället för att följa med ut i produktion
• Cachning och CDN är konfigurerat där det är relevant utifrån sajtens trafik och målgruppens geografiska spridning
• Core Web Vitals (laddningstid, interaktivitet, visuell stabilitet) ligger inom godkända intervall, eftersom de påverkar både användarupplevelsen och sökrankingen

Inför lansering och de första 48 timmarna

Checklistan ovan minskar risken, men den eliminerar den inte – ingen mängd kvalitetskontroll före lansering fångar allt, eftersom verklig trafik beter sig annorlunda än testtrafik. Några rutiner gör själva lanseringsögonblicket säkrare:

• Där det är praktiskt möjligt: kör en mjuk lansering eller en stegvis utrullning – låt en mindre andel av trafiken eller ett specifikt segment se den nya sajten först, istället för att växla över alla besökare samtidigt
• Ha en återställningsplan definierad och testad innan lansering – vet exakt hur ni skulle återställa DNS eller den tidigare versionen om något kritiskt går sönder, och vem som är ansvarig för att fatta det beslutet
• Bevaka noga de första 24–48 timmarna: serverfel, volymen inskickade formulär, trafikmönster i analysverktyget och eventuella övervaknings- eller drifttidslarm – utgå inte från att tystnad betyder att allt fungerar
• Håll teamet eller personen som byggde sajten nåbar under det här fönstret – problem som upptäcks på timme tre av en lansering är betydligt billigare att åtgärda än problem som upptäcks en vecka senare, när trafik och sökmotorer redan hunnit reagera på ett trasigt läge
• Gör en sista genomgång av den skarpa sajten efter att DNS har hunnit sprida sig fullt ut, eftersom vissa problem (varningar om blandat innehåll, cachade gamla versioner, omdirigeringsloopar) bara syns när domänen faktiskt pekar mot den nya sajten

De flesta punkterna här tar bara någon minut att kontrollera var för sig. Det som får lanseringar att gå fel är sällan att en enskild kontroll är svår – det är att teamet under deadline-press hoppar över hela checklistan och litar på att allt ser bra ut. Det gör det oftast också. Problemen på den här listan är, nästan per definition, de som inte gör det.

Om ni förbereder en lansering eller omlansering och vill ha ett utomstående team som kör igenom hela processen åt er, ingår den här typen av kontroll före lansering som en standarddel av vår tjänst skräddarsydd webbdesign. Hör gärna av er via kontaktsidan om ni vill ha ett par extra ögon som granskar innan ni går live.