Your sitemap is the one file on your website that nobody ever rereads.
Somebody set it up years ago, probably a plugin, and it has been quietly telling search engines what to crawl ever since. It works, so nobody opens it.
We opened 21 of them — from IKEA, Booking.com, Stripe, Shopify, Zillow, Goodreads, wikiHow and a dozen others — and checked each one against the sitemap protocol itself.
Eight came back clean. Thirteen did not.
One of the thirteen was ours.
Results at a glance
Two problems account for almost everything we found, and both are invisible from the outside: fields that do nothing, and URLs the file is not technically allowed to cover.
Neither will break your site. Both are worth ten minutes.
What we checked, and how
We took each site's robots.txt, followed the first sitemap it declared, opened one real URL file behind it, and asked three questions.
Does every URL sit inside the sitemap's own folder? The protocol says a sitemap covers its own path and below. A file at /sitemaps/ listing pages at /products/ is outside that.
Does it carry priority or changefreq? Both are valid XML and both are ignored by Google. They are leftovers from 2005.
Does it carry a readable lastmod? This one Google does use, when it trusts you.
Then we ran several of the same files through our own XML Sitemap Generator, which performs exactly these checks, to make sure our reading and the tool agreed. They did.
Only 8 of 21 came back clean
The clean eight: Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush and Similarweb.
The other thirteen: wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian — and UNmiss.
There is a pattern in that split, and it is the same one we found when we checked who publishes an llms.txt: the developer-tool companies are tidy, and the big consumer sites running older content systems are not.
The fields that do nothing
Eight of the 21 sitemaps carry <priority>. Eight carry <changefreq>.
Both tags were part of the original 2005 sitemap specification. The idea was that you would tell search engines which of your pages mattered most and how often they changed, and crawling would be scheduled accordingly.
It did not survive contact with reality, because every website said every page was priority 1.0 and changed daily. Google ignores both fields outright. They are still valid XML. They simply do nothing.
On a small site that is harmless clutter. On a large one it is not. IKEA's product sitemap runs to 47.6 MB against a hard protocol limit of 50 MB — and every entry in it is spending bytes on two fields nobody reads.
URLs outside their own folder
Ten of the 21 list URLs that sit outside the sitemap's own directory. This is the more interesting mistake, because almost nobody knows the rule exists.
A sitemap is only supposed to cover its own path and everything below it. Put the file at example.com/sitemaps/products.xml and it technically covers /sitemaps/ and down — not /products/, and not your homepage.
In practice Google is forgiving, particularly when you submit the sitemap directly in Search Console. But "usually forgiven" is a worse position than "correct", and the fix is the easiest one in SEO: move the file to the root of your domain. A sitemap at example.com/sitemap.xml covers everything, always, with no exceptions to remember.
We failed our own check
Now the uncomfortable part, and the reason we are confident the rest of this is fair.
We ran unmiss.com through our own XML Sitemap Generator. It reported 370 URLs, 399.5 KB, HTTP 200, with a readable lastmod on every entry — and then flagged this:
370 entries carry priority or changefreq.
"Google ignores both fields outright. They are valid, they are simply not doing anything for you."
Every single URL. You can see it in the raw file, where each entry is followed by a date, the word weekly, and the number 0.7:
Nobody chose that. It came from a default, years ago, and it survived because nobody reopened the file — which is exactly the point of this article.
Copy this in an afternoon
Four steps. The whole thing takes less time than reading about it.
1. Open your own sitemap. Add /sitemap.xml to your domain, or find the address in your robots.txt. Most people have never looked.
2. Search it for priority and changefreq. If they are there, remove them. There is no downside and no risk; they were doing nothing.
3. Check where the file lives. If it is in a subfolder while your pages are elsewhere, move it to the root. That single move retires an entire category of problem.
4. Make sure lastmod is honest. This is the one field that still counts, and it only counts if it is true. A file that claims everything changed today is telling search engines to ignore the field.
What we could not measure
21 sitemaps is a sample. We chose recognisable names across publishing, retail, software and developer tools, and we read the first sitemap each one declared. A different sample would give different percentages.
One file per site. Several of these companies publish thousands of sitemap files. We graded one real URL file from each, on the assumption that they are generated by the same system — which is likely but not verified.
Path scope is a rule Google usually forgives. We are reporting it because it is in the specification and because our tool flags it, not because we can show it is costing anyone traffic. We cannot.
We cannot see what any search engine does with these files. Everything here is what the sites publish, not what gets crawled or indexed.
Paste the address of a sitemap you already publish and our XML Sitemap Generator checks it against the protocol without visiting a single URL in it. It is the same check that found the problem in our own file, and in ten of the twenty-one above.
- Flags URLs outside the sitemap's own path
- Points out priority and changefreq, which Google ignores
- Hands back a cleaned-up copy you can publish today
Frequently asked questions
Which sitemaps did you check, and what were the results?
21 readable sitemaps on 23 August 2026. Clean: Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush, Similarweb. With at least one issue: wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian and UNmiss. Ten listed URLs outside the sitemap's own folder, eight carried priority and eight carried changefreq.
Does priority or changefreq do anything at all?
Not for Google, which ignores both fields outright and has said so plainly. Other crawlers may read them, but no major search engine commits to acting on either. They are valid XML that does nothing, and removing them carries no risk.
Why does it matter where the sitemap file lives?
Because the protocol says a sitemap only covers its own path and everything below it. A file at /sitemaps/products.xml technically does not cover /products/. Google is generally forgiving, especially for sitemaps submitted in Search Console, but the problem disappears entirely if you put the file at the root of the domain.
Is a sitemap with these issues broken?
No, and we would not use that word. None of the thirteen sites here has a sitemap that fails to work. They carry fields that waste space and, in ten cases, a path arrangement the specification does not strictly allow. These are tidiness problems, not outages — which is precisely why they survive for years.
You found a problem in your own sitemap. What was it?
All 370 URLs in unmiss.com's English sitemap carry priority and changefreq. Our own XML Sitemap Generator flagged it when we pointed it at ourselves. It came from a default years ago, nobody reopened the file, and it is exactly the failure pattern this article is about.
What about lastmod?
That one still matters. Google uses lastmod when it trusts the value, and trust is earned by accuracy. Every sitemap in our sample carried it on effectively every entry, which is good — provided the dates are real. A file claiming every page changed today teaches search engines to disregard the field.
How big can a sitemap be?
50,000 URLs or 50 MB uncompressed, whichever comes first, after which you split into multiple files behind a sitemap index. That ceiling is why the wasted fields matter at scale: IKEA's product sitemap is already at 47.6 MB, which is 95% of the limit, while spending bytes on two fields nobody reads.
Can I run this check myself?
Yes, in either direction. By hand: open your robots.txt, follow the sitemap, and search the file for priority and changefreq. Or paste the address into our XML Sitemap Generator, which runs the same checks and hands back a corrected copy.
Fix the file nobody rereads
Most of this series is about companies that built something remarkable. RTINGS measures what nobody measures, wikiHow draws a picture for every step, Goodreads found sixteen nouns where everyone else found one.
This one is about the opposite: the thing every website has, that almost nobody has looked at twice.
Thirteen of twenty-one large, well-resourced companies are publishing a sitemap with something wrong in it. Not because it is hard, but because it is invisible. The file works, so nobody opens it, so the 2005 defaults live forever.
We were one of the thirteen, and we only found out by pointing our own tool at ourselves.
So open your sitemap. It takes a minute, and there is a fair chance you have not read it since the day it was created.
Checked on 23 August 2026. Method: fetch each site's robots.txt, follow the first declared sitemap, open one real URL file behind it, and test path scope, priority, changefreq and lastmod. Results were cross-checked against our own XML Sitemap Generator, which performs the same checks, and the two agreed.
One file per site is a sample, not an audit of every sitemap those companies publish. Path scope is a specification rule that search engines commonly forgive, and no claim is made that any of these issues has cost anyone traffic.