Sitemapamic Laravel Package

Product Decisions This Supports

• Launch readiness / SEO baseline for any Statamic build. Every content site we ship needs a discoverable XML sitemap. This package turns that from a per-project engineering task into a configuration task in the control panel — directly supports a "go-live checklist" gate rather than bespoke scope per launch.
• CMS migration decisions (platform consolidation onto Statamic). When we evaluate moving a marketing site or content hub off WordPress/Drupal, sitemap parity is a hard requirement for preserving crawl coverage and SEO equity. Having a supported addon reduces migration risk and shortens the "is Statamic viable?" answer from a spike to a checklist item.
• Multi-site / multi-market roadmap. Statamic's multi-site is one of its main selling points; a sitemap generator that understands sites and locales lets us ship regional rollouts (with alternates) without new engineering work each time we add a market.
• Editorial workflow: publish → discoverable. Auto-inclusion of published entries removes the "did someone remember to update the sitemap?" class of bug from the content operations runbook, and removes an ops ticket from every campaign launch.
• Programmatic / high-volume landing page bets. If we pursue templated landing pages (location, category, integration pages), we need dynamic route coverage and a sitemap that keeps up. This is a gating dependency for that roadmap item, cheap to satisfy now rather than retrofitted later.
• Build vs. buy on the "SEO plumbing" layer. Sitemaps are a fully specified, undifferentiated format. Buying keeps our engineers on differentiators; the vendor's adjacent SEO addon (same maintainer, SeoTamic) also gives us a bundling path if we later want meta/canonical/redirect tooling from one supplier.
• Agency / multi-tenant template reuse. If we run many small Statamic sites, one vetted addon becomes a line in the boilerplate, not a repeated decision.

When to Consider This Package

Consider it when:

• The stack is Statamic (Laravel-based). Outside Statamic, spatie/laravel-sitemap is the obvious comparison and this package is irrelevant.
• The site is content-driven and crawl discovery matters: marketing site, blog, docs, resource library, directory.
• Editors or non-engineers need to change what's included (collections, custom routes, excluded entries) without a deploy — control-panel configuration is the actual product value here.
• We need multi-site/locale coverage that a hand-rolled Antlers template would get wrong the first time.
• Sitemap correctness is important but not a differentiator — i.e., we want it done in an afternoon, not a sprint.
• We're comfortable owning the exit: small surface area, public read-only endpoint, trivial to replace with a custom route if the addon stalls.

Look elsewhere or build in-house when:

• Scale is extreme (hundreds of thousands of URLs) and we need streaming/incremental generation, sharding, or a sitemap index strategy with per-file limits and freshness guarantees. Validate against real numbers before assuming it fits.
• We need advanced sitemap extensions as a hard requirement — image, video, news — and the package doesn't cover them.
• Procurement requires a vendor with a support contract, SLA, security review, or active CVE monitoring. At 15 stars and zero dependents, there is no downstream ecosystem vetting this for us; it's a single-maintainer dependency.
• We need guaranteed long-term maintenance for a platform bet. Absorb it knowingly: pin the version, snapshot-test the generated XML in CI, and treat replacement as a day of work.
• The team already has a Laravel sitemap implementation in shared infrastructure — don't add a second pattern for the same output.

Adoption criteria I'd apply: verify current Statamic version compatibility; confirm release cadence over the last 12 months rather than trusting a single date; confirm behavior on unpublished/draft entries and on excluded collections; check caching so a large sitemap isn't regenerated per request; and confirm it plays well with whatever CDN/edge caching fronts the site.

How to Pitch It (Stakeholders)

For executives (30 seconds): XML sitemaps are how search engines find our pages — table stakes, zero differentiation, and every site we launch needs one. Right now that's either custom code per project or a manual step people forget. This addon makes it configuration instead of engineering: one small, cheap dependency that closes an SEO gap across all our Statamic sites and removes a recurring launch risk. The cost of being wrong is low — the sitemap is a read-only public file, so if it disappoints we swap it out in a day with no user-visible impact.

For engineering (the honest version): It's a small, focused addon from an active Statamic-focused shop, with an adjacent SEO product that suggests it isn't a drive-by. The risk is maintenance maturity, not code complexity: low stars, no dependents, single maintainer. Mitigations are cheap and I'd make them conditions of adoption — pin the version, wrap the route behind our own config, add a CI test that snapshots the generated XML and asserts URL counts and status codes, and monitor the endpoint in production. In exchange we avoid re-implementing locale alternates, dynamic route inclusion, and control-panel config in every project. If we're not on Statamic, stop here and use spatie/laravel-sitemap; if we need image/video/news sitemaps or six-figure URL counts, we should scope that requirement before committing.

Decision I'm asking for: approve as a default dependency for Statamic content sites, with an owner and a written replace-by plan, rather than treating each launch as a fresh build-vs-buy debate.