Atualmente, este artigo está disponível apenas em inglês.

WordPressFeb 1, 20266 min read

WordPress Media Library Cleanup After WebP Conversion

After a WordPress WebP conversion, the media library can become harder to understand. Editors may see originals, WebP outputs, generated sizes, old unused images, and plugin-created files. Cleanup is useful, but deleting aggressively can break posts, product pages, archives, feeds, social previews, and external campaigns.

"Delete old images after WebP conversion to save space" is risky advice. A good cleanup process proves what is used, separates originals from generated variants, protects metadata, and keeps rollback possible until the new delivery path is verified.

Do Not Start by Deleting Files#

The first cleanup step is inventory, not deletion. WordPress media files may be referenced in posts, blocks, theme options, custom fields, widgets, page builders, CSS, plugin settings, and external feeds.

List the places where images may appear:

  • post and page content
  • featured image fields
  • reusable blocks or patterns
  • theme customizer settings
  • product galleries
  • page builder data
  • CSS background images
  • Open Graph image settings

If a tool only checks post content, it may miss references elsewhere. Treat deletion as the final step.

For GetWebP sites, start from the documented file model. The WordPress FAQ states that original images are not modified or deleted; generated WebP and AVIF files are stored beside the original. A normal converted attachment may look like this:

photo.jpg
photo.jpg.webp
photo.jpg.avif

Do not treat that pattern as three duplicate uploads. It is the source file plus delivery variants.

Preserve Attachment Metadata#

WordPress stores important information around media attachments, including titles, captions, alt text, and generated image sizes. The official Media Library screen documentation is a useful editor-facing reference for how media is managed.

During cleanup, make sure optimization work does not detach:

  • alt text
  • captions
  • descriptions
  • attachment IDs
  • featured image relationships
  • gallery order
  • product image associations

A smaller file is not an improvement if the cleanup breaks accessibility or editorial context.

The Getting Started workflow keeps the original attachment stable and stores generated files as siblings. That means cleanup should happen around the attachment record, not by manually choosing random files in uploads that appear redundant.

Understand Generated Sizes#

WordPress and themes can create intermediate sizes. A WebP conversion may create files for each generated size, or it may create alternate files beside originals. The WordPress developer guide to responsive images explains how srcset support depends on the available image sizes.

Before removing any derivative, confirm whether it is part of a srcset candidate list, used by a template, or required by a plugin. Deleting an apparently redundant file can remove a responsive option the browser was using.

Generated sizes are not always clutter. Some are the site's delivery system.

A useful classification table is:

CategoryExampleDefault action
Original sourcephoto.jpgKeep or archive outside WordPress; do not delete casually
WordPress generated sizephoto-768x512.jpgKeep until responsive candidates are verified
GetWebP variantphoto.jpg.webpKeep if delivery uses it; remove only through plugin cleanup actions
Optional AVIF variantphoto.jpg.avifKeep if AVIF delivery is enabled and verified
Truly unused uploadold campaign image with no referencesArchive or delete after backup and external-link check
Unknown referencefile found in CSS, builder JSON, feed, or CDNInvestigate before deleting

Separate Unused Images From Original Sources#

An unused published image and an original source file are different. An old campaign image may be safe to archive if no page references it. A high-quality original may still be useful for future re-exports even if the current page uses WebP.

Use categories:

published and used
published but unused
source original
generated derivative
conversion output
unknown reference

Only the "published but unused" category is a deletion candidate after backup and verification. Source originals should usually be archived, not casually removed.

GetWebP also has explicit variant cleanup actions in Batch Conversion: Delete WebP for a single Media Library row and Delete All WebP Files under advanced settings. Those actions remove generated .webp and .avif sibling files. They do not remove the original images. That distinction should be written into the cleanup plan.

Check Public URLs Before Cleanup#

Some images may be linked directly from newsletters, social posts, partner pages, or documentation outside WordPress. The media library may not know about those references.

For important assets, review server logs, analytics, or known campaign URLs before deleting. At minimum, avoid deleting recent campaign images and files used in emails.

If direct URLs must change, decide whether redirects are needed. A WebP migration is not automatically a URL migration for every external consumer.

Also check CDN and offload behavior. The FAQ notes that CDN or S3 delivery requires generated variants to be synced to the external storage layer. A cleanup pass that deletes local files before offload state is understood can make diagnosis harder.

Keep Editors Oriented#

After conversion, editors need to know which file to choose. If the library shows both banner.jpg and banner.webp, confusion is likely. Some workflows hide generated files from editors. Others keep only attachment records visible and store derivatives behind the scenes.

Choose a clear editorial rule:

  • editors upload originals
  • the system creates WebP outputs
  • editors select the normal attachment
  • generated derivatives stay out of manual selection

If editors are expected to choose WebP manually, document when and how. Ambiguous media libraries lead to inconsistent publishing.

For GetWebP, the cleaner editorial rule is usually:

Editors upload and select the normal attachment.
GetWebP creates generated WebP/AVIF siblings.
Editors do not manually pick sibling files for normal posts.
The Media Library status column shows conversion state.
Generated files are removed through plugin cleanup actions when needed.

Verify Backups and Rollback#

Before deleting anything, confirm that a restorable backup exists. A cleanup pass can affect thousands of files and database references. Rollback should not depend on remembering which files were removed.

Keep a cleanup log with:

  • files deleted
  • files archived
  • attachment IDs affected
  • pages checked
  • backup snapshot reference
  • cache purge notes

This is operational work, not just file tidying.

Use a cleanup log that distinguishes source deletion from generated-variant cleanup:

Cleanup date: 2026-02-01
Scope: uploads/2024 campaign folder
Backup snapshot: db-2026-02-01 + uploads-2026-02-01
Deleted original uploads: none
Archived originals: 18 unused campaign sources
Deleted generated variants: 120 WebP/AVIF siblings via GetWebP cleanup action
Attachment IDs affected: 42, 43, 51
Public pages checked: homepage, campaign archive, top product category
External references checked: newsletter URLs and Open Graph image list
Rollback owner: site admin

Clean in Rounds#

Use rounds rather than one large deletion:

  1. inventory and classify
  2. remove obvious duplicates in a staging copy
  3. check rendered pages
  4. verify backups
  5. purge caches
  6. monitor broken image reports

Small rounds make mistakes easier to catch.

Before marking a round complete, verify delivery on public URLs. The Frontend Delivery guide explains that GetWebP may rewrite post content, featured images, programmatic attachment output, and remaining images through output buffering. It can also use picture tags with the original image as fallback. If you remove generated variants while delivery is still enabled, retest Content-Type, srcset, and fallback behavior immediately.

Round-level acceptance should be concrete:

Media Library status: expected attachments still visible
Originals: available for sampled attachments
Generated variants: only intended siblings removed
Frontend delivery: no broken image requests in sampled pages
Fallback: original JPEG/PNG loads directly
Cache: page cache and CDN purged for affected URLs
Editor test: editor can still find and select the expected attachment

WordPress media cleanup after WebP conversion should protect the relationship between files, attachment metadata, theme output, delivery variants, and editor workflows. Remove clutter only after proving that the site, the library, and external references no longer need it.

Jack avatar

Jack

GetWebP Editor

Jack writes GetWebP guides about local-first image conversion, WebP workflows, browser compatibility, and practical performance checks for teams that publish images on the web.