How to Delete One URL and Its Captures from ArchiveBox

To remove snapshots matching a URL in a current ArchiveBox installation, use the documented URL-level command:

archivebox remove --yes 'https://example.com/page'

Check archivebox remove --help and your installed ArchiveBox version first. Review how URL matching works for that version so the command targets only the captures you intend to remove. Current security guidance says this removes matching Snapshot records and schedules their snapshot directories for cleanup. It does not necessarily erase every reference to the URL from imports, logs, or an external search backend.

1. Check your ArchiveBox version and command options

ArchiveBox command behavior has changed across releases. Before deleting anything, confirm which installation you are administering and inspect the local command help:

archivebox --version
archivebox remove --help

Use the current remove command reference alongside the security guidance for the release you run. The exact release cited in the current security guidance is version-sensitive, so do not assume an old flag or matching rule has the same effect in your installation.

2. Remove snapshots by URL

For the current documented URL-removal route, pass the URL to archivebox remove and confirm the operation with --yes:

archivebox remove --yes 'https://example.com/page'

Replace the example with the URL you want to remove. Treat the URL as a selection pattern: check the installed version’s help and behavior, then verify which records match before you confirm deletion. URL matching can be configured, and an apparently specific URL may match more than one snapshot depending on that behavior.

According to the ArchiveBox Security Overview, the current removal path deletes matching Snapshot rows and schedules their snapshot directories for cleanup through the normal state-machine path. Scheduling cleanup is not the same as claiming every copy or reference has already been erased.

3. Inspect matching snapshot records before deleting

If you want to review the Snapshot records first, or delete selected records rather than using URL-level removal, list snapshots using the URL substring filter. The snapshot CLI accepts JSON Lines output that can be piped into its delete command:

archivebox snapshot list --url__icontains='example.com/page' | archivebox snapshot delete --yes

This is a record-level workflow: the list filter selects records, and the delete command consumes Snapshot JSONL from standard input. Review the matching records carefully before piping them into deletion. Consult the snapshot CLI reference for options supported by your installed version.

Use this route when seeing the selected records is important or you need to target specific Snapshot records. Use URL-level removal when the URL matching behavior is appropriate for the set of captures you intend to remove.

4. Understand what removal does not guarantee

Removing snapshots is not necessarily the same as completely erasing every trace of a URL. The security guidance notes that original imports and operational history may remain in locations such as sources/ and logs/, or in an external search backend. Those stores require separate handling; the cited documentation does not provide one universal command that clears them all.

If complete erasure is your requirement, identify every store used by your installation, including any external index, and handle each according to your own retention and backup procedures. Do not infer that deleting Snapshot rows and scheduling snapshot-directory cleanup also clears those other stores.

5. Do not rely on old --delete behavior

Documentation for ArchiveBox 0.4.24 described --delete as deleting archived content and metadata folders. Current security guidance for 0.9.71rc43 describes the legacy flag as accepted for CLI compatibility without changing removal behavior. These statements refer to different release contexts.

Use the command documentation for your installed release. Do not add --delete based on the older description and assume it controls current removal behavior. See the 0.4.24 documentation for the historical behavior and the current security guidance for the later context.

6. Troubleshooting

Symptom	Likely cause	What to do
The command or an option is not recognized.	Your installed release has different CLI commands or flags.	Check archivebox --version and archivebox remove --help. Follow documentation for that release.
More captures match than expected.	The URL matching behavior or filter is broader than the exact record you intended.	Stop before confirming. Inspect matches with archivebox snapshot list --url__icontains=... and refine the selection using options available in your version.
A snapshot directory is still present immediately after removal.	The current removal path schedules directory cleanup; cleanup is handled through the normal state-machine path.	Check the installation’s cleanup state and the version-specific guidance. Do not treat a scheduled cleanup as proof that every other store is cleared.
The URL still appears in search or history.	Imports, logs, or an external search backend may retain traces.	Identify the store that still contains the URL and handle it separately. The cited docs do not specify one universal erasure command for these stores.
You expected --delete to remove files.	You may be relying on historical 0.4.24 documentation; later guidance describes it as a compatibility flag without a behavior change.	Use documentation matching your installed release and verify the current removal workflow.

7. Reliability and operational notes

• Confirm the target: Review URL matching and selected records before a consequential deletion.
• Use the right scope: URL-level removal selects by URL matching; snapshot list and delete lets you work from selected Snapshot records.
• Account for other stores: Snapshot removal does not establish that imports, logs, or external indexes have been erased.
• Follow local backup policy: The documentation describes command behavior, not the contents or recovery options of your particular installation.
• Check release-specific guidance: Command behavior and the meaning of legacy flags can vary by version.

This task is an administrative deletion workflow, so there is no relevant screenshot-processing performance or API cost claim to make. Avoid promising a cleanup time: the cited sources say directory cleanup is scheduled, but do not give a completion-time benchmark.

Or skip the browser setup

If you also need screenshots of pages you are archiving or documenting, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

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

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides screenshot, page-info, and PDF-capture tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up free for 1,000 screenshots a month, no card required.

FAQ

Does removing a URL delete every copy of it?

No. The documented removal targets matching Snapshot rows and schedules their snapshot directories for cleanup. Sources, logs, and external search backends may need separate handling.

Can I inspect snapshots before deleting them?

Yes. Use archivebox snapshot list with a URL filter to review records, then pipe the selected JSONL records to archivebox snapshot delete --yes.

Is --delete required?

Do not assume so. Its documented meaning differs between the 0.4.24 documentation and later security guidance. Check the help and documentation for your installed release.