Why is the Yoast XML sitemap not loading in WordPress?

A Yoast XML sitemap can fail in several different ways. Sometimes the main sitemap index does not load. In other cases, the sitemap index works normally but an individual sitemap such as page-sitemap.xml returns an error, takes too long to respond or displays the standard WordPress critical-error page.

Those symptoms should not automatically be treated as the same problem.

If the sitemap index works but one child sitemap consistently fails, WordPress and Yoast are capable of responding to the main sitemap request. The failure may instead be happening while WordPress and Yoast are generating the content required for that particular child sitemap.

This guide explains how to separate those situations, preserve useful evidence before changing settings, safely capture the underlying WordPress or PHP error, and understand why themes, page builders, plugins, server limits and caching can sometimes become part of sitemap troubleshooting.

It also uses a resolved WordPress and Divi case to show why the component mentioned in an error log is not automatically the root cause.

Use the links below to jump to the section most relevant to your question.

• Quick checks before changing anything
• Why can the sitemap index work while page-sitemap.xml fails?
• How can you capture the real WordPress error safely?
• What does a maximum execution time error mean?
• Why can Yoast sitemap images involve a page builder?
• What happened in a real WordPress and Divi case?
• What did PHP version and execution-time testing show?
• Could caching, Cloudflare or a WAF be involved?
• A safe diagnostic sequence
• When should the problem be escalated?
• Reducing the chance of repeat sitemap problems
• Supporting references
• Related guidance on this site
• Further Guidance and Support

Before switching settings, clearing every cache or changing plugins, establish exactly which sitemap request is failing. Preserving the failing state long enough to collect evidence can make the difference between identifying the cause and simply making the symptom temporarily disappear.

1. 1. Open the main Yoast sitemap index, normally sitemap_index.xml, and confirm whether it loads.
   2. Open the individual sitemap that fails, such as page-sitemap.xml.
   3. Record the exact result: 404, blank or malformed XML, timeout, HTTP 5xx response or the WordPress critical-error page.
   4. Where useful, test the alternative Yoast sitemap route ?sitemap=1. If that works while the normal sitemap index does not, URL rewriting may require investigation.
   5. Confirm that XML sitemaps are enabled in Yoast.
   6. Note any recent WordPress, Yoast, theme, page-builder, PHP or hosting changes.
   7. If WordPress displays its critical-error page, capture the PHP error before making several unrelated changes.

Avoid repeatedly switching the Yoast sitemap feature off and on simply to see whether the sitemap returns. That may regenerate sitemap behaviour without explaining why the failure occurred.

The first question is therefore not simply:

“Does the sitemap work?”

It is:

“Which sitemap request fails, how does it fail, and what does the server record when it happens?”

The Yoast sitemap index is primarily an index of the individual XML sitemaps available for different types of content.

A child sitemap such as page-sitemap.xml has more work to do. It needs to retrieve the relevant page URLs and build the entries that will be returned to search engines.

Yoast can also include information about images associated with public posts and pages. Discovering that information can require page content to be processed through WordPress filters.

That distinction matters.

A relatively small sitemap index can therefore load normally while generating a page sitemap involves substantially more WordPress processing.

A working sitemap index does not prove that every child sitemap can be generated successfully.

This also explains why the website itself can appear to work normally while a particular sitemap request fails. Loading an ordinary website page and generating a sitemap do not necessarily require WordPress to perform the same work.

The standard WordPress critical-error screen deliberately avoids displaying detailed PHP information to website visitors.

For troubleshooting, the useful evidence is normally in the WordPress or server-side error log.

Where WordPress debug logging is temporarily required, check wp-config.php first to see whether the settings already exist. Do not create duplicate definitions.

A typical temporary logging configuration is:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WP_DEBUG_DISPLAY should remain false on a public website so that PHP errors and implementation details are not displayed to visitors.

To capture a clean failure:

1. 1. Keep a copy of an existing wp-content/debug.log if it contains information you may need.
   2. Remove or rename the old log so that the next test is easier to interpret.
   3. Request the failing sitemap once.
   4. Immediately inspect the new log.
   5. Look first for entries such as PHP Fatal error, Maximum execution time, Allowed memory size exhausted or an uncaught PHP error.
   6. Separate fatal errors from warnings and deprecation notices.

Warnings may be useful when reviewing compatibility, but their presence does not automatically mean that they caused the sitemap request to fail.

Debug logging should be disabled again when it is no longer required, and diagnostic log files should not be left publicly accessible.

PHP can place a maximum time limit on how long an individual request is permitted to run.

If WordPress continues processing beyond that limit while generating a sitemap, PHP can terminate the request.

From the browser, the result may simply appear as:

• • a page that continues loading;
  • an HTTP 500 response;
  • incomplete or blank output;
  • or the standard WordPress critical-error screen.

A log entry such as:

PHP Fatal error: Maximum execution time of 60 seconds exceeded

provides much more useful information.

It establishes that the immediate reason the request stopped was the PHP execution-time limit.

It does not, by itself, prove that the particular PHP file or function shown on the final line of the error is defective.

PHP may simply have reached the permitted time limit while that function happened to be executing.

The wider call path and repeated behaviour are therefore more useful than one isolated filename or line number

It may seem surprising to find theme or page-builder functions in an error log generated by an XML sitemap request.

One reason is that Yoast can inspect page content while discovering image information to include in its XML sitemap.

WordPress content can pass through filters as part of that process.

Where a website uses a page builder, those filters may involve code responsible for interpreting or rendering the builder’s content.

A simplified processing path can therefore look like this:

Yoast builds page-sitemap.xml

↓

Yoast examines page content for sitemap information, including images

↓

WordPress applies content filters

↓

Theme or page-builder compatibility functions become involved

↓

Additional page content or shortcode processing takes place

↓

Yoast continues building the XML sitemap

This does not mean that every WordPress site or every page builder behaves in exactly the same way.

It also does not mean that finding a page-builder function in a stack trace proves that the page builder is faulty.

It tells us that the component was part of the processing path when the failure occurred.

A resolved WordPress and Divi case provides a useful example.

The main Yoast sitemap index continued to load normally. The alternative sitemap route was also available.

However:

page-sitemap.xml

produced the WordPress critical-error screen.

The important evidence came from the PHP log.

Repeated failures recorded:

PHP Fatal error: Maximum execution time of 60 seconds exceeded

The common processing path showed Yoast generating the sitemap, Yoast examining page content for sitemap image information, WordPress applying filters, and Divi’s Yoast compatibility and shortcode processing becoming involved.

A simplified version of the observed path was:

Yoast sitemap generation

↓

Yoast sitemap image processing

↓

WordPress content filters

↓

Divi Yoast compatibility processing

↓

Divi shortcode and builder processing

↓

PHP execution-time limit reached

The repeated path was more significant than whichever Divi function happened to appear on the final fatal-error line.

The evidence therefore supported a cumulative execution-time problem during legitimate Yoast and Divi processing.

It did not establish that Divi alone was defective or that Yoast itself was necessarily faulty.

Other log entries recorded during troubleshooting, including PHP deprecation notices, were retained as compatibility information but were not the fatal condition that stopped the sitemap request.

Controlled testing is most useful when one variable is changed at a time.

In the real case, changing PHP from version 8.5 to the previous supported version, PHP 8.4, did not change the sitemap failure.

PHP 8.5 was therefore restored.

That test helped rule out a simple explanation that the failure was caused solely by the PHP version change.

The next test addressed the error that was actually terminating the request: the 60-second PHP execution-time limit.

The limit was increased in a controlled way from:

60 seconds

to:

120 seconds

The original sitemap structure was then restored and page-sitemap.xml was tested again.

The sitemap completed successfully at the higher limit.

A temporary test had also been available to reduce the number of sitemap entries, which can help establish whether cumulative processing across many pages contributes to the problem. That reduced structure was not required as the final arrangement once the original sitemap could complete successfully.

The useful conclusion is not:

“Set every WordPress website to 120 seconds.”

It is:

“Where the captured fatal error consistently shows a legitimate request reaching the execution-time limit, a bounded increase can be a useful diagnostic test.”

If a request still reaches the new limit, repeatedly increasing it is not a sensible troubleshooting strategy. The processing path should instead be isolated and reviewed.

Caching, CDN rules and web application firewalls (WAFs) can sometimes affect sitemap requests, but they should not automatically be blamed for every sitemap problem.

For example, Cloudflare does not normally cache every XML response simply because it has an .xml extension. However, a broad custom caching rule or a Cache Everything configuration can change normal behaviour.

Where a CDN or caching service is involved, useful checks include:

• • whether a broad cache rule includes sitemap paths;
  • whether sitemap XML is intentionally bypassed from page caching;
  • whether the failing response changes after a controlled cache purge;
  • whether the CDN reports the response as cached, bypassed or dynamic;
  • and whether a WAF or security rule is actually matching the sitemap request.

The important distinction is between:

a cached or blocked sitemap response

and:

a sitemap request that reaches WordPress but fails while WordPress is generating it.

If the PHP log records a fatal execution-time error during generation of page-sitemap.xml, clearing a CDN cache does not explain the underlying server-side timeout.

Similarly, unrelated Apache security events, automated probing or hosting log entries should not be treated as the sitemap cause unless their timing and behaviour actually correspond with the failing request.

Once a sitemap failure can be reproduced, make changes one at a time so that each result provides useful evidence.

A sensible sequence is:

1. 1. Confirm that Yoast XML sitemaps are enabled.
   2. Test sitemap_index.xml.
   3. Test ?sitemap=1 where useful.
   4. Test the relevant child sitemap such as page-sitemap.xml.
   5. Record the exact visible failure.
   6. Capture one clean PHP or WordPress error log from the failing request.
   7. Identify the fatal condition before concentrating on warnings.
   8. Follow the complete call path rather than assuming that the final filename is the root cause.
   9. Review custom sitemap filters or other WordPress customisations.
   10. If PHP compatibility is genuinely in question, test a supported PHP version without changing other variables at the same time.
   11. If a consistent execution-time limit is the only fatal condition, consider a bounded increase as a controlled test.
   12. If reducing sitemap entries changes the behaviour, investigate cumulative processing rather than automatically adopting the reduced size permanently.
   13. Review relevant caching or WAF rules where the evidence suggests they may be involved.
   14. Retest the original failing sitemap after each material change.
   15. Restore temporary diagnostic settings that are no longer required.

On a production website, disabling major plugins, switching themes or changing significant WordPress code simply to see what happens can create a larger problem than the sitemap failure itself.

Where testing may affect a live business website, use a staging environment or controlled maintenance period where practical.

Some sitemap problems can be resolved through ordinary WordPress administration. Others require investigation of PHP, hosting limits, plugin interaction, theme behaviour or custom code.

Further technical review is appropriate when:

• • the same sitemap repeatedly produces an HTTP 500 or WordPress critical error;
  • the sitemap index works but the same child sitemap consistently fails;
  • the PHP log contains repeated fatal errors;
  • the request repeatedly reaches the PHP execution-time or memory limit;
  • custom sitemap code or WordPress filters are involved;
  • a page builder or plugin repeatedly appears in the relevant processing path;
  • testing would require disabling important components on a live website;
  • a higher PHP limit is required simply to keep the sitemap working;
  • the behaviour changes only when the number of sitemap entries is reduced;
  • or available evidence points towards several interacting components rather than one obvious setting.

Useful information to collect before escalating includes:

• • the exact failing sitemap URL;
  • whether sitemap_index.xml works;
  • whether ?sitemap=1 works;
  • the WordPress version;
  • the Yoast version;
  • the active theme or page-builder version;
  • the PHP version;
  • the PHP max_execution_time;
  • the PHP memory limit;
  • a fresh error log from one reproduction;
  • and details of any relevant CDN or WAF rule affecting the sitemap path.

Providing that evidence is much more useful than sending only a screenshot of the generic WordPress critical-error page.

A sitemap should not require constant manual intervention.

If the same problem repeatedly returns, the underlying processing should be reviewed rather than relying on repeated cache clearing, sitemap toggling or ever-increasing PHP limits.

Useful practices include:

• • checking the sitemap after significant WordPress, Yoast, theme or page-builder changes;
  • retaining access to PHP and hosting error logs;
  • keeping a record of custom sitemap filters and WordPress customisations;
  • reviewing whether unusual sitemap processing is cumulative across many pages;
  • testing potentially disruptive changes before applying them to a live website;
  • changing one relevant variable at a time during troubleshooting;
  • keeping sitemap URLs outside inappropriate broad page-caching rules;
  • and testing the actual XML sitemap URLs after a change rather than relying only on the WordPress administration screen.

The exact behaviour of WordPress, Yoast, PHP, themes, page builders and hosting platforms can change over time.

This guide should therefore be treated as a way to understand and investigate the failure mechanism, not as a permanent checklist that assumes every future sitemap problem will have the same cause.

The following vendor documentation can be useful when checking the behaviour described in this guide.

Yoast – XML sitemaps in Yoast SEO

Use the current Yoast documentation covering XML sitemap behaviour.

Yoast – Images in XML sitemaps

Use the current Yoast documentation covering how images can be included in XML sitemaps.

Yoast Developer – XML sitemap API

Use where sitemap filters or custom sitemap behaviour require technical review.

WordPress – Debugging in WordPress

Use the official WordPress documentation when configuring WordPress debug logging.

WordPress – wp-config.php guidance

Use the official WordPress documentation before changing wp-config.php.

Cloudflare – Cache behaviour and Cache Rules

Use the current Cloudflare documentation when checking whether custom caching behaviour may affect sitemap requests.

Sitemap generation is only one part of the wider WordPress and Yoast publishing process. These related guides cover different problems that can otherwise appear similar.

What Do the Yoast SEO Settings Mean in WordPress?

Explains the main Yoast fields, assessments and technical controls and how they relate to the wider WordPress publishing process.

Why a page is missing from the Yoast sitemap (and the easy thing everyone misses)

Covers the different situation where the XML sitemap itself works but a particular page does not appear in it, including problems caused by canonical URL configuration.