Nuxt Sitemap

Nuxt Sitemap is a module for Nuxt that automatically generates XML sitemaps to help search engines understand and index your site structure more effectively. It provides a sitemap.xml file that stays up-to-date with your site's content, reducing the manual effort required to maintain sitemaps for large or complex sites.

Key capabilities include:

• Automatic generation of sitemap.xml (supports single or multiple sitemaps like /posts-sitemap.xml).
• Support for lastmod dates and image discovery.
• Integration with Nuxt I18n and Nuxt Content.
• Support for SWR caching and Nuxt route rules.
• Ability to fetch sitemap URLs from external sources.
• Debugging tools via Nuxt DevTools or XML Stylesheet.

Nuxt Sitemap is a module designed to generate best-practice XML sitemaps for web crawlers. Key capabilities include:

• Sitemap Structure: Supports a single /sitemap.xml or multiple split sitemaps (e.g., /posts-sitemap.xml, /pages-sitemap.xml).
• Dynamic Data: Ability to fetch sitemap URLs from external sources or APIs.
• SEO Best Practices: Automatic generation of lastmod tags and image discovery.
• Performance: Supports SWR (Stale-While-Revalidate) caching and Nuxt route rules.
• Developer Experience: Debugging via Nuxt DevTools integration or XML Stylesheet.
• Integrations: Seamless compatibility with Nuxt I18n and Nuxt Content.

Starting with v4.0.0, Nuxt Sitemap introduces the concept of Sources. Every URL in your sitemap is categorized into one of two types:

1. User Source: URLs explicitly provided by the user.
2. Application Source: URLs automatically discovered or generated by the application.

This distinction helps manage how different sets of URLs are grouped and displayed, especially in multi-sitemap configurations. For detailed implementation details, refer to the Sitemap Sources documentation.

Sitemap URLs in @nuxtjs/sitemap are categorized into two types:

1. Application Sources: Automatically discovered from your Nuxt application (e.g., static pages, prerendered routes, Nuxt Content, or Nuxt I18n). Most sites rely on these automatically.
2. User Sources: Manually provided by you. These are necessary for dynamic routes originating from external databases or CMSs that are not handled by automatic discovery or prerendering.

If you need to prevent the module from automatically including certain parts of your app, you can use the excludeAppSources configuration option.

By default, the module sets sortEntries: true, which sorts all resolved URLs by their loc value before splitting them into chunks. This means the original order returned by your data source is not preserved.

If you need chunk boundaries to follow the specific order returned by your source, set sortEntries: false in the global sitemap configuration.

Warning: When using sortEntries: false, ensure your source is deterministic. Adding or removing entries can shift URLs between different sitemap files, requiring you to update the sitemap index lastmod for all affected files.

export default defineNuxtConfig({
  sitemap: {
    sortEntries: false,
    sitemaps: {
      posts: {
        sources: ['/api/posts'],
        chunks: true,
      }
    }
  }
})

When you use Nuxt prerendering (via nuxi generate or Nitro prerender options), the sitemap module automatically scans the generated HTML to discover and add content to your sitemap. This is particularly useful for including dynamic routes in your sitemap with minimal manual configuration.

The module extracts the following data from the raw HTML:

• Images: Adds <image:image> entries by scanning <img> tags located within the <main> tag. You can opt-out by disabling discoverImages.
• Videos: Adds <video:video> entries by scanning <video> tags located within the <main> tag. You can opt-out by disabling discoverVideos.
• Last Modified Date: Adds <lastmod> entries using the OpenGraph article:modified_time and article:published_time meta tags.

While zeroRuntime: true optimizes performance and bundle size, it introduces the following constraints:

• No Runtime Generation: Sitemaps are only generated during the build process; you cannot generate them on-the-fly at runtime.
• Static Data Only: Dynamic data sources that require runtime fetching (e.g., a CMS that updates without a redeploy) will not work.
• No Debug Endpoints: Debugging endpoints are disabled when zero runtime mode is active.

When to use:

• Your pages only change when you commit and deploy.
• You are using nuxt generate for a fully static site.
• You want to minimize server bundle size for edge or serverless environments.

When NOT to use:

• Your CMS updates content without requiring a redeploy.
• You have user-generated content that changes frequently.
• Your sitemap URLs depend on runtime data.

The sitemap module integrates automatically with @nuxtjs/i18n and nuxt-i18n-micro. It operates in two primary modes depending on your i18n configuration:

1. Automatic I18n Multi Sitemap: Triggered when you are not using the no_prefix strategy or when using Different Domains. This mode generates a separate sitemap file for each locale (e.g., en-sitemap.xml, fr-sitemap.xml) and automatically includes app sources. The nuxt:pages source will correctly determine alternatives for your pages.

2. I18n Pages Mode: Triggered when you enable i18n.pages in your i18n configuration. This mode generates a single sitemap. Unlike Multi Sitemap mode, it does not include app sources automatically, but you can add URLs via the sources option.

When using multiple sitemaps, the sitemap_index.xml file contains <lastmod> entries for each individual sitemap file.

• The lastmod in the index refers to when the sitemap file itself changed (e.g., due to adding or removing a URL).
• The lastmod inside the individual sitemap files refers to the page modification dates.

If you cannot produce a reliable date for a sitemap file change, it is better to leave the field out than to provide an inaccurate one. You can use the sitemap:index-resolved Nitro hook to set these dates from your database or metadata.

If you have automated scripts or CI/CD jobs that attempt to "ping" Google using the google.com/ping?sitemap=... endpoint, these will now fail.

Google deprecated the sitemap ping endpoint in January 2024. You should remove these pings from your deployment process and instead rely on robots.txt discovery or manual submission via Google Search Console.

Dynamic sitemaps resolve URLs at request time from a live data source instead of being baked into a static file at build time. This is ideal for content that changes frequently without requiring a new deployment, such as blog posts, products, or user-generated content from a CMS or database.

When to use dynamic endpoints:

• When routes are stored in an external database or CMS.
• When the crawler cannot discover URLs from the build output alone.
• When you need to transform external data into your site's specific URL structure.

Note: If your routes are already being prerendered by Nuxt (nuxi generate or route rules), the module can extract data directly from the rendered HTML without needing a runtime endpoint.