Sitemap Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for sitemap generation: This is a narrow, well-understood capability. The default PM position should be "buy" (adopt) unless you have non-standard URL discovery needs; hand-rolling sitemap XML, index files, and lastmod bookkeeping is pure undifferentiated work.
• SEO/discoverability roadmap sequencing: Sitemap correctness is a prerequisite for crawl-budget work, content launch campaigns, and internationalization rollouts. Adopting a maintained bundle de-risks those roadmap items instead of making them depend on bespoke code.
• Framework upgrade planning: v7.0.0 is a lockstep release — it drops Symfony <7.4 and adds Symfony 8 / PHP 8.5. This package's major versions track Symfony's major versions, so "upgrade this dependency" is not an independent decision; it is a line item inside the platform upgrade epic. Budget them together or you will discover the coupling mid-sprint.
• Dependency surface / maintenance burden decisions: A small, single-purpose bundle from a mid-size product company (Werkspot) is cheap to adopt and cheap to replace. That asymmetry — low switching cost — is itself a decision input: it lowers the bar for trying it and caps the downside.
• Not-a-Laravel decision: Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle. If your product is on Laravel, this is not a candidate at all; the equivalent decision is spatie/laravel-sitemap or framework-native routes. Confirm the stack before this enters any evaluation.

When to Consider This Package

Consider it when:

• The application is Symfony 7.4 or 8.x on PHP 8.5 — this release is explicitly built for that combination, and older combinations are now unsupported.
• You need conventional XML sitemap output (URL sets, lastmod, and whatever additional capability the bundle already exposes) for a content- or catalogue-driven site.
• You want sitemap generation to be a configuration concern (routes/controllers registered by the bundle) rather than custom application code you own and test forever.
• Your team is already on, or committed to, a near-term Symfony 7.4/8 upgrade — in which case adopting now avoids a second migration later.
• You value a small, replaceable dependency over a large SEO suite. The entire integration surface is likely a handful of lines; replacing it later is measured in hours, not sprints.

Look elsewhere when:

• You are on Laravel. Wrong ecosystem. Do not spend evaluation cycles here.
• You are on Symfony 6.4 LTS or earlier, or PHP < 8.5. v7.0.0 explicitly refuses to support you. Options: stay on v6.x (and accept you are now on an unmaintained branch), upgrade the platform first, or generate sitemaps yourself.
• You are pinned to an LTS cadence for compliance reasons. This package's support window is defined by upstream Symfony's, not by a vendor SLA. If you need a two-year guaranteed support contract, a community bundle is the wrong shape of dependency.
• You need sitemap features beyond the basics — sitemap index sharding at scale, image/video/news namespaces, hreflang matrices, crawl-stat ingestion, or automatic ping/submission workflows. Verify these exist in the current README before assuming; the release notes give no evidence either way, and the bundle's scope appears deliberately small.
• You require active multi-maintainer governance. Evidence available to us is a single release note and a compare link. Before committing, check commit recency, issue responsiveness, and whether the maintainer roster is one person or a team.

Caveat on this assessment: it is derived from a single changelog entry. There is no prior assessment, no usage data, no security history, and no feature inventory. Treat the feature claims above as hypotheses to confirm against the package's actual documentation during technical evaluation.

How to Pitch It (Stakeholders)

For executives (one paragraph): Sitemaps are plumbing for search visibility — unglamorous, but their absence quietly caps organic acquisition. This package lets us stop owning that plumbing ourselves. The v7.0.0 release is a maintenance release, not a feature release: it realigns the package with current Symfony and PHP versions. The strategic read is that the project is alive and tracking upstream, which is the main thing we need from a dependency this small. Cost to adopt is low, cost to reverse is low, and the risk is bounded — we are not betting a roadmap on it, we are deleting a small piece of undifferentiated code.

For engineering (the practical summary): v7.0.0 is a breaking change gated on the platform, not on the API. It drops Symfony <7.4 and adds Symfony 8 / PHP 8.5 support; there is no indication of public API changes. Consequences: (1) if we are below Symfony 7.4 we cannot take this version, and staying on v6.x means tracking an unsupported branch — decide deliberately, don't drift; (2) if we are planning a Symfony 7.4/8 upgrade, add this bump to the same epic so we only touch the dependency once; (3) if we are already on 7.4+/8.x, this is a low-risk patch-equivalent upgrade and we should take it for the PHP 8.5 compatibility. Before merging, confirm the bundle's actual feature set and maintenance activity against our requirements — we are working from a changelog only. And confirm the ecosystem: this is a Symfony bundle, so it is only relevant to our Symfony services, not the Laravel ones.