You already have a sitemap. WordPress has generated one in core since version 5.5, served at /wp-sitemap.xml, with no plugin required.
And you may not need it. Google's own threshold: you might not need a sitemap if "Your site is 'small'. By small, we mean about 500 pages or fewer on your site" and it is comprehensively linked internally.
More importantly, a sitemap does not cause indexing. Google states it directly: "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."
So the useful work here is small: make sure the sitemap lists what you want indexed and nothing else, submit it once, and go and do the internal linking instead.
What WordPress core gives you
Since 5.5, WordPress generates sitemaps automatically. They are produced on request rather than written as files.
The index lives at /wp-sitemap.xml and lists the sub-sitemaps.
By default it includes: all public and publicly queryable post types, all taxonomies, author archives, and the homepage.
Read that list against your archive decisions. If you have set tag archives to noindex — as WordPress categories and tags for SEO recommends for most sites — core's sitemap is still listing them, and you are sending two contradictory signals.
Two behaviours worth knowing:
It turns itself off when Settings → Reading discourages search engines. So a missing /wp-sitemap.xml is very often that checkbox rather than a sitemap fault.
It requires pretty permalinks. The plain /?p=123 structure disables core sitemaps entirely — one more reason the permalink decision comes first, as covered in WordPress permalinks and URL structure.
Core caps each sub-sitemap at 2,000 entries (filterable) and the index at 50,000 sitemaps — comfortably beyond what any normal site reaches.
The two tags Google ignores
This is the most useful thing on the page, because plugins expose settings for both.
Google's wording could not be plainer: "Google ignores <priority> and <changefreq> values."
So every hour spent setting a page's priority to 0.8 rather than 0.6, or telling Google a page changes weekly, is spent on nothing. These fields are ignored, and the settings screens exposing them are configuring a preference that has no reader.
The third tag, lastmod, is different — and conditional. Google uses it "if it's consistently and verifiably accurate", and it should reflect "the date and time of the last significant update to the page."
The two words doing the work are "consistently" and "significant". A site that updates lastmod every time a plugin touches a post — or on every page, nightly, regardless of change — is not consistently accurate, and the value stops being useful. A sitemap claiming everything changed yesterday tells Google nothing.
The practical rule: let your CMS set lastmod from genuine content edits, and do not "refresh" it to encourage recrawling. It does not work that way and it degrades the signal you would want later.
What belongs in a sitemap
One rule: the sitemap lists pages you want indexed. Nothing else.
| Include | Exclude |
|---|---|
| Posts | Anything set to noindex |
| Pages | Tag archives, on most sites |
| Category archives, if indexed | Date archives |
| The homepage | Author archives, on a solo site |
| Genuine landing pages | Search result pages |
| Thank-you and confirmation pages | |
| Paginated archive pages beyond page one | |
| Redirected or 404 URLs |
The contradiction to look for: a URL that is both in your sitemap and marked noindex. You have told Google to index it and not to index it, and the sitemap entry is wasted at best.
Checking for this takes two minutes and is the single most common sitemap fault on a WordPress site, because the plugin's noindex settings and its sitemap settings are configured on different screens.
Core sitemap or plugin sitemap
Both work. The difference is control.
Core's is automatic, needs no configuration, and includes everything public by default. Its limitation is that filtering it means writing filters — wp_sitemaps_post_types, wp_sitemaps_taxonomies and the rest are code, not settings.
A plugin's offers the same thing with checkboxes, and typically excludes noindex pages automatically — which resolves the contradiction above without you thinking about it.
When a plugin takes over, core's sitemap is disabled. That is expected behaviour and it accounts for a good share of "my sitemap URL changed" reports. Submit the new URL and move on.
The honest position: if you already run an SEO plugin, use its sitemap, because the automatic noindex exclusion is worth having. If you do not, core's is fine — and on a site under 500 pages with good internal linking, so is doing very little about either.
Setting it up properly
Six steps, once.
Step 1 — Find out what you actually have
Open /wp-sitemap.xml. If it loads, core's is running. If it 404s, either a plugin has replaced it — check the plugin's sitemap URL — or the discourage-search-engines checkbox is on.
Check /robots.txt too, which usually names the sitemap location.
Step 2 — Read it
Actually open the sub-sitemaps and look at the URLs.
You are looking for: archives you meant to exclude, noindex pages listed anyway, old URLs that now redirect, and anything you had forgotten was published.
This step finds more problems than any other and almost nobody does it.
Step 3 — Exclude what should not be there
Through the plugin's settings if you have one; through filters if you are on core.
Make it agree with your noindex rules. The two must say the same thing.
Step 4 — Submit it once in Search Console
Sitemaps → add the URL. Once.
Resubmitting does not make Google crawl faster, and a sitemap does not cause indexing. Submitting it is a discovery aid, not a request.
Step 5 — Read the Pages report, not the sitemap status
The sitemap report tells you the file was read. The Pages report tells you what is actually indexed and why things are not — which is the question you had.
Method in Google Search Console reports, read properly, and the diagnosis of specific exclusions in why a page is not indexed.
Step 6 — Leave it alone
It regenerates automatically. There is no maintenance task here, and nothing you do to a sitemap file will improve indexing on a site whose problem is elsewhere.
When a sitemap actually matters
Being fair to the thing, because "you probably do not need one" is not the same as "they are useless".
Google names the cases: a large site, where "it's more difficult to make sure that every page is linked by at least one other page"; a new site with few external links; and sites with rich media or news content.
The common thread is discovery. A sitemap helps when pages are hard to reach by following links.
Which points at the real fix. If pages on your site are only discoverable via the sitemap, the sitemap is compensating for internal linking that is not doing its job — and internal linking does more, because it also passes context and authority that a sitemap entry does not. That is the argument in internal linking and topic clusters.
Frequently asked questions
Does WordPress have a sitemap by default?
Yes. Since WordPress 5.5, core generates XML sitemaps automatically at /wp-sitemap.xml, covering all public post types, all taxonomies, author archives and the homepage. No plugin is required.
Do I need a sitemap plugin for WordPress?
Not necessarily. Core's sitemap works, and Google says a site of about 500 pages or fewer that is comprehensively linked internally may not need a sitemap at all. A plugin's advantage is excluding noindex pages with checkboxes rather than code.
Will a sitemap get my pages indexed?
No. Google states that a sitemap helps search engines discover URLs but does not guarantee that everything in it will be crawled and indexed. If pages are not being indexed, the cause is elsewhere.
Does priority in a sitemap do anything?
No. Google ignores the priority and changefreq values entirely, despite plugins exposing settings for both. Time spent configuring them achieves nothing.
What does lastmod do?
Google uses it if it is consistently and verifiably accurate, and it should reflect the last significant update to the page. Updating it without a real change makes it unreliable and the signal stops being useful.
Why did my WordPress sitemap disappear?
Usually the "Discourage search engines from indexing this site" setting, which disables core sitemaps automatically. Otherwise an SEO plugin has taken over and moved the sitemap to its own URL, or permalinks are set to plain, which disables core sitemaps.
What should I exclude from my WordPress sitemap?
Anything set to noindex, tag archives on most sites, date archives, search result pages, thank-you pages, and redirected URLs. A URL that is both in the sitemap and noindexed is a contradiction worth fixing.
How often should I resubmit my sitemap?
Once. Resubmitting does not speed up crawling, and WordPress regenerates the sitemap automatically as you publish.
What to do next
Open /wp-sitemap.xml on your own site, or your plugin's sitemap, and actually read one of the sub-sitemaps.
If it lists tag archives, date archives or anything you have set to noindex, you have found a contradiction you can fix in one settings screen — and that is the entire job.
Related guides
- WordPress SEO: what the platform decides for you — where sitemaps sit among the defaults
- WordPress categories and tags for SEO — deciding what should be listed
- WordPress permalinks and URL structure — why plain permalinks disable core sitemaps
- Choosing a WordPress SEO plugin — what replaces core's sitemap
- Why a page is not indexed — the report that actually answers the question
- Google Search Console reports, read properly — Pages, not sitemap status
- Internal linking and topic clusters — what a sitemap is usually compensating for
The short version
- Find out what you actually haveOpen /wp-sitemap.xml. If it 404s, either a plugin has replaced it or the discourage-search-engines checkbox is on. Check /robots.txt too, which usually names the sitemap location.
- Read itOpen the sub-sitemaps and look at the URLs. Look for archives you meant to exclude, noindex pages listed anyway, old URLs that now redirect, and things you forgot were published.
- Exclude what should not be thereThrough the plugin's settings, or through filters on core. Make the sitemap agree with your noindex rules u2014 the two must say the same thing.
- Submit it once in Search ConsoleOnce. Resubmitting does not make Google crawl faster, and a sitemap does not cause indexing.
- Read the Pages report, not the sitemap statusThe sitemap report says the file was read; the Pages report says what is indexed and why things are not, which is the question you had.
- Leave it aloneIt regenerates automatically. There is no maintenance task, and nothing done to a sitemap file improves indexing on a site whose problem is elsewhere.
The WordPress Email Delivery Checklist
Stop your WordPress emails from failing silently. Get the complete setup guide.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Choosing a WordPress SEO Plugin
This page names no winner, and the reason is that the choice matters far less than the category's marketing implies. The major WordPress SEO plugins do the same six things. They have converged, they will continue to converge, and the difference between them is interface preference and a small number of features most sites never […]
Two-Factor and Login Hardening for WordPress
Login attacks against WordPress are constant, automated and indiscriminate. Every public WordPress site receives them, regardless of size or traffic, because the cost of trying is near zero. They are also the least successful route into a WordPress site. Vulnerable plugins account for more compromises than password guessing, which is worth holding onto — login […]
WordPress Email: Why Your Site’s Emails Never Arrive
WordPress sends email in a way that fails modern authentication by default, and it reports success while doing it. That combination is why this problem is so persistent. The site is not broken. Nothing is logged. wp_mail() returns true, the order is placed, the form says thank you — and the message never reaches an […]