Redirects support migrations, page removals and structural changes. When the database only grows, active rules become mixed with duplicates and stale legacy. A one-time cleanup makes the table smaller only for a moment and does not remove the reason the debt returns.
Production · implemented and measured
60K+ → fewer than 5K redirects: a managed self-cleaning database
Over years, a simple CMS module grew into a database of 60K+ redirect rules with duplicates and historical legacy. I proposed a new architecture built around the lifecycle of each rule. After implementation, the working database fell below 5K records and became self-cleaning.
Case at a glanceIdentified the systemic cause of database growth and designed the product concept, SEO architecture, self-cleaning rules and exception model.
The database fell from 60K+ to fewer than 5K records — a reduction of more than 91.7%. Redirects gained a managed lifecycle: manual control, hit counting, quarterly automatic cleanup and protected exceptions for rules that must remain regardless of usage frequency. The database is now not only smaller but able to keep itself current.
60K+Legacy database
<5KAfter the change
Redirects: >60K → <5K.
The strong part is not deleting 55K rows but changing the economics of technical debt
A one-off cleanup would have kept the same append-only model and recreated the problem over time. The new lifecycle makes the database manageable: usage is measured, ordinary unused rules are removed automatically and important redirects can be protected by exceptions. The outcome is both legacy reduction and a mechanism against renewed accumulation.
The problem was not the size of the table
The old module understood only old URL → new URL. It could add rules but had almost no model for what happened to them later. After years of use by different specialists, the database exceeded 60K records and mixed active rules, duplicates and historical legacy.
What changed in the model
The key decision was to stop treating every redirect as permanent simply because it had once been created.
Before: append-only database
Every new rule was added on top of old ones with no lifecycle or automatic cleanup.
After: managed lifecycle
Rules can be managed manually, the system tracks actual hits and unused redirects can be removed automatically.
What the new module does
The module manages the life of a redirect after creation, not only the act of creating it.
Record management
Redirects became manageable CMS objects.
Hit counter
Each rule has a real usage signal.
Automatic cleanup
A normal redirect with zero hits for a quarter is removed automatically.
Protected exceptions
Rare but strategically important redirects can be excluded from automatic cleanup.
Lifecycle of one redirect
Instead of permanent storage, an ordinary rule keeps proving that it is still useful.
Create
The specialist adds the source URL and redirect target.
Count
The module records real redirect hits.
Review the quarter
The system checks whether the rule was used.
Keep, protect or remove
Used rules remain; strategic rules can be protected; ordinary zero-hit rules are removed automatically.
Why the result is stronger than a cleanup exercise
The 60K+ → fewer than 5K reduction shows the cleanup of accumulated legacy. The stronger result is that the system did not return to the same append-only model afterwards: the database became manageable and self-cleaning.
Context & measurement
- Context
- Large e-commerce business · CMS / SEO infrastructure
- Scale / period
- 60K+ → fewer than 5K records · >91.7% reduction · quarterly automatic cleanup
The key architecture principle
Automatic cleanup is not a blind rule applied to every redirect. The module contains exceptions for rare but important redirects, combining automation with deliberate manual control.
SEO infrastructure / CMS
Facing a similar challenge?
Tell me where SEO is blocked by product, engineering or data.