BigCommerce Platform Migration SEO: Moving from Shopify, Magento, or WooCommerce

Every ecommerce platform stores URLs differently. Shopify prefixes everything with /collections/ and /products/. Magento nests categories four or five levels deep. WooCommerce lets store owners pick any permalink structure they want, which means you can’t assume anything. Migrating to BigCommerce without accounting for these structural differences kills organic traffic. We’ve seen stores lose 60% of their search visibility within 48 hours of a botched migration. The traffic doesn’t trickle back on its own.

This post covers the exact URL mapping patterns, redirect CSV formatting, and cache-layer behavior you need to handle when moving to BigCommerce. It’s not a generic replatforming overview. Our platform migration SEO guide covers the general principles. This is the BigCommerce-specific playbook, built from migrating stores with 200 products and stores with 40,000 SKUs. Every CSV template, every SQL query, and every admin panel screenshot reference here comes from production migrations we’ve executed through our BigCommerce development practice.

If you’re evaluating BigCommerce against Shopify for SEO specifically, read our BigCommerce vs. Shopify SEO comparison first. It’ll help you confirm the platform decision before you commit to the migration work below.

Shopify to BigCommerce: URL Mapping and Bulk Redirect Import

Shopify enforces a rigid URL structure that you can’t change. Every product lives at /products/product-handle. Every collection lives at /collections/collection-handle. Collection-filtered product URLs follow /collections/collection-handle/products/product-handle. Blog posts sit at /blogs/blog-name/post-handle. Pages use /pages/page-handle. None of these prefixes are optional.

BigCommerce uses flat URLs by default. A product page is just /product-name/. A category page is /category-name/. There’s no /products/ prefix unless you manually add one. This structural difference is the core of the mapping problem: you need to strip Shopify’s path prefixes and redirect the old prefixed URLs to BigCommerce’s flat equivalents.

Building the Product URL Map

Start by exporting all product URLs from Shopify. The Shopify admin’s CSV export (Products > Export) includes a Handle column. The full URL is /products/{handle}. Export this into a spreadsheet and build the mapping column.

BigCommerce product URLs default to /{product-name}/, where product-name is auto-generated from the product title during import. You can also set custom URLs during the import by populating the Product URL column in BigCommerce’s product CSV.

The mapping formula is straightforward. For every Shopify product URL, the redirect target strips /products/ and appends a trailing slash:

Shopify URL              BigCommerce URL
/products/blue-widget    /blue-widget/
/products/red-widget-xl  /red-widget-xl/
/products/copper-fitting /copper-fitting/

Keep the slug identical whenever possible. If your Shopify handle is blue-widget, make your BigCommerce product URL /blue-widget/. Matching slugs preserves any link equity pointing at those specific path segments. Changing slugs during migration compounds the SEO risk unnecessarily.

Building the Collection-to-Category Map

Shopify collections become BigCommerce categories. The URL shift follows the same prefix-stripping pattern:

Shopify URL                  BigCommerce URL
/collections/outdoor-gear    /outdoor-gear/
/collections/kitchen-tools   /kitchen-tools/
/collections/sale            /sale/

Shopify also generates collection-filtered product URLs like /collections/outdoor-gear/products/hiking-boots. These are alternate paths to the same product. Google often indexes both the filtered and unfiltered versions. You need redirects for both:

/collections/outdoor-gear/products/hiking-boots  ->  /hiking-boots/
/products/hiking-boots                            ->  /hiking-boots/

Miss the collection-filtered variants and you’ll see 404 errors stacking up in Search Console for weeks after launch. Shopify stores with 50 collections and 500 products can easily have 5,000+ collection-filtered URLs indexed by Google.

BigCommerce’s Bulk Redirect CSV Format

BigCommerce accepts bulk 301 redirect imports through the control panel at Server Settings > 301 Redirects. Click Import and upload a CSV file. The format is two columns with a header row:

/products/blue-widget,/blue-widget/
/products/red-widget-xl,/red-widget-xl/
/collections/outdoor-gear,/outdoor-gear/
/collections/outdoor-gear/products/hiking-boots,/hiking-boots/
/blogs/news/summer-sale-announcement,/blog/summer-sale-announcement/
/pages/about-us,/about-us/

No header row is needed. Each line is a pair: old path on the left, new path on the right, separated by a comma. Use relative paths (no domain). BigCommerce processes these as 301 permanent redirects.

A few constraints to watch for. BigCommerce limits the redirect import to 10,000 rows per CSV file. Stores with more than 10,000 redirects need multiple uploads. The system deduplicates automatically, so if you upload the same old URL twice with different targets, the last upload wins. Also, BigCommerce’s redirect engine is case-insensitive for matching, but it preserves the case of the target URL you specify.

One critical gotcha: BigCommerce won’t let you create a redirect if the old URL matches an existing live page. If you import a product with the URL /blue-widget/ and then try to create a redirect from /blue-widget/ to something else, the system rejects it. Always upload redirects after completing the product and category import, not before. The redirect engine checks for URL conflicts at the time of import.

Blog and Page Redirects

Shopify blog posts live at /blogs/{blog-name}/{post-handle}. BigCommerce’s native blog uses /blog/{post-title}/. Map accordingly:

/blogs/news/how-to-choose-widgets    ->  /blog/how-to-choose-widgets/
/blogs/updates/new-product-launch    ->  /blog/new-product-launch/

Shopify pages at /pages/{handle} typically map to BigCommerce web pages. BigCommerce lets you set custom URLs for web pages, so use the same slug with a trailing slash: /pages/about-us becomes /about-us/.

Magento 2 to BigCommerce: Rewrite Table Export and Category Flattening

Magento 2 migrations are the most complex platform-to-BigCommerce projects we handle. Magento’s URL system operates on two layers: internal system URLs and the URL rewrite table that maps clean paths to those internal routes. The internal URLs look like /catalog/category/view/id/42 and /catalog/product/view/id/1587. Nobody sees these in production because Magento’s url_rewrite database table maps them to clean paths like /outdoor-gear/camping/tents.html.

The .htaccess rewrite rules that power Magento’s clean URLs don’t transfer to BigCommerce. BigCommerce runs on its own server stack with Akamai CDN in front. There’s no .htaccess, no mod_rewrite, no server-level rewrite layer you can configure. All URL routing happens through BigCommerce’s application layer and its 301 redirect system.

Exporting Magento’s url_rewrite Table

Connect to your Magento 2 database and export the url_rewrite table. This table contains every URL mapping Magento knows about, including category URLs, product URLs, CMS page URLs, and custom rewrites merchants added manually.

SELECT request_path, target_path, redirect_type, entity_type, store_id
FROM url_rewrite
WHERE store_id = 1
  AND redirect_type = 0
ORDER BY entity_type, request_path;

Filter for redirect_type = 0 to get the primary (canonical) URL mappings. Rows with redirect_type = 301 or redirect_type = 302 are existing redirects within Magento. You’ll want those too, but process them separately.

The request_path column is what Google has indexed. That’s the left side of your redirect CSV. The right side is whatever URL you assign to the corresponding product or category in BigCommerce.

Handling the .html Suffix

Magento 2 appends .html to product and category URLs by default (configurable under Stores > Configuration > Catalog > Search Engine Optimization). A product URL in Magento might be /industrial-caster-wheel.html. BigCommerce doesn’t use file extensions in URLs. Your redirect needs to map the .html version to the clean BigCommerce URL:

/industrial-caster-wheel.html,/industrial-caster-wheel/
/outdoor-gear/camping/tents.html,/camping-tents/
/power-tools.html,/power-tools/

If the Magento store was configured to omit .html suffixes, your URLs will already be clean. Check the actual indexed URLs in Google Search Console’s Pages report, not what you think the configuration should produce. Magento stores change this setting over their lifetime, and some URLs retain the old format even after a configuration change because Magento doesn’t retroactively rewrite existing URL rewrites.

Category Tree Flattening

Magento supports unlimited category nesting depth. A store selling industrial supplies might have a structure like:

Hardware > Fasteners > Bolts > Hex Bolts > Stainless Steel Hex Bolts

That’s five levels deep. Magento generates a URL like /hardware/fasteners/bolts/hex-bolts/stainless-steel-hex-bolts.html. BigCommerce’s category system tops out at three levels. You physically cannot create a fourth level. For a deeper look at how BigCommerce handles category pages, including duplicate content and pagination, see our dedicated guide.

This means you need to flatten your category tree during migration. The approach we use:

1. Map Magento’s top two levels directly to BigCommerce’s first two levels.
2. Merge level 3 and below into BigCommerce’s third level, using combined names if needed.
3. Create redirects for every deep Magento category URL pointing to the appropriate flattened BigCommerce category.

In practice:

Magento (5 levels)                                          BigCommerce (3 levels)
Hardware > Fasteners > Bolts > Hex Bolts > SS Hex Bolts  -> Hardware > Fasteners > Hex Bolts
Hardware > Fasteners > Bolts > Carriage Bolts            -> Hardware > Fasteners > Carriage Bolts
Hardware > Fasteners > Screws > Wood Screws              -> Hardware > Fasteners > Wood Screws

The redirect CSV entries for these flattened categories:

/hardware/fasteners/bolts/hex-bolts/stainless-steel-hex-bolts.html,/hardware/fasteners/hex-bolts/
/hardware/fasteners/bolts/carriage-bolts.html,/hardware/fasteners/carriage-bolts/
/hardware/fasteners/screws/wood-screws.html,/hardware/fasteners/wood-screws/

Products that lived in deep Magento categories need redirects too. Magento often includes the full category path in product URLs: /hardware/fasteners/bolts/hex-bolts/m8-stainless-hex-bolt.html. That entire path redirects to the flat BigCommerce product URL: /m8-stainless-hex-bolt/.

Handling Magento’s Duplicate Product URLs

Magento generates multiple URL paths for the same product when it’s assigned to multiple categories. A single product might have:

/hardware/fasteners/m8-hex-bolt.html
/stainless-steel/m8-hex-bolt.html
/m8-hex-bolt.html

All three paths resolve to the same product page. Google may have indexed any or all of them. Export all of these from the url_rewrite table and create redirect entries for every variant. The SQL query to capture all product URL variants:

SELECT request_path
FROM url_rewrite
WHERE entity_type = 'product'
  AND store_id = 1
ORDER BY request_path;

Each row becomes a redirect pointing to the single BigCommerce product URL.

WooCommerce to BigCommerce: Permalink Audit and /shop/ Archive Handling

WooCommerce is the wildcard. Unlike Shopify and Magento, WooCommerce lets store owners configure permalink structures with complete freedom. The default product URL uses /?product=product-name (the “ugly” permalink). Most stores switch to a “pretty” permalink structure, but the specific format varies. Common patterns include:

/product/blue-widget/
/shop/blue-widget/
/store/products/blue-widget/
/blue-widget/  (when using "Post name" permalink with no product base)

Category URLs are equally variable:

/product-category/outdoor-gear/
/shop/category/outdoor-gear/
/category/outdoor-gear/

You cannot assume any specific structure. The first step in a WooCommerce-to-BigCommerce migration is auditing every URL that Google has actually indexed.

Auditing Indexed URLs

Pull the list of indexed URLs directly from Google Search Console. Go to Pages > Indexed, export the full list. This gives you the exact URLs Google knows about, not what your WordPress settings say they should be. WooCommerce stores that changed permalink structures mid-life often have both old and new URL formats indexed.

Cross-reference the GSC export with a Screaming Frog crawl of the live WooCommerce site. The crawl catches URLs that Google might not have indexed yet but that internal links point to. Combine both lists, deduplicate, and use the merged set as your redirect source.

Also export the wp_posts table from WordPress with post_type = 'product' and post_status = 'publish' to get every product’s post_name (slug). The redirect map uses these slugs as the basis for BigCommerce URLs.

Handling the /shop/ Archive Page

WooCommerce creates a /shop/ page that serves as the product archive. It lists all products (paginated). This page often ranks for broad commercial terms. BigCommerce doesn’t have a direct equivalent. The closest match is either a top-level category page or a brand page that lists everything.

Two approaches work:

Option A: Create a “Shop All” category in BigCommerce and assign all products to it. Set its URL to /shop/. Redirect /shop/ to /shop/ (same URL, no redirect needed). This preserves the URL and its ranking equity entirely.

Option B: If your BigCommerce store’s information architecture doesn’t include a “shop all” page, redirect /shop/ to your most relevant top-level category or to the homepage. This loses some specificity but avoids a 404.

Paginated WooCommerce shop pages (/shop/page/2/, /shop/page/3/) should redirect to the main /shop/ equivalent. BigCommerce handles pagination differently (query parameters like ?page=2), and Google’s current guidance treats paginated pages as individual pages rather than a series. Redirecting all pagination pages to the first page is acceptable here.

WooCommerce Product Variation URLs

WooCommerce variable products append query parameters for variations: /product/blue-widget/?attribute_pa_size=large&attribute_pa_color=red. These variation URLs sometimes get indexed, especially if the site uses plugins that generate unique URLs for each variation.

BigCommerce handles product options differently. Options don’t create separate URLs. All options live on the same product page. Redirect any indexed WooCommerce variation URLs to the parent BigCommerce product URL:

/product/blue-widget/?attribute_pa_size=large,/blue-widget/
/product/blue-widget/?attribute_pa_color=red,/blue-widget/

BigCommerce’s redirect engine matches query parameters. Include the full query string in the old URL column of your CSV.

WooCommerce-Specific Redirect CSV Example

/product/blue-widget/,/blue-widget/
/product/red-widget-xl/,/red-widget-xl/
/product-category/outdoor-gear/,/outdoor-gear/
/product-category/outdoor-gear/camping/,/outdoor-gear/camping/
/shop/,/shop-all/
/shop/page/2/,/shop-all/
/shop/page/3/,/shop-all/
/product/blue-widget/?attribute_pa_size=large,/blue-widget/
/my-account/,/login.php
/cart/,/cart.php

Note the WooCommerce system pages at the bottom. /my-account/ maps to BigCommerce’s /login.php. /cart/ maps to /cart.php. These aren’t SEO-critical pages, but inbound links and bookmarks will break without them.

Post-Migration Akamai Cache Purge

BigCommerce serves all storefronts through Akamai’s CDN. This is the detail that catches most migration teams off guard. Akamai’s edge servers cache HTTP responses aggressively. When your new BigCommerce store goes live with fresh products, categories, and redirect rules, the Akamai edge nodes closest to Google’s crawlers may still be serving cached 404 responses from URLs that didn’t exist minutes earlier.

Here’s the scenario that causes damage. You activate your BigCommerce store at 2:00 PM. Redirect CSV is uploaded. Products are imported. Everything looks correct when you test from your browser. But Google’s crawler hits your site from a different geographic edge node at 2:05 PM. That edge node hasn’t seen the new redirects yet. It serves a cached 404. Google records the URL as “Not found.” Your Search Console Coverage report lights up with soft 404 errors by the next morning.

This isn’t hypothetical. It happens on every BigCommerce migration where the team doesn’t purge the CDN cache immediately after go-live.

How to Purge the Akamai Cache

BigCommerce exposes a cache purge control in the admin panel. Navigate to Server Settings > Store Settings > Cache (the exact menu path can vary slightly between control panel versions). You’ll see options to purge page cache, image cache, or the entire CDN cache. Hit Purge All.

After purging, it takes Akamai 3 to 5 minutes to propagate the invalidation across all edge nodes globally. Don’t test your redirects from the live domain immediately after clicking purge. Wait at least 5 minutes, then test from multiple locations using a VPN or an external tool like Uptrends or Check-Host.

Timing the Migration Sequence

The correct sequence for a BigCommerce migration go-live is:

1. Import all products, categories, and content pages.
2. Upload the complete redirect CSV (all 301 redirects).
3. Verify redirects work by testing 20 to 30 sample URLs in the BigCommerce preview.
4. Point DNS to BigCommerce (or activate the domain in the BigCommerce control panel).
5. Immediately purge the entire Akamai cache via admin panel.
6. Wait 5 minutes.
7. Re-test sample redirects from external locations.
8. Submit the updated sitemap in Google Search Console.

Steps 4 and 5 should happen within the same 10-minute window. If you activate the domain and then wait hours before purging cache, Google may crawl dozens of URLs with stale 404 responses during that gap.

GSC Change of Address Workflow for Domain Migrations

Two migration scenarios exist: same-domain and different-domain. They require different Search Console workflows.

Same-Domain Migration

If you’re keeping the same domain (e.g., example.com stays example.com, just moving the platform from Shopify to BigCommerce), you do not need the Change of Address tool. Google sees the same domain. The redirects handle the URL path changes. Submit your new BigCommerce sitemap in the existing Search Console property, and Google recrawls the redirects organically.

Monitor the Coverage report daily for the first two weeks. Look specifically for:

• Soft 404 errors: pages that return 200 but display thin or empty content (often caused by template pages that haven’t been populated yet).
• Redirect errors: redirect chains (old URL redirects to an intermediate URL that redirects again) or redirect loops.
• Not found (404) errors: URLs you missed in your redirect map.
• Crawled but not indexed: pages where the new version doesn’t meet Google’s quality threshold.

Different-Domain Migration

If the domain is changing (e.g., oldstore.com to newstore.com), use Google’s Change of Address tool. You’ll need verified Search Console properties for both the old and new domains.

Steps:

1. Verify the new domain in Search Console.
2. Set up 301 redirects from every old domain URL to the corresponding new domain URL. These redirects live on the old domain’s server (not in BigCommerce’s redirect system, since BigCommerce only handles redirects within its own domain).
3. In the old domain’s Search Console property, go to Settings > Change of Address.
4. Select the new domain and submit.
5. Google validates that redirects are in place and begins transferring signals.

The signal transfer takes 2 to 6 months for most stores. Expect a temporary traffic dip of 10% to 30% during the first 4 weeks, even with perfect redirects. This is normal. Google reprocesses every URL, recalculates rankings, and gradually applies the old domain’s authority to the new one. Don’t panic and don’t make additional URL changes during this settling period.

Content Migration: Product Descriptions, Meta Data, and Images

URL redirects preserve link equity. Content migration preserves ranking signals. Google ranks pages, not domains. If your product page ranked for “industrial caster wheel” on Magento, it ranked because of the content on that page: the title tag, the meta description, the H1, the product description copy, the image alt text, and the structured data. All of that needs to transfer intact.

Title Tags and Meta Descriptions

Export every title tag and meta description from the source platform. In Shopify, these live in the product’s SEO section. In Magento 2, export from the catalog_product_entity_varchar table (attribute IDs for meta_title and meta_description). In WooCommerce, export from the wp_postmeta table (_yoast_wpseo_title and _yoast_wpseo_metadesc if using Yoast, or rank_math_title and rank_math_description for RankMath).

BigCommerce’s product import CSV accepts Page Title and Meta Description columns. Map these directly. Don’t let BigCommerce auto-generate them from product names. Auto-generated titles are generic and won’t match what Google has indexed. A title tag mismatch can cause Google to re-evaluate the page’s relevance, and re-evaluation during a migration is a compounding risk you don’t need.

Product Descriptions

BigCommerce stores product descriptions in HTML. Most source platforms do the same. The transfer is straightforward, but watch for platform-specific shortcodes and embedded media.

Shopify descriptions may contain Liquid template tags. WooCommerce descriptions may include WordPress shortcodes like or . Magento descriptions sometimes reference widget directives like {{widget type="catalog/product_widget_link"}}. None of these render in BigCommerce. Scan every description for non-HTML markup and replace it with standard HTML before import.

A regex scan for non-HTML markup saves hours:

# Find Shopify Liquid tags
grep -P '\{\{.*?\}\}' products.csv

# Find WordPress shortcodes
grep -P '\[.*?\]' products.csv

# Find Magento widget directives
grep -P '\{\{widget.*?\}\}' products.csv

Replace these with equivalent HTML or remove them entirely before uploading to BigCommerce.

Image Migration

BigCommerce hosts product images on its own CDN (served via cdn11.bigcommerce.com or the store’s custom domain). You can’t point BigCommerce to external image URLs. Every product image needs to be downloaded from the source platform and re-uploaded to BigCommerce.

BigCommerce’s product import CSV accepts an Product Image URL - 1 column (and - 2, - 3, etc. for additional images). During import, BigCommerce fetches these URLs and downloads the images to its CDN. This means you can point the CSV at the old platform’s image URLs during import, and BigCommerce handles the download. But the source store must remain live while the import runs. If you shut down Shopify before BigCommerce finishes downloading all images, you’ll end up with broken product images.

Image alt text matters for SEO and it often gets lost during migration. Export alt text from the source platform and include it in the BigCommerce import CSV using the Product Image Alt Text - 1 column. Don’t leave this blank. Alt text contributes to image search rankings and web accessibility compliance.

Category Structure Mapping and BigCommerce’s 3-Level Limit

BigCommerce supports a maximum of three category levels. Top level, subcategory, and sub-subcategory. That’s it. Magento stores with five or six levels of nesting need to flatten their hierarchy before migration. Even Shopify collections are flat (one level), so moving from Shopify to BigCommerce actually gives you more depth, not less.

The flattening decision isn’t purely technical. It affects your BigCommerce SEO architecture. Deeper category nesting distributes internal link equity across more levels. Flatter structures concentrate authority on fewer, stronger category pages. For most stores, the 3-level limit is actually a net positive for SEO because it forces consolidation.

Mapping Strategy

Build a spreadsheet with four columns: Source Category Path, Source URL, BigCommerce Category Path, BigCommerce URL. Walk through every source category and decide where it lands in the 3-level BigCommerce structure.

Source Path (Magento)                              BigCommerce Path             BigCommerce URL
Electronics                                        Electronics                  /electronics/
Electronics > Computers                            Electronics > Computers      /electronics/computers/
Electronics > Computers > Laptops                  Electronics > Computers > Laptops    /electronics/computers/laptops/
Electronics > Computers > Laptops > Gaming Laptops Electronics > Computers > Laptops    /electronics/computers/laptops/
Electronics > Computers > Laptops > Business       Electronics > Computers > Laptops    /electronics/computers/laptops/

In this example, “Gaming Laptops” and “Business” (levels 4 and 5) merge into the “Laptops” category at level 3. Products from those deep subcategories get reassigned to the level-3 parent. You can use BigCommerce’s product filtering (faceted search) to let customers filter by use case (gaming, business) without needing separate category pages.

The redirect CSV captures the old deep URLs:

/electronics/computers/laptops/gaming-laptops.html,/electronics/computers/laptops/
/electronics/computers/laptops/business.html,/electronics/computers/laptops/

Multiple old URLs redirecting to the same new URL is fine. Google handles many-to-one 301s without issue. The receiving page gains the combined link equity from all redirecting sources.

Category Descriptions and SEO Content

Don’t forget category page content. Magento and WooCommerce both support rich HTML descriptions on category pages. BigCommerce does too, and the category description field accepts HTML. Export these descriptions and import them alongside the category structure. Category descriptions often contain keyword-rich content that supports rankings. Losing that content during migration drops ranking signals that took months or years to build. For a thorough understanding of category page SEO on BigCommerce, including pagination and canonical handling, read our guide to BigCommerce category page duplicate content.

Post-Migration Crawl Audit Checklist

Run this checklist within 24 hours of go-live. Every item catches a specific class of migration failure.

1. Full Site Crawl with Screaming Frog

Crawl the new BigCommerce store. Compare the crawl against the pre-migration crawl of the old platform. Look for:

• Pages on the old site that have no corresponding page or redirect on the new site.
• Status code mismatches (pages that returned 200 on the old site but return 404 or 500 on BigCommerce).
• Title tag and H1 differences between old and new pages.
• Missing canonical tags or incorrect canonical URLs.

2. Redirect Chain Audit

Feed your complete redirect list into Screaming Frog’s List Mode. Crawl every old URL and verify that each one returns a single 301 to the correct new URL. Redirect chains (301 > 301 > 200) dilute equity and slow crawl processing. Redirect loops (301 > 301 > 301 > back to start) result in complete crawl failure for those URLs.

Common chain scenario: you imported a redirect from /products/widget to /widget/, but BigCommerce’s internal routing also redirects /widget (no trailing slash) to /widget/. If Google’s crawl hits /products/widget, it goes 301 to /widget/ (one hop, clean). But if a backlink points to /products/widget/ (with trailing slash) and your CSV only mapped the version without the trailing slash, that URL might 404 instead of redirecting. Test both slash variants.

3. XML Sitemap Validation

BigCommerce auto-generates an XML sitemap at /xmlsitemap.php. Verify that:

• Every product, category, and content page appears in the sitemap.
• No old platform URLs appear (they shouldn’t, since BigCommerce generates its own).
• The sitemap URL count roughly matches your expected page count.
• All sitemap URLs return 200 status codes (crawl the sitemap in Screaming Frog).

Submit the new sitemap in Google Search Console immediately after go-live. If the old sitemap is still accessible (e.g., at /sitemap.xml on the old platform), remove it or redirect it to the new sitemap URL.

4. Structured Data Validation

Spot-check 10 product pages, 5 category pages, and the homepage in Google’s Rich Results Test. Verify that Product schema, BreadcrumbList schema, and Organization schema render correctly. The BigCommerce SEO guide details the full structured data implementation. Migration is a common point where schema breaks because template references change between platforms.

5. Internal Link Audit

Crawl the site and check for internal links that still point to old platform URLs. BigCommerce’s product and category descriptions may contain hardcoded links to old URLs (e.g., a product description linking to /collections/outdoor-gear instead of /outdoor-gear/). These internal redirects waste crawl budget and dilute link equity. Find them and update the href values directly in BigCommerce’s admin.

6. Robots.txt and Crawl Directives

BigCommerce generates its own robots.txt at /robots.txt. Review it to ensure no critical paths are blocked. BigCommerce’s default robots.txt blocks certain admin and checkout paths, which is correct. Verify that product pages, category pages, and blog posts are crawlable. If the old platform had custom robots.txt rules (common in Magento), confirm they’re no longer needed or have been replicated in BigCommerce’s configuration.

7. Google Search Console Coverage Monitoring

Check the Coverage report daily for the first 14 days post-migration. Google typically recrawls a small store (under 1,000 pages) within a week. Larger stores (10,000+ pages) take 2 to 4 weeks for full recrawl. Expect a temporary spike in “Not found (404)” errors as Google discovers old URLs that redirect. These errors should resolve within days as Google processes the 301s and updates its index.

Realistic Migration Timelines by Store Size

Migration timelines depend on product count, content complexity, customization depth, and the source platform. These are realistic estimates for a team that has done BigCommerce migrations before. First-time migrations take longer.

Small Store: Under 500 Products

Total timeline: 2 to 4 weeks.

• Week 1: Product and category data export from source platform. Content audit. URL mapping spreadsheet. BigCommerce store setup and theme selection.
• Week 2: Product import, category creation, redirect CSV preparation. Content migration (descriptions, meta data, images). Theme customization for SEO elements (schema, canonical tags, heading structure).
• Week 3: Staging review, redirect testing, stakeholder approval. DNS cutover, Akamai cache purge, sitemap submission.
• Week 4 (buffer): Post-launch monitoring, bug fixes, coverage report review. Address any 404 errors or redirect issues found in Search Console.

A 200-product Shopify store with clean data and no custom content can migrate in as little as 10 days. A 500-product WooCommerce store with custom shortcodes in every description takes the full 4 weeks.

Medium Store: 500 to 5,000 Products

Total timeline: 4 to 8 weeks.

• Weeks 1-2: Complete data export, URL audit (GSC + crawl), content inventory. Build the full redirect map. Identify data quality issues (missing images, duplicate products, broken descriptions).
• Weeks 3-4: Staged product import (batch by category to catch errors early). Category structure finalization. Redirect CSV creation and validation. Content cleanup (shortcode removal, HTML sanitization).
• Weeks 5-6: Full staging review. Load testing if the store handles high traffic. Theme QA for SEO elements across all page types. Redirect testing at scale (automated scripts checking every redirect in the CSV).
• Weeks 7-8: Go-live window, cache purge, monitoring. Two-week post-launch monitoring period for Search Console issues.

The biggest variable here is data quality. A Magento 2 store with 3,000 products and a clean database migrates faster than a WooCommerce store with 1,000 products and five years of plugin-generated garbage in the postmeta table.

Large Store: 5,000+ Products

Total timeline: 8 to 16 weeks.

Large store migrations add complexity in three areas: redirect volume (often exceeding 50,000 URLs when you account for category-filtered product URLs and variation pages), content volume (thousands of product descriptions that need shortcode and widget cleanup), and stakeholder coordination (multiple teams touching catalog data, marketing content, and design simultaneously).

• Weeks 1-3: Full platform audit. Catalog data export and normalization. URL inventory across all page types. Redirect strategy documentation. BigCommerce infrastructure provisioning (custom SSL, CDN configuration).
• Weeks 4-6: Iterative product imports (batch sizes of 500 to 1,000). Category tree finalization. Content migration with automated cleanup scripts. Image migration (can take days for stores with 50,000+ images).
• Weeks 7-10: Redirect CSV assembly and validation. Staged redirect upload (10,000-row batches). End-to-end testing of all SEO elements. Performance benchmarking.
• Weeks 11-12: Soft launch to limited traffic (if possible). Final redirect validation. Team training on BigCommerce admin.
• Weeks 13-16: Full launch, cache purge, monitoring. Extended post-launch period for large stores because Google’s recrawl takes longer.

Stores with 20,000+ products should plan for at least 12 weeks. Stores with 50,000+ products, extensive Magento customization, or multi-storefront setups often need 16 weeks. Rushing a large migration to meet an arbitrary deadline is the single most common cause of SEO traffic loss we see. The redirect map alone for a 50,000-SKU store takes 2 to 3 weeks to build and validate properly.

Frequently Asked Questions

Does BigCommerce automatically create 301 redirects when I change a product URL?

Yes. If you change a product URL in the BigCommerce admin, the platform automatically creates a 301 redirect from the old URL to the new one. This only applies to URL changes made after the product exists in BigCommerce. It doesn’t help with migration redirects from other platforms. You need to upload those manually via the bulk redirect CSV import.

How many 301 redirects can BigCommerce handle?

BigCommerce doesn’t publish a hard limit on total redirects. We’ve deployed stores with over 80,000 active redirects without performance issues. The bulk import tool accepts up to 10,000 rows per CSV file, but you can upload multiple files. Performance impact from large redirect tables is minimal because BigCommerce’s redirect engine uses indexed lookups, not linear scans.

Will my Google rankings drop during a BigCommerce migration?

A properly executed migration with complete 301 redirect coverage, matching content, and correct technical SEO implementation should see minimal ranking impact. Most stores experience a 5% to 15% traffic dip during the first 1 to 2 weeks as Google reprocesses the redirects. Traffic typically recovers fully within 4 to 6 weeks. Migrations that skip redirects, lose content, or break structured data see much larger drops that can take months to recover.

Can I migrate from multiple platforms to BigCommerce at the same time?

It’s technically possible but significantly more complex. Some businesses run Shopify for their main store, WooCommerce for a blog with integrated products, and a separate Magento instance for B2B. Consolidating all three into BigCommerce means building three separate redirect maps and merging three product catalogs. Prioritize migrating one platform at a time if your timeline allows it. If you must migrate simultaneously, treat each source platform as an independent redirect project with its own CSV file and validation process.

What happens to external backlinks pointing to old platform URLs after migration?

External backlinks follow the 301 redirects. When a referring site links to /products/blue-widget and that URL 301-redirects to /blue-widget/ on BigCommerce, Google transfers the link equity to the new URL. The redirect needs to remain active permanently. Don’t remove 301 redirects after migration, even months later. Backlinks pointing to the old URLs continue to send referral traffic and equity through the redirects indefinitely. Removing them means those backlinks hit 404 pages and their value disappears.