Laravel Sitemap Laravel Package

Product Decisions This Supports

• Technical SEO as a shippable feature, not a vendor line item. The package lets us generate sitemaps programmatically from our own domain data, which means "indexability" becomes a backlog item we can scope, estimate, and measure in Google Search Console rather than something we buy as a black box.
• Build vs. buy, resolved toward "buy" (at zero cost). MIT-licensed, ~2.6k stars, maintained by Spatie with an active changelog through Laravel 11 and PHP 8-only support. The engineering we avoid is real but unglamorous: XML serialization, sitemap-index generation, per-tag namespaces (image, video, Google News), and maxTagsPerSitemap splitting logic.
• Roadmap input: which sections deserve crawl budget. The writeToFile(fn (Url $url) => ...) closure lets us route URLs into separate sitemap files by section (e.g. /blog vs. the rest), and returning null excludes a URL entirely. That's a direct product lever: we can decide per section whether it gets indexed, and then read coverage per section in Search Console instead of guessing from one monolithic file.
• Model-driven freshness. Implementing Sitemapable (toSitemapTag()) ties sitemap entries to Eloquent models, so publishing, unpublishing, or renaming a post updates the sitemap without a separate content-ops step. This removes a recurring class of "the sitemap is stale" bugs that typically fall to whoever owns marketing ops.
• Two viable launch strategies, one dependency. Crawl-based generation (SitemapGenerator::create('https://example.com')) gets us coverage in an afternoon with no route inventory; manual Sitemap::create()->add(Url::create(...)) gives us precision when we need it; the hybrid (getSitemap()->add(...)) covers "crawl the long tail, hand-curate the money pages."
• Concrete use cases worth prioritizing: blog/content marketing surfaces, ecommerce PDP and category pages, multi-section marketplaces, Google News for editorial, image and video discovery for media-heavy catalogs, and setLastModificationDate on pages where freshness signals matter.

When to Consider This Package

Adopt when most of the following hold:

• The app is Laravel on PHP 8+, and the team is already comfortable with the Spatie package family (crawler, medialibrary) so dependency and upgrade behavior is familiar.
• Pages are server-rendered and linked — the generator's core value is crawling, and crawling only works on HTML that contains real <a href> links.
• We need programmatic, reproducible sitemap output (CI, scheduled job, deploy hook) rather than a CMS plugin.
• We need sitemap indexes and per-section splitting at a scale where a single file is either too large or too coarse for Search Console reporting.
• We need image/video/news extensions — these are genuinely tedious to hand-roll and are the strongest argument for the dependency.
• SEO ownership sits in-house, so we want the sitemap inside our codebase and our review process.

Look elsewhere when:

• The site is a JS-rendered SPA or heavily client-hydrated; the crawler will see shells, not content. Fix rendering first, or enumerate URLs from the database instead of crawling.
• The catalog is very large or highly dynamic and a full crawl is slower and costlier than a query. At that point, driving Sitemap directly from a query (or a queued job per shard) is the better architecture — the package still helps, but the crawl mode does not.
• A CMS or commerce platform already owns sitemaps (WordPress, Shopify). Duplicating it creates two competing sources of truth.
• We need governance-heavy SEO features the package does not model: hreflang matrices, per-locale index trees, analytics-driven priority scoring, or edge/CDN on-demand regeneration. Expect custom work on top.
• The crawler dependency version is pinned by another package in the tree and conflicts — it's the main coupling risk here.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed dependency from a well-known Laravel vendor that turns sitemap generation from a manual, error-prone chore into a scheduled, code-reviewed job. It costs one composer require and a few hours of integration, and it makes search visibility measurable — we can report index coverage per site section in Search Console instead of a single undifferentiated number. No vendor contract, no lock-in, no per-URL pricing.

To engineering: Narrow surface area, one dependency, PHP 8+ only, actively released (latest 2026-06-24) with passing tests, PHPStan, and documented changelog. Supports Laravel 11, model-driven entries via the Sitemapable contract, crawl-plus-manual hybrid generation, multi-file output with a generated index, maxTagsPerSitemap chunking, and image/video/Google News tags. Integration is typically a scheduled command writing to public/, or writeToDisk() if we'd rather use the storage disk.

The honest caveats to state up front: crawling our own production site from production has a real cost — schedule it off-peak, cap the crawl, and exclude admin/account/search-filter URLs with filters or null returns. Crawler-version coupling is the main upgrade friction. And crawling is a poor fit if any key surface is client-rendered; that's a rendering problem this package cannot solve for us.