How to Duplicate a WordPress Page or Post

Duplicating a WordPress page or post is one of the fastest ways to create new content when an existing item already contains the structure, layout or configuration you need.

Instead of rebuilding a page from scratch, you can use an existing post as the starting point for another independent WordPress content item.

This is particularly useful when the original already contains:

• a reusable page structure;
• Gutenberg blocks;
• formatted content;
• custom fields;
• a featured image;
• categories or tags;
• custom taxonomy terms;
• a page template;
• SEO metadata;
• page-builder configuration;
• plugin-specific settings.

But WordPress duplication is more complicated than copying the text visible inside the editor.

A WordPress post or page is a database object connected to metadata, taxonomies, media attachments, templates, users and potentially data managed by third-party plugins.

That creates an important distinction:

copying the visible editor content is not necessarily the same as duplicating the complete WordPress content object.

A reliable cloning process needs to understand which information belongs to the content, which information should be reused, and which values should deliberately remain unique.

This guide explains how to duplicate a WordPress page or post manually and programmatically, which data should be copied, how metadata and taxonomies behave, what happens to featured images and URLs, how duplication affects SEO, and what should be reviewed before the duplicate is published.

What does duplicating a WordPress page or post actually mean?

Pages and posts use WordPress’s underlying post system.

The main database record contains information such as:

• title;
• content;
• excerpt;
• post type;
• post status;
• author;
• publication date;
• parent;
• menu order.

Other information can be connected to that record separately.

Examples include:

• post metadata;
• featured images;
• categories;
• tags;
• custom taxonomies;
• custom fields;
• page templates;
• SEO settings;
• page-builder data;
• plugin configuration.

A proper duplicate therefore creates a new WordPress post object and then copies the relevant information from the source.

This matters because the duplicate must remain independent.

Changing the duplicated page should not change the original page, and changing the original should not unexpectedly modify the duplicate.

A duplicate needs its own WordPress identity

Consider an existing page:

Post ID: 184
Title: Web Design
Slug: web-design
Status: publish

A duplicated version should become another WordPress object:

Post ID: 527
Title: Web Design - Copy
Status: draft

The new page may initially contain the same content, but it has its own ID and lifecycle.

WordPress provides wp_insert_post() for creating post objects programmatically. The official WordPress wp_insert_post() documentation describes the fields that can be supplied when inserting or updating content.

The distinction between the source ID and the new ID becomes especially important when other data references the post.

For example, metadata attached to post 184 does not automatically belong to post 527.

Taxonomy relationships also need to be associated with the new object.

A duplication system therefore needs to reconstruct the useful relationships around the new post rather than merely changing an identifier.

If you want to understand where these different pieces of information actually live, The WordPress Database Structure, Explained provides a useful overview of the underlying tables and relationships.

Duplicating a post is different from creating a revision

WordPress duplication and WordPress revisions solve different problems.

A revision represents an earlier saved state of the same post.

A duplicate represents another independent post.

Conceptually, revisions look like this:

Page #184
├── Revision
├── Revision
├── Revision
└── Current version

Duplication looks like this:

Page #184
└── Original content

Page #527
└── Independent duplicate

Restoring a revision changes page #184.

Editing the duplicate changes page #527 without modifying the original.

The official WordPress revisions documentation explains how revisions are stored, compared and restored.

For a deeper look at the distinction, see What Are WordPress Post Revisions, Really? and WordPress Autosave vs. Post Revisions, Explained.

Duplication is also different from autosave

Autosave protects work while an editor is making changes.

It is not intended to create another independent piece of content.

If you want to experiment with a substantially different version of a page while keeping the published original untouched, creating a duplicate draft may therefore be more appropriate than relying on revisions or autosaves alone.

The original can remain publicly available while the duplicate is developed separately.

If autosave behavior itself needs adjustment, see How to Change the WordPress Autosave Interval.

Why duplicate a WordPress page or post?

Duplication is most valuable when creating a new content item involves a substantial amount of repetitive setup.

Suppose every service page on a website contains:

• a hero section;
• an introduction;
• a benefits section;
• a process section;
• testimonials;
• FAQs;
• a call to action;
• specific custom fields;
• SEO configuration.

Recreating that structure manually every time adds work without adding value.

A duplicate can provide the established structure immediately.

The editor can then replace the content that needs to be unique.

Common duplication workflows

WordPress content duplication is commonly useful for:

• service pages;
• landing pages;
• location pages;
• case studies;
• portfolio items;
• team profiles;
• event pages;
• documentation;
• structured blog posts;
• custom post type entries;
• campaign pages;
• product-related editorial pages.

In each case, the value comes from preserving a useful starting structure while allowing the new item to become independent.

How to duplicate a WordPress page manually

For an occasional simple page, the easiest approach may be to create another page and manually copy the editor content.

The basic workflow is:

1. open the existing page;
2. copy its editor content;
3. create a new page;
4. paste the content;
5. enter a new title;
6. configure the permalink;
7. restore any required page settings;
8. select the appropriate featured image;
9. review categories or other taxonomies;
10. save the new page as a draft.

For simple Gutenberg content, this may be sufficient.

The limitation is everything that exists outside the main editor.

Copying the editor does not copy the entire page

Imagine that the original page contains:

Gutenberg content
Featured image
Custom page template
Custom fields
SEO title
SEO description
Custom taxonomy
Plugin-specific metadata

Copying the visible blocks may reproduce the content while leaving the other settings behind.

The duplicate may therefore look similar in the editor but behave differently on the frontend.

This becomes increasingly important on websites using:

• advanced custom fields;
• custom post types;
• custom taxonomies;
• SEO plugins;
• page builders;
• membership systems;
• ecommerce plugins;
• custom templates;
• editorial workflow plugins.

For recurring duplication, a dedicated cloning system is usually more reliable than manually reconstructing every setting.

What should be copied when duplicating WordPress content?

There is no universal list because WordPress sites can attach very different information to posts.

A typical duplication system begins with the main post fields.

These may include:

• post_title;
• post_content;
• post_excerpt;
• post_type;
• post_author;
• post_parent where appropriate;
• menu_order where appropriate.

But each field should be considered deliberately.

Post title

The original title can be copied as a starting point, but the duplicate should normally be clearly identifiable.

For example:

Original:
Web Design Services

Duplicate:
Web Design Services - Copy

The temporary suffix helps editors distinguish the draft from the source.

It should normally be removed before publication.

Post content

The main content is usually the primary reason for duplication.

For Gutenberg pages, copying post_content generally preserves the block markup as well as the visible text.

Excerpt

An excerpt may be copied when it provides a useful starting point, but it should be reviewed if the duplicate develops into content with a different subject.

Author

There are two reasonable approaches:

• preserve the original author;
• assign the duplicate to the user performing the cloning operation.

The appropriate behavior depends on the editorial workflow.

A newsroom may want attribution preserved, while an agency workflow may prefer assigning the new draft to the editor who created it.

Post status

The status deserves special attention.

A published source should not normally produce another immediately published page.

Create published duplicates as drafts

Automatically publishing an identical copy can expose repeated content before anyone has reviewed it.

A safer workflow is:

Published original
        ↓
Duplicate
        ↓
New draft
        ↓
Edit
        ↓
Review
        ↓
Publish

This gives the editor time to change:

• title;
• slug;
• content;
• internal links;
• featured image;
• taxonomies;
• custom fields;
• SEO metadata.

Duplication should provide a starting point rather than automatically create another public URL.

Why draft status matters operationally

The issue is not limited to search engines.

An accidentally published duplicate may appear in:

• navigation;
• sitemaps;
• RSS feeds;
• internal search results;
• archive pages;
• related-post systems;
• API responses;
• third-party integrations.

Keeping the duplicate unpublished until review avoids introducing unfinished content into these systems.

How to duplicate a WordPress post with PHP

A basic custom duplication system can be built using WordPress Core APIs.

The first step is retrieving the original post.

WordPress provides get_post() for this purpose. See the official get_post() reference for the available parameters and return values.

A simplified implementation begins with:

<?php

$original = get_post( $post_id );

if ( ! $original ) {
    return;
}

You can then prepare the new post data:

$new_post_data = array(
    'post_title'   => $original->post_title . ' - Copy',
    'post_content' => $original->post_content,
    'post_excerpt' => $original->post_excerpt,
    'post_status'  => 'draft',
    'post_type'    => $original->post_type,
    'post_author'  => get_current_user_id(),
);

$new_post_id = wp_insert_post(
    $new_post_data,
    true
);

if ( is_wp_error( $new_post_id ) ) {
    return;
}

This creates the new post record.

At this point, however, only the fields supplied to wp_insert_post() have been reproduced.

Metadata and taxonomy relationships still need separate consideration.

Do not copy the database row directly

It may be tempting to think of duplication as copying a row from the wp_posts table.

That is a poor abstraction for application code.

WordPress APIs handle important behavior around post creation and provide extension points that plugins and themes can use.

Working through WordPress APIs also makes the implementation easier to understand and maintain than direct SQL designed around the current database structure.

For the broader database model, see The WordPress Database Structure, Explained.

How to duplicate WordPress custom fields

Post metadata is stored separately from the main post record.

Creating another post does not automatically transfer every metadata value attached to the source.

WordPress provides get_post_meta() for retrieving metadata.

The official get_post_meta() documentation explains how metadata associated with a post can be retrieved.

A simplified metadata copy could look like this:

$metadata = get_post_meta(
    $original->ID
);

foreach (
    $metadata as $meta_key => $values
) {

    foreach (
        $values as $value
    ) {

        add_post_meta(
            $new_post_id,
            $meta_key,
            maybe_unserialize( $value )
        );
    }
}

That demonstrates the mechanism.

It does not mean that blindly copying every metadata key is a good production strategy.

Not every custom field should be cloned

Metadata can contain several different kinds of information:

• editorial data;
• page-template settings;
• featured-image references;
• SEO configuration;
• page-builder layouts;
• internal plugin state;
• caches;
• editing information;
• temporary values;
• unique identifiers.

Some describe the content and are useful to the duplicate.

Others describe the state or identity of the original post and should not necessarily be copied.

A robust duplication system should therefore support exclusions.

Use an exclusion list for internal metadata

A custom duplication implementation can explicitly skip metadata that should not be inherited.

A simplified pattern might be:

$excluded_meta = array(
    '_edit_lock',
    '_edit_last',
);

foreach (
    $metadata as $meta_key => $values
) {

    if (
        in_array(
            $meta_key,
            $excluded_meta,
            true
        )
    ) {
        continue;
    }

    foreach (
        $values as $value
    ) {

        add_post_meta(
            $new_post_id,
            $meta_key,
            maybe_unserialize( $value )
        );
    }
}

The exact exclusion list depends on the website and installed plugins.

Do not assume that every metadata key beginning with an underscore is disposable either. Many important plugin settings and WordPress properties also use protected metadata keys.

The correct approach is to understand what the relevant metadata represents.

Do not copy editing locks and temporary state

WordPress can store temporary editor information as post metadata.

A new post should not inherit the editing state of another post.

The same principle applies to:

• temporary plugin values;
• generated caches;
• processing flags;
• background-job references;
• transient integration state.

The goal is to reproduce the useful content configuration, not every internal artifact associated with the source object.

This distinction becomes more important as the website accumulates plugins because each plugin may attach its own metadata to posts.

What happens to the featured image when a post is duplicated?

A featured image is associated with a post through a reference to a Media Library attachment.

Duplicating the featured image therefore does not normally require copying the physical image file.

Instead, both posts can reference the same attachment:

Media attachment #91
        ↑
        ├── Original post #184
        └── Duplicate post #527

This avoids unnecessary copies of the same media file.

The duplicate can later be assigned another featured image without changing the original post.

WordPress exposes featured-image functionality through functions such as get_post_thumbnail_id() and set_post_thumbnail().

Copy the relationship, not necessarily the file

A straightforward implementation can retrieve the original attachment ID:

$thumbnail_id = get_post_thumbnail_id(
    $original->ID
);

if ( $thumbnail_id ) {

    set_post_thumbnail(
        $new_post_id,
        $thumbnail_id
    );
}

The result is two posts referencing the same attachment.

This is usually exactly what you want when the image itself has not changed.

For a more detailed discussion of this specific case, see WordPress Featured Image Duplication, Explained.

When should the media file itself be duplicated?

A separate attachment may make sense when the new content needs a genuinely independent media asset.

For example, you may want to:

• replace the image without affecting workflows associated with the original;
• use a differently optimized version;
• change attachment metadata independently;
• maintain separate rights or attribution information;
• create a campaign-specific asset.

For ordinary page cloning, however, generating another physical copy of every image is usually unnecessary.

How to duplicate categories, tags and custom taxonomies

Taxonomy relationships are also stored separately from the main post content.

For ordinary WordPress posts, these relationships commonly include:

• categories;
• tags.

Custom post types may introduce taxonomies such as:

portfolio_category
service_type
location
product_brand
documentation_topic

WordPress provides wp_get_object_terms() for retrieving terms and wp_set_object_terms() for assigning them to an object.

See the official wp_get_object_terms() documentation and wp_set_object_terms() documentation.

A duplication process can retrieve the taxonomies associated with the source post type and reproduce the relevant relationships.

Retrieve the taxonomies for the post type

Instead of hardcoding only categories and tags, a more general implementation can inspect the taxonomies registered for the post type.

Conceptually:

$taxonomies = get_object_taxonomies(
    $original->post_type
);

foreach (
    $taxonomies as $taxonomy
) {

    $term_ids = wp_get_object_terms(
        $original->ID,
        $taxonomy,
        array(
            'fields' => 'ids',
        )
    );

    if (
        ! is_wp_error( $term_ids )
    ) {

        wp_set_object_terms(
            $new_post_id,
            $term_ids,
            $taxonomy
        );
    }
}

This makes the duplication mechanism more adaptable to custom content architectures.

Copied taxonomy assignments still need review

A cloned article may legitimately belong to another category.

A duplicated portfolio item may need another project type.

A duplicated location page may require a different geographical taxonomy.

Automation can preserve the starting configuration, but the editor still needs to decide whether that configuration describes the new content.

For a broader look at taxonomy behavior outside the simplest post-and-category setup, see WordPress Taxonomies Beyond Posts and Pages.

What happens to the slug when you duplicate a WordPress page?

The new content needs its own permalink identity.

If the original page uses:

/web-design/

the new page should not simply become another published page attempting to occupy the same URL.

WordPress contains logic for generating unique post slugs through wp_unique_post_slug().

The official wp_unique_post_slug() reference explains how uniqueness is determined according to post type, status and hierarchy.

Treat automatic copy slugs as temporary

A duplicate may temporarily receive a URL resembling:

/web-design-copy/

or another automatically generated variation.

That is useful for preventing conflicts while the page is being prepared.

It does not mean the generated slug should become the final public permalink.

If the duplicate becomes a new page about ecommerce development, its eventual URL should describe that page:

/ecommerce-development/

rather than how the page happened to be created.

What happens to the publication date?

The original publication date should not automatically be treated as the publication date of a new independent article.

If a post published three years ago is duplicated today, the new draft represents content being created today, even though its structure came from an older post.

Preserving the original date can create confusing behavior in:

• archives;
• feeds;
• date-based URLs;
• sorting;
• editorial reports;
• content freshness workflows.

A duplication system should therefore consider publication dates separately from the reusable content itself.

For a draft, allowing WordPress to handle the eventual publication timestamp is usually more appropriate than copying the original date blindly.

What happens to the page parent?

Pages and other hierarchical post types can have parent-child relationships.

For example:

Services
├── Web Design
├── SEO
└── Ecommerce

If Web Design is duplicated, should the copy remain a child of Services?

Sometimes yes.

If the new page will become another service page, preserving the parent can save work.

But if the duplicate is being repurposed elsewhere in the site, copying the parent relationship can produce an incorrect hierarchy and permalink.

Hierarchical relationships should therefore be copied only when they remain meaningful.

What happens to menu order?

Some post types use menu_order to control ordering.

If the source has:

menu_order = 4

copying that value can create two objects with the same order value.

That may be harmless if another sorting rule resolves the order, but it can also create unexpected positioning.

Sites that depend heavily on manual ordering should decide whether duplicates:

• inherit the original position;
• move immediately after the original;
• receive a default order;
• are placed at the end.

Sorting in the administration interface is a separate concern from the underlying content order. For that distinction, see WordPress List-Table Sorting, Explained.

Duplicating SEO metadata requires special attention

SEO plugins commonly attach additional metadata to posts.

This may include:

• SEO title;
• meta description;
• focus keyphrase;
• canonical URL;
• robots directives;
• social title;
• social description;
• social image;
• schema configuration.

Some of these values can be useful as an editorial starting point.

Others can become incorrect as soon as the new post has a different purpose.

Review the canonical URL

An explicitly configured canonical URL deserves particular attention.

Suppose the original page declares:

<link
    rel="canonical"
    href="https://example.com/web-design/"
>

If that exact setting is copied to a new independent page, the duplicate may continue telling search engines that the original URL is the preferred version.

That can be intentional when two URLs genuinely represent duplicate or equivalent content.

It is usually incorrect when the copied page is being transformed into a distinct page that should be indexed independently.

Google explains the use of canonical URLs in its documentation on canonicalization and duplicate URLs.

For the WordPress-specific implementation, see WordPress Canonical URLs, Explained.

Rewrite duplicated SEO titles and descriptions

If two pages target different topics, keeping identical search metadata makes little sense.

For example:

Original:
Web Design Services | Example

Duplicate:
Web Design Services | Example

is not an appropriate final configuration if the second page has become a landing page for ecommerce development.

The copied metadata should be reviewed alongside the new content.

Check robots directives

The original post may contain explicit indexing directives.

For example, a source page intentionally excluded from search results should not necessarily transfer that decision to a completely different page created from its structure.

Likewise, an indexable source does not mean an unfinished duplicate should immediately become indexable.

Google documents supported robots meta directives in its robots meta tag documentation.

Check schema settings

Structured data configuration can also be context-specific.

A cloned page may eventually represent another:

• article;
• service;
• product;
• event;
• person;
• FAQ;
• organization-related resource.

Do not assume that schema settings configured for the source still describe the duplicate correctly.

Does duplicating a WordPress page create duplicate content?

Creating a duplicate draft does not automatically create a search-engine problem.

The important question is whether multiple substantially identical URLs eventually become publicly accessible and indexable.

For example:

/web-design/
/web-design-copy/

should not normally remain as two independent published pages containing effectively the same information.

The duplicate should either be:

• rewritten into genuinely distinct content;
• kept unpublished while it is being prepared;
• removed if it is no longer needed;
• handled appropriately through canonicalization or redirects when the situation requires them.

For a broader explanation of this issue, see Duplicate Content in WordPress, Explained.

Duplication is an editorial shortcut, not a content strategy

A cloned page can provide a useful structure.

It should not become an excuse to publish dozens of nearly identical pages with only a few words changed.

If the duplicate is intended to become independent content, review:

• search intent;
• title;
• headings;
• body copy;
• examples;
• images;
• internal links;
• metadata;
• structured data;
• calls to action.

The final page should have a reason to exist independently from the source.

Check internal links after duplicating a page

URLs inside post_content are normally copied with the rest of the content.

If the original contains:

<a href="/services/web-design/">
    Discover Web Design
</a>

the duplicate normally contains exactly the same link.

That may be correct.

But context-specific links can become incorrect after duplication.

Review:

• buttons;
• internal navigation;
• anchor links;
• related-content links;
• form links;
• download links;
• contact links;
• campaign URLs;
• calls to action.

This is particularly important when cloning landing pages for different services, campaigns or locations.

Watch for self-referencing links

A page may contain links pointing to sections or resources associated with itself.

After duplication, some of those links may continue pointing to the original page.

For example, a call to action on the duplicate may still use:

https://example.com/web-design/#contact

when the intended destination is now:

https://example.com/ecommerce-development/#contact

A visual review alone may not reveal this problem because the button label can remain perfectly correct.

Inspect the destinations as well as the visible text.

Duplicating Gutenberg pages and posts

WordPress Block Editor content is primarily represented inside post_content using block markup.

A simplified page might contain:

<!-- wp:heading -->
<h2>Our Services</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Example content.</p>
<!-- /wp:paragraph -->

Copying post_content therefore preserves the block structure in many ordinary cases.

However, not every block is completely self-contained.

Blocks may reference:

• Media Library attachment IDs;
• shared content;
• patterns;
• query settings;
• plugin data;
• dynamic information;
• external resources.

A duplicated Gutenberg page should therefore still be opened and inspected before publication.

The official WordPress Block Editor Handbook documents the block architecture and developer APIs.

Be careful with synchronized content

Some block-based content may intentionally reference reusable or synchronized resources.

Duplicating the page does not necessarily turn every referenced resource into an independent copy.

This is an important conceptual difference.

You may duplicate the page while some components inside that page remain connected to shared content.

Before editing a duplicated page extensively, understand whether a block is:

• local to the page;
• reusable;
• synchronized;
• dynamically generated.

Otherwise, an editor may expect to change only the duplicate while actually modifying a shared resource used elsewhere.

Duplicating pages created with page builders

Page builders can make duplication more complicated because much of the page configuration may exist outside ordinary post_content.

Depending on the builder, a page may depend on:

• layout metadata;
• widget configuration;
• responsive settings;
• global-style references;
• template IDs;
• generated CSS;
• internal caches;
• plugin-specific metadata.

A duplication implementation that copies only post_content may therefore create an incomplete copy.

Copying every page-builder field is not automatically safer

The opposite approach can also create problems.

Blindly cloning every private metadata key may reproduce:

• generated caches;
• temporary information;
• internal references;
• values expected to be unique;
• obsolete builder state.

If a website relies heavily on a page builder, test the duplication workflow specifically with that builder.

The correct solution is to copy reusable page configuration while excluding data that should be regenerated.

Test responsive and generated styles after cloning

A duplicated builder page may look correct on desktop while containing stale generated assets or settings that behave differently at other breakpoints.

Test the duplicate at the same viewport ranges used for the original.

Pay particular attention to:

• responsive visibility;
• generated CSS;
• background images;
• dynamic widgets;
• global components;
• forms;
• animations;
• conditional content.

Can custom post types be duplicated?

Yes. Custom post types use the WordPress post architecture and can generally participate in the same basic duplication process.

A website might contain:

post
page
portfolio
recipe
event
property
testimonial
documentation

The official WordPress custom post type documentation explains how custom post types are registered and integrated with WordPress.

For duplication, however, you also need to understand the data associated with that post type.

A custom content type may depend on:

• custom taxonomies;
• custom fields;
• parent relationships;
• menu order;
• templates;
• external integrations;
• special publication workflows.

See WordPress Post Types vs. Custom Post Types for the underlying distinction.

If the post type participates in SEO, its archive, sitemap behavior, metadata and public URLs may also need consideration. See WordPress Custom Post Types and SEO for that side of the architecture.

Decide which post types can be duplicated

A production cloning feature should not necessarily expose a Duplicate action for every registered post type.

A simple allowlist can be safer:

$allowed_post_types = array(
    'post',
    'page',
    'portfolio',
);

if (
    ! in_array(
        $original->post_type,
        $allowed_post_types,
        true
    )
) {
    return;
}

This gives the developer explicit control over where cloning is available.

It also prevents a generic content tool from unexpectedly appearing beside objects that were never designed to be copied.

Some WordPress content types should not be cloned blindly

A generic duplication function should not automatically be available for every object that happens to use WordPress’s content infrastructure.

Some objects can represent operational or transactional data rather than editorial content.

Depending on the plugins installed on the website, this can include:

• orders;
• bookings;
• subscriptions;
• payments;
• form submissions;
• membership records;
• integration records;
• workflow objects.

These objects may contain values that must remain unique.

Examples include:

• transaction identifiers;
• external API IDs;
• payment references;
• tokens;
• generated hashes;
• integration keys;
• workflow states;
• timestamps.

Duplicating these values can have consequences far beyond creating repeated content.

Editorial content and transactional records should therefore be treated as different categories.

For a dedicated explanation of this problem, see Which WordPress Content Types Should Never Be Cloned.

Add a Duplicate action to the WordPress post list

If duplication is used regularly, placing the action directly in the WordPress content list creates a much faster workflow.

WordPress provides the post_row_actions filter for modifying the actions displayed beneath post titles.

The official post_row_actions documentation describes how these actions can be filtered.

The interface could become:

Example Post

Edit | Quick Edit | Duplicate | Trash | View

For hierarchical post types such as pages, WordPress also provides the page_row_actions filter.

Only show the action to users who can use it

There is little value in displaying a Duplicate action to a user who cannot edit the source or create the resulting content.

The row action can therefore be conditioned on capabilities.

This improves both security and interface clarity.

For sites with multiple editorial roles, see WordPress User Roles and Capabilities, Explained for the underlying authorization model.

Protect duplication actions with a WordPress nonce

A duplication request creates data.

It should therefore be protected against unintended or forged requests.

WordPress nonces provide request-intent verification.

The official WordPress Nonces documentation explains their purpose and limitations.

A duplication URL can be protected with wp_nonce_url():

$duplicate_url = wp_nonce_url(
    admin_url(
        'admin.php?action=project_duplicate_post&post='
        . $post_id
    ),
    'project_duplicate_post_' . $post_id
);

The receiving action should verify that nonce before performing the duplication.

A nonce does not replace a capability check

This distinction is important.

Nonce verification confirms the request context.

It does not determine whether the current user has permission to perform the action.

Check the user’s capabilities separately:

if (
    ! current_user_can(
        'edit_post',
        $post_id
    )
) {
    wp_die(
        'You are not allowed to duplicate this content.'
    );
}

The official current_user_can() documentation explains WordPress capability checks.

A secure implementation should use both mechanisms for their intended purposes:

Nonce
    ↓
Was this request intentionally generated?

Capability
    ↓
Is this user allowed to perform the action?

Passing one check does not make the other unnecessary.

Validate the source post before cloning it

A duplication handler should not assume that every supplied post ID is valid.

Before copying anything, verify:

• the ID exists;
• the object is a valid post;
• the post type is allowed;
• the user can edit it;
• the object is not a revision;
• the object is not an autosave;
• the content type is safe to clone.

This is particularly important when the source ID comes from a request parameter.

Administrative convenience should not become an excuse to skip validation merely because the action originates in the backend.

A safer WordPress duplication workflow

A reliable duplication feature should perform the operation in a deliberate sequence.

A useful model is:

1. Receive the source post ID
2. Sanitize and validate the ID
3. Verify the nonce
4. Verify the user's capability
5. Retrieve the source post
6. Check whether the post type can be cloned
7. Create a new draft
8. Copy approved metadata
9. Copy appropriate taxonomy relationships
10. Preserve the featured image when appropriate
11. Exclude temporary and unique state
12. Confirm that creation succeeded
13. Redirect to the new draft
14. Review before publication

This approach treats duplication as an application-level operation rather than a raw database copy.

Handle errors instead of assuming success

Functions such as wp_insert_post() can return an error when requested appropriately.

A production implementation should handle that situation instead of continuing to copy metadata to an invalid post ID.

For example:

$new_post_id = wp_insert_post(
    $new_post_data,
    true
);

if (
    is_wp_error( $new_post_id )
) {

    wp_die(
        esc_html(
            $new_post_id->get_error_message()
        )
    );
}

Useful error handling makes duplication failures easier to diagnose and prevents subsequent operations from running against an invalid object.

Redirect the editor to the duplicated draft

After successful duplication, sending the user directly to the editor for the new post makes the workflow much clearer.

WordPress provides get_edit_post_link() for retrieving the administration edit URL for a post.

See the official get_edit_post_link() reference.

The resulting workflow becomes:

Click Duplicate
      ↓
Create draft
      ↓
Open new draft
      ↓
Edit
      ↓
Review
      ↓
Publish

This avoids forcing the editor to return to the content list and search for the newly created copy.

Make it obvious that the editor is working on the copy

Immediately redirecting to an identical-looking page can create confusion.

A temporary title suffix such as - Copy helps distinguish the new draft.

An administration notice can also confirm what happened:

Page duplicated successfully.
You are editing the new draft.

Small interface details matter when the source and duplicate initially look almost identical.

What should you review after duplicating a WordPress page or post?

A duplicated page should be considered unfinished even when it appears identical to the source.

The following review should happen before publication.

Review the title

Remove temporary labels such as:

Copy of
Duplicate
- Copy
New

and replace them with the actual title of the new content.

Review the permalink

The final slug should describe the page rather than the duplication operation.

Review the content

Look for references that only apply to the original.

These can include:

• service names;
• product names;
• locations;
• prices;
• dates;
• people;
• campaign names;
• offers;
• calls to action.

Review internal links

Make sure buttons and links still point to destinations appropriate for the new content.

Review the featured image

Decide whether sharing the original Media Library attachment is appropriate.

Review taxonomies

Categories, tags and custom taxonomy terms copied from the original may no longer describe the duplicate accurately.

Review custom fields

Look for values containing:

• dates;
• URLs;
• IDs;
• prices;
• contact information;
• content-specific configuration.

Review SEO settings

Check:

• SEO title;
• meta description;
• canonical URL;
• robots directives;
• social metadata;
• schema settings;
• focus keyphrase.

Review publication status

Make sure the duplicate remains unpublished until it is ready.

Review the frontend

Do not stop at the WordPress editor.

Preview the duplicate and check the actual frontend output.

Look for:

• missing styles;
• incorrect templates;
• broken dynamic blocks;
• wrong breadcrumbs;
• incorrect forms;
• unexpected related content;
• layout problems;
• old calls to action;
• incorrect structured data.

The editor view cannot reveal every problem created by copied metadata or dynamic frontend logic.

What happens to comments when a post is duplicated?

Comments belong to the original post through its post ID.

Creating another post does not mean its existing comments should be transferred.

Consider:

Post #184
├── Comment #1
├── Comment #2
└── Comment #3

Duplicate #527
└── No comments

This is normally the expected result.

The comments describe discussion associated with the original publication, not the new content item.

A generic duplication tool should therefore not treat comments as ordinary reusable post configuration.

What happens to post relationships?

Plugins and custom applications can create relationships between posts.

For example:

Case Study
    ↓
Related Client

Recipe
    ↓
Related Ingredient Collection

Property
    ↓
Related Agent

These relationships may be stored as:

• post metadata;
• taxonomy relationships;
• custom database tables;
• plugin-managed relationship records.

A generic duplication system cannot automatically understand the intended meaning of every relationship.

Some should be preserved.

Some should be cleared.

Some should point to another object in the new context.

This is why complex custom applications need duplication rules designed around their data model rather than a universal “copy everything” command.

Should passwords and visibility settings be copied?

WordPress posts can have different visibility states, including password protection.

Whether these settings should be inherited depends on why the content is being cloned.

A duplicate used as a template may not need the original password.

A duplicate of restricted editorial content may need similar protection while it is prepared.

The important principle is to treat access-related fields as deliberate configuration rather than ordinary body content.

Do not assume that because a property can technically be copied, it should always be copied.

When duplicating WordPress content makes sense

Duplication is particularly effective when independent content items share a legitimate structure.

Examples include:

• service pages;
• location pages;
• team profiles;
• case studies;
• portfolio entries;
• documentation pages;
• landing pages;
• event pages;
• structured blog posts;
• custom post type entries.

An existing item can provide the structure while the duplicate develops into independent content.

This reduces repetitive setup work and helps maintain consistency across similar content types.

Duplication can also reduce configuration mistakes

Rebuilding complex pages manually introduces opportunities to forget small but important settings.

An editor may reproduce the visible layout but forget:

• a taxonomy;
• a template;
• a custom field;
• a featured image;
• a layout option;
• a plugin setting.

A well-designed duplication workflow can preserve an approved starting configuration and reduce this repetitive setup.

When duplication is the wrong solution

Duplication creates independent copies.

That is not always what you need.

Suppose the same call-to-action section appears on fifty pages.

If you duplicate that section fifty times, you now have fifty independent versions.

Changing the original does not automatically update the others.

If content needs to remain synchronized, consider reusable architecture instead:

• synced patterns;
• templates;
• template parts;
• dynamic blocks;
• custom fields;
• shared components;
• custom post types with dynamic rendering.

The key question is:

do you need a new independent copy, or do you need reusable content that should remain connected?

Duplication is appropriate for the first case.

A reusable architecture is usually better for the second.

Do not use duplication as a substitute for content templates

If editors create the same type of page repeatedly, duplicating an old page may eventually become unreliable.

Why?

Because the old page may contain historical decisions that should not become part of every new item.

Over time, the team can accidentally propagate:

• outdated content;
• obsolete links;
• old tracking parameters;
• deprecated blocks;
• legacy custom fields;
• old SEO configuration;
• temporary fixes.

When a structure is intended to become the official starting point for future content, a dedicated template may be cleaner than repeatedly cloning whichever existing page happens to look similar.

Duplication is strongest when you intentionally want to branch from a specific existing item.

Duplicating content on multilingual WordPress sites

Multilingual websites add another layer of relationships.

A page may be associated with translations in other languages.

Duplicating the source page does not automatically mean the new page should inherit those translation relationships.

For example:

English:
Web Design

Italian:
Web Design Italia

German:
Webdesign

If the English page is duplicated to create an entirely new service, retaining the original translation relationships could connect unrelated content.

Multilingual plugins may manage these relationships through metadata, taxonomies or their own tables.

Test duplication carefully when the site uses a multilingual architecture.

Duplicating content in a multisite network

Duplicating a post inside one WordPress site is different from copying content between sites in a WordPress Multisite network.

A post ID is local to the individual site.

Media attachment IDs, taxonomy term IDs and plugin configuration can also differ between sites.

A process that works for:

Site A
Post #184
    ↓
Site A
Post #527

cannot automatically be assumed to work for:

Site A
Post #184
    ↓
Site B
New Post

Cross-site duplication may require mapping:

• media attachments;
• users;
• taxonomy terms;
• templates;
• plugin settings;
• internal links.

That is closer to content migration than ordinary post cloning.

How duplication affects WordPress performance

Duplicating an ordinary page occasionally has negligible performance implications.

But poorly designed bulk cloning can create unnecessary database growth.

Consider a system that duplicates:

• hundreds of posts;
• dozens of metadata rows per post;
• physical media files;
• generated builder data;
• unnecessary caches.

The operation can create substantially more data than expected.

A clean duplication system should copy what the new object needs rather than reproducing every associated artifact indiscriminately.

This is another reason to avoid copying physical media when a shared attachment reference is sufficient.

If database growth is already becoming a concern, WordPress Database Bloat, Explained covers the broader causes of unnecessary database expansion.

Bulk duplication needs additional safeguards

Duplicating one post from a row action is relatively simple.

Duplicating fifty or five hundred items changes the operational problem.

Bulk operations should consider:

• execution time;
• memory usage;
• database writes;
• duplicate titles;
• error handling;
• partial completion;
• background processing;
• auditability.

A bulk cloning operation should not leave the administrator wondering whether 300 items were duplicated, 200 were duplicated or the request failed halfway through.

For large operations, background processing and clear progress reporting may be preferable to a single long-running administration request.

If reducing unnecessary write activity is important on a busy installation, see How to Reduce Database Writes in WordPress.

Using TheOneWP to duplicate WordPress pages and posts

When duplication becomes part of a regular editorial workflow, manually copying content and reconstructing its surrounding configuration creates unnecessary work.

TheOneWP can provide a dedicated content-cloning workflow so existing WordPress content can be used as the starting point for another independent item directly from the administration interface.

The purpose is simple:

take an existing content item and use it as the starting point for a new one without rebuilding the structure manually.

Clone content directly from the WordPress admin

A cloning workflow is particularly useful when editors repeatedly create:

• similarly structured pages;
• service pages;
• landing pages;
• articles based on an editorial structure;
• portfolio items;
• custom content entries.

Instead of opening the original, manually copying its content and reconstructing the surrounding settings, the duplicate can be created directly from the existing item.

The new content remains independent from the original and can then be edited normally.

Combine cloning with structured content

Duplication becomes more useful when the underlying WordPress content model is already organized.

Custom post types can separate different kinds of content, taxonomies can classify them, and custom metadata can provide structured information beyond the main editor.

In that environment, cloning can provide the starting values while the content structure defines what each item is expected to contain.

If you are deciding whether a new content structure should remain a standard post or become its own type, WordPress Post Types vs. Custom Post Types provides the architectural background.

Use the duplicate as a starting point

The presence of a cloning tool does not remove the need for editorial review.

After duplication, the editor should still decide:

• what the new content is called;
• which permalink it should use;
• what content needs to change;
• whether copied taxonomies remain correct;
• whether the featured image remains appropriate;
• which metadata should be updated;
• when the new content is ready to publish.

The benefit is not automatic publication.

The benefit is eliminating repetitive setup while preserving an existing structure.

WordPress page and post duplication checklist

• Confirm that you need an independent duplicate rather than reusable synchronized content.
• Create a new WordPress object with its own post ID.
• Keep duplicates of published content in draft status initially.
• Copy the main content when it should be reused.
• Copy the excerpt only when it remains relevant.
• Review the author assigned to the duplicate.
• Preserve the correct post type.
• Review parent relationships for hierarchical content.
• Review menu order where it affects the content type.
• Do not blindly preserve the original publication date.
• Copy only metadata that belongs to the new object.
• Exclude editing locks and temporary metadata.
• Be careful with plugin-generated metadata.
• Identify metadata values expected to remain unique.
• Preserve the featured-image reference when appropriate.
• Avoid creating unnecessary copies of physical media files.
• Review categories and tags.
• Review custom taxonomy terms.
• Give the duplicate a meaningful final slug.
• Do not leave temporary -copy URLs as the final permalink without reviewing them.
• Review duplicated SEO titles.
• Rewrite duplicated meta descriptions when necessary.
• Check explicit canonical URLs.
• Review robots directives.
• Review social metadata.
• Review schema configuration.
• Inspect internal links and buttons.
• Check self-referencing URLs.
• Check Gutenberg blocks that depend on external data.
• Identify synchronized blocks before editing them.
• Test page-builder content after duplication.
• Test responsive layouts on builder-generated pages.
• Do not blindly clone transactional content types.
• Do not copy unique external identifiers without understanding their purpose.
• Review multilingual relationships where applicable.
• Do not assume ordinary cloning logic works across Multisite sites.
• Protect custom duplication actions with WordPress nonces.
• Check user capabilities separately from nonce verification.
• Validate the source post ID and post type.
• Handle WP_Error when creating the duplicate.
• Redirect editors to the new draft after duplication.
• Make it visually clear that the editor is working on the copy.
• Preview the frontend before publication.
• Do not duplicate comments unless there is a specific reason to do so.
• Review custom post relationships.
• Use additional safeguards for bulk duplication.
• Consider a dedicated template when the same structure is repeatedly reused.
• Review the complete duplicate before publication.

Related guides

• WordPress Featured Image Duplication, Explained
• Which WordPress Content Types Should Never Be Cloned
• Duplicate Content in WordPress, Explained
• WordPress Canonical URLs, Explained
• What Are WordPress Post Revisions, Really?

Final recommendation

Duplicating a WordPress page or post is most useful when you need a new independent content item that begins with an existing structure.

For a simple page, manually copying the editor content may be enough. On a more complex website, however, the visible editor represents only part of the content object. Featured images, custom fields, taxonomies, templates, SEO settings, hierarchical relationships and plugin-specific metadata can all influence how the page behaves.

A reliable duplication process should therefore create a new WordPress object, preserve the information that genuinely belongs to the copy and deliberately exclude temporary, generated or unique state.

Keep the duplicate as a draft until it has been reviewed. Update its title and permalink, inspect the content and internal links, verify taxonomies and custom fields, and check whether the featured image is still appropriate.

SEO configuration deserves particular attention. Titles, descriptions, canonical URLs, robots directives, schema settings and social metadata that were correct for the original are not automatically correct for a new independent page.

The same principle applies to more complex WordPress data. A taxonomy relationship may still be useful, while a transaction identifier should remain unique. A featured-image attachment can normally be shared, while a temporary editing lock should not be transferred. A Gutenberg block may be copied directly, while synchronized content can remain connected to a shared resource.

If you build duplication functionality yourself, use WordPress APIs such as get_post(), wp_insert_post(), the metadata API and taxonomy functions instead of copying database rows directly. Protect administration actions with nonces, verify user capabilities, validate the source object and restrict cloning for content types that contain transactional or unique state.

For recurring editorial workflows, a dedicated cloning feature can remove the repetitive work of manually rebuilding copies and provide editors with a faster starting point for new content.

Duplication is particularly effective when it sits inside a well-structured content system. Custom post types, taxonomies and meta fields can define the structure, while cloning provides a convenient way to begin another independent entry from an existing configuration.

But duplication should not replace templates or synchronized content when the real requirement is centralized reuse. If fifty pages need to display the same component and every instance should change together, creating fifty independent copies is usually the wrong architecture.

The important principle is simple:

a duplicate should be the beginning of a new content item, not an unquestioned second publication of the original.