WordPress sitemap missing or invalid: repair the file and its failing URLs

Distinguish three failures before regenerating the sitemap

Your WordPress sitemap returns an error, is not recognized by Search Console, or contains missing pages. These situations require different corrections. A file that cannot be fetched, malformed XML, and failing content URLs are not all repaired by clicking the same regeneration button.

The goal is an accessible, readable file produced by the correct system, listing consistent public addresses. Successful reading does not prove every page will be indexed. A sitemap helps discover URLs; it replaces neither their content, permissions, nor the search engine’s decision.

Record the exact sitemap address, received message, time, and latest site change. Keep an affected child sitemap and a few content URLs as reference cases. Before a configuration change, preserve initial values and an appropriate backup. For component testing, use a copy with outbound messages, payments, and synchronization disabled.

Identify the generator and its actual address

WordPress has native generation usually available at wp-sitemap.xml under the installation’s public address. An SEO manager may provide another address and replace that mechanism. Find the actually active system before adding a plugin: two generators do not fix a routing defect and complicate tracking submitted files.

If Yoast SEO already manages the site, open the address provided by its XML feature instead of guessing a filename. Also record Sitemap references in robots.txt and submissions already recorded in Search Console. They may retain an old address after migration.

On WordPress.com, the service provides a sitemap at sitemap.xml. The documented procedure goes through Jetpack, Traffic, or Jetpack, Settings, Traffic tab, Sitemaps section. If the feature is missing although the site should be public, check Generate XML Sitemaps and view the suggested address. Keep the initial state to undo only that setting. A self-hosted installation with another generator must not receive this procedure as if it were a universal native menu.

Check the index and child sitemaps separately

A sitemap index lists other XML files. It does not necessarily list pages directly. Open the index logged out, then follow a posts or pages child sitemap. An accessible index may point to a failing child file; conversely, the old index submitted to Google may be wrong while the current generator works.

In each reference child sitemap, choose a content URL and open it. Record the three responses separately: index, child sitemap, and page. This locates the defect before settings are changed. Do not interpret a list of child files as proof that individual pages are absent from the sitemap.

Raw XML presentation is not necessarily a failure. A browser may show a tag tree or report no styling. Look primarily for a syntax error, HTML instead of the file, or a protection response. If the display looks empty, inspect the response or source before deleting files: the presentation stylesheet may have a problem separate from the data.

Read status and headers with a bounded GET

This optional check requires a terminal and the exact public address. The command below receives headers without displaying the sitemap body. It performs GET, supplies no credentials, and does not automatically follow redirects. Replace the fictional domain and path with the file actually used.

On Linux, use the adapted command. On Windows, use curl.exe and replace /dev/null with NUL. Keep -q first to avoid unexpected personal configuration. Timeouts bound client waiting without promising to stop work already started on the server.

A 200 containing a login page is still the wrong response for this file: also confirm the body in the browser. A 404 calls for checking the address and generator. A 403, challenge, or server error leads to the relevant layer’s logs. For Yoast sitemaps, noindex on the XML itself is intentional in the code; do not confuse it with noindex on listed pages.

Read the HTTP status itself: without a specific option, curl may finish without a transfer error even after a 403 response. Completion therefore certifies neither a 200 nor usable XML.

curl -q --silent --show-error --connect-timeout 5 --max-time 15 --dump-header - --output /dev/null 'https://exemple.invalid/wp-sitemap.xml'

Check the native system without making a private site public

If WordPress core is the intended generator, activation depends in particular on the blog_public visibility setting and may be altered by code. An intentionally nonpublic site may therefore not provide the expected sitemap. Check Settings, Reading, but do not remove staging exclusion merely to obtain XML.

If the site is intended for the public and the native setting remained incorrect, note its initial value, clear Discourage search engines from indexing this site, then click Save Changes and reopen the sitemap. If it remains absent, find the component disabling or replacing native generation. Forcing the activation filter to true does not correct that other system’s role and may create conflicting ownership.

Native rendering also requires SimpleXML, a PHP extension. If WordPress explicitly reports its absence, have hosting enable it for the PHP serving the domain. Terminal PHP may differ. A WordPress sitemap plugin does not install that missing PHP capability. After intervention, check the index and a child sitemap; if a setting test is abandoned, restore only its initial value.

Restore a sitemap route when evidence points to rewriting

This approach is appropriate if the generator is active and the 404 seems routing-related, particularly after an installation change. For the native system, compare /wp-sitemap.xml with /?sitemap=index, for example, if the public site is at the root. For a public site in a subdirectory, retain that subdirectory in both addresses. If one responds and the other fails, this suggests rewriting; it does not justify changing every site permalink. With plain permalinks, an address containing ?sitemap=index may be normal: use the address actually advertised by this generator before calling the readable route broken.

Before opening settings, record the current structure and keep a private copy of the relevant .htaccess if Apache uses it, with a restoration method. Open Settings, Permalinks once: in current core, opening this screen already regenerates rules. Change neither structure nor bases, and do not repeatedly save hoping for an additional effect.

Then revisit the same sitemap addresses and two ordinary pages. If the defect persists, examine server configuration appropriate to the generator. On Nginx, changing .htaccess does not repair its rules. Avoid generic configuration blocks that would overwrite other paths. If a file changed during this intervention causes regression, restore it from the initial copy.

Restore the XML feature in an existing Yoast installation

This approach is suitable if Yoast SEO is the chosen generator and already installed. As of November 3, 2026, the directory version is 28.8 by Yoast, requiring at least WordPress 7.0 and PHP 7.4, with declared testing up to WordPress 7.1.4. The XML feature is free; no Premium purchase is needed to enable it.

The expected result is access to its index and child sitemaps with the intended content groups. Keep the setting’s state before changing it and do not activate another generator in parallel. If abandoning this test, restore only the initial state and check which address remains in service.

1. In the dashboard, open Yoast SEO, Settings, then Site features.
2. Under Technical SEO, find XML sitemaps and enable it if this is the intended generation.
3. Wait for save confirmation or save if the interface requests it, then use View the XML sitemap.
4. Open a relevant child sitemap and a page URL it contains.
5. If a child sitemap remains at 404, also check that corresponding published content exists before attributing the entire failure to the server.

Correct stray output before the XML declaration

An error saying the XML declaration is not at the document’s beginning may come from whitespace, a PHP message, or other output added by a component. Open the response source and inspect what precedes the declaration. Record the error and reported line; do not publish a warning containing private paths.

On a copy reproducing the defect, begin with the recently changed component or the one named by the message. In Plugins, Installed Plugins, deactivate only that component, reread the same sitemap, then reactivate it to compare. Preserve configuration and dependencies; do not delete it. If the theme is responsible, have its output and custom files checked.

The fix must remove stray output at its source while preserving the initial file. Hiding a warning does not necessarily fix the error causing it. Do not automatically clean every PHP file to remove supposedly faulty characters. After fixing the copy, check complete XML and component functions, then prepare a limited intervention. Rollback restores only the modified file or setting.

Distinguish XML presentation from validity

An XSL stylesheet presents XML readably in the browser. If it fails, a page may appear empty or poorly presented while data remains available. Check the source response and exact error before treating this as a missing sitemap. A cosmetic change does not fix an incorrectly closed tag.

For an XML sitemap, the protocol defines structure and UTF-8 encoding. A page file contains elements including urlset, url, and loc; a sitemap index has another structure. The generator must correctly escape addresses and reserved characters. Do not manually replace every & in dynamic output: correct the component producing values.

In a page sitemap, optional lastmod describes the actual modification of the listed page, not every XML read. In an index, lastmod instead describes the last modification of the referenced sitemap file. Do not correct these levels as if they represented the same date. Keep the validation message for a custom generator’s maintainer. The goal is output that remains valid after future content additions, not a one-time corrected file overwritten at its next generation.

Correct the source of listed URLs that fail

Take a few reported failing URLs and compare expected content with actual responses. A deleted address, an old redirecting variant, and a still-useful but broken page call for different decisions. Note final status, redirect presence, and domain before changing anything.

If a useful page returns an error, first restore the page or its routing; removing it from the sitemap does not repair access. If it was genuinely replaced, align links and generator with the chosen final address. If it no longer needs to exist, retain the intended deletion handling instead of creating empty content merely to obtain a 200.

After migration, staging addresses or an old protocol may reveal inconsistent configuration. Check Settings, General and SEO-manager choices, preparing access recovery before any address correction. Do not run a global SQL replacement on serialized data. Correct dynamic output at its source; manually editing generated XML leaves the cause intact.

Reexamine exclusions and missing pages

A page absent from the sitemap is not necessarily lost. It may be private, unpublished, redirected, or intentionally excluded by the generator. Check its status and editorial intent before changing visibility. A customer area or staging content must not be made public to complete a list.

In an existing Yoast installation, search-appearance choices also affect sitemap selection. For a public page excluded by mistake, open its Yoast SEO box, Advanced, then Allow search engines to show this content in search results. Select Yes if exclusion was unintended, save the page, then check its response and sitemap. For an entire type, examine the exact type in Yoast SEO, Settings, Content types, with collective scope clearly approved.

If exclusion is intentional, retain it. If the canonical address points to another page, check that choice instead of forcing both variants into the file. Keep initial values to undo the test. Removing a URL from the sitemap does not guarantee removal from results: page directives and access controls address other needs.

Check pagination, volume, and cache

An index may distribute pages across multiple child sitemaps. The protocol limits one sitemap file to 50,000 URLs and 50 MB uncompressed; generators may choose smaller batches. WordPress core defaults to 2,000 URLs per file, with a filterable value. Do not conclude that pages are missing after reading only the first batch.

For WordPress.com’s sitemap, documentation consulted in November 2026 states a limit of 1,000 recently updated posts. This service-specific limit does not replace the protocol limit or describe every installable SEO generator. If an old post is missing, first check which system produces the file; absence proves neither content deletion nor noindex.

If a large child file exceeds available resources, record which one fails and its response time. Have its partitioning and generator query examined on a copy. Do not raise every PHP limit without understanding the cause, or combine every batch into one file to simplify display.

A cache may retain an old index or child sitemap after correction. Invalidate only affected responses through the existing system’s procedure, then check their rebuilt contents. If removed URLs return, find the component or synchronization reintroducing them. The index and child files must remain mutually consistent, including after normal publication, editing, and deletion.

Read the correct error level in Search Console

In the property matching the final domain, open Sitemaps and select the affected submission. Record its status and last-read date. Couldn’t fetch sitemap concerns access; parsing errors concern a received file that could not be processed correctly. An error on a listed page does not necessarily mean the whole sitemap is unreadable.

After fixing it, first verify the public response. With the required owner permissions, resubmit the valid address through Add a new sitemap, then Submit, when the previous submission failed or the change warrants it. Do not submit a private preview URL or old domain to try to dismiss the error.

A Success status confirms Google fetched and read the file. It does not certify indexing of listed URLs. If an old address was replaced, document the current submission; deleting the old report entry does not make Google forget already-discovered pages. Then inspect a few important URLs to distinguish their state from the XML file’s state.

Validate the repair and keep one sitemap owner

The repair is consistent when the index and reference child sitemaps respond correctly, XML no longer contains stray output, and chosen pages are accessible at their final addresses. Also check an intentional exclusion and recently modified content. Keep before-and-after observations, identifying the generator and exact setting touched.

Remove only unnecessary temporary adjustments and restore components used for comparison. Keep still-justified exclusions and staging protections. After the next planned publication, check that output updates without manual intervention; a frozen XML copy must not become the permanent workaround for broken generation.

To continue with a maintainer, provide the index, faulty child sitemap, a few content URLs, statuses, XML message, versions, and failure time. Mask private paths and sensitive information. Specify whether the site is self-hosted, on WordPress.com, or multisite. This record helps correct access, generation, or data in the right place without promising that successful reading alone will obtain rankings.

Locally check a small XML sitemap’s structure

Download your small public sitemap into a working directory as sitemap.xml. With Python 3, this snippet checks XML reading and distinguishes an index from a page list. Use it only on your trusted file; it follows no links and requires no WordPress access.

A ParseError exception indicates malformed XML; examine its line without arbitrarily modifying the response. Zero empty loc entries certifies neither protocol limits, final addresses, nor page accessibility. Still open a child sitemap and reference page as described in the guide. The namespace is an exact identifier: do not replace its http with https to match the site domain. After checking, delete local copies if no longer needed.

from pathlib import Path
import xml.etree.ElementTree as ET

fichier = Path('sitemap.xml')
if fichier.stat().st_size > 20 * 1024 * 1024:
    raise SystemExit('Choisissez un sous-sitemap de moins de 20 Mio pour cet exercice.')
racine = ET.parse(fichier).getroot()
ns = '{http://www.sitemaps.org/schemas/sitemap/0.9}'
types = {ns + 'urlset': 'url', ns + 'sitemapindex': 'sitemap'}
if racine.tag not in types:
    raise SystemExit('Racine ou namespace inattendu pour cet exercice XML.')
entrees = racine.findall(ns + types[racine.tag])
manquants = sum(not (e.findtext(ns + 'loc') or '').strip() for e in entrees)
print('Type :', types[racine.tag], 'Entrées :', len(entrees), 'loc vides :', manquants)

Related comparisons