Weave Code
Url Trailing Slash Laravel Package
illuminatech/url-trailing-slash
Laravel middleware that enforces consistent trailing slashes by redirecting requests to the canonical URL form. Avoid duplicate-content SEO issues and keep links predictable, with flexible per-route configuration for when a trailing slash should or shouldn't appear.
Allows enforcing URL routes with or without trailing slash
Frequently asked questions about Url Trailing Slash
- How do I install illuminatech/url-trailing-slash in a Laravel application?
- Install it with Composer using composer require illuminatech/url-trailing-slash. After installation, register the middleware in your HTTP kernel or bootstrap file so it runs during the request lifecycle. Then define your desired canonical policy and verify the redirects in a staging environment before enforcing them in production. The integration surface is intentionally small, so most setups only need one middleware registration plus a policy choice.
- How does the middleware decide whether to add or remove a trailing slash?
- The package lets you configure a canonical form for URLs, either with a trailing slash or without one, and it redirects incoming requests that do not match that form. Because the policy is configurable, you can enforce a global rule while still defining cases where the opposite form is expected. Start by auditing your existing URLs and sitemap so the policy you choose matches what search engines already index.
- Which Laravel and PHP versions does illuminatech/url-trailing-slash support?
- Compatibility is defined by the version constraints in the package's composer.json, which is the authoritative source for supported Laravel and PHP versions. Check those constraints against your application before adding it, especially if you are on a recent Laravel release. Because community adoption is modest, verify the package installs cleanly in a branch and run your test suite rather than assuming broad version coverage.
- Will this middleware break API routes, webhooks, or health check endpoints?
- A blanket trailing-slash redirect rule can interfere with APIs, webhooks, and health checks, where clients may not follow redirects or where redirects change expected behavior. Scope the policy to web route groups or exclude those paths explicitly rather than applying it globally. Test non-GET methods as well, since a redirect on POST, PUT, or PATCH can drop the request body depending on client behavior.
- Does the redirect preserve query strings and fragments?
- Query strings should be preserved when a request is canonicalized, but you must confirm this with your own tests, particularly for encoded values and multiple parameters. URL fragments are never sent to the server, so a fragment cannot be forwarded by server-side middleware. Add feature tests covering query strings, encoded characters, and nested paths before enabling the policy in production.
- Which HTTP status code does the trailing-slash redirect use?
- Redirect status codes matter because 301 and 308 responses are cached aggressively by browsers and CDNs, and are difficult to reverse once propagated. Review how the middleware issues redirects and confirm the code is appropriate for your traffic, since a permanent redirect on a misconfigured policy can cause lasting SEO and client issues. Validate behavior in staging and check your CDN cache rules before a production rollout.
- Can I apply the trailing-slash policy only to specific route groups?
- Yes, the middleware can be applied globally, to web route groups, or selectively by environment, which is the recommended approach for most applications. Keep API, webhook, and health check routes outside the policy unless you have explicitly verified redirect behavior for them. Scoping also gives you a safer rollback path, since disabling one group is less disruptive than reverting a global rule.
- Is illuminatech/url-trailing-slash safe to use in production?
- The package addresses a narrow, well-defined concern and its runtime overhead is negligible, but adoption is low and its repository license is reported as NOASSERTION. That means legal review is required before commercial use, and without a clear license the package should not be deployed to production. Treat it as a routing hygiene utility rather than a core dependency, pin a version, and isolate usage so you can replace it with first-party middleware or web-server rewrites if needed.
- How do I test trailing-slash redirects and prevent redirect loops?
- Write feature tests that assert the redirect status and target for both slash and no-slash variants, including query strings, encoded URLs, and excluded routes. Add cases for non-GET requests and confirm that a canonical URL does not redirect to itself, which is how loops appear. Run the suite with route caching enabled and test behind your reverse proxy or CDN configuration, since slash normalization at those layers can conflict with the middleware.
- What are the alternatives to this package for canonical trailing slashes?
- The main alternatives are a small in-house middleware, web-server rewrite rules in nginx or Apache, or enforcing consistent URLs at the application and sitemap level. Given the package's modest community validation and unclear license, a first-party middleware is a reasonable fallback and is straightforward to write for a single canonical policy. Whichever route you take, keep the policy documented in one place so internal links, canonical tags, and sitemap generation stay aligned.
Weaver
How can I help you explore Laravel packages today?