Redirect Bundle Laravel Package

Product Decisions This Supports

• URL and information-architecture changes without SEO loss. Any roadmap item that renames, restructures, merges, or retires public URLs (site redesign, product/category taxonomy rework, blog migration, locale prefix changes) needs a redirect layer. This package turns that from a bespoke engineering task into a configured dependency — a direct enabler of "we can restructure the site without bleeding organic traffic."
• Build vs. buy for redirect management. The naive version (a redirects table plus middleware) looks cheap but consistently grows into: regex/wildcard matching, query-string and fragment preservation, chain/loop detection, status-code selection (301 vs. 302 vs. 410), hit counting, and a non-developer editing surface. This bundle covers that full surface, which reframes the decision from "should we build it?" to "is our redirect volume and stakeholder self-service need large enough to justify a dependency?"
• Who owns redirects operationally. Because it ships a persistence model plus an admin CRUD surface and import/export, it supports a product decision to let marketing/content ops own redirects instead of filing engineering tickets. That's a headcount-and-throughput argument, not just a technical one.
• Campaign, partner, and lifecycle link management. Short-lived 302s for launches, affiliate/partner links, deprecated deep links from old app versions, and print/offline QR destinations all become data rather than deploys — enabling same-day changes without a release train.
• Sunsetting and content consolidation. Retiring a product line or folding pages into a hub requires per-URL decisions (redirect to parent, to a search page, or 410). Modeling this as data enables reversible, auditable decisions during a migration rather than one-way code changes.
• Platform upgrade planning. The v3.11.0 release adds Symfony 8 support and clears Foundry deprecations. That is a forward-compatibility signal: choosing it now does not create a blocker for a Symfony 8 upgrade, so it can be safely sequenced ahead of a framework modernization effort. No breaking changes, so no migration cost is introduced by this release.

When to Consider This Package

Adopt when most of the following hold:

• The application is Symfony (not Laravel or another framework) and already uses Doctrine ORM for persistence — the bundle is designed around Doctrine entities and a Symfony bundle config, and gains you nothing if you have to fight it into a different stack.
• You expect dozens to low thousands of redirects, authored and edited over time by people who are not developers.
• SEO equity and link stability are business-relevant: public marketing site, content/e-commerce with organic traffic, or a documented redesign/migration on the roadmap.
• You want hit counts and reporting on redirects to decide when an old URL can be retired, and import/export to bulk-load a legacy redirect map from an existing CMS or agency spreadsheet.
• You are planning or currently executing a Symfony version upgrade and want a dependency that is tracking upstream (v3.11.0 targets Symfony 8 and fixes Foundry deprecations) rather than one that will pin you back.

Look elsewhere when:

• The framework is Laravel or plain PHP. Use framework-native middleware plus a redirect table, or an equivalent Laravel package; this bundle's value is its Symfony integration.
• Redirects belong at the edge, not in the app. For high-traffic sites, a CDN/edge layer (Cloudflare, Fastly, CloudFront functions) or the web server config is the right home — it avoids an application boot per redirect and survives app outages. If that's your architecture, this package is the wrong tier.
• Volume is very large (hundreds of thousands to millions of rules). A relational lookup per request with regex evaluation is not the right engine; a key-value store or dedicated redirect service is.
• The site is static or JAMstack. Host-level redirect files are simpler and cheaper.
• You need enterprise workflow — approval chains, scheduled publish windows, multi-tenant governance, or granular audit/compliance — which a lightweight bundle does not provide.
• You cannot take a Doctrine dependency, or redirects must work in an app with no shared relational database.

How to Pitch It (Stakeholders)

For executives (one paragraph): Redirects are how we change our URLs — redesigns, renamed products, retired pages, campaign links — without losing the search rankings and inbound links we've already earned. Today that work is either hand-written by engineers on every change or not done at all, and both outcomes cost us traffic and engineering time. This is a small, actively maintained open-source component that stores redirects as data and gives authorized non-technical staff a safe way to add and edit them, with reporting on which old links still get traffic and bulk import/export for large migrations. The current release adds support for the next major Symfony version and fixes test-tooling warnings — no breaking changes. Net effect: fewer engineering tickets for routine marketing and content requests, and a de-risked path through our next site restructure. Cost is a dependency and a small admin surface to secure and govern, not a build project.

For engineering leads: Mature, narrowly-scoped Symfony bundle built on Doctrine, maintained by Zenstruck with a steady release cadence and a clean upgrade from v3.10.1 — v3.11.0 is additive only (Symfony 8 compatibility, Foundry deprecation cleanup). It gives you the redirect matching edge cases (regex/wildcard, query-string preservation, hit tracking, import/export, admin controller) that we would otherwise re-implement and maintain indefinitely. Principal caveats to design around: it runs in-application, so it is not a substitute for edge-level redirects at high traffic volume; it requires Doctrine; and the admin routes and import endpoints need explicit authentication, authorization, and rate limiting before they go anywhere near production. Recommended sequencing: adopt behind our own auth-guarded admin, seed it from our existing redirect map, and treat the edge/CDN layer as the complementary tier for high-volume or must-survive-an-outage rules.