Weave Code
Laravel Sitemappable Laravel Package
vursion/laravel-sitemappable
A Laravel package that makes Eloquent models sitemappable, letting you generate XML sitemaps directly from your models with configurable URLs, last-modified dates, priorities, and change frequencies for better search engine indexing.
An XML sitemap generator for Laravel.
Frequently asked questions about Laravel Sitemappable
- How do I install vursion/laravel-sitemappable in a Laravel application?
- Install it with composer require vursion/laravel-sitemappable; package auto-discovery registers the service provider, so you should not need to add it to your providers list manually on modern Laravel versions. Publish the package config (typically via php artisan vendor:publish) so you can control which models are included and how their URLs are emitted. No migrations or schema changes are involved, because the package only reads attributes your models already have.
- How do I make an Eloquent model sitemappable?
- Apply the package's sitemappable contract to the model and implement the method that returns the entry's URL along with its metadata. From that point the model becomes a source for the generated sitemap, with priority, change frequency, and last-modified values coming from your config or the model's own attributes. Because entries are derived from models rather than crawled routes, the sitemap stays aligned with the canonical URL set your application already persists.
- Do I generate the sitemap with a command, the scheduler, or a route?
- Generation is a read-side batch job that produces a static XML artifact, so the usual pattern is running the package's generation command from the Laravel scheduler or your deploy pipeline and writing to a local or S3 disk. Nothing touches the request path, and a queue worker is only needed if your deployment already generates asynchronously. For large model sets, verify how generation handles chunking and memory, since the sitemap protocol caps a single file at 50,000 URLs and 50 MB uncompressed; beyond that you need a sitemap index splitting entries across multiple files.
- Can I configure priority, changefreq, and lastmod per model?
- Yes. The package's purpose is configurable URLs, last-modified dates, priorities, and change frequencies per sitemappable model. Release 1.12.0 adds lastmod emission by mapping a model's existing created_at and updated_at attributes onto the lastmod element. Whether that emission is opt-in, default-on, or controlled by a config toggle should be confirmed against the published config stub before you depend on it.
- Which Laravel and PHP versions does laravel-sitemappable support?
- Check the require constraints in the package's composer.json rather than assuming; the package targets PHP 8.x and a specific Laravel support range. If your application runs an older Laravel major, verify the constraint before upgrading, because a mismatch fails at composer install rather than at runtime. Pinning to the exact minor version you validated in staging is the safest move for a production upgrade.
- Is updated_at a reliable source for sitemap lastmod?
- Often it is not. Many codebases bump updated_at on counter increments, touch() calls from related models, admin toggles, or queue-driven denormalization, and publishing those values as lastmod teaches crawlers that the field is noise, which is why Google explicitly ignores lastmod when it finds it unreliable. If your updated_at does not mean content changed, prefer a dedicated content-modified column or omit lastmod entirely. That is a decision about your data, not a defect in the package.
- What format should lastmod use, and does the application timezone matter?
- The sitemap protocol requires a W3C datetime, which in practice means ISO 8601 with an explicit offset or a UTC Z suffix. If your application timezone is not UTC and Carbon instances are rendered without explicit normalization, you get values that are technically valid but inconsistent across entries, and this is the most likely defect in any lastmod feature. Inspect the generated XML for a few rows and confirm the output respects config('app.timezone') the way you intend.
- Do I need to republish the config file when upgrading to 1.12.0?
- Diff your published config/sitemap.php against the package's current stub. Laravel merges package config additively, but keys added after you originally published do not appear in your copy, so a new lastmod toggle can look silently inert or fall back to a default that differs from your intent. Either republish and merge your customizations back, or copy the new keys in by hand, then regenerate and inspect the XML to confirm the feature is actually active.
- How do I test sitemap generation in my Laravel test suite?
- Create a handful of models with factories, run the generation entry point against a fake or temporary filesystem disk, and assert on the resulting XML. Asserting against the raw string is brittle; parsing with SimpleXML and checking specific nodes survives formatting changes better. Also cover the null case, such as a model with timestamps disabled or a missing updated_at, to confirm lastmod is omitted rather than emitted empty or as an epoch value.
- How does it compare to spatie/laravel-sitemap, and is the package actively maintained?
- Spatie's package is primarily aimed at crawling routes and building sitemaps from HTTP responses, while laravel-sitemappable derives entries directly from Eloquent models, which suits sites whose canonical URL set already lives in the database. Choose based on where your URL truth lives rather than on feature checklists. On maintenance, check the repository's recent commits, tagged releases, and open issues against your Laravel version before committing, and pin the minor release you validated in 1.12.0.
Weaver
How can I help you explore Laravel packages today?