On this page
A migration that looked fine on launch day
The shape is familiar from merchant forums. A shop with a few thousand products moves off Magento over a weekend. The new site looks right, orders come in on Monday, everyone relaxes. Three weeks later organic traffic is down by a third. Search Console is full of 404s on addresses ending in .html, image search visits have gone to almost nothing, a whole branch of old category links lands on the home page, and nobody can say which of these matters most.
It is not always that clear cut. In one thread a merchant lost about half of their traffic after moving from Magento even though redirects for products, categories and posts were in place; replies pointed at renamed categories, changed content and structure, and the weeks it takes signals to pass through redirects. In another, only the UK fell, three months after the move, and the suspects were legacy URLs nobody had mapped and missing hreflang tags. Both are the same lesson: a move is a list of URLs and signals, and anything not on the list gets dropped.
Why Magento URLs are harder to move than most
Magento builds addresses from several settings at once. A product's URL key can carry a suffix such as .html, can be served with or without its category path, and can sit behind a store code. Adobe's own URL rewrite documentation shows the same product reachable as gear/bags/impulse-duffle.html and as impulse-duffle.html, depending on configuration.
Behind all of that sits the url_rewrite table. It holds every address Magento answers: the current ones, the category path variants, and the 301s it created automatically each time someone changed a URL key over the years. That table, not your sitemap, is the real list of what Google may know about. Export it before anything else.
Where the rankings go: URL changes
- The .html suffix. What it looks like: every product and category 404s after launch, or lands on search. Why: almost no other platform uses a suffix, so /wool-coat.html becomes /wool-coat or /products/wool-coat. The fix: a pattern rule that strips the suffix is fine as a start, but check every rule against the real export, because category and product keys can collide.
- Category paths in product URLs. What it looks like: the short product URL redirects but /women/coats/wool-coat.html does not. Why: with categories in the path, one product has as many addresses as categories, and backlinks point at all of them. The fix: map every request_path for each product id to the single new address, not just the canonical one.
- Store codes. What it looks like: a second language or country loses everything. Why: with Add Store Code to URLs switched on, Adobe puts the code in every path, /en/ or /pt/, and store switcher links can also carry a ___store parameter. The fix: map each store view's URLs to the matching language version on the new site, never to the default language.
- Old URL keys Magento was still redirecting. What it looks like: links from blogs and old newsletters break months after launch. Why: rows in url_rewrite with redirect_type 301 kept years of renamed products alive, and they disappear with the old server. The fix: point each of those straight at the final new address, so it stays one hop.
- Layered navigation. What it looks like: Search Console reports thousands of odd URLs like ?color=49&size=166 returning 404 or redirecting to the home page. Why: Magento filters are query parameters on category pages, and Google crawls them. The fix: do not map them one by one. Send filtered URLs to their category, and only rebuild as real pages the few filter combinations that brought search visits. Google's faceted navigation guide explains why filter URLs waste crawling in the first place.
- Image addresses. What it looks like: Google Images traffic falls away and does not come back. Why: pictures move from /media/catalog/product/ to the new platform's storage under new names. The fix: Google's site move guide says to include images in your URL map; at least redirect the images of your best selling products, and keep the alt text and descriptive file names.
Where the rankings go: lost signals
- Missing redirects, or everything to the home page. What it looks like: a flat line of 404s, or a home page suddenly getting traffic for product queries. Why: a bulk rule sent unmatched URLs to the home page. Google says not to point many old URLs at an unrelated page, and says such redirects may be treated as a soft 404. The fix: one relevant destination per URL, and a real 404 or 410 where nothing fits.
- Redirect chains. What it looks like: old links work but rank worse and get crawled slowly. Why: an old key redirected to a newer key, which now redirects to the new platform. The fix: flatten the chain, every old address straight to the final one. Google advises going straight to the final address and, failing that, keeping chains to three hops or fewer; aim for one.
- Temporary instead of permanent. Why: some tools and app settings default to 302. A temporary redirect keeps the old URL in results; permanent ones (301 or 308) move the ranking to the new one. Use server side redirects; JavaScript redirects are a last resort.
- Meta titles and descriptions. What it looks like: pages are indexed but click through drops. Why: many importers bring the name and description but not Magento's meta_title and meta_description, so the new title is just the product name. The fix: export both fields and copy them across, especially for the pages that earn clicks.
- Canonicals and hreflang across store views. What it looks like: one language outranks another in the wrong country, or pages show as duplicates. Why: canonicals and hreflang tags are often added by a Magento extension or theme and simply do not exist on the new site. The fix: give every new page a self-referencing canonical and rebuild the language alternates between versions.
- robots.txt and noindex left over from staging. What it looks like: pages drop out of the index a few days after launch. Why: the staging site was hidden, and the setting went live with it. The fix: check robots.txt and the robots meta tag on the live domain within the first hour.
- The sitemap. Why: the old sitemap URL now 404s, and the new one was never submitted. The fix: submit the new sitemap in Search Console and, as Google suggests, keep a sitemap of the old URLs for a while so the redirects are found sooner.
The checklist, step by step
- 1
Crawl the live Magento site and export its URLs
Run a crawler over the whole shop and save every URL with its status, title, meta description, canonical and H1. Then export the url_rewrite table (request_path, target_path, redirect_type, store_id, entity_type, entity_id). Together they are your inventory.
- 2
Add what Google and other sites know
Export the top pages from Search Console's Performance report for the last 16 months, your top linked pages, and landing pages from analytics. Old sitemaps, server logs and the Wayback Machine find legacy addresses nobody remembers.
- 3
Map every old URL to one new URL
A spreadsheet with two columns: old and new. Products by SKU or ID, categories by ID, CMS pages by hand. Retired products go to their closest category or replacement, not the home page. Mark the URLs with search traffic or links so you test those first.
- 4
Carry the page signals across
Meta titles, meta descriptions, headings, category descriptions, image alt text and structured data. Keep category names and descriptions close to the old ones for the first months; a move is not the moment to rewrite everything.
- 5
Set up the 301s, one hop each
Server side permanent redirects, loaded from the map, each straight to its final address. Decide where they live (the new platform's redirect tool, your CDN or a web server in front) before launch, not after.
- 6
Test on staging, then again on live
Feed the old URL list to a crawler in list mode and check every one returns a single 301 to a 200 page. Then do it again on the live domain the hour you switch.
- 7
Open the doors
Remove any noindex and staging robots.txt rules, submit the new sitemap, keep the old URLs in a second sitemap, and inspect a handful of key pages with Search Console's URL Inspection.
- 8
Watch, fix and keep the redirects
Check the 404s in Search Console daily for the first two weeks and add redirects as they appear. Keep the redirects for as long as possible: Google says generally at least a year, and indefinitely is better for people following old links.
After launch: what is normal and what is not
Google's site move guide warns that rankings can fluctuate while it recrawls, and that for a medium sized site it can take a few weeks or more for most pages to move over; larger sites take longer. A dip in the first weeks is not a verdict.
| What you see | Normal when | Worry when |
|---|---|---|
| Impressions and clicks dip | It is shallow and recovering within a few weeks | It is still deep after two or three months |
| Old URLs still in search results | They redirect and fade over weeks | They return 404 or land on the home page |
| Many redirect warnings on the old sitemap | Always: that sitemap lists redirected URLs on purpose | The new sitemap shows errors or few indexed pages |
| New 404s in Search Console | A trickle of forgotten legacy URLs | Hundreds of product or category URLs |
| Traffic down in one country or language | Never really | From day one, which usually means store view URLs or hreflang |
A drop that is still there after two or three months almost always has a technical cause worth finding: compare the old URL list with what the new site returns, page by page.
If you are moving to WhizzyCommerce
The Magento 2 importer keeps each product's and category's URL key as its handle, and pages live at the root, so /wool-coat.html becomes /wool-coat. That makes the map mostly mechanical: strip the suffix and the category path. Images are copied into your shop's own storage, so their addresses change. The importer reads the default store view, and a second store view becomes a second shop.
Redirects come across: every old .html address of a product or category, at any depth, goes on to its new one with a 301 by itself, and the importer brings Magento's own redirects, custom ones included, each straight to the final page. What it does not do, plainly: product and category meta titles are not imported (each product and collection has its own SEO title and description to fill in), and store codes in URLs (/en/...) and layered-navigation filter addresses are not mapped by themselves; add those under Settings, Search engines, Redirects, by hand or from a CSV. The shop's sitemap lists every product, category and page, with its language versions. For the first 100 shops moving from Magento, a person on our side runs the move and keeps your URLs working: ask on switching from Magento. If you are moving because your release is losing support, start with Magento 2 end of life.
Questions
Will I lose Google rankings when I leave Magento?
Some movement in the first weeks is normal while Google recrawls. Lasting losses come from URLs that 404, redirect to the home page or chain, and from lost titles and descriptions. A complete URL map with one-hop 301s prevents most of it.
How long does traffic take to recover after a migration?
Google says a medium sized site can take a few weeks or more to move over, and larger sites longer. If traffic is still well down after two or three months, look for a technical cause rather than waiting.
Should I keep the .html at the end of my URLs?
Only if the new platform lets you keep identical URLs without workarounds. Otherwise drop it and redirect every old .html address to its new one with a 301. Clean redirects are fine; broken ones are what cost rankings.
Do I need to redirect layered navigation and filter URLs?
Not one by one. Send filtered URLs to their category page, and only rebuild as real pages the few filter combinations that brought search visits.
How long should I keep the redirects?
Google says for as long as possible, generally at least a year. Links on other sites and in old emails keep arriving for years, so keeping them indefinitely is the safer choice.