Validate Content, URLs, and Redirects

Validate Content, URLs, and Redirects

Content and URL validation is complete when required CMS Pages and Blog Posts are usable on the target store, priority URLs lead to the intended content, and supported redirects preserve the approved old-to-new paths. Use this checklist to separate migration defects from expected platform differences, target-store configuration, and presentation work before final sign-off.

This page validates migrated content and the result of applicable URL options. It does not promise that every metadata field, source URL pattern, theme layout, or search-engine outcome can be preserved across every migration path.

When to use this checklist

Use this checklist after Validate Full Migration Results confirms that the completed activity and overall scope are suitable for detailed review.

Complete it after catalog and Customer or Order checks when those areas provide URLs or relationships used by the content sample. Finish it before Define Sign-off Criteria is approved.

Prepare the content and URL evidence

Collect evidence that identifies the expected source result and the corresponding target result:

• the completed migration activity, target store, and source-data window;
• selected CMS Pages and Blog Posts when supported by the migration path;
• Success, Failed, and Skipped results for the applicable data types;
• stable source identifiers, source URLs, and corresponding target identifiers or URLs;
• the approved list of priority pages, posts, Products, Categories, and campaign URLs;
• applicable Migrate SEO URLs of categories, products, posts and pages and Create 301 redirects for migrated URLs settings;
• the expected target URL pattern or approved platform equivalent;
• content expectations for titles, body content, images, internal links, authors, Categories, dates, formatting, and priority metadata where applicable;
• known source issues, platform-model differences, and accepted limitations;
• a findings record with severity, owner, due date, and required next action.

CMS Pages and Blog Posts are separate data types

Validate CMS Pages and Blog Posts independently when both are supported and selected. A migration path can support one type, both types, or neither, depending on the Source Platform and Target Platform data models.

Build a representative sample

Do not validate only the homepage or a few recently created records. Select enough records and URLs to cover business importance, structural complexity, configuration impact, time range, and known risk.

Sample dimension	Include when available	Why it matters
Business importance	Policy pages, legal pages, high-traffic landing pages, campaign pages, high-value Blog Posts, and pages linked from primary navigation	Exposes differences with material customer, compliance, or search impact.
Content structure	Rich text, embedded images, tables, lists, internal links, authors, Categories, publication dates, and long-form formatting	Tests the content structures most likely to transform between platforms.
URL importance	Organic landing pages, paid campaign URLs, priority Product and Category URLs, bookmarked pages, and URLs listed in analytics or a sitemap	Focuses redirect and continuity checks on business-critical paths.
Configuration impact	Records affected by SEO URL migration, 301 redirects, description-image import, HTML handling, Data Filter, Advanced Data Mapping, Advanced Database Mapping, Data Transformation, or Customization	Confirms that the selected configuration produced the approved result.
Time and source window	Older and recent content, plus records near the beginning and end of the intended source-data window	Detects incomplete or unintended scope.
Known risk	Demo issues, previously Failed or Skipped records, source URLs with unusual characters, duplicate slugs, changed paths, unsupported fields, and expected target transformations	Confirms that known exceptions are resolved or accepted.

Increase the sample when the source content model is complex, many priority URLs change, redirect behavior is handled across multiple systems, or one issue appears across more than one content or URL pattern.

Run the content, URL, and redirect checks

1. Confirm the activity and content scope

   Verify that the records belong to the intended migration activity, migration path, target store, and source-data window. Confirm whether CMS Pages, Blog Posts, SEO URLs, and 301 redirects were supported, selected, and expected for this result.

2. Reconcile processing evidence

   Review Success, Failed, and Skipped results for CMS Pages and Blog Posts. Classify every Failed and unexpected Skipped record that affects required content or a priority URL.

3. Confirm CMS Page presence and identity

   Match each sampled target CMS Page to the intended source page using a stable identifier, title, source URL, or other distinguishing value. Confirm that required pages exist once and are available in the approved target location or equivalent content model.

4. Confirm Blog Post presence and identity

   When Blog Posts are supported and selected, match each sampled target post to the intended source post. Confirm required titles, body content, publication state, authors, Categories, dates, images, and relationships where those elements are supported and included in the acceptance criteria.

5. Validate content fields and formatting

   Compare titles, body content, headings, lists, tables, links, media, and priority metadata. Require exact values where the field is supported and defined as exact; use an approved equivalent when the Target Platform represents the same content meaning differently.

6. Validate images and embedded resources

   Confirm that required images load, belong to the correct record, and remain usable under the approved target behavior. When description-image import was enabled, test normal and exception records affected by source access, file format, authentication, CDN, or target media rules.

7. Validate internal links

   Open internal links in sampled pages and posts. Confirm that they lead to the intended target content, use the approved domain and protocol, and do not leave launch-critical links pointing to an obsolete source environment unless that behavior was explicitly approved.

8. Validate migrated target URLs

   When Migrate SEO URLs of categories, products, posts and pages was enabled and supported, compare priority target URLs with the approved target paths. Confirm the correct record opens and document target-platform path changes rather than requiring unsupported source patterns.

9. Validate 301 redirect pairs

   When Create 301 redirects for migrated URLs was enabled and supported, test each sampled source URL against its approved target destination. Confirm that the old URL returns the supported permanent redirect behavior and resolves to the intended live target record.

10. Check redirect quality

    Confirm that priority redirects do not lead to an unrelated page, redirect loop, avoidable multi-step chain, or final 404 response. Record whether an issue is caused by migrated redirect data, target routing, domain or web-server configuration, an application, or another target-side system.

11. Check priority URLs without migrated redirects

    When redirect creation was unavailable or intentionally excluded, compare the priority source URL list with the approved target-side redirect plan. Treat missing required coverage as an open launch item, not as proof that an unavailable migration option failed.

12. Validate affected configuration behavior

    Test normal, boundary, and exception records affected by filtering, supported field or database destinations, transformation, or approved Customization. Confirm that these rules preserve required content, relationships, and URL meaning.

13. Classify differences and record the decision

    Assign a failure class and severity to every unexplained difference. Record Pass, Pass with accepted limitations, or Fail, together with evidence, owners, corrective actions, and any required target-side work.

Apply testable content checks

Area	Pass condition
CMS Page presence	Every required sampled CMS Page exists in the intended target store and represents the correct source page.
Blog Post presence	Every required sampled Blog Post exists when supported and selected, and represents the correct source post.
Titles and body content	Required text is exact or transformed according to an approved rule without unexplained omission or corruption.
Authors, Categories, and dates	Applicable relationships and dates preserve the approved content meaning or documented target equivalent.
Images and media	Required media loads, belongs to the correct content record, and remains usable under the approved target behavior.
Internal links	Sampled links open the intended target content without launch-critical references to obsolete or incorrect destinations.
Priority metadata	Required supported metadata is present or represented through the approved target field or model.
Formatting	The content remains readable and editable; expected theme or editor differences are assigned separately.
Configuration behavior	Applicable options, Add-ons, and Customization produce the approved content scope, values, and relationships.

Apply testable URL and redirect checks

Area	Pass condition
Target URL identity	Each sampled target URL opens the correct Product, Category, CMS Page, or Blog Post.
SEO URL migration	When enabled and supported, the resulting path matches the approved source path or documented target equivalent.
Redirect destination	Each required sampled source URL resolves to the approved target destination.
Redirect status	The tested redirect uses the supported permanent redirect behavior where a 301 redirect was required.
Redirect chain	Priority URLs do not use an unexplained or avoidable chain that increases failure risk.
Redirect loop	No tested URL enters a loop or repeatedly returns to an earlier path.
Final response	The final destination loads the intended content and does not return an avoidable 404 or unrelated fallback page.
Coverage	The sampled priority URL list accounts for migrated redirects and any approved target-side redirect work.

A working destination does not prove the redirect is correct

Opening the final target page directly does not validate the old source URL. Test the source URL itself and record the redirect destination, behavior, and final response.

Interpret expected platform differences

Difference	Acceptance approach
CMS and Blog content use different record models	Confirm that required content, ownership, publication state, and editing use remain available through the approved target representation.
Metadata fields are renamed, combined, or unavailable	Confirm the approved supported destination or document the limitation and its search or operational impact.
Rich content is normalized by the target editor	Confirm that required text, links, media, and meaning remain intact; assign non-critical presentation cleanup separately.
URL prefixes or path structures change	Confirm the approved target URL and required redirect from the priority source URL.
Duplicate or reserved slugs require a target variation	Confirm that the affected content opens at the approved unique path and that the old path is handled where required.
Authors or Categories use a different target structure	Confirm the approved equivalent and that discovery or editorial ownership remains usable.
Redirects must be configured outside the migration result	Confirm the target-side owner, required pairs, implementation status, and validation evidence before launch authorization.

An expected platform difference must be defined, understood, and approved. Do not accept an unexplained missing field, broken relationship, changed URL, or failed redirect merely because the platforms differ.

Decide the content and URL outcome

Pass

Use Pass when:

• the sample covers the required content and URL risk dimensions;
• required CMS Pages and Blog Posts are present and correctly identified where supported and selected;
• required text, relationships, images, links, metadata, and formatting meet exact or approved transformed expectations;
• priority target URLs open the intended records;
• required sampled redirects resolve correctly without loops, unrelated destinations, or avoidable high-value 404 responses;
• Failed and Skipped records are resolved or understood;
• no unresolved Blocker or High-severity issue remains;
• required evidence is recorded.

Pass with accepted limitations

Use Pass with accepted limitations when:

• the difference is known and explained;
• the target representation or URL behavior is permitted by the acceptance criteria;
• customer, editorial, compliance, and search effects are understood;
• an authorized owner accepts the limitation;
• target-side work or mitigation has an owner and due date;
• the limitation does not make launch preparation materially unsafe.

Fail

Use Fail when:

• required content is missing, duplicated, corrupted, or associated with the wrong record;
• a required relationship, internal link, image, or priority metadata result is incorrect;
• a priority target URL opens the wrong content;
• a required source URL does not redirect, redirects to the wrong destination, loops, or ends in an avoidable 404;
• Failed or Skipped records affect required scope;
• configuration behavior is incorrect;
• platform differences have not been defined or approved;
• evidence is insufficient for acceptance.

Classify failures before correction

Failure class	Safest corrective path
Wrong activity, environment, or source-data window	Stop validation and identify the correct result.
Source-data quality issue	Correct the source content or document an approved source limitation.
Selection or filtering issue	Review selected CMS Pages or Blog Posts and applicable Data Filter behavior before another migration activity.
SEO URL option issue	Review whether URL migration was enabled and supported, then retest the affected target paths.
Redirect option issue	Review whether redirect creation was enabled and supported, then compare the required old-to-new pairs.
Advanced Data Mapping, Advanced Database Mapping, or Data Transformation issue	Correct the rule or destination and retest normal, boundary, and exception content.
Customization issue	Compare the result with the approved Custom Service requirement and request review when it differs.
Processing issue	Preserve the activity, data type, identifiers, URLs, counts, and relevant log evidence before contacting support.
Platform-model limitation	Define the supported target representation and obtain approval for the documented difference.
Target-store routing or content setup issue	Correct the target route, domain, application, content model, or publication settings without starting another migration activity unnecessarily.
Validation-method or evidence issue	Correct the source-to-target match, test the source URL itself, expand the sample, or collect missing evidence before deciding.

Record the validation output

Record:

• migration activity, target store, source-data window, and review date;
• selected CMS Page and Blog Post scope;
• sampled source identifiers, source URLs, target identifiers, and target URLs;
• checks performed and expected results;
• applicable SEO URL, redirect, image, Add-on, and Customization behavior;
• Success, Failed, and Skipped findings;
• exact or approved transformed content and URL expectations;
• redirect status, destination, chain, loop, and final-response results for priority URLs;
• accepted platform differences and customer or search effects;
• target-side work, open issues, severity, owner, due date, and corrective path;
• final Pass, Pass with accepted limitations, or Fail decision;
• reviewer and approval date.

Use My Tickets when an issue requires Next-Cart review. Include representative identifiers and URLs, but do not include credentials, private access tokens, or unnecessary personal data.

Next step

After Pass or Pass with accepted limitations, continue with Define Sign-off Criteria.

After Fail, correct the classified cause and repeat only the affected content, URL, or redirect checks. Repeat related Product or Category validation when the corrective action changes catalog URLs or relationships.