Weekly visual archive of web pages in n8n: screenshots to Google Drive (workflow JSON)

Built with n8n
,
1

I wanted a dated visual record of a few pages (competitor pricing pages, our own landing page, a supplier’s terms page) so I can see when something changed, not just that it changed. Text diffs miss layout, banner and price-badge changes, so I archive a screenshot every Monday instead.

What it does

Schedule (Mon 08:00) → Code (list of pages) → HTTP Request (screenshot as a file) → Google Drive (upload)

Each run drops files like 2026-10-21_competitor-a-pricing.webp into a Drive folder, so you can scroll the folder and spot the week something moved.

Tips that made it reliable

  • Response format = File on the HTTP Request node, otherwise you get a broken string instead of binary data.
  • Timeout 60 s and Retry on fail (2 tries, 5 s apart). Heavy pages occasionally take 15–30 s to render.
  • Batching: 1 item every 2 s so you don’t hit a rate limit when the list grows.
  • WebP keeps files around a third of the PNG size, which matters if you keep a year of weekly shots.
  • Turn on cookie-banner blocking, or half your archive is a “We value your privacy” modal.
  • Put the API key in a Header Auth credential (X-API-Key), not in the query string, so it doesn’t end up in execution logs or exported JSON.
  • Build the file name in the Code node (date + slug) so it sorts chronologically in Drive.

Workflow JSON

Paste into n8n, then set your Header Auth credential on the HTTP Request node and your Google Drive credential/folder on the last node.

Swapping the screenshot provider

Any screenshot API that returns a binary image on a GET works here; only the URL and query parameter names change (ScreenshotOne, ApiFlash, Urlbox etc. all fit the same shape).

Disclosure: the URL in the JSON is Snap, a screenshot API I built (snap.flyhold.in). Its free tier is 200 screenshots/month with no card, which covers this workflow for ~45 pages weekly. Paid starts at $9/month for 10,000. Honest gaps: no webhooks, S3 upload or geo proxies yet.

Happy to answer questions, and curious what others use for visual change tracking: do you diff the images, or just eyeball the folder like I do?

2

Useful workflow, and the disclosure about the screenshot service is appreciated. On your question about visual change tracking, a practical middle ground between diffing every image and eyeballing the folder is to compare each new capture against the previous week’s file by size or hash first, and only run a pixel-level comparison when the two differ. One caution is that pages with rotating banners, cookie notices or live timestamps will differ on every run, so it helps to hide those elements or to wait for the page to settle before capturing. For reliability, enabling Retry On Fail on the HTTP Request node, together with a separate workflow that starts with an Error Trigger node and sends a message when a run fails, means a missing weekly capture does not go unnoticed. Naming each file with the page slug and the date also keeps the Drive folder easy to sort and compare over time.

3

Thanks @williamsj04, really useful. The size/hash check before a pixel diff is a great idea since it keeps the weekly run cheap, and slug + date naming makes the Drive folder much easier to browse. I’ll add Retry On Fail with an Error Trigger alert to the JSON and mention hiding cookie banners in the post. Appreciate you taking the time.

4

Hey @amielpereira! This is a fantastic workflow share, really appreciate you posting it. Your tips on batching, WebP, and especially cookie-banner blocking are gold for anyone building similar page archives!

Regarding your question about visual change tracking, eyeballing the folder is a solid first step for spotting big shifts. For more automated detection, you could chain another HTTP Request or Code node to an image comparison service or library. I’ve even seen some builders experiment with feeding these into an AI Vision node to describe layout changes.