Sitemap workflow for regional and multilingual websites
For a regional site, build each sitemap from canonical public URLs for its host and language, remove duplicates and redirects, publish stable files, then verify and submit them as discovery hints.
Updated 7 October 2026. Keep the output and the verification step together.
Steps
- Choose the canonical hostname and protocol for every URL. Redirected HTTP URLs do not belong in the final list.
- Collect the URLs from your CMS or a reviewed list. Include public pages you want discovered, not every URL your system can generate.
- Remove duplicates, fragments, login pages, temporary URLs, noindex pages and pages that return errors.
- Generate the XML file and inspect the first, middle and last entries. Check escaping, hostname, path and protocol.
- Publish the file at a stable public address such as /sitemap.xml and fetch it from a clean browser session.
- Reference it in robots.txt and submit it in the relevant search engine tools when you have access.
- Update the source list when pages are materially added, removed or changed. Do not change lastmod just to make a URL look fresh.
Pick a regional URL source
A small static site can use a reviewed URL list grouped by canonical host and language. A large or frequently changing site should use the CMS or build system that already knows which regional pages are published and canonical. A manual file becomes risky when nobody owns the update step.
XML is for discovery
An XML sitemap helps search engines find URLs. It does not override robots.txt, noindex directives, canonical choices or access controls. It does not guarantee crawling, indexing, rankings or AI citations. Keep those outcomes out of the sitemap's purpose statement.
What belongs in the file
Use absolute URLs that return the preferred public page. Avoid redirects, duplicate versions, session parameters, search results, account pages, previews and URLs that you do not want in search. For a multilingual site, include the canonical URLs your architecture actually serves and handle alternates correctly in the site itself.
Last modification dates
Use lastmod only when a page had a significant change that a crawler should know about. A build timestamp on every URL creates noise and can reduce the value of the signal. Google ignores priority and changefreq, so do not add them as a ranking lever.
Review a generated file
Open the raw XML and search for the hostname, a known URL, an accidental fragment and a private path. Check that special characters are escaped and that the response has an XML content type. A generator can format a list, but it cannot decide whether each page deserves discovery.
Submit and measure carefully
A sitemap submission confirms that the search engine received a file or queued it for processing. It does not confirm that every URL was indexed. Use Search Console or the relevant search tool to inspect processing and search impressions after a reasonable delay.
The browser-local tool
The linked generator accepts a supplied URL list, validates one hostname, removes fragments and creates XML or HTML locally in the browser. It does not crawl a site or infer canonical URLs. Review the list before publishing it.
Europe and the US
The protocol is global, but sites often have regional hostnames, language paths and consent flows. Decide whether a URL is public and canonical for its market before adding it. Do not create near-identical regional files just to increase URL count.
Operating the file over time
Assign ownership for the URL source and the deployed sitemap. When a page is removed, decide whether it should disappear, redirect or remain as a useful replacement before changing the file. When a template changes, check whether its canonical, robots and language behavior still match the sitemap policy. Review a sample after each release rather than waiting for a search console warning.
Keep a small change log with the date, reason, number of URLs and any excluded classes. This helps explain why a page disappeared and prevents a future export from reintroducing old URLs. If the site has multiple regional hosts, keep the list for each host explicit and make the canonical choice part of the release review.
The generator can make a well-formed file quickly, but it cannot own the process. A human or build step must decide which pages are public, which URLs are canonical and whether a change is significant enough to update lastmod. Treat the sitemap as an output of publishing discipline, not as a substitute for it.
A small sitemap review log
For each release, record the source list, the count before and after, one included URL, one excluded URL and the reason for any large change. Add the live response status and the date of the last fetch. If a search tool later reports fewer discovered pages, this log helps you identify whether the file changed, the site policy changed or processing is simply delayed.
Do not manufacture freshness
A sitemap is not a place to list every possible URL or update every lastmod value on every build. A smaller, accurate file is easier to review and more useful to the systems that consume it. When an article changes only its build timestamp, keep the prior lastmod. When its answer or source changes materially, update the date and keep a note of the reason.
Questions
Does an XML sitemap improve rankings?
It can help discovery, but it is not a ranking signal or a guarantee of indexing.
Should I include every page?
Include canonical public pages you want discovered. Exclude duplicates, redirects, private URLs, errors and noindex pages.
Can the generator crawl my site?
No. It turns a supplied URL list into XML or HTML locally in the browser.