WordPress validation should prove that the migrated site remains manageable as a content and application environment. A CMS Page can exist in the database while its parent hierarchy, featured image, menu link, custom fields, page template, or public route is wrong. A custom post type can retain titles and bodies while losing the taxonomy, metadata contract, permissions, archive, or plugin behavior that made the records useful.
The evidence set must therefore follow WordPress ownership. Core Posts, CMS Pages, attachments, taxonomies, terms, users, roles, comments, metadata, menus, and options require different proof. Plugin-owned post types, custom tables, builder data, memberships, forms, events, directories, courses, or external identifiers must be checked through the application that consumes them. Record totals support reconciliation, but they cannot approve launch by themselves.
Define WordPress Proof and Launch Decisions
Every material finding should end in one decision state:
- Pass: representative and exception evidence proves that the migrated record is editable, discoverable, correctly related, and usable through its intended WordPress owner.
- Watch: the result is usable, but a documented nonblocking correction, target configuration task, manual presentation adjustment, or accepted platform difference remains.
- Block: the issue materially affects content access, account permissions, public routes, search visibility, application behavior, compliance, or agreed migration scope.
| Evidence area | WordPress proof | Typical Block condition |
|---|---|---|
| Core content | Posts and CMS Pages retain content, status, author, dates, hierarchy, media, metadata, and intended route. | A priority page is missing, inaccessible, or no longer editable through the intended workflow. |
| Structured content | Custom post types, taxonomies, terms, metadata, and archives preserve the application model. | A material record type is flattened into generic content or loses required fields and classifications. |
| Identity and access | Users, roles, capabilities, authorship, memberships, and restricted content align with intended ownership. | Unauthorized users can access restricted records or required users lose access. |
| Presentation | Blocks, templates, builder structures, menus, and media references support the intended public result. | A launch-critical path is unusable even though its text exists. |
| Plugin scope | Plugin records and custom tables have an explicit target owner and usable output. | A business-critical plugin workflow loses records, relationships, or identifiers. |
| URLs and SEO | Permalinks, archives, metadata, internal links, and redirects preserve priority discovery paths. | A high-value route fails without an approved destination. |
The decision record should identify the exact post type, taxonomy, plugin, route, user role, or multisite context reviewed. A general “WordPress content passed” decision is too broad when the same installation can contain several independent applications.
Use Representative Testing to Test the Real Content Model
Representative testing should expose the relationships that make the WordPress site distinctive. Select samples such as:
- a normal Blog Post with categories, tags, author, featured image, comments, and an SEO-sensitive permalink;
- a CMS Page with parent hierarchy, menu placement, template assignment, embedded media, and internal links;
- records from each important custom post type;
- hierarchical and flat custom taxonomies with representative term assignments;
- metadata that stores literal values, attachment references, post relationships, term references, user references, or serialized plugin state;
- media galleries, downloadable files, and reused attachments;
- users with different roles, capabilities, authorship, or plugin-owned profiles;
- builder, shortcode, reusable block, or template-dependent pages;
- one route from every important archive or plugin endpoint;
- plugin-owned or custom-table records included in scope.
A Representative test result is a Block when it exposes a structural assumption that broader migration execution would repeat. Examples include custom post types becoming CMS Pages, old numeric IDs being copied instead of translated to new record references, taxonomy terms becoming disconnected labels, or a membership profile arriving without the WordPress user and protected-content relationships it requires.
Representative migration test is not expected to prove volume completeness. It must prove that the selected evidence represents the actual WordPress model and that administrators can reproduce the review in both the dashboard and public site.
Validate Core Posts, CMS Pages, Categories, Tags, and Menus
Core content validation should test the full record, not only the title and body. Publication status, author, dates, excerpts, featured media, comments, hierarchy, password protection, sticky state, revisions where included, and route behavior can all change how WordPress treats the record.
| Core content evidence | Pass | Watch | Block |
|---|---|---|---|
| Blog Post | Content, author, dates, categories, tags, featured image, status, and permalink are coherent. | A low-priority taxonomy or presentation detail needs cleanup. | Editorial history or a priority publication path is materially wrong. |
| CMS Page | Content, parent hierarchy, template context, menu link, and public route are correct. | Minor menu ordering or template adjustment remains. | A priority page is orphaned, private, or routed incorrectly. |
| Category or tag | Term identity, hierarchy where applicable, assigned records, metadata, and archive behavior are correct. | Optional archive presentation needs adjustment. | A priority classification cannot be queried or exposes unrelated records. |
| Menu item | Destination, hierarchy, label, access, and active state are correct. | Noncritical ordering remains. | A primary visitor path leads to the wrong destination or a dead route. |
| Comment | Parent content, author, date, status, reply hierarchy, and moderation meaning remain understandable. | Low-value moderation cleanup remains. | A required discussion or review relationship is lost. |
Categories and menus need separate proof. A Category can exist and classify Posts correctly while the menu still points to an obsolete path. Conversely, a menu can load a route while the associated archive contains the wrong records. The launch decision should reflect both structures independently.
Multisite requires site-aware evidence. Posts, CMS Pages, terms, options, menus, and many plugin records belong to one site in the network, while users may participate across several sites. A record found on the wrong site is not a successful migration even when its content is intact.
Validate Custom Post Types, Taxonomies, and Metadata Contracts
Custom post types define application-specific records such as events, resources, staff, properties, courses, listings, or case studies. Their validation must cover the registered type, editing interface, capabilities, taxonomies, metadata, public routes, archives, and template or plugin consumer.
| Structured record | Required evidence |
|---|---|
| Custom post type | The record appears under the intended type, supports the required editor fields, and renders through the intended single and archive routes. |
| Custom taxonomy | Terms remain in the correct vocabulary, preserve hierarchy where required, and classify the intended post types. |
| Post relationship | References point to the correct destination records rather than old source IDs. |
| Media reference | Attachment IDs and URLs resolve to the migrated file and preserve gallery or featured-image context. |
| User reference | Author, owner, instructor, vendor, reviewer, or assignee relationships point to the intended user. |
| Serialized or structured metadata | The owning plugin or field system can interpret the data without silent truncation or broken references. |
| Field definition | Labels, field types, allowed values, repeaters, groups, and conditional relationships remain usable where included in scope. |
A value can display correctly while failing structurally. For example, a source relationship field may show a Product title as text, but the destination application may require a post-object reference to support filtering and updates. That outcome is a Block when the relationship drives a launch-critical workflow; it is not approved merely because the title appears.
Validation should also distinguish public data from administrative data. An external CRM ID may never appear on the storefront but can still be launch-critical when synchronization, reporting, or reconciliation depends on it.
Validate Media, Blocks, Builders, Templates, and Public Rendering
WordPress presentation can combine attachment records, block markup, shortcodes, reusable blocks, patterns, template parts, builder metadata, theme options, menus, widgets, and plugin output. The validation target is not pixel-for-pixel reproduction unless that is explicitly included in scope. The target is usable content with correct ownership, references, and an approved presentation outcome.
| Presentation evidence | Pass | Watch | Block |
|---|---|---|---|
| Media | Files open, attachment metadata is coherent, and featured images or galleries reference the correct records. | Secondary captions, ordering, or sizes need cleanup. | Priority media is missing or linked to the wrong content. |
| Core blocks | Block structure remains editable and renders without broken references. | Minor spacing or theme differences remain. | Content becomes invalid markup or loses essential embedded data. |
| Shortcodes | The owning plugin or replacement renders the intended content. | A documented manual replacement remains. | A priority page exposes raw shortcode text or loses required functionality. |
| Page builder | Important content is editable in the intended builder or has an approved rebuild outcome. | Noncritical layout refinement remains. | A launch-critical page is blank, broken, or trapped in unusable metadata. |
| Template or theme context | The correct record template and navigation context apply. | Visual polish remains outside migration scope. | Visitors cannot use the page or administrators cannot maintain it. |
The evidence report should classify whether a presentation issue belongs to migrated content, target theme configuration, builder compatibility, manual reconstruction, or an agreed non-standard migration output. That ownership prevents content corrections from being confused with full site implementation.
Include both editor-side and visitor-side evidence. Editors should be able to locate the record, understand its reusable components, replace media, and update the page without relying on obsolete source IDs. Visitor evidence should cover responsive output, embedded assets, interactive sections, and any login or plugin context that changes rendering. This separates a cosmetic variation from a structure that is no longer maintainable.
Validate Users, Roles, Capabilities, and Plugin-Owned Profiles
A WordPress user is a login identity, not a universal business profile. The same user may also own Posts, belong to a membership plan, represent a course learner, manage a vendor account, or hold a plugin-specific profile. Validation should prove both the core identity and the application relationships included in scope.
| Identity evidence | Required proof |
|---|---|
| Core user | Username or email identity, display name, account state, and required profile fields are correct. |
| Role and capability | The user can perform intended actions and is prevented from unauthorized actions. |
| Authorship | Priority Posts and custom records remain assigned to the intended author or owner. |
| Restricted content | User-group, membership, or access relationships expose only the intended records. |
| Plugin profile | Membership, learning, directory, vendor, donor, or community records remain connected to the correct user. |
| Authentication boundary | Password, single sign-on, or multi-factor expectations have an approved account-access outcome. |
Use representative users from every material role, including users with overlapping roles or plugin relationships. A role name can look correct while its capabilities differ. A user record can exist while its membership or course progress is detached. Those outcomes require separate evidence and separate decisions.
Account evidence should also cover disabled or dormant users, duplicate emails, changed usernames, and accounts that must retain authorship without receiving login access. Where a plugin creates its own profile or organization record, verify the direction of the relationship: the WordPress user should point to the intended application record, and the application should return the same identity when administrators review it.
Validate Plugin Records, Custom Tables, and Commerce Boundaries
Plugins can store records through custom post types, metadata, options, comments, scheduled events, or dedicated tables. Validation should follow the actual owner rather than assuming every record is ordinary WordPress content.
| Plugin-owned area | Evidence to collect | Launch decision cue |
|---|---|---|
| Forms | Form definition, fields, routing, submissions where included, notifications, and external references | Block when a required form or agreed submission history is unusable. |
| Memberships | Plans, user relationships, status, access rules, and protected content | Block when active members receive incorrect access. |
| Learning systems | Courses, lessons, enrollments, progress, attempts, and certificates | Block when learner history or access cannot be reconciled. |
| Events or bookings | Events, sessions, resources, attendees, reservations, and dates | Block when scheduled obligations or reservations are wrong. |
| Directories or marketplaces | Listings, owners, taxonomies, locations, claims, vendors, or payouts | Block when ownership or public discovery is materially wrong. |
| Redirect or SEO plugin | Metadata, canonical values, schema fields, and redirect rules | Block when priority routes or search signals are lost. |
| Commerce plugin | Products, Customers, Orders, payments, shipping, tax, inventory, and extensions | Validate under the relevant commerce-platform role, not as core WordPress content. |
Agreed approved migration outputs should be validated against the selected supported requirement and expected destination field or record. non-standard migration outputs should be validated against the approved transformation, relationship, custom-table, or external-ID requirement. Neither proves that an unrelated plugin, theme, or integration has been fully implemented unless that work is explicitly included.
For each included plugin domain, choose at least one ordinary record, one exception record, and one relationship-heavy record. The evidence should show not only that values were transferred, but that the destination application can query, edit, and display them through its supported interfaces. Records preserved only as an archive should be labeled clearly so they are not mistaken for active application data.
Validate Broader Migration Execution Completeness and Later Actions
Broader migration evidence should expand from representative structure to complete scope and exception coverage. Reconcile totals by record type and status, then investigate differences rather than treating equal counts as the only goal. Include orphaned attachments, duplicate slugs, unpublished records, missing authors, unassigned terms, broken relationships, multisite scope, and plugin records that were excluded or handled separately.
Later activity requires action-specific revalidation:
| Later action | WordPress evidence to repeat |
|---|---|
| continue under the accepted configuration | Confirm that new or changed records still use the same post types, taxonomies, field definitions, site scope, route rules, and plugin relationships. Recheck collisions with edits already made in the Target Store. |
| continue under revised configuration | Revalidate every changed mapping, data type selection, field rule, taxonomy destination, media rule, and plugin-handling decision. Previous approval does not cover the changed configuration. |
| produce a distinct new migration result | Treat the new result as an independent evidence set. Repeat structural, identity, route, plugin, and launch-decision review rather than inheriting the prior result. |
Build the WordPress Launch Decision Record
The final report should be reproducible and owner-based. Record:
- the post type, taxonomy, user role, plugin, site, or route tested;
- the source and target identifiers needed for reconciliation;
- the expected result and observed evidence;
- the Pass, Watch, or Block decision;
- the owner of any correction or target configuration task;
- whether the finding affects launch, later migration activity, or only nonblocking cleanup;
- the evidence required to close the finding.
A Pass requires that priority content and application records are understandable, editable, discoverable, permission-aware, and connected to the intended public routes or plugin workflows. A Watch item has a named owner and does not undermine those outcomes. A Block remains when the site would publish broken priority paths, expose restricted content, lose application records, or prevent administrators from maintaining essential content.
Conclusion
WordPress validation must follow ownership rather than table similarity. Core Posts, CMS Pages, attachments, terms, users, comments, metadata, menus, custom post types, plugin records, routes, and presentation structures can share infrastructure while requiring different evidence.
Representative testing proves the content and application model. broader migration execution proves scope completeness and exception handling. Later migration actions require focused revalidation of changed records and configuration. Launch is approved only when the evidence supports usable content, correct access, reliable routes, maintainable plugin relationships, and explicit Pass, Watch, or Block decisions.
Common Questions
Is checking WordPress record counts enough after migration?
No. Counts cannot prove that records use the correct post type, taxonomy, metadata contract, site scope, user relationship, plugin owner, route, or presentation structure. They support reconciliation but must be paired with behavioral and relationship evidence.
Why must custom post types be validated separately from CMS Pages?
Custom post types can have different taxonomies, metadata, capabilities, archives, REST behavior, templates, and plugin consumers. Flattening them into CMS Pages can preserve visible text while removing the application model.
How should page-builder content be classified?
Validate the content, references, editing surface, and required public output. A result can Pass when the content is usable through the intended builder or an approved rebuild outcome. It should Block launch when a priority page is blank, broken, or no longer maintainable.
Should plugin records be validated as ordinary WordPress content?
No. Validate them through the plugin or replacement application that owns their fields, relationships, permissions, and workflows. Core WordPress existence does not prove membership, course, booking, form, directory, or commerce behavior.
What must be rechecked after a later migration action?
Recheck new and changed records, mapping rules, taxonomy assignments, references, user ownership, media, routes, plugin relationships, and collisions with Target Store edits. For WordPress, a changed configuration or distinct migration requires broader post-type, taxonomy, user, media, route, and plugin evidence than continuing unchanged setup.
When should a WordPress finding Block launch?
Use Block when a material issue prevents administrators or visitors from using priority content, exposes restricted records, breaks a high-value route, detaches business-critical plugin data, or violates the agreed migration output.