- Can I use fourlabs/robots-bundle in a Laravel application?
- No. It is a Symfony bundle that depends on a bundle class, DI extension, kernel.response event subscriber, and an annotation reader, none of which boot inside a Laravel service provider. The realistic path is to reimplement roughly 60 to 100 lines of equivalent logic as Laravel middleware plus a PHP 8 attribute or route default.
- How do I install fourlabs/robots-bundle?
- On Symfony you would run composer require fourlabs/robots-bundle, register the bundle in AppKernel or bundles.php, and add YAML configuration for user-agent blocks, Allow/Disallow rules, and sitemap URLs. There is no verified Laravel installation path because the bundle registry and kernel events it relies on do not exist in Laravel. Given the package's sparsity and maintenance risk, treat any install as a short spike rather than a production dependency.
- How do I configure Allow, Disallow, and sitemap rules dynamically?
- The bundle reads YAML configuration where you define user-agent blocks with Allow and Disallow paths and inject sitemap URLs. Environment-aware defaults let you block crawlers in staging while serving production rules. In Laravel you would replace this with a config file plus a route or middleware that renders the same robots.txt body.
- Does fourlabs/robots-bundle support Laravel 11 or PHP 8.2?
- There is no evidence of Laravel support at all, since the package is a Symfony bundle. Its likely target is Symfony 2.x through 4.x and PHP 7.x, with PHP 8.2 and Symfony 6 or 7 compatibility unverified and probably broken. The metadata shows no CI matrix, so do not assume modern runtime support.
- How does the bundle apply per-route robots directives?
- Per the technical assessment, it uses a kernel.response event subscriber that inspects the controller for a @Robots annotation and parses it with doctrine/annotations or Symfony's annotation reader, then projects directives such as noindex or nofollow onto the response header. That annotation-driven mechanism is not how Laravel routing or middleware works. Porting it means using reflection on a PHP 8 attribute or a route default instead.
- What are the best alternatives for a dynamic robots.txt in Laravel?
- The simplest alternative is a first-party route or middleware that returns a robots.txt response built from config, optionally with per-route PHP 8 attributes for X-Robots-Tag directives. Route defaults such as ->defaults('robots', 'noindex') are the cheapest option when you do not need reflection. For sitemap generation, pair it with a maintained Laravel sitemap package, but vet any dependency the same way.
- How should I test robots directives in a Laravel middleware?
- Write feature tests that assert the expected X-Robots-Tag or robots.txt body on successful responses and on error, streamed, and binary responses. Cover precedence rules between a global default, route groups, and controller-level attributes. Most importantly, prove that production revenue routes never inherit noindex by adding a test that fails if they do.
- What are the production risks of depending on an unmaintained robots bundle?
- The package shows 1 star, 0 dependents, and a 0.005 package score, with no test or CI evidence, so it is likely abandoned. A silently dropped header is an SEO regression, and a leaked noindex on a revenue landing page is a measurable business loss. Pulling an unmaintained third-party into the request path to save one engineering day is a bad trade and would likely fail dependency vetting.
- How do I resolve precedence between environment defaults and per-route robots rules?
- Define an explicit order: global environment default first, then route-group setting, then controller attribute, with the most specific winning. Keep a production allowlist so staging-wide noindex rules can never leak into live revenue routes. Test error responses and controller inheritance, because those edge cases are unproven in the original bundle.
- Is fourlabs/robots-bundle maintained, and should we vendor it?
- The repository shows minimal adoption and sparse documentation, and the technical assessment rates it high risk and likely abandoned. If you were on Symfony, the safer move would be to vendor the listener and own the fork rather than depend on the package. For Laravel, do not adopt it; use it as a reference design and fund a first-party middleware with PHP 8 attributes.