En søndag ettermiddag i september 2022 tok noen seg inn i publiseringssystemet (CMS) til Fast Company og erstattet hver eneste overskrift på forsiden med en uanstendig, rasistisk melding. Teamet tok nettstedet ned og fikk det opp igjen omtrent to timer senere. To dager senere sendte den samme angriperen lignende meldinger til Fast Companys Apple News-følgere, og nettstedet endte opp med å være nede i åtte dager.
Det er den dramatiske versjonen. Hverdagsversjonen er langt mer lavmælt. En utrulling produksjonssetter en priskomponent som viser en helt tom tabell. En CMS-redaktør publiserer et utkast med plassholdertekst i hero-seksjonen. Noen gjenoppretter fjorårets personvernerklæring i forsøket på å rette en skrivefeil. Ingen personsøker piper, for serveren svarer og hver eneste side laster feilfritt.
Jeg jobber i Page Deltas – et verktøy de fleste team bruker til å følge med på andre selskapers nettsteder. Dette innlegget handler om å rette verktøyet mot ditt eget: hvilke sider du bør overvåke, hvordan du briefer AI-filteret slik at det forstår hva som er feil, hvordan du utløser en sjekk etter hver utrulling, og hvor grensene for verktøyet går.
Hvorfor de andre verktøyene dine overser det
De fleste nettsteder har allerede en oppetidsovervåker (uptime monitor). Den stiller ett enkelt spørsmål: svarer siden? Og en hacket forside (defacement) svarer helt utmerket. Det samme gjør en prisside med en ødelagt tabell. Oppetidssjekker er fantastiske til å fortelle deg at lyset er gått. De kan bare ikke fortelle deg at noen har malt om veggene.
Verktøy på serversiden har en annen blind flekk. En filintegritetsovervåker passer på dine egne lokale filer: den merker derfor ikke når et tredjepartsskript (en chatwidget, en tag manager eller en annonsesnutt) endrer det de besøkende faktisk ser. Den oppdager heller ikke en DNS-kapring, der domenet ditt peker til en annen server mens dine egne servere er urørte. Visualpings veiledning om defacement av nettsteder poengterer nøyaktig det samme, og de har helt rett: deteksjon må vurdere hva siden faktisk viser en besøkende.
Det er akkurat det en endringsovervåker for nettsteder gjør. Den henter siden utenfra, nøyaktig slik en besøkende ville gjort, og sammenligner den med forrige kontroll. Spørsmålet du stiller blir: «har denne siden endret seg på en måte vi ikke hadde planlagt?»
Hvilke sider bør du følge med på?
Du trenger ikke å overvåke hele nettstedet. Start med sidene der en uønsket endring raskest koster penger eller tillit, og der en besøkende sannsynligvis ville lagt merke til feilen før deg.
| Side | Hvordan en skadelig endring ser ut | Hva du bør skrive i briefen |
|---|---|---|
| Forside | Erstattet overskrift, tekst på et språk du ikke publiserer på, lenker til ukjente domener | Varsle om enhver endring i overskrift, hero-tekst eller primær call-to-action (CTA) |
| Priser | Manglende planer, feil pris, tom tabell | Varsle om enhver endring i pris, plan eller grenser |
| Viktigste landingssider | Plassholdertekst, manglende seksjoner | Varsle når en seksjon forsvinner eller plassholdertekst dukker opp |
| Vilkår og personvern | Gammel versjon gjenopprettet, manglende klausuler | Varsle om enhver klausul som legges til, fjernes eller omformuleres |
| Ditt sitemap | Nye URL-er ingen i teamet ditt har publisert | Ingen brief nødvendig, ettersom sitemap-overvåkere ganske enkelt lister opp de nye URL-ene |
De fire første radene er sideovervåkere. Den siste er en sitemap-overvåker, som slår alarm når nye URL-er dukker opp i ditt sitemap.xml. Det hjelper mot en helt spesifikk type angrep: den typen som i det stille oppretter hundrevis av spamsider under ditt domene, forutsatt at publiseringssystemet legger disse sidene til i sitemappet.
Gratisabonnementet gir deg 10 overvåkede URL-er, og en sitemap-overvåker teller som én. Det dekker forsiden, prissiden, tre sentrale landingssider, to juridiske sider og sitemappet – med to plasser til overs.
Oppsettet
Oppsettet følger samme fremgangsmåte som i vår guide om hvordan du overvåker nettsideendringer, med en viktig vri: her beskriver du hva som aldri skal skje, snarere enn hva du håper å se.
1. Legg til sidene dine med en brief
Opprett en gratis konto, klikk på New monitor (Ny overvåker), og lim inn URL-en. Beskrivelsesfeltet er prompten som vår LLM leser for å vurdere om en endring betyr noe: skriv det som en instruks til en kollega som passer på siden for deg.
For din egen forside fungerer en instruks som dette utmerket:
Vår egen forside (example.com). Vi endrer den sjelden utenfor en utrulling.
Varsle meg om enhver endring i hovedoverskriften, hero-teksten, primær CTA eller priser.
Varsle meg dersom det dukker opp tekst som ikke har noe med produktet vårt å gjøre, er støtende
eller skrevet på et språk vi ikke publiserer på.
Ignorer roterende kundelogoer og teaseren for nyeste blogginnlegg.Ekskluderingslinjen gjør mer nytte enn man skulle tro. Nesten hver eneste side har et element som endrer seg av seg selv: hvis du ikke nevner det uttrykkelig, vil du bruke den første uken på å få unødige varsler om det.
2. Send varsler til to uavhengige steder
Åpne Channels (Kanaler) og velg hvor varslene skal sendes. Slack, Discord og Microsoft Teams krever URL-en til en innkommende webhook. For e-post må mottakeren først bekrefte en verifiseringsmelding, og en signert webhook kan mate dine egne interne systemer. Klikk på Send test for hver kanal for å sjekke at alt fungerer.
For ditt eget nettsted anbefaler jeg å koble til to kanaler av ulik type, for eksempel Slack pluss et e-postalias for den som har vakt. Hvert varsel sendes bare én gang per kanal uten automatiske gjentakelser: en ekstra kanal sikrer at en midlertidig feil hos Slack ikke skjuler en kompromittert forside.
3. Kjør en sjekk rett etter hver utrulling
I Page Deltas angir du ikke en fast sjekkfrekvens. Tidsplanen er adaptiv: sider som endrer seg ofte sjekkes hyppigere og rolige sider sjeldnere, mens betalte planer prioriteres i travle perioder. Din egen forside er vanligvis veldig rolig – noe som er det stikk motsatte av hva du ønsker rett etter en endring.
Løsningen er å utløse sjekken selv. Hver overvåker har en Check now (Sjekk nå)-knapp, og samme handling er tilgjengelig via API-et, slik at du kan legge inn et enkelt kall på slutten av deployment-pipelinen din:
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-nowManuelle sjekker er begrenset til én per minutt per overvåker, noe som holder i massevis for utrullinger. Du oppretter nøkkelen under Settings > API keys (krever rollen editor eller admin). Den vises bare én gang, så lagre den direkte i CI-hemmelighetene dine. Artikkelen vår om hvordan du gjør et nettsted om til et endrings-API dekker resten av API-et hvis du også vil automatisere opprettelsen av overvåkere.
Hva du gjør når et varsel lander
Når systemet er i drift, genererer en vesentlig endring én samlet melding med et lettfattelig sammendrag samt før- og etter-skjermbilder. Hvis du bruker den signerte webhooken, ser meldingen slik ut (verdiene er fiktive eksempler):
{
"event": "change.detected",
"monitor_id": "01HW2X...",
"monitor_url": "https://example.com/pricing",
"monitor_name": "Vår prisside",
"change_id": "...",
"detected_at": "2026-10-08T07:12:00Z",
"summary": "Pro- og Business-planene vises ikke lenger. Pristabellen viser nå bare Free-planen.",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}De fleste varslene på ditt eget nettsted vil være endringer teamet ditt selv har gjort. Det er helt uproblematisk og nyttig: et raskt svar i tråden som «det var oss, rullet ut i dag» gjør kanalen til en løpende logg over hva som gikk live og når. Det avgjørende varselet er det ingen i teamet kjenner igjen.
Når det skjer, hjelper skjermbildene på to måter: de viser nøyaktig hva besøkende ser i det øyeblikket, og de fungerer som daterte bevis på hendelsen som sikkerhetsteamet eller forsikringsselskapet kan etterspørre senere. Historikken lagres i 14 dager på Free og lenger på betalte abonnementer (30 dager på Starter, opptil 730 på Scale) – last ned det du har behov for å ta vare på.
Noen ganger kommer det første varselet ikke fra et internt system i det hele tatt, men fra en kunde som legger ut et skjermbilde i sosiale medier. Hvis du også vil fange opp det, sender søsterproduktet vårt KWatch.io varsler når merkevaren din nevnes på Reddit, X, LinkedIn, Facebook og Hacker News.
Hvor grensene går
Det er enkelte situasjoner dette oppsettet ikke vil fange opp, og dem bør du være klar over før du stoler blindt på det.
Vi sammenligner hovedteksten på hver side. Navigasjon, bunntekst og annonser filtreres bort før sammenligningen: en spamplenke lagt inn i bunnteksten din vil derfor ikke bli oppdaget. Det samme gjelder rent visuelle endringer, som et byttet logobilde der teksten er uforandret.
Det er heller ikke en oppetidsovervåker. Hvis nettstedet ditt går ned, feiler sjekkene i stedet for å sende innholdsvarsler, og etter 10 feil på rad pauses overvåkeren automatisk og administratorene dine får beskjed. Det er altfor tregt for et driftsavbrudd – behold det vanlige oppetidsverktøyet ditt for den delen.
Mellom utrullinger oppdages endringer ved neste planlagte kontroll, og det finnes ikke noe fast garantert intervall. Hvis du trenger en garantert kontroll med få minutters mellomrom på en kritisk side, lar Visualping deg angi frekvensen per side og egner seg bedre der. Vi ser dessuten bare offentlige sider: alt bak en innlogging forblir utilgjengelig.
Til slutt: Page Deltas forteller deg at noe er endret. Verktøyet forteller deg ikke hvordan en angriper kom seg inn – det er fortsatt en jobb for de dedikerte sikkerhetsverktøyene dine.
Start med forsiden din
Legg til forsiden og prissiden først, tilpass briefen ovenfor med dine egne unntak, og send et testvarsel til begge kanaler. Legg deretter til check-now-kallet i utrullingsskriptet ditt. Gratisplanen dekker 10 URL-er eller sitemaps med AI-filtrering, alle fem varslingskanaler og API-tilgang – helt uten kredittkort. Start overvåking gratis.
Julien, produktsjef i Page Deltas
