A sitemap is a list of your pages, and yours is short

People treat this as a technical artefact requiring a tool. For an app with twelve pages it is a short text file you can write by hand in the time it takes to make coffee.

Run the free check

A sitemap is an XML file listing the URLs you want indexed, served at a fixed address on your domain and submitted in Google Search Console. For a small app it can be written by hand in about ten minutes. The step people skip is the submission, and a sitemap nobody has been told about does very little.

What it is for

A sitemap tells search engines which pages you consider worth indexing, in one place, without them having to discover every page by following links.

This matters most in exactly your situation. A large established site gets crawled thoroughly because it has many incoming links and a history of being worth crawling. A new app with no incoming links may have pages that nothing points at, and a crawler has no way to find them.

It is a suggestion rather than a command. Listing a page does not guarantee indexing, and a page can be indexed without appearing in any sitemap. What the file does is remove the discovery problem, which for a new site is a real problem.

What goes in it

Only pages you actually want people to land on from a search. This is where most hand-written sitemaps go wrong, by listing everything.

Include your homepage, your marketing and guide pages, anything that answers a question, and any public content page. Use the full address including the protocol and your chosen www form, matching exactly what the page is served at.

Leave out login pages, account and settings screens, anything behind authentication, thank-you pages, duplicate versions of the same content, and anything you have marked noindex. A sitemap containing pages you have told Google not to index is contradictory, and Search Console will report it as a problem.

The shape of the file

It is XML with a fixed structure. An opening urlset element declaring the sitemap namespace, then one url element per page, each containing a loc element with the address.

Two optional elements are worth knowing about. The lastmod element states when the page last changed meaningfully, and is worth including if you can keep it accurate. The other optional elements, priority and changefreq, are widely ignored and not worth your time.

Accuracy on lastmod matters more than its presence. A file claiming every page changed today, every day, is telling a crawler something false about your site, and the sensible response to that is to stop believing the field. Either derive it from when the content actually changed or leave it out.

Where to put it and how to announce it

Serve the file at yourdomain.com/sitemap.xml. This is convention rather than requirement, and following the convention means crawlers find it without being told.

Then do the two things that make it count, because a sitemap sitting on your server that nobody knows about achieves very little.

Add a Sitemap line to your robots.txt pointing at the full address. Crawlers read robots.txt first, so this is how they discover it without any action from you.

Then submit it in Google Search Console, under the Sitemaps section. This is the step people skip, and it is the one that gets your pages looked at soonest.

How often to update it

A sitemap is not a thing you submit once and forget, and it is also not something that needs constant attention.

If you generate it during the build, it updates itself every time you deploy and there is nothing to remember. This is the main argument for generating rather than hand-writing it, and it applies well before you have a large number of pages.

If you maintain it by hand, add the new page to it in the same sitting where you publish the page. Treating it as a separate task to do later is how sitemaps end up three months out of date, listing pages that were removed and omitting the last dozen you wrote.

You do not need to resubmit in Search Console after every change. Google recrawls a sitemap it already knows about. Resubmit when the address of the file itself changes, or when you have made a large change and want it looked at sooner.

When to generate it instead of writing it

Write it by hand when your pages are a fixed list you rarely change. Generate it when they are not.

The moment your pages come from data, such as guides stored in a database or user-generated content, a hand-written sitemap starts drifting the day you write it. Within a month it lists pages that no longer exist and omits pages that do.

Generate it from the same source the pages come from, so it cannot disagree with reality. On a build-time site this is a script that runs during the build. On a server-rendered site it is a route that produces XML from your database.

The general principle is worth stating plainly, because it applies well beyond sitemaps: anything that describes generated content should itself be generated, or it will eventually be wrong and nobody will notice.

Reading what Search Console tells you afterwards

Once submitted, Search Console reports what it made of the file, and this is genuinely useful information rather than a formality.

Check the discovered URL count matches what you expected. A lower number means some entries were rejected, usually for a malformed address or a mismatch between the address in the file and the address the page is actually served at.

Then check how many are indexed, which will be fewer, and that is normal. Indexing is a separate decision from discovery, and a new domain will see a delay between the two.

Any errors reported here are worth acting on immediately, because they are specific and fixable, which distinguishes them from most of what you will worry about in your first months.

Part of a larger guide

This page is one part of The fixes. The other parts:

Questions people ask

Do I need a sitemap for a small app?
Yes, and it matters more for you than for a large site. An established site gets crawled thoroughly because many links point at it, while a new app may have pages nothing points at, which a crawler has no way to discover. The sitemap removes that problem.
What should I leave out of a sitemap?
Login pages, account and settings screens, anything behind authentication, thank-you pages, duplicates, and anything marked noindex. A sitemap listing pages you have told Google not to index is contradictory and Search Console will report it as a problem.
Where does the sitemap file go?
At yourdomain.com/sitemap.xml by convention, which means crawlers find it without being told. Then add a Sitemap line to robots.txt pointing at the full address, and submit it in Google Search Console.
Should I include lastmod dates?
Only if you can keep them accurate. A file claiming every page changed today, every day, tells a crawler something false, and the sensible response is to stop believing the field. Derive it from when content actually changed, or leave it out.
When should I generate the sitemap instead of writing it?
As soon as your pages come from data rather than being a fixed list. A hand-written sitemap starts drifting the day you write it, and within a month lists pages that no longer exist. Generate it from the same source the pages come from so it cannot disagree with reality.
My sitemap shows fewer URLs than I submitted. Why?
Some entries were rejected, usually for a malformed address or a mismatch between the address in the file and the address the page is actually served at. Note that indexed count being lower than discovered count is separate and entirely normal, since indexing is a different decision from discovery.

Check whether your sitemap is being read

The free Get Found Check looks for your sitemap and robots.txt and reports whether they exist, parse, and agree with each other.

Run the free check Have Licheo do it for you