Statamic Xml Sitemap Laravel Package

Technical Evaluation

Architecture fit — This is a Statamic addon, not a general Laravel package. It registers a service provider via auto-discovery, publishes config/sitemapamic.php, and owns the /sitemap.xml route. Its value proposition is that it reads Statamic's content repository directly — collections, taxonomies, and per-site entry URLs — so the sitemap stays in sync with the CMS without template wiring. That makes it a strong fit only where Statamic is the content source of record. It is the wrong tool for plain Laravel apps, headless stacks serving content from elsewhere, or sites that already have a working SEO addon. As a TPM, the decision framing is narrow: this is a low-cost, low-differentiation capability that should be bought rather than built, provided we are already committed to Statamic.

Integration feasibility — Low effort. Composer require, publish config, select collections and taxonomies, verify /sitemap.xml returns application/xml. Custom URL sets cover legacy paths and externally hosted pages. Multi-site installs get per-site sitemaps and an index, which is the strongest reason to prefer this over a hand-rolled generator — hreflang/locale handling is where homegrown sitemaps usually fail. Realistic estimate: half a day for install and config, one to two days for validation, diffing, and Search Console resubmission on an established site.

Technical risk — Low to moderate, but concentrated on a business-visible surface. The sitemap is publicly crawled and SEO-critical, so defects are reputational rather than application-breaking. Principal risks: (1) route collision with an existing /sitemap.xml route or a stale static file in public/, which silently shadows the addon and makes it appear inert; (2) cache staleness after publish/unpublish or multi-site propagation, producing a sitemap that lags the site; (3) noindex or unpublished content leaking in and sending crawlers a contradictory signal; (4) governance — a small agency-maintained package with no SLA and only ~15 stars, meaning bus factor and support responsiveness are genuine concerns; (5) coupling to Statamic major versions, which gates our upgrade cadence on the maintainer's.

Release 3.5.1 assessment — A single-change patch ("Filter empty results", PR #44) that suppresses empty entries and empty result sets from the output. It removes a known false-positive class — empty <urlset>, blank <loc> values, dead URLs when a collection or taxonomy is empty. No breaking changes, no config or API surface change, no data migration. It does not alter the adoption decision or the effort estimate. Two TPM-relevant caveats: after upgrading, expect URLs to disappear from the sitemap, and confirm those were genuinely empty rather than a config error the filter is now masking; and recognise that the fix makes "misconfigured" and "correctly empty" look identical in the output, so we need an independent signal (entry count in the control panel vs. URL count in the XML).

Key questions

• Which Statamic major (3/4/5) and PHP version are in production, and is that combination inside the 3.5.x support envelope?
• Do we have an existing sitemap — route, addon, or static file — and who owns it today?
• Is there a conflicting /sitemap.xml route or a public/sitemap.xml artefact in the repo?
• Are legacy/external URLs required, or is collection and taxonomy enumeration sufficient?
• What is the cache invalidation behaviour on publish/unpublish, and does it cover multi-site propagation?
• Does the package emit a sitemap index at the 50,000-URL / 50 MB protocol ceiling, or do we need to shard?
• Do we require hreflang alternates, and does the package emit them correctly per site?
• Who is the named owner and what is the escalation path if the maintainer goes dark?

Integration Approach

Stack fit — Statamic 3/4/5 on Laravel 8–11 with PHP 8.x. The package assumes Statamic's content API and caching layer are present. Anything that bypasses Statamic — Eloquent-driven pages, external APIs, redirect-managed legacy paths — must be registered through a custom URL provider or it will simply not appear. That is the single largest correctness gap to plan and resource for; it should be an explicit line item in the estimate, not an afterthought.

Migration path — Two scenarios. (a) No sitemap today: install, configure collections and taxonomies, publish, submit to search engines. (b) Replacing an existing generator or static file: stand the new route up on staging first, diff the URL sets (added/removed/changed) against the current sitemap, and only then cut over. In scenario (b) the near-universal blocker is a leftover public/sitemap.xml that shadows the route. Removing it must be a named migration step with a checklist item, not a troubleshooting note — otherwise the install appears to do nothing and we burn a cycle diagnosing it.

Compatibility — 3.5.1 is a drop-in patch from 3.5.0: no config migration, no template changes, no data migration. Pin as ^3.5.1 so the empty-results behaviour is explicit in composer.json. Update via composer update mitydigital/statamic-sitemapamic --with-dependencies on a branch so any transitive Statamic bump is reviewed in the same diff rather than arriving silently in an unrelated release. Keep our config and any custom URL providers in application code, never in the vendor tree — that keeps a future fork or replacement contained to a small, known surface.

Sequencing

1. Install and configure in local/dev; confirm route registration and application/xml response.
2. Enumerate expected URL inventory from production content; compare against generated output.
3. Validate the 3.5.1 behaviour specifically: empty collections/taxonomies contribute nothing, no blank <loc>, no noindex/draft leakage.
4. Deploy to staging with a production-like content snapshot; diff URL sets old vs. new.
5. Confirm robots.txt references the canonical sitemap URL and no static file shadows the route.
6. Production deploy, then resubmit in Google Search Console and Bing Webmaster Tools.
7. Monitor coverage for 2–4 weeks; only then decommission the legacy generator or static file.

Step 7 is the rollback insurance — keep the old sitemap recoverable until coverage stabilises.

Operational Impact

Maintenance — Very low steady-state cost: one config file, one route, no schema, no queue workers, no cron. The only meaningful recurring task is smoke-testing sitemap output on each Statamic major upgrade — budget roughly half a day per major. Config changes are PR-reviewable and identical across environments, which is the main operational benefit over a bespoke route.

Support — Author-maintained via GitHub issues; no vendor contract, SLA, or paid tier. Acceptable for a non-transactional, read-only SEO surface, but it needs an owner and a documented fallback. Mitigation: treat the package as forkable — keep all customisation in application code so replacing or forking it is a contained day's work, not a mini-project. Escalate to build-vs-fork if the maintainer becomes unresponsive across two consecutive Statamic majors.

Scaling — Generation cost scales with content volume, not request throughput; that distinction matters for how we plan capacity. Caching absorbs most of the cost, but cold-cache regeneration on large multi-site installs can be slow enough to time out behind a proxy. Confirm behaviour at the 50,000-URL / 50 MB ceiling before any bulk content import, and pre-warm the cache after deploys and large imports so editors do not see a lagging sitemap. For sites approaching the ceiling, sitemap indexing and sharding strategy must be designed in advance, not retrofitted.

Failure modes

• Static public/sitemap.xml shadows the route — install appears inert; completely silent. Most likely single failure in migration.
• Cache staleness after publish/unpublish or multi-site propagation — sitemap lags content while the site is correct; invisible without monitoring.
• Empty or malformed entries from misconfigured collections — the class addressed by 3.5.1; validate on upgrade rather than assume.
• noindex or unpublished content leaking into the sitemap — contradictory crawl signal; needs an explicit assertion, not a spot check.
• 5xx after a Statamic or PHP upgrade — crawlers back off, indexed coverage decays quietly with no user-facing symptom.
• Custom URL providers serving stale or 404 URLs — persists until manually pruned; owner and review cadence required.
• Silent shrink — the 3.5.1 filter can hide a config regression, so URL count must be asserted independently.

Ramp-up — Low. A mid-level Laravel/PHP developer can install, configure, and validate in under a day from the README. The non-obvious knowledge is operational rather than technical: cache invalidation semantics, the static-file shadowing trap, and search-engine resubmission hygiene. Write those three into the runbook and the capability becomes fully transferable.

Recommendation — Adopt on ^3.5.1 for Statamic-backed sites; decline for non-Statamic or already-covered stacks. Treat the endpoint as production-monitored: a synthetic uptime check asserting HTTP 200 and application/xml, plus a periodic URL-count assertion to catch silent shrink, plus a CI smoke test fetching a known URL. Re-review at the next Statamic major or any 4.x release of the addon.