How to Archive Website Screenshots Automatically with Screenshot.rocks

Short answer: Screenshot.rocks is a screenshot mockup editor, not an automatic website archiver. Its browser extension captures the visible area of the current tab after you click its button and sends the image to the editor. It does not run in the background, schedule captures, or maintain screenshot history. To archive screenshots automatically, schedule a capture workflow and save each result with its capture time. You can then import an image into Screenshot.rocks when you want to present it in a browser or mobile mockup.

This guide shows a self-managed workflow with shot-scraper and GitHub Actions, explains an API-and-storage alternative, and covers what Screenshot.rocks can do in that workflow.

1. Understand what Screenshot.rocks does

The Screenshot.rocks extension is for capturing and styling a screenshot, then exporting it. The documented Chrome and Edge extension captures the visible part of the active tab when clicked; it does not capture an entire long page. Its documentation says the extension does not run in the background and does not store the screenshot. For full-page captures, use a browser or capture tool that supports them, then import the image into the editor.

So the practical division is:

Screenshot.rocks: format a screenshot as a browser or mobile mockup and export it.
Automation workflow: capture pages on a schedule and retain the files and metadata.

Do not expect clicking the extension once to create a recurring job. For a one-time mockup, open the target page, click the extension, style the result, and export. For an archive, set up one of the repeatable workflows below.

2. Choose an archive workflow

Approach	Best fit	You maintain
Hosted archive service	You want schedules, history, visual comparison, and exports with minimal setup.	URLs, schedule, retention, and service settings.
Screenshot API plus object storage	You need control over storage, metadata, access, or integration with an existing system.	Scheduler, API calls, storage, indexing, retries, and retention.
shot-scraper plus GitHub Actions	You want an inspectable workflow and a small archive that can live in a repository.	Browser dependencies, workflow configuration, repository size, and history.

Snapshot Archive describes scheduled captures, full-page screenshots, visual diffs, alerts, exports, and API access. These are vendor-described features; confirm current limits and plan details before choosing a service. Its how-it-works page explains its scheduled capture process.

For a custom pipeline, ScreenshotAPI’s archiving guide describes requesting a full-page capture and saving the image, timestamp, and SHA-256 checksum in object storage such as S3, R2, or GCS. This still requires a scheduler and a way to find and manage stored captures.

3. Build a scheduled archive with shot-scraper

This example runs every day, captures configured URLs, and commits the screenshots to the repository. It is a workable small archive when repository storage and history are appropriate. The shot-scraper documentation describes using GitHub Actions for configured captures; review its current documentation for supported options and setup details.

Step 1: Add the capture configuration

Create screenshots.yml in the repository root:

- url: https://example.com/
  output: screenshots/example-home.png
  height: 1200
  width: 1440

- url: https://example.com/pricing/
  output: screenshots/example-pricing.png
  height: 1200
  width: 1440

Replace the sample URLs with pages you are allowed to capture. Fixed dimensions help keep repeated captures comparable. This configuration overwrites the same output files on each run; to retain every dated capture, use timestamped output paths or move the resulting files into timestamped names in a script before committing.

Step 2: Add a scheduled GitHub Actions workflow

Create .github/workflows/screenshots.yml:

name: Website screenshots

on:
  workflow_dispatch:
  schedule:
    - cron: "17 4 * * *"

permissions:
  contents: write

jobs:
  capture:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.x"

      - name: Install shot-scraper and browser
        run: |
          python -m pip install shot-scraper
          shot-scraper install

      - name: Capture configured pages
        run: shot-scraper multi screenshots.yml

      - name: Commit changed screenshots
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add screenshots
          git diff --cached --quiet || git commit -m "Update website screenshots"
          git push

GitHub scheduled workflows use UTC cron schedules and can run later than the requested time when runners are busy. The manual workflow_dispatch trigger lets you run a capture on demand. Consult GitHub’s current Actions documentation for repository-specific scheduling and permission rules.

Step 3: Run and inspect it

Commit the configuration and workflow to the repository’s default branch.
Run the workflow manually once and inspect the Actions log.
Check the generated files and confirm that the captured viewport and page state suit your use case.
Let the schedule run, then check that commits appear and that repository growth is acceptable.

To keep history in Git, produce a distinct path for each capture, such as archive/2026-10-04/example-home.png. A production workflow should derive the date at runtime in UTC and avoid overwriting prior records. If the archive becomes large, store image objects outside Git and keep only an index or manifests in the repository.

Using the captured image in Screenshot.rocks

Open the generated image locally or from your repository, then import it into the Screenshot.rocks editor to apply a browser or mobile frame and background. The editor step is presentation; the scheduled workflow remains responsible for capture and retention.

4. Use a screenshot API and durable storage

An API workflow separates rendering from storage. A scheduler requests a screenshot, the job checks the response, and the image is written to storage alongside metadata. Include at least the requested URL, the UTC capture time, the viewport or device configuration, and a checksum. Keep credentials in the scheduler’s secret store, not in source code.

With ScreenshotNeo, the following runnable examples save the API response as a file. Add them to a scheduler to repeat the capture. The examples use the supplied ScreenshotNeo endpoint and options; see the ScreenshotNeo API documentation for configuration details.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/ \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as image:
    image.write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: process.env.SCREENSHOTNEO_API_KEY,
  url: 'https://example.com/'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

The Node.js example uses Bun’s file-writing helper. With Node.js alone, save the response body using node:fs/promises:

import { writeFile } from 'node:fs/promises';

const q = new URLSearchParams({
  access_key: process.env.SCREENSHOTNEO_API_KEY,
  url: 'https://example.com/'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

For a durable archive, replace the local file write with an upload to your chosen object store. Use a path that includes a normalized host, page identifier, and UTC timestamp. Keep the checksum and capture configuration in metadata or an index. Do not use a content hash as the only filename if you need to retain repeated captures of an unchanged page: identical content may produce the same checksum.

5. Decide what the archive must preserve

A screenshot is a visual record of a rendered page at a point in time. It does not preserve the underlying site, its interactions, or all page resources. Choose settings based on what you need to compare or retain.

Viewport or full page: use viewport captures for consistent visual comparisons; use full-page captures when below-the-fold content matters.
Viewport dimensions: keep width, height, and device scale consistent between runs.
Page readiness: dynamic sites may need a wait condition or delay so data and images finish loading.
Authentication and geography: private pages, consent state, and localized pages need deliberate handling; avoid placing secrets in committed configuration.
Metadata: record URL, UTC timestamp, status, capture settings, and a checksum.
Retention: define how long to retain each image and who can access it.

For evidence-oriented records, preserve the original file and metadata. A checksum can help detect whether a file changed after capture; a screenshot by itself does not establish legal admissibility.

6. Storage, performance, reliability, and cost

Storage and retention

Daily capture volume compounds quickly. Estimate storage as the number of pages multiplied by captures per day, days retained, and average image size. This is an estimate, not a benchmark; actual image size varies with page length, format, and content. Git history retains previous versions even when a file is overwritten, so a repository can grow substantially. For larger archives, object storage plus a searchable index is generally easier to manage than committing every image to Git.

Performance

Each capture starts or uses a browser, loads the page, waits for rendering, and encodes an image. Pages with heavy scripts or slow third-party resources take longer. Start with a modest schedule and a small URL set, and capture only the pages and viewport sizes you need. Full-page captures can require more rendering and produce larger files than viewport captures.

Reliability

Expect individual captures to fail because a site is unavailable, blocks automated traffic, changes its markup, or takes longer than the timeout. Keep failures visible in logs and record failed attempts separately; do not silently treat a missing image as a successful capture. Use bounded retries with backoff for transient errors, but avoid retry loops that overload the target website. A scheduled workflow should be safe to run manually and more than once.

Cost

A self-managed workflow can have no screenshot API charge if it runs entirely on infrastructure you already use, but it still consumes runner time, storage, and maintenance effort. Hosted archives and screenshot APIs have their own quotas and prices; verify the current terms before selecting one. The ScreenshotNeo plans supplied for this article are Free: 1,000 screenshots/month with no card; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; and Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

7. Troubleshooting

Symptom	Likely cause	Fix
No scheduled run appears	The workflow is not on the default branch, the cron expression is misunderstood, or the scheduler has not started it yet.	Confirm the workflow is committed to the default branch, use UTC when interpreting the cron schedule, and run it manually to check setup.
Browser installation or launch fails	The runner lacks browser dependencies or the install step did not complete.	Run the documented shot-scraper installation command in the job and inspect the full install log; pin compatible dependencies if your workflow requires reproducibility.
Output file is missing	Bad YAML indentation, invalid URL, output directory not created, or capture error.	Validate the configuration, create the output directory if needed, and inspect the failing command’s logs.
Screenshot is blank or incomplete	The page has not finished rendering, content is lazy-loaded, or the site blocks the runner.	Use an appropriate wait option supported by the capture tool, verify the target URL loads from the runner, and check for bot checks or access restrictions.
Every run overwrites the prior image	The configured output path is fixed.	Add a UTC timestamp or date partition to each output key, or explicitly decide to retain only the latest image.
Git push is rejected	The workflow token lacks write permission or branch protection disallows direct pushes.	Grant the workflow contents write permission where allowed, or use a pull request based update flow that follows repository policy.
Archive repository grows too fast	Binary image revisions accumulate in Git history.	Reduce capture frequency or retention, or move image objects to external storage and retain an index in Git.
API response saved as an image is invalid	The request returned an error response or an unexpected page verdict.	Check HTTP status and response headers before storing the body; keep error details in logs and retry only transient failures.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF, so a scheduled job can focus on naming and retaining the result. Its API supports full-page captures, CSS selector captures, custom waits, device presets, custom CSS and JavaScript, and other capture settings; the parameter names used by other screenshot APIs also work. See the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

Cookie banners are accepted and removed before capture, along with supported newsletter popups and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response indicates the page verdict and billing status in headers. An MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

9. Frequently asked questions

Can Screenshot.rocks run a screenshot archive on a schedule?

No. Its documented extension flow is a user-clicked capture sent to the editor. Use a scheduler, automation workflow, or hosted archive for recurring captures.

Can I make a full-page screenshot with the Screenshot.rocks extension?

The documented extension captures the visible area of the active tab. Capture a full page with a separate browser or automation tool, then import the resulting image into Screenshot.rocks.

Should I commit every screenshot to Git?

Only if the archive is small enough and Git history is an acceptable retention system. Image revisions accumulate in repository history; larger or longer-lived archives are often better stored as objects with a separate index.

Does a screenshot prove what a website showed?

It records pixels produced by a capture process. Preserve the original image and relevant metadata for traceability, but do not assume an image alone proves authenticity or legal admissibility.