Automatic Sitemaps for Laravel, WordPress & Webflow (2026)

Every CMS and framework has its own sitemap story, and none of them handle every case. A Laravel package needs a scheduled job you'll forget to check. A WordPress plugin bloats the database and breaks with aggressive caching. Webflow generates a sitemap you can't customize. Hybrid stacks — which most modern sites are — end up with three sitemaps that don't talk to each other.

This guide covers how to automate sitemaps on each major stack, where the native option works, where it breaks, and why the answer for multi-stack setups usually isn't another plugin.

Table of contents

1. Why every stack has a sitemap problem
2. Laravel sitemaps
3. WordPress sitemaps
4. Webflow sitemaps
5. Shopify, Ghost, Astro, Next.js: quick reference
6. The no-plugin alternative
7. Decision framework by stack
8. FAQ

---

Why every stack has a sitemap problem

Every stack gives you some sitemap. The problems are variations on the same theme:

• The sitemap isn't hosted where it should be. On-CMS means it shares fate with your app — when the app goes down, the sitemap goes down with it.
• Updates require something else to happen. A re-deploy, a cron job, a plugin refresh, a manual trigger. Every dependency is a chance for drift.
• You can't control what's in it. Built-in generators on hosted platforms (Webflow, Shopify) are opaque. You get what they give you.
• It doesn't handle multi-source sites. Most real sites today are hybrids: marketing on Webflow, blog on Ghost, docs on Mintlify, app on Next.js. No native plugin sees the whole picture.

The honest answer for many sites is that the sitemap should live outside the stack entirely — which we'll get to at the end. First, the stack-by-stack reality.

Laravel sitemaps

The standard option: spatie/laravel-sitemap

For Laravel developers, spatie/laravel-sitemap is the de-facto package — over 14 million installs on Packagist and actively maintained. Install:

composer require spatie/laravel-sitemap

Basic usage — crawl your own site and write a sitemap file:

use Spatie\Sitemap\SitemapGenerator;

SitemapGenerator::create('https://example.com')
    ->writeToFile(public_path('sitemap.xml'));

Or build it explicitly from Eloquent models:

use Spatie\Sitemap\Sitemap;
use Spatie\Sitemap\Tags\Url;
use App\Models\Post;

Sitemap::create()
    ->add(Url::create('/'))
    ->add(Url::create('/about'))
    ->add(Post::all())   // if Post implements Sitemapable
    ->writeToFile(public_path('sitemap.xml'));

Schedule it to run daily:

// app/Console/Kernel.php
$schedule->command('sitemap:generate')->daily();

Where this works

• Single-stack Laravel apps with models that cleanly map to URLs.
• Teams comfortable owning a custom Artisan command and its scheduling.
• Sites under ~50,000 URLs where generation stays fast.

Where it breaks

• The scheduler dependency. If you're on a platform without cron access (serverless platforms, Laravel Vapor with misconfigured schedulers, shared hosting), the sitemap never regenerates. You find out eight months later when coverage drops.
• Generation time grows non-linearly with URL count. A 10k-URL generation that takes 20 seconds becomes a 5-minute job at 100k URLs. Memory usage spikes too. On constrained instances, the command OOMs.
• Database load during generation. If your sitemap generator scans the same tables your production traffic hits, crawls can cause measurable latency at peak times.
• Multi-source content isn't covered. If your blog is on Ghost or Mintlify and your app is on Laravel, the Laravel sitemap doesn't know about the blog.
• Every new section means code. Add an /integrations section tomorrow? You write a new Sitemapable implementation and re-deploy.

For a single-stack Laravel marketing site under 50k URLs, it's the right tool. For anything larger or more complex, the "just install the package" answer stops being sufficient.

WordPress sitemaps

The standard options: Yoast, RankMath, All in One SEO

WordPress is the easiest case, in that almost every SEO plugin ships a working sitemap:

• Yoast SEO — the market leader, sitemap at /sitemap_index.xml.
• RankMath — faster-growing alternative, same URL pattern, slightly more configuration.
• All in One SEO — older option, still viable.
• Built-in WordPress core sitemap — since WordPress 5.5, core ships a sitemap at /wp-sitemap.xml. Limited customization, works fine for basic sites.

Install the plugin, flip the "generate XML sitemaps" toggle, submit /sitemap_index.xml to Search Console. That's it for most small sites.

Where this works

• Single-site WordPress installations under ~10,000 posts.
• Sites using standard post types and taxonomies.
• Teams that already use Yoast or RankMath for the rest of their SEO work.

Where it breaks

• Aggressive page caching. Full-page caches (WP Rocket, W3 Total Cache, server-side caching on managed WordPress hosts) sometimes cache /sitemap.xml for 24 hours or more. You publish a post; Google fetches the cached sitemap; your post doesn't appear for a day. Solvable with proper cache rules, but easy to get wrong.
• Database bloat on large catalogs. The sitemap is generated on every request by querying the wp_posts table. At 50k+ posts with complex taxonomies, each request runs heavy queries. On shared hosting, sitemap requests can time out under load.
• Plugin conflicts. Running Yoast and RankMath simultaneously creates two competing sitemaps. Less obvious: security or caching plugins can silently block /sitemap_index.xml from bots, breaking discovery.
• No CDN hosting. The sitemap is served from your WordPress app, not from a CDN. If your app goes down, your sitemap goes with it — and hosted WordPress platforms have more outages than most people realize.
• Multi-site installations. WordPress Multisite handles sitemaps inconsistently depending on the plugin. RankMath has the best Multisite support; Yoast Premium is adequate; the free versions struggle.

WordPress sitemap plugins are fine for single small-to-medium sites. They stop being fine at scale or on multi-site setups.

Webflow sitemaps

The built-in option

Webflow auto-generates a sitemap at yoursite.com/sitemap.xml and updates it on publish. You find it in Site Settings → SEO → Sitemap.

Where this works

• Standard Webflow marketing sites with pages, CMS Collections, and the standard structure.
• Sites where you don't care what's in the sitemap — Webflow's defaults are reasonable.

Where it breaks

• Zero customization. You can exclude specific pages, but you can't override URLs, control <lastmod> logic, add URLs that aren't Webflow pages, or change the format.
• CMS collection edge cases. Custom slug patterns, archived items, and items with conditional publish dates sometimes don't appear correctly.
• External content isn't included. If you run a Ghost blog on a subdomain or docs on Mintlify, Webflow's sitemap only covers the Webflow pages.
• No diff tracking. There's no way to know what changed between the last sitemap generation and this one — which is the most useful audit signal on any growing site.

For a pure-Webflow site, the built-in sitemap is fine. For Webflow as one piece of a larger stack (which is how most Webflow sites actually operate), it's incomplete.

Shopify, Ghost, Astro, Next.js: quick reference

The short version for each:

Shopify — Auto-generates sitemap.xml at the root. Covers products, collections, blog posts, pages. No customization, no way to exclude. Good enough for pure Shopify, opaque for anyone integrating with external tools.

Ghost — Built-in sitemap at /sitemap.xml, with per-content-type child sitemaps (/sitemap-posts.xml, /sitemap-pages.xml, etc). Clean, reliable, not much to configure.

Astro — @astrojs/sitemap integration. Runs at build time. Works perfectly if every content change triggers a rebuild; breaks the moment your content source updates without triggering one.

Next.js — next-sitemap package for pages router, built-in sitemap.(ts|js) convention in App Router. Both run at build or revalidate time. Same trade-off as Astro: content-velocity vs deploy-velocity.

Nuxt — @nuxtjs/sitemap module. Supports both build-time and runtime generation. The runtime mode handles dynamic content sources that change between deploys — but reintroduces the "sitemap competes with production traffic" problem. See dynamic vs static sitemaps for the full treatment.

Hugo — Core ships a sitemap generator, no configuration needed. Regenerates on every build. JAMstack-style — works if deploys track content.

Rails — Comparable packages to Laravel's Spatie option (sitemap_generator is the main one). Same trade-offs.

Django — Built-in django.contrib.sitemaps framework. Comparable to Laravel's Spatie package. Requires code per URL pattern.

Every one of these has the same fundamental shape: the sitemap is a function of your app, not an independent layer. That's fine for single-stack sites. It breaks for anything hybrid.

The no-plugin alternative

Here's the framing most stack-specific guides miss: you don't actually need a sitemap plugin at all.

A sitemap is a file that lists the URLs on your site in XML format. To build that file correctly, something needs to know which URLs exist — and the most reliable way to find out what URLs exist is to ask the live site. Which is what a crawler does.

External hosted sitemap tools work on exactly this principle. You give the tool your domain. It crawls the site from outside infrastructure, builds the sitemap from what it actually finds in your HTML, and hosts the result on a CDN you point Google at.

What "no plugin" means in practice

With Indexly specifically:

• No Composer package. Laravel apps stay untouched.
• No WordPress plugin. No database impact, no plugin conflict surface.
• No build-time generator. JAMstack deploys don't need to do extra work.
• No code change. Not a single line in your repo.

The integration is: paste your URL into the Indexly dashboard, get a hosted sitemap URL back, submit that URL to Google Search Console. Done.

The stack-agnostic angle

This is where the approach earns its place: if your marketing site is on Webflow, your blog is on Ghost, your docs are on Mintlify, and your app pages live on Next.js, the crawler sees one website. It discovers URLs across every subdomain and subpath you've configured, produces a single sitemap (or a sitemap index for large sites), and keeps it current regardless of which system an individual URL lives in.

There's nothing magical about this — it's just what happens when the sitemap layer isn't coupled to any single stack.

The trade-offs (because there are always trade-offs)

Honest limitations of the external-crawler approach:

1. It's HTML-based. Indexly's crawler reads HTML, not rendered JavaScript. If your site is a pure client-rendered SPA where pages only appear after JS runs, the crawler sees empty shells — same problem Googlebot has on its first pass. The fix isn't a different sitemap tool; it's server-side rendering or pre-rendering. Frameworks like Next.js (SSR), Nuxt (ssr: true), and Astro produce server-rendered HTML by default and work fine. Pure client SPAs need Prerender.io or a migration to an SSR framework.

2. Login-gated content won't be discovered. The crawler fetches as an anonymous user-agent. Pages behind authentication are invisible to it — which is correct behavior, since they should also be invisible to Googlebot.

3. Very high cadences (hourly+) require the Agency plan or event-driven API calls. The default crawl rhythm on lower plans is weekly or daily.

For most sites, none of the above is a problem. For client-only SPAs or auth-walled content, it's a dealbreaker — but those are the same sites that struggle to get indexed by any tool, including Googlebot itself.

Decision framework by stack

Run through this in order:

1. Single-stack WordPress, under 10k posts, no heavy caching? → Yoast, RankMath, or WordPress core sitemap. Done.

2. Single-stack Laravel/Rails/Django, under 50k URLs, you control the infra? → spatie/laravel-sitemap or your framework's equivalent. Schedule it daily.

3. Pure JAMstack site where every content change triggers a rebuild? → Build-time generator (next-sitemap, @astrojs/sitemap, etc.).

4. Webflow, Shopify, Ghost — pure single-platform site? → Built-in sitemap. Submit the URL and move on.

5. Any of the above, but your content is spread across multiple tools (marketing + blog + docs on different platforms)? → External hosted sitemap. Indexly is designed for this shape.

6. Any of the above, but scale is pushing you past 50k URLs? → External hosted sitemap. Native options stop scaling cleanly here.

7. You're a pure client-rendered SPA with no SSR? → Fix rendering first. No sitemap tool solves this. See why Google isn't indexing your pages.

The framework isn't "external beats native." It's "use the simplest thing that works for your actual situation." For single-stack, small-to-medium sites, native is usually right. For hybrid or scaled sites, it usually isn't.

FAQ

How do I generate a sitemap for my website?

The fastest way depends on your stack. On WordPress, install Yoast or RankMath and enable XML sitemaps. On Laravel, install spatie/laravel-sitemap. On Webflow or Shopify, one is generated automatically. For multi-stack sites or anything over 50,000 URLs, a hosted sitemap service that crawls your live site is usually simpler and more reliable.

What's the best sitemap plugin for WordPress?

For most sites: Yoast SEO or RankMath. Both generate a valid sitemap automatically, handle custom post types and taxonomies, and integrate with the rest of their SEO features. RankMath offers slightly more configuration; Yoast has broader compatibility. If you only need a sitemap and no other SEO features, WordPress core's built-in sitemap at /wp-sitemap.xml is enough.

How do I create a sitemap in Laravel?

Install spatie/laravel-sitemap via Composer, then either crawl your site (SitemapGenerator::create('https://example.com')->writeToFile($path)) or build the sitemap explicitly from Eloquent models that implement the Sitemapable interface. Schedule the command to run daily via Laravel's scheduler. For sites over 50,000 URLs or multi-source content, an external hosted sitemap often fits better.

Does Webflow automatically create a sitemap?

Yes. Webflow auto-generates a sitemap at yoursite.com/sitemap.xml and updates it whenever you publish the site. You'll find it in Site Settings → SEO → Sitemap. It covers Webflow pages and CMS Collection items with minimal configuration. The trade-off is that customization is limited — you can exclude pages, but you can't override URLs or include external content.

Do I need a sitemap plugin if my site is on multiple platforms?

Usually not — and traditional plugins rarely handle multi-platform setups well anyway. If your marketing site is on Webflow, your blog is on Ghost, and your docs are on Mintlify, each platform's native sitemap only covers its own content. A hosted external sitemap tool that crawls your domain produces a single unified sitemap across all sources, which is usually what you actually want.

What happens if I run two sitemap plugins at once?

You end up with two sitemaps, two sets of <lastmod> logic, and two places things can break. If both are submitted to Search Console, you'll often see "Duplicate, submitted URL not selected as canonical" errors. Pick one, uninstall the other, clean up the Search Console submissions. Running two sitemap generators is never the right answer.

---

The bottom line

Every stack has a sitemap solution, and every solution breaks in predictable ways. For single-stack sites under moderate scale, the native option is almost always right — Yoast on WordPress, Spatie on Laravel, built-in on Webflow. For hybrid stacks and scaled sites, the question isn't which plugin to pick; it's whether the sitemap should live inside your stack at all.

If you're running a stack where the answer is "outside," try Indexly free. Works with Laravel, WordPress, Webflow, Shopify, Ghost, Next.js, Nuxt, Astro, Hugo — anything that serves HTML. No plugin, no Composer package, no deploy required. Paste your site URL, get a hosted sitemap URL, submit it to Google once. Every page found. Every page indexed.