Robots Extension Laravel Package

Product Decisions This Supports

• Build vs. buy for crawl governance. This package represents the "buy/borrow" option for a narrow but real problem: letting non-engineers own robots.txt without shipping code. If your roadmap includes an admin-facing SEO surface (robots.txt, sitemap, redirects, meta defaults), it is a useful scope reference for what "good enough" looks like — a single editable document per site, versioned by the CMS, rendered at the root path.
• Per-environment and per-site crawl policy. The core product value is decoupling robots.txt from deploys: staging stays disallowed, production is editable by marketing, and multi-site installs get a file per domain rather than one shared artifact. That is a genuine operational pain point worth a decision, even if this particular package isn't the answer.
• Roadmap de-scoping. The existence of a ready-made extension is an argument for deferring this from your own backlog — you can ship a v1 with a static file or a config-driven route and revisit only if content editors actually ask for self-service.
• Platform-contingent reuse. If you are on the Anomaly/PyroCMS Streams platform, this is a candidate feature module; if you're on stock Laravel, it informs the spec of something you'd build in an afternoon rather than a dependency you'd adopt.
• Risk posture on SEO-adjacent surface area. Because a malformed robots.txt can de-index a site, this decision should be framed as who is allowed to change crawl directives and what guardrails exist (preview, diff, restricted permission, environment lock) — not merely "do we install a plugin."

When to Consider This Package

Adopt or seriously evaluate only when all of the following hold:

• You are already running the Anomaly Labs / PyroCMS Streams platform and its extension conventions (this package is built for that ecosystem, not generic Laravel — it will not drop into a vanilla app).
• You need editor-level control of robots.txt per site and lack a deployment pipeline that makes a static file easy to change.
• You have someone who can read the source and patch it yourself; treat it as vendored code, not a maintained dependency.
• Your Laravel/PHP version lines up with the extension's era, or you're willing to backport.

Look elsewhere — or build the 50-line version — when:

• You're on standard Laravel. A route returning a Blade/config string, or a small settings-backed controller, covers this with zero third-party risk.
• Maintenance signals matter. 0 stars, 0 dependents, and a dormant parent ecosystem are strong abandonment indicators for anything on the critical SEO path. There is no community to catch a regression.
• You need more than a single file. Sitemap generation, hreflang, canonical policy, and redirect management live outside this package's scope; don't assume adjacent capabilities.
• You need audit/compliance guarantees. No evidence of permissioning granularity, change history, or approval workflows — table stakes if marketing, not engineering, holds the keys.

Net: this is a reference implementation, not a dependency. Mine it for the admin UX and the "one document per site" data model; don't put it on your critical path.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed CMS extension that lets non-technical teams edit robots.txt from an admin panel instead of filing an engineering ticket. The idea is sound and cheap to replicate; the specific package is effectively unmaintained (no stars, no downstream users, dormant ecosystem), so the recommendation is borrow the concept, not the code — roughly a day of engineering against our own stack, with no licensing cost and no third-party risk. It also gives us a clear answer to "why isn't SEO self-service on the roadmap yet": we can ship a guarded v1 without committing a quarter.

To engineering: Treat anomaly/robots-extension as a spec, not a dependency — it's an Anomaly Streams module, so it won't install into our app without that platform, and there's no maintainer buffer if it breaks. The functional requirement it encodes is simple: a per-site, persisted robots.txt document, served at the root, editable by a permissioned role, with a preview before publish. We can implement that as a settings-backed route with an environment guard in well under a sprint, and add change history and a diff view that this package doesn't offer. If anyone is on legacy PyroCMS, it's a legitimate install; otherwise, no.