Site Discovery Laravel Package

Product Decisions This Supports

• Build vs. buy for SEO/discovery infrastructure: Sitemaps, robots.txt, and feed discovery surfaces are mandatory for most public-facing web products but are almost never differentiating. Adopting a maintained package lets the team spend differentiation budget on product features instead of XML specs and crawler edge cases.
• Roadmap acceleration for SEO / marketing requirements: Unblocks "get us out of Google's crawl coverage gaps" style asks without committing to a bespoke sitemap pipeline that needs ongoing maintenance as content types, localization, and routing change.
• Multi-content-type discovery: Relevant when the roadmap adds new content models (blog, docs, product catalog, location pages) that each need to appear in discovery artifacts — a package handles the aggregation logic more reliably than hand-rolled controllers.
• Deprecation / refactor safety: A stable 1.x release line (now at v1.0.49, spanning v1.0.43 → v1.0.49) with no breaking-change signal suggests adopting is low-risk and that future minor updates likely won't force app-level rewrites.
• Reducing maintenance surface: Consolidating discovery behavior into one dependency makes it easier to audit for correctness (canonical URLs, lastmod accuracy, sitemapindex limits) than scattered controllers.

When to Consider This Package

Adopt when:

• You run a Laravel app with public, indexable content and no existing sitemap/discovery layer.
• You have multiple content types or a CMS-driven site where URLs are not statically enumerable.
• You want discovery artifacts to be generated from application state (models, routes) rather than a static file someone forgets to update.
• You want an actively maintained, small-footprint dependency — the steady cadence of point releases through v1.0.49 is a positive maintenance signal.

Look elsewhere or build in-house when:

• Your CDN or edge platform (Cloudflare, Fastly, Vercel) already generates and serves discovery artifacts at the edge — adding an app-level package duplicates responsibility.
• You need advanced SEO/analytics features (crawl budgeting, indexation monitoring, structured-data validation) — this is a generator, not an SEO platform; pair it with a dedicated auditor.
• You have non-standard discovery requirements (custom XML vocabularies, WebFinger / host-meta, or protocol-level discovery) that a general package won't cover cleanly.
• You are heavily multi-tenant with per-domain discovery and strict isolation requirements — verify tenant scoping before adoption.

Caveat on this release: v1.0.49 ships with only a compare-changelog link (v1.0.48...v1.0.49) and no itemized notes — the second consecutive point release to do so. Treat it as a maintenance/patch release: no evidence of breaking changes, no evidence of new capability. Do not plan roadmap work around it, and do not assume it is a pure no-op purely on the version number: budget a short diff review (v1.0.48...v1.0.49) before bumping, and pin the version in composer.json so upgrades are deliberate rather than incidental. The absence of a major-version bump preserves the "safe to adopt" signal, but release-note hygiene is thin enough that we should verify rather than trust the changelog.

How to Pitch It (Stakeholders)

For executives: This is a small, mature, actively maintained open-source Laravel component that covers a mandatory-but-undifferentiated capability — making our site discoverable to search engines. Adopting it removes a recurring maintenance tax from the engineering team and lets us meet SEO/marketing requests faster. Risk is low: it's on a stable 1.x line, its latest release (v1.0.49) is a patch update with no breaking changes, and the dependency footprint is small enough to replace if needed. The one process cost is that recent releases ship with auto-generated changelogs only, so we will pin the version and review diffs before each upgrade — a few minutes of engineering time, not a project.

For engineering: Standard Composer install into a Laravel app; it generates discovery artifacts from application state, so sitemaps stay in sync with content changes rather than drifting from a hand-maintained file. Version v1.0.49 is a maintenance release off v1.0.48 with no indicated API changes — expect a drop-in upgrade, but since the changelog is a bare compare link, skim the diff (v1.0.48...v1.0.49) before merging. Recommendation: pin the minor version, prototype integration in a branch, validate output (canonical hosts, lastmod correctness, sitemapindex behavior at scale, tenant isolation if applicable) against a staging crawler, then ship behind the existing route layer.