🗺️ sitemap.xml Generator
Paste a URL list (one per line) to build a sitemap.xml. Per-URL lastmod, changefreq, priority, hreflang, image and video extensions. Includes the 50,000 URL / 50 MB limit warnings.
🔒 About Privacy
- ・Your URL list is never sent to any server
- ・Generation runs entirely in your browser
- ・No signup, no login, no payment ever
0 URL
Bulk defaults
hreflang multilingual (optional)
Format: "lang: URL-prefix" per line. Applied per URL.
📄 sitemap.xml
📖 Where people get stuck
Builds a sitemap.xml from a list of URLs, with bulk lastmod, changefreq and priority, hreflang entries for language versions, and the image and video extensions. Everything runs in the browser. A sitemap does not guarantee indexing — it only says that a page exists, and whether it is listed is decided by the search engine on the merits of the content. Miss that premise and you will spend time on work that has no effect.
| Case | What happens | What to do |
|---|---|---|
| A URL is in the sitemap and still not indexed | A sitemap assists discovery; it promises nothing about inclusion. A page that is thin, duplicates another, or was merely generated from a template will not be indexed however prominently it appears in the sitemap. It can even work against you: listing a noindex page, a page whose canonical points elsewhere, a URL that redirects or one that 404s puts contradictory signals in front of the crawler. From its point of view you are asking for inclusion and refusing it at the same time, and the credibility of the whole sitemap drops. |
List only the pages you want indexed. The rule is simple, but sites that generate their sitemap automatically often break it by enumerating every page mechanically. The reason for non-inclusion is visible in the Pages report in Search Console: Discovered, currently not indexed means it has not even been crawled — judged low priority, whereas Crawled, currently not indexed means it was read and judged not worth listing, and the remedies for the two are entirely different. The first is a problem with your link structure; the second is a problem with the content. Resubmitting the sitemap without distinguishing them helps with neither. |
| Spending time tuning priority and changefreq | Google has stated publicly that it largely ignores priority and changefreq. The reason is obvious: they are self-declared by the site owner, and so many sites set every page to 1.0 and daily that the fields stopped carrying information. priority was meant to express relative importance within the site, so identical values everywhere say nothing at all. lastmod is still consulted, but it too loses credibility when every page carries today date — and static site generators default to exactly that, so sitemaps where the build timestamp is the lastmod of every page are extremely common. |
You can simply omit priority and changefreq — leaving them out costs you nothing. Spend the time instead on making lastmod the real modification time: use the updated_at column in your database, or the date of the last commit that touched the file in Git. When it is accurate, search engines recrawl updated pages sooner — one of the few parts of a sitemap that genuinely works. Conversely, do not bump lastmod without changing the content: it may provoke a crawl once, but if you keep claiming an update that never materialises, the claim itself stops being believed. |
| Exceeding the 50,000 URL or 50MB limit | The limit is 50,000 URLs and 50MB uncompressed per file, and it is the same for Google and Bing. Exceed it and the excess is not dropped — the whole file errors out, so adding the fifty-thousand-and-first URL takes down the fifty thousand that were working. On a shop or a publication, products and archives keep accumulating, so one day you simply cross the line. And you will not notice until an error appears in Search Console, which is the awkward part, because nobody looks at their sitemap day to day. | Split with a sitemap index — a <sitemapindex> listing several <sitemap> entries. The index itself holds up to 50,000, which puts the practical ceiling at 2.5 billion URLs. Splitting by update frequency is the efficient arrangement: put the pages that change often — new articles, stock levels — into one small file and keep the near-static archive in another, and the crawler visits the first frequently and the second rarely, which spends your crawl budget where it matters. Split from the start rather than when you approach the limit: changing the structure later forces a temporary rediscovery of every URL. |
A sitemap is discovered from a single Sitemap: https://example.com/sitemap.xml line in robots.txt. Registering it in Search Console is not required, but it is worth doing because you get to see the errors and the indexed count. The URLs inside are constrained: they must be absolute, and on the same host and protocol as the sitemap itself — including URLs from another domain requires verified ownership in Search Console. And a sitemap is not something you build once: URLs of deleted pages left behind produce a row of 404s and a standing warning in Search Console. This site went through that in July 2026 when the Portuguese and German versions were retired: the sitemap was trimmed from 2,016 URLs to 1,440. Treat setting up the 301 redirects and removing the URLs from the sitemap as one task — do only one of them and an inconsistency is guaranteed to remain.
📖 How to Use
-
1
Paste URLsPaste one URL per line in the text area.
-
2
Set optionsSet lastmod, changefreq, priority and hreflang as needed.
-
3
DownloadPlace the file at site root and submit it to Google Search Console.
❓ Frequently Asked Questions
What is the per-file limit?
Do priority and changefreq affect SEO?
Should hreflang go in the sitemap?
🔗 Related Tools
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.