Sitemap Laravel Package

Product Decisions This Supports

• Whether organic discovery is a supported channel. Sitemap generation is the plumbing behind "can search engines find our long-tail pages?" — catalog items, listings, docs, UGC, locale variants. If that's on the roadmap, this decision gets made; if it isn't, this is not a priority.
• Build vs. buy, scoped honestly. Sitemap XML is commodity infrastructure. The real decision is "cheap dependency vs. a one-day in-house serializer" — never a strategic bet. The low opportunity score (1.6) is the correct read: no differentiation, no lock-in, no leverage.
• Content coverage and granularity. Which content types get their own sitemap, whether you emit a sitemap index per section/locale/tenant, and whether you need extension markup (images, video, news, hreflang alternates).
• Freshness policy. On-publish regeneration vs. nightly cron vs. on-demand endpoint. This is a product/ops tradeoff about crawl budget and indexation latency, not a library feature.
• Marketplace and multi-tenant packaging. If customers get their own domains or storefronts, per-tenant sitemap indexes become a customer-facing capability rather than internal plumbing.
• Scale thresholds. The 50,000-URL / 50MB-per-file limits force a splitting strategy for large catalogs — a decision that must be made before launch, not after.

When to Consider This Package

Reasonable fit when:

• You run a Laravel/PHP service on PHP 7.x–8.0 and need spec-correct sitemap XML quickly with a small, MIT-licensed, low-dependency library.
• The work is a stopgap, an internal tool, or a short-lived project where a fork is acceptable.
• You are willing to treat it as vendored code: pin the version, read the source, own the patches.

Look elsewhere when:

• You're on PHP 8.1+. The last release was April 2020 and the repository is archived — no one is coming to fix compatibility or security issues. Verify before committing.
• You need maintenance guarantees, an active issue tracker, or a security review trail. Prefer a maintained, Laravel-native alternative (e.g. spatie/laravel-sitemap) or first-party code; the switching cost is measured in hours either way.
• You need scheduled generation, crawler-aware behavior, or rich extensions — you'll be wiring that yourself regardless of which package you pick.
• Your codebase already has a generic XML/serializer layer, in which case the package's value collapses to a few hundred lines you can own outright.

How to Pitch It (Stakeholders)

For executives: This is a low-cost enabler for organic acquisition, not an initiative. It deserves hours of engineering judgment, not a quarter of roadmap. The one material risk is that the project is archived, which means we inherit maintenance — mitigate by either forking it deliberately or choosing a maintained library at essentially the same cost. Frame the decision as "which commodity dependency," not "should we invest in SEO."

For engineering: Small, MIT-licensed, focused XML writer with sitemap index support; it absorbs the spec boilerplate — XML escaping, URL/size limits, lastmod formatting — so we don't hand-roll it and get it subtly wrong. Caveats: last release April 2020, repository archived, compatibility with modern PHP unverified. Recommendation: if we adopt it, wrap it behind a thin internal interface so replacing it with a maintained package or first-party code is a single-file change. If we're starting fresh on PHP 8.x, skip it and take the maintained option now — the effort is comparable and the risk is lower.