XML Sitemap: What It Is and How to Submit One

An XML sitemap is a file that lists the URLs on your website you want search engines to know about, along with when each one last changed, so Google has a direct map instead of relying only on links. Every WordPress, Shopify and Wix site generates one automatically, and hand-coded sites need one written and kept current by hand.

I set up or audit an XML sitemap on every site I work on, and it is usually the fastest technical fix in a first review because most of the mistakes are one-line errors nobody has looked at since launch. This guide covers what an XML sitemap actually is and is not, when a small site genuinely needs one, what a real sitemap entry looks like, why the lastmod field only helps you if you use it honestly, the URL limits, how WordPress, Shopify and Wix each handle this automatically, how to submit and read the report in Search Console, and the mistakes I find most often on Indian business sites.

What is an XML sitemap?

An XML sitemap is a plain text file written in a specific XML format that lists the URLs on your site, one <url> entry per page. Search engines already discover pages by following links, which I cover in what crawling is in SEO, and a sitemap is the second discovery channel: instead of waiting for Googlebot to stumble onto a page through a chain of links, you hand Google the address directly. A weak internal linking structure is still worth fixing on its own, since a sitemap tells Google a URL exists but internal links are still what tell Google the page matters enough to revisit often.

The file itself is short. A ten-page business site's sitemap might be forty lines. A two-hundred-page blog's sitemap might be a few thousand. Either way, the structure is the same: an opening <urlset> tag declaring the sitemap schema, then one <url> block per page, closed by </urlset>. Nothing about the format is complicated. What matters is which URLs go in it and how accurate the metadata is, which is most of what this guide covers.

What an XML sitemap does not do

The most common misunderstanding about XML sitemaps in SEO is treating them as a guarantee. They are not. Google's own sitemap documentation states plainly that submitting a sitemap "doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site," and it says nothing at all about ranking. A sitemap gets a URL onto Google's radar faster. It does not make Google index that URL, and it has no influence on where the page ranks once it is indexed.

I have had business owners tell me they submitted their sitemap and expected every page to appear in search within days, then conclude SEO does not work when a handful of thin, low-value pages stay out of the index. A sitemap cannot compensate for a page Google has decided is not worth indexing, cannot fix a page blocked by robots.txt, and cannot override a stray noindex tag. It is a discovery tool, not a persuasion tool. If your real problem is pages that are crawled but not indexed, the diagnosis belongs in why your website is not showing on Google, not in the sitemap file.

Does a small business site actually need one?

For a five-page site with a clean navigation menu, a sitemap is a minor convenience rather than a necessity, because Googlebot can find every page by following the main menu in a few seconds. The value rises quickly once a site grows past that. A blog with fifty or more posts, a site with pages that are not all linked from the main navigation, or a newer domain with few external links pointing at it all benefit directly, because a sitemap gives Google a complete list instead of relying on your internal linking being perfect.

I treat a sitemap as mandatory, not optional, on every site I build or manage regardless of size, for a simple reason: it costs nothing to maintain once it is set up, and it removes one variable from every future indexing question. When a client asks why a new page has not appeared in Google yet, the first thing I check is whether it is in the sitemap. Having that answer ready in ten seconds is worth more than the file cost to create.

A simple decision rule if you are still unsure: if you can list every page on your site from memory in under a minute, a sitemap is a nice to have. Once the count grows past what fits in your head, usually somewhere around the twenty to thirty page mark for most service businesses once you count location pages, blog posts and tool pages together, it moves from nice to have to something I would not launch a site without.

Anatomy of a sitemap entry

Here is what one XML sitemap example entry looks like in practice:

<url>
  <loc>https://yoursite.in/dental-implants-baner</loc>
  <lastmod>2026-09-14</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.7</priority>
</url>

Only <loc> is required. It must be the full, absolute canonical URL, including https, exactly as it should appear in search, which is why this field breaks the moment a site has unresolved duplicate URLs; I cover that overlap in what canonical URLs are. <lastmod> is the date the page last had a real, meaningful update. <changefreq>, a hint about how often the page changes, and <priority>, a relative importance score from 0 to 1, are both technically valid but Google has said, at the time of writing, that it ignores them. I still see sitemap generators fill every page with priority: 0.8 as if it matters. It does not change how Google treats the page, so it is not worth hand-tuning; leave your plugin's defaults and focus your attention on the two fields that do something.

The lastmod field: why honesty matters more than freshness signals

Of the two fields that matter, lastmod is the one people misuse most. Google's guidance on sitemaps is specific here: it uses the <lastmod> value only "if it's consistently and verifiably accurate," meaning it has to actually reflect a real update, not a date a script bumped automatically on every deploy. Fake or constantly-changing lastmod dates that do not correspond to real content changes are exactly what erodes that trust, and once Google stops trusting the field for your site, it stops giving lastmod any weight at all, for every URL, not just the dishonest ones.

On this site, sitemap.xml is a hand-maintained file, not one a plugin regenerates on every deploy, and I only change a page's lastmod date when I have made a genuine content change to that page, such as rewriting a section or updating a figure, not for a typo fix or a template tweak. That is why the file has clusters of pages sharing one date and a smaller set carrying a later one: the dates mean something, so Google has reason to trust them when deciding whether a page is worth a fresh crawl. If your CMS sets lastmod to "today" on every single page every time it regenerates the sitemap, which several WordPress setups do by default, you are training Google to ignore the field for your entire site, which is the opposite of what a properly maintained lastmod is meant to achieve.

Sitemap limits: 50,000 URLs and sitemap index files

At the time of writing (September 2026), a single sitemap file is capped at 50,000 URLs or 50MB uncompressed, whichever comes first, a hard limit set by the sitemap protocol and confirmed in Google's documentation. Limits like this have shifted before over the life of the sitemap protocol, so treat the number as current rather than permanent and check Google's own page if a project depends on it. Almost no small business site in India comes close to this. A clinic, a restaurant, a coaching institute or a single-location service business with even a few hundred blog posts is nowhere near 50,000 URLs.

Sites that do exceed the limit, typically large e-commerce catalogues or classifieds platforms, use a sitemap index file instead: one small file that lists the locations of several individual sitemaps, each staying under the 50,000-URL cap, which Google then reads as a set. If you are running a WooCommerce or Shopify store with thousands of product and variant URLs, your platform almost certainly already generates this structure for you without you needing to configure anything. For the overwhelming majority of the small Indian business sites I work on, one sitemap file is enough, and reaching for a sitemap index is a problem to solve only if you actually hit the ceiling.

How WordPress, Shopify and Wix generate a sitemap

Every major platform builds a sitemap for you by default now, which is why "xml sitemap generator" is such a common search: most people asking already have one and do not realise it.

This site falls into the last row. shreyasbagal.in is a hand-built static site hosted on Vercel with more than 200 guides and 11 free tools under /tools/, and sitemap.xml is a file I edit directly rather than one a plugin regenerates. The trade-off is manual effort in exchange for exact control over which URLs appear and when lastmod actually changes, which is the discipline described in the previous section. If you are choosing a platform for a new site and crawlability is part of that decision, my comparison of WordPress, Wix and Shopify covers how each one handles this, along with robots.txt and rendering, in more depth.

How to create and submit an XML sitemap

The steps differ slightly by platform, but the sequence and the goal are the same everywhere: a complete, accurate, canonical-only list of URLs, submitted where Google can find it.

Step 1: Generate or write the sitemap file

On WordPress, install Yoast SEO or Rank Math and the sitemap is created automatically at /sitemap_index.xml; check by visiting the URL in your browser. On Shopify and Wix, the sitemap already exists at /sitemap.xml with no setup required. On a hand-coded or static site, write the XML file following the structure shown earlier, or generate one with a free tool such as xml-sitemaps.com for a one-off list, then maintain it by hand afterwards.

Step 2: Include only canonical, indexable URLs

Go through the list and remove anything that is not the final canonical version of a page: no .html duplicates if your clean URL is the canonical, no parameter URLs, no pages carrying a noindex tag, and no URLs that redirect elsewhere. Every entry should be a URL you actually want to appear in search, exactly as its own canonical tag declares it.

Step 3: Set accurate lastmod dates

Where your platform lets you control this, make sure lastmod reflects a real content change rather than every rebuild or deploy. If you cannot control it on your platform, leaving lastmod out entirely is safer than shipping a dishonest one, since an untrustworthy date pattern can cost you the benefit of the honest ones too.

Step 4: Reference the sitemap in robots.txt

Add one line near the end of your robots.txt file: Sitemap: https://yoursite.in/sitemap.xml, using the full absolute URL. This is how this site's own robots.txt declares its sitemap, and it means any crawler that reads robots.txt first, including AI crawlers, finds the sitemap without needing a separate submission.

Step 5: Submit it in Google Search Console

In Search Console, open Sitemaps under Indexing, enter the path (just "sitemap.xml" is enough since the property already knows your domain), and click Submit. If you have not set up Search Console yet, my Google Search Console beginners guide walks through verification first. Submission itself takes under a minute; what happens after is Google fetching and reading the file on its own schedule, not instantly.

Step 6: Read the Sitemaps report and resubmit after major changes

Come back to the Sitemaps report a few days later. It shows the status (Success or an error), when it was last read, and how many URLs were discovered from it. Resubmit only when you make a structural change, such as adding a large batch of new pages or fixing a batch of URLs; day-to-day edits to existing pages do not need a resubmission, since Google rechecks a submitted sitemap on its own.

Reading the sitemap report and checking your file

The Sitemaps report in Search Console is the closest thing to an xml sitemap checker built into Google's own tools, and I read it before trusting any third-party checker. A Success status with a "Discovered URLs" count close to your actual page count means the file parsed correctly and Google is reading it. A count noticeably lower than your real page total, or an error status, means something in the file is malformed or unreachable, and it is worth opening the raw file in a browser to confirm it still loads and looks like valid XML.

For a second opinion, or to check a competitor's setup, my free website SEO checker reports on-page and indexability signals for any single URL in under a minute, which is a useful cross-check against what the Sitemaps report says about a specific page. Third-party xml sitemap checker tools mostly do the same job: fetch the file, validate the XML, and flag entries that 404, redirect, or look malformed. None of them replace Search Console's own report, because only Search Console tells you what Google itself actually did with the file.

Say your sitemap lists 180 URLs but the report shows only 140 discovered. That forty-URL gap is worth chasing before anything else on the page, because it usually means a batch of entries are malformed, blocked, or pointing at addresses that no longer resolve the way the sitemap claims. Open a handful of the missing ones directly, check whether they load without a redirect, whether robots.txt allows them, and whether each page's own canonical tag agrees with the URL as written in the sitemap. A gap like this rarely closes on its own, and it is almost always one of those three causes rather than something mysterious.

Common XML sitemap mistakes

These are the errors I find most often auditing sitemaps on Indian business sites, roughly in the order I find them.

• Non-canonical URLs in the sitemap. Listing the .html version, the www version, or a URL with tracking parameters instead of the clean canonical form sends Google a signal that contradicts your own canonical tags. The sitemap should agree with the canonical tag on every single URL, which I cover from the canonical side in what canonical URLs are.
• Noindexed pages left in the sitemap. Telling Google "please index this" through the sitemap while a noindex tag on the same page says the opposite is a direct contradiction. Search Console will flag this as "Submitted URL marked noindex," and the fix is to remove the page from the sitemap, not to remove the noindex.
• Redirecting URLs left in the sitemap. A sitemap entry that 301s somewhere else wastes the crawl and reports as an error. Update the sitemap to list the final destination directly instead of the old, redirecting address.
• 404s in the sitemap. Pages deleted without removing them from the sitemap tell Google to fetch a page that no longer exists. This is common after a redesign or a bulk content cleanup; regenerate or manually prune the file straight after.
• Dishonest or auto-updating lastmod. Covered in depth earlier in this guide, and worth repeating here because it is the single most common technical mistake I find in sitemaps that otherwise look fine.
• Forgetting to resubmit after a domain or URL structure change. Migrating to a new domain, adding https, or restructuring URLs without updating and resubmitting the sitemap leaves Google working from a stale map during exactly the period when accurate discovery matters most.

When a sitemap will not fix your indexing problem

A sitemap is a discovery aid, not a cure for every visibility problem, and it is worth being honest about what it cannot do. If your pages are being crawled and indexed but simply are not ranking, the sitemap was never the bottleneck and no amount of tidying it will move the needle; that is a content, intent or authority problem, not a technical one. If two of your own pages are competing for the same query, a sitemap cannot resolve that either. That is keyword cannibalization, not a crawling problem, and I cover diagnosing and fixing it separately in my keyword cannibalization guide, which is worth reading alongside this one since both symptoms can look similar in Search Console at first glance.

Similarly, if robots.txt is blocking the pages your sitemap lists, or a noindex tag sits on them, the sitemap submission does nothing, because discovery was never the problem; permission was. Always check robots.txt and each page's indexing status before assuming the sitemap needs work. And if you are not sure where to start across all of this at once, my technical SEO basics guide puts the sitemap in context with crawling, speed and HTTPS, and how to index a website on Google walks through the full indexing checklist in order, sitemap included.

Frequently asked questions

What is an XML sitemap in SEO?

An XML sitemap in SEO is a file that lists the URLs on your website you want search engines to crawl and index, usually with a last-modified date for each one. It works alongside internal links as a second discovery channel, handing Google a direct list instead of relying only on Googlebot following links from page to page. It helps Google find your pages faster. It does not force Google to index them and has no direct effect on where a page ranks once indexed.

Do I need an XML sitemap generator, or does my platform already have one?

Check before installing anything. WordPress with Yoast SEO or Rank Math, Shopify and Wix all generate a sitemap automatically at sitemap.xml or sitemap_index.xml with no setup required, so visit that URL on your own site first. Only hand-coded or custom-built sites need a sitemap written manually or produced with a free generator tool such as xml-sitemaps.com for an initial list, which you then keep updated as pages are added or removed.

What does a basic XML sitemap example look like?

A minimal sitemap is an opening urlset tag, one url block per page containing at minimum the page's full canonical address, and a closing urlset tag. Each url block can also include a lastmod date showing when that page last had a real content update. The priority and changefreq fields are technically valid but Google has said it ignores both, so a clean example sitemap focuses on accurate addresses and honest lastmod dates rather than those two fields.

How do I submit my sitemap to Google?

Open Google Search Console, select your property, click Sitemaps under the Indexing section in the left menu, type the path to your file such as sitemap.xml, and click Submit. This takes under a minute. Google then fetches and reads the file on its own schedule, which is not instant, and you can check progress afterwards in the same report, which shows a status, the last read date, and how many URLs were discovered.

Is there a free XML sitemap checker?

Yes. The Sitemaps report inside Google Search Console is the most reliable free xml sitemap checker because it shows exactly what Google itself did with your file, not a simulation. Opening yoursite.in/sitemap.xml directly in a browser is a free manual check that the file loads and looks like valid XML. Third-party checker tools add convenience by flagging broken or redirecting entries automatically, but they do not replace what Search Console reports.

Related guides

• Keyword cannibalization: meaning, how to find it, how to fix
• What is crawling in SEO? How Googlebot finds your pages
• What is robots.txt in SEO?
• What are canonical URLs? The canonical tag explained
• Technical SEO basics every business owner should know
• Google Search Console beginners guide
• How to index your website on Google
• WordPress vs Wix vs Shopify: which is best for your business?

Your next step

Open yoursite.in/sitemap.xml right now and check three things: does it load, does every URL match your canonical addresses, and are the lastmod dates honest. Then submit it under Sitemaps in Search Console if you have not already, and run your homepage through the free website SEO checker to confirm nothing else is blocking indexing. If the Sitemaps report shows an error you cannot explain, send me the URL and I will take a look.