Sitemap Generator Laravel Package

Product Decisions This Supports

• Build vs. buy for a commodity SEO surface. Sitemap generation is undifferentiated plumbing: it turns database records into XML and gets referenced from robots.txt. The real decision this package informs is not "which generator" but "do we spend engineering sprints on this at all, or adopt a library and move on." Framing it that way protects roadmap capacity for work that actually moves retention or revenue.
• Content-discovery policy. Any generator forces the team to make explicit product calls that are otherwise implicit: which entities are indexable (products, categories, CMS pages, user profiles?), what changefreq/priority we advertise, whether we publish a sitemap index with per-section children, and how we handle pagination past the 50k-URL / 50MB limits. Those are product decisions about what we want crawled, not implementation details.
• Roadmap timing for SEO investment. A sitemap only pays off alongside canonicalization, robots.txt, structured data, and a crawl-budget strategy. Adopting a generator in isolation is a partial solution; the PM decision is whether SEO is a committed OKR this quarter or a checkbox.
• Integration architecture. This library is ORM-agnostic by design (Propel, Doctrine, and by extension Eloquent via an adapter), which means the PM-level question becomes: do we accept a data-access adapter layer, or do we want a framework-native package that reads Eloquent models directly? That choice affects maintenance ownership long after the sitemap ships.
• Risk acceptance on third-party dependencies. With 16 stars, zero dependents, no release since January 2015, and an archived repository, this is a case study in supply-chain risk as a product decision — MIT licensing means we can vendor or fork it, but we, not the maintainer, own every future bug and PHP-version incompatibility.

When to Consider This Package

Consider it only in narrow circumstances:

• You are maintaining a legacy PHP 5.x application already built on Propel or Doctrine, the sitemap requirement is genuinely one-off, and you intend to vendor the source into your repo rather than depend on Packagist. In that scenario it is a readable reference implementation of "iterate records → emit sitemap XML," and the MIT license makes copying it clean.
• You need a pattern reference for how to structure a generator that is decoupled from your ORM — useful when writing your own 200-line implementation.
• You are doing due-diligence archaeology on an inherited codebase and need to understand what an old dependency was doing before you replace it.

Look elsewhere — decisively — when any of the following hold:

• You are on Laravel with Eloquent. There is no reason to bridge a 2015 ORM-agnostic library into Eloquent when maintained, framework-native sitemap packages exist and handle chunking, sitemap indexes, and caching out of the box.
• You are on PHP 7.4 / 8.x. A package last released in 2015 predates modern PHP entirely; expect deprecation warnings at best and hard failures at worst. It will also fail modern Composer audits and abandoned-package checks in CI.
• You have any security, compliance, or SLA obligation. An archived repository receives no security advisories, no patches, and no issue triage. An XML generator has a small attack surface, but "nobody is watching this" is still an unacceptable answer in a regulated environment.
• You need sitemap indexes, image/video/news extensions, hreflang alternates, or scheduled regeneration. Validate these against the source before assuming support; if they are missing, the "cheap" option becomes a fork you now maintain forever.

Treat the internal score as a confirming signal rather than the argument: a 0.67 overall with an opportunity score of 13 and zero dependents says this package has no ecosystem momentum to borrow.

How to Pitch It (Stakeholders)

To executives: Sitemap generation is table stakes, not a differentiator — it tells search engines what to crawl. We evaluated an open-source generator that is free (MIT) but was last released in 2015 and is now archived, meaning nobody fixes it when PHP or our framework moves. The license lets us copy the code, but then we own it permanently. Recommendation: do not adopt as a dependency; if SEO is on the roadmap, allocate one short sprint to a maintained, Laravel-native package (or a small in-house generator) alongside canonical tags and robots.txt, and treat it as a single bundled SEO work item rather than a standalone initiative.

To engineering: The library's only real asset is a clean separation between record iteration and XML emission, with Propel/Doctrine adapters. That pattern is worth ten minutes of reading and about a day of reimplementation. Depending on it means: no PHP 8 support, Composer abandoned-package warnings in CI, an unowned fork the moment we need a fix, and an adapter layer between our Eloquent models and a foreign ORM abstraction. If someone wants to reuse the approach, vendor the file with a license header and a comment pointing at the upstream repo — do not add it to composer.json.

One-line recommendation: Free but abandoned — copy the idea, not the dependency; ship sitemaps with a maintained package inside a broader SEO work item.