# What happens to WordPress attachment pages after migration? > When you migrate off WordPress, you do not recreate its attachment pages, because those are the thin, auto-generated pages WordPress makes for every uploaded image, and they add no value; a rebuilt site simply does not generate them. What you do handle is their URLs. If those attachment pages were indexed or linked, you map each one to a 301 redirect pointing at its parent post or the image file, so you avoid a wave of 404s and any residual value flows to a real page. This also stops the crawl budget waste that thin attachment pages cause, since search engines no longer chase pages that only display a single image. The image files themselves migrate separately and keep their SEO; it is only the attachment pages that you retire and redirect. WPBuildAI rebuilds without generating attachment pages and maps every old attachment URL to a verified 301, so nothing 404s and no crawl budget is wasted. Source: https://wpbuildai.com/what-happens-to-wordpress-attachment-pages-after-migration/ By lawrence-arya ยท 2026-06-20 --- When you migrate off WordPress, you do not recreate its attachment pages, because those are the thin, auto-generated pages WordPress makes for every uploaded image, and they add no value; a rebuilt site simply does not generate them. What you do handle is their URLs. If those attachment pages were indexed or linked, you map each one to a 301 redirect pointing at its parent post or the image file, so you avoid a wave of 404s and any residual value flows to a real page. This also stops the crawl budget waste that thin attachment pages cause, since search engines no longer chase pages that only display a single image. The image files themselves migrate separately and keep their SEO; it is only the attachment pages that you retire and redirect. WPBuildAI rebuilds without generating attachment pages and maps every old attachment URL to a verified 301, so nothing 404s and no crawl budget is wasted. ## What attachment pages are, and why they exist The confusion here is between an image and the page WordPress wraps around it. When you upload an image, WordPress does two things: it stores the file, and it also creates a small page whose only job is to display that one image, reachable at an address like ?attachment_id=123 or /post-name/image-slug/. That second thing is the attachment page. It is generated automatically, it usually has no real content of its own, and most site owners never even know it exists until they find dozens of them in the index. So an attachment page is a byproduct of the WordPress media system, not something you deliberately created, which is the first clue that you do not need to carry it forward. ## Why you retire them rather than rebuild them Because attachment pages are thin and near-duplicate, they are a liability, not an asset. A site can accumulate hundreds of them, each holding a single image and little else, and search engines spend crawl effort on those empty pages instead of your real content. This is why SEO plugins commonly redirect attachment URLs in the first place, and why a mass of indexed attachment pages is a known drag on a site. A rebuilt site does not generate them, so the migration removes the problem at the source rather than reproducing it. Given that traffic and value concentrate on a minority of real pages, as the [Ahrefs study](https://ahrefs.com/blog/search-traffic-study/) shows, dropping the thin ones loses nothing and tidies the index. ## Where to redirect the attachment URLs Retiring the pages does not mean ignoring their addresses. Any attachment URL that was indexed or linked should be sent somewhere real with a 301, rather than left to 404. The natural target is the parent post the image appeared in, because that is the page a visitor or a crawler actually wants when they land on an image address. Redirecting to the image file itself is also valid when the file is genuinely the destination. Either choice consolidates the request onto something that exists, which is the whole point of handling a [URL change with 301s](https://developers.google.com/search/docs/crawling-indexing/301-redirects). To do it completely you need the full list of attachment URLs, which is why [extracting every URL up front](/find-extract-all-urls-website-301-redirects) is the practical starting point. ## Images migrate separately from attachment pages It is worth being precise, because this trips people up. The image files and the attachment pages are two different things, and they migrate on different tracks. The files, the actual images, move with your media library and keep their SEO when their URLs are preserved or redirected, which is covered in [whether images keep their SEO after migration](/do-images-keep-seo-after-website-migration). The attachment pages, the near-empty wrappers, are the part you retire. So a clean migration keeps your images and their rankings while dropping the thin pages around them, and confusing the two is what leads people either to preserve pages they should retire or to worry that retiring pages will lose their images. It will not; the files are handled on their own. ## Handling the parameter and slug variants Attachment pages show up in more than one URL shape, so map all of them. Some appear as query parameters, like ?attachment_id=123, and some as clean slugs, like /post-name/image-slug/, depending on your permalink settings and whether an SEO plugin rewrote them. Both forms may be indexed, so both need to be in the redirect map, which overlaps with the general work of [handling parameter URLs in a migration](/how-to-handle-pagination-and-parameter-urls-in-a-migration). Where an attachment page truly had no inbound value and you would rather retire it outright than redirect, a 410 is an option, though a 301 to the parent post is the safer default; the difference is covered in [404 versus 410 for deleted pages](/404-vs-410-deleted-pages-after-migration). Capturing every variant is what prevents stray 404s after launch. ## Steps to handle attachment pages in a migration 1. **Do not recreate them:** the rebuilt site will not generate attachment pages, and that is correct. 2. **Extract every attachment URL**, both the ?attachment_id and clean-slug forms. 3. **Choose a target** for each, normally the parent post, sometimes the image file. 4. **301 the attachment URLs** to those targets with verified redirects. 5. **Confirm the image files migrated** separately and keep their own URLs or redirects. 6. **Watch Search Console** for attachment 404s and consolidation over the next crawls. ## Worked example: clearing 300 thin pages cleanly Consider a long-running blog that, unknown to its owner, had roughly 300 attachment pages indexed, one per image uploaded over the years. Moving off WordPress, the rebuild did not generate any attachment pages at all, so the thin pages stopped existing by default. The old attachment URLs, in both the ?attachment_id and slug forms, were extracted and each mapped to a 301 pointing at the post the image had appeared in. The image files themselves migrated with the media library and kept their addresses. Over the following crawls, Google consolidated the attachment URLs onto the parent posts, the 300 thin pages dropped out of the index without any 404s, and crawl attention shifted to the content that actually earned traffic. ## Limitation: consolidation is gradual, and rare cases have real value It is honest to bound this. Redirecting the attachment URLs is correct, but Google works through the 301s over several crawls, so the thin pages leave the index gradually rather than at once; expect to watch it settle in Search Console. And while attachment pages almost never hold value, there is the rare exception, an image that somehow attracted links or a gallery page that was deliberately built up, so check your data before treating everything as disposable. If a specific attachment URL genuinely earned links, redirect it thoughtfully to the most relevant real page rather than dropping it. The default of retire-and-redirect is right for the overwhelming majority. ## Common mistakes - Recreating attachment pages on the new site, reproducing a problem the rebuild had solved. - Letting attachment URLs 404 instead of redirecting the indexed or linked ones. - Mapping only the slug form and missing the ?attachment_id variants, or the reverse. - Confusing attachment pages with the image files and worrying the images will be lost. - Assuming the cleanup is instant, rather than watching consolidation in Search Console. ## Key points When you migrate off WordPress, you retire its attachment pages rather than recreate them, because they are thin, auto-generated wrappers around a single image, and a rebuilt site does not produce them. Extract every attachment URL, in both the ?attachment_id and clean-slug forms, and 301 each indexed or linked one to its parent post or the image file, so no address 404s and crawl budget stops draining into empty pages. The image files migrate on their own track and keep their SEO, so retiring the pages does not touch your images. Consolidation is gradual, so watch it in Search Console, and check for the rare attachment URL that genuinely earned links before treating it as disposable. WPBuildAI rebuilds without generating attachment pages and maps every old attachment URL to a verified 301, so nothing 404s and no crawl budget is wasted. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.