What a valid urlset actually contains - and where sitemap index generator fits
A sitemap is a <urlset> in the sitemaps.org 0.9 namespace holding one <url> per page. Only <loc> is required. <lastmod>, <changefreq> and <priority> are optional, and two of those 3 are dead weight (more on that below).
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.example.com/pricing</loc>
<lastmod>2026-08-01</lastmod>
</url>
<url>
<loc>https://www.example.com/blog/seo-guide</loc>
<lastmod>2026-07-14</lastmod>
</url>
</urlset>
3 rules the format enforces and most hand-built sitemaps break:
- Every URL must be absolute and fully qualified.
/pricingis invalid inside a<loc>. Set a Base URL here and relative lines get resolved for you. - A sitemap may only list URLs on the host that serves it. A file at
example.com/sitemap.xmllistingshop.example.comURLs is a cross-submission problem, not a normal sitemap. The generator warns when your paste spans more than one hostname. - Reserved characters have to be entity-escaped. An
&inside a query string becomes&. That single character is the most common cause of "couldn't fetch" in Search Console when the file clearly exists.
Fragments are stripped, since #section never identifies a distinct URL. Duplicate <loc> values are removed, because repeating one is a validation error rather than a ranking signal.
The fields on this page and what each one changes
- URLs is the only required field. One URL per line. Blank lines and lines starting with
#are skipped, so you can leave comments in a paste you keep reusing. - Sitemap type switches the output format. Standard XML is the default here; the same engine also produces HTML, image, news, video, WordPress and visual variants.
- Base URL does 2 jobs: it resolves relative lines like
/pricing, and it gives the sitemap index absolute file locations when your list is large enough to split. Fill it in whenever either applies. - Last modified controls where
<lastmod>comes from. "Omit unless supplied" is the safe default, "today" stamps every URL with the current date, and "per line" trusts only the column you provide. - Change frequency and Priority both default to omit. Priority also has an auto mode that derives a value from URL depth: root gets 1.0, one level down 0.8, then 0.6, 0.5 and 0.4.
Extra columns are matched by shape, not by position
Anything after a | on a line is an extra column, and the parser identifies each one by what it looks like rather than where it sits. A value containing a parseable date becomes lastmod. One of the seven spec keywords (always, hourly, daily, weekly, monthly, yearly, never) becomes changefreq. A number between 0 and 1 becomes priority.
That means these 2 lines produce identical output:
https://www.example.com/pricing | 2026-08-01 | weekly | 0.8
https://www.example.com/pricing | 0.8 | 2026-08-01 | weekly
Tabs are treated exactly like pipes, so a column copied straight out of a spreadsheet or a CSV export works without reformatting. A per-line column always beats the dropdown setting above it, which is what you want when most pages share a default and a few need something specific.
When the 50,000-URL cap bites
The specification caps a single sitemap file at 50,000 URLs and 50 MB uncompressed, whichever you hit first. Both matter. Long URLs with tracking parameters and a full set of optional tags will push a file past 50 MB well before 50,000 entries, which is why this tool packs against both limits at once rather than counting rows and hoping.
When your list exceeds either limit, the output is split into numbered parts and a sitemap_index.xml is generated alongside them:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.example.com/sitemap1.xml</loc>
<lastmod>2026-08-28</lastmod>
</sitemap>
<sitemap>
<loc>https://www.example.com/sitemap2.xml</loc>
<lastmod>2026-08-28</lastmod>
</sitemap>
</sitemapindex>
Submit the index, never the parts individually. The index needs absolute locations for each part file, so this is the case where leaving Base URL blank produces an invalid file. Gzip is allowed and does not change the limits: the 50 MB ceiling is measured uncompressed.
Why changefreq and priority default to omit
Google has stated plainly that it ignores both. changefreq was never a scheduling instruction, and priority is relative within your own file, so setting every page to 1.0 is arithmetically the same as setting every page to 0.5. Neither tag has moved a ranking in a decade.
They are not harmful, they are just bytes. On a large site those bytes are the difference between one file and 2. The options are here because some internal tooling and a few older CMS validators still expect them, not because you need them.
The lastmod rule that ruins sitemaps
lastmod is the one optional tag Google actually uses, and only while it stays credible. A sitemap regenerated nightly that stamps every URL with today's date is telling the crawler that 10 thousand pages changed overnight. After a few cycles of finding nothing changed, that signal gets discounted for the whole file, including the pages that genuinely did change.
Emit lastmod from your real content-modified timestamp or leave it out. The "today for every URL" option here exists for a first publish or a genuine site-wide migration, not for a cron job.
Getting it crawled once it is live
Upload the file to your web root, then do 2 things:
- Add a line to
robots.txt:Sitemap: https://www.example.com/sitemap.xml. This is the discovery path every crawler honors, not just Google. - Submit the URL in Search Console under Sitemaps, which is also where you read back the parse errors.
Google retired the sitemap ping endpoint in 2023. Any script or plugin still hitting google.com/ping?sitemap= is making a request that does nothing. Bing removed its equivalent as well. Discovery is now robots.txt plus the search console interfaces, full stop.
One last thing worth checking after upload: every URL in the file should return 200 and be self-canonical. A sitemap full of redirect hops and pages canonicalized elsewhere sends conflicting signals, and it is a much more common problem than a malformed tag. BlazeHive automates the SEO content side of this end to end, but the sitemap itself should always reflect what your server really serves.