WordPress attachment pages are the URLs WordPress creates for every single image you upload. Upload one photo and you get a page for it, with the image, a title, and almost nothing else. They get crawled, they get indexed, and on an older site there are usually more of them than there are real pages.
WordPress 6.4 turned them off. What nobody says loudly enough is that it turned them off for new installs only, so if your site existed before that release, you still have every one of them.
What is a WordPress attachment page?
It is a full URL for a media file, generated automatically at upload time. On most themes the page renders the image, the caption if you set one, and the theme chrome around it. That is the entire content. No article, no product, nothing a search result should ever land on.
The WordPress core team put the problem plainly in the development note announcing the change. These pages “don’t add any meaningful information. They do, however, exist, get indexed by search engines, and sometimes even rank in search results, leading to bad results for users and site owners.”
That is core describing its own feature as a search problem. It is worth reading twice, because the fix that followed is narrower than the description suggests.
What did WordPress 6.4 actually change?
WordPress 6.4 added an option called wp_attachment_pages_enabled. When it is off, requests to an attachment page redirect to the attached file instead of rendering a page.
The catch is the default. New installs get the option set to disabled. Existing sites, on upgrade, get it set to enabled, precisely so that nothing already published breaks. That is a reasonable decision for backwards compatibility and a bad one for anyone who assumed the release fixed their site.
Behaviour as described in the WordPress core development note on changes to attachment pages, October 2023.
Why does this matter for indexing?
Because it inflates the crawlable size of the site with pages that can never earn anything.
Every uploaded image is a URL. A blog with a thousand posts and three images per post is carrying three thousand near empty pages alongside a thousand real ones. Googlebot has to fetch them to learn they are worthless, and it has to keep coming back, because as far as it knows they are ordinary pages that might change.
What you tend to see in the Page indexing report afterwards is a large pile of URLs sitting in crawled, currently not indexed, or grouped under duplicate without user selected canonical when the attachment page and the post it belongs to look similar enough. Neither status is a bug to fix directly. Both are Google telling you it fetched something and found no reason to keep it.
I want to be careful about the claim here. I am not going to tell you attachment pages are throttling your crawl budget, because I cannot measure that on your site and neither can anyone else from the outside. What I can say from the report side is more modest and more useful: they make the indexing report hard to read. When several thousand junk URLs sit in the same bucket as your real problems, you stop being able to see the real problems.
How do I check whether my site has them?
Pick any image on your site, open it in the media library, and look at the URL WordPress offers under the attachment details. If that URL ends in a page slug rather than a file extension, load it. If it renders a page rather than redirecting to the .jpg or .png, attachment pages are enabled.
Then check the scale. In Search Console, open the Page indexing report and look at the URL samples in the larger buckets. Attachment page URLs are usually obvious once you see one, because they repeat the image filename in the slug.
What I do about them
On WordPress builds, I disable them and then let the redirect do the work. Both major SEO plugins expose the setting, and core exposes the option directly, so this is a checkbox rather than a project. Once the option is off, the URLs redirect to the file, and over subsequent crawls Google drops the pages from the index on its own.
Two things I do not do. I do not delete the images, obviously, since the file and the page are different things and disabling the page leaves the file untouched. And I do not block the attachment URLs in robots.txt, because blocking a URL prevents Google from ever seeing the redirect, which leaves the old page stranded in the index with no way to resolve. That is the same trap as every other case of reaching for a crawl rule to solve an index problem, which I went through in detail in noindex versus robots.txt.
When I audited a WordPress and Elementor build for three UK locksmith businesses, the media library was the second thing I looked at after the sitemap, for exactly this reason. It is a five minute check that changes what the rest of the report means. The other pile of URLs WordPress generates without being asked is archives, and whether to keep them is a longer question: should you noindex category and tag pages.
The honest caveat
Core’s own development note describes the redirect behaviour and the option, and that is where my sourcing ends. Themes and plugins can and do override attachment templates, and a page builder can keep serving something at those URLs regardless of the option. Test one URL after you change the setting rather than trusting that the setting took.
Sources
- WordPress core development note, Changes to attachment pages, for the
wp_attachment_pages_enabledoption, the new install versus upgrade defaults, the redirect behaviour, and core’s own description of the search problem. - Google Search Central, Page Indexing report, for what the crawled and duplicate statuses mean.