If a WordPress page is missing from your sitemap, first check whether you are looking for the right public URL in the right sitemap file. A missing entry can be intentional. It can also expose a mismatch between the saved page, its search settings and the output visitors receive.
Do not start by enabling every content type, switching SEO plugins or asking Google to index the page repeatedly. Those actions can expose content you meant to keep out of search while leaving the real omission unresolved.
This guide is for an owner who has a specific business page that should be public. It separates an absent sitemap entry from a page that Google has not indexed, then gives you a safe order for checking the cause.
Missing from the sitemap is not the same as missing from Google
A sitemap tells a search engine about URLs you want it to discover. It is not a list of guaranteed search results. A page can be discovered through an internal link without appearing in a sitemap, and a listed page may still not be indexed. Google’s sitemap guidance makes that distinction clear.
Start with one question: can you find the exact intended page address in the actual XML file? If yes, the next job is to inspect the page’s crawl and indexing status. If no, investigate why WordPress or the SEO plugin did not include it. These are different jobs with different evidence.
Write down the page URL, its WordPress page ID, when it was published and why it should appear in search. Keep the current SEO settings before editing them. For a member page, checkout step, private document or staging copy, the correct outcome may be to leave it excluded.
Open the correct child sitemap and compare the exact URL
On a Yoast site, start from the sitemap link in Yoast rather than a filename copied from another website. Its sitemap index normally leads to separate files for posts and pages. Yoast documents its sitemap structure and automatic updates.
Open the child file that matches your content, following any additional child files listed in the index. Searching only the index for your page address can make a healthy setup look broken: the index lists sitemap files, not every page inside them.
Compare the full address, including the hostname, path and final redirected destination. A menu label, editor preview link or old slug is not necessarily the public URL. If your original address redirects to another page, inspect the destination before deciding the old address is missing.
During our 7 October 2026 check, Webless’s public sitemap index pointed to separate post and page sitemaps. That is an observation of this site’s output, not proof that every WordPress installation uses the same files. An image sitemap answers a separate image-discovery question.
Use the omission matrix before changing settings
Check saved state first, then served output, then sitemap freshness. This order helps distinguish a deliberate exclusion from an output defect without changing unrelated pages.
| Evidence you find | What it suggests | Safe next action |
|---|---|---|
| The entry exists in another child sitemap or at the final URL | You searched a different file or address | Record the correct entry. Do not create a replacement page or duplicate sitemap |
| The saved document is a draft, private or password protected | The document is not the public page you expected | Confirm the intended audience with its owner before changing visibility |
| Yoast excludes the page or its content type from search results | The omission may follow an indexing decision | Review that decision. A content-type change affects more than this page |
| The page has an intentional canonical pointing to another URL | Another address is the preferred version | Check the destination and its sitemap entry before removing the canonical |
| The public URL redirects, fails or shows different content | The served page does not match the expected document | Capture the response and fix the owning route or output layer, not the sitemap text |
| The page should be included, but a fresh sitemap still omits it | Generation, filtering or caching needs investigation | Preserve the page settings and both responses, then ask the maintainer to trace the mismatch |
Yoast’s individual-page omission guidance identifies search exclusions and differing canonicals among possible causes. A rule can be functioning correctly even when it conflicts with what you now want. Establish the intent before treating that rule as a bug.
Do not force a private page into a sitemap to make a checklist pass. Likewise, do not remove a canonical simply because you want both versions listed. Google’s canonical guidance recommends consistent signals for the preferred URL.
Compare saved Yoast settings with the public response
Open the affected page’s native Yoast advanced controls. Review whether search engines may show it and whether a different canonical has been entered. Also establish whether a broader content-type setting owns the exclusion. Record the exact values; do not change a global switch just to test one page.
Next, open the clean public URL in a signed-out view. Check its final address, whether it loads successfully, and the page source for its robots and canonical output where present. A developer can also inspect HTTP response headers, which can carry an indexing rule that is not visible in the page editor.
Google’s noindex documentation explains the page-level rule. A robots.txt crawl block is not the same thing. Neither rule is a suitable access-control system for confidential content. Our staging-site protection guide covers that different problem.
If the saved settings and public response disagree, stop changing keywords and descriptions. Trace which component owns the output. Keep the SEO plugin, server rules and cache layers as separate possibilities until evidence identifies the cause.
Treat stale sitemap output as a delivery problem
Yoast generates sitemap output automatically; you do not normally type new page URLs into the XML. Its stale sitemap documentation describes caching as one possible reason changes do not appear.
Ask the maintainer to compare a fresh origin response with the public sitemap and identify the stale layer. Record the time and the exact missing URL. A cache-busted response can help compare output, but it does not prove that every cache was bypassed.
Use the site’s documented cache refresh process after a justified correction. Do not disable protection, purge repeatedly without a comparison, toggle sitemap generation as a ritual or install a second SEO plugin. If the XML returns an error or HTML instead, preserve that response before investigating the endpoint.
The same saved-versus-served distinction applies to WordPress changes that visitors cannot see. A fresh editor view is not proof of fresh public delivery.
Decide what is complete before requesting indexing
Use the following acceptance checks to keep discovery repair separate from Google’s later indexing decision. Repair only the confirmed mismatch, then compare the result with the before state.
| Checkpoint | Evidence to keep | Stop condition |
|---|---|---|
| Public intent | The owner confirms this exact page belongs in public search | The proposed fix exposes a private, member-only or staging document |
| Page response | The intended URL loads correctly and its search signals match that intent | The clean URL redirects unexpectedly, fails or still carries an unwanted exclusion |
| Sitemap output | The correct fresh child XML contains the intended canonical address | Only the editor or a different cached response looks correct |
| Change boundary | Unrelated pages, canonicals and exclusions retain their intended state | A one-page repair requires unreviewed site-wide visibility changes |
| Google inspection | The live test can access the eligible page; the request result is recorded once | You are submitting an unchanged or deliberately excluded URL to create activity |
After the public checks pass, use Search Console’s URL Inspection tool to compare the indexed record with the live page. Request indexing for an eligible new or materially corrected page after a successful live test. An accepted request is not confirmation that indexing has finished.
If the entry is present but Google has not indexed the page, investigate the reported reason, internal links, duplication and usefulness. Do not keep rebuilding a healthy sitemap. Review that page alongside the wider monthly SEO maintenance routine without publishing a competing copy.
When a missing sitemap page needs technical help
A wrong child file needs no development job. An intentional exclusion needs an owner decision. Technical help becomes appropriate when a public page’s saved state, served response and generated sitemap disagree, or when resolving it could change other pages.
Send the public page URL, relevant child sitemap address, publication time, observed response and the intended search status. Keep credentials, customer records and private screenshots out of a general enquiry. A scoped investigation should identify the owning setting or component, preserve the before state and verify the public result.