Sitemap Bundle Laravel Package

Getting Started

svc-sitemap-bundle is a Composer package for generating XML sitemaps (and, depending on version, sitemap indexes) from a set of URLs you supply. The name and 0.x versioning signal it originated as a Symfony bundle, so before wiring it into a Laravel app, confirm how it expects to be bootstrapped.

1. Install with Composer (composer require sven-ve/svc-sitemap-bundle). Pin the version — 0.4.0 sits on a 0.x line, so treat minor bumps as potentially breaking.
2. Read the actual changelog first. The 0.4.0 release notes you were given are only a compare/0.2.1...0.4.0 link, so the real changes live on GitHub. Diff 0.2.1..0.4.0 and scan for renamed classes, changed constructor signatures, and config keys before adopting.
3. Locate the entry point. Look in src/ for the sitemap generator/service and the URL-provider (or "collector"/"URL set") abstraction. That pair is what you actually use day-to-day; the framework integration layer is just glue.
4. First use case: build a controller/route that returns application/xml for /sitemap.xml, feeding it your app's public URLs (home, static pages, and one model-backed set such as blog posts or products).

For a Laravel app specifically: if the package is Symfony-bundle-shaped, either (a) use only its framework-agnostic core classes inside a Laravel service/command, or (b) skip the bundle scaffolding and re-implement the small amount of sitemap XML writing you need. Don't force a Symfony bundle's DI/config conventions into Laravel's container without checking they degrade cleanly.

Implementation Patterns

URL provider per content type. The durable pattern is one provider/collector class per source of URLs — static pages, Post::published(), Product::active() — each returning absolute URLs plus <lastmod>, <changefreq>, and <priority>. Keep the "what URLs" logic in providers and let the package own serialization.

Generate to file on a schedule, serve statically. Sitemaps for large sites are expensive to build per-request. Register an Artisan command (or a scheduled job wrapping the generator) that writes public/sitemap.xml (and sitemap-{n}.xml for indexes), then serve them as static assets. Add the command to app/Console/Kernel.php / routes/console.php and schedule it nightly, or on model events for smaller sites.

Stream large output. If your URL count is in the tens of thousands, write incrementally (XMLWriter-style streaming) rather than building one giant string. Check whether 0.4.0's generator supports streaming or chunking; the 0.2.1→0.4.0 diff is the place to confirm.

Sitemap index for scale. Above ~50k URLs or 50MB per file, emit an index that points to per-section sitemaps (sitemap-posts.xml, sitemap-products.xml). This maps naturally to your per-source providers.

Advertise it. Reference the sitemap in robots.txt (Sitemap: https://example.com/sitemap.xml) and submit it in Search Console. Also handle gzip if the package supports compressed output.

Integrate with routing / URL generation. Feed providers absolute URLs from Laravel's route()/url() helpers rather than hardcoding domains, so local/staging/production all produce correct <loc> values. Drive the base URL from APP_URL/config.

Cache invalidation. If you cache the generated file, bust it on the same events that change your URL sets (post published, product updated), otherwise stale <lastmod> values hurt crawl freshness.

Gotchas and Tips

• 0.x means breaking changes are expected. 0.2.1 → 0.4.0 is two feature bumps; assume API churn until you've read the diff. Lock the version in composer.json and test upgrades deliberately.
• The release notes are empty of substance. Don't infer behavior from the version bump alone — verify against the source at the tag. Anything not in the changelog is an assumption.
• Bundle vs. Laravel package mismatch. "Bundle" implies Symfony's Bundle class and a DependencyInjection extension. In Laravel this won't auto-register; check whether the core sitemap classes are dependency-light (they usually are) before deciding to use them bare.
• Absolute URL requirement. The sitemap spec requires fully-qualified <loc> values. Relative paths are a common silent failure — validate in your provider.
• XML escaping. Query strings and slugs with & must be entity-escaped; this is the package's job, but confirm it does it rather than string-concatenating.
• Character limits. Keep <loc> under 2048 chars and <lastmod> in W3C format (YYYY-MM-DDThh:mm:ss+00:00) — a frequent bug source when you format dates yourself.
• Memory on big sets. Eager-load the models backing your providers; a lazy N+1 across a sitemap of thousands of URLs will time out before it OOMs.
• robots.txt and auth. Ensure sitemap routes are public, and that no accidentally-private URL leaks into the generated set — providers that query models directly are the usual culprit.
• Extension points to look for: a provider/collector interface to implement, URL-transformer hooks, and config for base URL, file paths, and compression. Confirm these didn't move between 0.2.1 and 0.4.0 before wiring them in.
• Debugging: generate to stdout in a test, assert it parses as valid XML, and compare against a known fixture. A sitemap that "looks right" but fails the W3C sitemap validator is worse than none.