XML Sitemap for SaaS Sites: What to Include & How to Submit

You’ll end up with a clean XML sitemap that lists only the SEO‑critical pages of your SaaS product, and it will be submitted to Google Search Console so you can monitor coverage. The process works for any CMS or static site and takes under an hour.

What you’ll have at the end

A single sitemap.xml file that contains URLs such as your home page, product overview, pricing, blog articles, and key resource pages, but excludes login screens, user dashboards, and filtered search results. Search Console will show the file under Sitemaps and indicate any crawl errors.

Step‑by‑step process

1. List the pages you want indexed – Open a spreadsheet and add rows for each URL. For a SaaS like AcmeAnalytics (25‑person team) include: Home, About, Feature pages, Pricing, Blog index, individual blog posts, Help Center articles, and public integrations. Exclude: /login, /app/*, and any internal customer portals.
2. Generate the XML – Use a simple online generator (e.g., XML‑Sitemaps.com) or a CMS plugin. Paste the URL list, set the changefreq to weekly for blog posts and monthly for static pages, and let the tool produce the sitemap.xml file.
3. Validate the file – Upload the XML to the Google Search Console URL Testing Tool. The tool will report malformed tags or unreachable URLs. Fix any errors in the spreadsheet and re‑generate the file.
4. Upload to your server – Place the final sitemap.xml at the root of your domain (https://www.acmeanalytics.com/sitemap.xml). Verify by visiting the URL in a browser; it should display raw XML.
5. Submit in Search Console – In the property for your site, go to Sitemaps → Add a new sitemap, enter sitemap.xml, and click Submit. The console will show Pending then Success once Google processes it.

Validate the sitemap

Photo by Ferenc Almasi on Unsplash

Even after submission, occasional crawl errors appear. Return to the Coverage report daily for the first week. Look for Submitted URL not found (404) warnings; they usually mean a page was removed after the sitemap was generated. Update the spreadsheet and resubmit the file when the count exceeds a handful of URLs.

Submit to Google Search Console

If your site uses multiple subdomains (e.g., blog.acmeanalytics.com), add each as a separate property and submit the same sitemap.xml URL. Google treats each property independently, so coverage metrics will appear for both the main site and the blog.

Monitor coverage and fix problems

The Coverage tab lists URLs as Valid, Error, or Excluded. For a SaaS, focus on keeping the Valid list steady and shrinking the Error list. When a new feature page is launched, add its URL to the spreadsheet and re‑run step 2; the updated sitemap will be picked up automatically after you resubmit.

Typical mistakes and how to spot them

• Including login or app URLs – These appear as 403 or 404 in the Coverage report. Remove any pattern matching /login* or /app/* from the list.
• Missing dynamic blog posts – If new posts never appear in coverage, the changefreq may be set too low. Set blog posts to daily or weekly so Google knows to revisit them often.
• Having duplicate URLs – The validator will flag duplicate `` entries. Keep only the canonical version (e.g., prefer https://www.acmeanalytics.com/blog/post-title over https://acmeanalytics.com/blog/post-title).

Want a turnkey system that keeps your XML sitemap up to date and feeds AI‑ready pages? See how we do it.

Validate the sitemap (expanded) After the initial validator run, run a quick URL Inspection on a handful of representative URLs. In Search Console paste the full URL (e.g., https://www.acmeanalytics.com/blog/how-to‑track‑events) and click Test Live URL. The report tells you whether Google can fetch the page, whether the canonical tag points back to the same URL, and whether any redirects were encountered. If the live test shows ‘Redirected 301’ but the sitemap still lists the old URL, update the spreadsheet and regenerate the file.

For larger sites it’s worth scripting a sanity check. A simple curl -I loop against each URL can spot 4xx or 5xx responses in seconds. Flag any URL that returns a status other than 200, then decide whether the page should be removed from the sitemap or corrected on the site.

Don’t forget the robots.txt file. If a URL is blocked there, Google will ignore it even if it appears in the sitemap. Open https://www.acmeanalytics.com/robots.txt and look for Disallow: rules that overlap with your sitemap entries. When you find a conflict, either adjust the robots rule or drop the URL from the sitemap, keeping both consistent prevents confusing crawl reports.

Submit to Google Search Console (expanded) Google allows a maximum of 50 000 URLs per sitemap and 10 MB uncompressed size. A growing SaaS blog can outgrow a single file quickly. When you approach those limits, split the sitemap into logical groups: one for static pages (home, about, pricing), one for feature pages, and one for blog content. Name them clearly (e.g., sitemap‑features.xml, sitemap‑blog.xml) and submit each separately in the Sitemaps panel.

Add a reference to each file in your robots.txt so Google discovers them even if you forget to submit later:

Sitemap: https://www.acmeanalytics.com/sitemap-features.xml
Sitemap: https://www.acmeanalytics.com/sitemap-blog.xml

If you run a separate subdomain for a help center (help.acmeanalytics.com), treat it as its own property in Search Console. Upload the same sitemap files to the subdomain’s root, but submit the URLs that belong to that subdomain only. This keeps coverage metrics tidy and prevents cross‑property contamination.

When you submit a new sitemap, the Status column initially shows Pending. Refresh after a few minutes; a Success status indicates Google has downloaded the file. If the status flips to Error, hover over the icon to see the exact problem, often a temporary network hiccup or a malformed XML tag that slipped past the offline validator.

Monitor coverage and fix problems (expanded) The Coverage tab groups URLs into four buckets:

• Valid – Google has successfully indexed the URL.
• Error – Fetch failed (404, 5xx) or blocked by robots.txt.
• Valid with warnings – Indexed but flagged for issues such as “Redirect error”.
• Excluded – Intentionally left out (duplicate, noindex, or blocked by a robots rule).

Focus on the Error and Valid with warnings groups. Click any entry to open the URL Details pane. It shows the exact reason Google rejected the page and often offers a direct “Test Live URL” link. Use that to verify whether the problem is still present.

For SaaS sites, a common source of Error entries is stale feature pages. When a feature is retired, the URL may still sit in the sitemap. Remove it promptly; otherwise Google will waste crawl budget repeatedly hitting a dead page, which can dilute the crawl frequency for fresh content.

Another useful view is the Submitted URLs report (under Sitemaps). It lists every URL the sitemap fed to Google and the current index status. If you see a large proportion of Submitted but not indexed rows, consider raising the priority attribute (a value between 0.0 and 1.0) for those pages, especially for high‑value assets like a pricing comparison or a product‑demo landing page. Priority does not guarantee ranking, but it signals to Google that the page warrants more frequent crawling.

Typical mistakes and how to spot them (expanded)

• Including filtered or paginated URLs – SaaS apps often expose URLs like ?sort=asc&page=2. If such URLs appear in the sitemap they generate massive duplicate‑content warnings. Run a quick grep on your spreadsheet for ? characters; keep only the canonical first‑page version (/blog/) and let pagination be discovered naturally.

• Submitting URLs that return a 302 temporary redirect – Google follows redirects, but the final URL should be the one listed in the sitemap. If you notice many Redirected flags in the coverage report, replace the source URL with the destination URL in your source list.

• Neglecting language‑specific pages – International SaaS products may have example.com/es/ versions. If you include both the English and Spanish pages without proper hreflang annotations, Google may treat them as duplicate content. Either add the correct hreflang tags on the pages or keep only the primary language version in the sitemap.

• Over‑using the changefreq attribute – Setting every blog post to daily floods Google with crawl requests that it may not honor, especially for low‑traffic sites. Reserve daily for truly time‑sensitive pages (e.g., a daily news feed). For static documentation or roadmap pages, monthly or yearly is sufficient.

• Leaving out the trailing slash consistency – Some servers treat https://www.acmeanalytics.com/blog and https://www.acmeanalytics.com/blog/ as separate URLs. If both variants appear, the validator will flag duplicate entries. Choose one style (prefer the trailing slash for directories) and enforce it site‑wide via a 301 redirect.

• Forgetting to update after a redesign – A redesign often changes URL structures. Before you generate a new sitemap, audit the old one against the current site map. Tools like Screaming Frog can crawl the live site and export a fresh URL list; compare it with your spreadsheet to catch any mismatches early.

• Adding non‑HTML resources – PDFs, images, and video files are crawlable but rarely need to be in a sitemap unless they are primary assets (e.g., a downloadable whitepaper). Including every asset bloats the file and can mask the presence of core content. Keep the sitemap focused on pages that deliver value to a searcher and that you want to appear in AI‑driven answers.

By systematically checking for these patterns, you can keep your sitemap lean, accurate, and aligned with the pages that matter most for SEO and AI citation visibility.

Comppound builds the crawling layer of this workflow while leaving the final URL selection to a dedicated SEO lead. See how we do it.