Redirect Manager

Free — GPL coresize Mplanned, not built

Generated from docs/plan/core/redirect-manager/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Redirect Manager is a core feature that lets merchants create 301/302 redirects from old product URLs to new ones. It preserves Google rankings when products are renamed and prevents customer dead links.

The problem

Merchants rename products and lose old Google rankings; customers get 404 errors and leave.

What it does

• Provide UI to create manual redirects (old URL → new URL) with 301/302 type selection
• Auto-create 301 redirect when product URL slug changes (optional)
• Bulk redirect import (CSV: old_url, new_url, status_code)
• Admin dashboard listing all active redirects with usage stats and redirect hit tracking
• Validate redirect chains (warn if redirect points to another redirect) and circular redirects
• Export redirects (CSV, YAML, nginx format) and maintain redirect logs

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Does NOT support regex-based redirects (reason: complexity, security risk)
• Does NOT apply redirects at HTTP server level (reason: CMS-level routing, app-level)
• Does NOT track redirect effectiveness (reason: requires analytics integration)
• Does NOT auto-delete stale redirects (reason: requires manual review)

Data model

New table: redirects (id, old_url, new_url, status_code, active, created_at, updated_at). New table: redirect_logs (id, redirect_id, referer, user_agent, timestamp). New table: redirect_stats (redirect_id, hit_count, last_hit_at) [summary].

API

• POST /api/redirects {old_url, new_url, status_code}
• GET /api/redirects
• DELETE /api/redirects/:id
• GET /api/redirects/:id/stats
• POST /api/redirects/bulk-import {redirects: […]}

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Redirects dashboard with table of active redirects, hit count, last used date; create redirect form; bulk import (CSV); stats showing total redirects and hits; search/filter; validation warnings; export as CSV or nginx config.

The seam — why this is core

Core owns: redirect storage, routing logic, admin UI.

Core owns the interface + honest 301/302 mapper; redirects are routing infrastructure, not a support commitment or credential.

Dependencies

• Assumes URL routing system exists
• Assumes product slug API exists (for auto-create on rename)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• GET /products/old-shirt redirects to /products/new-shirt with 301 status
• Redirect followed transparently (user sees new page)
• hit_count increments each time redirect is used
• Circular redirects detected: A → B → A shows warning
• Redirect chain detected: A → B → C shows warning
• 404 destination detected: redirect points to non-existent URL shows warning
• Bulk import accepts CSV with 1000+ redirects
• Export generates valid nginx redirect rules
• Merchant can change redirect status from 301 to 302
• All storage drivers support redirects equally

Risks

Redirect chains: A → B → C inefficient for search engines. Circular redirects: infinite loop if A → B → A. 404 destination: redirect to non-existent page causes error after redirect. Performance: 10k+ redirects become slow without indexing.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.