A sitemap.xml file is a list of every page a website offers up to search engines for indexing, usually reachable at yourdomain.com/sitemap.xml. Website builders and WordPress with an SEO plugin generate it automatically, static site generators build it at deploy time. The actual task for a small business owner is submitting it in the Sitemaps report inside Google Search Console, a process that takes a few minutes and then shows exactly how many pages Google actually picked up.
What a sitemap actually does
A sitemap isn’t a requirement and it’s no guarantee of indexing, it’s a signal to Google about which pages a site considers worth crawling. Per Google’s own documentation, only URLs that should actually be indexed belong in it: status code 200, no noindex, no redirect. For a newly launched business website with few internal links, that signal makes a real difference, since Google would otherwise mostly rely on external links pointing in to discover new service pages, which takes longer. On an established site with a mature internal link structure, the effect is smaller, but a clean sitemap entry never hurts and it’s a fast diagnostic when a specific page refuses to show up in search.
Where the sitemap comes from: three platforms compared
Which sitemap file exists and how current it stays depends on the platform behind the site.
| Platform | Typical path | How it updates | What’s left to do |
|---|---|---|---|
| Website builder (Wix, Squarespace, etc.) | /sitemap.xml | Automatically on every change | Submit it once in Search Console |
| WordPress with Yoast/Rank Math | /sitemap_index.xml | Automatic, plugin manages sub-sitemaps | Check content types in the plugin, then submit |
| Static site generator (Astro, etc.) | /sitemap-index.xml or /sitemap.xml | Automatic, rebuilt from the route list on every deploy | Confirm it’s reachable after the first deploy |
On a website builder, the platform’s own help documentation usually lists the exact path to enter in Search Console. On WordPress, an active SEO plugin generates a sitemap index that points to separate sub-sitemaps for posts, pages, and categories, and a leftover sitemap.xml from an older WordPress version shouldn’t stay submitted alongside it. On a static site generator, the file gets rebuilt from the project’s actual page structure at every deploy, so there’s no manual upkeep for individual URLs, a new service page shows up in the sitemap the moment it ships.
Submitting your sitemap in Google Search Console
Submission works the same way regardless of platform, assuming the property in Search Console is already verified, as covered in Setting Up Google Search Console for a Small Business.
- Open the correct property in Search Console (Domain or URL-prefix property, depending on how it was set up).
- In the left menu, under “Indexing,” click “Sitemaps.”
- Under “Add a new sitemap,” enter the path, usually just
sitemap.xmlorsitemap_index.xmlwithout the full domain in front. - Click “Submit” and check the status shortly after: “Success” with a page count is the goal.
If the report shows errors or warnings like “URL blocked by robots.txt,” it’s worth checking the site’s own robots.txt file, since an overly broad block there often stops exactly the pages the sitemap was meant to surface.
The most common mistakes on small business sites
The first mistake is noindex pages showing up in the sitemap. Some SEO plugins and generators sweep in test pages, old campaign landing pages, or draft versions even though those are deliberately excluded from indexing. The Sitemaps report flags these as “not indexable,” a good prompt to configure exactly which content types the plugin should include.
The second mistake is orphaned pages, URLs listed in the sitemap that no longer have any internal links pointing to them, often leftovers from an earlier version of the site. Google can still find these pages through the sitemap, but that’s rarely the intent, most of the time they’re forgotten pages that should either get relinked or consolidated onto the current page with a 301 redirect.
The third and most expensive mistake in practice shows up after switching website providers or a full redesign: the old sitemap URL stays submitted in Search Console but now points to a file that doesn’t exist on the new platform, or uses a different format entirely, like sitemap.xml instead of the new setup’s sitemap_index.xml. After any provider switch, checking the Sitemaps report belongs on the same list as checking robots.txt and redirects.
Two special cases: bilingual sites and image sitemaps
A business running two language versions of its site, the way Mr.Site does for its own English and German content, benefits from a sitemap index that points to separate sub-sitemaps per language rather than one combined file. That keeps a single, oversized file from mixing both language versions together, and it makes it obvious in the Sitemaps report if one language stops updating fully after a change. Most single-language home services businesses never need to think about this, but any contractor serving a bilingual market or a manufacturer with a second language version should ask about it during the next technical review.
A second special case is the image sitemap, a separate file that hands Google extra image metadata. For most small business sites it’s barely worth the effort: project photos and reference images already get embedded directly in HTML pages, and Google’s own documentation states it favors images embedded in pages over ones that only show up in a separate sitemap. An image sitemap starts to matter for photo-heavy portfolio or gallery pages running into the hundreds of images, a normal service page with a handful of project photos is fully covered by the regular sitemap.
Checking your own sitemap
Before submitting anything in Search Console, it’s worth a direct look from the outside. The fastest check is typing your own domain with /sitemap.xml appended into a browser: a readable list of <url> entries means the file exists and is publicly reachable. A blank page or an error is a good reason to try sitemap_index.xml next, which is the actual current path for WordPress with an SEO plugin and for most static site setups. For a more thorough check, curl -I https://www.samplecontractor.com/sitemap.xml confirms the server returns a 200 status instead of a redirect or an error page, a detail that gets missed especially often right after switching providers.
Once it’s submitted, the Sitemaps report itself gives the most useful numbers to watch. “Discovered URLs” shows how many addresses Google actually read out of the file, and if that number is noticeably lower than the site’s real page count, it’s worth checking for causes like a stale sub-sitemap or a duplicate file submitted by mistake. The “Status” column distinguishes between “Success” and “Couldn’t fetch” or similar errors, which usually trace back to a wrong file format, an unreachable URL, or confusion between a relative path and a full URL. It’s worth another look after any major site update too, similar to the routine check on robots.txt, since both files tend to break in the same situations: a platform switch, a full redesign, or a larger change to the site’s page structure.
Next step
Most business websites don’t need a hand-maintained sitemap, just a one-time check that the auto-generated file exists, is submitted correctly, and still matches the site’s actual page structure after any major change. Mr.Site checks the sitemap, robots.txt, and Search Console setup as part of its managed website service during every redesign and provider switch, so new service pages don’t sit unindexed for weeks.