WordPress → Strapi
Move structured WordPress content into Strapi with an approved schema, configurable content-type APIs, explicit HTML and field transformations, relationship ordering, media handling, staging validation, and front-end cutover boundaries.
Self-service migration path
Source and target connectors are available. wordpress: Available. strapi: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the site URL and an Application Password, or approve a Bridge when required custom types, metadata, taxonomies, media, comments, menus, or plugin fields are not available through REST.
Provide the Strapi base URL and a restricted API token with create and update permissions for the approved content types and upload access for in-scope media.
Confirm plural API IDs, field names and types, required fields, relations, media fields, draft and publish behavior, locales, components, dynamic zones, and the destination front-end contract before loading.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to WordPress and connect a prepared staging Strapi destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported WordPress data belongs in the prepared Strapi model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
This page is synchronized with the WordPress source capability and stable Strapi target capability. Both are public-ready in both directions; this path requires a prepared Strapi schema rather than generic record dumping.
The current source exposes Authors, Categories, Tags, Posts and pages, Comments, Menus, Menu items, Media plus the mapped editorial fields documented on the WordPress service page. Plugin-owned and custom fields still require discovery.
The current target exposes Attachment, Author, Content, Tag. API names for the article, author, and category or tag content types are configured explicitly, and fields must match the target payload.
Standard means the current target payload matches a prepared Strapi field. Review means schema or transformation decisions are required. Custom means the feature is outside the configured article, author, category or tag, and attachment path.
| WordPress source | Strapi target | Status and boundary |
|---|---|---|
| Posts | Configured article or post collection type | Standard: title, content, slug, excerpt, author, tags, attachments, and approved publication state are available to the target payload. |
| Pages and custom post types | Configured collection types | Review/custom: the standard target uses one configured content API; multiple destination types require routing and schema-specific work. |
| Authors | Built-in users or a custom author content type | Standard with configuration: the target author API name and identity rules must be approved before content relationships load. |
| Categories and tags | Configured category or tag content type | Review: WordPress taxonomies may be consolidated because the current target uses one configured term API. |
| Featured and inline media | Strapi Media Library and media fields | Standard with validation: assets require upload permission, compatible fields, provider acceptance, and rewritten references. |
| HTML and Gutenberg markup | Text, rich-text, blocks, components, or dynamic zones | Review/custom: the current standard payload writes content to a configured field; structured blocks need schema-aware transformation. |
| Draft, published, scheduled, pending, private, and trash | Draft and Publish state | Review: published records can receive publishedAt; other WordPress states need an explicit safe mapping. |
| SEO and source URLs | Custom SEO component or fields plus front-end routes | Custom/review: SEO storage and public URLs belong to the prepared schema and front end, not a universal Strapi core field. |
| Comments, menus, roles, and passwords | Custom content types, front-end navigation, or user systems | Custom/excluded: these are not standard configured destination entities in the current Strapi adapter. |
| Theme, templates, plugins, forms, and commerce | Headless front end and integrations | Rebuild: WordPress presentation and application behavior require separate implementation. |
The mapping contract ties each WordPress field to the actual Strapi content-type schema and the front-end query that will render it.
| WordPress value | Migration rule | Strapi result |
|---|---|---|
| Post ID and post type | Preserve source identity and route the record to an approved API ID | Stable migration ID plus configured Strapi document |
| Title, body, slug, excerpt | Normalize markup and map to exact destination field names | Article title, content, slug, and excerpt fields |
| Author ID | Create or match the approved author record before content | Author relation using the destination ID |
| Categories and tags | Consolidate or separate taxonomies and load terms first | Configured term records and article relations |
| Attachment URL | Download, upload through the media path, and record the result | Media Library asset plus linked media field or rewritten content |
| Status and old URL | Translate publication state and add the source path to the route contract | Draft or published document plus front-end redirect requirement |
Strapi generates APIs from the destination content model. Records cannot be mapped reliably until API IDs, fields, relations, validation, localization, and publication behavior are stable.
List post types, taxonomies, fields, ACF groups, plugin metadata, blocks, media, users, comments, menus, counts, statuses, and relationships.
Approve collection types, fields, components, dynamic zones, media, relations, locales, required values, defaults, and front-end ownership.
Confirm plural API IDs, token permissions, payload shapes, relation IDs, provider limits, draft behavior, and error responses before the dry run.
Load authors, terms, and media before articles, preserve source IDs, and reconcile every failed or rejected relationship.
Copying rendered HTML may preserve appearance temporarily but can leave shortcodes, embeds, classes, and plugin assumptions that the new front end cannot use.
Map standard blocks to approved content, convert reusable structures, and identify custom blocks that need components or manual reconstruction.
Replace shortcodes, builder wrappers, tracking fragments, broken embeds, inline scripts, and source-only classes according to approved rules.
Split people, locations, calls to action, related content, downloads, and other reusable entities only when the destination schema and front end support them.
Check stored values, relations, media, locales, draft state, API responses, preview, front-end rendering, links, metadata, and conversion journeys.
Strapi stores content, while public paths, metadata rendering, canonicals, sitemaps, redirects, caching, and analytics normally belong to the headless front end or edge platform.
Pair every valuable WordPress URL with the exact front-end route and content query that will render the approved Strapi record.
Map source SEO values into prepared fields or components, then verify how the front end renders titles, descriptions, canonicals, social tags, and schema.
Implement old-to-new redirects at the correct layer, rewrite internal references, and test status, chains, loops, parameters, and trailing slashes.
Coordinate API availability, front-end deployment, cache invalidation, sitemap generation, analytics, forms, error monitoring, and rollback ownership.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Check the schema, version and publication-date requirements before quoting.
Open guide →Agree the destination fields, relationships and exceptions.
Open guide →Review WordPress source extraction, custom content, plugins, media, URLs, and destination planning.
Open guide →Compare a publication-focused destination with posts, pages, tags, members, newsletters, and Ghost routes.
Open guide →Clear answers
Yes when the Strapi article or post content type is prepared with compatible fields. The standard target payload supports title, content, slug, excerpt, author, tags, attachments, and publication state.
They require routing review. The current target uses one configured article content API, so multiple destination models or custom fields need schema-specific mapping or adapter work.
Only through explicit transformation into compatible Strapi fields, components, dynamic zones, or related content types. Blind HTML copying does not create a maintainable structured model.
Supported files can be downloaded and uploaded when the API token has permission and the destination media provider accepts them. Inline references and media fields are validated separately.
They are not standard configured target entities in the current Strapi adapter. They require a custom model, another system, front-end implementation, archive, or exclusion.
No. Routes, metadata rendering, canonicals, sitemaps, and redirects normally depend on the prepared schema, headless front end, and edge configuration.
No. Reduce risk through URL and metadata contracts, dry runs, validation, coordinated deployment, monitoring, and rollback decisions, but external search and infrastructure outcomes cannot be guaranteed.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
