Product Decisions This Supports
- Ship-or-not decision on programmatic SEO. A sitemap generator is table stakes for any URL-generating surface (catalog pages, listings, profiles, docs, blog). This package is the smallest credible way to answer "can crawlers find our long tail?" without a discovery epic.
- Build vs. buy. The scope is narrow and the protocol is frozen (sitemaps.org, 50k URLs / 50MB per file, index files for sharding). Writing this in-house is 1–2 weeks plus permanent ownership of gzip, escaping, streaming, and sharding edge cases. Buying (free, BSD-3) removes that from the roadmap.
- Scale architecture for the sitemap layer. First-class sitemap index support means sharding is a configuration concern, not a rewrite — this directly unblocks marketplace/multi-tenant models where each seller or tenant needs its own sitemap and one index ties them together.
- Crawl-budget and infra cost decisions. Gzip output and streaming generation let you regenerate sitemaps on a schedule against large tables without loading the whole set into memory. That is an argument for nightly batch regeneration instead of a queue-per-URL pipeline.
- Feature gating for SEO work. Decides whether "SEO essentials" is a v1 checkbox or a later initiative. If this is adopted, sitemap emission becomes a small, non-controversial line item rather than a roadmap candidate competing with core features.
- Stack/roadmap signal. This is a PHP library with a Yii2 integration layer first and a framework-agnostic core second. Adopting it is fine under Laravel/Symfony with a thin adapter; it is not evidence that your team should standardize on Yii. Do not let the dependency pull architectural decisions with it.
- Operational model. Encourages a "regenerate on cron/job, write to disk or object storage, serve statically" pattern — cheap, cache-friendly, and easy to monitor (file exists, URL count, last-modified freshness).
When to Consider This Package
Adopt when:
- You're on PHP and need standards-compliant
sitemap.xml plus index sharding for a URL set that exceeds a single 50k/50MB file.
- You want zero framework lock-in. The core generator is plain PHP; a 20–40 line Laravel service provider, console command, or scheduled job wraps it cleanly.
- Your sitemap is derived from data you already have (DB rows, routes, a search index) rather than something you need to discover by crawling.
- You value a small dependency surface over batteries-included DX — few transitive deps, no config sprawl.
- Maintenance expectations are calibrated to a spec-complete library. The sitemap protocol has been essentially static for years; low release velocity here is a feature, not decay. Recent releases indicate it is still tended.
Look elsewhere when:
- You need Laravel-native ergonomics out of the box — auto-discovery, publishable config, Eloquent models as sources, middleware.
spatie/laravel-sitemap (or an equivalent) covers that with more opinion and more dependency weight.
- You need crawling/discovery, not just serialization. If you don't already know your URL set and want a spider to walk the site, this is the wrong tool.
- You need rich sitemap extensions (image, video, news, hreflang alternates) as a hard requirement. Verify coverage explicitly before committing; don't assume, and don't plan a roadmap on unverified support.
- You need Google Search Console submission/ping automation as part of the flow — that's a separate integration either way.
- The site is small and static (tens to low hundreds of URLs). Hand-writing or a route-driven template is less machinery than any dependency.
- Your org requires a supported vendor or a multi-maintainer project. 543 stars and a single primary maintainer is a real (if modest) bus-factor risk. Mitigate with a fork-able copy and a pinned version, or accept the risk explicitly.
How to Pitch It (Stakeholders)
To executives: This is a free, permissively licensed (BSD-3) utility that gets our pages discovered by search engines — the cheapest acquisition channel we have — for roughly a day of engineering instead of a multi-week build. It's small, has no vendor lock-in, and fails safe: if it breaks, we lose freshness signals, not revenue-critical functionality.
To engineering: It's a focused serializer — you hand it URLs, it writes spec-compliant sitemaps and sitemap indexes, streams to disk, and gzips. The core is framework-agnostic PHP, so we wrap it in one small Laravel command plus a scheduled job and keep our own code out of the XML-escaping and sharding business. It is not a crawler and not a Laravel package — we own the ~30 lines of glue. Pin the version, write one integration test asserting well-formedness and the 50k-per-file boundary, and treat it as infrastructure rather than a product dependency.
To both: The main risk is not technical, it's governance — one primary maintainer and a narrow scope. That's acceptable for a library implementing a frozen spec, provided we pin the version and keep the adapter thin enough to swap in a day if we ever need to.