Fixed WordPress fatal error: from sitemap error to return to normal
In the process of using WordPress, we will inevitably encounter various errors. One of the most troublesome ones is the seemingly insolvent red screen prompt ‘this site encountered a fatal error’. Although these errors are terrible, as long as they have the correct troubleshooting ideas and tools, most of the problems are subject to rules to follow.
As a website administrator, at a sudden moment, you may open the background and want to post an article, but the result is ‘this site encountered a fatal error’ or a white screen. What is even more confusing is that the mistakes are not fully appearing – for example, they are all sitemaps (sitemap), Chinese article maps cannot be opened, but English ones can be accessed normally. If you have encountered a similar problem, don’t panic, this is a typical scenario in which this article will take you to analyze and solve it.
From the red screen error of the site map, to the memory bottleneck, to the final successful repair and recovery of the Google index, this experience may provide you with a complete idea and solution.
1. Phenomenon: The same sitemap, but the performance is completely different
One day, when I was checking the Google Search Console (Google Webmaster Tools) of the website, I found that the index status has always been 0, and I received an error that the sitemap cannot be crawled (as shown in Figure 1).
So I tried to directly access the URLs of these sitemaps and found a strange phenomenon:
– English site map: `https://www.你的域名.com/en/wp-sitemap-posts-post-1.xml`→ Access normal
– Chinese site map: `https://www.你的域名.com/wp-sitemap-posts-post-1.xml`→ Display ‘fatal error’ as shown in Figure 2
With the same program and the same website structure, why can the English version be displayed normally, but the Chinese version with a large number of articles has crashed?
This clue immediately locked me into the preliminary investigation direction: the problem is likely to be related to the server resources.
2. In-depth analysis: who is the real ‘culprit’?
With doubts, I turned on the debug mode of WordPress, which can be achieved by modifying the `wp-config.php` file:
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
After completing the settings and visiting the error page again, I saw the specific php error in the `debug.log` file generated in the `/wp-content/` directory, which pointed to the core of the problem. If you do not have permission or are not familiar with file operations, you can also quickly check by installing plugins such as “Query Monitor” or “WP-ServerInfo”. In order to facilitate and quickly locate, I decided to start with the system state itself, and use a “System Info” plugin to obtain a comprehensive environmental report.
This is a WordPress plugin – System Info
### Begin System Info (Generated 2026-05-17 11:15:28) ###
------------ SITE INFO
Site URL: https://www.shuijingwanwq.com
Home URL: https://www.shuijingwanwq.com
Multisite: No
------------ USER BROWSER
Platform: Windows
Browser Name: Chrome
Browser Version: 148.0.0.0
------------ WORDPRESS CONFIG
WP Version: 6.9.4
Language: zh_CN
Permalink Structure: /%year%/%monthnum%/%day%/%post_id%/
Active Theme: Hueman 3.7.27
Show On Front: posts
ABSPATH: /data/wwwroot/www.shuijingwanwq.com/
WP_DEBUG: Disabled
WP Memory Limit: 40MB
------------ NIMBLE CONFIGURATION
Version: 3.3.8
Upgraded From: 3.3.7
Started With: 1.8.3
------------ WP ACTIVE PLUGINS
Akismet Anti-spam: Spam Protection: 5.7
AutoPoly - AI Translation For Polylang: 1.4.11
Contact Form 7: 6.1.6
Disable Google Fonts: 2.0
Gutenberg: 23.1.1
Hueman Addons: 2.3.3
Light - Responsive LightBox: 1.1
Nimble Page Builder: 3.3.8
Polylang: 3.8.3
Post Views Counter: 1.7.10
PublishPress Series Free: 3.1.2
Regenerate Thumbnails: 3.1.6
SyntaxHighlighter Evolved: 3.7.2
WP-PageNavi: 2.94.5
WP Reading Progress: 1.7.0
------------ WP INACTIVE PLUGINS
BackUpWordPress: 3.14
Classic Editor: 1.6.7
Focus Mode - Reading Experience Optimizer: 1.0
Kill 429: 1.1.0
SyntaxHighlighter Evolved: Go Brush: 1.0.0
WP-Cumulus: 1.23
------------ WEBSERVER CONFIG
PHP Version: 8.1.19
MySQL Version: 5.7.32
Webserver Info: nginx/1.24.0
Write/Read permissions: OK
------------ PHP CONFIG
Memory Limit: 256M
Upload Max Size: 50M
Post Max Size: 100M
Upload Max Filesize: 50M
Time Limit: 600
Max Input Vars: 1000
Display Errors: N/A
PHP Arg Separator: &
PHP Allow URL File Open: 1
### End System Info ###
A key message in this report immediately caught my attention:
– WP Memory Limit (WordPress memory limit): 40MB
– PHP Memory Limit (PHP memory limit): 256MB
This data means that although the server’s PHP process has 256MB of memory available, the WordPress platform itself is only allowed to use the poor 40MB.
When the system needs to generate a website map containing a large number of Chinese articles, the 40MB of memory is immediately exhausted, triggering a ‘fatal error’. The English site map can be opened normally, which further confirms this conjecture – the reason why it is normal is probably because the number of English articles is far less than Chinese, and the required memory is within a 40MB limit.
It’s like a faucet (PHP) that can flow out 256 liters of water, but your WordPress can only hold 40 liters at a time. When the content you want to process (the amount of data in Chinese articles) far exceeds 40 liters, the program will crash due to ‘explosion’.
📚 Technical Science: Unraveling the Mystery of Memory Configuration
This link is very valuable because it can help you clarify two key memory settings in WordPress, which is extremely important when troubleshooting similar problems:
– PHP `memory_limit` (256M): This is the global rigid upper limit set in the server `php.ini` file, which is a ‘ceiling’ that all php scripts can use. Modifying it usually requires contacting the host or operating through the server panel.
– `wp_memory_limit` (40M): This is the memory limit that WordPress sets for the front end (the page that the visitor sees). The default setting is 40MB, which can be adjusted through the `wp-config.php` file.
– `wp_max_memory_limit` (256M): This is the memory limit set by WordPress for the background (the dashboard operated by the administrator) and some intensive tasks (such as generating sitemaps, importing and exporting data, running backups, etc.) memory limits.
Simply put, `wp_memory_limit` cannot exceed php `memory_limit`, and `wp_max_memory_limit` can usually be set higher than php `memory_limit`. Many users still encounter problems in the background after setting `wp_memory_limit`, probably forgot to adjust `wp_max_memory_limit` at the same time.
3. Solution: Relieve the confinement in wp-config.php
The root of the problem has been found, and the repair method is also very simple and straightforward. We need to actively increase the memory limit of WordPress in the root directory configuration file `wp-config.php` of WordPress, so that the platform can make full use of the resources provided by the server.
You can use FTP or the server file manager to find the `wp-config.php` file in the root directory for editing. Please note that it is best to back up the file before editing, so as to avoid misoperation and cause the website to be inaccessible.
1. Find this line comment in the file and place the newly added code above it:
/*好了!请不要再继续编辑。请保存本文件。使用愉快! */
2. On top of that line, add the following code (as shown in Figure 3):
/* 增加 WordPress 内存限制 */
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');
3. Save the file and upload the overwrite.
I use the `vi` editor to connect to the server via ssh. During the editing process, I encountered an unexpected network disconnection, causing the vim to prompt that there is an old swap file (`swap file`). In this case, you don’t have to panic, just press the `Q` key on the prompt interface to exit, and then execute the `rm -f.wp-config.php.swp` command to delete the residual file, and you can edit it normally.
After completing the modification, visit the original Chinese sitemap again, and find that the XML structure can be displayed normally. This verifies that the modification has taken effect. as shown in Figure 4
In addition, you can also set `max_execution_time` to 300 in the server’s php.ini file to avoid interrupting some large-scale data processing scripts due to timeouts.
Four, follow-up observation: Google index and site map recovery
After fixing the site map, it does not mean that the problem is completely solved. You also need to clear the legacy negative effects, making sure that Google can correctly identify and use this fixed sitemap.
Clear sitemap cache
If you use any caching plugin or CDN service (such as Cloudflare), be sure to add the sitemap file (usually contains `wp-sitemap.xml` and its submaps) to the exclusion list in the plugin settings to prevent them from being cached.
Resubmit in Google Search Console
Log in to your Google Search Console. If you are like me, there are both in the resource list `http://`和`https://`版本的网站，请务必确保在正确的`https://`资源下进行操作。
1. Go to the Index → Sitemap page.
2. Find the `/wp-sitemap.xml` with the status ‘Unable to Crawl’, and click the menu next to it to delete it.
3. Click ‘Enter New Sitemap’ and resubmit: `wp-sitemap.xml`.
After submission, the site map status may take several hours to go from ‘pending’ to ‘success’. Just wait patiently.
5. Summary
The experience of solving the problem has not only restored my website to normal operation, but more importantly, I learned how to systematically think and locate the error. When encountering seemingly complex ‘fatal errors’, the key is to master the correct path of investigation and make good use of tools:
1. Identification mode: The performance of the problem often provides key clues. Why is it normal and one error in the same situation? This usually points to differences in resource consumption.
2. Make good use of tools: Tools like the ‘System Info’ plugin can help you quickly through the underlying environment of the website, and it is a ‘perspective mirror’ for diagnosing problems.
3. Understand the concept: The real understanding of the difference between PHP memory limit and WordPress memory limit is the cornerstone of solving such problems.
4. System execution: directly increase the WordPress memory limit by modifying `wp-config.php`, which is the most core and most effective solution.
5. Active communication: After repairing, update the status in the Google Search Console in time, and resubmit the site map, so that the search engine can see your results.
Although WordPress is powerful, the complex logic behind it does sometimes bring challenges. I hope this article can be a reliable reference for you to deal with similar problems in the future. If you really encounter any problems in the process of modifying the file, you can ask me again at any time~
