Sitemap Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged primary red flag. v1.1.0 is a feature release inside the existing Symfony bundle: three PRs adding host-specific sitemap groups, host-level sitemap paths, and route filtering by host. Nothing in the release notes touches framework bootstrapping, and nothing suggests a Laravel ServiceProvider, facade, or config-publishing shim has been added. The package remains a Symfony bundle (Jgniecki\SitemapBundle, DI Extension, compiler passes, bundle service config), and Laravel still cannot load it. Fit for a Laravel codebase remains zero out of the box; the integration layer is still yours to write. In a native Symfony host the fit remains idiomatic — and is now meaningfully richer, since host-awareness is exactly what a multi-tenant or multi-locale Symfony estate needs.

What v1.1.0 actually changes. This is an additive, multi-host capability release:

• Host-specific sitemap groups — grouping is now addressable per host rather than one global set.
• Host-level sitemap paths + warnings for the default group — per-host sitemap locations, with the default group flagged as a probable misconfiguration.
• Route filtering by host — URL discovery is now host-aware, which answers part of the earlier "how are URLs discovered" question: discovery is route-introspection based and can be scoped by host.

Two implications matter for evaluation. First, this partially answers the multilingual/multi-host question from the prior assessment: the package now has a story for per-host sitemaps and (by extension) sitemap indexes per host, but still no stated hreflang, news/image/video, or gzip support. Second, it increases configuration surface area — host groups, host paths, and host-filtered routes are more places to get wrong, and the "warnings for default group" hints the maintainer knows the default path is a footgun.

Integration feasibility. The two verdicts from the prior assessment stand, and the gap widens slightly:

• Symfony host: Still low effort, and now the package is a stronger fit for multi-host estates — composer require, register the bundle, import routing, configure host groups and paths, run the command. Afternoon-scale for single-host, roughly a day for multi-host including validation.
• Laravel host: Still high effort, low return, and more work than before, because you would now be forking a host-grouping feature set rather than a simple XML emitter. spatie/laravel-sitemap — which is Laravel-native and has host/domain concepts of its own — remains the correct comparison, and the glue-vs-build math has moved further against the bundle.

Technical risk — still elevated, but the release cadence is now a genuine positive signal. Zero stars, zero dependents, and a 0 score remain true; there is still no community validation, no downstream projects, no issue history, no third-party review. The mitigations are now two data points rather than one: 2025-09-04 initial release plus an active v1.1.0 with three merged PRs. That is a maintainer who is engaged, not a maintainer who shipped once. It is still a bus factor of one. The new risk specific to this release is host-resolution correctness: if host detection reads HTTP_HOST or X-Forwarded-Host and the app sits behind a proxy or CDN, a misdetected host can place URLs from one property into another property's sitemap — a cross-host canonical leak that is worse than a missing sitemap and fails silently. "Warnings for default group" also implies new config validation that can emit noisy or unexpected output on existing single-host setups.

Key questions — updated for v1.1.0 (resolved items removed).

1. Still open: declared composer.json constraints (php, symfony/*) and the Symfony major-version support matrix.
2. Partially resolved: URL discovery is route-introspection with host filtering. Still open: does it support explicit/tagged providers and database-driven sources?
3. Still open: what it provides beyond XML — sitemap index sharding, gzip, caching, robots.txt integration, hreflang/multilingual alternates, news/image/video extensions.
4. New: How is the current host determined — Request host, X-Forwarded-Host, explicit config? Is there a trusted-proxy story, and is there a hard assertion that a generated group only contains URLs for its own host?
5. New: Is the "default group" warning a lint-time notice or a behavioral change? Does v1.1.0 alter output for a pre-existing single-host config, i.e. is the minor bump actually non-breaking in practice?
6. Still open: lastmod strategy and trustworthiness.
7. Still open: CI, test suite, license.
8. Still open: behavior at the 50,000-URL / 50MB limits, now compounded by per-host index generation.
9. Still open: API stability — 1.x with an actively evolving config schema, so treat the config format as unstable.

Integration Approach

Stack fit — unchanged verdict. Treat this as Symfony-only. v1.1.0 makes it a better Symfony citizen, not a Laravel one. Mixed estate: if the target is a Symfony service, particularly a multi-host or multi-tenant one, this is now a more compelling low-cost utility than it was at v1.0.1. If the target is Laravel, the stack fit remains a hard mismatch and the evaluation stops here.

Migration path. No migration path into Laravel, for the same reasons as before, with the added wrinkle that host grouping would now have to be re-implemented in any fork. The honest options remain (a) a separate Symfony sitemap service — now genuinely more justifiable if you already run Symfony for a multi-host property — or (b) fork and re-home, converting a dependency into owned code. Within Symfony, migration in and out remains trivial, because a sitemap is a derived artifact: regenerate with any tool and diff the output. That property, not the feature list, is still the strongest argument for piloting.

Compatibility. Verify four axes now, not three: PHP ceiling, Symfony major version (5.4 vs 6 vs 7), config-schema compatibility with any existing v1.0.x setup, and host-resolution behavior under your actual proxy/CDN topology. Zero dependents still means every "works with X" claim must be proven in your environment. Pay specific attention to whether existing single-host configs need editing to silence the new default-group warning — a config migration is still a migration.

Sequencing.

1. Spike (1–2 days): install in a throwaway Symfony skeleton. Generate a single-host sitemap first and diff against v1.0.x output to confirm the minor bump is behaviorally additive. Validate against the sitemap XSD and Google's limits; check absolute URLs and lastmod.
2. Multi-host spike (1–2 days, new): configure two host groups. Verify by inspection that no URL from host A appears in host B's sitemap, and that host detection behaves correctly when the request arrives through your proxy/CDN. This is the release's central claim and its central risk.
3. Build-vs-buy: generate the same per-host sitemaps naively. If the delta is small, the dependency is not earning its keep — and the per-host case is where an internal script is most tractable.
4. Pilot behind a flag: one low-traffic property, sitemap deployed at a non-canonical path, compare before promoting.
5. Promote only with an owned fallback — a script that regenerates all host sitemaps without the package.

Recommendation for a Laravel estate: do not adopt. Unchanged, and the rationale is now stronger — you would be declining a larger, more framework-specific feature set. Document the rejection with the framework-mismatch rationale so it is not re-litigated, and route the requirement to a Laravel-native solution.

Operational Impact

Maintenance. Still single maintainer, still no downstream users, so you remain maintainer of last resort and must budget for a fork. v1.1.0 is mild evidence the fork is unlikely to be needed soon, which lowers the probability but not the cost. The fork burden has grown: a fork must now carry host grouping and host filtering, not just XML emission. That fork falls to whoever owns the sitemap pipeline, who may not be a PHP developer.

Support. Still none — no vendor, no community, no incident history. Internal runbook and named ownership remain prerequisites. Add host-group configuration and expected per-host sitemap inventory to the runbook; a new engineer must be able to state which URLs belong in which file and prove it.

Scaling. Same batch-processing cliffs (memory on large URL sets, PHP timeouts, the 50,000-URL / 50MB per-file limits), now multiplied by host count: N hosts means N sitemaps, N index entries, and N regeneration jobs, with memory pressure determined by the largest host rather than the total. Regeneration stays a scheduled job writing to durable storage — never request-time rendering. Caching and CDN delivery are still the right shape, and must now be keyed per host so one property's sitemap is not served from another's cache entry. Per-host caching support must be verified, not assumed.

Failure modes. Ranked by how quietly they fail, with the new ones called out:

• Cross-host URL leakage (new) — host misdetection (proxy, CDN, SNI, multi-domain routing) causes host A's URLs to appear in host B's sitemap. Produces duplicate/cross-canonical signals that are hard to trace back to the generator. Needs a hard assertion in validation that every URL's host matches its group.
• Stale sitemap — job stops, nobody notices, new pages unindexed. Needs freshness alerting on lastmod and file mtime, now per host.
• Malformed or invalid XML — crawl errors surfaced weeks late. Schema validation in CI.
• Wrong lastmod or canonical host — actively degrades crawl prioritization; worse than no sitemap.
• Missing or misconfigured host group (new) — a host silently absent from config produces no sitemap for that property, with no loud error. The new "default group" warning is a hint, not a guarantee; inventory-check sitemaps against known hosts.
• Partial or truncated file on memory/timeout — write atomically (temp file + rename) per host.
• robots.txt mismatch — sitemap not referenced, or referenced at a path that 404s. Now per host, so N chances to get it wrong.

Ramp-up. For a Symfony developer: hours for single-host, add roughly half a day to internalize host groups and proxy behavior. For a Laravel-only team: still effectively a new framework surface, and the debugging surface grew with the host-resolution code path — cost that dwarfs the feature's value. The dominant ramp-up cost remains the validation and monitoring harness around an unvetted dependency, and it is now larger because it must cover per-host correctness in addition to XML validity and freshness. That cost is fixed regardless of which package you choose, and it is the main thing to budget before committing.