Sitemap strategy for an 18-page tool site: what to include and what to leave out

My downloader site is small — eighteen pages, one tool, no blog archive the size of a library. My sitemap is not a discovery problem; it is an editing problem. Every URL I add is a promise to Google that the page is worth crawling, and on a tool site a lot of URLs are not. Here is how I decide what goes in and what stays out.

Hand-maintained, not auto-generated

The sitemap is a static XML file I edit by hand. That sounds old-fashioned, but for eighteen pages it is the right call: an auto-generated sitemap would happily include /index.php?ref=twitter or the service worker file, and I would have to bolt on exclusion rules anyway. Hand-editing takes two minutes per new page and forces the real question: is this page worth having crawled?

What goes in

Every page a visitor should be able to find from search:

• The homepage and the tools hub page, the two front doors.
• Every tool page: the main downloader, the TikTok downloader landing page, the Slide, Story and Notes pages.
• The platform guides — long-form Facebook, YouTube and Instagram downloader guides — because these carry genuine original content a reviewer might actually read.
• The trust pages: About, Contact, Privacy, Terms. These exist for people first and search second, but they still belong in the sitemap.
• The blog posts. Only a handful, but real posts with real content.

Each entry carries a lastmod I update only when I actually change the page. I never fake it — a sitemap where every page claims yesterday's date teaches crawlers to ignore your dates, and then the one time you need them noticed they will not be.

What stays out

This list matters more:

• API endpoints. /api/resolve, the download proxy, the health check — these take POST requests, and no crawler should ever hit them. They are also excluded in robots.txt; leaving them out of the sitemap is the second layer of the same decision.
• The PWA files. manifest.json, sw.js, the icons. They are assets, not pages. Putting them in a sitemap is how you get a search result for your service worker, which helps nobody.
• Duplicate variants. Canonical URLs only. If a page is reachable with and without a trailing slash, or an asset carries a ?v= cache-buster, the sitemap names one version. This is also why every page has a canonical tag — the sitemap and the canonical have to agree, or you are sending mixed signals.
• Placeholder pages. My Douyin page is marked 'coming soon'. It is honest about being unfinished, but a coming-soon page in a sitemap asks a crawler to index a promise. I kept the page visible for visitors, but left it out of the sitemap until it is a real page.

Priorities: set honestly or not at all

I set priority sparingly — homepage on top, tool pages in the middle, trust pages at the bottom. Google treats these as mild hints at best, and I write them mostly for my own clarity: ranking my own pages is a useful exercise the next time I consider adding one. I skip changefreq entirely; for a tool site that changes when I ship, not on a schedule, guessing 'weekly' for a page I touched twice this year is fiction.

Submission is plumbing, not strategy

Once the file exists, getting it noticed is the easy part: I submitted it in Search Console and ping IndexNow from a small PHP script whenever a genuinely new page goes live, so Bing and Yandex learn about it within hours. But submission only matters because the contents are deliberate — a perfect sitemap of forty junk URLs is worse than a plain sitemap of eighteen good ones. Discovery is cheap; relevance is the actual work.

The sitemap on ramrom.io is twenty-one URLs today (it grew since I first counted). Every one is a page I would be happy to see in a search result. That is the whole strategy: the sitemap is a list of pages I am proud of, and anything that does not clear that bar does not get a slot.