Robots Bundle Laravel Package

Product Decisions This Supports

• Declaring indexability policy per route, at the moment the route ships. The core capability is attaching an X-Robots-Tag directive (noindex, nofollow, noarchive, max-snippet:N) to individual responses. That converts "is this page supposed to be in Google?" from a post-launch SEO ticket into a line of code reviewed in the same pull request as the feature. For a PM, that is a governance win: the decision is versioned, revertible, and attributable.

• Deciding which surfaces we expose to search — a genuine roadmap input. Faceted search URLs and filter/sort permutations, internal site search results, paginated listings, gated or paywalled previews, thin programmatic pages, A/B and personalized variants. Each is a product question with real consequences for crawl budget and index quality, and this capability makes the answer cheap to express. It lets you greenlight a feature and its indexability stance together instead of accumulating an SEO debt backlog.

• Non-HTML assets, where robots.txt is the wrong instrument. The header works on PDFs, images, JSON API responses, and generated exports. This matters: Disallow in robots.txt prevents the crawl, so a noindex inside the document is never read and the URL can still surface with a bare snippet. If the roadmap touches document downloads, media libraries, or public API responses, this is the correct mechanism and robots.txt is not.

• Environment and tenant gating as release safety. Staging, preview, and white-label tenant domains defaulting to noindex is a small, repeatable control that prevents a known class of embarrassing incident — a staging site outranking production, a customer microsite leaking into the index. Cheap to build, high perceived value with executives, and it removes a manual pre-launch checklist item.

• Build vs. buy: build — decisively. The delivered behavior is a response middleware plus a way to read a per-route marker. In Laravel that is a middleware and a PHP 8 attribute, roughly a day of engineering. The package under evaluation is a Symfony bundle that will not install or boot in Laravel at all: no bundles, no kernel.response, no annotation reader, no container compiler passes. The "buy" option does not exist for this stack.

• Read the scores as a portfolio signal, not a vendor signal. Opportunity 5.5 against a package score of 0.005 says the problem space is worth roughly a thousand times more than this specific artifact. Interpret that as: fund the capability internally, do not adopt the repository.

Recommendation: ship a first-party Laravel middleware + #[Robots] attribute; use this bundle only as a reference design. It covers perhaps a third of "control what search engines do" — robots.txt management, sitemap directives, and path-level disallow rules remain separate concerns.

When to Consider This Package

Consider adoption only if all of the following hold:

• The application is Symfony, not Laravel. This is a Symfony bundle built around a kernel.response event subscriber. It will not function in a Laravel service provider. If the stack is Laravel — as framed here — the package is out of scope and evaluation should stop.
• The codebase already uses Doctrine annotations for controller configuration and is pinned to a Symfony version where that pattern is idiomatic. Modern Symfony (PHP 8+) has moved to native attributes; an annotation-driven bundle is a strong hint of a legacy codebase and an unmaintained dependency.
• The surface area is small and non-critical: a handful of controllers, an SEO policy that changes rarely, no legal or compliance exposure tied to indexability.
• The team accepts fork-and-own. With 1 star and 0 dependents, this is effectively unmaintained and unaudited. Treat adoption as "copy the logic into our codebase with attribution," not "add a dependency." Pin an exact version and vendor the source if you must.

Look elsewhere — or build — when:

• The stack is Laravel. Not compatible. Do not spend further evaluation time.
• The requirement is robots.txt management. This package only sets a response header. Crawl budgeting, sitemap directives, and path-level Disallow rules are a different tool.
• You need maintained, supported, or audited dependencies. Zero dependents and a single star mean no ecosystem pressure to fix bugs, no security review, no upgrade path. Under most dependency-vetting or SBOM policies this fails on vendor risk alone.
• The logic is revenue- or security-critical. A silently dropped header, or noindex leaking onto a revenue landing page, is a commercial incident rather than a bug ticket. Critical indexability policy belongs in code you own and test.
• You are on modern Symfony and want attributes. A native implementation is a few dozen lines and avoids pinning to a deprecated annotation layer.
• You want marketing to self-serve the policy. This package pushes SEO decisions into developer code and deploys. If the requirement is a CMS or config-driven interface for non-engineers, look at a config layer instead.

How to Pitch It (Stakeholders)

To executives: This is a tiny MIT-licensed Symfony utility that lets developers mark individual pages and files as "do not index" directly in code, per route, reviewed in the same pull request that ships the feature. The problem it addresses is real and worth funding: leaked staging sites, thin pages diluting search quality, A/B and personalized variants polluting the index, and PDFs or API responses surfacing when they shouldn't. The opportunity score reflects that value. The artifact itself does not: one star, zero downstream users, no maintenance signal, and it does not run on our Laravel stack. Recommendation: do not adopt the dependency; fund a one-day in-house implementation — a Laravel middleware plus a per-route PHP attribute — which delivers the same behavior plus ownership, tests, and an upgrade path at negligible cost. The strategic value is in the policy, not the package.

To engineering: We want per-route X-Robots-Tag control, declared next to the route so it is reviewed with the feature, defaulting to noindex outside production with an allowlist of explicitly indexable public routes. The referenced bundle does this for Symfony via a response listener reading Doctrine annotations — it is not Laravel-compatible, and annotations are legacy in current Symfony. Build a middleware that reads a PHP 8 attribute or a route default and sets the header on the response. Estimate under a day plus tests. Watch the details that bite: header must survive exception rendering, streamed and binary responses, and 304/ETag short-circuits; middleware ordering must place it after any response transformation; and it must not silently overwrite headers set by a CDN or reverse proxy. Treat the bundle's header-formatting logic as a reference, not a dependency. Sequence it as: inventory existing ad hoc header emission (half a day), spike the middleware and attribute (1–2 days), feature tests asserting exact header values per route class plus a negative test that production routes do not carry noindex (1 day), then ship dark in log-only mode and diff observed headers against expectation for one crawl cycle before enforcing.

To SEO/marketing: You get a declarative, per-route indexability switch enforced at the HTTP layer, and it covers PDFs, images, and API responses — precisely the cases where robots.txt fails because the crawl never happens. It does not replace robots.txt or sitemap management; those stay separate. The tradeoff to accept is that changes ship with deploys rather than through a CMS, so bring indexability requirements into the feature ticket at planning time instead of requesting them after launch. Ask early for the default-to-noindex behavior in staging and preview environments — it is the cheapest insurance against a staging site outranking production.