Why a WordPress Page Is Missing From Your XML Sitemap

A page missing from the sitemap is usually excluded on purpose by a rule, listed in a child file you did not open, listed under a slightly different address, or hidden behind a cached copy. Check those four in order. First, though, confirm that the page belongs in the sitemap at all: a sitemap should list the pages you want in search results, so a noindexed, redirected, or duplicate page is supposed to be absent.

Google’s sitemap guidelines, checked September 27, 2026, say to include the URLs you want to see in Google’s results and to use fully qualified absolute URLs. Its canonicalization guidance, checked the same day, says every URL in a sitemap is suggested as a canonical. A sitemap is a list of preferred addresses, not an inventory of every URL the site can serve.

Confirm the page should be listed

Check the page itself before searching the sitemap. Run these signed out, against the page’s preferred address (the example URL is illustrative):

PAGE="https://garden.example/garden-design/"

curl -sI "$PAGE" | grep -iE '^HTTP|^location|x-robots-tag'
curl -s "$PAGE" | grep -io '<meta[^>]*name=["'\'']robots["'\''][^>]*>'
curl -s "$PAGE" | grep -io '<link[^>]*rel=["'\'']canonical["'\''][^>]*>'

Then read the results against this table.

In WordPress, also check the editor. The post must be Published, not scheduled, draft, or private. Check whether it has a password: WP Visibility leaves password-protected posts out of its sitemap, and other generators document their own rule.

If the page should not be listed, you have your answer. If you want it indexed after all, fix the directive or the redirect at its source; Keep a Page Out of Search shows where page-level indexing settings live in WP Visibility.

Find which generator owns the sitemap

WordPress core has served its own sitemap index at /wp-sitemap.xml since version 5.5, according to the WordPress 5.5 sitemaps announcement, checked September 27, 2026. The same post says core disables it when the site is set to discourage search engines. SEO plugins often replace it with their own. A site can end up with more than one sitemap, and the one submitted in Search Console may not be the one you are reading.

SITE="https://garden.example"
curl -s "$SITE/robots.txt" | grep -i '^sitemap:'
curl -sI "$SITE/sitemap.xml" | head -n 1
curl -sI "$SITE/sitemap_index.xml" | head -n 1
curl -sI "$SITE/wp-sitemap.xml" | head -n 1

Compare the addresses that respond with the ones listed in Search Console’s Sitemaps report. If Search Console holds an old address from a previous plugin, it may still be reading a file that no longer changes, or getting an error. Settle on one generator, submit its index, and remove the stale submission.

With WP Visibility’s Sitemaps module on, the index is /sitemap.xml with child files for each included post type and taxonomy that has entries, and WordPress’s own /wp-sitemap.xml is turned off while the module is on. Submit Your Sitemap lists the file names and the submission steps.

Check the generator’s exclusion rules

Every generator applies rules. Read the documentation for the one you use and compare the rules with the page. For WP Visibility 2.10.3, the documented rules are:

• Included: published posts, pages, and public custom post type entries, plus term archives that contain at least one post.
• Excluded: attachments, password-protected posts, anything set to Noindex, and any post type ticked under Exclude post types from the sitemap or under Indexing, Noindex these post types. A ticked type stays out even when one of its entries is set to Index in the editor.
• Taxonomies: a taxonomy ticked under Noindex these taxonomy archives has no sitemap file.
• Per page: there is no setting that hides one page from the sitemap while keeping it indexable.

Two causes are easy to miss. A custom post type registered as not publicly viewable has no public pages, so a generator has nothing to list for it; check how the type was registered. And a whole post type can be excluded in a setting someone changed months ago, so look at the settings screen, not just the page.

Search every child file for the exact URL

A sitemap index points to child files, and each child holds a limited number of URLs before the list continues in the next file. Google’s guidelines set a limit of 50,000 URLs or 50 MB uncompressed per file. Generators may use a smaller page size. WordPress core’s sitemap holds up to 2,000 entries per file by default, according to the 5.5 announcement cited above, and WP Visibility lists 1,000 URLs per file by default and continues in -2.xml and so on. The page you want may sit in the second file of its post type.

This loop fetches the index, then searches every child for the exact address:

SITE="https://garden.example"
PAGE="https://garden.example/garden-design/"

curl -s "$SITE/sitemap.xml" \
  | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' > children.txt

while read -r child; do
  curl -s "$child" | grep -qF "<loc>$PAGE</loc>" && echo "Found in $child"
done < children.txt

If nothing prints, search for the slug alone to catch near misses:

while read -r child; do
  curl -s "$child" | grep -o '<loc>[^<]*garden-design[^<]*</loc>'
done < children.txt

A near miss is a different URL. http against https, www against no www, a missing trailing slash, or an old slug means the sitemap and the site disagree about the preferred address. Fix the site’s address settings or the permalink, not the sitemap. If the sitemap still lists an old slug, the file you fetched may be a cached copy; see the next section.

Rule out a cached sitemap

Some sitemap generators cache their output, and a page cache or CDN may hold another copy. If the page was published or changed recently, the file you fetched may predate it.

WP Visibility caches sitemap files for up to a week. Saving or deleting a post, or editing a term, clears that cache so the next request rebuilds the file. Changing a setting, such as the excluded post types, does not clear it, and neither does a change that reaches the database another way, such as an import or a direct database edit. In those cases, run:

wp visibility flush

It marks the cached files stale; they regenerate on the next request. A page cache or CDN in front of the site keeps its own copy under its own rules. Check the response headers of the child file for signs of a cached copy:

curl -sI "https://garden.example/sitemap-posts-page-1.xml" | grep -iE '^age:|cache'

A large Age value or a cache HIT means an intermediate cache answered. Purge that file in the cache that served it, then fetch again. SEO changes not showing on WordPress walks through identifying the layer.

Compare the sitemap and the page after the fix

Once the page appears in the correct child file, check that the entry and the page agree:

• The <loc> is character for character the canonical the page prints.
• The page returns 200 and carries no noindex in its HTML or headers.
• The <lastmod>, if present, reflects the page’s last real change. Google’s guidelines say it uses lastmod when it is consistently and verifiably accurate.

Then leave Search Console to read the file on its own schedule, or resubmit the index in the Sitemaps report. Listing a page does not make Google index it. Google’s sitemaps overview, checked September 27, 2026, says a sitemap helps discovery but does not guarantee every listed item will be crawled and indexed. The Page indexing report can be filtered to All submitted pages to compare what you listed with what Google indexed, as described in Google’s Page indexing report help, checked September 27, 2026.

If the sitemap itself shows an error in Search Console rather than a missing entry, the problem is fetching or parsing the file. Fix a WordPress sitemap that Google cannot fetch or parse covers that.