--- title: "How to Export and Import WordPress Block Content" date: 2026-02-07 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-export-import-wordpress-block-content.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # How to Export and Import WordPress Block Content Choose an export method by scope. Clipboard suits a few blocks. WXR suits collections. APIs support controlled automation. Block markup can travel inside post content. Providers, media files, theme styles, shared records, configuration, and licences may not. Import into staging first. Map dependencies, preserve dates and ownership, then verify rendered output before any production release. ## Choose the transfer method by scope ScopeUseful methodMain limitation One block or sectionClipboard copyDependencies remain manual Reusable patternPattern export or managed codeShared identities need mapping Posts or pagesWXR export and importNot a complete site clone Repeatable content pipelineREST API or WP-CLIRequires engineering and logging Entire siteMigration or backup toolingBroad scope needs careful rollback No single export format contains every WordPress dependency.## Understand what WXR contains WordPress eXtended RSS is an XML content-transfer format. It can contain posts, pages, custom post types, comments, fields, terms, and users. The [official Tools Export guide](https://wordpress.org/documentation/article/tools-export-screen/) documents content filters and the downloaded WXR file. WordPress can import it on another site. Block markup travels inside each exported post’s content. That preserves delimiters and saved attributes when the target understands them. WXR is useful for content. It is not a database dump. It does not reproduce every option, plugin table, or server setting. ## Use Tools → Export 1. Open the source Dashboard. 2. Choose Tools, then Export. 3. Select all content or a content type. 4. Apply available filters deliberately. 5. Download the export file. 6. Record the export time and scope. 7. Store the file securely. Post and page filters can include author, date range, and status. Post exports can also filter by category. Use the narrowest scope matching the migration. Smaller files simplify review, importing, retries, and [rollback](https://wpblocksuite.com/blog/roll-back-wordpress-plugin-update/). ## Do not treat WXR as a full backup The [WP-CLI export reference](https://developer.wordpress.org/cli/commands/export/) states WXR excludes site options and attachment files. It can include attachment records without file bytes. - Theme and plugin code. - WordPress configuration. - Uploads as file bytes. - Most server configuration. - Some plugin custom tables. - Secrets and environment values. - Cache state. - Every licence or remote integration. Maintain separate tested backups for restoration. WXR supports content movement. A backup supports broader state recovery. ## Prepare the target before importing 1. Back up the target. 2. Create a staging copy. 3. Match supported WordPress versions. 4. Install approved block providers. 5. Configure target content types. 6. Create required taxonomies and terms. 7. Prepare author mappings. 8. Match theme tokens and block styles. 9. Record existing content counts. Importing before provider registration can create unsupported blocks. Importing before post-type registration can change or reject intended content. ## Use Tools → Import on staging Open Tools, then Import. Choose the WordPress importer. Install the approved importer when the interface requests it. Upload the WXR file. Map source authors to target users or create deliberate accounts. Avoid accidental administrator creation. The importer can attempt attachment handling when configured. Network access, source permissions, file sizes, and timeouts can affect results. Keep the import log. Record errors and imported IDs. Do not retry blindly after a partial result. ## Plan author mapping Authors affect ownership, archives, permissions, and accountability. Map people by responsibility, not merely matching display names. Create target accounts only when those people need access. Historical attribution can sometimes map to a non-login archival user. Confirm email, role, and public display settings. Never copy weak passwords or source credentials into the target. Document every mapping. Automated imports need a repeatable mapping file or rule. Ambiguous ownership becomes expensive later. ## Plan taxonomy mapping WXR can carry categories, tags, and custom taxonomies. The target may already contain similar terms with different slugs. Decide whether to merge, rename, or preserve source terms. Use meaning and [governance](https://wpblocksuite.com/blog/block-editor-governance-teams-agencies/). Do not rely only on numeric IDs. Review imported term descriptions and parentage. Duplicate terms can fragment archives, navigation, and internal reporting. ## Preserve statuses and dates deliberately Exports can include draft, pending, private, scheduled, and published content. Filters determine which records enter the file. Verify imported status, publication date, timezone, and slug. A content migration should not accidentally publish hidden drafts. Scheduled posts need special review. Target timezone and cron behaviour can change release timing. Pause schedules during uncertain migrations. ## Verify media attachment imports An attachment record and its uploaded file are different things. Confirm the target stores local files and generates expected sizes. - Original file exists. - Expected thumbnail sizes exist. - MIME type is correct. - Alternative text survived. - Captions and descriptions survived. - Parent relationships are acceptable. - File URLs use the target domain. - Licensing records remain available. Retry failed media separately where practical. Reimporting the whole file can create duplicates or confusing partial results. ## Verify registered block providers Search imported markup for block namespaces. Match each namespace to an approved target plugin or core capability. Open representative posts. Check for unsupported or invalid blocks. Do not attempt mass recovery until one example is understood. Provider version differences can trigger migrations. Preserve original WXR and staging backups before saving converted markup. ## Verify shared and synced patterns Synced patterns depend on separate records. Their references need correct imported or recreated target identities. Confirm each shared pattern’s title, content, owner, sync behaviour, and consumers. Numeric IDs can change during import. If the pattern cannot transfer safely, convert approved consumers into independent blocks. Record the loss of central synchronization. ## Verify internal links and embedded URLs Imported post content can retain absolute source URLs. Search the target database and rendered pages for the source hostname. - Page and post links. - Image and download URLs. - Buttons and calls to action. - Form destinations. - Embeds and API endpoints. - Canonical and social metadata. - Structured-data identifiers. - CSS background images. Rewrite only target-owned references. Preserve deliberate external citations. Test redirects, but prefer correct target URLs inside content. ## Verify custom fields and SEO metadata WXR can contain custom fields, but plugins decide how they register, interpret, and expose data. Target compatibility still matters. Check SEO titles, descriptions, canonicals, social fields, redirects, and schema settings. Do not assume visible post content proves metadata parity. Sensitive custom fields require special care. Export files can expose private values. Remove secrets before transfer and rotate anything exposed. ## Use WP-CLI for repeatable migrations The [wp export command](https://developer.wordpress.org/cli/commands/export/) generates WXR files with programmable filters. It can split files by maximum size. The [wp import command](https://developer.wordpress.org/cli/commands/import/) uses the WordPress Importer plugin. It supports author mapping and attachment-related options. Newer importer versions can rewrite imported source URLs through an option. Confirm installed support before depending on it. Store commands in reviewed runbooks. Capture stdout, errors, checksums, file names, versions, and final content counts. ## Use the REST API for controlled pipelines REST pipelines can fetch and create content records using structured JSON. They can map IDs and validate fields during transfer. Media usually needs separate upload handling. Taxonomies, authors, statuses, dates, and registered metadata need deliberate mappings. Use least-privilege credentials and encrypted transport. Never log passwords, application secrets, or private content unnecessarily. Make imports idempotent where possible. Record source-to-target IDs. Safe reruns should update known records rather than create duplicates. ## Export patterns for managed reuse Pattern-management interfaces can support individual exports. Theme-managed patterns can also live in reviewed code. Record titles, namespaced slugs, categories, keywords, and dependencies. Target imports should preserve stable meaning without assuming identical record IDs. Test pattern insertion after import. Confirm previews, translations, locking, and content-only behaviour. Review the resulting block tree. ## Distinguish Site Editor export The Site Editor can export theme changes into a downloadable package. This includes templates, [template parts](https://wpblocksuite.com/blog/wordpress-template-parts/), and styles. That export solves a different problem. It does not replace WXR content transfer. It also requires theme and code review. Choose it when moving a block theme’s design configuration. Choose WXR when moving posts, pages, and related content records. ## Prevent duplicate imports Partial imports can create some records before failing. Retrying without inspection may duplicate content, terms, attachments, or users. Compare imported IDs, slugs, titles, dates, and source identifiers. Remove test data only through a validated rollback plan. For repeatable tooling, use stable source identifiers and update logic. Do not treat titles as unique keys. ## Protect export files WXR files can contain sensitive material. Examples include drafts, emails, comments, custom fields, internal URLs, and personal data. Store them in access-controlled locations. Encrypt transfers where required. Set deletion dates after the migration and audit retention. Do not upload production exports to public file-sharing tools. Redact secrets and unnecessary personal data before external troubleshooting. ## Verify the import systematically 1. Compare record counts by type. 2. Review statuses, dates, and slugs. 3. Confirm author and taxonomy mappings. 4. Inspect representative block markup. 5. Find unsupported or invalid blocks. 6. Verify local media files. 7. Search for source-domain URLs. 8. Test synced patterns and dynamic blocks. 9. Review custom fields and SEO data. 10. Test forms and interactive output. 11. Check accessibility and responsive layouts. 12. Record exceptions and final sign-off. Sample every content shape, not merely several recent posts. Rare block types often contain the dependencies a quick review misses. ## Know when full-site migration is safer Use full migration tooling for deeply connected sites. Plugin tables, uploads, users, commerce, and complex relationships often require it. Plan downtime, URL replacement, cache clearing, search indexing, email, scheduled tasks, and rollback. The wider scope needs stronger controls. Do not choose full migration merely because WXR needs review. Broad copying can bring obsolete code and configuration too. ## Create a migration manifest List every exported content type, filter, status, date range, author, and expected count. Record the source URL and timezone. Add required plugins, themes, taxonomies, fields, media paths, and integrations. Name an owner for each dependency. Calculate a checksum for each export file when tooling permits. Checksums detect accidental file changes during storage or transfer. Keep the manifest beside protected logs, not inside public content. Update it after every retry or scope adjustment. ## Split large exports deliberately Large WXR files can hit upload, memory, execution, proxy, or importer limits. Smaller batches make failures easier to isolate. Split by content type, date, status, or other stable scope. Avoid overlapping filters that import the same records twice. Number files and record their order. Import shared terms or prerequisite records before dependent content when the workflow requires it. WP-CLI can split exports by maximum file size. Test the chosen threshold within target infrastructure. ## Decide whether comments and revisions belong Comments may belong with public posts, or they may contain personal data requiring separate review. Define the migration scope explicitly. Standard WXR movement focuses on content records, not complete revision history. Confirm any history requirement before choosing the method. Approval audits may need separate exports or retained source access. Do not promise historical parity without testing authoritative records. ## Design rollback before the first import Back up target staging and production before writing. Record existing IDs, counts, and content boundaries. Define the rollback owner. Prefer isolated staging that can be rebuilt. For production, know whether rollback restores the database, files, or imported records only. Do not delete partial imports manually without a manifest. Imported terms, media, users, and posts can have different relationships. After failure, preserve logs and stop reruns. Diagnose scope, correct the process, restore a clean target, then try again. Run one complete rehearsal before production. Measure duration, file sizes, failures, and verification effort. Update the manifest and rollback steps from observed results. Keep those results with the migration record. ## Frequently asked questions Does WordPress export preserve block content? Yes. Serialized block markup travels inside exported post content when the record is included. Does a WXR export include uploaded media files? No. It can include attachment records, while actual file transfer requires separate handling. Is WordPress Tools Export a complete backup? No. It omits important configuration, code, files, and some plugin-managed data. Can I import WordPress content with WP-CLI? Yes. The wp import command uses the WordPress Importer for WXR files. Why are imported blocks unsupported? The target may lack the required registered provider or a compatible version. ## The verdict Verdict **Choose scope first:** clipboard, WXR, APIs, and full migrations solve different problems. **Verify dependencies:** providers, media, identities, URLs, and configuration decide whether imported blocks work. A consistent block stack makes approved imports easier to validate. Try free plugins first. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when several Pro blocks support maintained sites.