Quick Answer
A WordPress media library cleanup should start with an inventory, not a delete button. Review large files, unattached items, duplicate-looking uploads, missing attachment details, oversized image defaults, direct file links, and posts that still depend on old media. The best fit for a small publisher is a monthly review that fixes metadata and obvious duplicates, then deletes only files that have a backup and no live-page dependency.
Cleanup Map
| Area | What to check | Better choice |
|---|---|---|
| Inventory | Media type, date, file size, dimensions, and uploaded-to status | Sample first, then batch similar issues |
| Unattached files | Items with no visible attached post or page | Verify public usage before deletion |
| Large images | Files much larger than the display need | Compress or replace through a controlled edit |
| Attachment details | Alt text, title, caption, description, and file URL | Fill details that help accessibility and editorial context |
| Direct links | Images linked to the media file or attachment page | Choose no link unless the file needs to open separately |
| Settings | Thumbnail, medium, large image dimensions, and upload folders | Document defaults before changing them |
| Deletion risk | Backups, old posts, galleries, blocks, themes, and redirects | Delete only after a restore path is clear |
Who Should Use This Checklist?
Use this checklist when a WordPress content site has accumulated months of screenshots, logos, featured images, downloads, or one-off uploads and the media library is becoming hard to search. It is useful before a redesign, after a large content refresh, after image optimization work, before migrating hosts, or when editors keep uploading new versions because they cannot find the existing file.
This is not a storage-hacking guide or a promise that deleting media improves rankings. The operator goal is narrower: make the library searchable, reduce accidental duplicate uploads, keep article images maintainable, and avoid removing files that public pages still need.
The main risk is treating "unattached" as "unused." WordPress documentation notes that media uploaded from Media Library or Media Add New can be unattached until inserted, and attachment state does not prove whether a file is embedded, linked, used by a theme, or referenced by a plugin. Use unattached status as a review queue, not as permission to bulk delete.
Step 1: Export Or Record A Small Media Inventory
Start with a simple worksheet. A full crawl can wait. For the first pass, record:
- File name.
- Media type.
- Upload month.
- File size.
- Image dimensions.
- Uploaded-to value.
- Public page where the media appears, if known.
- Action: keep, edit details, replace, compress, investigate, or delete later.
The WordPress Media Library supports grid and list views, date filtering, media-type filtering, search, sortable columns, and attachment details. That is enough for a small operator to review one month, one content cluster, or one file type at a time.
Do not begin with all historical media. Pick a bounded batch such as screenshots uploaded in the last quarter, unattached images from a migration month, or oversized feature images on the most important posts. A small finished batch is safer than a half-finished library-wide purge.
Step 2: Check Backups Before Deleting Anything
Media cleanup is destructive when files are permanently deleted. Before deleting a batch, confirm that the site backup includes uploads, database records, and the current theme or plugin state that renders the media on public pages.
Use this delete preflight:
- [ ] A recent backup exists and includes
wp-content/uploads. - [ ] The affected post or page list is recorded.
- [ ] The candidate file is not a featured image, gallery image, product image, download, logo, favicon, or social preview asset.
- [ ] The file is not used in a reusable block, pattern, sidebar, footer, theme template, or custom field.
- [ ] The public page still renders correctly after a draft replacement.
- [ ] The file can be restored if the cleanup removes the wrong item.
If the backup status is uncertain, do not delete. Edit metadata, rename the worksheet row, or mark the file for later review instead.
Step 3: Treat Unattached Media As A Review Queue
WordPress can show media that is unattached to a post or page, and the list view can display an attach action for unattached items. That does not mean the item is unused. A file may be linked directly, embedded by a block, reused after a post was deleted, included in a gallery, called by a theme, or referenced in older content.
Use this triage:
| Unattached item | Audit question | Action |
|---|---|---|
| Old screenshot | Is it still visible in a tutorial or changelog? | Keep or replace through the article edit |
| Duplicate upload | Is there a newer canonical image already used? | Delete only after checking the public page |
| Download file | Does a button or link point to the file URL? | Keep and document the page |
| Logo or icon | Is it used by theme, header, social image, or plugin settings? | Keep unless the replacement is verified |
| Random test file | Was it uploaded during staging or a failed draft? | Delete after backup and page check |
The better workflow is to mark uncertain items as investigate, not delete. Deletion should be the final step after the file's role is clear.
Step 4: Fix Attachment Details Before Reuploading
The Media Library attachment details surface file name, file type, file size, dimensions, alt text, title, caption, description, file URL, and related actions. For image-heavy editorial sites, those fields are often more valuable than uploading another copy.
Use these cleanup rules:
- Add useful alt text when the image carries meaning for the reader.
- Leave alt text empty only when the image is decorative and the surrounding text already explains the point.
- Use captions when the image needs source, context, or a screen-state explanation.
- Use descriptions for editorial notes that help future editors understand why the asset exists.
- Keep file names understandable enough for search and maintenance.
- Copy direct file URLs only when a page intentionally links to the file.
This overlaps with image optimization, but the media-library pass has a different focus: keeping the asset record useful after publication. The editor who refreshes an article six months later should be able to tell which screenshot is current, why it was uploaded, and where it appears.
Step 5: Review Image Size Defaults
The WordPress Media Settings screen controls image size defaults for thumbnails, medium images, and large images. It also includes upload organization into month- and year-based folders. These settings affect future uploads and inserted media behavior, so record the current defaults before changing them.
For a small blog, ask:
- Are thumbnail, medium, and large sizes still aligned with the current theme layout?
- Are featured images being uploaded far larger than they are displayed?
- Are screenshots legible at the size used in the article?
- Are month and year folders helpful for backup review and cleanup?
- Does the host have file-size limits that create failed uploads or editor workarounds?
Do not change size defaults in the middle of a cleanup batch unless the site has a controlled plan for regenerated thumbnails, cache clearing, and visual checks. A setting change can be correct and still create confusing before-and-after behavior across older media.
Step 6: Audit Direct File And Attachment Links
WordPress attachment behavior allows media to be linked directly to the file, linked to an attachment post, or not linked. For ordinary article images, no link is often the cleanest choice. Direct file links are useful when the reader needs to open a full-size diagram, download a PDF, or inspect a screenshot more closely.
Check high-traffic posts for these patterns:
| Link pattern | Good use | Cleanup trigger |
|---|---|---|
| No link | Inline screenshot or decorative image | None if the image supports the article |
| Media file link | Download, full-size chart, or inspectable diagram | File URL points to old or duplicate upload |
| Attachment page | Gallery or theme-specific attachment flow | Thin attachment pages exposed unintentionally |
| External image link | Licensed external asset or vendor-hosted file | Missing source note or unstable hotlink |
If an image link is wrong, fix the post first. Deleting the old file before fixing the public link creates a broken user path and a harder rollback.
Step 7: Use Google Image Guidance As A Maintenance Filter
Google image SEO documentation emphasizes helpful page context, meaningful image placement, descriptive file names, useful alt text, and stable images that can be crawled. For an operator checklist, translate that into maintenance questions rather than ranking promises.
Ask these questions:
- Does the article text around the image explain why the image is present?
- Does the file name help an editor understand the asset?
- Does the alt text describe the image when the image carries meaning?
- Is the image near the relevant section, not parked far from the explanation?
- Is the image URL stable after replacements, migrations, and cache clears?
- Is the image blocked, broken, or replaced by a placeholder on the public page?
This is also where media cleanup connects to internal operations. A screenshot may be technically valid but editorially stale after a plugin UI change, Search Console UI change, or WordPress editor update. Mark stale images for refresh instead of deleting them blindly.
Step 8: Run A Small Public-Page Recheck
After a cleanup batch, verify the pages readers actually see. Open the affected post or page, reload after cache clearing if needed, and check:
- Images render.
- Captions still match the image.
- Download links still work.
- Featured images still appear.
- Galleries still contain the intended files.
- The article layout did not shift unexpectedly.
- The media library no longer contains the obvious duplicate or retired file.
If the site uses a cache plugin or CDN, pair media cleanup with the cache-clearing checklist. The WordPress admin view may be correct while the public page is still serving an older cached asset.
What Should The First Cleanup Include?
The first cleanup should include one bounded batch: duplicate screenshots from one workflow, unattached files from one month, or oversized images from the top five articles. Record the files, verify backups, update attachment details, fix public-page references, and delete only the files that have no live dependency.
For a Yolkmeet-style operator blog, a practical first batch is the last 30 to 60 days of screenshots used in WordPress, Search Console, Bing Webmaster Tools, analytics, and automation workflow articles. Those assets change quickly, but they are also easy to misidentify if the article title, caption, and upload month are not recorded.
Common Questions
Is unattached media safe to delete in WordPress?
No. Unattached media is a useful review filter, but it does not prove the file is unused. Check public pages, links, blocks, theme areas, downloads, and backups before deleting.
Should every old image be compressed or replaced?
No. Replace images when the file is too large for its display need, the screenshot is stale, or the asset is duplicated. Leave useful images alone when they render correctly and have enough context.
Should attachment pages be indexed?
Usually not for a small editorial blog unless the attachment page itself has a clear reader purpose. If attachment pages appear unexpectedly, review theme, SEO plugin, and link behavior before making sitewide changes.
How often should a media library cleanup run?
Run a small monthly review and a larger quarterly review. Also run the checklist before host migration, theme changes, gallery changes, image-heavy refreshes, or large deletion batches.
Source Notes
- https://wordpress.org/documentation/article/media-library-screen/ checked 2026-06-07; used for source-derived analysis of Media Library grid and list views, filters, search, attachment details, uploaded-to fields, delete actions, copy URL behavior, and unattached media handling.
- https://wordpress.org/documentation/article/settings-media-screen/ checked 2026-06-07; used for source-derived analysis of media image-size defaults, upload folder organization, and why settings changes should be documented before cleanup.
- https://wordpress.org/documentation/article/use-image-and-file-attachments/ checked 2026-06-07; used for source-derived analysis of attachment behavior, direct file links, attachment post links, and why unattached status is not enough to prove deletion safety.
- https://wordpress.org/documentation/article/media-add-new-screen/ checked 2026-06-07; used for source-derived analysis of single and bulk uploads, upload-size visibility, and why duplicate upload behavior should be managed through an operator workflow.
- https://wordpress.org/documentation/article/image-block/ checked 2026-06-07; used for source-derived analysis of image insertion behavior, captions, alt text, link settings, and image display controls in the block editor.
- https://developers.google.com/search/docs/appearance/google-images checked 2026-06-07; used for source-derived analysis of image context, descriptive file names, alt text, stable image URLs, and public-page verification.
Internal Link Plan
Link to wordpress-image-optimization-checklist when the cleanup finds oversized images, stale screenshots, or missing alt text. Link to wordpress-backup-restore-checklist before any destructive media deletion batch. Link to wordpress-internal-link-audit-checklist when old file URLs or attachment pages are linked from articles. Link to wordpress-cache-clearing-checklist after replacing public images. Link to blog-reporting-spreadsheet when tracking cleanup batches, file status, page dependencies, and refresh dates.
Update Note
Review this checklist every 60 days. Recheck WordPress Media Library controls, Media Settings behavior, attachment documentation, Image block options, and Google image SEO guidance. Refresh earlier after a WordPress editor release, theme change, image plugin change, cache plugin change, host migration, or a visible image indexing/reporting change.