Multisite Content Copier - WordPress Plugin

A Setup Guide to Multisite Content Copier for WordPress Multisite

Multisite Content Copier is not meant for the usual task of duplicating a single page within one site. It is built for a narrower use case: moving posts, pages, users, media, and some settings from one WordPress Multisite site to other sites in the same network. In this guide, we will walk through how to prepare the network, where to find the settings after installation, which modes make sense for different scenarios, and how to verify that the copy did not create hidden issues.

The plugin belongs to the WPMU DEV product line for WordPress Multisite and is especially useful when a network relies on the same starter pages, recurring news items, standard content, or template-based sites. But there is an important caveat: this is a legacy tool, so before using it on a live network, you should test compatibility on a copy or a staging subsite instead of running a blind bulk copy.

You will not find instructions here on purchasing, license activation, or workarounds for getting the paid version. The focus is strictly on using a plugin you already have in a practical way: installation, configuration, a real-world workflow, troubleshooting, limitations, similar alternatives, and safe result validation.

When content copying in Multisite actually saves time

The main use case for Multisite Content Copier is centrally preparing content for multiple subsites. In regular WordPress, you can duplicate a page within a single site, but in Multisite every site lives in its own context: its own posts, its own users, its own media, its own theme settings, and its own plugins unless they are network-activated. Because of that, manual copying quickly turns into a chain of small errors.

The plugin is useful when one source site serves as the canonical version or editorial base, and the content then needs to be pushed to selected sites in the network. According to the official description in the WPMU DEV repository, it supports copying pages, posts, custom post types, users, images, comments, parent pages, publication dates, and even plugin activation when those plugins are available across the network. That does not mean it clones an entire site. It works with selected entities and specific copy modes.

The most common false expectation is to treat this tool like a migrator or a sync engine. If you need to keep the same content continuously updated across dozens of sites, a one-time copy is not enough. Once the original page changes, you will need to run the copy again, choose an update strategy, or look at alternatives that provide dedicated broadcasting or synchronization logic.

Good use cases

• Roll out standard pages such as About, Contacts, Policies, or Documents across multiple sites in the network.
• Deliver a starter set of posts or custom post types to new subsites.
• Copy users and roles to sites where the editorial team needs similar permissions.
• Move attached images together with the content so editors do not have to rebuild the media manually.
• Prepare baseline content for sites created from blog templates or groups of sites.

When another approach is better

If you want to clone an entire site, including its full settings structure, theme, widgets, menus, third-party plugin tables, and all database content, Multisite Content Copier is too narrow a tool. In that case, Multisite site-cloning plugins are a better fit. If your goal is to distribute a post from a main site and then manage the relationship between the copies, you should look at content broadcasting or post distribution tools instead.

Before running anything in bulk, define the task in one sentence: "I need to copy specific posts and related data" or "I need to clone the whole site." In the second case, this plugin should not be your first choice.

What to check before installing it on a production network

WordPress Multisite is sensitive to roles, network activation, domains, caching, and plugins that store data in their own tables. That makes preparation more important here than on a standard standalone site. The purpose of the review is to understand exactly what will be copied, who is allowed to run the operation, and where you can safely review the result before using it at scale.

Network admin permissions and a test path

Installation and network-level actions should be handled by a user with network administrator permissions. A regular admin on an individual subsite may not have access to the required sections. Before your first operation, create or choose two safe subsites: a source site and a test destination site. Do not start by copying to every site in the network.

For testing, one page, one post, one image, and one low-risk user are enough. That small set will show how the plugin handles the title, content, publication status, attachments, author, parent page, and related metadata in your specific environment.

Backups and indexability

Before running a bulk copy, create a backup of the database and uploaded files. The plugin can create new content across multiple sites at once, and cleaning it up manually on a large network will be tedious. If the network is open to search engines, check separately whether you are about to create dozens of duplicates of the same page without an SEO plan in place.

This is especially important for template pages: an About page may only be temporary placeholder text, but search engines will still see it as duplicate content if those pages are publicly accessible. In cases like that, it is better to copy the content as drafts first, adjust the local differences, and publish only afterward.

Compatibility with editors and page builders

Official WPMU DEV support notes that the plugin relies on standard WordPress mechanisms for posts and metadata. That is good for the default editor, regular pages, and custom post types, but it may not be enough for complex builders. In discussions around Elementor and WPBakery, the cautious position is consistent: if the builder stores its structure in metadata, the transfer may work, but that does not guarantee full compatibility with all internal relationships, widgets, shortcodes, and global templates.

Test one piece of content built with your editor before adding it to a bulk workflow. During testing, look beyond the text itself and review styles, images, internal links, dynamic blocks, forms, shortcodes, and third-party plugin data.

Installation and the first check after activation

The installation process is the same as for any standard WordPress plugin, but in Multisite the context matters: the plugin needs to be available to the network, and the management interface may appear in the network admin panel or in an individual site menu depending on the version and enabled modules. After uploading the ZIP file, open the network admin panel, go to the plugins section, and activate Multisite Content Copier so it can work across network sites.

Do not jump straight into bulk copying after activation. First, locate the copy management screen and make sure the plugin can see the list of sites. If the list is empty, verify that you are in the network admin panel rather than inside an individual subsite, and that your current role has sufficient permissions.

A quick one-page test

The first validation is easiest to run on a simple piece of content. On the source site, create a page with a short text, one image, and a clear title, such as "Content Copy Test." Then select a single destination site and run the copy with the minimum set of options.

1. Open the source site and confirm that the test page has been saved.
2. In the plugin interface, select the source site, the content type, and the specific page.
3. Select one destination site, not the entire network.
4. Enable image copying if you want to test attachment transfer.
5. Run the copy and wait for the operation to finish.
6. Open the destination site and review the page both in the admin area and on the front end.

The right first result is one where you clearly understand what the plugin created: a new page, a page with the same status, a draft, or a post with transferred attachments. If that is not clear, do not run the copy across the whole network.

What to review after the first run

Check the title, permalink, publication status, author, parent page, images, gallery, comments, custom fields, and the destination site's menus. If the source page was a child page, make sure the parent structure was transferred as expected or that you are prepared to rebuild it manually. If the content relies on shortcodes, confirm that the corresponding plugin is installed on the destination site.

Settings map: where to copy from, where to send it, and what to transfer

The Multisite Content Copier setup can be reduced to three questions: source, destination, and the set of data being transferred. The more precisely you answer those questions before you start, the less cleanup you will have to do later. In large networks especially, do not treat the "all sites" mode like a routine button. Choose recipients intentionally.

Content source

The source is the site in the network where the content already exists. In some cases, this is the main network site. In others, it is a dedicated template subsite where editors prepare canonical pages. A good practice is to keep the source clean: do not mix drafts, temporary blocks, outdated images, or content that should not be transferred elsewhere.

If the source site uses plugins that are not active on the destination sites, review the content for dependencies. For example, a page may look fine on the source because a gallery or form is working there, but after copying to another site the shortcode may render as plain text or the block may end up empty.

Destination sites, groups, and template blogs

The plugin supports different destination modes: one site, all sites, groups of sites, and integration with WPMU DEV New Blog Templates. According to the official description, New Blog Templates integration works for template blogs created after Multisite Content Copier is installed. That is an important detail: if you already had older templates before installation, do not assume they will automatically fit into the new workflow without testing.

In a network with dozens of subsites, it is much easier if you divide sites by purpose in advance: regional sites, branch sites, education program sites, or departmental showcase sites. Then a standard page set can be copied to a specific group instead of being pushed across the entire network. That reduces the chance of sending internal instructions to a public site or marketing content to a service subsite.

Content types and related data

In the settings, it helps to separate the content itself from related entities. A page without images may be enough for a draft, but a ready-to-publish item usually also needs its attachments. A custom post type may copy over as content, but its public rendering depends on whether that post type is registered on the destination site. A user may be copied successfully, but their actual permissions still depend on the roles and capabilities available on the new site.

Once the setup is defined this way, the workflow becomes clear: the source is clean, destinations are limited, transferred entities are selected based on the task, and validation is planned in advance. That is the foundation of using this plugin safely.

Working with media, custom post types, and page builders

In practice, related data creates the most questions. Plain text and a title usually copy more predictably than an image, a builder block, a product post type, a custom field, or a gallery. That is why post-installation setup should cover not only what gets copied, but also how that content will function on the destination site.

Media and galleries

The official plugin description mentions image copying, and WPMU DEV support adds an important note about galleries: if the content uses a gallery shortcode with specific attachment IDs, you may need to update it manually after copying. The reason is simple: attachment IDs do not have to match across different network sites. The file itself may transfer correctly, but the link or shortcode still needs validation.

After copying media, open the destination page both in edit mode and on the front end. If the image appears only because the link still points to the source site, that is not a full transfer. Ideally, the attachment should exist in the destination site's media library, and the file path should belong to that site.

Custom post types

The plugin claims support for custom post types. But the post itself is only part of the picture. If the post type is created by a third-party plugin, such as a directory, form, event, or product system, the destination site must have the same plugin or code that registers that post type. Otherwise, the copied content may be invisible in the admin menu or render incorrectly.

A proper custom post type check should include three steps: the post type is visible in the destination site's admin area, the entry opens in the editor, and the public page uses the correct template. If any of those checks fail, the problem may not be the copy itself but a missing plugin or theme dependency.

Page builders and blocks

Be careful with Elementor, WPBakery, and similar builders. Support for standard posts and metadata is not the same as a guarantee that every widget, global template, dynamic source, or stylesheet will transfer perfectly. If the builder stores data in meta fields, the basic transfer may work. If it uses separate tables, global libraries, or internal relationships, the outcome depends on the specific builder and its active modules.

For those pages, run a separate test: copy one complex page, clear the destination site's cache, open it in the builder editor, save it without changes, and check the front end. If styles or blocks disappear after saving, do not run a bulk copy of that content until you understand the dependency.

Practical example: rolling out a starter section to branch sites

Imagine a WordPress network for an organization with several branches. Each subsite needs the same starter pages: About the Branch, Documents, Contacts, and FAQ. Some of the text is shared, but addresses, phone numbers, and local documents need to be different. The role of Multisite Content Copier here is to create the foundation, not to replace editors.

Goal and preparation

The goal is to move four pages from the canonical site to a group of branch subsites, preserve the hierarchy and images, but avoid publishing those local pages before review. Before starting, prepare the source site: remove temporary wording, review titles, replace placeholder images, and make sure links do not point to restricted pages.

On the destination side, review the theme, active plugins, permalink structure, and editor permissions. If editors will refine the pages themselves, make sure they have been added to the relevant subsites with the right roles.

Copy steps

1. On the source site, create a parent page called "Visitor Information" and child pages for documents, contacts, and FAQs.
2. Add one test image to each page so you can verify attachment transfer.
3. In the Multisite Content Copier interface, select the source site and the "pages" content type.
4. Select the required pages and enable parent relationship transfer if that option is available in your version.
5. Select the branch site group or several specific destination sites.
6. Enable image copying, and leave comments disabled if they are not needed for starter pages.
7. Run the copy to one test branch first, review the result, and then repeat it for the remaining sites.

Reviewing the result

Open the destination site and look at the page list. You should see the same hierarchy you prepared on the source. Then check the public URLs, images, internal links, and editor permissions. If the pages are published immediately but the local data is not ready yet, switch them back to drafts or restrict indexing until editorial review is complete.

An important detail in this example: if every page includes a branch address, do not copy it as if it were final content. Use copying as a fast way to create the structure, not as a substitute for local editing.

SEO, duplicates, and canonical links after bulk copying

Copying identical pages across different sites in a network can be a perfectly valid workflow, but from a search perspective it requires caution. If all copies are open to indexing and contain the same text, search engines may treat them as duplicates. That is not always critical for internal or utility pages, but for commercial, reference, and regional content, it is better to decide in advance where the original lives, where the localized version belongs, and where a temporary draft makes more sense.

WPMU DEV support has discussed a scenario where you may want to add a canonical link to the copied content pointing back to the source. In one public response, they showed an example using the mcc_copy_post hook. That approach can be useful if you intentionally create copies but still want to signal the primary source to search engines. However, that is a technical customization, not a universal setting for every site.

A safe no-code option

The simplest path is to copy template content as drafts, adapt the text for the destination site, and publish only after a local review. That lowers the risk of duplicates while preserving the efficiency of bulk copying. For regional sites, add local addresses, contacts, service terms, and internal links.

A careful customization through an mu-plugin

If your network has a technical specialist and a confirmed need to add a canonical link to copied content, use a dedicated mu-plugin instead of modifying WordPress core, the theme, or Multisite Content Copier itself. The example below shows the idea: when content is copied, the source post URL is stored in post meta, and a canonical tag is then output on the front end. Before using it, verify that the hook is available in your version of the plugin.

<?php
/*
Plugin Name: MCC Canonical Source Helper
Description: Adds a source canonical URL for copied posts when Multisite Content Copier exposes mcc_copy_post.
*/

add_action('mcc_copy_post', function ($source_post_id, $copied_post_id, $source_blog_id) {
    if (!$source_post_id || !$copied_post_id || !$source_blog_id) {
        return;
    }

    switch_to_blog((int) $source_blog_id);
    $source_url = get_permalink((int) $source_post_id);
    restore_current_blog();

    if ($source_url) {
        update_post_meta((int) $copied_post_id, '_mcc_source_canonical_url', esc_url_raw($source_url));
    }
}, 10, 3);

add_action('wp_head', function () {
    if (!is_singular()) {
        return;
    }

    $source_url = get_post_meta(get_the_ID(), '_mcc_source_canonical_url', true);
    if ($source_url) {
        echo '<link rel="canonical" href="' . esc_url($source_url) . "\" />\n";
    }
});

Place that file in the wp-content/mu-plugins/ directory only after testing it on a copy of the network. The validation is simple: copy one page, open the source code of the destination page, and look for the canonical tag. Rolling it back is simple too: remove the mu-plugin and clear the added post meta from the test records. If you already use an SEO plugin, check first that it will not output a second canonical tag.

Post-copy review: what should match and what should be changed

After a successful run, do not stop at the confirmation message in the admin panel. A bulk operation is only complete after validation on the destination site. Ideally, you should have a short checklist that an editor or administrator can run through for each group of copied items.

Admin area review

• The content appears under the correct post type and has not gone missing because of an unavailable custom post type.
• The publication status matches the plan: published, draft, or pending review.
• The author and permission setup do not give users more access than intended.
• Parent pages and menu order do not break the site's structure.
• Attachments are visible in the destination site's media library rather than being pulled only from the source site.

Front-end review

Open the page as a normal visitor, ideally in a window where you are not logged in. Check the title, text, images, buttons, forms, galleries, shortcodes, breadcrumbs, and internal links. Then clear the cache if the network uses a caching plugin or server-side caching. Sometimes a copied page looks wrong not because of the copy itself, but because of stale cached CSS files or delayed style generation from a page builder.

The final quality check is to open several destination sites and make sure the copies have not become completely identical in places where local differences are supposed to exist. For branch sites, regional pages, and educational programs, that matters more than the transfer itself.

Common issues and troubleshooting

Copying errors in Multisite rarely look like one obvious failure. More often, some data transfers and some does not: the page exists but the image does not; the post is there but the block does not work; the user was added but cannot see the needed section; the gallery opens but loads files from the source site. That is why troubleshooting works best when you follow the symptoms.

The copy did not appear on the destination site

First, verify that you selected the correct destination site and the correct content type. In Multisite, it is easy to confuse sites with similar names or domains. Then confirm that the operation was run by a user with network administrator permissions. If the content belongs to a custom post type, check whether that post type is registered on the destination site.

What to fix

Repeat the copy to a single test site with unnecessary options turned off. If a simple page transfers correctly but the custom post type does not, the problem is likely tied to another plugin dependency. Do not copy to the entire site group until that post type is restored on the destination side.

Images do not display or still point to the source site

The reason is usually attachment transfer or hardcoded links inside the content. Check the destination site's media library and inspect the page source. If the file path points to the source domain, the content is still visually dependent on the source.

What to fix

Repeat the copy with the image transfer option enabled, if it is available, or replace the links manually on the destination site. For galleries that use a list of attachment IDs, inspect the shortcode and rebuild the gallery in the editor, because attachment IDs may differ after copying.

The builder page looks different

If the page was built with Elementor, WPBakery, or another builder, check that the builder is active on the destination site, that the required add-ons are installed, and that the metadata was preserved. In some cases, you need to open the page in the builder editor and save it again so the styles can be regenerated.

When to roll back

If blocks disappear or errors appear after saving, do not continue bulk copying pages of that type. Restore the test site from backup or remove the test copies and review builder compatibility separately.

Users were copied with excessive permissions

Copying users is convenient for editorial teams, but roles in Multisite require careful attention. Review which roles were assigned to users on each site and whether they gained access to administrative capabilities they do not actually need.

What to fix

Adjust the roles on the destination site and test access again under another user account. On large networks, it is better to prepare a list of roles and target sites in advance than to fix permissions after a bulk copy.

When Multisite Content Copier is the right choice

Multisite Content Copier is worth using if you already have a WordPress network, a clear source site, a limited set of content to transfer, and a willingness to validate the result on a test subsite. It is especially useful for standard pages, starter content, site groups, and situations where manually repeating the same work leads to errors.

If, on the other hand, you need continuous synchronization, full-site cloning, deep support for a complex page builder, or data transfer for third-party plugins that rely on separate tables, it is better to review alternatives first. What matters here is not choosing the "most powerful" tool, but choosing the right one for the actual job.

Before rolling it out, prepare a backup, run a test on one destination site, and verify the media, permissions, and front-end output. If the test is stable, you can download Multisite Content Copier and move on to careful copying across the site groups you actually need.