Sitemap Laravel Package

Product Decisions This Supports

• Build vs. buy for sitemap generation: this release moves the package from "works, but fragile" to "safe to standardize on." The added unit/feature test suite and the PHP 8.2/8.3/8.4 × Statamic 5/6 CI matrix materially reduce the maintenance risk of not owning this code ourselves.
• Platform upgrade sequencing: 2.0.0 is a hard gate for anyone still on Statamic 3 or 4. If our roadmap includes a Statamic 5/6 upgrade, this package's requirements become a dependency in that plan rather than a free-floating concern — and conversely, adopting 2.0.0 forces the CMS upgrade. Decide which direction the upgrade is driven from.
• Content freshness SLA commitments: event-based cache invalidation decouples "how long we cache" from "how fast changes appear." We can now promise editors that saved changes are live immediately without paying a regeneration cost on every request — a direct input to any editor-facing SLA or support-ticket budget.
• Performance/capacity planning: query-level filtering of entries by collection and status (instead of loading all entries and filtering in PHP) changes the cost curve on large content sets. This is the difference between "sitemap is a scaling risk on big sites" and "sitemap is a rounding error" — worth re-checking for any site with tens of thousands of entries.
• Roadmap fit for multi-site / i18n: the extracted site-prefix logic in the service provider is internal plumbing, not a shipped feature, but it signals the maintainer is cleaning up the multi-site path. Treat multi-site sitemap correctness as "improving, still worth a spot check" rather than "solved."
• Use cases this unlocks or de-risks: marketing sites and content-heavy blogs where SEO completeness matters, editorially active sites where stale sitemaps were a real complaint, and any property where we want zero custom sitemap code in our own codebase.

When to Consider This Package

Adopt or upgrade when:

• We are on Statamic 5 or 6 and PHP 8.2+, and we want sitemap generation handled by a maintained package rather than custom code.
• The site is editorially active — the old 60-second cache meant changes could lag; 2.0.0 makes new and edited content appear immediately with a 1-day cache, which is the better trade on both freshness and load.
• The content set is large enough that sitemap generation shows up in profiling, or we anticipate growth; the query-level filtering is the main reason to upgrade even if nothing is broken today.
• We have custom templates or addEntries() callers and can absorb a small, well-scoped code change — this is the one real cost of the upgrade.
• We want maintenance signals we can point at: tests, CI matrix, active cleanup. This release is a credible signal of active maintenance.

Look elsewhere or defer when:

• We are still on Statamic 3 or 4 and have no concrete upgrade timeline — 2.0.0 simply will not install, and there is no migration path within this package. Staying on 1.x is the answer until the CMS upgrade is funded.
• Our sitemap needs are highly bespoke (custom XML dialects, news/video/image extensions, complex per-entry business rules that fight the SitemapEntry model) — the 2.0.0 API tightening (typed priority, nullable lastmod) is a small preview of the friction that comes with bending a general-purpose addon.
• We need guaranteed backwards compatibility across major versions; this release is correctly semver'd but genuinely breaking, and future majors should be budgeted for the same way.
• We are not on Statamic at all — this is a Statamic addon, not a general Laravel package. For plain Laravel or other CMSes, evaluate alternatives.

Adoption criteria I'd apply before merging the upgrade: confirm PHP and Statamic versions across all environments, grep for custom templates and addEntries() usage, verify any code that reads priority as a string or treats lastmod as always-present, and spot-check multi-site output.

How to Pitch It (Stakeholders)

For executives: We use a small open-source addon to generate the XML sitemap that search engines read. The new major version fixes a real reliability problem — content edits used to take up to a minute to appear, and could crash the sitemap entirely if an entry had no modification date — and makes the addon faster and cheaper to run on large sites. It also adds an automated test suite and continuous testing across supported PHP and CMS versions, which lowers the risk of us maintaining this ourselves. The catch is a mandatory platform floor: the CMS and PHP versions must both be current, so this release is best scheduled as part of the upgrade work we already have on the roadmap, not as a standalone task.

For engineering: This is 2.0.0 of the Statamic sitemap addon. Breaking: Statamic 3/4 support is dropped (requires Statamic 5/6 and PHP 8.2+), SitemapEntry::$priority is now a float and $lastmod is nullable with an updated constructor, and the default cache expire goes from 60 seconds to 1 day. That last change is safe because cache invalidation is now event-driven — entries and terms flush the cache on save and delete — which also fixes the stale-content problem. Performance work filters entries by collection and status in the query rather than in PHP. Fixes include the null-lastmod crash and several type inconsistencies (isAbsoluteUrl returns a real bool, priority normalized to float); Generator no longer extends Facade, and site-prefix logic moved into the service provider. Upgrade work is expected to be small: audit custom templates and addEntries() callers, and any code treating priority as a string. Confidence is higher than for 1.x because the package now ships tests and a CI matrix.

One-line ask: Approve the upgrade as part of the Statamic 5/6 and PHP 8.2+ migration, with a short audit of custom sitemap templates and addEntries() callers before merge.