Drupal XML sitemaps: when a site needs one and what it must list
A Drupal site needs a reliable way for search engines to find new, changed and translated pages, and an XML sitemap is the file that tells them where those pages are. A sitemap is a discovery aid, not a ranking control. It lists canonical URLs and optional metadata such as last-modified dates and language alternates, but it does not raise a page in results, and a page left out of the file can still be crawled through internal links. The practical question for the scope is whether the site publishes enough content, often enough, that relying on links alone would leave pages undiscovered for too long. Editorial sites, catalogs, multisite estates and sites with several languages usually reach that point quickly.
Teams generally use a contributed module rather than hand-built files because the module generates the sitemap from Drupal's own entities, updates it as content is published, unpublished or aliased, and respects per-content-type and per-language settings. Two options dominate on Drupal.org: Simple XML Sitemap, which is built around per-entity-type settings and is the lighter choice for most content models, and XML sitemap, which offers a wider set of options and an additional module ecosystem for custom needs. Confirm the current release, Drupal version support and maintenance status of each on its project page before choosing. The decision belongs in the written scope because it sets how content types, languages, exclusions and sitemap chunking are designed and tested. Changing it after go-live means reconfiguring a live file and rechecking what search engines have already read.
Before the scope is signed, the team should inventory which entity types, bundles and languages must appear in the sitemap, which should be excluded (drafts, filtered listings, internal search results, thin archive pages), and who owns the decision when editors add a new content type. Ask the partner to show how the chosen module handles canonical URLs that come from Pathauto aliases, how it behaves when a node is unpublished, and where the generated files are served from in your hosting layout. Those answers determine the test plan and the monitoring you will need after launch.
Which Drupal XML sitemap module fits your site
This table compares Simple XML Sitemap and XML sitemap on the dimensions that shape configuration and maintenance work. Read each row against your content model and language setup, then confirm the current release, supported Drupal core versions and documented hreflang behavior on each project page before deciding.
| Dimension | Simple XML Sitemap | XML sitemap |
|---|---|---|
| Entity and bundle selection | Enable sitemap output per entity bundle from the module settings, with a simple on or off choice per type | Enable inclusion per entity type and bundle, with more granular control over which entities are listed |
| Multilingual output | Confirm on the project page how translated entities and language variants are listed and whether hreflang alternates are emitted | Confirm on the project page how translations are handled and whether hreflang alternates are emitted, and test the output on your languages |
| Custom links | Add custom paths to the sitemap through module configuration; confirm the supported method for your release | Add custom paths through the module interface; confirm how priority and change frequency are set for each link |
| Per-entity overrides | Confirm whether individual nodes or terms can exclude or adjust their own sitemap entry | Check whether per-entity settings can override inclusion, priority and change frequency on individual content |
| Editorial configuration load | Lower for sites with few content types, but editors may still need to understand exclusion rules | Higher for large content models, since bundle-level and per-entity settings add choices that editors and admins must maintain |
| Sitemap size on large sites | Ask how the module splits output into multiple sitemap files and index files on very large sites | Ask how the module splits output into multiple sitemap files and index files, and how generation is scheduled |
| Current release and core support | Confirm the latest stable release and its supported Drupal core versions on the project page before planning | Confirm the latest stable release and its supported Drupal core versions on the project page before planning |
How the choice changes for small, multilingual and large sites
A brochure site usually has a few content types, a small number of public URLs and one language, so sitemap work is mostly about listing the pages visitors should find and leaving out everything else. Start with the smallest configuration that covers those pages, then add scope only when a real need appears. Either contributed module can handle this scope well, so the deciding factors are usually how much per-content-type control your editors need and how much maintenance your team will accept.
- Enable entries for the basic page and any service or landing content types that editors publish as public pages.
- Exclude user profiles, the site search results page, form confirmation pages and any utility or tracking URLs.
- Exclude unpublished content and any node set to noindex, so the sitemap never contradicts the robots meta tag.
- Confirm that the canonical host (with or without www, and the https scheme) matches the URLs the sitemap emits, since a mismatch is a common launch fault.
- Document the enabled bundles in your site notes so the list is reviewed when a new content type is added.
After launch, request the sitemap file directly in a browser, check that each listed URL returns a 200 response in its canonical form, and submit the sitemap in Google Search Console and any other search console you use.
On a multilingual site, each translation usually has its own URL alias, so the sitemap must list each language version under its own address and never let one language's alias stand in for another. Decide early whether hreflang alternates will come from the sitemap module, from the Hreflang module covered in the multilingual SEO topic, or from another method. Mixing two sources for the same alternates is a frequent cause of conflicting signals, so choose one and document it.
- Enable sitemap entries for every translation that has its own published page and alias.
- Exclude language versions that fall back to the default language text, since they duplicate content and point search engines at pages that are not really in that language.
- Exclude language-neutral or untranslated nodes, unless you intentionally serve them under every language prefix.
- Confirm that each language URL resolves to its own translated alias and that alternates are reciprocal, so page A lists page B and page B lists page A.
- Decide on the x-default target (usually the language selector page or the default language home page) and confirm your developers implement it the same way everywhere.
After launch, sample one page per language, check that the alternates in the sitemap match the hreflang tags in the page source, and confirm that no URL appears in two language entries by accident.
A large estate with many content types, taxonomies and listing pages needs a deliberate inventory before any module setting is changed. The main risks are sitemap files that grow past the limits set by the sitemap protocol, faceted and filtered URLs that multiply the crawlable set, and generation jobs that compete with cron and queue work. Confirm the current file and URL limits in the sitemap protocol documentation before you design the split, because they determine how the sitemap index is organized.
- Enable each bundle deliberately from a written list, and review that list whenever a content type is added.
- Split the sitemap into index files by bundle or language so each file stays within protocol limits and can be regenerated independently.
- Exclude faceted search, filter and sort parameter URLs, thin taxonomy term pages and archived content that should return a gone or redirect response.
- Limit paginated listing pages to the pages you want crawled, rather than listing every page number by default.
- Confirm with your IndexNow provider which search engines accept notifications, and whether you want notifications on publish, update and delete events, before you connect it.
After launch, check that the sitemap index loads, that file counts match the totals reported in the CMS, that the lastmod values change when content is edited, and that generation finishes inside your cron window.
Drupal XML sitemap hreflang entries on multilingual sites
Alternate-language entries in an XML sitemap are a second way of telling search engines which translation belongs to which URL, and they must agree exactly with the hreflang annotations on the pages themselves. Each URL in a language group needs a matching set of alternates that lists every other version, uses the same absolute addresses, uses the same language codes, and includes a return link from each version back to the others. If the sitemap says one thing and the page head says another, search engines may ignore the annotation for that group. Before the build starts, confirm with the module vendor or its documentation whether the sitemap module you choose can emit alternate-language entries at all, because not every sitemap option supports them and some teams end up maintaining hreflang in two places by accident.
Translated URL aliases change the list of URLs the sitemap must contain. If Pathauto or a manual alias process produces a different path for each language, the sitemap has to list the translated path for each version, not the default-language path with a language prefix bolted on. Ask the team to inventory which content types have translated aliases, which fall back to the source language, and which should not be indexed in certain languages at all. Untranslated nodes that show the source language under a language prefix are a common source of mismatched alternates, so decide the rule for them before the sitemap is generated.
The sitemap must also match the language negotiation method the site uses, whether that is by path prefix, by domain or by a combination. A path-based setup produces one set of URLs per language on the same host, while a domain-based setup needs absolute URLs on each domain in every alternate entry. Check that the sitemap generator reads the same language configuration as the front end, and test a sample of translated pages from each language to confirm the listed URLs resolve with a 200 response and return to themselves. The detailed hreflang configuration, including the Hreflang module and page-level annotations, belongs to the multilingual SEO page in this series, so this section only covers the sitemap side of the agreement.
Sitemap size on large sites: what to split and monitor
On a large Drupal site, the sitemap stops being a single file you can regenerate without thinking about it. The decisions below connect: how files are split, which URLs earn a place, when files are rebuilt, and how much background work that rebuilding adds to cron and queues. Each one should be settled before launch, not after search engines start reporting errors.
Split into files under an index
A sitemap index points to several child sitemap files, and each child must stay within the per-file limits set by the sitemap protocol. Confirm those limits in the protocol documentation and the chunking settings of the module you choose, rather than relying on remembered figures. Split by content type or section so that a problem in one file is easy to trace and fix. Check that the index itself lists every child file and that no child is accidentally left out after a configuration change.
Exclude low-value and duplicate URLs
Large Drupal sites often generate paginated listings, filtered views, tag archives and duplicate aliases that should not appear in a sitemap. Decide the inclusion rule per content type and per route before generating anything, and align it with the canonical URLs and robots directives on those pages. A sitemap that lists URLs marked noindex or redirected sends mixed signals and wastes crawl attention. Review the exclusions after each new content type or view is added.
Regenerate on a schedule or on save
Regenerating on every save keeps the sitemap current but adds write load at the moment editors publish, and it can be expensive when a bulk import touches thousands of nodes. Regenerating on a schedule is predictable and cheap but can lag behind new content. A common pattern is to queue individual updates on save and rebuild the full set on a fixed cadence. Ask your team which pattern they will operate and test it against a bulk import.
Plan cron and queue load
Sitemap generation runs as background work, usually through cron or the Drupal queue API. On a large estate, a full rebuild can compete with editorial traffic, cache clears and other scheduled jobs for database and PHP capacity. Measure how long a full rebuild takes on a production-sized copy, decide whether it runs in a quieter window, and confirm that a slow run cannot overlap the next scheduled run. Ask any partner to show the timing and queue behavior in your environment.
Monitor for missing or stale files
A sitemap can fail silently: a child file stops regenerating, the index keeps pointing to an old file, or a cron job errors without notice. Set up checks that confirm each child file exists, that its last-modified time moves when content changes, and that the search console reports no fetch or parse errors. Log generation failures to the same channel your team already watches. Assign an owner for these alerts before launch, because a stale sitemap often goes unnoticed for weeks.
Drupal XML sitemap setup, step by step
This sequence takes a Drupal site from an agreed list of content types and languages to a generated, validated sitemap index that search engines have been asked to read and that regenerates when content changes. Each step closes with a check so the internal team and the implementation partner can confirm progress before moving on.
Confirm content scope and languages
Before any module is installed, the internal team lists which content types, taxonomy terms, user profiles and languages should appear in the sitemap, and which should not. The team also supplies the canonical domain, the list of excluded paths (such as internal search, preview or staging routes) and any sections that must stay out of search. Output: a signed-off scope document. Check: every content type in the site's content model is marked include or exclude, and the canonical domain matches the one used in redirects and hreflang tags.
Choose between Simple XML sitemap and XML sitemap
The implementation lead compares the two contributed modules against the scope document. Simple XML sitemap is the lighter option for straightforward entity inclusion, while XML sitemap offers more granular control and is commonly used where per-bundle, per-language or custom link handling is needed. Confirm the chosen module's current release supports the Drupal core version in use by checking its Drupal.org project page. Output: a written module decision with the reason. Check: the team can name the one requirement that drove the choice.
Install and configure the chosen module
A developer installs the module with Composer, enables it in a non-production environment, and sets the base URL to the canonical domain. Default settings are reviewed for each entity type, and a configuration export is committed to version control so the settings travel with the codebase. Output: a configuration export in the repository and a working sitemap in staging. Check: the module's sitemap page loads on the canonical domain without redirects or mixed protocols.
Set inclusion and exclusion rules
Using the scope document, the developer sets inclusion per content type and bundle, excludes unpublished content and the excluded paths the internal team supplied, and sets priority and change frequency only where the team has a clear reason. Language handling follows the decision made in step one, so every translated node is either listed with its language or excluded deliberately. Output: a rules table reviewed by the content owner. Check: a sample of published, unpublished, translated and excluded URLs is tested by hand, and each returns the expected inclusion result.
Generate and validate the sitemap index
The developer generates the sitemap, including the sitemap index file if the module splits large sites into several files, and checks the output against the sitemap protocol. Validation covers well-formed XML, absolute URLs on the canonical domain, correct encoding, and that no URL returns a 404, redirect or noindex response. Output: a validated index and child sitemap files saved to the staging environment. Check: an automated crawl of the listed URLs returns only 200 responses, and the index references every child file.
Submit the sitemap through webmaster tools
The internal SEO or web owner verifies the production domain in the search engine webmaster tools they use, then submits the sitemap index URL. Where the site runs several languages or domains, each property is verified separately. Output: a submitted sitemap with a recorded submission date. Check: the webmaster tool reports the sitemap as read, and the discovered URL count is close to the number the crawl produced. Any gap is investigated before sign-off.
Confirm regeneration after content changes
The developer tests that publishing, unpublishing, editing the alias and deleting a node each update the sitemap as expected, and that the cron or queue process that rebuilds the file runs on the schedule the operations team has set. The team also confirms that the sitemap is served from the production web server and that caching layers purge it when it changes. Output: a short test record and a runbook entry for the operations team. Check: each test change appears in the sitemap within the expected cycle, and the rebuild job shows in the monitoring dashboard.
Adding IndexNow notifications without losing control
IndexNow is a push notification for changed URLs, and it is separate from the XML sitemap file. The sitemap is a list that search engines fetch on their own schedule. IndexNow lets the site tell participating search engines that a specific URL was created, changed or deleted, so they can recrawl sooner. Whether it is worth configuring depends on which engines matter in your market and whether each one accepts IndexNow submissions. Confirm current support for each target engine directly with that engine before you plan the work, and confirm which contributed module or external service you will use to send the notifications, since the choice affects how keys are stored and how failures are reported. Do not treat an IndexNow notification as a replacement for the sitemap or for correct canonical URLs.
Before enabling anything, plan the verification file. IndexNow requires a key file hosted at the site root, so that the engine can confirm the site controls the domain. Decide who owns the key, where it is stored, and how it is rotated, and make sure your web server, CDN and any multisite or language-prefixed routing do not block or rewrite that file. Also decide which URLs are sent. A safe starting set is published content whose canonical URL is the one you want indexed, plus URLs that changed because of an editor action. Exclude unpublished drafts, filtered or paginated variants, and URLs that redirect. Settle when the notification fires, for example on post save, on publish, or in a batch after cron, and test that a change made through a cache-cleared page reaches the queue with the final URL.
Caching and deletion need explicit rules. If a reverse proxy or CDN serves a stale page after an edit, the search engine may read the old content even though the notification was sent, so purge the affected URLs before or alongside the notification. For deleted content, decide whether the URL returns a 404 or 410 or redirects, and make the notification match that outcome, because sending a URL that now redirects or returns a not-found status creates noise in engine reporting. Ask the module or service owner how failed submissions are logged and retried, and make sure those logs are reviewed as part of normal Drupal operations.
Security and operational risks of public sitemaps
A sitemap is a public, machine-readable index of what your site wants found, so every URL, host and key it exposes is a deliberate choice. The risks below share one root cause: the sitemap is generated from site data that changes through content workflows, migrations and module updates, and nobody checks the output after those changes.
Unpublished and restricted URLs in the sitemap
Both Simple XML sitemap and XML sitemap build entries from entity data, so unpublished nodes, access-restricted content and entities behind a permission can end up listed if the generator does not apply the same access checks as the front end. Confirm with a logged-out crawl and a test account with limited roles that the sitemap contains only URLs that anonymous visitors can load. Check this after every change to content moderation, node access or custom entity types.
Private and staging hosts listed
Sitemaps copied from a production database into staging, or generated while a staging site uses a production base URL, publish hosts that were never meant for search. The sitemap URLs follow the base URL configuration, so a clone with the wrong domain setting can list the wrong host. Make the base URL an environment-specific setting, block indexing on non-production hosts, and include a host check in the release checklist.
Internal paths leaking through custom links
Custom menu links, redirects and hand-entered paths can point to administrative routes, preview URLs or internal tools, and any of these may be picked up by the sitemap if they are included in the generated set. Review which link types and paths the sitemap includes, exclude administrative and preview routes explicitly, and inspect the file for paths that expose internal structure such as /admin or /node/add.
Stale sitemaps after migration
After a Drupal 7 migration or replatform, the old sitemap may still list URLs that now redirect or return errors, and the new sitemap may be cached with entries from before the cutover. Search engines then spend crawl effort on dead or redirected addresses. Regenerate the sitemap at cutover, clear its cache, compare it with the redirect map, and confirm that the sitemap file served by the new site is the one referenced in the robots file.
Leaked IndexNow key
IndexNow notifications rely on a key file that proves ownership of the host to the search engines receiving submissions. Anyone who obtains the key can submit URLs on your behalf, which can flood an index with spam or point it at injected pages. Store the key as a secret rather than in version control, rotate it when staff or hosting access changes, and watch submission logs for URLs you did not publish.
Module updates changing sitemap output
A minor update to the sitemap module, its dependencies or a custom entity integration can change which entities are included, how priorities are set or how file names are generated. Drupal core and contributed modules publish security releases on a fixed weekly cycle, so updates arrive regularly. Keep a documented update routine that compares sitemap output before and after each update, and schedule a periodic review tied to the core security release schedule.
Questions buyers ask about Drupal XML sitemaps
Which Drupal sitemap module should we pick, Simple XML sitemap or XML sitemap?
Pick the module that matches how many sitemap variants, languages and custom sources you need, then confirm it supports your Drupal version before the build starts. Simple XML sitemap is the lighter choice for a single site with mostly standard content types and default settings. XML sitemap offers more control over per-bundle inclusion, custom sitemap contexts and multilingual handling, which larger estates usually need. Check each module's Drupal.org project page for current compatibility, since support follows the core release cycle. The decision should be written into the scope so the team knows which fields, settings and hooks to expect.
What drives the cost of an XML sitemap engagement?
The main cost drivers are the number of content types and bundles to include, the number of languages, the amount of custom logic for excluded or generated URLs, and how much verification your organization requires. Cost has a one-time part (configuration, testing, launch checks) and a recurring part (reviewing sitemaps after upgrades and new content types). Ask for a quote that separates these lines and names who performs each task, your team or the partner. Engagements are fixed-scope, so the written scope should list the sitemap variants, the environments covered and the acceptance checks. DeployOpen does not publish prices, so the quote follows from that scope.
How long does sitemap setup take with many languages and large content volumes?
Duration depends mainly on language count, content volume and how many URL sources need special handling. A single-language site with standard content types is a much smaller task than a multilingual estate with translated aliases, many bundles and custom entities. Large content volumes add time for chunking, generation performance and testing against the crawl budget your team needs to protect. No fixed timeline applies across projects, so ask for a schedule in the written scope that ties milestones to the languages and content types included. Confirm with your own environment team how long staging and production deployments take.
What must our team supply before a sitemap project starts?
You need to supply a list of content types, bundles and entities that should appear in the sitemap, plus the languages and domains in use. Provide the current URL structure, existing sitemap files if any, and any URLs that must be excluded, such as internal search, filtered listings or staging paths. Access to a staging environment that matches production, with the Drupal version and PHP version your site runs, is needed for testing. Also name the person who approves search-engine-facing changes, because sitemap decisions affect indexing. Access to Search Console or Bing Webmaster Tools, where your organization already uses them, helps verification.
Can our internal team set up Drupal XML sitemaps without a partner?
Yes, a capable Drupal team can configure a sitemap module on a simple site, provided it has someone who understands Drupal configuration and search indexing. The gaps usually appear in multilingual settings, custom sitemap sources, performance on large sites and verification after upgrades. Decide which parts your team will own, such as routine checks, and which parts you want reviewed by an outside party. A partner can take the fixed-scope build, document the configuration and hand over a runbook so the internal team can maintain it. Whichever route you choose, the written scope should say who signs off each change.
How do we verify the sitemap output is correct?
Verify the output by checking that each sitemap file is well formed, lists only canonical URLs that return a successful response, and includes the expected languages and content types. Compare the URL counts against your content inventory, sample entries in each language, and confirm excluded paths are absent. Submit the sitemap to the search engines you use and review the reports they provide for errors and coverage. Keep a record of the checks so the same tests can run after each release. If your organization needs independent evidence, the auditor or assessor decides what evidence is sufficient; DeployOpen prepares the checks and records but does not issue assessments.
How are sitemaps maintained after Drupal upgrades and new content types?
Sitemaps need review after each core or module upgrade, because module settings, entity types and URL generation can change. Drupal core bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, according to the core release schedule, so plan a regular test cycle around those dates. Each new content type, language or custom route should trigger a sitemap check before it goes live. Document the owner of this routine and the test steps in a runbook. Upgrade work for major versions is a separate scope, and the written plan should name the sitemap checks that run as part of it.
Does a sitemap by itself protect search rankings?
No. A sitemap helps search engines discover URLs you want indexed, but it does not fix duplicate content, broken redirects, slow pages or weak metadata. Treat the sitemap as one part of technical SEO, alongside canonical URLs, redirect maps and structured data. Ask any partner to show how the sitemap connects to those other controls in the written scope. No outcome in search results can be promised from sitemap configuration alone.
Limits to confirm in your environment
The Simple XML sitemap and XML sitemap modules differ in how they handle versions, languages, custom entities and migrated URLs. Confirm each limit below with the module maintainers or in a test environment built like production, before you write the sitemap into your build plan.
Core and PHP version support
Confirm that the module release you plan to install supports your Drupal core and PHP versions, not only the version you run today. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Ask the maintainers which core versions each release line targets, then test the upgrade path on a copy of your site. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later.
Hreflang and language output
Ask whether the module writes alternate language links into the sitemap and whether it reads your language negotiation setup, including path prefixes, domains and translated URL aliases. Check how it handles untranslated nodes, and whether each language version lists every alternate URL, including a self-reference. Test with one node that has all translations and one that has only some of them, then inspect the generated XML directly.
IndexNow notification support
Confirm whether the module sends IndexNow notifications on its own, relies on a separate contributed module, or needs an external service. Ask which search engines receive submissions, how the key file is hosted, and whether updates are sent on publish, on edit or only on a scheduled run. Do not assume that a sitemap module submits changed URLs, and check that deletions and redirects are reported as your process expects.
Cache and CDN behavior
Find out how the sitemap is cached, when it is regenerated and whether the reverse proxy or CDN keeps serving an old copy after content changes. Ask whether cache tags are set on the sitemap response so that purging works. Confirm the file location and response headers in your edge configuration, and test that a newly published page appears in the sitemap within the interval you agreed with your SEO team.
Custom entities and migrated URLs
Ask whether the module includes custom entity types, bundles and taxonomy terms that your content model uses, and whether you can exclude entities or paths. After a Drupal 7 migration or replatform, check that the sitemap lists the new canonical URLs and not the old aliases or redirected paths. Confirm how the module treats URLs that return a redirect or 404, and whether it can read redirect maps from the Redirect module.
How DeployOpen scopes and delivers Drupal sitemap work
DeployOpen plans the sitemap setup for Drupal XML sitemaps: Simple XML sitemap or XML sitemap as part of a written, fixed-scope engagement, starting from how your content types, languages and URL aliases actually behave. The work is built, tested and documented inside your own infrastructure, then handed over with the runbook your team needs to operate it.
How we scope
- Inventory which content types, taxonomies, languages and custom routes should appear in sitemaps and which should be excluded.
- Confirm the sitemap module choice, sitemap size planning and whether hreflang entries or IndexNow notifications are in scope.
- Agree deliverables, testing evidence and timelines in writing before any build work starts.
How we build
- Configure the chosen sitemap module, entity inclusion rules and per-language settings in a development environment first.
- Test generated sitemap files against sample pages, canonical URLs and redirect targets before anything reaches production.
- Verify sitemap delivery, caching and regeneration behavior on cron or queues in the hosting environment you control.
How we hand over
- Document the configuration, module versions and Composer-managed changes so your team can reproduce the setup.
- Provide a runbook covering sitemap regeneration, submission checks in search consoles and troubleshooting steps.
- Walk your developers and content owners through the handover so they can make routine changes without reopening the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan sitemap checks alongside Drupal core and contributed module updates so changes are tested before release.
- Ask for the support scope, response expectations and reporting in writing as part of the quote.
