Sitemap Extension Laravel Package

Product Decisions This Supports

• SEO/discoverability roadmap for PyroCMS-backed sites — This extension appears to add XML sitemap generation to the Anomaly Labs / Streams Platform (PyroCMS) ecosystem. It supports decisions around whether organic discoverability is a first-class product feature or a "marketing site" concern handled separately.
• Build vs. buy for sitemap generation — A PM facing "we need sitemap.xml for the content portal" can treat this as a candidate off-the-shelf option before committing engineering cycles to a custom controller + queue job. The evaluation ultimately hinges on ecosystem fit rather than feature depth.
• Addon-first vs. core-feature strategy — If the product ships on PyroCMS, this is a data point on whether to lean on community "extensions" for infrastructure-adjacent features (sitemaps, feeds, redirects) or absorb them into the core product to control quality.
• Content syndication and indexing use cases — Supports scoping for blog aggregation, multilingual content portals, marketing microsites, and any surface where fresh content needs to be discoverable by search engines within hours, not days.
• Maintenance burden triage — With 0 stars, 0 dependents, and a low opportunity score, this is a signal to decide deliberately whether an internal fork is acceptable, rather than letting a single unmaintained dependency quietly become load-bearing.
• Not a differentiator — Sitemap generation is table stakes. It should not consume roadmap narrative; it belongs in the "hygiene / SEO fundamentals" bucket.

When to Consider This Package

Consider it when:

• You are already running PyroCMS or the Streams Platform — the extension assumes that runtime, its entry model, and its routing conventions. Outside that context its value collapses.
• You need a fast, low-effort sitemap for a content-driven site built on Streams entries, and "good enough" beats "best in class."
• The deployment is internal, low-traffic, or non-revenue-critical, where a stalled upstream project is an annoyance rather than an incident.
• You are comfortable vendoring or forking the MIT-licensed code and owning it — treat this as a code sample to adopt, not a dependency to trust.
• You need sitemap behavior tightly coupled to CMS content types (auto-inclusion of new entry streams) rather than a generic URL list.

Look elsewhere when:

• You are not on PyroCMS/Streams. On plain Laravel, spatie/laravel-sitemap is the obvious, actively maintained choice with vastly larger adoption.
• You need advanced sitemap semantics — Google News, image, video, hreflang/alternate links, sitemap index sharding at scale, or lastmod accuracy tied to real publish events.
• Supply-chain review is a gate. Zero stars, zero dependents, and a low composite score mean no community signal: no downstream users to surface regressions, no issue history to read, no PR velocity to assess.
• You require versioned compatibility guarantees against current Laravel/PHP releases.
• Performance at scale matters — a CMS-coupled extension is unlikely to handle 100k+ URL generation with chunking and caching out of the box; validate before committing.

Recommendation: treat as tactical, ecosystem-locked, and unproven. Green-light only inside an existing PyroCMS footprint with a named internal owner and a written exit plan.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed addon that generates XML sitemaps for sites built on our CMS stack — the plumbing that tells Google what pages exist. Cost is effectively zero and integration is quick if we are already on PyroCMS. The honest caveat is maturity: the project has no visible adoption, no dependent projects, and no community around it. That means no one else is finding its bugs. I'd position it as a shortcut we adopt and own, not a vendor relationship. Recommendation: use only if PyroCMS is already our platform; otherwise standardize on a maintained Laravel library and move on. Either way, this does not belong on the roadmap as a feature — it's SEO hygiene.

To engineering: The extension plugs sitemap generation into Streams content types, so new entry types are indexed automatically rather than requiring a hand-maintained URL list. That coupling is its whole value and its whole risk — it inherits the CMS's release cadence and conventions. Given zero dependents, assume we own the code from day one: vendor it, pin it, and add a smoke test asserting /sitemap.xml returns 200 with expected entries. Before adopting, verify PHP/Laravel compatibility against our target versions, confirm how it handles volume (chunking, caching, index sharding), and check whether lastmod is driven by real publish events or naive timestamps. If any of those come back weak, the fallback is a ~1-day custom implementation or spatie/laravel-sitemap — cheap enough that we should not spend a sprint negotiating with an unmaintained dependency.