內容簡介
SEO'n'AI - Image Locator & Find Unused Images 外掛幫助使用者管理媒體庫中的圖片，提供圖片使用情況的詳細資訊，並安全地刪除未使用的圖片，避免意外損失。
【主要功能】
• 媒體列表中的使用情況欄位
• 每張圖片的「使用於」面板
• 每張圖片的使用頁面
• 過濾顯示已使用、未使用或未檢查的圖片
• 批次刪除未使用圖片的功能
• SEO'n'AI 垃圾桶保護機制
外掛標籤
開發者團隊
② 後台搜尋「SEO'n'AI – Image Locator & Find Unused Images」→ 直接安裝（推薦）
原文外掛簡介
Every media library grows. Sooner or later you look at an image and ask the question WordPress cannot answer: is this still used anywhere?
Core shows you “Uploaded to” — the post an image happened to be attached to, which says nothing about where it actually appears. Image Locator answers the real question:
A Usage column in the media list: used in how many places, unused, or not checked yet — with the first findings in the tooltip.
A “Used in” panel on every image (list view and grid modal): each post, page, widget or setting that references the image, linked for one-click editing.
A usage page per image: the image on one side, every place it is used on the other — each opening in a new tab for editing. Checked live on every visit, with a delete button that warns you properly if the image is in use.
A filter: show only used, unused or unchecked images.
A library scan that works through everything in small time-budgeted batches — it cannot time out, even on large libraries.
A bulk action to delete unused images — see below for why it is the careful kind.
The SEO’n’AI Trash for unused Images, on by default in new installations: what this plugin deletes can be restored — with its original attachment ID — until you empty the trash.
The safety net comes first
Finding unused images is the easy half. The half that can hurt is the deleting, and that is where most plugins of this kind leave you alone: WordPress has no trash for media unless a line in wp-config.php says so, so a deleted image is simply gone from the server.
Image Locator brings its own — the SEO’n’AI Trash for unused Images, switched on from day one. Every image the plugin deletes goes there first: the file stays on the server, the image keeps its attachment ID, and one click puts it back so that every post, page and page-builder element referencing it works again. A file from a backup cannot do that — it returns with a new ID, and the gaps stay.
That turns the honest limit of any scanner into something you can live with. Delete, then look at your website, then empty the trash. And if the site does run WordPress’ own media trash, the plugin recognises it and uses that one instead.
Where it looks
The scan searches the database, not just the post content:
Post content: image blocks, classic editor markup, galleries — matched by attachment ID and by every size variant of the file name
Featured images
Custom fields and page-builder data (Elementor, Divi, WPBakery and others store image references in post meta as IDs or URLs — both are searched)
Widgets, the site logo, the site icon
Term images, including WooCommerce category images
Drafts count as usage — those are exactly the ones you want to know about before deleting. Revisions and trashed items do not count.
Deleting, done carefully
“Unused” from a cached scan is not enough to delete a file. The bulk action “Delete unused (verified)” re-checks every selected image live, immediately before deletion. If an image turns out to be in use after all — because content changed since the scan — it is skipped and reported, not deleted. With the safety net on, the same action is called “Move unused to SEO’n’AI Trash (verified)”: same check, reversible outcome.
And if you try to delete an image the scan knows is used, the media list warns you first, with the number of places it appears.
The trash in detail
WordPress has a trash for posts and pages. For media it has one too, but it stays switched off unless wp-config.php contains define( 'MEDIA_TRASH', true ); — and no plugin can switch it on for you, because WordPress settles that constant before plugins are even loaded. That is why the plugin keeps its own instead of promising something it cannot deliver.
Where it lives: on Media → Image Locator — every deleted image with a preview, the day it was deleted, the days left before WordPress clears it, “Restore”, “Delete permanently” and “Empty trash”. Without MEDIA_TRASH, the media library itself does not list trashed images; that is WordPress, not the plugin, and the reason the trash has its own page here.
Three ways lead into it, and they all belong to this plugin: the bulk action “Move unused to SEO’n’AI Trash (verified)” in the media list, the “Move to SEO’n’AI Trash” link under an image in list view, and the button on an image’s usage page. What WordPress itself calls “Delete permanently” stays exactly that and removes the file at once — in the list as well as in the grid view, where WordPress offers plugins no place for an extra action. If you want every deletion on the site to be caught, add the wp-config.php line above; the plugin then steps aside and uses WordPress’ own media trash.
Mind the clock: WordPress empties the trash by itself after 30 days (EMPTY_TRASH_DAYS). Do your check within that window. On a site that sets EMPTY_TRASH_DAYS to 0, no trash of any kind is possible — the plugin says so plainly instead of promising a net it cannot hold.
Installing, updating, removing: new installations start with the safety net on. A plugin update never changes the behaviour of an existing site; the switch simply sits on the tools page, ready. And if you ever delete the plugin, it puts every image it had trashed back into the media library before it uninstalls itself — nothing is left behind that WordPress would quietly clear out later. Deactivating does not touch anything, but the plugins screen warns you while images are still in the trash.
Without the net, deletion is permanent and removes the actual files, like WordPress’ own delete. Keep backups either way.
Honest about the limits
A database scan cannot see everything. Images hard-coded in theme or plugin template files, images referenced from custom CSS, and use on other websites are invisible to any plugin of this kind. Treat “unused” as strong evidence, not as a court ruling — that is exactly why the bulk delete re-checks each image, and why nothing is ever deleted automatically.
Disclaimer
This plugin is a tool, not a promise. It reads your database and reports what it finds; it cannot see images hard-coded in theme or plugin template files, referenced from custom CSS, or used on other websites. Deleting images is always your decision and your responsibility: every deletion is started by you and confirmed by you. The trash buys you time to notice a mistake, but it is not a backup and it does not last forever — once it is emptied, by you or by WordPress after 30 days, the files are gone. Verify the findings before you delete (the usage page exists exactly for that) and keep backups. The author accepts no liability for deleted images, broken layouts or any other consequences of using this plugin.
Performance
The media list never scans on render — the column reads only cached results. Scanning happens when you ask for it: per image with one click, or for the whole library in batches with a strict time budget per request. When content changes, existing results are marked as outdated instead of silently lying to you.
One honest trade-off: a full library scan takes time on large libraries. Every image is checked individually, with the same logic that runs before any deletion — one truth, one code path. On a library with thousands of images that can take a while; on a typical site it is a few minutes, and it is a one-time cost — after the first full run, “Check new images” only looks at new uploads. To really catch everything, thoroughness beats speed. The front end of your site is never touched either way.
