n8n web scraping i detekcija promjena: pouzdano pratite stranice, otkrivajte ažuriranja i pokrećite workflowe

# Što ćete izgraditi#

Ovaj vodič prikazuje produkcijski pristup za n8n monitoring detekcije promjena pri web scrapingu. Dohvatit ćete i parsirati HTML, normalizirati sadržaj tako da pratite samo smislene promjene, detektirati ažuriranja pomoću hashiranja i opcionalnog diffinga te slati upozorenja u Slack i Email.

Na kraju ćete imati n8n obrazac workflowa koji možete ponovno koristiti za cjenike, dokumente politika, oglase za posao, changelogove, kalendare događaja i praćenje konkurencije.

ℹ️ Napomena: Ako izvor nudi API, RSS feed ili webhook, prvo koristite to. Scraping je rezervna opcija kad ne postoji stabilna integracija.

# Preduvjeti#

Ako ste novi u n8n triggerima i webhook obrascima, krenite s n8n webhook tutorial. Za robusne operativne obrasce pročitajte n8n error handling retries alerting.

# Arhitektura: pouzdana petlja nadzora#

Pouzdan workflow za monitoring ima četiri odgovornosti:

1. 1
   Dohvatiti stranicu bez blokiranja i bez preopterećivanja servera.
2. 2
   Izdvojiti samo dio koji vam je bitan.
3. 3
   Normalizirati izdvojeni sadržaj kako biste uklonili šum.
4. 4
   Usporediti s prethodnom verzijom i obavijestiti samo kod smislenih promjena.

Praktičan obrazac je: Schedule Trigger → HTTP Fetch → Parse and Normalize → Hash and Compare → Store Snapshot → Route Alerts.

Preporučeni podatkovni model za svaki URL#

🎯 Ključna poruka: Tajna monitoringa s malo šuma nije “bolje scrapati” nego “bolje spremati”: održavajte stabilan normalizirani snapshot i uspoređujte ga dosljedno.

# Korak 1: Dohvat HTML-a s HTTP Request (i nemojte biti blokirani)#

Koristite Schedule Trigger (Cron) za pokretanje provjera. Za većinu slučajeva, 15 do 60 minuta je dovoljno. Ako scrapate češće od svakih 5 minuta na zaštićenoj stranici, vjerojatnost blokade naglo raste.

Postavke HTTP Request noda koje rade u produkciji#

Koristite HTTP Request node uz ova načela:

• Postavite realističan User-Agent.
• Pošaljite Accept-Language i Accept headere.
• Koristite timeout da izbjegnete zaglavljene egzekucije.
• Preferirajte conditional requestove s ETag i Last-Modified kad je podržano.

Primjer headera:

{
  "User-Agent": "Mozilla/5.0 (compatible; SamiodaMonitor/1.0; +https://samioda.com/en/automation)",
  "Accept": "text/html,application/xhtml+xml",
  "Accept-Language": "en-US,en;q=0.9"
}

Ako stranica daje ETag ili Last-Modified, spremite ih i vraćajte natrag koristeći If-None-Match i If-Modified-Since. To može značajno smanjiti bandwidth i opterećenje jer server može vratiti 304 Not Modified.

Obrasci rate limiting-a unutar n8n#

Ako nadzirete puno URL-ova, dodajte batching korak. n8n može slučajno izgledati kao paralelni crawler ako odjednom pokrenete puno itema.

Koristite Split In Batches node i dodajte Wait node za razmake:

💡 Savjet: Ako nadzirete 100 URL-ova svakih sat vremena uz 2 sekunde pauze, run traje oko 100 * 2 = 200 seconds plus vrijeme mreže. To je obično prihvatljivo i puno sigurnije nego paralelni dohvat.

Proxy, geo i CAPTCHA razmatranja#

Neke stranice blokiraju po IP reputaciji ili regiji. Proxyji mogu pomoći, ali povećavaju trošak i složenost.

Koristite ovu tablicu odluke:

⚠️ Upozorenje: Ako stranica zahtijeva izvršavanje JavaScripta za renderiranje sadržaja, čisti HTML dohvat može vratiti praznu “ljušturu”. Tada razmotrite rendering servis ili izvor koji izlaže podatke server-side. Ne pokušavajte brute-force bot zaštite.

# Korak 2: Parsirajte HTML i izdvojite sadržaj koji vas stvarno zanima#

Detekcija promjena propada kad hashirate cijelu stranicu. Headeri, footeri, cookie banneri, AB test widgeti i timestampovi stalno se mijenjaju.

Opcija A: Izdvojite regiju pomoću CSS selektora#

Ako možete pouzdano ciljati regiju, učinite to. Česti ciljevi:

• Container s pricing karticama
• Container s listom poslova
• Glavno tijelo članka
• Redovi tablice u specifičnom odjeljku

U n8n možete parsirati HTML u Function nodeu koristeći lagani DOM pristup. Ako vaš n8n instance ima cheerio, možete ga koristiti. Ako ne, i dalje možete primijeniti sigurnije string-extraction obrasce za stabilne stranice, ali selektori su bolji.

Primjer Function node koda s Cheerio:

const cheerio = require('cheerio');
 
const html = $json.body;
const selector = $json.selector || 'main';
 
const $ = cheerio.load(html);
const content = $(selector).text();
 
return [{ ...$json, extractedText: content }];

Držite selector po URL-u u data storeu kako biste ga mogli fino podesiti bez uređivanja workflowa.

Opcija B: Izdvojite strukturirane podatke ako postoje#

Mnoge stranice ugrađuju JSON-LD ili druge strojno čitljive blokove. To je obično stabilnije od scrapinga vidljivog HTML-a.

Potražite:

• application/ld+json
• Inline JSON u script tagovima
• Ugrađene API pozive koje možete koristiti direktno

Ako možete nadzirati JSON payload umjesto HTML-a, učinite to. Diffing i hashing nad JSON-om je čišći i smanjuje lažno pozitivne rezultate.

# Korak 3: Normalizirajte sadržaj kako biste izbjegli lažno pozitivne rezultate#

Normalizacija je mjesto gdje se rješava većina problema tipa “monitor mi je previše bučan”.

Što normalizirati (ukloniti)#

Praktičan pipeline normalizacije:

1. 1
   Pretvorite izdvojeni HTML ili tekst u plain text.
2. 2
   Pretvorite u lowercase ako velika/mala slova nisu bitna.
3. 3
   Sažmite whitespace na pojedinačne razmake.
4. 4
   Uklonite poznate dinamičke uzorke.
5. 5
   Trim.

Primjer u Function nodeu:

let text = $json.extractedText || '';
 
text = text.replace(/\s+/g, ' ').trim();
text = text.replace(/last updated:\s*[a-z0-9,:\s]+/gi, ''); // example pattern
text = text.replace(/updated\s+\d+\s+(minute|minutes|hour|hours|day|days)\s+ago/gi, '');
 
return [{ ...$json, normalizedText: text }];

Ako trebate robusnija pravila, držite uzorke po URL-u, ne globalno. Job board i pricing stranica imaju različite izvore šuma.

Normalizirajte HTML umjesto teksta kad je struktura važna#

Ponekad text-only izgubi smisao. Npr. tablica gdje su stupci bitni ili lista gdje je redoslijed stavki bitan.

U tim slučajevima:

• Uklonite scripts, styles i komentare
• Uklonite atribute koji se često mijenjaju, poput data-* i id
• Zadržite tagove i stabilne atribute
• Zatim hashirajte normalizirani HTML string

Ovaj pristup čini smisleno uočljivim strukturne promjene bez reagiranja na tracking atribute.

# Korak 4: Detektirajte smislene promjene hashingom i opcionalnim diffingom#

Hashing za brzu detekciju#

Hashing je najjednostavniji pouzdan pristup:

• Napravite hash normaliziranog sadržaja.
• Usporedite ga s prethodnim hashem spremljenim za taj URL.
• Ako se promijenio, tretirajte to kao ažuriranje.

Primjer hashiranja u Function nodeu pomoću Node crypto:

const crypto = require('crypto');
 
const normalized = $json.normalizedText || '';
const hash = crypto.createHash('sha256').update(normalized, 'utf8').digest('hex');
 
return [{ ...$json, contentHash: hash }];

Zašto SHA-256: brz, široko dostupan, zanemariv rizik kolizije za ovaj use case.

Diffing za bolja upozorenja#

Hashing vam kaže da se nešto promijenilo. Diffing vam kaže što se promijenilo, što skraćuje vrijeme istrage i čini Slack upozorenja upotrebljivima.

Lagani pristup koji radi bez teških diff biblioteka:

• Spremite prethodni normalizirani tekst.
• Kada dođe do promjene, uključite kratki isječak:

  • prvih 300 do 1000 znakova
  • ili linije koje sadrže ključne riječi
  • ili oba: prethodni i trenutni snippet usporedno

Ako imate dostupnu diff biblioteku, generirajte unified diff. Ako ne, napravite pragmatičan sažetak:

const prev = $json.previousNormalizedText || '';
const curr = $json.normalizedText || '';
 
const prevSnippet = prev.slice(0, 500);
const currSnippet = curr.slice(0, 500);
 
return [{
  ...$json,
  changeSummary: `Prev: ${prevSnippet}\n---\nCurr: ${currSnippet}`
}];

Ovo nije pravi diff, ali često je dovoljno da potvrdite promjenu cijena ili politike.

ℹ️ Napomena: Ako nadzirete compliance-kritične stranice, razmotrite spremanje punih snapshota u object storage i linkanje iz upozorenja. To daje auditabilnost kada se promjene sadržaja osporavaju.

Pragovi za “smislene” promjene#

Neke se stranice minimalno mijenjaju pri svakom requestu. Dodajte threshold pravilo kako biste smanjili šum:

• Ignorirajte promjene gdje se duljina normaliziranog teksta promijeni za manje od 1%.
• Ili ignorirajte promjene gdje se mijenjaju samo brojevi koji odgovaraju uzorku “view count”.
• Ili alertajte samo ako se ključna riječ pojavi ili nestane.

Primjer threshold pravila:

• abs(currLength - prevLength) / prevLength * 100 manje od 1 znači ignorirati

Formulu pišite u kodu, ne kao plain text, kako bi MDX ostao siguran.

# Korak 5: Spremite stanje i uspoređujte pouzdano#

Potrebna vam je perzistencija. Bez nje, svako pokretanje izgleda kao “promjena”.

Opcije u n8n:

Robusna početna baza:

• Spremite jedan “latest snapshot” po URL-u
• Opcionalno spremite povijest samo kada se dogodi promjena

Minimalna polja za spremiti: url, contentHash, normalizedText, fetchedAt, etag, lastModified.

# Korak 6: Rutiranje upozorenja u Slack i Email#

Rutiranje upozorenja nije samo “pošalji poruku”. Želite pravu razinu hitnosti i pravo odredište.

Predložak Slack upozorenja#

Uključite:

• URL
• Što se promijenilo (sažetak)
• Kada je detektirano
• Status code i response time ako ga pratite
• Link na spremljeni snapshot ako postoji

Primjer strukture Slack poruke:

Koristite Slack node s jednim formatiranim text payloadom i držite se ispod Slack limita. Ako šaljete dugačke diffove, uploadajte kao datoteku ili spremite eksterno pa linkajte.

Predložak Email upozorenja#

Email je bolji za:

• Compliance i audite
• Vanjske dionike
• Distribuciju na više primatelja

Neka email bude kratak i uključite link natrag na Slack thread ili spremljeni snapshot.

💡 Savjet: Upozorenja za “prvo podešavanje” rutirajte u privatni kanal. Kad su selektori i normalizacija dotjerani, prebacite upozorenja u operativni kanal. To obično smanji šum za 70 do 90% u prvom tjednu.

# Korak 7: Kontrole pouzdanosti: retry, backoff i dead-lettering#

Detekcija promjena ne vrijedi ništa ako “flapa” zbog timeouta i prolaznih grešaka.

Implementirajte:

• Retry na 429 i 5xx uz eksponencijalni backoff
• Circuit breaker ponašanje kad se ponavljaju blokade
• Odvojeno alertanje za “stranica promijenjena” vs “monitor pokvaren”

Jednostavna politika koja radi:

Za kompletan obrazac s retry nodeovima, fallback flowovima i eskalacijom, slijedite n8n error handling retries alerting.

# Primjer Blueprint workflowa (node-po-node)#

Ovo je praktičan raspored koji možete kopirati:

Ako želite da vanjski sustavi dinamički šalju URL-ove, primajte ciljeve preko webhooka i upisujte ih u storage. Postavljanje webhooka pokriveno je u n8n webhook tutorial.

# Česte zamke i kako ih izbjeći#

1. 1
   Hashiranje cijelog HTML-a stranice — alertat ćete na oglase, tracking i šum layouta. Prvo izdvojite stabilnu regiju.
2. 2
   Bez normalizacije — whitespace i timestampovi stvaraju lažno pozitivne rezultate. Izgradite per-site skup pravila normalizacije.
3. 3
   Previše konkurentnosti — paralelni requestovi brzo izazovu blokade. Koristite batching i Wait nodeove.
4. 4
   Bez spremljenog stanja — bez perzistencije, svaka egzekucija izgleda kao promjena. Spremite barem zadnji hash.
5. 5
   Alertanje na svaku grešku — odvojite “sadržaj promijenjen” od “monitor nije uspio” i primijenite retry politike.

⚠️ Upozorenje: Ne “rješavajte” bot blokade tako da slijepo povećate učestalost i rotirate IP-ove. To često povećava challenge rate i može dovesti do trajnih IP banova.

# Ključne poruke#

• Dohvaćajte stranice odgovorno: realistični headeri, conditional requestovi, kontrolirana konkurentnost i odgode kako biste smanjili blokade.
• Izdvojite samo regiju sadržaja koja vas zanima, zatim agresivno normalizirajte kako biste eliminirali timestampove, bannere i šum whitespacea.
• Koristite SHA-256 hashing za brzu detekciju promjena te dodajte diff ili snippet razumljiv ljudima kako bi upozorenja bila upotrebljiva.
• Perzistirajte stanje po URL-u: spremite zadnji hash i normalizirani snapshot te po želji vodite povijest samo kad dođe do promjena.
• Rutirajte upozorenja po ozbiljnosti: Slack za operativne promjene, Email za compliance i dionike, te odvojite upozorenja “monitor pokvaren” od “stranica promijenjena”.
• Dodajte kontrole pouzdanosti: retry s backoffom za 429 i 5xx te eksplicitno rukovanje 403 blokadama i 304 not-modified odgovorima.

# Zaključak#

Pouzdan n8n monitoring detekcije promjena pri web scrapingu najviše se svodi na dosljednost: stabilno izdvajanje, snažnu normalizaciju i usporedbe sa stanjem uz disciplinirani rate limiting. Kad jednom implementirate tu petlju, možete pokretati workflowe za odobrenja, izradu ticketa, CRM ažuriranja ili incident response uz daleko manje lažno pozitivnih rezultata.

Ako želite da je ovo postavljeno end-to-end uz ojačane retryje, proxy strategiju i čisto rutiranje prema Slacku i Emailu, Samioda to može implementirati i hostati kao dio naše automation prakse. Pogledajte naše mogućnosti na https://samioda.com/en/automation i podijelite stranice koje želite nadzirati.