Every image you upload to WordPress gets its own page. Not the image file, a page: a URL with your theme around it, a title, and nothing else on it.
It is a default from an older web, it serves almost nobody, and on a large site it quietly doubles the number of URLs you own.
This covers what those pages are, how to tell whether yours exist, and what the fix actually does, including one detail about Yoast’s setting that is commonly described wrongly.
The short version
- Turn attachment pages off. Almost no site needs them.
- Yoast’s setting redirects them to the image file, not to the post that contains it.
- Images still get found through the post they sit on, so nothing is lost.
- If yours are already indexed, the fix is a redirect plus patience, not a removal request.
Three Things People Confuse
Most of the confusion around this comes from treating one upload as one thing. It is three.
| The file | /wp-content/uploads/2026/09/photo.png | The actual image. Can rank in image search. |
| The media record | A row in the database | Stores the title, alt text and caption. Not a URL. |
| The attachment page | /photo/ or /?attachment_id=123 | An HTML page containing the image and nothing else |
Only the third is the problem. Turning attachment pages off does not delete the file, does not touch alt text, and does not affect image search.
That is worth being clear about, because the fear of losing image rankings is why people leave these pages switched on.
Why They Are a Problem
- They are thin by definition. An image, a title, and your theme. There is no version of that page that is useful.
- They multiply. A site with 200 uploads has 200 extra URLs. This site has 206 attachments against 140 posts, so attachment pages alone would have outnumbered the content.
- They consume crawl budget. Google fetches URLs it knows about. On this site Google makes roughly 53 crawl requests a day with only 10% going to discovery, so hundreds of empty URLs are not free.
- They can rank instead of your post. Rare, embarrassing, and it happens: someone searches your topic and lands on a bare image.
- They make audits harder. Hundreds of thin URLs in a report obscure the problems that matter.
What they are not is a penalty. Nobody is being demoted for having attachment pages. They are waste, and waste is worth removing on a site that has little crawl budget to spare.
Do You Have Them?
Thirty seconds to find out. Take any image on your site and try its attachment URL.
- A page loads with your header, footer and the image: attachment pages are on.
- It redirects to the image file: they are disabled, which is the common fix.
- It redirects to the post: also disabled, by a different method.
- 404: they are off and nothing is redirecting, which is fine but less tidy.
The quickest way to test is the query form, which works regardless of permalink settings:
curl -sIL "https://yoursite.com/?attachment_id=123"
Or check at scale: crawl the site and look for URLs that are not posts or pages, and check Search Console’s Pages report for thin URLs you do not recognise. The audit checklist covers where those show up.
What Yoast’s Setting Actually Does
This is the part described loosely almost everywhere, so here is what it does on a live site.
With Yoast’s media setting enabled, requesting an attachment URL returns a 301 to the image file itself:
/?attachment_id=5494 → 301 → /wp-content/uploads/2026/09/Technical-SEO-Checklist.png
Not to the post the image appears on. To the raw file.
Why that distinction matters
- The thin page is gone, which was the point.
- A visitor who follows an old attachment link lands on a bare image with no navigation and no way back.
- The image URL becomes the destination, which is fine for image search and useless as a landing page.
For most sites that trade is correct, because almost nobody arrives at an attachment URL. If you have real traffic to those URLs, redirecting to the parent post is better, and that needs a redirect rule rather than the plugin toggle.
AIOSEO has an equivalent setting, and its behaviour should be checked the same way rather than assumed.
What a Correct Setup Looks Like
Using this site as the worked example, because the configuration happens to be right.
| Check | State |
| Attachment pages | Disabled, 301 to the file |
| Media sitemap | Does not exist, returns 404 |
| Images in the sitemap | 149 <image:loc> entries, inside the post sitemap |
| Image files | Return 200, no robots restriction |
That last pair is the point. Images are declared alongside the posts they belong to rather than on their own, which is how Google is meant to find them. The attachment pages are gone and image search is unaffected.
If you want images to rank, the work is alt text, filenames, file size and the content around them, not keeping the attachment page alive. Image SEO covers that properly.
If Yours Are Already Indexed
Turning the setting on stops new ones. Pages already in the index take longer.
- Enable the redirect first. Everything else depends on it.
- Check they are out of the sitemap. Most SEO plugins handle this with the same setting; confirm rather than assume.
- Wait for a re-crawl. Google drops redirected URLs as it revisits them, over weeks rather than days.
- Do not request removal in bulk. The removals tool hides URLs for about six months and does not deindex them. It is for emergencies, not cleanup.
- Watch the indexed count in Search Console rather than checking individual URLs.
Should you use 410 instead?
Some guides suggest serving 410 Gone rather than redirecting, on the grounds that Google drops 410s faster than 404s.
That is true and usually not worth the implementation. A 301 to the file achieves the same removal, keeps any link equity those URLs had, and does not strand a visitor on an error page. Reach for 410 only if you are removing thousands of URLs and want them gone quickly.
Either way this is a crawl-budget cleanup rather than a ranking fix, and the technical checklist puts it in the order it deserves: after indexing problems, before structured data.
When the Setting Does Not Stick
You switch it on, and months later the pages are back. Three causes, in order of how often they turn up.
- A second SEO plugin. Running two is the most common reason. One disables attachment pages, the other re-enables them, and whichever loads last wins. The fix is to run one.
- A theme with its own attachment template. Some themes ship an
attachment.phporimage.phpfile, which can serve the page even when the plugin intends to redirect. A theme update can reintroduce it. - A plugin update resetting the option. Rare, and worth ruling out by checking rather than assuming it cannot happen.
The check takes a moment and is worth repeating after any theme or plugin update:
curl -sIL "https://yoursite.com/?attachment_id=123"
A 301 means the setting is working. A 200 with HTML means something has switched it back on, and you want to know that before an audit finds a few hundred new URLs.
The Exception
There is one case for keeping attachment pages, and it is narrower than people hope.
If the image is the content, and the page around it has real substance, an attachment page can be a legitimate page. A photography portfolio where each image has a caption, context, settings and a description is a page worth having.
Even then, most people are better served building a normal post for each image rather than relying on WordPress’s attachment template, because a post gives you full control over the content and the internal links.
If your images are illustrations inside articles, which is the case for almost every blog, there is no exception and the setting should be on.
The same logic applies to WordPress’s other auto-generated archives. Tag pages have the same shape of problem and the same kind of answer.
Frequently Asked Questions
What is a WordPress attachment page?
A page WordPress creates automatically for every uploaded file, containing just that file and your theme. It is separate from the image itself and from the media record that stores the alt text.
Should I disable attachment pages?
For almost every site, yes. They are thin by definition, they multiply with every upload, and they consume crawl budget. The exception is a site where each image is genuinely the content, such as a portfolio with real descriptions.
Will disabling them hurt my image rankings?
No. Image search indexes the image file and the page it appears on, not the attachment page. Declaring images inside your post sitemap, which most SEO plugins do automatically, is what matters.
Where does Yoast redirect attachment URLs to?
To the image file, not the parent post. Tested on a live site, an attachment URL returns a 301 straight to the file in the uploads folder. If you want visitors sent to the post instead, that needs a redirect rule rather than the plugin setting.
How do I check whether I have attachment pages?
Request an attachment URL in the query form, which works regardless of permalink settings: yoursite.com/?attachment_id=123. A page that loads with your theme means they are on. A redirect or a 404 means they are not.
Should I use 404, 410 or a redirect?
A 301 to the file is the usual answer, because it removes the page, keeps any equity and does not strand visitors. A 410 removes URLs faster and is worth the effort only when clearing thousands at once.
How long before they disappear from Google?
Weeks rather than days, as Google re-crawls each URL and sees the redirect. Watch the indexed page count in Search Console rather than checking individual URLs, and resist the removals tool, which hides URLs temporarily instead of deindexing them.
