---
title: "How to Add a Sitemap for a Help Centre"
canonical: https://supportpages.io/guides/add-a-sitemap-for-a-help-centre
updated: 2026-08-13
---

This guide leaves you with a valid `sitemap.xml` listing every canonical, indexable article URL, referenced from `robots.txt`, submitted to Search Console, and regenerated whenever you publish. A sitemap does not make pages rank. It makes them discoverable, which is a precondition rather than an advantage.

## Before you start

You need a list of your published article URLs, the ability to serve a file at the root of the help centre's hostname, and verified access to Search Console for that hostname. If your help centre tool generates a sitemap already, find its URL and check its contents against the steps below before building a second one - two competing sitemaps is a worse state than one imperfect sitemap.

![A chain from published articles to sitemap.xml to robots.txt to a search console submission.](/images/guides/figures/add-a-sitemap-for-a-help-centre.webp)

*The sitemap is one link in a chain. Two of the other three are what actually get it read.*

## Steps

1. **Decide what belongs in the file.**
   Only URLs that return 200, are canonical, and are not blocked from indexing. A sitemap is a statement about what you want indexed, so anything that redirects, 404s, carries a `noindex`, or canonicalises elsewhere should not appear.

2. **Generate it rather than writing it by hand.**
   Whatever holds your articles can produce the list. A hand-maintained sitemap is accurate on the day it is written and wrong by the third publication after that.

3. **Include `lastmod`, and make it truthful.**
   It should be the date the article's content meaningfully changed. Setting it to the build timestamp for every URL on every deploy means the field says "everything changed today" every day, which is the same as saying nothing.

4. **Leave out `priority` and `changefreq`.**
   Major search engines have stated they ignore both. They add bytes and give reviewers something to argue about that has no effect.

5. **Exclude the machinery.**
   Category listing pages are usually fine to include; tag pages, search result pages, paginated duplicates and draft previews are not. If a URL exists for navigation rather than for answering a question, it probably does not belong.

6. **Reference it from `robots.txt` with an absolute URL.**
   A line reading `Sitemap: https://help.example.com/sitemap.xml`. Relative paths are invalid here, and this is a common silent failure.

7. **Serve it from the same hostname as the URLs it lists.**
   A sitemap on your marketing domain listing help subdomain URLs is treated as cross-submission and is only honoured in specific verified cases. Keep each hostname's sitemap on that hostname.

8. **Split above 50,000 URLs or 50MB uncompressed.**
   Those are the format's limits. Beyond either, use a sitemap index file pointing at several sitemaps. Few help centres reach this, but the limit is worth knowing before an export writes one enormous file.

9. **Submit it once, then leave it alone.**
   Submission is a one-time action per property. After that, search engines re-fetch on their own schedule; resubmitting after every publication achieves nothing.

10. **Check the coverage report a week later.**
   The useful number is the gap between submitted and indexed. A large gap points at content or crawl problems, and the sitemap has done its job by making that gap measurable.

## Common mistakes

**Listing URLs that redirect.** Every restructure leaves old URLs in the sitemap, and a sitemap full of redirects is treated as a low-quality signal about the file rather than about the pages.

**Stamping every `lastmod` with the deploy time.** It destroys the only field in the file that carries information, and it does so in a way that looks correct in every validator.

**Including `noindex` pages.** The sitemap says index this and the page header says do not, which is a direct contradiction and gets reported as an error against your property.

**Forgetting to remove deleted articles.** Retired URLs linger in the file for months, generating crawl errors that mask real ones in the same report.

**Believing a sitemap fixes indexing.** It helps discovery, particularly for pages with few internal links. Pages that are crawled and deliberately not indexed have a different problem, and adding them to a sitemap again does not change it.

## When this stops scaling

A generated sitemap scales fine. The file itself is not the limit - it handles fifty thousand URLs without complaint, and no help centre is near that.

What stops scaling is the hand-maintained version, and the threshold is low: about thirty URLs, or the first month in which you publish weekly. Past that, someone forgets an entry, the omission is invisible because nothing breaks, and the missing articles never get crawled.

The `lastmod` field has its own threshold. Keeping it truthful requires knowing when an article's content actually changed, distinct from when its metadata was touched. Most help centre tools do not distinguish the two, so the field decays into a build timestamp and stops being worth reading - which matters, because it is the field crawlers use to prioritise re-crawls.

Where the help centre is generated rather than hand-maintained, both problems disappear: the URL list and the modification dates come from the same source as the content. [SupportPages](https://supportpages.io) publishes the sitemap alongside the articles for that reason. If your last sitemap check found three URLs that no longer exist, the file has already stopped being maintained by hand.