When you duplicate a WordPress post or page, one small decision can have surprisingly large consequences for the Media Library: what should happen to the featured image?
At first glance, the answer seems obvious. If the new post is a copy of the original, its featured image should be copied too.
But “copying the featured image” can mean two very different things in WordPress.
You can make the duplicated post reference the same existing Media Library attachment, or you can create a completely new attachment and physical image file.
Those approaches may look identical on the frontend, but internally they produce very different results.
In most ordinary post-cloning workflows, reusing the existing attachment is the cleaner option. It preserves the featured image while avoiding duplicate files, duplicate attachment records and unnecessary generated image sizes.
Creating a separate media copy makes sense only when the duplicated post genuinely needs an independent asset that can later be edited, replaced or managed separately.
This guide explains how WordPress featured images are stored, what should happen when a post is duplicated, why cloning the attachment itself is usually unnecessary, when a real media duplicate is appropriate and how developers can implement both behaviors safely.
How WordPress actually stores a featured image
A WordPress featured image is not stored inside the post itself.
The image exists as a separate WordPress attachment. The post then stores a reference to that attachment.
The official get_post_thumbnail_id() documentation describes the featured image as an attachment ID associated with the post.
Conceptually, the relationship looks like this:
Post #120
↓
_thumbnail_id = 450
↓
Attachment #450
↓
/wp-content/uploads/2026/09/hero-image.jpgThe important part is _thumbnail_id.
WordPress stores the featured-image relationship in post metadata using that key. The value is the ID of an attachment in the Media Library.
If the featured image is attachment 450, the post does not need its own private copy of the image. It simply references attachment 450.
WordPress provides set_post_thumbnail() for establishing this relationship programmatically.
A basic example is:
$attachment_id = 450;
$post_id = 120;
set_post_thumbnail( $post_id, $attachment_id );Internally, Core associates the attachment ID with the post’s _thumbnail_id metadata.
The featured image and the image file are different objects
This distinction is fundamental to understanding duplication.
There are several layers involved:
- the post using the featured image;
- the
_thumbnail_idrelationship; - the attachment post in the Media Library;
- the original uploaded file;
- the attachment metadata;
- the generated image sub-sizes.
Changing one layer does not necessarily mean creating new copies of all the others.
This is also why attachments should not be treated as ordinary posts during generic cloning. See Which WordPress Content Types Should Never Be Cloned for the broader distinction between reusable editorial content and records that need specialized handling.
What should happen when you duplicate a post?
Suppose you have:
Post A
Featured image → Attachment #450You duplicate Post A and create Post B.
The simplest and usually most appropriate result is:
Post A
Featured image → Attachment #450
Post B
Featured image → Attachment #450Both posts now use the same Media Library attachment.
No image file has been copied.
No second attachment has been created.
No additional thumbnails need to be generated.
The new post simply receives the same featured-image relationship.
Sharing an attachment is normal WordPress behavior
An attachment does not have to belong exclusively to one post.
The same Media Library image can be used:
- as the featured image of several posts;
- inside multiple Image blocks;
- inside a gallery;
- inside a Query Loop template;
- inside a Cover block;
- inside custom fields;
- inside page-builder content.
WordPress’s Page/Post Settings documentation explains that a featured image can be selected from the existing Media Library or uploaded as a new image.
That existing-media workflow is exactly what makes attachment reuse a normal part of WordPress rather than an exceptional case.
Reusing the featured image is not the same as duplicating it
This terminology causes much of the confusion.
A cloning plugin may say that it “copies the featured image,” but technically it may only copy the relationship.
That is usually desirable.
Consider this original post:
Post #120
_thumbnail_id = 450A cloned post could be created with:
Post #900
_thumbnail_id = 450The featured-image setting has been duplicated, but the media attachment has not.
This is fundamentally different from:
Post #120
_thumbnail_id = 450
↓
hero-image.jpg
Post #900
_thumbnail_id = 901
↓
hero-image-copy.jpgIn the second model, WordPress has two attachment records and two independent source files.
Why reusing the attachment is normally better
Reusing the existing attachment avoids:
- duplicate source files;
- duplicate Media Library entries;
- duplicate attachment metadata;
- duplicate generated image sizes;
- additional storage usage;
- confusing nearly identical media records;
- unnecessary backup size;
- additional media-management work.
If twenty cloned landing pages intentionally use the same corporate hero image, WordPress does not need twenty copies of that image.
One attachment referenced by twenty posts is usually the cleaner data model.
How to preserve a featured image when cloning a post
From a development perspective, preserving the same featured image is straightforward.
First retrieve the source post’s attachment ID with get_post_thumbnail_id(), then assign that ID to the newly created post with set_post_thumbnail().
$source_post_id = 120;
$new_post_id = 900;
$thumbnail_id = get_post_thumbnail_id( $source_post_id );
if ( $thumbnail_id ) {
set_post_thumbnail( $new_post_id, $thumbnail_id );
}This copies the relationship rather than the physical media asset.
The official get_post_thumbnail_id() reference returns the attachment ID associated with the post’s featured image, while set_post_thumbnail() assigns an attachment as another post’s featured image.
You could copy _thumbnail_id directly, but the API is clearer
Because the relationship is stored in post metadata, code could technically retrieve and copy the _thumbnail_id value directly.
For example:
$thumbnail_id = get_post_meta(
$source_post_id,
'_thumbnail_id',
true
);However, the dedicated featured-image functions communicate intent more clearly and allow the implementation to work through the WordPress API designed for that purpose.
When WordPress provides a public API for a particular relationship, using that API is generally preferable to treating the underlying database representation as the primary interface.
No thumbnail regeneration is needed
If both posts reference attachment 450, the image sizes associated with attachment 450 already exist.
There is no reason to regenerate them simply because another post now uses the attachment.
The attachment remains the same object.
What happens to generated image sizes?
When WordPress processes an uploaded image, it can create multiple image sub-sizes.
The official wp_generate_attachment_metadata() documentation explains that WordPress generates attachment metadata and creates thumbnails and other intermediate image sizes for supported images.
An upload might therefore result in files conceptually similar to:
hero-image.jpg
hero-image-150x150.jpg
hero-image-300x200.jpg
hero-image-768x512.jpg
hero-image-1024x683.jpgThe exact files depend on the registered image sizes and the dimensions of the source image.
WordPress records information about generated sub-sizes in the attachment metadata.
The attachment can then be rendered at an appropriate size depending on the context.
Two posts sharing one featured image share its derivatives too
If Post A and Post B both reference attachment 450, they also use the same attachment metadata and available image sub-sizes.
WordPress does not generate another set such as:
hero-image-copy-150x150.jpg
hero-image-copy-300x200.jpg
hero-image-copy-768x512.jpgmerely because the attachment appears on another post.
This is one of the biggest practical advantages of preserving the attachment ID during cloning.
For sites with thousands of images and many registered image sizes, unnecessary media duplication can otherwise multiply storage usage surprisingly quickly.
Responsive image output also follows the attachment
When WordPress renders an attachment through its media APIs, it can use attachment metadata to construct responsive image output.
The wp_get_attachment_image() function, for example, returns HTML for an image attachment and works with WordPress’s attachment and image-size system.
Sharing the attachment therefore preserves the same underlying responsive-image resources rather than manufacturing another media object solely because the post was duplicated.
When should the featured image actually be duplicated?
There are situations where creating a new attachment is appropriate.
The deciding question is not whether the post was cloned. It is whether the image itself needs an independent lifecycle.
The clone will receive a different edited image
Suppose a company duplicates a landing page for a second market.
The original uses:
hero-italy.jpg
The new page initially looks identical, but its image will soon be edited with different text, branding or localization.
If both posts continue referencing the same attachment, replacing the shared media asset could affect both pages.
An independent attachment can make sense when the new page genuinely needs its own image asset.
The image needs independent metadata
An attachment has its own metadata and editorial properties.
If two uses require genuinely different media-level information or management, separate attachments may be appropriate.
Do not create duplicate attachments merely to change how an image is presented by a particular block or template, however. Presentation-level differences often belong in the consuming content rather than in duplicate media records.
The duplicated content will become a separate reusable template
Sometimes a cloned piece of content is being turned into an independent campaign or reusable package that should have no media dependency on the original.
In that situation, duplicating selected assets may be an intentional part of creating an independent content bundle.
The key word is intentional.
A cloning tool should not manufacture independent media files automatically when the site does not need them.
How a true featured-image duplicate should be created
If a separate attachment is genuinely required, copying only the attachment database record is not enough.
A complete media duplication workflow has to consider:
- the source file;
- the uploads directory;
- a unique destination filename;
- the new attachment post;
- attachment metadata;
- generated image sub-sizes;
- the new featured-image relationship.
WordPress provides media APIs for creating and processing attachments rather than requiring developers to manipulate those layers manually.
The media_handle_sideload() function, for example, handles a sideloaded file using WordPress’s media workflow and creates an attachment for it.
For newly created attachments, wp_generate_attachment_metadata() generates attachment metadata and image sub-sizes.
A real duplicate needs a new attachment ID
The end result should conceptually be:
Original Post
↓
Attachment #450
↓
hero-image.jpg
Cloned Post
↓
Attachment #901
↓
hero-image-copy.jpgAttachment 901 is now an independent WordPress media object.
Changing or deleting it does not mean changing attachment 450.
Do not duplicate only the database metadata
Copying the attachment post and its metadata while leaving both records pointed at the same underlying physical file creates an awkward hybrid.
You now have two attachment IDs that appear independent in WordPress but may still depend on one physical asset.
Operations such as deletion, replacement, metadata regeneration and file management become considerably harder to reason about.
If you need independence, create genuine independence. If you do not, reuse the existing attachment.
Shared attachments and media replacement
Reusing a featured image has one important consequence: the attachment is shared.
Imagine:
Post A → Attachment #450
Post B → Attachment #450
Post C → Attachment #450If you replace the file associated with attachment 450 while preserving its identity, all three posts still reference attachment 450.
They can therefore all display the updated asset.
This behavior can be either exactly what you want or exactly what you do not want.
Replacement preserves identity
TheOneWP Media Replace provides a workflow for replacing the file behind an existing Media Library attachment while preserving the attachment relationship.
This distinction matters because featured images normally reference the attachment ID, not a private copy of the source file.
For example:
Product A featured image
→ Attachment #450
Article B featured image
→ Attachment #450If attachment 450 is intentionally replaced, both references remain valid because the attachment identity remains the same.
This is useful when an asset itself has been updated globally, such as:
- a corrected product image;
- an updated company logo;
- a revised diagram;
- a new version of an existing campaign graphic.
Upload a new attachment when only one use should change
If Post B should use a different image while Post A must preserve the original, changing the shared attachment is the wrong operation.
Instead:
- upload or create the new image as a separate attachment;
- assign that new attachment as Post B’s featured image;
- leave Post A connected to the original attachment.
This gives each content object the intended relationship without unnecessary duplication elsewhere.
Featured image duplication can affect SEO and media organization
Creating unnecessary media duplicates is not usually an SEO catastrophe by itself, but it can make the site harder to maintain and create confusing asset structures.
Suppose the Media Library contains:
office-team.jpg
office-team-1.jpg
office-team-2.jpg
office-team-3.jpg
office-team-4.jpgand all five files are visually identical.
Editors now have to determine which attachment should be used, which ones are referenced and which can safely be removed.
The problem becomes worse when each attachment also has its own generated sub-sizes.
For guidance on managing larger media collections, see Organizing a Large WordPress Media Library and Keeping a WordPress Media Library Organized at Scale.
Do not confuse featured-image reuse with duplicate page content
Two posts using the same featured image does not mean those posts are duplicate content.
Content duplication and media reuse are separate concepts.
It is entirely normal for several pages to use:
- the same logo;
- the same team photograph;
- the same product image;
- the same background asset;
- the same campaign graphic.
The SEO problem arises when pages themselves substantially duplicate one another without a clear purpose, not merely because they reference the same Media Library attachment.
For that distinction, see Duplicate Content in WordPress, Explained.
Alt text belongs to the attachment
WordPress commonly stores an image’s alternative text as attachment metadata.
That means two posts referencing the same attachment generally reference the same stored alt-text value when WordPress derives output from that attachment.
This deserves consideration when the same image has meaningfully different purposes in different contexts.
Sometimes the correct answer is still to share the attachment and control the rendered alternative text at the point of use. In other workflows, genuinely different media semantics may support using separate assets.
The decision should follow accessibility requirements rather than a blanket rule that every reuse needs a duplicated attachment.
Featured images in the Block Editor and Site Editor
Modern WordPress can display featured images in several ways beyond a traditional PHP theme calling a post-thumbnail function.
The Post Featured Image block can display the featured image dynamically inside templates and Query Loop structures.
The block does not need a separate image copied into the template.
It represents the featured image of whichever post is currently being rendered.
Conceptually:
Post Template
↓
Post Featured Image block
↓
Current post
↓
Current post's _thumbnail_id
↓
AttachmentThis separation is useful because the design template can remain reusable while every post points to its own featured-image attachment.
An Image block is not the same as a Post Featured Image block
An ordinary Image block references a chosen image as block content.
The Post Featured Image block dynamically represents the featured image associated with the current post.
WordPress’s current Image block documentation also provides a “Set as featured image” action, allowing the selected image to become the post’s featured image.
Understanding this distinction is useful when cloning block-based content. A duplicated ordinary Image block can continue referencing its selected attachment, while the Post Featured Image block continues to resolve the featured-image relationship of the post being displayed.
For a broader explanation of modern template behavior, see WordPress Full Site Editing and Block Widgets, Explained.
Common featured-image cloning mistakes
Most problems come from treating the image as though it were embedded inside the post rather than referenced through a separate attachment.
Creating a new physical image for every cloned post
This creates unnecessary Media Library records and files when the posts could simply share one attachment.
If the image is intended to remain identical, reuse it.
Copying the attachment post without copying the file correctly
This can create two attachment records whose independence is questionable because their underlying media storage was not duplicated consistently.
Use the WordPress media APIs when a genuine independent attachment is required.
Regenerating thumbnails when the attachment did not change
Assigning attachment 450 to another post does not alter attachment 450.
Its generated sub-sizes already exist, so there is normally nothing to regenerate.
Replacing a shared attachment when only one post should change
If several posts reference the same attachment, replacing that attachment is a shared operation.
Create a new attachment and change only the desired post when the new asset should be local to that post.
Deleting a shared attachment because one cloned post no longer needs it
Removing a featured-image relationship from one post is not the same as deleting the Media Library attachment.
If the attachment is used elsewhere, deleting it can break those other references.
When a post no longer needs its featured image, remove the relationship from that post rather than assuming the media file itself is unused.
Assuming attachment parent tells you every place an image is used
WordPress attachments can be referenced from many locations independently of their historical post_parent value.
An image may be a featured image on one post, embedded in another and referenced by custom fields elsewhere.
This is why attachment usage cannot reliably be determined from one parent relationship alone.
The deeper attachment model is discussed in WordPress Attachment Status and Term Counts, Explained.
A practical duplication strategy
A safe cloning feature should make an explicit decision about featured images rather than accidentally copying whatever metadata happens to exist.
A useful default strategy is:
| Situation | Recommended behavior |
|---|---|
| Normal post or page clone | Reuse the existing featured-image attachment ID |
| Clone will intentionally use the same image | Reuse the existing attachment |
| Clone will soon receive another image | Reuse initially, then assign a different attachment when needed |
| Image itself must become independently editable | Create a genuine new attachment and file |
| Shared asset needs a global replacement | Replace the existing attachment while preserving its identity |
| Only one post needs a modified version | Create a new attachment for that version |
Make the behavior predictable
If a cloning tool offers different featured-image strategies, the interface should make the difference clear.
For example:
- Keep featured image could reuse the current attachment;
- Duplicate media file could explicitly create an independent attachment;
- Remove featured image could leave the clone without one.
The wording matters because “duplicate featured image” is ambiguous. Some users expect the new post to display the same image. Others expect an entirely separate Media Library asset.
A well-designed system should not force users to understand _thumbnail_id before they can predict what a button will do.
How this fits into WordPress content cloning
Featured images illustrate a broader principle of WordPress duplication: copy relationships when appropriate, but do not duplicate the related object unless independence is actually required.
The same reasoning can apply to:
- taxonomy terms;
- authors;
- shared media;
- referenced templates;
- other reusable WordPress objects.
If a cloned post belongs to the same category, WordPress normally references the same category term rather than creating a duplicate category.
Likewise, if it uses the same featured image, WordPress can reference the same attachment rather than creating a duplicate media record.
This is why generic database copying is rarely the best mental model for WordPress cloning.
A good cloning system understands which properties are values, which are relationships and which represent independent application objects.
For the broader safety rules, see Which WordPress Content Types Should Never Be Cloned.
Related guides
- Which WordPress Content Types Should Never Be Cloned
- Duplicate Content in WordPress, Explained
- WordPress Attachment Status and Term Counts, Explained
- Organizing a Large WordPress Media Library
- Keeping a WordPress Media Library Organized at Scale
- WordPress Full Site Editing and Block Widgets, Explained
Final recommendation
When duplicating a WordPress post, the featured image should normally be preserved by copying its attachment relationship, not by copying the physical image.
If the source post uses attachment 450, the cloned post can also use attachment 450. WordPress supports multiple pieces of content referencing the same Media Library item, and doing so avoids unnecessary files, attachment records and generated image sizes.
This is the most efficient behavior when the image is genuinely shared.
Create a new attachment only when the duplicated content requires an image with an independent lifecycle. That may be appropriate when the new image will be edited separately, replaced independently or maintained as a distinct media asset.
When creating a real duplicate, duplicate the complete media object correctly: create the new physical file, register a new attachment, generate its metadata and image sub-sizes, and assign the resulting attachment ID to the cloned post.
Do not create a second attachment record that merely pretends to be independent while still relying on the same underlying file.
Finally, remember the consequence of sharing attachments. If several posts reference the same featured image, replacing that attachment can update the asset everywhere it is used. If only one post should change, give that post a different attachment instead.
The cleanest cloning system therefore distinguishes between two operations that sound similar but are technically very different: preserving the featured image and duplicating the media asset.