When we say "sitemap" in a project conversation, we could mean either of two completely different things, and they get confused constantly. One is a planning document. The other is a file sitting on your web server. Both matter, and they do unrelated jobs.
The blueprint that comes before design
Before a single page gets designed or a single line of code gets written, we build a sitemap. Every time, for every client. It is the plan for what pages exist, how a visitor gets from the homepage to a service page to a contact form, whether a topic deserves its own page or a section inside a larger one, where the blog lives, and how deep the navigation goes.
Get this right and the rest of the project flows. Get it wrong and you are reworking pages mid-build, which costs time and budget.
It also decides what your visitors experience. Most people make up their mind about a website in seconds. If they cannot tell where they are or where to go next, they leave. A structure that makes sense means the important content is easy to find and the path to action, whether that is contact us or book an appointment or request a quote, is never more than a click or two away.
We treat this as a strategic document, not a technical one. We build it before design begins, review it with you before anything else is created, and revisit it whenever the scope changes.
The file search engines read
The other sitemap is sitemap.xml, a machine-readable list of your pages in a standard format published at sitemaps.org. It exists so a search engine does not have to find every page by following links. You can look at yours right now by adding /sitemap.xml to your domain.
It is not a copy of your navigation and it is not written for people. It lists only the canonical pages that load successfully and are meant to be indexed. Staging URLs, redirects, internal search results and anything marked noindex stay out.
What it will and will not do
This is where the industry oversells, so we would rather be plain about it. A sitemap helps search engines discover URLs. It does not instruct them. Google's own documentation is direct:
"A sitemap helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed."
Google goes further and says a small, well-linked site may not strictly need one. So why generate and submit one for every client? Because it costs nothing, and because submitting it to Google Search Console turns the file into a monitoring surface. Search Console then reports, for that specific sitemap, when Google last read it, how many of its URLs made it into the index, and which ones were excluded and why.
That report is how we notice a page quietly falling out of Google before you notice a dip in traffic.
How we handle it
On StoryCanvas, the platform generates the sitemap itself. Publishing regenerates it, and the site's robots.txt points crawlers straight at it, so nothing depends on a person remembering a step. On Drupal builds we use the Simple XML Sitemap module to the same end.
Either way, we submit the sitemap to Google Search Console on your behalf at launch, and we keep an eye on the coverage report afterward as part of ongoing support. You never have to know any of this exists. That is rather the point.
