An XML sitemap is a file that helps search engines discover important URLs on a website. It provides crawlers with a structured list of pages that site owners want search engines to know about and can make content discovery easier, especially on larger or more complex websites.
For a WordPress website, an XML sitemap can contain posts, pages, custom post types, taxonomy archives and other public content. It acts as an additional discovery mechanism alongside normal internal links.
An XML sitemap is useful for SEO, but it is important to understand what it actually does. A sitemap does not guarantee indexing, does not improve rankings by itself and cannot compensate for poor content or weak website architecture.
Its job is simpler: helping search engines discover the URLs that actually matter.
The challenge in WordPress is deciding which URLs belong in that list. Public post types, custom post types, taxonomy archives, canonical URLs, robots directives and redirected pages can all affect whether a sitemap accurately represents the site’s indexing strategy.
In this guide, we will look at how XML sitemaps work, what should and should not be included and how TheOneWP can provide more control when WordPress’s default sitemap behaviour is not enough.
What is an XML sitemap?
An XML sitemap is a machine-readable file containing a collection of URLs from a website.
Unlike a normal webpage designed primarily for human visitors, an XML sitemap is structured for search engines and other compatible crawlers. It follows the standardized Sitemap protocol so crawlers can process URLs consistently.
A basic sitemap might look like this:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
<lastmod>2026-08-18</lastmod>
</url>
<url>
<loc>https://example.com/guides/</loc>
<lastmod>2026-08-16</lastmod>
</url>
</urlset>
Each <url> element represents one URL included in the sitemap.
The <loc> element contains the absolute URL:
<loc>https://example.com/guides/xml-sitemaps/</loc>
An optional <lastmod> element can indicate when that page was last significantly modified:
<lastmod>2026-08-18</lastmod>
A real sitemap may contain hundreds or thousands of URLs rather than the two shown in this simplified example.
The exact XML format, required elements and sitemap limits are defined by the Sitemaps protocol.
Why does an XML sitemap matter?
Search engines normally discover pages by following links.
If your homepage links to a category page, and that category page links to an article, a crawler can follow those links until it reaches the article.
An XML sitemap gives search engines another structured way to discover that article.
This becomes particularly useful when:
- a website contains a large number of pages;
- a website has recently launched;
- some pages are several levels deep in the site structure;
- new content is published frequently;
- the website contains several custom post types;
- some important URLs receive relatively few internal links;
- large sections of content have recently been created or reorganized.
The sitemap therefore provides an additional source of URLs for crawlers to discover.
How search engines discover pages without a sitemap
Search engines discover links while crawling the web.
When a crawler finds a link such as:
<a href="https://example.com/wordpress-guide/">
WordPress Guide
</a>
it can discover the destination URL and potentially crawl it later.
This is why internal linking remains one of the foundations of a healthy website structure.
A sitemap does not replace that system. It supplements it.
A properly linked page can still be discovered without appearing in an XML sitemap, while a sitemap entry does not automatically make the corresponding page important within the website’s architecture.
An XML sitemap does not guarantee indexing
One of the most common sitemap misconceptions is that submitting a URL means search engines must index it.
They do not.
Sitemap inclusion effectively communicates:
This is a URL on my website that I want search engines to know about.
Search engines still decide whether the page should actually appear in their index.
A page may be discovered through a sitemap and still not be indexed because of issues such as:
- thin or low-value content;
- duplicate or near-duplicate content;
- a
noindexdirective; - a canonical pointing somewhere else;
- access restrictions;
- server errors;
- other crawling or indexing decisions made by the search engine.
Think of the sitemap as a discovery signal, not an indexing command.
If pages are already present in the sitemap but still do not appear in Google, see Why isn’t my WordPress site showing up on Google? for the broader indexing checks.
Does an XML sitemap improve rankings?
Not directly.
Creating an XML sitemap does not automatically make a page rank higher.
Its value is primarily in discovery and crawl management. Helping a search engine discover a URL is a necessary preliminary step before that URL can be crawled, evaluated and potentially indexed.
But if the page itself is weak, a sitemap will not rescue it.
SEO still depends on content quality, relevance, technical accessibility, internal linking, site architecture and many other signals.
What URLs should be included in an XML sitemap?
A sitemap should generally contain canonical URLs that you want search engines to discover and potentially index.
Typical examples include:
- important posts;
- important pages;
- public custom post type entries;
- useful taxonomy archives;
- other canonical public URLs intended for organic search.
A useful rule is:
If you would not want the URL appearing in search results, ask whether it belongs in the sitemap at all.
Sitemap configuration should reflect the site’s actual indexing strategy rather than blindly listing every URL WordPress can generate.
What should not be included in an XML sitemap?
Not every accessible URL needs to appear in the sitemap.
Depending on the website, you may want to exclude URLs such as:
- pages intentionally marked
noindex; - temporary utility pages;
- duplicate URL variations;
- internal search result pages;
- low-value archives;
- private or restricted content;
- obsolete URLs that redirect elsewhere;
- URLs whose canonical points to another page.
Including these URLs can produce a sitemap that does not match the site’s real indexing strategy.
This is one of the main reasons to use a sitemap system that gives you control over post types and taxonomies instead of simply accepting every public WordPress object automatically.
Managing sitemap inclusion with TheOneWP
TheOneWP’s XML Sitemap module provides dedicated sitemap management inside WordPress.
Instead of treating the sitemap as a fixed list generated from whatever WordPress happens to expose, you can configure which content structures should participate in it.
This is particularly useful on websites with:
- multiple custom post types;
- custom taxonomies;
- utility content;
- content structures that should remain public but outside organic search;
- large editorial architectures that need cleaner sitemap separation.
The goal is not to maximize the number of sitemap URLs. It is to expose the right URLs.
What is a sitemap index?
Large websites do not necessarily place every URL inside one XML file.
Instead, they can use a sitemap index.
A sitemap index contains references to several individual sitemap files:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/post-sitemap.xml</loc>
</sitemap>
<sitemap>
<loc>https://example.com/page-sitemap.xml</loc>
</sitemap>
<sitemap>
<loc>https://example.com/guide-sitemap.xml</loc>
</sitemap>
</sitemapindex>
This allows content to be separated logically.
For example:
/sitemap_index.xml
/post-sitemap.xml
/page-sitemap.xml
/guide-sitemap.xml
/product-sitemap.xml
/category-sitemap.xml
Separating content types makes larger sitemap structures easier to inspect and troubleshoot.
TheOneWP XML Sitemap follows this model by using a sitemap index and separate sitemap files for supported content groups.
How many URLs can an XML sitemap contain?
The Sitemap protocol limits an individual sitemap file to 50,000 URLs and an uncompressed size of 50 MB.
If a website exceeds either limit, the URLs must be divided across multiple sitemap files.
A sitemap index can then reference those files.
For ordinary WordPress websites, this splitting should normally be handled automatically by the sitemap system rather than assembled manually.
What does lastmod mean in an XML sitemap?
The <lastmod> value indicates when the content represented by a URL was last significantly modified.
For example:
<url>
<loc>https://example.com/guides/wordpress-security/</loc>
<lastmod>2026-08-18</lastmod>
</url>
This can give crawlers useful information about pages that have changed since an earlier visit.
The important word is significantly.
Google recommends using lastmod only when the value represents a real meaningful change and is consistently accurate.
Updating the date every day when the content itself has not meaningfully changed makes the signal less useful.
What about priority and changefreq?
The Sitemap protocol supports optional elements such as:
<changefreq>weekly</changefreq>
<priority>0.8</priority>
These describe a suggested change frequency and relative priority within the site.
However, Google states that it ignores both <changefreq> and <priority>.
This means:
<priority>1.0</priority>
does not tell Google that a page deserves better rankings or privileged crawl treatment.
The official Google Search Central sitemap documentation explains which sitemap elements Google uses and which it ignores.
If changing a decimal were enough to dominate search results, technical SEO would have been conquered by spreadsheet dropdowns a long time ago.
XML sitemap vs HTML sitemap
An XML sitemap and an HTML sitemap serve different audiences.
XML sitemap
An XML sitemap is primarily designed for crawlers.
https://example.com/sitemap_index.xml
HTML sitemap
An HTML sitemap is a normal webpage designed primarily for visitors.
It may contain organized links to:
- Services;
- Products;
- Guides;
- Documentation;
- Contact information.
Both can help content discovery, but they solve different problems.
XML sitemap vs robots.txt
An XML sitemap should also not be confused with robots.txt.
A sitemap helps crawlers discover URLs.
A robots.txt file provides crawling rules.
For example:
User-agent: *
Disallow: /private-area/
tells compatible crawlers not to crawl the matching path.
Meanwhile:
Sitemap: https://example.com/sitemap_index.xml
can advertise the location of the sitemap.
These systems complement each other but are not interchangeable.
For the distinction between crawling rules and indexing controls, see What is robots.txt, and why does it matter for SEO?.
Manage robots.txt and sitemaps together
A sitemap that advertises important URLs makes little sense if crawler rules simultaneously block the sections containing those URLs.
This is why sitemap and robots configuration should be reviewed together.
TheOneWP includes a Robots.txt module alongside XML Sitemap, allowing crawler rules and sitemap configuration to remain part of the same technical SEO toolkit.
The modules solve different problems:
XML Sitemap
→ which URLs should crawlers discover?
Robots.txt
→ which paths should compatible crawlers access?
Keeping those responsibilities separate but visible in the same toolkit reduces the chance of creating contradictory configurations.
Should you add your XML sitemap to robots.txt?
Adding a sitemap reference to robots.txt is a standard way to expose its location to compatible crawlers.
A typical entry is:
Sitemap: https://example.com/sitemap_index.xml
This does not replace sitemap submission through search engine webmaster tools, but it provides another discovery mechanism.
When reviewing crawler rules, make sure sitemap configuration is not accompanied by broader directives that accidentally block important content.
See Common robots.txt mistakes that hurt SEO for the failure cases worth checking.
XML sitemaps in WordPress
WordPress core has included native XML sitemap functionality since WordPress 5.5.
The default sitemap index is available at:
https://example.com/wp-sitemap.xml
WordPress generates the sitemap dynamically rather than requiring a static XML file to be maintained manually.
The WordPress Core team documents the implementation in its official WordPress XML Sitemaps documentation.
For many basic websites, the native sitemap provides a perfectly functional starting point.
The limitation appears when the website needs more deliberate control over which post types and taxonomies belong in its organic search structure.
When WordPress core sitemaps may not be enough
A simple site containing standard posts and pages may require little more than the default WordPress sitemap.
A more complex website may contain:
- public custom post types intended for search;
- public custom post types intended only for application functionality;
- custom taxonomy archives;
- content structures with different indexing strategies;
- content created by multiple plugins.
At that point, simply exposing everything WordPress considers eligible may not match the actual SEO strategy.
TheOneWP’s XML Sitemap module gives administrators more explicit control over the sitemap structure instead of relying entirely on core defaults.
WordPress custom post types and XML sitemaps
Custom post types deserve particular attention because not every custom post type should necessarily become a search landing page.
Imagine a website containing:
- blog posts;
- documentation;
- portfolio projects;
- internal templates;
- utility content.
The first three might be useful search destinations, while the final two may exist only for site functionality.
Automatically including every public content structure without reviewing its purpose can expose URLs that do not belong in the site’s organic search strategy.
Before deciding whether a custom post type belongs in the sitemap, review its public URLs, archive value, canonical behaviour and indexing purpose.
See WordPress custom post types and SEO for the broader content-model considerations.
Use XML Sitemap selectively with custom post types
This is one of the stronger use cases for TheOneWP XML Sitemap.
The module allows sitemap configuration to follow the site’s actual WordPress content model rather than treating every registered content type equally.
For example:
Posts
→ include
Pages
→ include
Guides
→ include
Projects
→ include
Internal Templates
→ exclude
Utility Content
→ exclude
That creates a cleaner sitemap that better reflects the URLs intended for search discovery.
Should taxonomy archives appear in an XML sitemap?
Categories, tags and custom taxonomies can create useful archive pages, but they can also produce large numbers of low-value URLs.
A taxonomy archive can be valuable when it acts as a real topic hub containing:
- a useful introduction;
- multiple relevant pieces of content;
- clear navigation;
- a meaningful purpose for visitors.
A taxonomy archive containing one item and no unique information is a very different case.
Do not decide whether taxonomies belong in the sitemap solely because WordPress can generate them.
TheOneWP XML Sitemap can include selected registered taxonomies, making it possible to align taxonomy sitemap visibility with the site’s actual content architecture.
How XML sitemaps work with canonical URLs
Sitemap URLs should generally correspond to the canonical versions of your pages.
Imagine these two URLs display essentially the same content:
https://example.com/product/
https://example.com/product/?ref=campaign
If the canonical version is:
https://example.com/product/
that is normally the version that belongs in the sitemap.
Filling a sitemap with non-canonical variations creates an inconsistent representation of which URLs the website considers primary.
Manage canonical URLs alongside sitemap configuration
Sitemap inclusion and canonical configuration are closely related.
TheOneWP’s SEO Meta module provides page-level canonical and robots controls, while XML Sitemap controls which content structures appear in the sitemap.
Together, those controls help maintain a cleaner relationship between:
Canonical URL
→ preferred page version
Robots directives
→ indexing preference
XML Sitemap
→ URLs advertised for discovery
Those signals should normally point in the same direction.
Do redirected URLs belong in the sitemap?
Normally, obsolete URLs that permanently redirect elsewhere should not remain in the active sitemap.
Consider:
https://example.com/old-guide/
→ 301
https://example.com/new-guide/
The sitemap should normally contain:
https://example.com/new-guide/
rather than continuing to advertise the obsolete address.
Redirects remain useful for visitors, external links and previously discovered URLs, but the sitemap should represent the website’s current preferred URL structure.
Use Redirect Manager when sitemap URLs move
When content changes location, the sitemap should reflect the new canonical URL while the old address may still need to redirect visitors and crawlers.
TheOneWP’s Redirect Manager can handle 301, 302 and 410 responses for those URL changes.
The roles are different:
Redirect Manager
→ handles what happens when an old URL is requested
XML Sitemap
→ advertises the current URL structure
Keeping obsolete URLs out of the sitemap while redirecting them appropriately creates a cleaner migration path.
Should noindex pages be in an XML sitemap?
As a general SEO practice, intentionally noindex pages should not normally be included in a sitemap whose purpose is to expose URLs intended for indexing.
Otherwise the site effectively communicates:
Here is a URL I am actively advertising for discovery, but the page itself says it should not appear in the index.
That does not automatically create a disaster, but it makes the sitemap less consistent.
A well-maintained sitemap should reflect the intended indexable URL set as closely as practical.
Keep robots directives and sitemap inclusion aligned
This is another area where XML Sitemap and SEO Meta work well together.
If an editor intentionally applies noindex to a page, the broader sitemap configuration should not be designed around indiscriminately exposing every possible URL.
The goal is consistency between page-level SEO controls and site-wide discovery configuration.
Submitting an XML sitemap to Google Search Console
Once a sitemap is publicly accessible, it can be submitted through Google Search Console.
Search Console allows verified site owners to provide the sitemap URL and monitor whether Google was able to fetch and process it.
This can help expose problems such as inaccessible or malformed sitemap files.
Submitting a sitemap does not create the sitemap and does not guarantee indexing.
It simply tells Google where the sitemap can be found.
How often should an XML sitemap update?
A dynamic WordPress sitemap should normally reflect changes to the content it represents automatically.
Publishing a new indexable post should cause its URL to become available in the relevant sitemap without requiring somebody to edit XML manually like it is still 2006.
Likewise, removing or changing the public status of content should eventually be reflected by the sitemap generator.
The objective is for the sitemap to describe the site’s current eligible URL structure rather than becoming a historical archive of every URL that has ever existed.
Should you resubmit the sitemap every time you publish?
Normally, no.
Once Google knows the sitemap URL, you do not need to submit the same sitemap again after every new post.
A dynamic sitemap can change while remaining available at the same URL.
The more useful maintenance task is making sure it remains accessible and accurately reflects the site’s current content.
Common XML sitemap mistakes
1. Including every URL WordPress generates
More sitemap URLs do not automatically mean better SEO.
Include URLs that actually belong in the site’s indexing strategy.
2. Including noindex pages
If a page is deliberately excluded from indexing, including it in an index-oriented sitemap usually creates unnecessary inconsistency.
3. Including redirected URLs
Sitemap entries should normally point directly to current canonical destinations rather than obsolete URLs that immediately redirect.
4. Including duplicate URL variations
Tracking parameters and alternative representations of the same content should not unnecessarily inflate the sitemap.
5. Assuming the sitemap replaces internal linking
An XML sitemap is not a substitute for a usable website architecture.
6. Using inaccurate modification dates
Do not make every page appear freshly modified when nothing meaningful has changed.
7. Obsessing over priority and changefreq
Google ignores these values, so adjusting decimals is not a productive substitute for improving the site.
8. Creating a sitemap and never reviewing it again
Website structures evolve.
New post types appear, sections disappear and indexing strategies change. Sitemap configuration should evolve with them.
9. Treating sitemap configuration separately from robots and canonical rules
Sitemaps, robots directives, canonicals and redirects describe different parts of the same URL architecture.
They should not contradict one another.
How to check your XML sitemap
Start by opening the sitemap URL directly in your browser.
Depending on your setup, it may look like:
https://example.com/wp-sitemap.xml
or:
https://example.com/sitemap_index.xml
Then check whether:
- the sitemap returns successfully;
- the expected content types are present;
- important URLs are included;
- obsolete URLs are absent;
- redirected URLs are not listed unnecessarily;
- URLs use the preferred HTTPS version;
- canonical versions are being used;
- unwanted content types are excluded.
These basic checks catch a surprising number of sitemap problems without requiring complicated tooling.
Check the sitemap before launching a WordPress site
A sitemap review is particularly important when moving a website from staging to production.
At launch, verify that:
- the production sitemap is accessible;
- URLs point to the production domain rather than staging;
- important content is included;
- temporary content is excluded;
- the site is not accidentally configured to discourage indexing;
- crawler rules do not block important sections.
This belongs alongside the other technical checks performed before search engines begin discovering the production site.
See A WordPress pre-launch SEO checklist for the complete launch review.
XML sitemap SEO checklist
Use this checklist when reviewing a WordPress sitemap:
- Confirm that the sitemap is publicly accessible.
- Include important indexable posts and pages.
- Review custom post types individually.
- Review categories, tags and custom taxonomies.
- Exclude URLs that should not appear in search.
- Avoid obsolete redirected URLs.
- Use canonical URL versions.
- Do not rely on the sitemap instead of internal links.
- Keep
lastmodvalues accurate when they are provided. - Do not rely on
priorityorchangefreqfor Google. - Add the sitemap location to
robots.txtwhen appropriate. - Submit the sitemap through relevant search engine webmaster tools.
- Review sitemap configuration when the site’s architecture changes.
Manage XML sitemaps with TheOneWP
WordPress already provides basic sitemap functionality, but more complex websites often need more control over what search engines are being asked to discover.
TheOneWP’s XML Sitemap module provides that control from inside WordPress.
It is the main TheOneWP module for this workflow and allows sitemap configuration to follow the actual content architecture of the site rather than assuming every registered content type belongs in organic search.
This becomes particularly useful when a website contains:
- multiple public post types;
- custom post types;
- custom taxonomies;
- internal utility content;
- content structures created by other plugins;
- sections with different indexing purposes.
The sitemap can then represent the content that actually matters rather than merely everything WordPress happens to expose.
The surrounding SEO workflow
XML Sitemap is the central module for sitemap management, but sitemap quality depends on several related SEO decisions.
Other TheOneWP modules can support those surrounding tasks:
- SEO Meta manages canonical URLs, robots directives and other page-level SEO metadata.
- Robots.txt manages crawler rules and can expose the sitemap location.
- Redirect Manager handles old URLs when content permanently moves or disappears.
Together, these modules cover different parts of the same URL lifecycle:
SEO Meta
→ which version of a page is canonical and indexable?
XML Sitemap
→ which current URLs should be advertised for discovery?
Robots.txt
→ which paths may compatible crawlers access?
Redirect Manager
→ what happens to obsolete or moved URLs?
The benefit is not a different SEO theory. It is having the controls available inside one modular WordPress toolkit instead of managing the same URL architecture through disconnected snippets, plugins and configuration files.
You can explore the complete toolkit on the TheOneWP features page.
Do you always need an XML sitemap?
Not necessarily.
A very small website with clear internal linking may be discovered without difficulty even without a sitemap.
Google notes that smaller sites with comprehensive internal linking may not need one.
However, XML sitemaps are inexpensive to maintain when generated automatically and provide a useful additional discovery mechanism.
For most WordPress websites, there is little operational downside to having a properly configured dynamic sitemap.
The important distinction is between having a sitemap and having a good sitemap.
A sitemap containing clean, canonical, indexable URLs supports the site’s technical structure.
A sitemap filled with redirects, duplicate URLs and content deliberately excluded from search simply publishes the underlying mess in XML format. Apparently even robots deserve cleaner paperwork.
Final thoughts: why XML sitemaps matter
An XML sitemap is one of the simplest technical SEO tools, but its purpose is frequently misunderstood.
It does not tell Google what to rank. It does not force pages into the index. It does not replace internal linking, useful content or sensible site architecture.
Its job is to help search engines discover URLs and provide a structured view of the site’s current content.
For WordPress websites, the important step is therefore not merely enabling a sitemap. It is making sure the sitemap reflects the actual indexing strategy of the website.
You can rely on WordPress core for a basic sitemap, but as the site grows, custom post types, taxonomies, canonical rules and indexing decisions can make more granular control useful.
TheOneWP’s XML Sitemap module provides that control, while SEO Meta, Robots.txt and Redirect Manager cover the related parts of the technical SEO workflow.
The objective remains simple: expose clean, canonical URLs that deserve to be discovered, keep obsolete or deliberately excluded URLs out of the sitemap and make the site’s search signals agree with one another.

