4. Rebuilding the Content Model

4.1 Designing schemas in Payload

Design schemas for editorial clarity first, not for one-to-one WordPress table mapping.

Model for portability

When you migrate from WordPress, aim for a destination model where:

• Core editorial content is independent from layout choices
• Reusable elements (callouts, galleries, feature lists) are represented as explicit blocks
• SEO metadata lives in a single, consistent group
• Navigation is modeled as data, not as hard-coded markup

Core collections

• posts
• pages
• authors
• categories and tags
• navigation
• globals for site-level settings

Recommended fields

• title, slug, excerpt, heroImage
• seo group: title, description, canonical, social image
• contentBlocks array for structured rich sections
• status, publishedAt, updatedAt

4.2 Editorial workflows

Set up workflow intentionally:

• Roles: admin, editor, author, reviewer
• Draft and publish transitions
• Preview URLs with token protection
• Scheduled publish with timezone rules

Workflow guardrails

• Require slug validation before publish
• Require SEO title and description for indexable pages
• Log publish events for rollback auditing

4.3 MDX strategy

Use MDX where engineering ownership is useful.

Strong MDX candidates

• Technical guides and docs
• Pages with reusable interactive components
• Content that benefits from version control review

Strong CMS candidates

• Marketing pages managed by non-developers
• Frequently edited editorial pages
• Structured content reused across multiple templates

Gutenberg mapping strategy (common case)

If your WordPress content is Gutenberg-first, you have three practical migration approaches:

Option A: Convert blocks into structured CMS blocks

Best when you want editorial content inside Payload and you want predictable templates.

• Convert paragraphs, headings, lists, and images into the obvious equivalents
• Map common block patterns into explicit Payload block types
• Treat unknown custom blocks as a separate type that gets manual review

Option B: Convert blocks into MDX

Best when engineering owns the docs-like content and you want component-driven rendering.

• Convert common blocks into markdown primitives
• Convert special blocks into MDX components
• Preserve raw HTML only as a last resort, and isolate it

Option C: Preserve HTML and rebuild layout

Best when content portability is limited, but you still want to migrate quickly.

• Store sanitized HTML in a single field
• Rebuild templates around it
• Use this as a temporary state, not a long-term content strategy

Navigation and menus

Do not leave navigation as an afterthought. Model it explicitly.

Typical approach:

• A navigation collection that stores menu structures and links
• A globals record that references the active header and footer menus
• A redirect-aware link model so legacy paths can be preserved during migration

Ownership model

Define who edits what:

• Marketing team owns CMS collections
• Engineering owns MDX docs and component contracts
• Shared governance for SEO fields and publishing SLA

Migration pattern

1. Build schemas and validation.
2. Import sample dataset.
3. Run editor UAT.
4. Adjust field design before full import.

If the site uses a page builder that stores critical content in proprietary formats, content modeling becomes only one part of the problem. You may need a partial salvage plus manual rebuild approach. If you need help scoping that, contact BeyondWP.