Submit a Sitemap to Google Search Console Correctly

To submit a sitemap to Google, you find your sitemap URL, check that it loads with HTTP 200, test it with URL Inspection in Search Console, and then paste it into the Sitemaps report and click Submit. After that, you read the status Google shows and fix anything that says "Has errors" or "Couldn't fetch". The whole job usually takes less than half an hour.

If your site runs on WordPress 5.5 or newer, WordPress already builds a sitemap for you. Most people never look at it, so they never notice when a plugin switches it off.

By the end of this guide you will know where your sitemap lives, how to prove it works, how to submit it, and how to read what Google tells you about it.

What is a sitemap, and does Google really need one?

Google describes a sitemap as "a file where you provide information about the pages, videos, and other files on your site". In plain words, it is a list of the pages you want search engines to know about, written in a format machines can read.

Think of a shop that hands a delivery driver a printed list of every address on the route. The driver could find the houses by driving around, but the list is faster and a quiet street is less likely to be missed. Google's crawler (the program that visits and reads web pages, called Googlebot) works the same way: it can follow your links, but a sitemap points it straight at the pages you care about.

Why this matters: a sitemap is a hint, not an order. Google says a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed." It helps Google discover pages, but the pages still need to be worth indexing.

Do you even need one?

Google's own guidance says you might not need a sitemap if your site is small, which it defines as "about 500 pages or fewer", your important pages are linked from other pages on your site, and you do not have many video, image or news pages.

You probably do want one if your site is large, if it is new and "has few external links to it", or if you publish a lot of video, image or news content.

Quick tip: if your CMS already makes a sitemap, submitting it costs nothing and gives you a useful report in Search Console.

Before you start

Gather these things first so you do not have to stop halfway:

• Search Console access as an owner. Google says "You must have owner permissions on a property to submit a sitemap using the Sitemaps report." If your domain is not verified yet, follow our guide to verifying your domain in Google Search Console with a TXT record first.
• Your site's live address, including https:// and whether it uses www or not. Your sitemap URLs must match this exactly.
• A login to your WordPress dashboard or hosting panel, so you can check plugins and files.
• A terminal with `curl` if you want the command line checks. This is optional, a browser is enough for most steps.
• About 20 to 30 minutes. Google's processing of the sitemap happens later and needs no attention from you.
• Risk level: low. Submitting a sitemap does not change your website. The only step that changes a live file is editing robots.txt, and we keep that edit to one line.

Find and test your sitemap

Step 1: Find the sitemap WordPress already made

WordPress added built-in XML sitemaps in version 5.5. The WordPress core team announced that WordPress "will expose a sitemap index at /wp-sitemap.xml."

A sitemap index is a sitemap that lists other sitemaps. WordPress uses one index that points to smaller sitemaps for posts, pages, categories and so on. Each of those smaller files holds up to 2,000 entries by default.

Open this address in your browser, replacing the domain with your own:

https://example.com/wp-sitemap.xml

You should see a page listing several sitemap links. If you see your normal 404 "page not found" page instead, jump to the plugin step below, because something has probably replaced or switched off the core sitemap.

WordPress disables its core sitemaps when the site is set to discourage search-engine indexing. Check this setting if a public production sitemap is missing, but keep it enabled on a private staging site and protect staging with authentication. A missing sitemap alone does not establish the cause of a traffic loss.

Step 2: Check whether an SEO plugin owns the sitemap

Many SEO plugins create their own sitemap and turn off the WordPress one. A WordPress core contributor noted that "Yoast SEO disables the core sitemap in favor of their own solution."

If you use Yoast SEO, go to Yoast SEO > Settings > Site features, make sure the XML sitemaps toggle under Technical SEO is on, and click View the XML sitemap to open the exact URL. For any other SEO plugin, look for a sitemap section in its settings and copy the URL it shows you.

Quick tip: use only one sitemap source. Yoast's own help page advises you to "disable other sitemap plugins and remove any physical sitemap files" before turning on its sitemaps. Two competing sitemaps make troubleshooting much harder.

Step 3: Check the sitemap in a browser

Open the sitemap URL and click through to one of the child sitemaps. Look at a few of the listed page addresses.

Each address should be a full URL starting with https://, on the same domain you use publicly. Google asks you to "Use fully-qualified, absolute URLs in your sitemaps," and the file "must be UTF-8 encoded."

Also check that the URLs are the versions you want people to land on. Google's guidance is: "If you have the same content accessible under different URLs, choose the URL you prefer." If your sitemap lists http:// addresses that redirect to https://, that is a problem we fix in Troubleshooting. Our guide on checking an HTTP redirect chain helps you see where each address really ends up.

Step 4: Check the response with curl

The -I option makes a HEAD request for response headers, not the XML body. It is a quick diagnostic, not proof that a normal GET returns a valid sitemap. Also open the file, inspect a child sitemap and check the Sitemaps report; some servers handle HEAD and GET differently.

This command requests only the response headers for the WordPress sitemap index:

curl -I https://example.com/wp-sitemap.xml

You want to see a first line containing 200, and a Content-Type header that contains xml. A 404 means the sitemap is not there. A 301 or 302 means it redirects, so copy the final address and test that instead. A 503 usually means the site is in maintenance mode or overloaded. If that happens, our guide on HTTP 503 during maintenance and what it means for SEO explains why it matters and how long is safe.

Step 5: Look at what a valid sitemap contains

You rarely need to write a sitemap by hand on WordPress, but knowing the shape helps you spot a broken one. Google's example shows the basic structure of an XML sitemap with one page in it:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/foo.html</loc>
    <lastmod>2022-06-04</lastmod>
  </url>
</urlset>

The <loc> tag holds the page address and <lastmod> holds the date it last changed. Google says it "ignores <priority> and <changefreq> values", so do not spend time tuning those. It uses <lastmod> only if the value is "consistently and verifiably" accurate.

Google also accepts RSS 2.0 and Atom 1.0 feeds, and plain text sitemaps with one URL per line and a .txt extension.

Submit the sitemap in Search Console

Step 1: Run a live URL inspection on the sitemap

Before submitting, Google recommends that you test the sitemap URL itself. In Search Console, paste the full sitemap URL into the URL Inspection search bar, then run a live URL inspection (the live test).

Look at the Page fetch line. Google's help page says to confirm that it shows "Successful". If it shows anything else, fix that first, because the Sitemaps report will hit the same wall.

This test checks whether Google can fetch the sitemap file. It does not validate every XML entry or establish that the pages listed in it will be indexed. Use the Sitemaps report for parsing errors, and inspect individual page URLs separately when diagnosing indexing.

Step 2: Open the Sitemaps report and submit

Open the Sitemaps report from the Search Console menu for your property. Paste the sitemap URL into the Add a new sitemap box and click Submit.

On WordPress, submit the index (/wp-sitemap.xml, or your SEO plugin's index) rather than every child sitemap. Google confirms that "you can use a sitemap index file as a way to submit many sitemaps at once."

What you should see: the sitemap appears in the list of submitted sitemaps with columns such as "Sitemap URL", "Type", "Submitted", "Last read", "Status" and "Discovered pages". Google fetches the sitemap soon after you submit, but crawling the pages in it can take much longer.

Step 3: Add a Sitemap line to robots.txt as a backup

The robots.txt file is a small text file at the top of your site that tells crawlers which areas they may visit. It can also point crawlers to your sitemap, and Google says to "Insert the following line anywhere in your robots.txt file."

This line tells every crawler where to find your sitemap index:

Sitemap: https://example.com/wp-sitemap.xml

Google's rules for this line are clear: "It must be a fully qualified URL, including the protocol and host," and "The sitemap field isn't tied to any specific user agent." You may list more than one Sitemap: line if you have several sitemaps.

This is also your route if you are not an owner on the Search Console property. Google picks up the line "the next time we crawl your robots.txt file."

Quick tip: the WordPress core team said the robots.txt that WordPress generates "will reference the sitemap index", so check your live https://example.com/robots.txt before adding a duplicate line. If you are editing robots.txt for other reasons too, our guide to robots.txt rules for GPTBot, ClaudeBot and Google-Extended shows how to keep the file tidy.

Variants: cPanel, Plesk, Nginx and SEO plugins

cPanel

If you uploaded a static sitemap file yourself, it should sit in your web root so it can cover the whole site. Google notes that a sitemap at the site root "can affect all files on the site." cPanel's documentation describes the web root as public_html, and shows the document root path as /home/user/public_html, where user is your cPanel username.

To check the file, open File Manager, go to public_html, right-click the sitemap file and choose View Files. cPanel's File Manager cannot edit files larger than 1 MB, so download large sitemaps and open them locally instead.

Plesk

On a Linux Plesk server, Plesk's documentation lists httpdocs as the folder for "HTTP documents", at /var/www/vhosts/<vhost>/httpdocs. A static sitemap.xml belongs in that folder for the main site.

Your actual document root can be changed per site. In Plesk, click Hosting Settings below the site's name at Websites & Domains and check the Document root field before uploading anything.

Nginx

On Nginx, a static sitemap file is served from whatever folder the root directive points to. Nginx builds the file path "by merely adding a URI to the value of the root directive", so a request for /sitemap.xml maps to sitemap.xml inside that folder.

This minimal server block illustrates static-file lookup only. Do not replace an existing production, HTTPS or WordPress configuration with it. An administrator should preserve the complete site configuration and test any proposed change before reloading:

server {
    server_name example.com;
    root /var/www/example.com;

    location / {
        try_files $uri $uri/ =404;
    }
}

The mime.types file that ships with Nginx maps the .xml extension to text/xml, so the content type check from earlier should pass as long as that file is included in your config. For WordPress on Nginx, the sitemap is generated by PHP rather than stored as a file, so leave your existing WordPress rules in place and simply test the URL with curl.

SEO plugins

Keep this short: if a plugin generates your sitemap, use the plugin's URL everywhere, in Search Console and in robots.txt. Do not also upload a static sitemap.xml to the web root, and do not submit the core /wp-sitemap.xml if the plugin has turned it off.

Split a sitemap when it gets too big

Each sitemap has a limit. Google says: "All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs." Above that, you split it into several files and list them in a sitemap index.

A sitemap index "may have up to 50,000 loc tags", and the child sitemaps "must be hosted on the same site as your sitemap index file" and "must be in the same directory as the sitemap index file, or lower in the site hierarchy." You can submit up to 500 sitemap index files for each site in Search Console.

This example index points Google to two child sitemaps:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap2.xml.gz</loc>
  </sitemap>
</sitemapindex>

Invented example: Amira runs a recipe site on WordPress with about 9,000 posts. She submits /wp-sitemap.xml, and Search Console shows one index with several child sitemaps underneath, each holding up to 2,000 posts. She never has to touch the limits, because WordPress split the list on its own.

How to check it worked

Run these checks a day or two after submitting:

1. In the Sitemaps report, the Status column for your sitemap says "Success", which Google defines as "The sitemap was loaded and processed successfully with no errors."
2. The "Last read" date is recent, which shows Google has fetched it after your submission.
3. Compare Discovered pages with the eligible URLs your sitemap actually lists, including any intentional exclusions. A lower number is a clue to investigate, not proof of a plugin fault, and discovered URLs are not the same as indexed pages.
4. Running curl -I on the sitemap URL still returns 200 and an xml content type.
5. Your live robots.txt contains exactly one Sitemap: line per sitemap, each with a full https:// URL.

You do not need to resubmit every time you publish. Google says it "will periodically recrawl the sitemap at a pace unrelated to the regular site crawl," and says to resubmit if you make big changes to a sitemap.

Troubleshooting

Status says "Couldn't fetch"

Symptom: the Status column shows "Couldn't fetch", meaning "The sitemap could not be fetched for some reason."

Likely cause: the URL is wrong (a 404), the server returned an error, or robots.txt blocks it. Fix: open the URL in a private browser window, run curl -I on it, and run a live URL inspection. Google retries a failed fetch for a few days and then stops, so once you fix the cause, submit the sitemap again.

Status says "Has errors"

Symptom: "Has errors", described as "The sitemap could be fetched, but has one or more errors." Google still queues any URLs it could read.

Likely cause: open the sitemap's details to see the exact error. Common ones include "Invalid date" (use W3C Datetime format, such as a plain date), "Parsing error" (escape characters like &), "Invalid URL in sitemap index file: incomplete URL" (use full URLs for each child sitemap) and "Too many URLs" (split the sitemap). Fix the source, usually the plugin or the file, then resubmit.

The sitemap is blocked by robots.txt

Symptom: URL Inspection says the URL is blocked by robots.txt, or the Sitemaps report lists a robots.txt block as the reason it could not fetch.

Likely cause: a Disallow: rule that is too broad, for example one that blocks every .xml file or the whole site. Fix: remove or narrow the rule that matches the sitemap address, then run the live inspection again until Page fetch shows "Successful".

The sitemap lists URLs that redirect or are not canonical

Symptom: "Discovered pages" looks fine, but Search Console's other reports show many pages as redirects or duplicates. Google's error list includes "URLs not followed" for this case.

Likely cause: the site address saved in WordPress still uses http:// or the wrong www form, so every listed URL redirects. Fix: Google says to replace redirecting URLs with final URLs. Correct the saved site address so the sitemap lists your real, final URLs, and make sure the www form in the URLs matches where the sitemap lives, because Google also flags a "Path mismatch" for that.

The sitemap returns 404 after installing or removing a plugin

Symptom: /wp-sitemap.xml returns your 404 page, and Search Console says "Couldn't fetch".

Likely cause: an SEO plugin turned off the core sitemap, or custom code uses the wp_sitemaps_enabled filter to switch it off. WordPress documents that when sitemaps are disabled this way, "rewrite rules are still in place to ensure a 404 is returned." Fix: submit the plugin's sitemap URL instead. If you removed the plugin, check whether the core sitemap is back. If it is still 404, ask a developer to search the theme and custom plugins for wp_sitemaps_enabled.

Pro tips and security notes

• Use a Search Console property that includes the sitemap URL. A URL-prefix property is limited to its configured protocol, host and path; a Domain property covers protocols and subdomains within its domain. Do not accidentally inspect an unrelated http or non-www URL-prefix property.
• Removing a sitemap from the report does not make Google forget it. Google says "Deleting a sitemap removes the sitemap from this report, but Google won't forget the sitemap or any URLs listed in it."
• Do not list private or staging pages in a public sitemap. Protect confidential content with authentication and authorization: robots.txt and noindex are not access controls. To keep a public page out of Search with noindex, Google must be allowed to crawl it and read that instruction.

Ask your host or a developer for help when curl shows a 403 or 503 that you cannot explain, when a firewall or security plugin blocks Googlebot, or when the sitemap only fails on the live server and works everywhere else.

The one message worth forwarding

If something is wrong and you need help, send this message to your developer or host:

Hi, Google Search Console reports a problem with our sitemap at https://example.com/wp-sitemap.xml. Could you please check that this URL returns HTTP 200 with an XML content type to outside visitors and to Googlebot, that no firewall, security plugin or robots.txt rule blocks it, and that it lists our final https:// URLs without redirects? If an SEO plugin should own the sitemap instead, please tell me the correct sitemap URL so I can submit that one. Thank you.

The short version: find the sitemap your site already has, prove it returns 200 with curl, submit it once in the Sitemaps report, and then let the status column tell you what, if anything, needs fixing.