Preserve product and category URLs during a store rebuild by matching each old address to the same product, variant or category meaning before choosing a destination. Restoring the catalog’s appearance is not enough. A valuable historical product link can still fail if it opens the wrong item, loses a selected variation or lands on a generic homepage.
Keep existing addresses where the approved platform can support them. Where a genuine constraint prevents that, document the exception and obtain approval for an appropriate alternative. Do not use URL cleanup as a reason to rename a recovered store’s entire catalog.
Separate item identity from its addresses
One product may appear through several category paths, tracking URLs or variant links. Conversely, similarly named products may be different items. Begin with a verified identity map using surviving exports, owner records and public evidence. Keep each known URL attached to that identity.
Record the distinction between a product, a variation, a collection and a filtered result. A color-specific link is not necessarily equivalent to the parent product’s default view. A filtered category is not necessarily equivalent to the whole shop. Review the intended destination instead of treating all successful responses as acceptable.
A commerce URL acceptance card
- Old address: full path and any meaningful variation or filter parameter.
- Meaning: verified item, selected option, category or paginated result.
- Source: dated export, capture or owner-held record supporting that relationship.
- Planned result: preserve the address, approve an equivalent alternative, retain historical information or document an unavailable item.
- Constraint: destination-platform path or routing limitation, if actually verified.
- Acceptance: direct response, correct page identity, selected state, links and canonical reviewed.
This card complements the general original-URL restoration checklist. Its additional purpose is to preserve product meaning and options, not simply the spelling of a slug.
Product variants need an explicit decision
Google’s ecommerce URL guidance describes variant identification through a path or query parameter. It also calls for consistent URL usage across links, sitemaps and canonicals. Do not delete a meaningful parameter from the inventory just because it resembles tracking data.
Check whether visiting a recovered variation address selects the correct option and displays the relevant image and approved price. A parameter preserved in the address bar but ignored by the rebuilt page has not preserved that experience.
Canonical choices require review against the actual variant model. They do not replace working visitor destinations. Do not apply one blanket rule to products that have materially different variant content, availability or existing indexation arrangements.
Categories and pagination carry their own intent
Recover category relationships from evidence rather than generating empty categories from every old link. Where a category still makes sense, preserve its address and useful description, then verify its approved product membership.
Inspect pagination, filtering and sorting separately. Some parameters change which items are shown; others only alter display order. Keep those differences in the mapping record and avoid generating an uncontrolled number of thin destinations from an old crawl.
The owner should approve discontinued categories and products. An item may need an informative historical page, a genuinely relevant replacement or an honest unavailable response. The store homepage is not automatically a suitable destination for every retired product.
Check platform constraints before promising exact preservation
Shopify’s redirect documentation identifies fixed and reserved paths and explains that its redirects work from broken URLs rather than active pages. Filter and query-string behavior has additional limitations. These constraints matter when considering a rebuild on a different platform.
Do not promise that a redirect can reproduce every historical route or selected state. Test the specific route in an authorized preview or implementation review and record what actually happens. Resolve incompatible paths before launch, not after customers discover them.
A redirect recommendation is not authorization to change production URLs. Preserve the agreed source-to-destination map, obtain approval for exceptional changes and keep a rollback reference for the eventual implementation.
Verify the route customers actually use
Test old product links directly, category-to-product navigation, breadcrumb links and representative meaningful variation addresses. Check mobile navigation too. Search results, supplier references and saved bookmarks may enter the store through a product rather than the homepage.
Review response codes and redirect chains alongside the final content. Confirm that internal links point to approved destinations and that the canonical identifies the intended representative. Record unresolved identities rather than treating a random replacement as a successful recovery.
The WooCommerce recovery service includes important historical store structure within the reviewed scope. Share the original product/category inventory and any destination-platform constraints so URL acceptance can be agreed independently of checkout and catalog-field recovery.
Store URL questions
Can changing every product slug improve the rebuild?
A cleaner-looking slug does not justify losing a useful historical address. Preserve existing routes unless an approved, evidence-backed change is necessary.
Does a redirect prove the product link was preserved?
No. Check the final item, meaningful selected variation and visitor result. A redirect to an unrelated page is not equivalent product recovery.
