Last updated on August 13th, 2026 at 03:51 pm
The safest way to change a page slug is to keep a small redirect history and consult it only after the current slug lookup fails.
I learned that this order prevents old links from breaking without making normal page requests slower or more complicated than necessary.
What problem does slug history solve?
A slug is the readable part of a URL. When it changes, bookmarks and search results may still point to the old address.
Deleting the old slug loses that connection. Keeping every old version in the main page table creates ambiguity. A separate redirect-history table gives each old slug one clear purpose: point to the current page.
The lookup order that keeps behavior predictable
- Look for the current slug. If it exists, return the page normally.
- Check redirect history after a miss. Match the page identifier and requested old slug.
- Resolve the current slug. Use the stored page reference to find the latest URL.
- Return redirect metadata. The caller can send a permanent redirect to the canonical URL.
- Return a small 404 response. If neither lookup succeeds, do not build unrelated navigation data.
Why the backend should own the decision
When several clients display the same content, centralizing slug resolution avoids duplicated rules. Each client only needs to understand three outcomes: render, redirect, or show a 404 page.
A compact response also helps. A redirect response needs the destination slug, not the full page payload. An unknown-slug response needs an error state, not large navigation collections.
Important data rules
- Old slug must be unique in its page scope. This prevents two destinations from claiming the same address.
- Save history only when the slug changes. New pages do not need redirect records.
- Preserve useful counters on updates. Do not reset hit counts when refreshing the destination.
- Do not cache misses for long. A newly added redirect should become available quickly.
Common mistakes and fixes
- Cause: Checking redirect history before current content. Fix: Always prefer the live slug.
- Cause: Returning a successful page for an unknown slug. Fix: return a real not-found result.
- Cause: Sending a large payload for a redirect. Fix: return only the destination and status metadata.
- Cause: Cleaning history during a partial data update. Fix: delete stale records only when the full data set is known.
Conclusion
The practical takeaway is simple: make slug resolution a three-way decision—current page, known redirect, or 404—and keep that decision in one place.
Next action: document these three response shapes before connecting another client.