Sitemap Bundle Laravel Package

Product Decisions This Supports

• SEO/discoverability roadmap: Sitemap generation is table-stakes for organic search. This package remains a useful reference for what that feature must do — URL providers, per-URL priority/changefreq/lastmod, sitemap index splitting, caching, and XML output — which helps scope the work regardless of whether you adopt it.
• Build vs buy vs borrow: Still a borrow/reference candidate, not a buy. The 4.4.0 release is a deprecation notice, not a feature release, so the "borrow the design, don't inherit the dependency" conclusion is now stronger, not weaker.
• Framework-fit decision: The package is a Symfony bundle, not a Laravel package, and its maintainers have now formally deprecated it in favor of nucleos/seo-bundle. For a Laravel stack this still argues for a maintained ecosystem package (e.g., spatie/laravel-sitemap) or a thin internal generator, and for enforcing framework fit as an adoption gate.
• Successor evaluation: The upstream direction of travel is now explicit. If any Symfony surface needs sitemap support, nucleos/seo-bundle becomes the thing to evaluate — against the same criteria below, not assumed-good because it's newer.
• Legacy triage: If the bundle already exists in a Symfony codebase, this release converts "keep/replace/remove" into "plan the migration." Deprecated upstream means no further fixes, including security-relevant ones.
• Prioritization guardrail: Sitemap generation is commodity infrastructure, not a differentiator. It should not absorb roadmap weight beyond the SEO baseline or a compliance requirement.

When to Consider This Package

Consider it when:

• You need a reference implementation or learning artifact — a worked example of provider-based sitemap assembly. This is now the primary valid use.
• You are auditing an existing Symfony app to understand what it contributed and what migrating off it entails — and its maintainers have handed you the successor to migrate toward.
• You are on Symfony (era-appropriate: Symfony 4/5, PHP 7.4–8.0), pinned and vendored, with an already-scheduled migration to nucleos/seo-bundle.

Look elsewhere when:

• The project is new or production-facing: 4.4.0 does not reverse the archived status, the 2022-09-18 release date, or the absence of a security response and PHP/Symfony support policy.
• The stack is Laravel — wrong abstraction; adoption means fighting the framework, and now also adopting something its own authors have deprecated.
• You need multi-locale, database-driven, high-cardinality sitemaps, sitemap indexes, or cache invalidation — a low-adoption package (5 stars, 0 dependents) is unlikely to carry that.
• Your supply-chain policy (SOC 2, CVE response, maintained-dependency requirements) forbids archived or deprecated dependencies.
• New adoption in any form — the deprecation makes starting fresh indefensible; go to the successor or in-house.

Adoption criteria: only if (a) pinned/vendored, (b) off the critical path, (c) you explicitly own it, and (d) there is a dated migration plan off it. Otherwise, decline.

How to Pitch It (Stakeholders)

For executives: "Sitemap generation is a commodity SEO feature — cheap to satisfy and not a differentiator. The candidate package is archived, has essentially no adoption (5 stars, 0 dependents), is built for Symfony, not our stack, and its latest release exists solely to deprecate itself in favor of a successor bundle. Recommendation: do not adopt. Fund a small internal implementation or a maintained ecosystem package instead. This keeps our SEO baseline inexpensive and avoids taking ownership of a dependency its own maintainers have retired."

For engineering: Release 4.4.0 contains no features — it is a BC-break deprecation pointing to nucleos/seo-bundle (PR #483). That confirms the earlier read: treat this as a spec, not a dependency. Lift the useful design — provider-based URL collection, a URL set abstraction, XML rendering — and reimplement thinly in-house with tests, or substitute a maintained sibling. If it already exists in a legacy Symfony service, the keep/replace question is now closed: schedule replacement rather than extension, evaluate nucleos/seo-bundle on its own maintenance and version-support merits before committing to it, and keep the current bundle off any critical path in the interim.