Statamic Xml Sitemap Laravel Package

Product Decisions This Supports

• Build vs. buy (buy, clearly). This is commodity plumbing, not differentiation. Roughly one developer-day to install, configure, and validate versus an estimated three-to-six days to hand-roll an equivalent (route, XML view, collection/taxonomy enumeration, multi-site handling, size-limit sharding) plus permanent ownership of an SEO-critical endpoint. The package converts an engineering project into a configuration task.
• Launch readiness and content-migration gates. For every new site build or CMS migration we run, "sitemap exists, is valid, and is submitted" is a checklist item. This package turns that item into a half-day rather than a named workstream, which shortens the tail of migration projects where SEO plumbing is usually the last thing done and the first thing forgotten.
• Cost of adding content types. Because coverage is driven by Statamic collections and taxonomies via config, launching a new section (blog, case studies, docs, glossary) inherits sitemap coverage automatically. That removes a recurring "SEO follow-up ticket" from every content-type launch and makes the marginal cost of new content surfaces near zero.
• Indexation policy becomes an explicit product decision. Inclusion, exclusion, priority, and change-frequency live in a versioned config file reviewed in PRs. That lets us make deliberate decisions — "this collection is noindex and stays out of the sitemap," "this legacy URL set is deliberately included" — instead of the decision being an accident of who wrote the template.
• Multi-market expansion. Per-site sitemaps and index files are the reason to prefer this over a homegrown generator if we run multiple locales off one Statamic install. It makes international expansion cheaper, but note that hreflang alternates are an open question — do not gate a locale launch on this package alone until that is verified on staging.
• Legacy sitemap retirement. Where we currently ship a static public/sitemap.xml or a bespoke generator, this package gives us a clean cutover path (staging, diff old vs. new URL sets, then swap). That is a risk-managed replacement rather than a leap of faith.
• Ops investment decision. Adoption implies a small, permanent commitment: treat /sitemap.xml as a monitored production surface (uptime check for HTTP 200 + application/xml, plus a periodic URL-count assertion to catch silent shrink). Budget half a day per Statamic major upgrade for smoke-testing.
• What we are explicitly not buying. No hreflang guarantees, no image/news/video sitemap extensions out of the box, no vendor SLA, no commercial support tier. If a roadmap item depends on any of those, it is our work, not the package's — decide that up front rather than discovering it in a launch retro.

When to Consider This Package

Consider it when:

• Statamic (3/4/5) is the content source of record and entries are reachable through Statamic's collections, taxonomies, and routing.
• The site has no sitemap today, or has a static file / bespoke generator that is drifting from reality and nobody wants to own it.
• Expected URL volume per site is comfortably under the 50,000-URL / 50 MB protocol ceiling, or we are prepared to shard by collection.
• Multi-site / multi-locale is on the roadmap and per-site sitemaps plus index files are wanted without custom work.
• There is a small number of edge URLs (landing pages, legacy paths, externally hosted marketing pages) that can be enumerated through a custom URL provider — and those are genuinely enumerable, not dynamic.
• The team does not have dedicated SEO engineering capacity and would rather spend its time on revenue-facing features.
• We are comfortable with an agency-maintained dependency on a non-transactional surface, and are willing to fork if support lapses.

Look elsewhere when:

• The application is plain Laravel, or headless with content served from a separate CMS/API — the package's value proposition evaporates.
• We already pay for an SEO platform or another addon that emits sitemaps. Two generators means duplicate, conflicting, or silently competing endpoints; pick one and remove the other.
• Requirements include first-class hreflang, image/video/news sitemaps, or automatic sitemap-index sharding at scale. Those are build items, and a heavier-weight or commercial solution may be a better fit.
• Procurement, security review, or an SLA applies — there is no vendor contract here, and a small single-maintainer project will not clear a formal dependency review in a regulated context.
• Content volume is large enough that cold-cache generation risks timing out behind a proxy, and there is no appetite for pre-warming.
• There is an ownership conflict: an existing /sitemap.xml route, a stale static file in public/, or a competing SEO addon. Resolve the conflict before considering adoption, not after.

How to Pitch It (Stakeholders)

To executives: This closes a search-visibility gap for roughly a day of engineering and zero licensing cost. It ensures search engines can discover every page we publish — including new content types and new locales — without anyone remembering to do anything. The risk is deliberately bounded: it is a config-and-one-route change, it touches no customer data and no transaction path, and because we keep our configuration in our own codebase it can be swapped or forked in a day if the maintainer disappears. The only real exposure is a temporary dip in indexed coverage if the endpoint breaks, which we mitigate with a single uptime monitor.

To engineering: composer require, auto-discovered service provider, publishable config, one route, no schema, no queues, no template changes. Pin ^3.5 and take 3.5.1 — a one-line patch that filters empty results and removes a known class of malformed-output false positives. Three non-obvious things to put in the runbook: a static file in public/ will shadow the route and make the install look inert; cache invalidation on publish/unpublish (and multi-site propagation) is the most likely cause of stale output, so bypass Statamic's static cache, the CDN, and any response cache before touching config; and the empty-result filter can mask a genuine misconfiguration, so compare CP entry counts against XML URL counts after config changes. Treat the endpoint as production-monitored and re-smoke-test it on every Statamic major — that is the entire maintenance bill.