Laravel Blade Crawler Detect Laravel Package

Product Decisions This Supports

• Feature-level: conditional rendering by client type in Blade. Two directives (@user / @unlessuser) let you wrap third-party embeds, chat widgets, carousels, video players, and A/B-test scripts so they render for humans but not for bots. This is a cheap way to ship a "lite" variant of a heavy marketing page without a second template or a device-detection service.
• Roadmap input: Core Web Vitals / Lighthouse workstream. v0.5.0's repositioning around the Lighthouse/PageSpeed win is the maintainer explicitly targeting the "our homepage scores 42 on mobile" problem. If CWV is on your roadmap, this is a candidate tactic — but as a presentation-layer tactic, not a substitute for image optimization, JS budget reduction, or CDN work. Budget it as a supporting item, not the headline fix.
• Build vs. buy: strongly favors buy. The package is a thin, readable wrapper over jaybizzle/crawler-detect plus Blade directives. Building in-house means owning the UA regex list, keeping it current, and owning the ReDoS surface — none of which is differentiating work.
• Use cases where the value is real: serving a static/no-JS fallback to crawlers so content is indexable, keeping heavy marketing widgets out of the bot render path, and reducing wasted render cost on crawler traffic.
• Use case to decline explicitly: do not use this to show bots a materially different page from users. That is cloaking under Google's guidelines, it risks manual action, and hiding widgets specifically from the Chrome-Lighthouse UA inflates your score without improving real user experience. Treat the Lighthouse angle as a diagnostic convenience, never as the OKR.
• Adoption prerequisite, now cleared: the Octane/Swoole bug (every request seeing the first caller's UA) is fixed in v0.5.0. Before this release, any Octane-based service would have been silently wrong — that single fix is the difference between "evaluate" and "do not adopt" for a large share of modern Laravel deployments.

When to Consider This Package

Adopt when all of these hold:

• You are on Laravel 10, 11, 12, or 13. Laravel 9 was dropped in v0.5.0 (EOL Feb 2024) — if you are still on 9, pin 0.4.x and treat the upgrade as a scheduled task.
• Your pages are server-rendered Blade. With Inertia, Livewire, or an SPA front end, the directives cover far less of the render path and the payoff shrinks.
• You need coarse bot/human branching, not verified bot identity. This is UA-string matching: trivially spoofable, and fine for rendering decisions, useless for security or access control.
• You are willing to pin a pre-1.0 version (~0.5.0) and re-test on minor bumps. There is no 1.0 API-stability commitment yet.
• You can absorb single-maintainer risk on a non-critical dependency. Mitigation: it is small enough to fork or vendor if it goes stale.

Look elsewhere when:

• You need verified crawler detection (reverse-DNS / IP-range validation, e.g. Google's published ranges) — use a dedicated bot-verification service or edge provider.
• The real problem is actual performance, not bot traffic. Fix the bundle first; this package does not make your site faster for users.
• You need device, viewport, or capability detection — wrong tool; that is responsive design or a device-detection library.
• Your organization requires vendor support, SLAs, or security review of a maintained LTS. Pre-1.0 with a solo maintainer will not clear that bar.
• You are on an API-only or queue-heavy service with no Blade surface — nothing to apply it to.

How to Pitch It (Stakeholders)

One-liner: a small, free, MIT-licensed Blade helper that lets us render a lighter page for crawlers and keep heavy third-party widgets off the bot render path — roughly a day of integration work for a measurable Lighthouse delta.

For executives: low cost, low risk, reversible. It is a two-directive change confined to templates, with no infrastructure or vendor contract. It removes a known category of noise from our CWV numbers and improves how much of our content bots can actually parse. Be clear about the ceiling: it improves how we present the page, not how fast the page is. It will not close a JS-budget gap, and we should not report the Lighthouse improvement as a product win on its own — hiding widgets from the Lighthouse user agent is scorekeeping, not user value.

For engineering: thin wrapper over jaybizzle/crawler-detect with @user / @unlessuser directives. v0.5.0 makes it Octane-safe — the UA is now read from the current request inside the closure rather than captured at boot, and CrawlerDetect is bound rather than singleton'd so its $_SERVER state no longer leaks across long-lived workers. That was a genuine correctness bug, not a nicety, and it is now covered by real tests (browser, Googlebot, Chrome-Lighthouse, missing UA, oversized UA, @unlessuser). UA strings are clamped to 2048 chars before regex evaluation to blunt ReDoS, which matters because the header is attacker-controlled. Dependency surface went down — spatie/invade removed. Watch items: breaking drop of Laravel 9, string alias 'CrawlerDetect' retained only for BC (prefer the typed binding), and orchestra/testbench/Pest bumps that affect our own test matrix if we mirror their setup.