TL;DR: A migration changes your URLs, and every old URL that Google indexed needs a 301 redirect to its new address or the ranking attached to it disappears. Map every product, category, brand, blog, and filter URL before launch, import the redirects into BigCommerce in bulk, and watch Google Search Console for four to twelve weeks after go-live. Done right, organic traffic carries through with no measurable drop.
Here is the question that decides how a replatform ends: when your old URLs stop existing, does the ranking they earned move to the new pages, or does it evaporate? A 301 redirect is the mechanism that moves it. Skip that step, and a store that ranked on page one for hundreds of product and category terms can wake up on launch day with those pages returning 404 Not Found, the rankings gone, and the traffic with them. Get it right, and the migration is invisible to Google: same equity, new platform.
This guide is written for the two people who own that outcome. If you run the store, you want to know what is at stake and how to tell your developer or agency did the job correctly. If you are the one building the redirect map inside BigCommerce, you want the exact steps, the URL types that get missed, and the edge cases that turn a clean migration into three months of recovery work. Both readers are served here, in order, from the strategy down to the control-panel clicks.
What a 301 Redirect Does During a BigCommerce Migration
A 301 redirect is a permanent server instruction that sends anyone (a shopper, a search crawler, or a link) from an old URL to a new one, and tells search engines to transfer the old page’s ranking signals to the destination. The 301 is the HTTP status code for “moved permanently.”
Every page you have ever ranked has a URL, and that URL is what Google stores in its index. When you migrate to BigCommerce from Volusion, Magento, Shopify, or a custom build, the platform generates its own URL structure. Product slugs change, category paths change, and the file extensions your old platform used often disappear. The page content may be identical, but to a search engine the address is new, and the old address now points to nothing.
A 301 redirect closes that gap. During a BigCommerce migration, a 301 redirect maps each old URL to its new BigCommerce address so rankings transfer with it. It maps a legacy URL such as old-store.com/shop/blue-widget-123 to its new home at new-store.com/blue-widget/ so that the equity Google associated with the old URL, the backlinks, the ranking history, the click data, flows to the new page. Google has stated that 301 redirects pass ranking signals and are the correct tool for a permanent move. Without the redirect, the new page starts from zero, and the old page becomes a dead end that Google eventually drops from the index.
Redirects, more than theme design or app selection, decide if organic traffic survives the move. A beautiful new BigCommerce store that returns 404s for every legacy URL throws away years of SEO work on launch day. The redirect map carries the old store’s authority onto the new one.
301 vs 302 vs 307: Which Redirect to Use
For a migration, always use a 301, the permanent redirect. A 302 or a 307 signals a temporary move, so Google keeps the old URL indexed and stalls the transfer of its ranking to the new page. The redirect type you choose tells search engines how to treat the move, and the wrong type is a common, damaging migration mistake.
A 302 or a 307 tells Google the original URL will return, so it keeps the old URL in the index and is slow to transfer ranking signals to the destination. Developers reach for 302 because it is often the framework default, and on a migration that default quietly stalls recovery for months. Confirm every migration redirect resolves as a 301 Moved Permanently.
| Code | Meaning | Passes ranking signals? | Use for a migration? |
|---|---|---|---|
| 301 | Moved permanently | Yes, fully | Yes, this is the correct code |
| 308 | Permanent redirect (method preserved) | Yes, like a 301 | Fine, though 301 is the standard choice |
| 302 | Found (temporary) | Slowly, and keeps the old URL indexed | No |
| 307 | Temporary redirect (HTTP/1.1) | Treated as temporary | No |
| 410 | Gone (page removed on purpose) | Signals permanent removal | Only for pages with no successor |
The 410 in that table matters more than migration guides usually admit, and it has its own section below. For now, the rule is simple: a page that has a home on the new store gets a 301, and a page that is genuinely gone with no equivalent gets a 410.
What Skipping Redirects Costs Your Rankings
When legacy URLs return 404 because no redirect exists, three things happen at once, and they compound. First, the ranking pages vanish from search results as Google recrawls and finds them dead, so the terms they ranked for stop sending traffic. Second, any backlinks pointing at those old URLs now point at error pages, so the authority those links passed is stranded. Third, Google wastes crawl budget hitting dead URLs across your site, which slows how fast it discovers and ranks the new pages.
The damage scales with how much you ranked before. A store with a few dozen indexed pages might absorb the hit. A catalog with thousands of indexed product and category URLs, each carrying its own ranking history, can lose the majority of its organic traffic in a matter of weeks. Recovery is possible, but it means rebuilding the redirect map after launch under pressure, waiting for Google to recrawl, and accepting lost revenue in the gap. Doing the map before launch costs a fraction of the time and none of the revenue.
Optimum7 has run this exact scenario across enterprise BigCommerce migrations. On the LCE Performance move from Volusion to BigCommerce, comprehensive 301 redirects with preserved metadata carried 100% of the store’s SEO equity through a migration of more than 273,000 orders and 6,700 products. The same held on the B2B move for Omnimax USA to BigCommerce: full 301 coverage and no measurable organic disruption at launch. Both full case studies are further down this page. The point here: the difference between a traffic collapse and a clean move is the redirect map, and nothing else in the migration substitutes for it.
Picture the two outcomes on one product page. A category page ranks third for a commercial term and sends 2,000 organic visits a month. With a 301 in place, a shopper and Googlebot both land on the new BigCommerce category, the ranking holds within a few weeks, and the 2,000 visits continue. With no redirect, that URL returns a 404, Google drops it from the index over the following weeks, the position is gone, and the 2,000 visits go with it until the page is rebuilt and re-earns the ranking from scratch. Multiply that across every ranking URL in the catalog, and the redirect map is the single line item that decides the revenue outcome of the whole project.
How to Build Your BigCommerce Redirect Map
The redirect map is a spreadsheet with two columns: every old URL on the left, and the new BigCommerce URL it should point to on the right. Building it well is the whole job. A map that covers the URLs you remember and misses the ones you forgot is why migrations lose traffic. Inventory the old site by machine, by crawling it, so nothing rests on memory.
Step one: inventory every URL that exists
Pull your URL list from three sources and combine them; each source alone leaves gaps. Crawl the live old site with a tool like Screaming Frog to capture every internal URL. Export the last twelve to sixteen months of pages from Google Search Console so you capture URLs that earn organic clicks even with few internal links pointing at them. Add your old XML sitemap and any top-landing-page export from analytics. De-duplicate the combined list; that is your left column.
Step two: categorize by URL type
Ecommerce URLs span several types, and each type maps differently. Sorting the inventory into these buckets stops pages from slipping through. The buckets below apply to almost every store.
Step three: match each old URL to its best destination
The destination should be the closest equivalent page. Redirect a product to the same product, a category to the same category. When there is no exact match, go up one level: a discontinued product redirects to its parent category, a retired subcategory to its parent. Redirecting everything to the homepage is the mistake to avoid, because Google treats a redirect to an irrelevant page as a soft 404 and passes little to no equity. Relevance of the destination is what preserves the ranking.
Discontinued and Out-of-Stock Products: 301 or 410?
Migrations get this decision wrong more than any other, and it is worth getting right because it affects hundreds or thousands of URLs. A discontinued product has no matching page on the new store, so what should its old URL return? The answer depends on two things: if the product will return, and if a close alternative exists.
Out-of-stock and discontinued are different cases. A product that is temporarily out of stock keeps its URL live on the new store and stays in place, because the page still exists and will sell again. The redirect decision applies only to products that are permanently gone, and the choice for those is a 301 to a relevant page or a 410 Gone, the status code that tells Google a page was removed on purpose.
A blanket “301 everything to the homepage” fails because Google reads an irrelevant redirect as a soft 404 and gives the destination no credit. A handful are harmless. Thousands, all pointing at the homepage, dilute the signal and leave the retired products effectively unhandled. Match each discontinued URL to a relevant destination, or use a clean 410 where nothing fits; that is the difference between a tidy migration and a long tail of soft 404s in Search Console.
URL Changes to Expect From Your Old Platform
The left column of your redirect map, the old URLs, looks different depending on the platform you are leaving, and knowing the pattern in advance tells you where the tricky mappings will be. The method stays the same across every source: inventory, categorize, map, and test. The platform only changes the shape of the old URLs you are mapping from.
| Leaving | Typical old URL pattern | Redirect watch-out |
|---|---|---|
| Volusion | Product and category URLs tied to internal numeric IDs | ID-based URLs have no readable equivalent; map each one from an exported ID-to-product list |
| Magento | Deep category-path URLs, often with a .html suffix, plus layered-navigation filter URLs at scale | Drop the .html suffix cleanly and consolidate filter URLs to their parent category |
| Shopify | /products/ and /collections/ prefixes, plus duplicate /collections/x/products/y paths | Each duplicate collection-product path needs a redirect to the single BigCommerce product URL |
| WooCommerce | /product/ and /product-category/ slugs, with dated blog permalinks | Match the shop base path and map dated blog permalinks individually |
ID-based platforms like Volusion are the ones to plan for early, because a numeric product URL gives Google nothing to match against on its own; the redirect is the only link between the old ID and the new readable slug. Platforms with a suffix convention, such as Magento and its .html endings, need the whole set remapped even when the slug is otherwise identical, because the suffix change alone makes every URL new to Google. Confirm the pattern for your source platform before you build the map, and the mapping work becomes mechanical.
How to Set Up 301 Redirects in BigCommerce
BigCommerce handles redirects natively in the control panel, so a migration rarely needs a third-party app for this. There are three methods, and a migration uses all three: automatic redirects for slug changes you make inside BigCommerce, single manual redirects for one-off fixes, and a bulk CSV import for the full migration map. Enterprise stores add a fourth, the API, for programmatic control.
| Method | Best for | Where |
|---|---|---|
| Automatic | Slug edits made inside BigCommerce after launch | Created for you when a URL changes |
| Single manual | One-off fixes and post-launch corrections | Settings → 301 Redirects |
| Bulk CSV import | The full migration map, hundreds to thousands of rows | 301 Redirects → Import |
| API | Enterprise and programmatic sync | REST Admin redirect import job |
Create a single 301 redirect
In the control panel, go to Settings and open the 301 Redirects page. Add a redirect, enter the old path in the “Old URL” field, and set the destination to either a page you pick from the store (product, category, or content page) or a manual URL. Save. BigCommerce now serves a 301 from that old path to the destination. This is the right tool for a handful of corrections; for a migration map you want the bulk import.
Bulk import the migration map by CSV
This is how the full redirect map goes live. Prepare a CSV with two columns, Old URL and New URL, one redirect per row. In the control panel, open Settings → 301 Redirects, click Import, choose your file, and if your CSV has a header row, check This file contains headers so BigCommerce does not treat the labels as a redirect. Run the import; the page reloads with your redirects in place. Test a sample of live URLs immediately after to confirm each returns a 301 to the right destination.
Automatic redirects and the API
After launch, when you edit a product or category slug inside BigCommerce, the platform can create the 301 from the old slug to the new one for you, so ordinary content edits do not silently break links. For large or frequently changing catalogs, the BigCommerce REST Admin API exposes a redirect import job that lets a developer manage the full redirect set programmatically, which is how enterprise stores keep redirects in sync with an external product feed.
Redirect Chains, Loops, and Soft 404s
A redirect map can be complete and still be slow or broken in ways that cost rankings. The three problems to catch are chains, loops, and soft 404s. On moves off a platform that already ran its own redirects, like the Volusion-to-BigCommerce migrations Optimum7 handles, a pre-launch crawl routinely surfaces legacy-on-legacy chains stacked under the new map. Each problem has a clear fix, and each is easy to miss without that crawl.
Redirect chains
A chain is when URL A redirects to B, which redirects to C. This happens on migrations because an old URL already had a redirect on the previous platform, and the new map adds another hop on top. Each hop adds load time and bleeds a little ranking signal, and long chains can stop Google from following through to the destination. The fix is to flatten every chain so the original URL points directly at the final destination in one hop. Crawl the redirect map and rewrite any A to B to C as A straight to C.
Redirect loops
A loop is when A redirects to B and B redirects back to A, so the page never resolves and the browser shows an error. Loops usually come from a mistake in the map or a conflict between a manual redirect and an automatic one. A pre-launch crawl on staging catches loops before shoppers or crawlers ever hit them; fix the conflicting rule so each URL has exactly one forward path.
Soft 404s
A soft 404 is a page that returns a “success” status but shows no real content, or a redirect to an irrelevant page that Google decides to treat as an error. On migrations, the two common causes are redirecting discontinued products to the homepage and thin category pages that lost their products. Google Search Console reports soft 404s under the Page indexing report; the fix is to point the redirect at a relevant page or return a proper 404 or 410 so the signal is honest.
HTTPS, WWW, and Cross-Domain Moves
Product and category redirects get the attention, and two lower-level moves get forgotten. Both change the URL that Google sees, so both need handling or the redirect map leaks equity at the root.
First, protocol and subdomain. Every version of your domain should resolve to one canonical version through 301s: http to https, and the non-preferred host to the preferred one (either www or the bare domain, pick one and enforce it). If both a www and non-www version of a page respond with 200, you split signals across duplicates. Confirm the canonical version is consistent across the old and new store.
Second, changing domains. If the migration also moves to a new domain, the per-URL 301 map still applies, and you add one more step: use the Change of Address tool in Google Search Console to tell Google the whole site moved. Google’s own guidance is to keep the 301s in place for at least a year so the signals fully transfer. The tool speeds recognition of a full-site move; the redirects do the actual work of carrying each page’s equity.
Find and Fix 404s Before You Launch
The best time to catch a broken redirect is on staging, before Google or a customer sees it. Point a crawler at your list of old URLs and confirm each one resolves with a single 301 to a live 200 page. Anything that returns a 404, a 302, or a chain goes back on the fix list. This pre-launch pass is the cheapest insurance in the whole migration.
Run the crawl in list mode against your old-URL inventory so you are testing the exact addresses Google has indexed. Internal links alone would miss URLs that rank but sit unlinked on the site. Sort by status code and work top down: fix every 404 first, then flatten every chain, then confirm the 302s are meant to be 302s (almost none should be). When the list is all single-hop 301s to 200 pages, the map is launch-ready. Keep the crawl file; it becomes your post-launch baseline.
The First 12 Weeks After Launch
Launch begins the window where you confirm the move worked. Google needs time to recrawl every old URL, follow the redirect, and reassign the ranking. Expect some position movement in the first few weeks even on a clean migration, then expect it to settle. What you watch during this window tells you when to act.
Week one: confirm nothing is dead
Submit the new XML sitemap in Search Console and recrawl your old-URL list live. Check the Page indexing report daily for a spike in 404s or soft 404s, which would mean a redirect is missing or misfiring. Watch server logs or analytics for real 404 hits from Googlebot and from customers, and add single manual redirects for anything that slipped through.
Weeks two to four: watch the crawl and the rankings
Google is recrawling in earnest now. In Search Console, the old URLs should start showing as redirected and the new URLs as indexed. Track your top commercial keywords; a temporary dip as pages reshuffle is normal, and it should trend back toward the prior positions. Keep clearing any new 404s and soft 404s as they surface.
Weeks five to twelve: confirm recovery
By this point, indexed new URLs should be steady and organic traffic should be at or above the pre-migration baseline. Compare clicks and impressions in Search Console against the same period before launch. If a specific set of pages has not recovered, it usually traces back to a missing redirect, a soft 404, or a chain; the diagnosis is the same as before, applied to the pages that lag. Keep the redirects live long after this window closes.
Your BigCommerce Migration Redirect Checklist
A BigCommerce migration redirect checklist covers seven things: the URL inventory, categorization by type, mapping each URL to its new destination, the bulk CSV import, a staging crawl, canonical setup, and twelve weeks of post-launch monitoring. Work through it before launch and in the first week after; it condenses everything above into a sequence you can hand to whoever owns the migration.
Before launch
Launch week and after
How Optimum7 Preserves SEO Equity in a Migration
The methods above are the same ones Optimum7 uses on enterprise BigCommerce migrations. On the LCE Performance project, an automotive performance retailer moved from Volusion to BigCommerce with a catalog and order history large enough that any redirect gap would have been expensive. The team built a comprehensive 301 redirect map with metadata and structured data preserved, and the store’s search visibility carried through the move intact.
The pattern repeats on B2B moves. On the Omnimax USA migration to BigCommerce B2B Edition, Optimum7 implemented 301 redirects across all legacy product, category, and page URLs, with no measurable organic search disruption at launch. The common thread across both is a complete redirect map, tested before launch and watched after. If you are planning a move, the Optimum7 ecommerce migration team builds and tests this map as part of the migration, and our SEO services team handles the post-launch monitoring. For the wider picture beyond redirects, the BigCommerce migration and replatforming guide covers the full project, and how SEO works explains why the equity transfer matters. For the technical foundations, see technical SEO for beginners.
Frequently Asked Questions
How long should you keep 301 redirects after a migration?
Keep them for at least a year, and ideally indefinitely. Google recommends holding 301s for a permanent move for a minimum of a year so ranking signals fully transfer. Because backlinks to old URLs can persist for years, deleting the redirects later reintroduces 404s and loses the equity you preserved, so the safe practice is to keep the map live for the life of the store.
How long does a 301 redirect take to work?
The redirect itself works instantly; a visitor hitting the old URL lands on the new page right away. What takes time is Google recrawling the old URL, following the redirect, and reassigning the ranking, which usually takes several weeks and typically settles within about twelve weeks. The speed depends on how often Google crawls your site and the size of the migration.
How long until Google recognizes that my whole site moved?
For a full-site or domain move, recognition typically takes a few weeks to a few months as Google recrawls everything. Submitting the new sitemap and using the Change of Address tool in Search Console speeds it up. Traffic on a clean migration with complete redirects generally settles back to baseline within about twelve weeks.
Do 301 redirects pass full link equity?
Google has stated that 301 redirects pass ranking signals and that no PageRank is lost through a 301 used for a legitimate permanent move. The equity transfers as long as the redirect points to a relevant destination. An irrelevant redirect, such as a discontinued product sent to the homepage, is treated as a soft 404 and passes little value.
Can I bulk-import redirects in BigCommerce?
Yes. BigCommerce supports a bulk CSV import on the 301 Redirects page, with one row per redirect and columns for the old and new URLs. The import only creates new redirects; it cannot update existing ones, so to change redirects already in the store you export and delete them first, then re-import the corrected file.
Should discontinued products get a 301 or a 410?
Use a 301 to a replacement product or the parent category when a relevant destination exists, especially if the product holds backlinks or rankings. Use a 410 Gone only when the product is permanently removed, has no relevant destination, and carries no equity worth preserving. A blanket redirect of every discontinued product to the homepage creates soft 404s and should be avoided.
What is a redirect chain and why does it hurt SEO?
A redirect chain is when one URL redirects to a second, which redirects to a third, so the original URL reaches the final destination only after several hops. Chains add load time, bleed a small amount of ranking signal at each hop, and long chains can stop crawlers from reaching the destination. Flatten every chain so the original URL points directly to the final page in a single 301.
Does BigCommerce create redirects automatically?
When you edit a product or category slug inside BigCommerce after launch, the platform can create a 301 from the old slug to the new one automatically, so routine content edits do not break existing links. For the migration itself, you still build and import the full redirect map, because BigCommerce cannot know the URL structure of your previous platform.
Will 301 redirects slow down my site?
A single 301 adds a small, negligible amount of load time as the browser follows one hop. The performance problem comes from redirect chains, where a URL passes through several hops before resolving, adding delay at each step. A clean map with one 301 per old URL keeps the impact minimal, which is why flattening chains is part of the pre-launch checklist.
Is there a limit on 301 redirects in BigCommerce?
BigCommerce does not publish a hard limit on the number of 301 redirects, and the bulk CSV import and the API handle catalogs with thousands of URLs. For a very large migration, split the map into batches for the import and verify each batch resolves correctly before moving on, so a single malformed row does not stall the whole file. Keep a master copy of the full map outside BigCommerce as your source of truth, since the bulk import creates redirects but does not give you a versioned history of the set.
About the author: Duran Inci is the CEO and Co-Founder of Optimum7, an ecommerce development and digital marketing agency. He helps mid-market and enterprise brands scale revenue through conversion optimization, SEO, and custom ecommerce solutions.
