How to Move Blocks Between WordPress Sites

Move blocks between WordPress sites only after matching their providers and required design support. Then transfer serialized markup into staging.

Audit media, links, identifiers, shared records, queries, and frontend output before publication. Cross-site copying is a dependency migration.

Core text blocks travel easily. Dynamic plugin blocks, synced patterns, forms, and theme-led layouts need much more evidence.

Why block markup can travel

WordPress serializes a block tree into post content. HTML comments identify block names and can store attributes. More on that in how to export and import WordPress block content.

The official data format explanation describes this parsing and serialization lifecycle. Saved markup remains the content source of truth.

Copying that markup can recreate blocks on another site. The target still needs code understanding those block names and attributes.

Markup can also reference media URLs, record IDs, CSS classes, or external data. Those dependencies do not travel automatically.

Map every dependency before transfer

Dependency	Source evidence	Target requirement
Block provider	Namespace and version	Compatible registered block
Theme styles	Tokens, presets, CSS	Equivalent design support
Media	Files, metadata, licences	Imported local assets
Shared record	Pattern or entity ID	Mapped target record
Dynamic data	Post types and terms	Equivalent data model

Inventory block namespaces

Inspect the source content in code view or parsed tooling. Record every block name, including core and third-party namespaces.

A serialized third-party block resembles namespace/block-name. That namespace identifies its provider. Record required plugin versions and licences.

Install trusted compatible providers on target staging first. Do not paste unsupported blocks and hope installation later fixes everything.

The block file structure guide recommends registering content blocks through plugins. Theme switches should not remove core content capabilities.

Match provider versions carefully

The same plugin name does not guarantee compatible saved markup. Source and target versions may define attributes differently.

Read changelogs for migrations, deprecations, and renamed blocks. Test the source markup on target staging before changing production versions.

A newer provider may migrate old markup after editing. Save only after confirming the resulting output and rollback path.

Keep the original serialized source. Automatic migration can be useful, but the converted result may not reverse cleanly.

Create a target staging environment

1. Back up the destination.
2. Create or refresh staging.
3. Match supported WordPress versions.
4. Install approved block providers.
5. Configure the target theme.
6. Create required content types and terms.
7. Prepare representative media.
8. Create an empty destination draft.

Do not test first on a public destination. Broken dynamic blocks can expose errors, stale URLs, or private source content.

Choose the smallest transferable scope

Copy one block for one component. Copy an outer Group for a complete section. Transfer full content only when most blocks belong. The full walkthrough is in how to copy blocks between WordPress pages safely.

Smaller transfers reduce hidden dependencies. They also make validation and rollback clearer. Avoid moving an entire page for one card.

Large collections may need WXR, APIs, or migration tooling. Clipboard transfer remains useful for deliberate small-scale movement.

Copy serialized blocks through the editor

1. Open the source page.
2. Select the exact outer block.
3. Choose Copy.
4. Open target staging.
5. Paste into an empty draft.
6. Inspect List View.
7. Save only after validation.

Separate browser sessions can simplify source and target navigation. Confirm which site holds clipboard-sensitive private content.

If the paste becomes plain text, undo. Recopy through the block action. Do not publish a flattened fallback accidentally.

Use code view only with validation

Technical teams can copy serialized markup through the code editor. This preserves exact delimiters and attributes.

One malformed comment or JSON attribute can invalidate nesting. Validate before saving. Keep the source unchanged for comparison.

The edit and save guide explains block validation. WordPress compares regenerated markup with stored content to detect mismatches.

Do not manually “clean” unknown attributes during migration. Determine their owner first. Removing one can change frontend behaviour.

Move media files, not only URLs

Copied Image blocks can keep source-domain URLs and media IDs. The target may display remote files while appearing successful.

Import authorised files into the target Media Library. Replace block selections. Review alternative text, captions, crops, and focal points.

Do not hotlink the source accidentally. Source deletion, access controls, or domain changes can break target pages later.

Preserve licensing and attribution records. File movement does not create new usage rights. Remove private metadata where required.

Rewrite internal URLs

• Page and post links.
• Same-site anchor links.
• Media and download URLs.
• Form action destinations.
• API endpoints.
• Checkout links.
• Canonical or metadata fields.
• Structured-data URLs.

Search serialized markup and rendered output for the source hostname. Exclude legitimate external links deliberately, not accidentally.

Test redirects only as temporary protection. Target content should usually reference its own canonical resources directly.

Regenerate anchors and unique identifiers

HTML anchors can travel unchanged. Duplicate identifiers on the target page can break navigation and script targeting.

Plugin blocks may store unique IDs for styles or interactions. Test repeated instances. Follow provider guidance for regeneration.

Do not perform blind database replacement on opaque IDs. Some values may reference actual records. Map ownership before changing them.

Rebuild synced patterns on the target

A synced pattern references a separate WordPress record. Copying its reference does not guarantee that record exists on target.

Export or recreate the shared pattern through an approved method. Then map target content to the new target record.

Alternatively, convert the source to independent blocks before transfer. Confirm that losing synchronization matches the ownership decision.

Never guess shared record IDs. The same number can identify unrelated content on another WordPress installation.

Match theme tokens and presets

Blocks can reference named colour, spacing, font-size, and other presets. The target theme may lack those names or values.

Inventory source preset slugs. Map them to target design tokens. Avoid replacing everything with hard-coded inline styles.

Matching slugs with different values can change appearance intentionally or accidentally. Compare the rendered designs, not names alone.

Preserve destination governance. A source page should not import a competing design system through local overrides.

Match block styles and CSS

Named block styles require registration and CSS on the target. Without them, the class can remain while appearance disappears.

Inventory custom classes too. Decide whether each belongs to theme code, plugin code, or obsolete source implementation.

Port approved styles through maintained code. Do not paste random CSS into page content. Test editor and frontend consistency. We work through it in pasting from Google Docs cleanly.

Map custom post types and taxonomies

Dynamic blocks can query source post types, terms, authors, or metadata. The target may use different identifiers or models.

Create equivalent structures before transfer. Map terms by meaning, not numeric ID. Recheck query filters and empty states.

A query returning nothing is not always broken markup. It may reveal missing target content. Confirm expected data separately.

Treat forms as application migrations

Form blocks can depend on many external settings. These include recipients, webhooks, lists, keys, consent rules, and spam protection.

Recreate configuration securely on target. Never copy production secrets through visible block markup. Rotate exposed credentials immediately.

Submit controlled tests. Verify validation, delivery, storage, consent text, success actions, and deletion workflows.

Inspect dynamic and server-rendered blocks

Dynamic blocks may serialize only attributes and render through PHP. A valid editor block can still fail on the frontend.

Check target logs, permissions, queries, caches, and templates. Test anonymous visitors and supported signed-in roles.

Compare source and target outputs with realistic content. Exact visual matching may be inappropriate when target design intentionally differs.

Handle unsupported blocks without losing content

WordPress may show unsupported or invalid blocks when providers are missing or markup differs. Preserve the original source before recovery.

Install the approved provider when appropriate. Otherwise convert through a tested replacement path. Keep meaningful content readable.

“Convert to HTML” can preserve output but remove structured editing. Use it only after understanding the maintenance tradeoff.

Do not click Attempt Recovery across many blocks blindly. Test one representative block and compare serialized results.

Validate responsive behaviour

Target container widths, breakpoints, typography, and spacing can change wrapping. Preview narrow, medium, and wide screens.

Check Columns, grids, Covers, galleries, tables, and long buttons. Use realistic translations and content lengths.

Do not fix every difference with local overrides. Adapt the block to the target design system first.

Validate accessibility and semantics

• Heading hierarchy.
• Keyboard order and visible focus.
• Alternative text and captions.
• Form labels and instructions.
• Table headers.
• Contrast against target colours.
• Landmarks and link text.
• Zoomed and reflowed content.

Source accessibility does not transfer automatically. Target styles and scripts can change the experience. Test the rendered destination.

Run a source-hostname audit

Search target content, markup, metadata, and network requests for the source hostname. Classify every remaining reference.

Keep deliberate citations and external destinations. Replace target-owned media, pages, APIs, forms, and canonical references.

Repeat after cache clearing. Generated CSS, embeds, or plugin data may retain source URLs outside visible content.

Map permissions and user context

Blocks can show content based on authors, roles, capabilities, or signed-in state. Target users rarely share source numeric IDs.

Map responsibilities and capabilities deliberately. Test anonymous visitors, editors, members, and administrators through representative target accounts.

Do not copy source role names into custom logic blindly. Check capabilities server-side. Preserve least-privilege access on target.

Check performance and loaded assets

A transferred block can introduce new scripts, styles, fonts, images, or requests. Measure the destination before and after migration.

Check editor responsiveness and frontend metrics. Look for duplicate libraries, broad asset loading, layout shifts, and failed network requests.

Target caching can hide failures temporarily. Test logged-out visits after clearing page, object, browser, and edge caches.

Do not preserve source optimisations without understanding them. Destination hosting and theme architecture may need different implementation.

Check structured data and duplicated schema

FAQ, review, recipe, event, and product blocks can emit structured data. The target may already generate similar schema elsewhere.

Inspect rendered JSON-LD and microdata. Validate representative URLs. Remove duplicate or conflicting claims through the owning system.

Schema must match visible target content. A copied rating or date can create inaccurate machine-readable claims.

Retire the source only after acceptance

“Move” often includes eventual source removal. Keep the source until target content, media, links, forms, and search behaviour pass review.

Plan redirects for public URLs. Update canonical signals, sitemaps, navigation, and external campaigns. Monitor logs after launch.

Archive source evidence when policy requires it. Revoke obsolete integrations and licences. Remove credentials from retired environments.

Document the acceptance date and owner. A clipboard transfer becomes a completed migration only after controlled source cleanup.

Document the final target baseline

Record WordPress, theme, and provider versions after acceptance. Include migrated block namespaces, mapped records, and known exceptions.

Capture representative screenshots and validated URLs. Store source exports securely. Set review dates for temporary compatibility code.

This baseline simplifies future updates and incident diagnosis. Without it, teams cannot distinguish migration defects from later changes. Review the baseline after scheduled updates and provider migrations. Record every deliberate exception for future maintainers. Always keep ownership explicit.

Use a staged release checklist

1. Inventory block namespaces and versions.
2. Prepare compatible target staging.
3. Transfer the smallest useful scope.
4. Import authorised media locally.
5. Rewrite internal URLs.
6. Map patterns, terms, and records.
7. Match tokens and block styles.
8. Validate serialized block structure.
9. Test dynamic output and forms.
10. Check accessibility and responsive layouts.
11. Search for source references.
12. Prepare production rollback.
13. Repeat smoke tests after release.

Frequently asked questions

The verdict

A consistent provider stack simplifies approved cross-site movement. Try free plugins first. Then compare the $299 lifetime suite when several Pro blocks support maintained sites.