Sitemap Laravel Package

Product Decisions This Supports

• Organic acquisition roadmap: Decides whether SEO discoverability is a launch blocker or a fast-follow. If our content is public and indexable, sitemap generation is table stakes for new marketing pages, catalogs, docs, or listings — this package makes that a config-and-schedule task rather than a build item.
• Build vs. buy for a commodity capability: A sitemap generator is undifferentiated infrastructure. Adopting an MIT library at ~0 cost beats a 1–2 sprint internal build, and beats a paid SEO platform when sitemaps are the only capability we actually need from it.
• Content lifecycle design: Supports decisions on when sitemaps regenerate (publish/update events vs. nightly cron vs. on-demand), which in turn drives queue, caching, and invalidation choices in the CMS/content pipeline.
• Multi-tenant and multi-domain architecture: Forces an explicit decision on per-tenant vs. per-domain vs. single global sitemap, and on how tenant onboarding provisions a new sitemap URL. This is a product/architecture decision, not just an implementation detail — and, post-v1.0.4, also a decision about who is allowed to influence the output filename.
• Localization and internationalization scope: Whether we invest in alternate-language annotations, regional URL structures, and per-locale sitemaps — a roadmap input for expansion into new markets.
• Consolidation and tech-debt prioritization: If multiple services or teams have hand-rolled sitemap code, this is a candidate to standardize on, reducing inconsistent output and duplicated maintenance.
• Launch-readiness criteria: Gives a concrete, testable checklist item (valid XML, reachable sitemap, submitted to search consoles, lastmod accuracy) for every public-surface release.
• Security-patch responsiveness as a standing input: v1.0.4 shows this dependency can ship a filesystem-safety fix on a patch version. That argues for a pinned-version policy with a defined review cadence, and for never letting tenant- or user-supplied strings flow into Sitemap::store().

When to Consider This Package

Adopt when:

• The stack is PHP, Laravel, or Symfony — the framework-agnostic design means one dependency covers multiple services without a rewrite.
• Sitemaps must be generated dynamically from a database, CMS, or catalog rather than hand-maintained, and the URL set changes frequently.
• The catalog is in the small-to-mid range (roughly up to the standard 50k-URL / 50MB per-file limits, with sitemap-index support for sharding). Confirm index support in the current release before committing.
• We want a small, permissively licensed, dependency-light library we can wrap behind an internal interface.
• The team has no existing sitemap capability and no SEO platform already emitting sitemaps.
• We can pin to v1.0.4 or later; earlier 1.x versions accept filenames in Sitemap::store() without path-traversal rejection.

Look elsewhere when:

• The stack is not PHP — a Node, Python, or Go service gets no value from a PHP package and should use its native equivalent.
• The site operates at very large scale where sitemap generation is a distributed job tied to crawl-budget analytics, log-file analysis, and index-coverage monitoring; that is a platform concern, not a library concern.
• Requirements include advanced formats or annotations (image/video/news sitemaps, hreflang alternates) — verify support explicitly; if absent, budget for extension work or choose a more feature-complete option.
• The roadmap includes programmatic search-console submission or indexing APIs, which sit outside a pure XML generator.
• Supply-chain risk is unacceptable: with a single-maintainer profile, zero listed dependents, and a low opportunity score, this is a convenience dependency, not an ecosystem standard. If the org requires vendor SLAs, multiple maintainers, or high dependents as a proxy for durability, treat adoption as a spike, not a commitment. Note the counter-signal: a same-day-style security patch is a good sign of maintainer responsiveness, but one fix does not change the underlying bus-factor.
• Any deployment would write sitemap files based on user-, tenant-, or request-derived filenames and we cannot enforce sanitization in our own wrapper.
• We already have a framework-native or established alternative in place; migration cost likely exceeds the benefit.

How to Pitch It (Stakeholders)

For executives: This is a low-cost enabler for organic acquisition, not a differentiator. It is MIT-licensed, free, and replaces a small internal build with a config-and-schedule task — roughly a sprint of engineering avoided. Adopting it carries minimal financial exposure; the real risks are maintainer durability and dependency hygiene, which we contain by wrapping it behind our own interface and pinning versions. v1.0.4 is a security-hardening patch (rejects path traversal when writing sitemap files), so the recommendation is unchanged in direction but now includes a minimum version floor: adopt at v1.0.4+, not earlier. Recommend a time-boxed evaluation rather than a long-term strategic commitment.

For engineering: Framework-agnostic, works across our Laravel and Symfony services, and is small enough to audit in an afternoon. The integration surface is narrow — generate, shard, write, serve — so we should own that boundary with an internal SitemapGenerator contract and contract tests on the XML output. Pin to >=1.0.4: v1.0.4 fixes a path-traversal issue in Sitemap::store() where a crafted filename could escape the intended output directory. Action items: (1) bump the constraint and lockfile in every service; (2) grep for any call site passing tenant IDs, slugs, or request input into store() and sanitize at our wrapper boundary regardless; (3) treat the output directory as write-only and non-executable, and confirm it is not web-servable beyond the sitemap files themselves; (4) add a regression test asserting traversal sequences (../, absolute paths, null bytes) are rejected before they reach the library. Vendor the dependency, watch the release cadence, and assume we may need to fork or replace it. Do not let it leak into domain logic.

For SEO/marketing: Gives us programmatic, always-current sitemaps tied to content publication rather than a stale static file. The v1.0.4 fix is an internal file-writing hardening change with no effect on sitemap output, XML format, or search-engine behavior — no re-submission is required for existing sitemaps beyond our normal regeneration. Confirm up front which annotations we need — if image, video, news, or hreflang support is out of scope for the library, that becomes a scoped extension in our own code, and should be reflected in the launch checklist rather than assumed.