Laravel Sitemappable Laravel Package

Product Decisions This Supports

• Accurate freshness signaling (<lastmod>): 1.12.0 makes sitemap entries carry the source model's created_at/updated_at, so the generated XML reflects real content change dates instead of generation-time or null values. This directly supports crawl-efficiency and re-indexing decisions for content-heavy properties.
• Feature work — content discovery: enables "new/updated content surfaces to search engines faster" epics without bespoke cron jobs or manual sitemap editing. Pairs naturally with a content publishing roadmap (blogs, docs, listings, changelogs).
• Build vs. buy: sitemap generation is commodity infrastructure with near-zero differentiation. Adopt, don't build. The release reduces the remaining custom-glue justification (you'd otherwise write your own lastmod mapping against the package's entry model).
• Use cases unlocked: blog/knowledge-base freshness, marketplace listings that churn (price/stock-driven updated_at), multi-locale content sets requiring sitemap indexes, and programmatic SEO pages where lastmod accuracy affects crawl budget allocation across thousands of URLs.
• Instrumentation opportunity: because timestamps now flow from model data, PMs can reason about crawl behavior against actual publish/edit cadence — useful for prioritising which content templates get re-crawled.

When to Consider This Package

Adopt when:

• The product runs on Laravel and indexable content is modelled as Eloquent records (or can be mapped to them).
• You need automated, scheduled sitemap generation, sitemap indexes, or per-entity sitemap segmentation at moderate scale.
• lastmod fidelity matters — i.e. content is edited post-publish and you want change signals rather than uniform timestamps.
• You want crawl-related behaviour owned by the application, not by an external SEO tool or manual upload process.

Look elsewhere when:

• The site is statically generated (build-time sitemap plugins are a better fit) or the stack isn't Laravel/PHP.
• A CMS or commerce platform already emits correct sitemaps — duplicating them creates two sources of truth and conflicting lastmod values.
• Scale exceeds what in-application generation can serve comfortably (hundreds of thousands of URLs, high regeneration frequency); you'd want a dedicated indexing pipeline.
• You need advanced sitemap semantics beyond scope — news/video/image variants at depth, hreflang matrices, or per-URL priority tuning as a product surface.
• Data hygiene is poor: updated_at bumps on incidental writes (view counters, soft-delete touches, sync jobs) will emit false lastmod values, which erodes trust in the signal. Fix the write paths first, or scope lastmod to a dedicated content_updated_at column.

How to Pitch It (Stakeholders)

To executives: Low-cost, low-risk SEO hygiene. Sitemap freshness signals help search engines prioritise re-crawling pages that actually changed, which supports faster indexing of new and updated content — a lever on organic acquisition and time-to-index for launches. No new infrastructure, no vendor contract; the cost is a small amount of engineering review time.

To engineering: Minor version (1.12.0), additive — timestamps from the underlying model are now persisted onto sitemap entries rather than being absent or derived at generation time. Adoption is configuration plus a model/entry mapping, not a rewrite. Key review points: confirm updated_at semantics match "content changed" for each mapped model, and confirm the scheduled generation job's cadence is appropriate relative to publish frequency. Watch for models where updated_at is touched by non-content writes.

To SEO/content stakeholders: This makes the sitemap's lastmod values truthful by default. It does not change which URLs are included — coverage and prioritisation remain separate decisions — and it will not compensate for inaccurate timestamps upstream. Worth a post-release check comparing emitted lastmod values against actual edit history on a sample of high-value URLs.