Statamic Redirect Laravel Package

Technical Evaluation

Architecture fit. rias/statamic-redirect is a Statamic addon, not a standalone Laravel package. Its value is entirely contingent on the application already running Statamic (v3/v4/v5) on Laravel. It plugs into the Statamic addon lifecycle — a service provider registered through Composer's extra.statamic manifest, a control-panel UI for editors, and a middleware that intercepts requests before (or alongside) Statamic's own router. For a Statamic site this is a natural fit: redirects become content that editors own rather than a developer-maintained .htaccess or nginx map block. For a plain Laravel app, this package is the wrong abstraction — use spatie/laravel-missing-page-redirector or a route-level table instead.

Integration feasibility. Low effort, high uncertainty. Installation is a single Composer require plus config publish; there is no database migration in the typical flat-file variant, which keeps the blast radius small and rollback trivial. The real work is not installing it but reconciling it with whatever already handles redirects — a CDN edge rule set, a legacy .htaccess, Laravel route redirects, or a hand-rolled middleware. Any two of those running simultaneously produce ordering bugs that are painful to diagnose.

Technical risk. Concentrated in five places:

• Storage model. Flat-file/YAML redirect definitions are parsed per request unless cached. Thousands of entries will show up as latency; tens of thousands will not be viable without an index or an export to the edge.
• Middleware position. A redirect middleware sits in the hot path of every request. An exception or an unhandled edge case (malformed source, regex backtracking, circular target) can 500 the entire site rather than degrade gracefully. This is the highest-severity failure mode and warrants a kill switch.
• Static caching interaction. Statamic's static cache can serve pages without ever invoking the middleware, so redirects added in the CP may appear not to work. Needs explicit verification, not assumption.
• Maturity signals. 29 stars, zero dependents, and a single-maintainer bus factor. The maintainer is well known in the Statamic community, which raises the quality prior, but adoption is effectively zero — no third-party validation, no ecosystem pressure to keep it current.
• Version metadata anomaly. The reported last release of 2026-08-28 postdates the present. That is either a metadata error or a mis-parsed field; do not treat "recent release" as evidence of active maintenance until verified against tags and commit history.

Key questions for the maintainer/team:

1. Which Statamic and Laravel major versions are supported today, and is there a CI matrix proving it?
2. Where are redirects persisted, and is there a compiled/cached index for request-time matching?
3. How are redirect chains and loops detected — at save time, at request time, or not at all?
4. Does it preserve query strings, handle trailing-slash and case normalization, and support 301/302/307/308 explicitly?
5. What is the license, and is the code small enough to fork and own if maintenance lapses?
6. Multisite: are redirects scoped per site or global?
7. Does it cooperate with Statamic static caching, or must the cache be purged/invalidated on save?

Integration Approach

Stack fit. Only proceed if the target is Statamic. Confirm the exact Statamic minor version and PHP constraint first; a mismatch here ends the evaluation. If the site is Laravel-only, or if redirects are already handled at the CDN, the marginal value is low and the operational surface added is not.

Migration path. Treat this as a consolidation project, not an install. Inventory every existing redirect source — CDN rules, web-server config, legacy CMS tables, marketing-owned spreadsheets — into one canonical list with source, target, status code, and owner. Load that list into the addon, then explicitly disable the superseded mechanisms in the same change window. Half-migrated redirect state is the most common cause of SEO damage in this kind of work.

Compatibility. Two axes: Statamic/Laravel version support, and coexistence with other middleware. The second is routinely missed. Check what else is in the web group and where Statamic pushes its own middleware; a redirect layer that runs after session/auth middleware wastes work on every request, and one that runs after the router never fires.

Sequencing.

1. Sandbox install, config publish, no production data. Verify a 301, a 302, a query-string case, a trailing-slash case, and a deliberately broken rule.
2. Confirm behavior under static caching — this is a go/no-go gate.
3. Import the consolidated map into staging; run a crawler over the top ~200 URLs by traffic and compare against the current CDN/webserver behavior.
4. Add monitoring: a synthetic check on the redirect middleware and an alert on 5xx rate.
5. Cut over with the edge rules left in place but logged-only where the CDN permits it, so you can diff behavior for a week.
6. Retire the old mechanism, hand the CP UI to editors with a short written policy (status codes, no chains, no redirecting to redirects).

Operational Impact

Maintenance. Single maintainer, minimal dependents, and a release date that cannot be trusted at face value. Assume you may need to fork. That is acceptable for a small addon — the ceiling on fork cost is low — but it must be a conscious decision, not a surprise during a Statamic upgrade. Budget a review at every Statamic major.

Support. GitHub issues only. No SLA, no vendor to escalate to, no commercial backing implied. Editor-facing breakage lands on the internal team. Write the runbook before launch, not after.

Scaling. Fine for hundreds of redirects, questionable for thousands, and wrong for anything at CDN scale. If redirect volume or traffic is large, the correct architecture is to author redirects in the CP and publish them to the edge (Cloudflare Bulk Redirects, Fastly, or a generated nginx map), keeping the addon as the editorial interface rather than the runtime. That preserves editor workflow and removes the request-path risk.

Failure modes to instrument:

• Redirect loop or chain — user-visible hang or wrong destination; detect at write time.
• Middleware exception — site-wide 5xx; needs a config flag to bypass.
• Static cache staleness — rules saved but not applied; alert on a known test path.
• Multisite bleed — a redirect scoped to site A firing on site B.
• Silent loss of query parameters or POST bodies on 301/302 — analytics and campaign attribution quietly break.
• Orphaned rules after a page is deleted or re-slugged — accumulation with no owner.

Ramp-up. Developer: under a day to install and understand, plus the caching verification. Editors: the CP UI is the point of the package and should be intuitive, but they need a short policy — prefer 301 unless temporary, never chain, never redirect to a 404, log the reason in the rule. Product/SEO: half a day on status-code semantics and the measurement plan. The dominant effort is the redirect inventory and the dual-run verification, not the software.