Oc Sitemap Plugin Laravel Package

Product Decisions This Supports

• Feature/roadmap — a "table stakes" SEO capability, not a differentiator. XML sitemap generation is a compliance requirement for any content site we ship on October CMS. This package lets us close that requirement without allocating an engineering sprint to build one. It supports launch-readiness checklists and the discovery/indexation workstream.
• Build vs. buy — buy, decisively, if October is the serving layer. The alternative is 3–5 engineer-days building and maintaining URL collection, multilingual alternates, <lastmod> semantics, and cache invalidation. Adoption cost is roughly one engineer-day of setup plus a recurring automated validation check. The economics are not close.
• Architecture scope decision — this is a leaf feature, not a platform component. It serves sitemap generation inside an October CMS install. It does not serve a vanilla Laravel app, a headless/API-driven front end, or a multi-property sitemap consolidation strategy. Choosing it is implicitly a decision that October remains the serving layer for the properties in scope.
• Use cases it supports well: marketing/corporate sites on October; editorial sites where sitemap entries must follow publish/unpublish automatically; multilingual or multisite October installs (host + hreflang are configurable); catalogs where a custom model can be registered as a source instead of hand-maintaining URLs.
• Ownership model decision. Sitemap item definitions live in October's settings database, not in version control. That means content/marketing ops — not engineering — become the day-to-day owners of sitemap configuration. This is a real organizational commitment and should be decided at adoption time, not discovered later.
• Licensing consideration for distribution. GPL-2.0 is fine for sites we operate internally or for clients as a hosted service. It becomes a legal review item if we ever redistribute it inside a shipped product.
• The archived status reframes the decision. We are not "adopting a maintained dependency," we are "adopting a codebase we will own." That's still a legitimate call for a leaf SEO feature — but it belongs in the maintenance budget and in the risk register, and it rules out roadmap dependencies on future October compatibility fixes.

When to Consider This Package

Adopt when all of the following hold:

• October CMS or Winter CMS is the serving layer for the site in question.
• Content is editorially driven, so a sitemap generated from CMS pages and models is genuinely better than a static list.
• The site is small-to-moderate in URL volume, or regeneration can be pushed to a scheduled job rather than fired synchronously on editor save.
• The team already has October experience — ramp-up is hours, not weeks.
• We are willing to treat the plugin as internally owned code: pin the version, read diffs before upgrades, and run our own sitemap validation.

Look elsewhere when any of the following hold:

• The front end is not October. Vanilla Laravel, headless, or Next.js front ends need a framework-agnostic generator; this package has the wrong abstraction boundary.
• We need to consolidate sitemaps across multiple properties or brands. That calls for a scheduled generator outside the CMS, not a per-install plugin.
• Active upstream maintenance is a requirement. The repository is archived. There will be no security patches, no compatibility work for future October releases, and no issue triage. If the site is long-lived and strategic, budget for a fork or an eventual replacement.
• URL volume is very large (tens of thousands of entries) or crawl-budget precision matters enough to warrant custom <lastmod> and canonical control.
• We intend to redistribute the software in a product, where GPL-2.0 obligations need legal sign-off.
• Marketing wants a vendor SLA. There is none — support is community and upstream maintainer only, and there is no upstream activity to rely on now that it's archived.

How to Pitch It (Stakeholders)

For executives: Search engines need a sitemap to reliably discover our new content at scale, and this package produces one automatically from our CMS instead of a list someone has to remember to update. The adoption cost is about one engineer-day plus a small recurring validation check — very cheap relative to building it. The one thing to accept up front: the open-source project is archived, so we take ownership of it rather than relying on a vendor. That's a maintenance line item and a periodic upgrade review, not a blocker. It only applies to sites running on October CMS; it is not a step toward a unified sitemap strategy across all our properties.

For engineering: Install is a routine Composer + plugin-migrate step with no application code changes. The real work is verification, not integration: confirm the model query scopes exclude drafts, soft-deleted records, and noindex pages; confirm absolute URLs come from October's site definition rather than APP_URL; and confirm cache invalidation actually fires on publish. Sitemap item configuration lives in the settings database, so a fresh environment yields a valid but nearly empty sitemap without erroring — we need a seed or migration to reproduce the item set per environment. Pin the version and read diffs before any upgrade, since release notes are a changelog link only. Add a scheduled fetch-and-validate check against the live sitemap.xml with an alert on entry-count or file-size discontinuity: a malformed sitemap is an SEO incident that our infrastructure monitoring will not catch on its own.