QA starts before launch
Migration QA should begin while the Shopify store is still being prepared. Redirects, metadata, indexability, tracking, templates and priority landing pages need checks before the domain switch.
Launch-day QA protects the handover
On launch day, focus on the highest-risk items: old URLs, top landing pages, analytics, checkout, robots rules, sitemap access and Search Console readiness.
Post-launch QA finds what launch missed
Crawl errors, missed redirects, indexing changes and tracking issues often appear after launch. A monitoring window is part of the migration, not an optional extra.
QA needs evidence, not vibes
Record test results, URLs, screenshots, dates, owners and fixes. Without a log, migration issues become vague arguments about whether traffic has dropped.
A Shopify migration QA checklist is not about testing pages.
It is about preventing surprises.
Most migration QA fails because it is treated as a final check instead of a control system. Pages are reviewed, but not prioritised. Issues are found, but not logged. Fixes are applied, but not tracked.
That creates uncertainty at the point where the store should be most controlled.
This checklist is designed to make the migration predictable by forcing structured checks, ownership and evidence before and after launch.
Why migration QA fails
Most QA processes fail for predictable reasons:
- testing starts too late
- no sample set is defined
- issues are not logged consistently
- page types are not separated
- priorities are unclear
- launch-day checks are rushed
- post-launch monitoring is skipped
The result is a store that looks ready but behaves unpredictably.
QA should reduce uncertainty, not reveal it after launch.
What QA is actually doing
QA is not checking pages.
It is validating that:
- important URLs behave correctly
- redirects preserve intent
- collections and products match expectations
- tracking can be trusted
- internal links support key pages
- search engines can access the store
The goal is not coverage. It is confidence.
QA priority order
Do not treat all checks equally.
Use this order:
- Redirects and old URLs
- Priority collections and products
- Indexation and crawl controls
- Analytics and tracking
- Internal linking
- Content and metadata
- Everything else
A missed redirect on a key URL is more important than dozens of minor page issues.
Build the QA sample set first
Do not start with the homepage.
Create a sample set that reflects real risk:
- highest organic landing pages
- highest revenue products
- strongest WooCommerce categories or old collection equivalents
- backlink target URLs
- pages with custom metadata
- blog posts or guides that assist conversions
- discontinued products
- out-of-stock products
- old redirected URLs
- filter/tag/archive examples
- checkout and account paths
The sample set should include easy pages, awkward pages and pages that would hurt if they failed.
A QA checklist without a sample set becomes cosmetic testing.
If time is limited, prioritise high-value URLs over full coverage.
What good QA produces
A strong QA process produces:
- a defined sample set
- a clear log of issues
- prioritised fixes
- verified redirect behaviour
- confirmed tracking accuracy
- confidence in key page types
- a monitoring plan
If QA produces only a checklist, it has not been applied properly.
Pre-launch QA: redirects
For every P1 and P2 old URL, check:
- old URL returns expected redirect status
- destination is the most relevant Shopify page
- no redirect chain exists
- no homepage fallback is being used for important URLs
- destination page returns 200
- destination page is indexable where appropriate
- internal links point to the new URL, not the old URL
Redirects are not successful just because they resolve. They are successful when the destination satisfies the same commercial or informational intent.
If a P1 URL fails, stop and fix it before continuing QA.
If redirects work but destinations are weak, improve the page before launch.
Pre-launch QA: collections
Collections are often where migration value is lost.
Check important collections for:
- correct title and H1
- appropriate handle
- indexable status
- canonical target
- product relevance
- product ordering
- collection description or buying context
- internal links from navigation, guides and products
- no unwanted filter URLs being treated as main landing pages
A collection that is technically live but has no context, no internal support and weak product matching is not migration-safe.
Pre-launch QA: products
For important products, check:
- product title
- handle and URL
- description completeness
- variant structure
- price and availability
- images and alt text
- review transfer if relevant
- product schema output
- collection membership
- related product links
- redirects from old product URLs
The product import may pass while the product page still loses useful evidence.
Pre-launch QA: content and guides
If the old store used WordPress content, check more than products.
For blog posts, guides and pages, confirm:
- migration decision is recorded
- URL destination is mapped
- visible content transferred or intentionally consolidated
- internal links updated
- old media/embed dependencies checked
- metadata reviewed
- page is indexable if it should rank
- page supports a commercial path where relevant
Do not leave content migration until after launch if that content supports organic revenue.
Pre-launch QA: crawl and index controls
Check:
- robots.txt output
- sitemap URLs
- noindex rules
- canonical tags
- duplicate URL patterns
- password protection removed before launch
- staging URLs not indexed
- live domain resolves correctly
- important pages are crawlable
This is where small template mistakes become sitewide problems.
Pre-launch QA: analytics and conversion tracking
Check analytics before interpreting launch performance.
Confirm:
- GA4 receives traffic
- ecommerce events are tested where possible
- purchase event is visible after a test order if available
- Shopify analytics access works
- Search Console access exists
- paid pixels are checked
- form/resource conversion events are tested
- consent behaviour is understood
- launch annotation is prepared
A tracking failure after migration can waste days of SEO diagnosis.
If analytics is not working, do not interpret early performance.
Pre-launch QA: checkout and operations
SEO migration QA still needs to check commercial function.
Test:
- product add to cart
- variant selection
- cart updates
- discount codes if used
- shipping rules
- tax display
- payment methods
- confirmation page
- order email
- customer account flow where relevant
A perfect redirect map does not help if users cannot buy.
Launch-day QA
On launch day, check in this order:
- domain resolves correctly
- homepage loads
- collection sample loads
- product sample loads
- top redirects work
- checkout flow works
- analytics receives traffic
- sitemap is accessible
- robots/index rules are correct
- no major template/page rendering errors are visible
Do not let cosmetic issues interrupt P1 checks.
This is where most critical failures appear.
When to pause the launch
Not every issue should stop launch, but some should.
Pause or delay if:
- P1 redirects fail for important old URLs
- checkout or payment testing fails
- priority collections are noindex, blocked or broken
- analytics cannot record orders or basic traffic
- the live domain resolves inconsistently
- the sitemap, robots.txt or canonical output is clearly wrong
Proceed with a logged fix plan if:
- secondary metadata needs polishing
- low-priority internal links need cleanup
- non-critical images or copy need adjustment
- P3/P4 issues are owned and scheduled
The launch decision should come from risk, not pressure.
First 24 hours
Check:
- server responses
- 404s
- redirect failures
- conversion tracking
- checkout errors
- Search Console inspection for key URLs
- top organic landing page redirects
- paid traffic landing pages
- resource/download links if the site uses them
Log everything. Do not fix issues from memory.
First 14 days
Monitor by page type:
- collections
- products
- blog/guides
- resources
- old WooCommerce URLs
- redirect targets
- checkout/conversion events
Do not react to every daily fluctuation. Look for patterns: missing page types, failed redirects, tracking gaps, accidental noindex, or internal links still pointing to old URLs.
Monitoring is part of QA, not a separate task.
QA severity levels
Use a shared severity system:
| Severity | Meaning | Example |
|---|---|---|
| P1 | Launch/revenue/indexing blocker | Important pages noindexed, checkout broken, top redirects failing |
| P2 | Serious migration issue | Key collection weak, product redirects missing, analytics partially broken |
| P3 | Fix soon | Missing metadata on secondary pages, low-priority internal links |
| P4 | Backlog | Minor copy, image naming, non-critical presentation issues |
This stops the team treating every issue as urgent.
Minimum QA log fields
Use these columns:
- date found
- area
- URL
- old URL if relevant
- issue
- severity
- owner
- decision
- fix applied
- retest status
- notes
The QA log is your protection against launch confusion.
If QA results are not logged, assume issues will be missed.
Without logs, QA cannot be trusted.
What to do next
For an editable checklist, use the Migration QA Checklist.
For launch-day ownership, use the Launch Day Command Centre.
If redirects are the weak point, use the Shopify redirect mapping guide.
If crawl or indexing is unclear, use the Shopify migration crawl and indexing checks.
If analytics cannot be trusted, use the Shopify migration analytics tracking QA.
If traffic has already dropped, use the traffic drop after migration runbook before making more changes.
A Shopify migration does not fail because of one missed check.
It fails because uncertainty is allowed into the process.
QA is not there to confirm the store works.
It is there to prove that the important parts cannot fail.
Quick answer
Use migration QA to catch broken redirects, missing metadata, noindex mistakes, tracking failures and template issues before customers and search engines find them.
What you will do
- Run pre-launch and post-launch QA from the same evidence list.
- Assign ownership to SEO, developer and store teams.
- Reduce avoidable launch-day traffic loss.
What to check first
- Crawler export for the old site and Shopify staging site.
- Google Search Console page, query and indexing exports.
- GA4 annotations and landing-page reports.
- Shopify URL redirects.
- Redirect Mapping Sheet, Migration QA Checklist and Post-Migration Monitoring Sheet.
Work through it in this order
- Crawl the current site and export all indexable URLs.
- Export Search Console pages and queries for at least the last 16 months where available.
- Tag each old URL as protect, merge, replace, retire or investigate.
- Map protected URLs to the closest Shopify destination before launch.
- Copy or improve critical titles, descriptions, headings, content blocks and internal links.
- Test redirects, canonicals, sitemap output, robots rules and tracking on staging.
- Monitor Search Console, analytics and 404 logs for four weeks after launch.
Real-world notes
- The most common failure is redirecting old category URLs to the homepage because the Shopify collection structure was not ready.
- Traffic drops often look like ranking problems when the real issue is missing tracking, missing redirects or changed internal links.
- Blog URLs are easy to ignore during ecommerce migrations, but they often carry internal links and long-tail traffic.
Final checks
- Old URL crawl saved.
- Search Console export saved.
- Top landing pages mapped.
- Redirects uploaded and tested.
- Metadata for priority pages reviewed.
- Analytics and conversion tracking checked.
- Post-launch monitoring owner assigned.
Watch-outs
- If the old site has faceted URLs indexed, decide which should become Shopify collections and which should be retired.
- If products are discontinued during migration, redirect only where the replacement is genuinely useful.
- If the domain changes as well as the platform, follow a stricter site-move process and expect a longer stabilisation period.
Run QA on staging, repeat it immediately after launch, then monitor for four weeks.
Field questions
When should Shopify migration QA start?
Start before launch, once the Shopify structure and priority URLs are ready to test. Do not wait until the domain switch.
What should be checked first on launch day?
Check priority old URLs, redirects, top new pages, analytics, checkout, robots.txt, sitemap access and Search Console access first.
How long should post-launch QA continue?
At minimum, check daily for the first two weeks, then weekly for the first two months. High-value migrations should be monitored for a full quarter.
