"The site is experiencing technical difficulties" is the page WordPress shows when PHP hits a fatal error, and on your own site the fix is to find the plugin or theme that crashed and switch it off. What most guides skip is that core printed this exact sentence only in WordPress 5.2: from 5.3 onwards it says "There has been a critical error on your website", and today "on this website".
So the wording is evidence.
If you see the old sentence, either the site is still on 5.2, something on the site has replaced the error message, or you are looking at a page that is not WordPress at all. Each of those points somewhere different, and working out which one you have takes about two minutes.
Is it your site, and is it WordPress?
Start here, because a lot of people who search this sentence are visitors, not site owners. The phrase is plain English and plenty of non-WordPress sites use something like it on their outage pages.
Searches for the exact sentence sat at 20 to 50 a month through 2023 and jumped to 2,400 a month from November 2024, and they are still around 1,900 a month (DataForSEO Labs, 2026-10-31). WordPress 5.2 sites did not multiply in late 2024, so at least part of that traffic is likely people hitting some other site's error page.
If the site is not yours, there is nothing to fix: the owner has to, and retrying later is the whole answer.
If it is yours, confirm it is the WordPress handler you are looking at:
curl -s -o /tmp/err.html -w '%{http_code}\n' https://example.com/
grep -o '<title>[^<]*</title>\|wp-die-message' /tmp/err.html
The core page comes from wp_die() with a 500 status, the default title WordPress › Error, and the message inside a <div class="wp-die-message">. A 200, a different title, or a branded page means the message came from somewhere else, which is the next section.
Why do I see the old wording on a current WordPress?
Here are the messages from display_default_error_template() in wp-includes/class-wp-fatal-error-handler.php, by version:
| Version | Where | Message |
|---|---|---|
| 5.2 | Front end | The site is experiencing technical difficulties. |
| 5.2 | wp-admin, wp-login.php | The site is experiencing technical difficulties. Please check your site admin email inbox for instructions. |
| 5.3 | Front end | There has been a critical error on your website. |
| Current | Front end | There has been a critical error on this website. |
| Current | wp-admin, wp-login.php, single site | ...Please check your site admin email inbox for instructions. If you continue to have problems, please try the support forums. |
| Current | wp-admin, multisite | ...Please reach out to your site administrator, and inform them of this error for further assistance. |
| Current | In a recovery session | ...putting it in recovery mode. Please check the Themes and Plugins screens for more details. |
That leaves three ways a site on a current release still shows the 5.2 sentence.
The site really is on 5.2. Check before assuming anything else:
grep wp_version wp-includes/version.php
# or, with WP-CLI
wp core version
If it says 5.2.x, the crash is very likely a plugin or theme that now needs a newer WordPress or a newer PHP than the site has. Do not update core in place on a broken site that old; take a copy first (see the last section).
Something replaced the message. Core loads wp-content/php-error.php instead of its own template if that file exists, and the message also passes through the wp_php_error_message filter. Hosts, agencies and old tutorials have shipped both, often with the 5.2 text pasted in.
ls -l wp-content/php-error.php
grep -rln "technical difficulties" wp-content/ --include=*.php
A hit in php-error.php, an mu-plugin or a theme's functions.php tells you the wording is custom. It tells you nothing about the cause of the crash, which is still a real fatal error you have to find.
You are looking at a stored copy. If a page cache, a reverse proxy or a CDN rule kept the error page, it keeps serving it after the site recovers. Compare the response headers with a request that bypasses the cache:
curl -sI https://example.com/ | grep -i 'age\|cache\|x-'
curl -sI "https://example.com/?nocache=$(date +%s)" | head -1
If the cache-busting request returns 200 and the plain one returns 500 with a cache HIT, the site is fine and the cache needs purging. Our guide to clearing a WordPress cache covers each layer.
Why is there no email, when the page says to check it?
The page and the email are decided separately, and the email has more conditions than the page. In WP_Recovery_Mode::handle_error(), core sends a recovery link only when the crashing file is inside WP_PLUGIN_DIR or a theme directory, the plugin is not network-activated, and the request was to a protected endpoint: wp-admin, wp-login.php, or one of a short list of Ajax actions such as update-plugin and heartbeat.
None of the top-ranking guides we read spells out the consequence. A plugin that fatals only on the front end will show visitors the error page all day and never mail anyone, because a front-end request never qualifies.
Load /wp-admin/ yourself and core gets a chance to send it.
The other conditions, in short: one email per day by default (recovery_mode_email_rate_limit), sent to RECOVERY_MODE_EMAIL if defined and otherwise to the admin_email option, never on multisite, and never if WP_DISABLE_FATAL_ERROR_HANDLER is set. We went through each of these in source in WordPress recovery mode: why the email never arrived.
wp option get admin_email
wp config has RECOVERY_MODE_EMAIL && wp config get RECOVERY_MODE_EMAIL
wp config has WP_DISABLE_FATAL_ERROR_HANDLER
How do I find what crashed?
Read the error, not the page. The handler deliberately hides the details from visitors, so the PHP message is in a log, and it names the file and line.
Turn on logging without showing errors to visitors, in wp-config.php above the "stop editing" line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Load the broken page once, then read the end of wp-content/debug.log. The line you want starts PHP Fatal error: and its path tells you the owner: wp-content/plugins/<slug>/ is that plugin, wp-content/themes/<slug>/ is that theme.
Core only intercepts E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR and E_RECOVERABLE_ERROR (should_handle_error()). A warning or a deprecation notice does not produce this page, however many of them are in the log, so skip past them to the fatal.
If the log is empty, the crash may come before WordPress can write it, for example a syntax error in wp-config.php. Your host's PHP error log catches those, and the full no-access routine is in debugging a WordPress white screen.
How do I get the site back up?
Switch off the one thing the log named. With WP-CLI, skipping plugins and themes so the broken code never loads:
wp plugin deactivate <slug> --skip-plugins --skip-themes
# a broken theme: activate a default one instead
wp theme activate twentytwentyfive --skip-plugins --skip-themes
Without WP-CLI, rename wp-content/plugins/<slug> over SFTP; WordPress skips a plugin whose folder has gone, and drops it from the active list the next time you open the Plugins screen. Renaming the whole plugins directory works too, but you then have to reactivate everything by hand, so prefer the single folder when the log has named it.
On a site losing orders, do this on production first and investigate second. Everything below assumes the site is back up.
Find out why it broke, on a copy
The deactivated plugin is a stopgap. You still need to know whether the fix is an update, a PHP version change, or a conflict with another plugin, and testing that on production means breaking it again.
Copy the site instead. The SandyWP Cloner plugin sends a database export and a copy of wp-content to a disposable sandbox, and only reads the live site while doing it.
The plugin runs from wp-admin, so if both the front end and wp-admin are crashing, deactivate the culprit first and clone after.
On the copy, reactivate the plugin and reproduce the crash on purpose. Debug mode switches WP_DEBUG_LOG and WP_DEBUG_DISPLAY per site and shows debug.log in the dashboard, so the fatal is one reload away.
From there, try the candidate fixes one at a time with WP-CLI over SSH: wp plugin update <slug>, a different PHP version, or deactivating plugins one by one until the fatal stops. The sandbox also captures outgoing mail in its email log, so you can trigger the crash from wp-admin and read the recovery email core sends without it reaching anybody.
Once the copy works, you know exactly which change to make on production. Then delete the copy.
When a copy is the wrong tool
A copy reproduces code and data problems: a plugin needing newer PHP, two plugins declaring the same function, a theme calling a removed function. It does not reproduce the live server.
If the log says Allowed memory size exhausted or a fatal only happens under real traffic, the cause may be a memory limit, an opcode cache or a host-level setting, and the place to test it is the live server or a staging copy on the same host. And if the error page is a cached copy, or not WordPress at all, there is nothing to reproduce.
