Sjekkliste før lansering – ta en dokumentert go/no-go

En nettside er ikke klar fordi forsiden «ser ferdig ut». Den er klar når virksomheten vet hvem som eier lanseringen, hvilke krav som er testet, hvilke avvik som aksepteres og hvordan løsningen tas tilbake hvis kritisk funksjon feiler.

Bruk denne sjekklisten som en go/no-go-gate. Tilpass den til løsningen: en enkel presentasjonsside trenger ikke samme testomfang som en nettbutikk, innloggingstjeneste eller side som behandler helseopplysninger.

For en behandlingspraksis bør dere i tillegg bruke avgrensningene for nettside, skjema og e-post for psykolog eller klinikk .

Først: utpek eier og stopp ukontrollerte endringer

Registrer:

• lanseringsansvarlig og endelig beslutningseier
• teknisk ansvarlig, innholdseier og personvernansvarlig
• leverandørkontakter og eskaleringsvei
• planlagt tidspunkt og tidssone
• hva som inngår og uttrykkelig ikke inngår i lanseringen
• kritiske feil som stopper åpning
• rollbackfrist og fremgangsmåte

Frys design- og funksjonsendringer før sluttkontrollen. Nye «småting» etter godkjenning gjør testresultatet ugyldig og øker risikoen for uforutsette feil.

1. Kontroller eierskap og tilganger

Fjern testbrukere, gamle byråtilganger, standardpassord og midlertidige administratorer. Secrets skal ikke ligge i repository, HTML, supportsaker eller delte dokumenter.

2. Verifiser domene, DNS og HTTPS

• riktig A, AAAA eller CNAME svarer for alle offentlige vertsnavn
• www og rotadressen følger valgt hovedvariant
• HTTP går til riktig HTTPS-adresse uten redirect-loop
• sertifikatet dekker alle navn, har gyldig kjede og kan fornyes
• ingen aktive sider laster ressurser over HTTP
• MX, SPF, DKIM og DMARC er ikke utilsiktet endret under weboppsettet
• DNSSEC er valid hvis det brukes
• CAA tillater sertifikatutstederen som faktisk skal fornye
• staging- og origin-adresser er ikke eksponert uten behov

Test fra et eksternt nettverk, ikke bare fra serveren selv. Sjekk både IPv4 og IPv6 hvis begge publiseres. Bruk DNS-planen for et nytt nettsted , HTTPS-guiden og oppskriften for å sjekke DNS-poster ved avvik.

3. Test de kritiske brukerreisene ende til ende

Lag en tabell med forventet resultat, testdata og testbevis. Eksempler:

En grønn forside eller HTTP-status 200 beviser ikke at kunden kan fullføre oppgaven. Bruk tydelig merkede testordre og avklar hvordan de kanselleres, refunderes og slettes.

Test feilsituasjoner også: ugyldig input, manglende samtykke, avvist betaling, utløpt lenke og utilgjengelig tredjepart. Feilmeldingen skal hjelpe brukeren uten å avsløre tekniske detaljer.

4. Gå gjennom innholdet som virksomheten står ansvarlig for

• firmanavn, organisasjonsnummer og kontaktopplysninger er riktige
• priser, merverdiavgift, frakt og abonnement er presentert for riktig målgruppe
• tjenester, åpningstider, ansatte og geografisk dekning er oppdatert
• vilkår, personvern, retur og andre pliktopplysninger passer tilbudet
• bilder, fonter, video og tekst har dokumentert bruksrett
• ingen testdata, plassholdertekst eller interne notater er publisert
• påstander, sertifiseringer, kundeuttalelser og sammenligninger kan dokumenteres
• telefon, e-post, kart, sosiale lenker og nedlastinger virker

Les som en ny kunde. Språkvask fanger ikke opp at et gammelt telefonnummer er juridisk eller kommersielt feil.

5. Dokumenter personvern og cookies

Kartlegg dataflyten før lansering:

Test skjema med minst mulig data, tydelig informasjon og en reell mottaker. Sørg for at e-postvarsler ikke unødvendig gjengir følsomme opplysninger.

For cookies og lignende sporing må dere vite hvilke teknologier som aktiveres før valg. Datatilsynet oppgir at samtykke til ikke-nødvendig lagring eller tilgang skal være frivillig, spesifikt, informert, utvetydig, dokumenterbart og like lett å trekke tilbake som å gi. Se Datatilsynets gjeldende cookie-veiledning .

Kontroller i en ny nettleserøkt at valgfrie scripts, piksler og tredjepartsinnhold faktisk blokkeres før samtykke. «Vi bruker cookies»-tekst alene er ikke en samtykkeløsning. Strengt nødvendige teknologier og valgt lagring må beskrives presist.

Bruk den trinnvise testen for cookies og samtykke til å validere førstebesøk, avvisning, delvalg og tilbaketrekking i nettverksloggen.

6. Test tilgjengelighet manuelt og automatisk

Start med om løsningen er omfattet av norsk regelverk og hvilke krav som gjelder. Uu-tilsynet publiserer en filtrerbar oversikt over WCAG-krav for privat og offentlig sektor . Avklar strengere kontrakts- eller sektorkrav separat.

Kontroller minst:

• alle funksjoner med tastatur, inkludert synlig fokus og logisk rekkefølge
• overskrifter, landemerker, lister og tabeller med riktig semantikk
• tilgjengelig navn, instruksjon og feil for alle skjemafelt
• tekstalternativ for meningsbærende bilder og tom alt-tekst for dekorative
• kontrast i normal, hover, fokus, deaktivert og feiltilstand
• zoom, tekstforstørrelse, liten mobilbredde og begge visningsretninger
• video, lyd, bevegelse, timeout og innhold som oppdateres dynamisk
• forståelig språk, lenketekst og konsekvent navigasjon

Automatiske verktøy finner bare visse maskinlesbare feil. En poengsum fra Lighthouse eller axe er ikke dokumentasjon på full samsvar. Ta vare på testomfang, funn, alvorlighet, eier og frist.

7. Kontroller søkesynlighet og URL-er

• hver indekserbar side har riktig statuskode og selvrefererende eller planlagt canonical
• title, hovedoverskrift og beskrivelse stemmer med faktisk innhold og søkeintensjon
• gamle publiserte URL-er har relevante permanente redirects ved endring
• ingen viktige sider har utilsiktet noindex
• robots.txt blokkerer ikke sider eller ressurser som skal crawles
• sitemap inneholder kanoniske, indekserbare URL-er med riktige vertsnavn
• interne lenker peker direkte til endelig URL uten unødige redirectledd
• språk- og landvarianter er konsistente hvis de finnes
• strukturert data beskriver synlig innhold og består syntakskontroll
• Search Console-eierskap og tilgang ligger hos virksomheten

Google presiserer at robots.txt styrer crawling, ikke er en pålitelig metode for å hindre indeksering. Bruk autentisering for privat staging og kontroller eventuelle noindex-regler før åpning. Se Googles robots-veiledning og sitemap-krav .

Send sitemap når løsningen er offentlig og stabil. Indeksering er ikke øyeblikkelig og kan ikke garanteres av innsendingen.

8. Mål ytelse og kapasitet på riktig måte

• ta en laboratoriemåling av representative sidetyper på mobil og desktop
• kontroller LCP-element, INP-risiko og layoutskift, ikke bare totalscore
• mål serverens svartid, cache og tredjepartsavhengigheter
• test bilder, fonter og scripts på tregere nettverk og en moderat enhet
• sett budsjetter for sidevekt og tredjepartskode
• gjennomfør avtalt lasttest på testmiljø ved forventede topper
• aktiver feltmåling uten å bryte samtykke- eller personvernkrav

Ikke gjør en stor optimalisering rett før åpning uten ny funksjonstest. Bruk måleprosessen for nettsidehastighet og noter baseline for sammenligning etter lansering.

9. Gjør sikkerhetskontrollen konkret

• alle komponenter og versjoner er inventarført og vedlikeholdt
• admin-, hosting-, DNS- og e-postkontoer har minste nødvendige tilgang
• MFA er aktivert for privilegerte kontrollkontoer der det støttes
• test-, debug- og katalogvisning er av
• hemmeligheter og API-nøkler er produksjonsverdier fra sikkert lager
• opplasting, filtyper og størrelse er begrenset etter behov
• sikkerhetsheadere er testet mot faktisk funksjon
• logger og varsler har navngitt mottaker
• sårbarhets- og hendelsesvei er dokumentert
• avhengigheter og eksterne scripts er godkjent

Kjør aldri en aggressiv skanner mot produksjon uten avtale og plan. Et automatisk funn må valideres, og fravær av funn er ikke en friskmelding.

10. Bevis at backup og rollback virker

«Daglig backup aktivert» er ikke et akseptansekriterium. Dokumenter:

• hvilke data, filer, innstillinger og secrets som kan gjenopprettes
• maksimalt akseptabelt datatap og nedetid
• tidspunkt og konsistens for siste kopi før lansering
• hvem som kan starte restore og hvor lang tid testen tok
• at minst én kopi er beskyttet mot samme konto eller feil
• nøyaktig versjon eller deploy som rollback går til
• hva som skjer med nye ordre eller skjemadata etter åpning

Gjennomfør en full restore-test når risikoen tilsier det. En kode-rollback alene gjenoppretter ikke nødvendigvis database, opplastinger eller tredjepartsinnstillinger.

11. Ta go/no-go-beslutningen

Samle åpne avvik i én beslutningslogg:

Beslutningseier signerer go, no-go eller et eksplisitt, tidsbegrenset avvik. Kritiske brukerreiser, personvernbrudd, ukjent datatap eller manglende rollback bør ikke gjemmes i en generell «ser bra ut»-godkjenning.

12. Kjør lanseringen som en tidsstemplet runbook

1. Bekreft backup, restoretilgang og rollbackpunkt.
2. Stopp uavtalte endringer og publiseringer.
3. Ta siste nødvendige datasynkronisering.
4. Publiser produksjonsversjonen.
5. Gjør eventuelle DNS- eller rutingendringer.
6. Kjør kritiske tester fra utsiden.
7. Kontroller logger, varsler, skjema, e-post og transaksjoner.
8. Bekreft robots, noindex, canonical og sitemap på produksjonsadressen.
9. Noter resultat, tidspunkt og ansvarlig for hvert steg.
10. Åpne trafikk og kommunikasjon gradvis når plattformen støtter det.

Ikke slett staging, gammel løsning eller rollbackpunkt før observasjonsperioden er ferdig og eventuelle nye data er sikret.

Etter lansering

Første time

• overvåk feilrate, svartid, logger og kritiske brukerreiser
• test skjema eller testordre på produksjon
• kontroller DNS, HTTPS og begge vertsvarianter utenfra
• følg support og varsler tett

Første døgn

• sammenlign trafikk, konvertering og feil mot baseline
• se etter manglende e-post, webhooks og bakgrunnsjobber
• kontroller indekseringssignaler og uventede 404-er
• gjennomgå nye persondata og sletteflyt

Første uke

• prioriter faktiske brukerproblemer og målte avvik
• lukk eller forleng dokumenterte unntak
• oppdater driftsdokumentasjon og vedlikeholdsregister
• gjennomfør en kort etterkontroll med eiere og leverandører

Lansering av nettsiden Vymo lager

For Vymos enkle standardnettside håndterer Vymo oppsett og publisering, mens bedriften leverer og godkjenner navn, tekst, kontaktinformasjon og eventuelle bilder. Tilbudet er ikke et selvbetjent webhotell eller en generell lanseringstjeneste for eksisterende WordPress- og nettbutikkløsninger.

Bedriften må fortsatt kontrollere at innhold, priser, rettigheter, kontaktdata og personvernopplysninger er riktige. Se leveranseomfang og begrensninger , eller beskriv særskilte krav til tilgjengelighet, integrasjoner og godkjenning før bestilling.