Sitemap Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 9 readiness): v5.5.0 adds Laravel 9 support, which is the single most decision-relevant fact here. If the roadmap includes a Laravel 9 migration, this package is no longer a blocker and can be carried forward rather than replaced or forked. If the app stays on Laravel 8 or below, this release changes nothing about current plans.
• Build vs. buy for sitemap generation: sitemap emission is commodity functionality — XML schema compliance, URL sets, lastmod/changefreq/priority, and index files for large sites. Continuing to depend on a maintained package is the low-cost path versus owning a custom generator and its edge cases (50k-URL limits, sitemap index partitioning, escaping).
• SEO/technical discoverability scope: confirms sitemap generation stays a "solved" capability that engineering does not need to staff. Product effort belongs in what gets indexed (content coverage, canonical URLs, crawl budget), not in the XML writer.
• Risk tracking on a low-activity dependency: the release is a community PR from a first-time contributor, not a maintainer-driven feature release. That is fine for a compatibility bump, but it is a signal to keep this package on the dependency watch list rather than assume proactive maintenance.
• Feature/roadmap non-impact: no new product-facing capabilities. Do not treat this as a reason to re-open sitemap feature requests (image/video/news sitemaps, dynamic priority rules) — those remain package-capability questions, not delivered functionality.

When to Consider This Package

Adopt or keep it when:

• You need standards-compliant XML sitemaps (and sitemap indexes) generated from Laravel routes, Eloquent models, or arbitrary URL sets with minimal code.
• You are on, or moving to, Laravel 9 / PHP 8.0+ — v5.5.0 is the first release in this line to support that combination, so pin ^5.5 rather than an earlier 5.x tag.
• You want a small, framework-native integration (config-driven, no external service, no SaaS dependency for a purely mechanical output).
• Your sitemap needs are conventional: static pages, model-backed URLs, multi-language or multi-domain variants within normal size limits.

Look elsewhere or build in-house when:

• You are still on Laravel 8 or earlier and have no near-term upgrade — v5.5.0 offers no benefit; stay on the prior tag and avoid a gratuitous dependency bump mid-cycle.
• You need heavy crawling-adjacent features (automatic lastmod derivation from content diffs, SEO scoring, robots.txt orchestration, search-engine submission APIs) — this is a generator, not an SEO suite.
• You require vendor-backed SLAs, security review attestation, or guaranteed release cadence. This is a single-maintainer community package; the Laravel 9 work arrived via an outside contributor, which indicates best-effort maintenance.
• Your sitemaps are extraordinarily large or generated at high frequency — validate performance and caching strategy first, since regeneration cost, not correctness, becomes the constraint.

Action for this release: treat v5.5.0 as an upgrade enabler, not a feature. Pin it in the Laravel 9 migration branch, verify generated output against the prior version (byte-level or URL-set comparison), and confirm the PHP 8.0+ requirement is satisfied in all target environments before rollout.

How to Pitch It (Stakeholders)

To executives: A routine maintenance release for the library that generates our XML sitemaps. Its significance is narrow but real — it clears one dependency from the Laravel 9 upgrade path. No new product capability, no cost, no customer-visible change. It slightly reduces platform-modernization risk at zero incremental spend.

To engineering: v5.5.0 adds Laravel 9 compatibility via a community PR. Adopt it as part of the Laravel 9 migration and not before; it implies PHP 8.0+. Diff the generated sitemap output before and after to confirm no behavioral change in URL sets or XML structure. Flag that this is a single-maintainer package with contributor-driven releases — keep it on the dependency review list and avoid extending it into areas it does not own.