Audit WordPress attachment pages: Redirect pages without deleting images

Your crawl finds a page containing little more than an image. A guide already uses that image, and the Media Library shows another address for the file. Before removing anything, establish which URL you are looking at. You can deal with an unwanted attachment page while keeping the image that the guide needs.

This distinction matters particularly on older WordPress sites. Updating Core does not establish that every attachment page now redirects. Enabling a redirect setting in an SEO plugin establishes a configuration choice. You still need to check the response an anonymous visitor receives.

This workflow extends the broader principles of WordPress SEO. Its scope is media and the pages associated with them, rather than a general Media Library cleanup.

Separate the page from the file

WordPress can manage a media file through an attachment record. That record may have a public attachment page, while the image may have several generated sizes. The article embedding the image has its own address too.

The following example is entirely fictional. The ID, names and paths do not come from an inspected website:

A readable path does not reliably identify the resource type. The documentation for get_attachment_link() covers both readable permalinks and the attachment_id form. Filters can change the returned address.

By contrast, wp_get_attachment_url() returns the file address. That address may use a different host when media are offloaded or served through a CDN. Retrieve both values for the actual record instead of guessing one from the other.

A smaller image referenced in srcset is not necessarily the original uploaded file either. For image optimization, record whether your check covers the original, a delivered variant or an HTML page. One successful download does not establish the behavior of all the other routes.

What changed in WordPress 6.4

The Core development note explains that attachment pages are disabled by default on new installations starting with WordPress 6.4. The setting is wp_attachment_pages_enabled: new sites default to 0, while existing sites received 1 on upgrade to preserve their previous behavior. Administrators can change it.

The boundary concerns installations and their configuration. It does not mean every site running 6.4 or later has disabled attachment pages. Nor does it mean only images uploaded after an upgrade redirect.

A site created years ago can still serve attachment pages on a recent Core version. A clone of an existing installation also needs inspection. The date of a redesign does not tell you which option was copied into the new environment.

With attachment pages disabled, the intended Core redirect destination is the media file. A redirect to a parent article can come from another configuration. Keep these outcomes distinct when documenting the change: a link to an image and a link to an explanatory guide answer different visitor expectations.

Read the version, site setting and record first

If you have WP-CLI access, you can read the Core version and option. Run these commands in the correct WordPress directory. The fictional --url identifies the target site, which is particularly important in a multisite network.

bashwp core version
wp --url=https://example.com option get wp_attachment_pages_enabled

These commands read values. The WP-CLI option get documentation also describes choosing the site with --url. If the option cannot be found or the command fails, record that outcome. A failed read is not a confirmed value of 0.

Next, retrieve both addresses for a known attachment ID. For the fictional ID 417, the read-only request is:

bashwp --url=https://example.com eval 'echo get_attachment_link(417), PHP_EOL; echo wp_get_attachment_url(417), PHP_EOL;'

Without shell access, collect the file address from the Media Library and an existing attachment link from the public site. Interface labels and available buttons depend on the installation. A button label cannot substitute for checking the HTTP response.

Also record the active theme, relevant media and SEO plugins, and any upstream cache or redirect rules. The option describes the Core configuration. The public response comes from the whole system. A plugin can filter links, the server can redirect before WordPress runs, or a cache can serve an older response.

Preserve the mapping when replacing an image

When an editor replaces an image, record what should change: the image content alone, the filename as well, or the attachment record too. These cases require different checks. An unchanged display title does not establish an unchanged file address. Uploading a new file with a different name does not necessarily update every old link either.

Compare the recorded addresses before and after the replacement. Revisit the article, intended image variant and previous attachment link. If a cache still shows the old image, distinguish that finding from an incorrect redirect. Record the host and image size where the difference occurs.

For a larger change, include this mapping in your SEO migration checklist. Redirecting an attachment page to its file does not automatically handle a separate migration of old image-file URLs. Those require their own decision if the addresses change too.

Test the public response without a login

Include at least one older and one more recent media item. Where they exist, add an image with a parent article and an unattached item. These cases cover different paths through the installation; they are not a statistically representative sample.

Use a Site Audit to organize the subsequent technical website check. Supplement it with the attachment URLs you collected deliberately. An ordinary link crawl may not discover an unlinked historical URL even when an earlier export proves that address existed.

Start with a GET request that does not automatically follow redirects. The commands below display headers and discard the body. On Windows, use curl.exe if necessary to invoke curl itself.

bashcurl -sS -D - -o /dev/null 'https://example.com/?attachment_id=417'
curl -sS -D - -o /dev/null 'https://example.com/guides/wall-shelf/installation-step/'

Replace /dev/null with NUL on Windows. Do not supply an authenticated session or browser cookies for this check. A logged-in administrator's browser may see a different state from a public visitor.

Then repeat with -L to follow the chain. Read each Location, the final status and the content type. A final 200 without that context does not tell you whether you reached the attachment page, a login screen or the image.

Different responses from the ID-based and readable URLs are a finding to investigate. They do not establish a particular Core bug or faulty plugin by themselves. The current redirect_canonical() reference can help developers trace the behavior. Whether that code runs unchanged in the hosting environment is a separate question.

Decide whether to keep, redirect or exclude the page

An attachment page may serve a useful purpose. A curated photography page could provide a description, creator credit and a clear download option. Check its specific value, incoming links and observed search visits before treating it as an empty image frame. Having an attachment ID says nothing about content quality.

If the page should go, choose a destination that fits its previous role. The file may be appropriate for a visitor expecting the individual image. A closely related article may work for someone expecting instructions about that subject. A technical parent relationship does not automatically identify the best replacement: an image can appear in several articles or retain an old association.

For permanent redirects, Google's documentation recommends server-side responses when URLs have permanently moved. This does not guarantee preserved rankings. Keep the chain short and validate the destination instead of sending every attachment page to the homepage regardless of its content.

Keeping an HTML page available while excluding it from Google is a different decision. For noindex to work, Google must be able to retrieve the page, as the indexing control documentation explains. A simultaneous robots.txt block can prevent that. Inspect the HTML instruction and any HTTP indexing header on that specific URL.

A canonical tag also does not redirect a visitor. Give status code, redirect destination and indexing instruction separate fields in your findings. The team can then see which behavior was actually implemented.

Keep image availability as a separate acceptance check

Do not disable attachment pages by deleting the media. The official wp_delete_attachment() reference explicitly states that permanently deleting an attachment removes the file too. An image still required by an article can disappear as a result.

Inspect the addresses actually embedded in the article: src and srcset, relevant image variants and the CDN host where applicable. A rule intended for attachment HTML must not accidentally cover the entire uploads directory.

Google's image SEO documentation identifies standard HTML image elements as an important discovery route. Check the page that will continue presenting the image in context. A working file endpoint alone establishes neither correct embedding nor visibility in Google Images.

Read indexing instructions on the file and HTML page separately too. A blanket X-Robots-Tag: noindex across uploads would be an additional decision about the media themselves. Do not introduce that outcome silently when the goal is to remove thin attachment pages from web search.

Hand over a change with explicit acceptance criteria

Before implementation, prepare a short mapping: attachment ID, previous permalink, file address, intended behavior and reason. Save the public responses with their observation date. After the change, repeat those exact requests and revisit the articles using the images.

Preserve the previous option and affected rules so an unintended change can be reversed precisely. On production systems, identify the owner of the redirect and the cache layer that needs checking after a correction.

Assess indexing afterward using current fetches and the available Search Console evidence. Historical report rows do not necessarily change at the same time as the technical response. Keep the previously reported state distinct from what the URL returns today.

If an attachment page you deliberately retain is reachable but absent from Google, use the diagnosis for “Crawled, currently not indexed”. Increasing the number of indexed URLs is not a useful sign-off criterion. The technical change is complete when the agreed routes respond correctly, required image files remain available and the articles still work. Monitor later search performance separately.