What the message is
WordPress.org's Common WordPress Errors page quotes the full message: There has been a critical error on this website. Please check your site admin email inbox for instructions. It lists the usual causes as plugin conflicts, theme compatibility issues, an incompatible PHP version, hitting the memory limit, or corrupted WordPress files.
The message comes from the fatal error protection added in WordPress 5.2. The WordPress core developer note explains that when a plugin or theme causes a fatal error, WordPress emails the admin address a secret link to recovery mode. Recovery mode sets a cookie on your browser and pauses the failing extensions for that browser only, so you can reach the dashboard. Everyone else still sees the error until you deactivate or fix the extension.
After a migration, all three common triggers change at once: the PHP version, the PHP extensions installed and the memory limit all belong to the new server, not to your site files.
Path 1: use the recovery-mode email
Look in the inbox of the address set as the site's admin email. Following the link logs you into recovery mode, where the dashboard names the paused plugin or theme. Deactivate it, then check whether the site loads for a logged-out visitor.
On a freshly migrated site, the email may never arrive because outgoing mail has not been set up on the new host yet. If nothing comes within a few minutes, go straight to the debug log rather than waiting.
Path 2: read the debug log
WordPress.org's Debugging in WordPress page documents adding define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php, which writes errors, notices and warnings to debug.log in the content directory, usually wp-content/debug.log. Reload the broken page once, then open the log and find the line that starts with PHP Fatal error. The file path in that line names the plugin or theme folder at fault.
Turn logging off when you are done. The Site Health screen flags WP_DEBUG_LOG as a critical issue because errors are written to a file that is potentially available to all users. If you cannot reach the dashboard at all, WordPress.org's troubleshooting FAQ documents two ways to deactivate every plugin: rename wp-content/plugins (for example to plugins.hold) by FTP or file manager, or set the active_plugins option to a:0:{} in phpMyAdmin.
Migration causes and how to confirm each
Read the fatal error line first, then match it to the server difference most likely to produce it.
| Cause after a move | Typical clue in the log | What to compare |
|---|---|---|
| Newer PHP than the old host | An error inside an older plugin or theme file that worked yesterday | PHP version on old and new host; plugin's stated PHP support |
| Older PHP than the old host | Syntax or unknown function errors in a recently updated plugin | The plugin's minimum PHP version |
| Missing PHP extension | Call to undefined function, for example an mb_ or intl function | WordPress hosting handbook extension list against the new host's PHP settings |
| Lower memory limit | Allowed memory size of ... bytes exhausted | WP_MEMORY_LIMIT and the host's PHP memory limit; LearnDash asks for 128 MB or more |
| Incomplete file copy | Failed opening required file, or a missing class | File counts and sizes in wp-content between old and new servers |
Published requirements for common course and membership plugins
The table collects what each project publishes. WordPress itself recommends PHP 8.3 or greater and says it also works with PHP 7.4 and later, but that those older versions are end of life. PHP.net lists 8.2 as receiving security fixes until 31 December 2026, 8.3 until 31 December 2027, 8.4 until 31 December 2028 and 8.5 until 31 December 2029.
| Software | PHP | WordPress | Database | Other published requirements |
|---|---|---|---|---|
| WordPress core | 8.3 or greater recommended; works with 7.4+ | Not applicable | MySQL 8.0+ or MariaDB 10.11+ recommended | HTTPS support |
| LearnDash | 7.4 or greater; 8.3 recommended | 6.6 or greater | MySQL 5.6+ or MariaDB 10.1+ | PHP memory limit 128 MB or greater; multisite not supported |
| MemberPress | 7.4+ | 6.0+ | MySQL 8.0+ | NO_ZERO_DATE and strict mode should be disabled |
| LifterLMS | 8.3 recommended | 6.7 recommended | MySQL 8.0+ or MariaDB 10.6+ | Nginx, or Apache with mod_rewrite |
Extensions and memory to check on the new host
The WordPress hosting handbook lists json, hash and mysqli as required PHP extensions, and curl, dom, exif, fileinfo, igbinary, imagick, intl, mbstring, openssl, xml and zip as highly recommended. Site Health's Info tab, under Server, shows the PHP version and settings the new host is actually running; compare it with the same screen on the old host before you cancel it.
For memory, WordPress.org says WordPress tries to raise PHP memory to 40 MB on a single site and 64 MB on multisite by default, and WP_MEMORY_LIMIT can change that within what the host allows. LearnDash publishes a 128 MB minimum, so a new host with a lower ceiling needs a plan or setting change, not just a wp-config edit.
A practical rule for the cutover: run the new host on the same PHP version as the old one, prove the site works, and upgrade PHP as a separate step. Our PHP upgrade acceptance guide covers that second step.
Critical error checklist after a host move
- Check the admin email for the recovery-mode link and deactivate the paused extension.
- If no email arrives, enable WP_DEBUG and WP_DEBUG_LOG and read wp-content/debug.log.
- Compare PHP version, extensions and memory limit on old and new hosts in Site Health > Info > Server.
- Match the old PHP version for cutover; upgrade separately later.
- Confirm each LMS and membership plugin's published PHP, WordPress and database minimums.
- Reactivate premium plugin licenses on the new domain if they fail license checks.
- Turn debug logging off and delete debug.log when finished.
Questions before you decide
Where does the critical error email go?
To the site admin email address. WordPress's 5.2 developer note says the admin receives a secret link to recovery mode, which pauses the failing plugin or theme for that browser only. If outgoing mail is not working on the new host, use the debug log instead.
Where is the WordPress debug log?
With WP_DEBUG and WP_DEBUG_LOG set to true, WordPress writes debug.log to the content directory, usually wp-content/debug.log. Site Health warns that this file may be publicly reachable, so turn logging off afterward.
Which PHP version should a LearnDash site use?
LearnDash's technical requirements list PHP 7.4 or greater and recommend PHP 8.3. WordPress also recommends 8.3 or greater. During a migration, match the old host's version first and upgrade separately.
Can low memory cause the critical error?
Yes. WordPress.org lists hitting the memory limit among the causes. LearnDash publishes a minimum PHP memory limit of 128 MB, above WordPress's default 40 MB attempt for a single site.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- WordPress.org: Common WordPress errors Accessed 30 Oct 2026
- Make WordPress Core: Fatal error recovery mode in 5.2 Accessed 30 Oct 2026
- WordPress.org: Debugging in WordPress Accessed 30 Oct 2026
- WordPress.org: Editing wp-config.php Accessed 30 Oct 2026
- WordPress.org: FAQ troubleshooting Accessed 30 Oct 2026
- WordPress.org: Site Health screen Accessed 30 Oct 2026
- WordPress.org: Requirements Accessed 30 Oct 2026
- WordPress hosting handbook: Server environment Accessed 30 Oct 2026
- PHP.net: Supported versions Accessed 30 Oct 2026
- LearnDash (Nexcess docs): Technical requirements Accessed 30 Oct 2026
- MemberPress: Technical requirements Accessed 30 Oct 2026
- LifterLMS: System requirements Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.