Submit your sitemap in Google Search Console properly

If you want Google to find your key URLs more reliably, submitting a sitemap in Google Search Console is the right housekeeping step. It tells Google where your preferred URLs are and gives Googlebot another source of discovery. It does not prove those pages will be indexed, and it does not improve rankings by itself.

That distinction matters when people ask how to submit a sitemap to Google Search Console. The submission itself is simple. The useful work is checking that the sitemap contains the right URLs, then reading the response properly so you do not mistake “Google fetched the file” for “Google indexed the pages”.

What submitting a sitemap does, and what it does not prove

A sitemap is a machine-readable list of URLs you want search engines to know about. In practice, submitting one in Google Search Console helps Google discover pages, especially on larger sites, newer sites, and sites where internal linking is imperfect.

Google’s own guidance is clear on the limit of that benefit. Search still depends on useful, accessible content, crawlability, and the rest of the search fundamentals. A sitemap submission is not a ranking lever, and it is not a guarantee that a listed URL will appear in search results Google SEO Starter Guide. Likewise, the Page indexing report exists because many discovered URLs are not indexed for reasons that have nothing to do with whether they appeared in a sitemap Google Page indexing report.

So what does a sitemap submission actually do?

It helps with discovery. It can tell Google about:

• important pages that are not yet well linked internally
• recently added pages
• canonical versions of URLs
• the structure of large sets of content, often via a sitemap index

What does it not prove?

It does not prove that:

• Google accepts every URL as indexable
• Google agrees with your canonical choice
• the page quality is sufficient for indexing
• the page will rank for any query
• the page will receive impressions or clicks

This is similar to other search evidence we cover on The SEO Blog. A crawler visit, an indexed page, an impression, a click, and a business outcome are different things. The same caution applies if you are also thinking about AI crawlers such as OAI-SearchBot or GPTBot. Their access controls and purposes differ from Google Search access, and Google does not require any special AI text file or special AI schema for its Search AI features Google AI features OpenAI crawler documentation.

Check the sitemap before you submit it

Before you add anything in Google Search Console, open the sitemap URL in a browser and inspect it like a document, not like a ritual.

For many sites the URL is one of these:

• /sitemap.xml
• /sitemap_index.xml
• a CMS-generated sitemap path such as /page-sitemap.xml or /post-sitemap.xml

A working sitemap should return normally in the browser and should not redirect through a chain of odd URLs. If it produces a 404, a server error, a login requirement, or a blocked file, fix that first.

Then check the contents.

Confirm it contains the right pages

You do not need every URL on the site. You need the URLs you actually want indexed.

Look for:

• your main service, product, category, article, and core landing pages
• the preferred version of each URL
• current pages, not deleted ones
• live HTTPS URLs if the site runs on HTTPS

If the site is small, you can scan the file manually. If it is large, sample several sections and compare them with the site’s navigation and CMS output.

Exclude non-canonical URLs

A common sitemap mistake is listing URLs that are not the canonical versions. Examples include:

• both http and https
• both www and non-www
• URLs with tracking parameters
• print versions
• duplicate category paths
• paginated or filtered URLs that should not be indexed

Your sitemap should usually contain the canonical URL you want Google to treat as primary. If your page declares one canonical URL but the sitemap lists another, you are sending mixed signals.

Exclude blocked or non-indexable URLs

Do not include pages that are intentionally blocked from indexing. Typical examples are:

• URLs with a noindex directive
• login-only or basket pages
• staging URLs
• search results pages on your own site, if you do not want them indexed
• duplicate tag archives or thin utility pages

Also check robots rules. A sitemap can list a URL that robots.txt blocks, but that often creates confusion rather than helping. If you want a page indexed, it normally needs to be crawlable as well as indexable.

Reflect what should be indexed, not every URL that exists

This is where many automated sitemap generators overreach. A good sitemap is not a dump of your database. It is a maintained list of URLs worth indexing.

If your CMS has generated hundreds of attachment pages, tag archives, or parameter variants, do not assume “more URLs” means “better SEO”. Usually it means a noisier signal and a harder indexing diagnosis later.

If you are already reviewing crawl waste, our guide on a practical Google Search Console check for crawl errors can help you spot the sort of URLs that should not be promoted in a sitemap.

How to add the sitemap in Google Search Console

Once the sitemap itself looks right, the submission process is straightforward.

1. Open the correct property

Sign in to Google Search Console and choose the property that matches the site version you want to monitor.

This matters. If you have several properties, such as:

• a Domain property
• an https://www.example.co.uk/ URL-prefix property
• an https://example.co.uk/ URL-prefix property

make sure you are working in the one you actually use for reporting. In most cases, a verified Domain property is the least confusing because it covers protocols and subdomains together. But many teams still use URL-prefix properties for specific sections.

2. Go to Sitemaps

In the left-hand menu, open the “Sitemaps” section.

You will usually see:

• a field to “Add a new sitemap”
• a list of submitted sitemaps
• status information for previous submissions

3. Enter the sitemap path

Google Search Console usually shows your property root, then asks for the path. Enter the sitemap path exactly as it exists, for example:

• sitemap.xml
• sitemap_index.xml
• blog-sitemap.xml

If you are using a URL-prefix property, take extra care that the sitemap is inside that property’s scope. A sitemap on another host or protocol may not fit the property you selected.

4. Click Submit

After submission, Google Search Console usually gives an immediate message acknowledging the request. This first response is limited. It does not mean the URLs were indexed. It usually means one of these:

• the sitemap was submitted successfully
• Google could not fetch it
• the format appears invalid
• the sitemap is already known

For a valid sitemap, the first useful follow-up is whether Google can read it, not whether every URL is accepted.

5. If you use a sitemap index, submit the index, not every child file

Many CMS platforms generate a sitemap index that points to multiple child sitemaps, such as pages, posts, categories, or products. In that case, submit the sitemap index unless you have a specific reason to isolate one section.

That keeps administration simpler, especially after content growth or migrations.

How to tell whether Google accepted it

After submission, return to the Sitemaps area and open the submitted item. This is where people often overread a green or neutral status.

The main fields to check are:

Status

A status such as “Success” usually means Google fetched and processed the sitemap file. It does not mean all listed URLs were indexed.

If the status shows an error, common causes include:

• the URL is wrong
• the file is unreachable
• the XML format is broken
• the sitemap contains unsupported content
• the property does not match the sitemap location

Last read

This shows when Google last fetched the sitemap. If the date is recent, Google is at least revisiting the file. If it is old on a frequently updated site, check whether the sitemap is still accessible and whether the property is the one you expect.

Discovered URLs

This is the count Google extracted from the sitemap. It is useful as a rough check.

For example:

• if you expected 120 core URLs and the sitemap shows 4, something is missing
• if you expected 120 and it shows 12,000, your CMS is probably outputting too much
• if the count drops suddenly after a migration or plugin update, investigate immediately

Treat this as a sitemap-content signal, not an indexing result.

Warnings and details

Warnings may point to specific formatting or coverage issues. Read them, but do not jump to the conclusion that the sitemap is the whole problem. Often the real issue sits on the page itself.

A successful fetch is still only the start. To see what happened to the URLs afterwards, you need the indexing reports and URL-level checks. If you want a framework for separating “we have data” from “we have an explanation”, our piece on Search Console evidence and its limitations is relevant here.

What to do if pages still are not indexed

If the sitemap was accepted but pages are still absent from search, move from sitemap diagnosis to indexing diagnosis.

Google’s Page indexing report is the right place to start Google Page indexing report.

Step 1. Open the Page indexing report

Look at the excluded and indexed groups. The point is not to make every excluded URL indexed. Google explicitly notes that some excluded URLs should stay excluded Google Page indexing report.

What you are looking for is whether your target pages fall into patterns such as:

• Excluded by ‘noindex’
• Alternate page with proper canonical tag
• Duplicate without user-selected canonical
• Crawled - currently not indexed
• Discovered - currently not indexed
• Not found
• Blocked by robots.txt
• Server error

Each pattern suggests a different next check.

Step 2. Inspect a specific URL

Use URL Inspection on one affected page.

Check:

• whether the URL is in Google’s index
• the user-declared canonical
• the Google-selected canonical
• whether crawling was allowed
• whether indexing was allowed
• when it was last crawled
• whether the page could be fetched successfully

This separates “the sitemap did not help discovery” from “Google discovered it but rejected or deferred indexing”.

Step 3. Match the issue to the likely cause

Here is the simple diagnostic path.

If the page is “Excluded by ‘noindex’”:

• remove the noindex if the page should be indexable
• check whether the CMS, template, or plugin is applying it automatically

If the page is “Blocked by robots.txt”:

• allow crawling if you want indexing
• then make sure the page is not also carrying noindex or canonical conflicts

If the page is “Duplicate” or “Alternate page with proper canonical tag”:

• decide whether that is actually correct
• if the page should be primary, review canonicals, internal links, and duplicate paths
• make sure the sitemap lists the preferred version only

If the page is “Discovered - currently not indexed”:

• Google knows the URL exists, often from the sitemap or links, but has not crawled or processed it fully
• review internal linking, crawl efficiency, server reliability, and the overall value of the page set

If the page is “Crawled - currently not indexed”:

• Google has seen the page and not indexed it, at least for now
• this often points away from the sitemap and towards duplication, thin content, weak distinctiveness, or broader site quality signals

If the page returns “Not found” or server errors:

• fix the page or remove it from the sitemap
• do not keep dead URLs in the file as if they were valid inventory

This is also why we avoid overclaiming from crawl evidence alone. Googlebot fetching a page is not the same as indexing it, just as a visit from OAI-SearchBot or GPTBot is not proof of citation or training use.

If the diagnosis becomes messy after a redesign or traffic shift, our guide on how to investigate a change in search performance gives a more structured sequence.

When you should update, replace or remove a sitemap

You do not need to resubmit a sitemap every week out of habit. Once a stable sitemap is live and Google can read it, many small sites need very little manual attention.

Update, replace, or review a sitemap when:

You launch a new site or section

A new section, subfolder, or content type is a good reason to confirm that the sitemap includes it properly.

You migrate domains, protocols, or URL structures

After a migration, check that the sitemap reflects the new canonical URLs only. Old HTTP URLs, old subdomains, or redirected legacy paths should not linger in the current sitemap.

Your CMS or plugin changes its output

Plugins break. CMS updates alter settings. A sitemap that used to list only pages may suddenly include attachments, tags, or parameterised URLs. If discovered URL counts jump or collapse, inspect the generated file.

You remove large content sets

If you delete product lines, archive sections, or temporary campaign pages, the sitemap should stop advertising them. A sitemap full of dead URLs is not a harmless detail.

Google Search Console shows fetch or parsing problems

If Google can no longer read the file, fix and resubmit it. This is one of the few cases where a fresh submission is directly useful.

You split or consolidate sitemap files

Larger sites often move between a single sitemap and a sitemap index with child files. That is fine, provided the current submitted location reflects the new structure.

For smaller brochure sites, once the sitemap is stable, the main routine is simply to spot-check it after meaningful site changes. You do not need constant manual intervention if the CMS is behaving and the indexed pages match expectations.

Submitting a sitemap properly is a useful technical check, not a magic switch. If you confirm the file is clean, submit it in the right property, and then read the indexing evidence rather than assuming success, you will usually get to the real issue faster. For broader context, our SEO and AI search topic guides collect the related checks that sit around this one.