Why keep a separate list of addresses?
Websites often grow a little at a time. Guides, offers and language versions appear alongside the original main pages. Looking only at the homepage may not reveal the complete collection. A sitemap offers an additional organised list of the public pages you want to present. The first useful decision is editorial: which addresses represent distinct content worth finding? Answering that question can expose duplicate versions or important pages that are now reachable only through old emails. The file should describe a deliberately chosen collection, not reproduce every address a system happens to be capable of generating.
Distinguish an XML sitemap from a visitor directory
The word sitemap can also mean a visible overview for people, usually a collection of clearly labelled links. A technical XML sitemap follows a machine-readable format and can carry additional information. The two have different jobs. A visitor wants to choose a relevant guide; a technical system processes addresses and associated details. Specify which meaning you intend when commissioning work. An XML file does not automatically make a confusing menu easier to use. Equally, a well-designed visitor directory may not provide the separate technical file needed for the publishing process you have agreed with your website supplier.
A fictional course provider illustrates the problem
Imagine a small provider of outdoor courses. Its website contains general course descriptions, individual dates and an archive of previous events. The sitemap comes from an old list maintained by hand. New course pages are missing, while several removed events remain in the file. The visible website might still appear orderly at first glance. Comparing the two collections reveals that publishing and the address list have become separate jobs. A more dependable arrangement generates the list from the approved page collection. The provider must still decide which archived pages offer useful information and which should no longer be presented as available content.
Choose the intended address for each page
List the address at which the content is actually meant to be publicly available. Alternative spellings, old redirecting addresses and extra URL parameters can otherwise make the collection hard to understand. The page's canonical reference is one of the signals that should agree with this choice. For the fictional provider, the current course description should not be treated as several independent offers simply because the system can produce several URL variants. Record deliberate exceptions, such as a useful archive page. A clear selection makes later troubleshooting easier because someone can explain why each address belongs in the file.
Tie modification dates to real content changes
A modification date should reflect an actual relevant change. If every automatic rebuild gives every entry today's date, it becomes difficult to distinguish edited pages from unchanged ones. A corrected course date is different from rebuilding the same website without changing its information. Establish where the content date comes from and who or what updates it. Your content management system may provide suitable records, but the particular implementation still needs checking. Also agree how newly published, removed and renamed pages affect the generated file. Treat these as normal publishing events with predictable results, rather than problems to repair manually when someone notices them.
Submission and indexing answer different questions
You can tell a search engine about the file and inspect its processing through the available tools. This does not complete crawling or indexing. Successfully reading a listed address is a different matter from including its page in the search index. If a course cannot be found, investigate the particular page: does the address work, does it contain the expected information, and are there conflicting settings? Sending the same list again will not repair those underlying problems. Record the specific issue and correct it at its source before deciding whether another submission is a useful next step.
Keep useful pages within the visible site structure
An important course should also be reachable through a sensible route on the website. Internal linking helps visitors move from an overview to a relevant explanation and back again. Having a sitemap is not a reason to remove a page from every visible context. The course provider could organise its overview by subject or required experience and connect it with the appropriate dates. That arrangement helps people complete their task. The technical file can list the same collection without reproducing the exact visual order. Judge each component by the question it is meant to answer, rather than expecting one to replace the other.
Use a small publishing check you can repeat
Compare your intended public page collection with the generated entries. Look for missing addresses, duplicates and pages that redirect or return an error. Then test a newly created page and a genuine content edit. Does each appear correctly in the output? On a multilingual website, check the actual address of every language version. Assign responsibility for repeating this review after a substantial change to the system or site structure. Keep the results of a few representative checks so that future work has a clear reference. This is more dependable than repeatedly rewriting the entire list by hand without knowing how it relates to the publishing system.
Common questions
Must the file be called sitemap.xml?
That filename is common, but it is not the only possible choice. The intended file must be accessible and correctly made known to the relevant systems. Record its address in the project documentation so that a later migration does not leave an old file being mistaken for the current collection.
Can leaving a page out protect confidential information?
No. A sitemap is not access control. An address that is publicly reachable can become known through other routes. Confidential information needs suitable access protection. Omitting a page from a list is a decision about discovery, not a decision about who is permitted to read it.
Should a larger site use several sitemaps?
That can help with organisation and becomes necessary when technical limits are exceeded. A clear division by content area also makes reviews easier. A sitemap index can bring the separate files together. Divide them for a practical maintenance purpose, not because someone promises an automatic ranking advantage.