Magento Migration Redirect and Canonical Planning
How to inventory legacy URLs, decide 301, 410 or 404 outcomes, align canonicals and sitemaps, preserve parameter rules, and validate a Magento migration release.
Start with observed URLs, not only the new catalog
The redirect plan needs the URLs search engines, customers and referring sites already know. Export Search Console pages, indexing and link data; crawl the current site; export the existing sitemap; review analytics landing pages; collect paid and email landing URLs; and inspect server logs when available. Add catalog URL keys, CMS routes and known historical migrations from Magento data.
Combine those sources into one inventory and normalize host, scheme, path, trailing slash, casing and query handling for comparison. Keep the raw source columns so a reviewer can see why a URL matters. A redirect map without evidence often misses low-traffic but high-value product, category or campaign URLs.
- Current HTTP status and final destination after existing redirects.
- Indexation, impressions, clicks, sessions and known backlinks.
- Page type, business owner and whether an equivalent new destination exists.
- Proposed status, destination, rationale and reviewer.
Choose 301, 410 and 404 by meaning
Use 301 when the old URL has a genuinely equivalent replacement that satisfies the same user intent. Use 410 when a known, permanently removed URL has no replacement and a deliberate removal signal is useful. Use 404 for arbitrary, malformed or unknown paths. Do not redirect unrelated obsolete URLs to the homepage simply to avoid a 404 count.
Many-to-one redirects are valid when products or categories were intentionally consolidated and the destination remains relevant. They are harmful when every retired route is sent to a broad category or homepage. Review high-value URLs manually rather than generating equivalence from string similarity alone.
[Legacy URL]
|
+-- Equivalent replacement? -- yes --> [301 to one canonical URL]
|
+-- Known permanent removal? -- yes --> [410 Gone]
|
+-- Unknown or arbitrary? ----------- --> [404 Not Found]Make route status, canonical and sitemap agree
A URL in the release sitemap should return 200, be indexable, declare itself canonical and exist in the released HTML artifact. Redirects, error routes, noindex pages, parameters and duplicate forms do not belong in the sitemap. Canonical tags should be rendered in the initial HTML and should not change after JavaScript hydration.
Do not use canonical as a substitute for redirecting a permanently replaced URL. The old URL should redirect to the canonical new URL. Error responses must not inherit the homepage canonical or structured data through an SPA fallback.
Handle Magento URL and parameter behavior deliberately
Review category and product URL suffixes, category paths in product URLs, URL rewrites, store codes, locale or domain splits, layered navigation, search routes, pagination, sorting, tracking parameters and configurable-product patterns. The migration must define which variants are crawlable, which canonicalize, which are blocked from indexation and which redirect.
Magento URL rewrites can preserve catalog mappings, while Nginx or an edge layer may be more appropriate for a large static legacy map. Keep one owner for each rule and test precedence so an application rewrite does not fight a web-server redirect.
map $uri $legacy_redirect {
default "";
/old-category /new-category;
/old-product.html /new-product;
}
if ($legacy_redirect != "") {
return 301 $scheme://$host$legacy_redirect;
}Prevent chains and encoded surprises
Every legacy URL should resolve directly to the final canonical destination. A map that points to another redirect adds latency, complicates monitoring and can break when an intermediate rule is removed. Test encoded characters, uppercase variants, trailing slashes, query strings and host changes explicitly.
Avoid a broad regular expression when an exact reviewed map is safer. If a pattern rule is justified, constrain it by page type and prove it against both intended matches and a negative test set.
Launch validation
Run the legacy URL set against the release before activation where possible, then repeat it against the public hostname after the switch. Compare status, location, final status, canonical, robots, title and body identity. Crawl the new sitemap and internal links separately.
The migration is not ready if unknown paths return homepage HTML with 200, the 404 document returns 200, a redirect chain remains, an old URL lands on an unrelated page, or a sitemap URL is redirected or noindex.
- Known equivalents return one 301 to a 200 canonical page.
- Known removals return the approved 410 or 404 response.
- Random and unpublished routes return branded 404 content with a 404 status.
- Every sitemap URL returns 200 and is canonical and indexable.
- No old hostname, protocol or slash variant creates a chain.
- Internal links point directly to final URLs.
Monitor evidence after launch
At 48 hours, review status distribution, logs, sitemap availability and unexpected high-volume 404s. At seven days, review Search Console sitemap processing, indexing and soft-404 signals. Continue comparing landing-page query groups and important legacy URLs over the following weeks.
Do not promise ranking recovery on a fixed date. The deliverable is a coherent, tested route system and a monitoring record that makes later search-engine behavior diagnosable.
Continue with related work
Apply this to the store you are operating.
Share the Magento version, affected path, constraints and current evidence. The quote flow keeps this article as the source context.