After a representative migration test or a broader run into WordPress, validation must connect the agreed content result with the publishing, access and application outcomes the destination needs. Approve evidence under the installed release, site or network, editor, active theme and registered application, because correct content in one context can remain unusable in another.
Record presence does not prove a manageable WordPress site:
- A CMS Page can lose its parent, featured image, menu link, custom fields, template or public route.
- A custom type can retain text while losing its taxonomy, metadata contract, permissions, archive or plugin behavior.
Test the intended editing, access and application outcomes.
Follow each record’s owner:
- Core: Posts, CMS Pages, attachments, taxonomies, terms, users, roles, comments, metadata, menus and options.
- Applications: plugin post types, custom tables, builder data, memberships, forms, events, directories, courses and external identifiers.
Validate through the intended consumer. Record totals support reconciliation; they do not authorize launch by themselves.
Record the installation and hosting constraints, active editor/theme, registered post types and plugins before judging the result. Native WordPress or plugin capability does not establish accepted migration coverage. Core content, separately agreed application records and target presentation or code work retain their own owners and evidence.
Define WordPress Evidence and Decision States
Every material finding should end in one decision state:
- Pass: evidence proves the agreed output and its required editing, discovery, relationships and access. An approved transformation, rebuild, archive or exclusion can Pass when it meets that agreement.
- Watch: a usable result has a documented remaining nonblocking issue, with an owner, follow-up evidence and an accepted scope effect. A planned platform difference alone is not an issue.
- Block: a required outcome is unusable or materially unproven, including critical access, permissions, routes, search visibility, application behavior, compliance or agreed output. Assignment or a deadline does not resolve it.
| 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. |
Use explicit acceptance criteria and record the exact post type, taxonomy, plugin, route, user role or site context reviewed.
A general “WordPress content passed” label is too broad when one installation contains independent applications. Apply each matrix below to its agreed scope; optional or excluded behavior is not automatically a defect.
Test the Agreed Content Model
Representative tests should expose the site’s actual relationships using capabilities available in the selected path. If a sample cannot exercise enhanced or separately implemented output, obtain that proof in its appropriate context. The following examples guide coverage; they do not establish automatic transfer eligibility.
- 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 result is Block for the affected next step when it exposes an unapproved structural assumption that broader execution would repeat.
Illustrative cases include:
- Required custom types flattened into ordinary Pages.
- Old numeric IDs copied instead of translated references.
- Taxonomy terms detached from their classifications.
- Membership profiles separated from required users or protected content.
Judge these against the agreed model, not an assumption that every Source structure must be cloned.
Representative testing establishes evidence for the selected model, not volume completeness. Administrators need to reproduce the review in the actual administration context and through the intended public or application consumer. Broader scope and untested exceptions require later proof.
Validate Core Content and Navigation
Review the full core record:
- Publishing: status, author, dates, excerpt, sticky state and included revisions.
- Relationships: featured media, comments and hierarchy.
- Access and discovery: password protection and route behavior.
Titles and bodies alone cannot establish the intended result.
| 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 | Agreed content, parent hierarchy, template context and menu use are correct; intended routes and access work for public or protected Pages. | Minor menu ordering or template adjustment remains. | A priority page is orphaned, unintentionally 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. |
Classification and navigation need separate proof:
- A Category can classify Posts correctly while a menu points to an obsolete route.
- A menu can open a route while its archive contains the wrong records.
Record both outcomes independently.
Identify whether the target uses classic menus, a Navigation block or another owner, and test the menu selected in each important header or template.
Distinguish an automatically generated Page List from individually maintained links. Publishing a Page can change the former; existing labels alone do not prove the intended continuing navigation.
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.
Use the intended user in each relevant site:
- Verify actual roles and effective capabilities there.
- Include a restricted record or action that must be denied.
- Distinguish site from network administration when assigning permission work.
A network account or role label alone does not approve site-specific access.
Prove Structured Content and References
Events, resources, staff, properties, courses, listings and case studies can use custom types. Test the registered type, editor, capabilities, taxonomies, metadata and intended template/plugin consumer.
Public routes and archives need proof where required; private or administrative records need the agreed access boundary instead.
| Structured record | Required evidence |
|---|---|
| Custom post type | The record uses the intended type and required editor fields; agreed single/archive routes and their access rules work where applicable. |
| 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.
Illustrative example: a relationship field shows a Product title as text, but the destination needs an object reference for filtering and updates. Apply the metadata/reference distinction.
That result is Block when the required relationship supports a launch-critical workflow; visible text alone does not approve it.
Public visibility and operational importance are different. An external CRM ID may never appear on the storefront but can be critical to integration relationships, reporting or reconciliation.
Check Editing and Public Rendering
Review the intended presentation layers:
- Attachment records, block markup, shortcodes and reusable blocks.
- Patterns, template parts, menus and widgets.
- Builder metadata, theme options and plugin output.
Require pixel-for-pixel reproduction only when explicitly agreed. Otherwise, prove usable content, correct references, ownership and the approved presentation result.
| 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. | A nonblocking spacing or theme deviation from the agreed outcome remains. | Content becomes invalid markup or loses essential embedded data. |
| Shortcodes | The owning plugin or replacement renders the intended content. | Only a documented nonblocking manual replacement remains; required content is already usable. | 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. | Optional out-of-scope visual polish is recorded separately; Watch applies only to a remaining nonblocking deviation. | Visitors cannot use the page or administrators cannot maintain it. |
Assign each presentation finding to its actual work:
- Migrated-content correction.
- Target theme configuration.
- Builder compatibility.
- Manual reconstruction.
- Agreed separate implementation.
This prevents record corrections from becoming an assumed full-site implementation promise.
Collect both evidence contexts:
- Editors: locate records, understand reusable components, replace media and update content without obsolete IDs.
- Visitors: inspect responsive output, embedded assets, interactive sections and rendering affected by login or plugins.
A cosmetic variation and an unmaintainable structure require different decisions.
For synced patterns and shared template parts, prove the shared definition and its uses on more than one priority page. A detached block no longer shares that pattern, and permitted local overrides need their own expected result.
Preserve the intended edit propagation and reference identity rather than approving a visually correct isolated copy.
Prove Identity and Effective Access
A WordPress login identity can also serve distinct purposes:
- Authoring Posts.
- Membership or learning access.
- A vendor account or plugin-specific profile.
Prove core identity and each agreed application relationship separately.
| 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 | The approved password, single sign-on or multi-factor account-access outcome is demonstrated on the qualified path. |
Sample all material roles, including overlapping roles and plugin relationships:
- A role name can appear correct while effective capabilities differ.
- A user can exist while membership or course progress is detached.
These outcomes need separate evidence and decisions.
Test a permitted editing or viewing task and a task that the same user must not perform. Match both to the actual capability set, content owner and site.
Imported identity or a successful login does not prove password continuity, membership access or authority to manage templates and application records.
Include account exceptions:
- Disabled or dormant states where used.
- Duplicate emails and changed usernames.
- Authorship retained without login access.
For plugin profiles or organization records, verify the expected association from both the user and application contexts. Follow the actual schema’s reference direction; matching identity in both reviews does not require reciprocal database fields.
Validate Plugin and Commerce Scope
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. |
Apply outcome validation to each evidence context:
- Compare migrated output with its agreed destination field or record.
- Compare separately implemented output with its transformation, relationship, custom-table or external-ID requirement.
Neither approves an unrelated plugin, theme or integration unless that implementation is explicitly included.
For each included plugin domain, sample an ordinary record, an exception and a relationship-heavy case.
- Live application data needs evidence that its consumer can query, edit and display the required result.
- An agreed archive needs its retained meaning and traceability verified, and must not be mistaken for active application data.
Scope determines the consumer proof required.
Reconcile Scope and Recheck Later Runs
Broader execution needs scope reconciliation, not equal totals alone. Compare record types and statuses, then investigate:
- Orphaned attachments, missing authors, unassigned terms and broken relationships.
- Duplicate slugs, unpublished records and Multisite scope.
- Plugin records excluded or handled separately.
Review differences against the agreed result and exception coverage.
Later activity requires action-specific revalidation:
| Later action | WordPress evidence to repeat |
|---|---|
| Continue with 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 after revising 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. |
| Create a 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. |
Revalidation follows what the later run actually touches:
- Name included records and rules, including earlier records updated or processed again. Unchanged configuration does not establish a newly-added-only window.
- Compare combined earlier/later output and protect accepted target-side changes where required.
- Reopen dependent post/media references, synced-pattern uses, site roles, selected navigation, priority routes and plugin consumers.
Run completion does not inherit a prior Pass.
Record the WordPress Launch Decision
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 proves the agreed result and its required content, relationships, access, routes or consumer behavior. Approved transformations, rebuilds, archives and exclusions can Pass when evidenced.
A Watch records a usable outcome with a remaining nonblocking issue, an accountable owner and follow-up evidence. A Block remains for unusable priority outcomes, restricted-content exposure, missing required meaning or materially unproven launch dependencies. An owner, deadline or completed run does not clear it.
Conclusion
WordPress validation follows the agreed meaning and consumer of each record. Shared storage does not make content, identity, application, route and presentation evidence interchangeable.
Representative tests establish selected structural evidence; broader runs reconcile agreed scope and exceptions. Later activity reopens the records, configuration and consumers it changes.
Use that evidence for go-live acceptance. Content and application proof informs launch authorization; it does not replace the separate decision to operate the live site.
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?
For live application data, validate through the plugin or replacement that owns its fields, relationships, permissions and workflow. Core record presence does not prove membership, course, booking, form, directory or commerce behavior.
An agreed archive needs its retained meaning, relationships and traceability verified against that scope; it should not be presented as a working live application.
What must be rechecked after a later migration action?
Recheck touched content, taxonomy assignments, metadata references, user ownership, media, routes and plugin relationships, including earlier records updated or processed again. Compare the combined result and accepted target edits.
Unchanged configuration does not establish a newly-added-only window; revised mappings or a distinct result require wider structural, site, permission and presentation evidence.
When should a WordPress finding Block launch?
Use Block when a material issue or missing critical evidence leaves an agreed launch requirement unusable or unproven. This includes priority content, restricted access, high-value routes, business-critical plugin relationships or required migration output. Assignment, monitoring or a deadline does not establish the missing result.
Can one correctly rendered WordPress page approve a synced pattern?
No. Check the shared pattern definition and at least two relevant uses, including editing behavior. An ordinary or detached block may look identical while losing shared updates.
Where the installed version permits local overrides, confirm which values should remain local and which should follow the shared definition. A launch-critical broken reference or unintended shared change is Block.
Does a WordPress network account prove access to every site?
No. Verify the intended role and effective capabilities in each relevant site and through the plugin or content owner. Include a denied action or restricted record. Site administration and network administration have different boundaries; a shared identity must not grant unintended content access or editing rights.