ecbeing: URL and Redirect Design for a Large-Scale Renewal

In a project that renews an ecbeing-built site together with its back-office integration, every URL changes, at a scale of thirty thousand products, two thousand categories, and five thousand content pages. Setting every redirect by hand is impossible, so you decide the order of the design first.

The answer is to handle them by rule, and handle individually only what falls outside the rules. If thirty thousand product URLs can be converted from old product ID to new product ID, one rule covers the redirects. Only the exceptions the rule can't convert go into an individual mapping table. Merged products, deleted categories, and content with irregular URLs fall here. If this design isn't done early in the renewal, tens of thousands of 404s appear on cutover day.

This article lays out the URL inventory, rule design, exception extraction, cutover-day steps, and post-migration monitoring in chronological order.

Conclusion: Rules for nine in ten, a mapping table for the rest. Verify every URL on staging before cutover

Key idea: In a move of tens of thousands of URLs, "checking by hand" applies only to the few dozen main URLs. The rest are covered by rules and mechanical verification. In moving-house terms, you carry the precious dishes yourself and leave the rest to the mover's checklist. A redirect that hasn't been verified is the same as one that doesn't exist. Separate the URLs you check by hand from the ones you check by machine at the start.

Inventory: every URL on the old site, by type

URLs with heavy search traffic and many backlinks are the pages where redirects matter most. Flagship product pages are the typical case. Mark the URLs you will check by hand on cutover day.

Rule design: conversion rules per type

A rule is built from an "old URL pattern → new URL pattern" plus a mapping table for the variables inside the pattern. If product IDs don't change, the rule alone is enough. If they do, you need a mapping table of (old ID, new ID). It is the difference between a move where only the address format changes and one where the street number changes too. Confirm with the back-office team whether product IDs will change.

How to find the exceptions

URLs the rules can't convert are extracted mechanically. There is no need to hunt for them by eye.

• Apply the rules to the list of old URLs and generate the new URLs

• Check whether each generated new URL exists on the new site (does staging return 200)

• Those that don't exist are the exceptions. For each, decide the merge target, the new location, or deletion (410)

Exceptions tend to cluster in predictable places: merged products (two old products → one new product), discontinued categories, and content whose URLs were hand-made. Sweep these three kinds first.

Verification: every URL on staging

1. Request the full list of old URLs (tens of thousands) against the new site on staging

2. Record the response code and redirect target for each URL

3. Extract everything that isn't a 301 (404, chained 301, 302, 200)

4. Fix what was extracted and verify again

5. Repeat until every URL reaches a 200 page in a single 301

Chained redirects (old → intermediate → new) lead to lost signal and wasted crawling. The more transfers a route has, the more people get off partway. Design so that a single 301 reaches the final URL.

What to do on cutover day

• Enable the redirects

• Open the top 50 URLs by search traffic and backlinks by hand and confirm they redirect correctly

• Resubmit the sitemap in Search Console. Delete the old sitemap

• Confirm robots.txt matches the new site's intent (no staging Disallow left behind)

• Request indexing for main pages via URL Inspection

A noindex or Disallow: / set on staging and left in production is one of the most common failures in a large-scale renewal. Once you cut over, look here first.

What to watch after migration

Redirects continue after the migration

Redirects don't end on cutover day. Backlinks to old URLs remain for years, and 404s turn up later. Every time the back-office integration reissues product IDs or categories are reorganized, new redirects are needed. It is like keeping a store relocation notice up for years.

Search OS continuously monitors 404s, redirect chains, canonicals, and changes in index count on large sites such as ecbeing. It also tracks the correspondence between the old and new URLs that bots fetch. Pages lost in the renewal are organized as fixes to make. It does not replace the renewal work itself. Decide in advance who keeps finding the holes after the renewal.

Frequently asked questions

Will setting tens of thousands of redirects slow the site down?

Rule-based redirects aren't affected by volume. If the individual mapping table runs to tens of thousands of entries, handle it with the web server's map feature or the CDN's redirect feature.

Which old URLs can be set to 410 (gone)?

Those with no traffic, no backlinks, and no corresponding new page. Search engines drop a 410 from the index faster than a 404.

How long should redirects be kept after migration?

At least one year. As long as backlinks remain, keep them permanently. Removing them loses the backlink value.

Related reading

• How to Write SEO and AI Search Requirements into an ecbeing RFP

• The SEO Assets Lost When Migrating from EC-CUBE 2 to 4

• Crawl Budget and Index Coverage for Large Catalogs

• ecbeing: 6 Things to Check First

References

• Google Search Central: Site moves with URL changes

• Google Search Central: Redirects and Google Search

• Google Search Central: Large site owner's guide to managing your crawl budget