Initpc: an SEO migration of 16 years of URLs to WooCommerce

An e-commerce store that has been selling online for sixteen years does not have one set of addresses: it has five, one for every platform that has ever run it. Initpc moved from osCommerce to Zen Cart, then to Magento, Magento 2 and finally WooCommerce, and each generation wrote its URLs with a grammar of its own. Those addresses are still alive in Google's results, in forum and blog links, in customers' bookmarks.

The SEO migration was about making sure all of that history still leads somewhere. With over 280,000 products and more than a million media files, the difference between a migration that holds and one that scatters years of rankings lies in the method: how you inventory the URLs, how you decide their destinations, what you check afterwards.

This page is a deep dive into the Initpc case study, where we describe the project's full architecture. Here we focus on the one layer no platform can carry over on its own: the addresses.

Five platforms, five URL grammars

osCommerce and Zen Cart built their URLs around a PHP script and query parameters: the product page took the form product_info.php?products_id=…, the category index.php?cPath=… with the levels chained together. Sorting, page and session were further parameters: a single item existed under many variants of the same address.

Magento introduced human-readable permalinks with a .html extension: product-name.html for the product page, category/subcategory.html for the category. The same product could be reached from the direct path and from the one nested under its category, while pagination and layered filters (?p=…, ?limit=…, attributes) multiplied the indexable variants.

Magento 2 kept the scheme, but the regeneration of URL rewrites during the upgrade produced slightly different slugs for part of the catalogue.

WooCommerce, the current platform, uses the WordPress structure: /product/product-name/ and /product-category/category/subcategory/, with a trailing slash, plus /page/N/ pagination and attribute filters.

Generation	URL form	Migration rule applied
osCommerce	product_info.php?products_id=…, index.php?cPath=…	One-to-one 301 by id, from the id → current product table
Zen Cart	same scripts with extra parameters (&page=, &sort=, session id)	Parameter normalisation, then the same one-to-one rule by id
Magento	product-name.html, category/sub.html, ?p=, layered filters	Pattern 301 on the .html extension, one-to-one exceptions for changed slugs
Magento 2	as Magento, with regenerated slugs	Reconciliation of divergent slugs, then the pattern rule
WooCommerce	/product/slug/, /product-category/…/, /page/N/	Canonical tags, XML sitemaps and crawl rules for pagination and filters

The inventory: know what exists before deciding where it goes

No list of the legacy URLs existed in a single place: we rebuilt it by cross-referencing several sources.

The server logs are the most honest source: they record what visitors and crawlers actually request, including forms nobody remembered any more. Search Console gave us Google's view: indexed and excluded pages, crawl errors, addresses still being requested years later. The XML sitemaps of the previous platforms filled the gaps for the less visited addresses. The backlinks showed which URLs carried external value worth protecting regardless of traffic.

The result was a single inventory, with every address classified by generation, type (product, category, pagination, filter, image, static page) and weight: without it, every rule would have been a guess.

Mapping and redirects: patterns where possible, one-to-one where needed

First the pattern rules: where a whole URL form transforms according to a simple law (the .html extension that drops away, the nested category that becomes a WooCommerce path), a single rule covers an entire generation and stays readable.

Then the one-to-one redirects: the numeric identifiers of osCommerce and Zen Cart bear no relation to the current slugs, so they require lookup tables generated from the ERP database, which preserves the product code across every migration. The same applies to the Magento 2 slugs that diverged from Magento: a list of exceptions, not a rule.

Two constraints apply to both. No chains: an osCommerce URL that redirects to its Magento counterpart, then to Magento 2 and finally to WooCommerce wastes crawl budget and loses strength at every hop: every legacy address points straight to its final destination, and at each platform change the rules are rewritten, not stacked. Evaluation order: one-to-one rules come before pattern rules, otherwise the exception is never reached; sorting and session parameters are stripped upstream, so all variants converge on the same destination.

Canonical tags and XML sitemaps on the current platform

Redirects settle the past; for the present, WooCommerce also needs discipline, because it produces several addresses for the same resource.

Every product page and every category declares a canonical pointing to its own clean, parameter-free form. Paginated pages keep the canonical on themselves, because they are distinct content; filter combinations point back to the category and stay out of the index. Google can still ignore a canonical if the page it names is too different from the one declaring it: this has to be checked in Search Console.

The XML sitemaps are split by type: products, categories, static pages and a dedicated image sitemap that links each product to its photos at their current address. On a catalogue this size the sitemap is a file index, generated from what is actually published and updated whenever availability changes: that is the job of the ERP that keeps the warehouses in sync with the site.

Discontinued products: 301, 410 or leave the page up

The most delicate decision concerns what no longer exists: over sixteen years many products have left the catalogue, and each one had an address, often more than one.

If a direct replacement exists (updated code, next version of the same model), a 301 redirect to the new product page.

If the product is gone but the category still makes sense, a 301 redirect to the most specific category: someone looking for a cartridge for a discontinued model finds the cartridges compatible with the same printer, not the home page. Redirecting to the home page was ruled out from the start: Google treats it as a soft 404.

If there is neither a replacement nor a relevant category, the page returns 410 Gone: it declares the removal and the index is cleaned up faster than with a generic 404.

Temporarily unavailable products, on the other hand, stay published, with the correct status in their structured data: removing and re-adding a product page costs more, in indexing terms, than leaving it visible with an honest "out of stock".

Images, media and legacy backlinks

Images are the bulkiest asset and the easiest to lose: each platform stored them in a different folder, with different names and crops, and their addresses show up in Google Images, on marketplaces and on third-party pages.

The media follow the same logic as the products: pattern rules from the previous platforms' folders to the current storage, and a lookup table for the renamed files. The product pages generated with Hector AI kept the image address wherever the file was the same.

Legacy backlinks took priority: every URL with external links was checked after the rules went live, verifying that the destination was relevant and reached in a single hop. Where the link pointed to removed content we preferred the closest category over a 410: an external link deserves to be captured even if the product is no longer there.

Monitoring after the migration

The migration is over when the crawler has stopped finding surprises. In the following weeks we checked, daily at first and then at wider intervals:

• the 404 errors in the logs and in Search Console, grouped by URL form: every new pattern that appears is a missing rule;
• the soft 404s, pages that respond 200 but that Google judges empty: emptied categories, indexed internal searches, redirects to generic destinations;
• the ignored canonicals, flagged by Search Console when it picks an address other than the declared one: a symptom of pages that are too different, inconsistent redirects or parameters not stripped;
• the index coverage, compared with the inventory: the indexed pages must converge on the products actually in the catalogue.

On top of this come the sitemap checks (URLs in the map that return a redirect or a 404) and a review of the queries in Search Console.

It is the same method we used for the CMS migration from Joomla to WordPress and for every e-commerce development and design project we take on: the platform changes, the store of addresses has to stay.