Which WordPress Content Types Should Never be Cloned

Cloning content in WordPress can save a significant amount of time. A carefully designed landing page, product layout, event template or reusable custom post can often be duplicated and adapted much faster than rebuilding it from scratch.

But the fact that something appears in the WordPress admin does not mean it is safe to clone.

WordPress uses post types as a flexible data model. Posts and pages are obvious examples, but Core also uses post-like objects for attachments, revisions, navigation, templates and other internal structures. Plugins extend that model further with products, events, memberships, subscriptions and application-specific records.

Some of those objects represent reusable content. Others represent transactions, historical records, relationships or system state.

Cloning the first category can be useful. Cloning the second can create duplicate identifiers, incorrect relationships, broken workflows, misleading records or application data that looks valid in the admin while being internally inconsistent.

This guide explains which WordPress content types should never be cloned blindly, which ones require special handling, and how to decide whether a custom post type is actually safe to duplicate.

Cloning a WordPress post means more than copying its text

A WordPress post is not just its title and content.

The WordPress post type API allows post types to support features including titles, editors, authors, thumbnails, excerpts, custom fields, comments, revisions and page attributes.

A typical content object can therefore involve:

• the main post record;
• post metadata;
• taxonomy relationships;
• featured images;
• parent-child relationships;
• menu order;
• custom fields;
• plugin-generated metadata;
• SEO settings;
• workflow status;
• external identifiers.

This is why “duplicate this post” is not one universal database operation.

A cloning system has to decide what should be copied, what should be regenerated and what should deliberately be excluded.

The broader distinction between WordPress content structures is explained in WordPress Post Types vs. Custom Post Types.

A new post ID does not automatically make the clone independent

A correctly created clone should receive its own WordPress post ID. But metadata copied from the source may still contain references to other objects.

For example, custom metadata could contain:

• an external CRM record ID;
• a payment transaction ID;
• a subscription identifier;
• a booking reference;
• a form submission ID;
• a synchronization token;
• another post ID;
• a customer ID;
• a serialized configuration containing several relationships.

Copying those values unchanged can make two different WordPress objects appear to represent the same external or internal entity.

This is the first rule of safe cloning: a field being stored as post meta does not mean that field is reusable content.

Normal posts and pages are usually the safest objects to clone

Standard editorial posts and pages are the most obvious candidates for duplication.

A clone can be useful when creating:

• similar landing pages;
• location pages with a shared structure;
• campaign pages;
• recurring editorial formats;
• documentation pages;
• standardized service pages;
• draft variations of an existing layout.

Even here, however, the clone should normally be created as a new draft rather than as another immediately published page.

Duplicating a published article without changing its purpose, URL and copy can create substantial content overlap. See Duplicate Content in WordPress, Explained for the SEO side of that problem.

Review metadata before publishing the clone

A cloned page may inherit information that should be unique.

Depending on the plugins installed, this could include:

• SEO titles and descriptions;
• canonical URL settings;
• redirect configuration;
• schema properties;
• social sharing metadata;
• page-builder settings;
• custom tracking identifiers.

Copying the visual layout can be perfectly reasonable while copying every piece of metadata is not.

This distinction becomes particularly important on sites where custom fields carry business logic rather than merely presentation data.

Never treat revisions, autosaves and internal WordPress records as ordinary cloneable content

WordPress Core registers several built-in post types that exist primarily for internal behavior rather than normal editorial publishing.

The Core post type registry includes types such as revision, nav_menu_item, custom_css, customize_changeset, oembed_cache, user_request, wp_global_styles, wp_navigation, wp_template and wp_template_part.

These objects should not be assumed to behave like ordinary posts merely because WordPress represents them through its post infrastructure.

Revisions should not be cloned as independent content

WordPress revisions exist to preserve previous states of another post.

Core registers the revision post type as non-public and intended for internal use. The Core post type registration reflects that special role.

A revision belongs to the history of another content object. It is not a reusable content template.

If you want to create a new article from an older version, restore or inspect the revision first and then create a legitimate new post from the desired content. Do not treat the revision record itself as the new content object.

For more background, see What Are WordPress Post Revisions, Really?.

Autosaves are also state, not reusable content

Autosaves protect editing work. They exist in relation to an editable post and its revision history.

They should not become independent published objects through a generic cloning operation.

A cloning feature should work with the canonical content object, not indiscriminately duplicate every supporting record associated with its editing history.

Attachments should not be cloned like ordinary posts

WordPress represents media-library items using the attachment post type.

That can be misleading because an attachment record and the underlying media file are related but not identical.

An attachment can contain:

• a title;
• a caption;
• a description;
• alternative text stored in metadata;
• file metadata;
• generated image-size information;
• references to the physical uploaded file.

Blindly cloning the attachment post does not necessarily create a genuinely independent copy of the physical asset.

Decide whether you need another record or another file

Suppose an attachment represents:

/wp-content/uploads/2026/08/product-photo.jpg

Creating another database record that points to the same file is fundamentally different from copying the file and registering the new asset properly.

If your goal is to reuse the same image, you generally do not need to duplicate the attachment at all. WordPress content can reference the existing media item.

If your goal is to create a genuinely separate media asset, use a workflow that understands WordPress attachments and the filesystem rather than cloning the database row.

For larger libraries, see Organizing a Large WordPress Media Library and Keeping a WordPress Media Library Organized at Scale.

WooCommerce orders should never be cloned as ordinary WordPress posts

Orders are one of the clearest examples of application data that should not be handled by a generic post-cloning system.

An order represents a transaction and can be connected to:

• a customer;
• billing and shipping addresses;
• products and variations;
• line items;
• tax calculations;
• shipping methods;
• payment state;
• transaction identifiers;
• refunds;
• stock changes;
• download permissions;
• emails;
• webhooks;
• analytics records.

Creating a second post that superficially resembles an order does not safely reproduce that transactional graph.

Modern WooCommerce orders may not be WordPress posts at all

This distinction has become even more important with WooCommerce High-Performance Order Storage.

WooCommerce documents High-Performance Order Storage as a dedicated storage architecture for orders. On stores using HPOS as their authoritative storage, order data is maintained in WooCommerce-specific tables rather than relying on the traditional wp_posts and wp_postmeta architecture.

The main HPOS tables include:

• _wc_orders;
• _wc_order_addresses;
• _wc_order_operational_data;
• _wc_orders_meta.

WooCommerce provides its own order APIs and recommends retrieving orders through interfaces such as wc_get_orders() and WC_Order_Query.

A generic WordPress clone operation that assumes an order is simply a post with metadata is therefore architecturally wrong on modern HPOS stores.

For the broader WooCommerce structure, see WooCommerce Account and Checkout Pages, Explained.

“Reorder” is not the same as cloning an order

An ecommerce system may intentionally provide functionality that lets a customer purchase the same products again.

That workflow creates a new transaction from selected information in the previous order.

It should not simply duplicate the previous transaction record, payment identifiers and historical state.

The difference is important: reuse business inputs where appropriate, but create new transactional state through the application’s supported APIs.

Subscriptions, bookings, memberships and similar records need application-specific handling

Many WordPress plugins use custom post types or custom tables to represent application objects.

Examples include:

• subscriptions;
• bookings;
• appointments;
• memberships;
• invoices;
• support tickets;
• course enrollments;
• form submissions;
• event registrations;
• license records.

These may look like content in the admin interface, but they frequently represent stateful records.

A subscription, for example, may be connected to payment schedules, renewal orders, customer information and external payment-provider identifiers.

WooCommerce Subscriptions also integrates with HPOS. WooCommerce’s developer documentation explains that subscription data can use the dedicated order storage architecture when HPOS is enabled.

That alone demonstrates why checking only the WordPress post type is insufficient.

Look for external side effects

Before cloning an unfamiliar custom post type, ask whether creating a new record normally triggers anything outside the record itself.

For example:

• Does it reserve inventory?
• Does it schedule a recurring payment?
• Does it create an appointment?
• Does it send an email?
• Does it generate a license?
• Does it provision an account?
• Does it create a remote CRM record?
• Does it communicate with a payment gateway?

If the answer to any of these questions is yes, generic cloning is dangerous.

The plugin’s own API or duplication workflow should determine how a new object is created.

Products and other structured content require selective cloning

WooCommerce products are different from orders.

A product is much closer to reusable content, so duplicating one can be a legitimate workflow. But even here, not every field should necessarily survive unchanged.

A product can contain:

• SKU;
• price;
• stock configuration;
• downloadable files;
• attributes;
• variations;
• shipping properties;
• tax settings;
• gallery images;
• plugin-specific metadata.

A unique SKU, for example, should not accidentally identify two independent products.

The lesson is that some content types are conditionally cloneable. Their editorial structure can be copied, but unique or operational metadata must be regenerated, reset or excluded.

Custom post types belong in the same conditional category

The label “custom post type” tells you almost nothing about whether an object is safe to duplicate.

One custom post type might represent a portfolio project:

portfolio

Another might represent a booking:

booking

Both may ultimately be registered through WordPress’s post type system, but their semantics are completely different.

That is why WordPress Post Types vs. Custom Post Types is useful background when designing cloning rules.

Do not decide whether something is cloneable based on where it is stored. Decide based on what the object represents.

Be careful with hierarchical content, relationships and unique metadata

Even ordinary editorial content can become risky when its meaning depends heavily on relationships.

Parent and child pages

WordPress pages can be hierarchical.

A cloned child page may retain a relationship to the original parent unless the cloning workflow deliberately changes it.

That may be correct, or it may create a page in the wrong section of the site.

The new object’s hierarchy should therefore be reviewed before publication.

Taxonomy relationships

Categories and tags are often safe to copy because they describe the new content in the same way as the source.

But custom taxonomies can carry application-specific meaning.

A taxonomy term representing “Photography” is ordinary classification. A taxonomy used by a plugin as part of a workflow may not be.

See WordPress Taxonomies Beyond Posts and Pages for a broader look at how taxonomies can be used beyond basic categories and tags.

Unique identifiers in post meta

Metadata deserves particular attention because WordPress and plugins can store almost anything in it.

A clone should generally reconsider fields such as:

• UUIDs;
• SKUs;
• transaction IDs;
• remote API IDs;
• license keys;
• tracking IDs;
• payment references;
• import identifiers;
• synchronization timestamps;
• workflow locks.

If a field exists specifically to make an object unique, copying it unchanged defeats its purpose.

Templates and reusable design objects need a different mental model

Modern WordPress also stores several design-related objects as post types.

These include block templates, template parts, navigation structures and global style records.

They may be intentionally reusable, but generic cloning is still not automatically the correct workflow.

A template can participate in theme resolution. A navigation object can be referenced by blocks. Global style records represent configuration associated with the site’s visual system.

Creating arbitrary duplicates can therefore produce unused, ambiguous or conflicting configuration rather than useful editorial content.

The relationship between modern WordPress editing structures is covered in WordPress Full Site Editing and Block Widgets, Explained.

Reusable does not always mean cloneable

This distinction is worth making explicitly.

A template is reusable because multiple pages can use it.

A reusable pattern is reusable because its structure is designed to be inserted repeatedly.

That does not mean the underlying database object should be duplicated every time somebody wants to reuse the design.

Sometimes the correct action is to reference or insert the existing reusable object rather than clone its storage record.

How to decide whether a WordPress content type is safe to clone

Before enabling cloning for a post type, inspect the object from the perspective of its meaning rather than its database implementation.

A useful decision process is:

Inspect the post type registration

Developers can use get_post_type_object() to inspect a registered post type.

For example:

<?php
$post_type = get_post_type_object( 'my_custom_type' );

if ( $post_type ) {
    var_dump( $post_type );
}
?>

This can reveal whether the type is public, hierarchical, exposed through REST and which capabilities it uses.

You can also inspect supported features with get_all_post_type_supports().

But these technical properties are only the beginning. They cannot tell you what a plugin’s metadata means or which external systems depend on the object.

Read the plugin’s API before cloning its objects

If a custom post type belongs to WooCommerce or another application plugin, use its documented API whenever one exists.

This is particularly important for WooCommerce orders because HPOS means direct assumptions about wp_posts and wp_postmeta are no longer portable across store configurations.

The same architectural principle applies to other plugins that abstract their persistence layer.

Designing a safe WordPress cloning feature

A well-designed cloning tool should not simply expose “Clone” for every post type WordPress knows about.

It should maintain explicit rules about what can and cannot be duplicated.

A conservative architecture can start by allowing ordinary editorial types such as:

• post;
• page;
• known editorial custom post types.

It can then exclude Core internal types and application records unless compatibility has been deliberately implemented.

Use an allowlist when possible

An allowlist is often safer than trying to maintain an endless blacklist.

Instead of:

Clone everything except these dangerous types.

the system can follow:

Clone only types that have been explicitly approved.

This matters because installing a new plugin tomorrow can register a new post type that your cloning tool has never seen before.

A blacklist cannot know that the new type represents a payment, booking or license record. An allowlist leaves it disabled until its behavior has been reviewed.

Create clones as drafts

For editorial content, the safest default status is normally draft.

This gives an editor an opportunity to review:

• the title;
• slug;
• content;
• taxonomy terms;
• featured image;
• custom fields;
• SEO metadata;
• parent relationships;
• unique identifiers.

before the duplicate becomes public.

Define metadata exclusions

A robust cloning system should be able to exclude metadata that should never survive duplication.

The exact list is site-specific because plugins invent their own meta keys and storage models.

This is another reason a generic “copy every row in wp_postmeta” implementation is too simplistic for a mature WordPress site.

How TheOneWP approaches content cloning

TheOneWP includes a dedicated cloning capability for WordPress content rather than treating database duplication as a universal operation.

The practical principle should remain conservative: cloning is appropriate for content intended to serve as the starting point for another piece of content.

It is not a substitute for an application’s own transaction, booking, subscription or workflow APIs.

When configuring cloning behavior, think in terms of approved editorial post types rather than assuming every registered post type deserves a Clone action.

This is especially important on installations where WordPress has evolved into more than a publishing system and now hosts ecommerce, memberships, learning systems or other application data.

The more business logic a post type carries, the less appropriate blind duplication becomes.

Related guides

• WordPress Post Types vs. Custom Post Types
• Duplicate Content in WordPress, Explained
• What Are WordPress Post Revisions, Really?
• WordPress Taxonomies Beyond Posts and Pages
• WooCommerce Account and Checkout Pages, Explained
• WordPress Full Site Editing and Block Widgets, Explained

Final recommendation

The safest rule for WordPress cloning is simple: clone reusable content, not application state.

Ordinary posts, pages and genuinely editorial custom post types are usually reasonable candidates. Even then, the clone should normally become a draft and unique metadata should be reviewed before publication.

Revisions, autosaves and internal WordPress records should not be treated as ordinary content. Attachments require media-aware handling rather than simple database duplication. Templates, navigation objects and global style records should be managed according to the systems that consume them.

Transactional records require even stricter boundaries. WooCommerce orders, subscriptions, bookings, memberships, payments, form submissions and similar objects may contain relationships and side effects that a generic cloning operation cannot reproduce safely.

Modern WooCommerce HPOS makes this especially clear: an order may not even be stored as a traditional WordPress post. The supported WooCommerce data layer, not assumptions about wp_posts, defines how that object should be created and managed.

For custom post types, never decide based only on the post type label. Determine what the object represents, which metadata must remain unique, which relationships it owns and whether creating it normally triggers application logic.

If you are building a cloning system, prefer an explicit allowlist of approved editorial post types. Unknown types should remain excluded until their data model has been reviewed.

That approach is less convenient than adding a Clone button to everything in the admin, but it prevents a useful editorial shortcut from quietly becoming a database-corruption feature.