XML sitemap basics: what it does and what it does not

Aug 29
3 min read

Updated: 3 days ago

Introduction

Somebody says the site needs a sitemap. A file is generated, submitted, and never looked at again. Two years later it lists pages that no longer exist, omits half the ones that do, and nobody has opened it since the day it was created.

A sitemap is a list of the addresses on your site that you want search engines to know about. It is genuinely useful for discovery and completely irrelevant to ranking, and most of the value comes from keeping it accurate rather than from having one at all.

1. XML sitemap basics start with what it is for

Discovery, not promotion.

The file tells search engines which pages exist so they can be found without relying entirely on following links. It has no influence whatsoever on whether those pages rank once they have been discovered, which is the single most useful thing to know about it.

2. Check whether you already have one

Most platforms generate it automatically.

Add the standard sitemap path to the end of your domain and see whether a file appears. Hosted website builders and content systems almost always produce one, and creating a second by hand usually causes more confusion than it resolves.

3. Make sure it lists only pages you want indexed

The most common defect.

Redirected addresses, error pages, no-indexed pages and draft content should not appear. A sitemap full of addresses that cannot be indexed reduces confidence in the whole file.

4. Make sure it lists everything you do want

The other half of the same problem.

Check that new sections, product ranges and article archives are actually included. Automatic generators sometimes miss content types added after the site was built, particularly anything introduced by a plugin.

5. Keep the modification dates honest

A detail that is quietly abused.

The date attached to each address should reflect when the page genuinely changed. Files that report every page as modified today are ignored on that signal, which removes a useful hint for the pages that really did change.

6. Split large sitemaps into an index

Only relevant past a certain size.

Beyond tens of thousands of addresses, a sitemap should be divided into several files with an index listing them. Splitting by content type is also easier to read when you are diagnosing which section has a problem.

7. Reference it in your robots file

A small step frequently skipped.

A single line in the robots file naming the sitemap address makes it discoverable without any submission. It costs nothing and covers search engines you have not registered with.

8. Submit it and then read the report

The part that is actually valuable.

After submission, the search console reports how many addresses were found and how many were indexed. That comparison is one of the most useful diagnostics available to a small site, and it only means anything if the sitemap itself is accurate in the first place.

9. Do not expect it to fix anything

Set the expectation correctly.

A sitemap will not get a blocked page indexed, will not improve a thin page, and will not raise a position. If pages are missing from search, the sitemap is where you start looking, not where the problem usually is.

Check the file after any migration or restructure. Sitemaps are regenerated automatically and frequently regenerate wrongly, listing the old address structure or dropping entire sections, and this is exactly the moment when accurate discovery matters most.

Conclusion

Treat the sitemap as a discovery aid with no influence on ranking, because that framing prevents most of the wasted effort around it.

Check whether your platform already generates one, remove redirected and no-indexed addresses from it, confirm that newer sections are actually included, keep modification dates truthful, split very large files into an index, reference it from your robots file, submit it and then read the found against indexed comparison, expect it to fix nothing on its own, and re-check it after every migration.