Så bevakar du din egen webbplats för oväntade ändringar

En söndagseftermiddag i september 2022 tog sig någon in i Fast Companys innehållshanteringssystem (CMS) och ersatte varje rubrik på startsidan med ett obscent och rasistiskt meddelande. Teamet stängde ner webbplatsen och fick upp den igen ungefär två timmar senare. Två dagar senare skickade samma angripare liknande meddelanden till Fast Companys Apple News-följare, och sajten blev till slut liggande nere i åtta dagar.

Det är den dramatiska versionen. Vardagsversionen är betydligt tystare. En deploy driftsätter en priskomponent som renderar en helt tom tabell. En CMS-redaktör publicerar ett utkast med platshållartext i hero-sektionen. Någon återställer förra årets integritetspolicy i samband med att ett stavfel rättas till. Ingen personsökare piper, eftersom servern svarar och alla sidor laddas felfritt.

Jag arbetar på Page Deltas – ett verktyg de flesta team använder för att hålla koll på andra företags webbplatser. Det här inlägget handlar om att rikta verktyget mot din egen webbplats: vilka sidor du bör bevaka, hur du briefar AI-filtret så att det förstår vad som är fel, hur du triggar en kontroll efter varje deploy och var verktygets begränsningar går.

Varför dina andra verktyg missar det

De flesta webbplatser har redan en upptidsbevakning (uptime monitor). Den ställer en enda fråga: svarar sidan? Och en vandaliserad startsida (defacement) svarar alldeles utmärkt. Det gör även en prissida med en trasig tabell. Upptidsbevakningar är fantastiska på att tala om att lampan är släckt. De kan däremot inte berätta att någon har målat om väggarna.

Verktyg på serversidan har en annan blind fläck. En filintegritetsmonitor vakar över dina egna filer: den märker alltså inte när ett tredjepartsskript (en chattwidget, en tagghanterare eller en annonssnutt) förändrar vad besökarna faktiskt ser. Den märker inte heller en DNS-kapning, där din domän pekar mot en annan server medan dina egna servrar förblir orörda. Visualpings guide om website defacement belyser precis samma sak, och de har helt rätt: upptäckten måste utgå från vad sidan faktiskt visar för en besökare.

Det är precis vad en webbplatsändringsbevakning gör. Den hämtar sidan utifrån, precis som en besökare skulle göra, och jämför den med föregående kontroll. Frågan du ställer blir: "har den här sidan förändrats på ett sätt vi inte hade planerat?"

Vilka sidor bör du hålla koll på?

Du behöver inte bevaka hela sajten. Börja med de sidor där en felaktig ändring snabbast förstör intäkter eller förtroende, och där en besökare sannolikt skulle upptäcka felet före dig.

Sida	Hur en skadlig ändring ser ut	Vad som ska stå i briefen
Startsida	Ersatt rubrik, text på ett språk du inte publicerar på, länkar till okända domäner	Larma vid alla ändringar av rubrik, hero-text eller primär call-to-action (CTA)
Priser	Saknade planer, fel pris, tom tabell	Larma vid ändringar av pris, plan eller gränser
Viktigaste målsidor	Platshållartext, saknade avsnitt	Larma när ett avsnitt försvinner eller platshållartext dyker upp
Villkor och integritet	Gammal version återställd, klausuler saknas	Larma vid alla tillagda, borttagna eller omformulerade klausuler
Din sitemap	Nya URL:er som ingen i ditt team har publicerat	Ingen brief behövs, eftersom sitemap-bevakningar helt enkelt listar de nya URL:erna

De fyra första raderna är sidbevakningar. Den sista är en sitemap-bevakning, som larmar när nya URL:er dyker upp i din sitemap.xml. Det skyddar mot en mycket specifik typ av angrepp: sådana som i tysthet skapar hundratals spamsidor under din domän, under förutsättning att ditt CMS lägger till dessa i sitemapen.

Gratisplanen ger dig 10 bevakade URL:er, och en sitemap-bevakning räknas som en. Det täcker din startsida, prissida, tre viktiga målsidor, två juridiska sidor och din sitemap – och lämnar två platser över.

Konfigurationen

Upplägget är detsamma som i vår guide om hur man bevakar webbplatsändringar, med en viktig skillnad: här beskriver du vad som aldrig får hända, snarare än vad du hoppas få se.

1. Lägg till dina sidor med en brief

Skapa ett gratis konto, klicka på New monitor (Ny bevakning) och klistra in URL:en. Beskrivningsfältet är prompten som vår LLM läser för att avgöra om en ändring är viktig: skriv det som en instruktion till en kollega som vakar över sidan åt dig.

För din egen startsida fungerar en brief som denna utmärkt:

Vår egen startsida (example.com). Vi ändrar den sällan utanför en release.
Larma mig vid alla ändringar av huvudrubriken, hero-texten, primär CTA eller priser.
Larma mig om det dyker upp text som inte har med vår produkt att göra, är stötande
eller är på ett språk vi inte publicerar på.
Ignorera roterande kundlogotyper och teasern för senaste blogginläggen.

Undantagsraden gör mer nytta än man kan tro. I stort sett varje sida har en komponent som ändrar sig av sig själv: om du inte nämner den uttryckligen kommer du att tillbringa första veckan med att få onödiga larm om den.

2. Skicka aviseringar till två oberoende destinationer

Öppna Channels (Kanaler) och välj var aviseringarna ska landa. Slack, Discord och Microsoft Teams tar emot en inkommande webhook-URL. För e-post måste mottagaren först bekräfta ett verifieringsmeddelande, och en signerad webhook kan mata dina egna interna system. Klicka på Send test (Skicka test) för varje kanal så att du vet att det fungerar.

För din egen webbplats rekommenderar jag att koppla två kanaler av olika typ, till exempel Slack plus ett e-postalias för den som har beredskap. Varje larm skickas en enda gång per kanal utan automatiska omförsök: en extra kanal säkerställer att en tillfällig driftstörning hos Slack inte döljer en vandaliserad startsida.

3. Gör en kontroll direkt efter varje deploy

I Page Deltas ställer du inte in ett fast kontrollintervall. Schemat är adaptivt: sidor som ändras ofta kontrolleras oftare och lugna sidor mer sällan, och betalda planer prioriteras när kön är full. Din egen startsida är oftast väldigt lugn – vilket är raka motsatsen till vad du vill ha precis efter att någon har rört den.

Lösningen är att trigga kontrollen själv. Varje monitor har en Check now (Kontrollera nu)-knapp, och samma åtgärd finns tillgänglig via API:et, så du kan lägga till ett anrop i slutet av din deploy-pipeline:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

Manuella kontroller är begränsade till en per minut och monitor, vilket räcker mer än väl för driftsättningar. Du skapar nyckeln under Settings > API keys (kräver rollen editor eller admin). Den visas bara en gång, så spara den direkt i din CI:s hemligheter. Vår artikel om hur du förvandlar en webbplats till ett change-API beskriver resten av API:et om du även vill automatisera skapandet av bevakningar.

Vad du gör när ett larm kommer in

När systemet är igång genererar en betydande ändring ett enskilt meddelande med en tydlig sammanfattning samt före- och efter-skärmdumpar. Om du använder den signerade webhooken ser meddelandet ut så här (värdena är fiktiva exempel):

{
  "event": "change.detected",
  "monitor_id": "01HW2X...",
  "monitor_url": "https://example.com/pricing",
  "monitor_name": "Vår prissida",
  "change_id": "...",
  "detected_at": "2026-10-08T07:12:00Z",
  "summary": "Pro- och Business-planerna visas inte längre. Pristabellen visar nu endast Free-planen.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

De flesta larm på din egen sajt kommer att röra ändringar ditt eget team har gjort. Det är helt i sin ordning och mycket användbart: ett snabbt svar i tråden som "det var vi, driftsatt idag" förvandlar kanalen till en löpande logg över vad som gick live och när. Det kritiska larmet är det som ingen känner igen.

När det inträffar hjälper skärmdumparna på två sätt: de visar exakt vad besökarna ser just nu, och de utgör ett daterat bevis på händelsen som ditt säkerhetsteam eller försäkringsbolag kan efterfråga senare. Historiken sparas i 14 dagar på Free och längre på betalda planer (30 dagar på Starter, upp till 730 på Scale) – ladda ner eventuella bevis du behöver arkivera.

Ibland kommer den första signalen inte alls från ett internt larm, utan från en kund som publicerar en skärmdump i sociala medier. Om du även vill fånga upp det skickar vår systerprodukt KWatch.io aviseringar så fort ditt varumärke nämns på Reddit, X, LinkedIn, Facebook och Hacker News.

Var gränserna går

Det finns vissa situationer denna uppsättning inte fångar upp, och dem bör du känna till innan du förlitar dig helt på den.

Vi jämför huvudtexten på varje sida. Navigering, sidfötter och annonser sorteras bort före jämförelsen: en spamlänk som injiceras i din sidfot kommer därför inte att synas. Detsamma gäller rent visuella förändringar, som en utbytt logotypbild där texten lämnats orörd.

Det är inte heller en upptidsbevakning. Om din sajt går ner misslyckas kontrollerna istället för att larma, och efter 10 misslyckanden i rad pausas monitorn automatiskt och administratörerna får ett meddelande. Det är alldeles för långsamt för ett driftstopp – behåll ditt vanliga upptidsverktyg för den saken.

Mellan deployer upptäcks en förändring vid nästa schemalagda kontroll, utan något garanterat fast intervall. Om du behöver en garanterad kontroll med några minuters mellanrum på en affärskritisk sida låter Visualping dig ange frekvensen per sida och passar bättre där. Vi ser dessutom endast offentliga sidor: allt bakom en inloggning förblir oåtkomligt.

Slutligen meddelar Page Deltas att något har ändrats. Verktyget talar inte om hur angriparen tog sig in – det förblir en uppgift för dina säkerhetsverktyg.

Börja med din startsida

Lägg till startsidan och prissidan först, anpassa briefen ovan med dina egna undantag och skicka ett testlarm till båda kanalerna. Lägg sedan till check-now-anropet i ditt deploy-skript. Gratisplanen täcker 10 URL:er eller sitemaps med AI-filtrering, alla fem larmkanaler och API-åtkomst – helt utan kreditkort. Börja bevaka gratis.

Julien, produktchef på Page Deltas