What does “There has been a critical error on this website” mean?
It means PHP hit a fatal error while building the page and WordPress stopped. Rather than dump technical details on visitors, WordPress shows a short, generic notice and, where it can, emails the site administrator.
Before WordPress 5.2, the same failure usually produced a blank white page, the so-called white screen of death. The WordPress core team's announcement of fatal error recovery mode in 5.2 explains the change: when a fatal error happens, WordPress sends the admin email a secret link into recovery mode, where the plugin or theme responsible is paused so you can log in and deal with it.
So the message is not the problem itself. It is a cover over a specific error in a specific file, and a WordPress critical error fix is really about uncovering that line. Once you know which file failed and why, the repair is usually straightforward. Guessing without the log is how people end up deleting the wrong plugin or reinstalling WordPress for no reason.
- Front end, admin or both can show the message
- Visitors see only the notice; details are hidden for safety
- WordPress tries to email the admin address with a recovery link
- The underlying cause is logged if debugging is enabled
Step one: check the recovery mode email
Check the inbox of the site's admin email address, including spam, for a message from your WordPress site about a technical issue. It usually names the plugin or theme that caused the failure and contains a link into recovery mode.
Clicking the link places a cookie in your browser and lets you log in to the dashboard with the faulty extension paused for you only. From there you can deactivate it, roll back to an earlier version, or contact its developer. The core announcement notes there is a button in the admin bar to exit recovery mode when you are done.
Problems with this step are common in practice. The admin address may belong to a developer who left years ago. The site's mail may not be delivered because it uses PHP mail without proper authentication. Developers can redirect these alerts using the RECOVERY_MODE_EMAIL constant, which is worth setting to a shared inbox as part of prevention.
If mail from your site never arrives, the same authentication gaps probably affect contact form emails too; see why business emails land in spam. When no email appears within a few minutes, move on to the debug log.
How to enable the WordPress debug log to find the real error
Turn on logging in wp-config.php, reload the broken page once, and read the new log file. This is the single most useful step in any WordPress critical error fix without a recovery email.
WordPress's developer documentation describes three constants. WP_DEBUG switches debug mode on across WordPress. WP_DEBUG_LOG, when true, saves messages to debug.log in the content directory, usually wp-content/debug.log. WP_DEBUG_DISPLAY controls whether messages are printed inside the page HTML. On a live site you want logging on and display off, so visitors never see file paths.
Add the lines above the comment that says to stop editing, using your hosting file manager or FTP. Then load the page that fails. Open debug.log and look for lines that start with “PHP Fatal error”. The line names a file path and line number; the folder in that path, such as wp-content/plugins/some-plugin, tells you what to disable.
The same documentation warns that debug tools are meant for local testing and staging, not live sites. So switch WP_DEBUG back to false when finished and delete the log, which can reveal server paths if left publicly reachable.
- define( 'WP_DEBUG', true );
- define( 'WP_DEBUG_LOG', true );
- define( 'WP_DEBUG_DISPLAY', false );
Reading the fatal error line: what common messages tell you
Every fatal error line has three useful parts: the type of error, the file and the line number. The type tells you what kind of fix you need; the file tells you who wrote the code.
“Allowed memory size … exhausted”
PHP ran out of memory. The file named is often innocent; the real issue is a heavy plugin or a low limit. Raise WP_MEMORY_LIMIT or the host's PHP memory, then find what is consuming it.
“Call to undefined function”
Code relies on a function that is not loaded: a missing PHP extension, a deactivated companion plugin, or a function removed in a newer PHP version.
“Uncaught Error: Class … not found”
An autoloader or dependency is missing, often after an incomplete plugin update. Reinstalling that plugin cleanly usually resolves it.
“syntax error, unexpected …”
Someone edited a PHP file by hand, commonly functions.php, and left a typo. Undo that edit or restore the file.
“Cannot redeclare …”
Two plugins, or a plugin and theme, define the same function. Deactivate one of them.
“Uncaught TypeError” or “ArgumentCountError”
Old code meeting stricter rules in newer PHP. Update the plugin or theme, or fix the code.
If the path points into wp-admin or wp-includes rather than plugins or themes, core files may be damaged; that case is covered below.
WordPress critical error from a plugin: how to disable it without admin access
Rename the plugin's folder over FTP or in the hosting file manager, and WordPress deactivates it on the next load. You do not need the dashboard for this.
If the log names one plugin, rename only that folder, for example by adding “-off” to the end. Reload the site. If it comes back, you have your culprit. If the log is empty or confusing, rename the whole plugins folder to deactivate everything, confirm the site loads, then rename it back and reactivate plugins one at a time from the dashboard until the error returns.
Conflicts rather than single bad plugins are common. Two optimisation plugins both trying to rewrite the same output, a page builder add-on that expects a newer version of the builder, or a security plugin blocking another plugin's file access can each produce a fatal error only when both are active.
Once found, do not just leave it off. Check for an update, roll back to the version that worked, or replace the plugin. And note what happened, because the same plugin will update again next month. Help with choosing replacements is part of what a freelance WordPress developer does.
When the theme causes the critical error
If the fatal error points into wp-content/themes, the active theme is the cause. Rename its folder and WordPress falls back to a default theme if one is installed, which brings the site up in a plain design so you can work.
Check wp-content/themes first for a default theme such as a recent Twenty-something theme. If none is there, upload one before renaming, or WordPress will have nothing to fall back to.
Theme failures usually come from three places. Custom code pasted into functions.php, often from a tutorial, with a missing bracket. A commercial theme several years out of date that breaks on newer PHP. Or a child theme that calls functions its parent no longer provides after an update. The debug line tells you which.
Custom or heavily edited themes deserve extra care. Restoring a clean copy may wipe changes someone paid for. We compare the broken file with the original from the vendor before replacing anything, and if the theme is abandoned we discuss whether updating it or moving to a maintained theme makes more sense. Bigger rebuilds are covered on custom WordPress theme development.
WordPress critical error after a PHP update: fixing version mismatches
If the error appeared when your host changed the PHP version, older code is failing on the newer version. The short-term fix is to select the previous version in the hosting panel; the real fix is updating the code so the site runs on a supported release.
Why hosts push upgrades: the PHP project's supported-versions page says each release branch receives two years of active support and then two years of security fixes only, after which it reaches end of life. It lists PHP 8.2's security support ending on 31 December 2026, for example. WordPress.org's requirements page recommends PHP 8.3 or greater.
Rolling back PHP buys time but leaves the site on a version that will stop getting security fixes. So use the rollback to get the site up, then update or replace the plugins and theme that failed, test on a staging copy with the newer PHP, and switch again once the log is clean.
Many Indian shared hosting panels have a “Select PHP version” or “MultiPHP Manager” tool that sets the version per domain. Change only the affected site, and note the old value before touching it. For older custom PHP code rather than WordPress plugins, see PHP version upgrade.
Memory limits, corrupted core files and failed updates
Not every critical error comes from a plugin or theme. Memory exhaustion, a half-finished core update and damaged files can all produce the same message.
Memory errors show the “Allowed memory size exhausted” line. Raising WP_MEMORY_LIMIT in wp-config.php, or the PHP memory limit in the hosting panel, often brings the site back. But treat it as a clue: a site that suddenly needs far more memory usually has a plugin doing something expensive, such as loading huge product lists into one page.
A core update interrupted by a timeout can leave a mix of old and new files. Signs include errors pointing into wp-admin or wp-includes and a leftover .maintenance file in the site root that keeps showing a maintenance message. The fix is to replace wp-admin and wp-includes with fresh copies of the same WordPress version, without touching wp-content or wp-config.php, and delete the .maintenance file.
Damaged database tables are rarer but real after server crashes. WordPress has a built-in repair script enabled through a wp-config constant; use it briefly, then turn it off again.
WordPress critical error on a WooCommerce store
On a store the same steps apply, but the stakes and the order change: get checkout working first, then investigate the rest. Every hour down means lost orders and customers who may not come back.
WooCommerce sites run more extensions than most, and those extensions often depend on a minimum WooCommerce version. An automatic update to WooCommerce itself can leave a payment, shipping or invoicing extension calling functions that moved. The log names it; roll that extension back or update it.
After recovery, test properly. Place orders through UPI, card and cash on delivery if you offer them, confirm that order emails go out, that stock reduces, and that invoices with GST details generate correctly. A store that loads but cannot take payment is still broken.
Stores benefit most from a staging copy where updates are tried first. If yours needs deeper work, see our WooCommerce development page; if you are considering a move off WooCommerce, Shopify maintenance explains what upkeep looks like there.
Can't log in to WordPress admin? Fixing the critical error from the hosting panel
You can fix almost every critical error without the dashboard, as long as you can reach the files. The hosting control panel's file manager or an FTP/SFTP account is all you need.
Decide what access you actually have. With a hosting login, open the file manager, go to the site's folder and you can edit wp-config.php, rename plugin and theme folders and download the debug log. Without a hosting login but with FTP details, the same is possible using an FTP client. With neither, your first task is recovering access from the hosting company using the account email.
This is where Indian sites often stall. The developer who built the site registered hosting under their own email and cannot be reached. Hosting companies can usually restore access to the verified account owner, which is why hosting should always be in the business's name. Our guide for when a developer leaves a project midway covers the recovery steps.
Have hosting panel access
Everything in this guide is possible: edit wp-config.php, rename folders, change PHP version, read logs.
Have FTP only
Edit files and rename folders; ask the host to change PHP version if needed.
Have nothing
Recover the hosting account first. Do not pay anyone claiming they can fix it without access.
What not to do while fixing a WordPress critical error
The most expensive mistakes happen in the first panicked hour. Slow down enough to avoid making the problem bigger.
Do not delete plugins when renaming will do; deleting can remove settings and data. Do not reinstall WordPress over the whole folder, which risks overwriting wp-content. Do not restore an old backup on a store without checking what orders came in since. Do not leave WP_DEBUG_DISPLAY on, which shows file paths to visitors and attackers. And do not paste random code from forums into functions.php on the live site.
Most of all, take a backup of the broken site before changing anything, files and database both. It sounds odd to back up something that does not work, but it preserves recent content and gives you a way back if a fix goes wrong.
- Back up the broken site first
- Rename folders instead of deleting plugins
- Keep debug display off on live sites
- Check order history before restoring a store backup
- Do not reinstall over wp-content
- Write down every change you make
Should you attempt a WordPress critical error fix yourself?
Try it yourself if you have hosting access, the recovery email or log names one plugin, and the site is not a busy store. Call someone when the log points to custom code, core files or PHP compatibility, or when the site makes money every hour it is down.
A reasonable rule: give yourself thirty minutes with the steps above. If the site is not back by then, or you are no longer sure which change did what, stop and get help rather than stacking more changes on top.
When you hire, share the error line and any recovery email up front, along with hosting access. It saves time and money. Ask the person fixing it to tell you the cause in writing and what should change so it does not recur. Anyone who fixes it without explaining is setting you up for the same call next month. Help is available through hiring a WordPress developer or directly from us on WhatsApp.
How much does a WordPress critical error fix cost in India?
It depends on the cause, so an honest price comes after the diagnosis. A single plugin conflict on a small site is a short job. A custom theme that needs rewriting for current PHP, or a store with several broken extensions, takes longer.
Across the market, quotes for emergency WordPress fixes vary widely. The differences come from access (ready logins versus recovery), whether the cause is found or merely hidden, how much testing follows, and whether the person can work with custom code. Compare what each offer includes rather than only the number.
For prevention, our maintenance plans start at ₹8,000/mo (US$120/mo abroad), with updates tested on a copy, off-server backups and monitoring. General pricing for upkeep is explained on website maintenance charges. When a site is too far gone, rebuilding as a static site from ₹10,000 or a store from ₹50,000 can be cheaper than repeated rescues.
- Access: hosting and FTP ready, or recovery needed first
- Cause: one plugin, theme code, PHP compatibility or core damage
- Custom code written by someone else
- Store testing needed after recovery
- Any sign of malware behind the error
How to prevent the WordPress critical error next time
Most critical errors come from updates applied straight to the live site. Put a buffer between an update and your visitors and the problem mostly goes away.
- Keep a staging copy and apply updates there first
- Automatic off-server backups, with a restore tested occasionally
- Fewer plugins: remove anything unused or duplicated
- Avoid nulled or pirated themes and plugins entirely
- Plan PHP upgrades before the host forces them
- Set RECOVERY_MODE_EMAIL to a shared inbox someone reads
- Uptime monitoring that alerts you within minutes
- A written list of custom code and where it lives
- Turn off automatic updates for critical plugins on stores, and update them deliberately
Monitoring is covered on website uptime monitoring. If a second problem appears alongside the error, such as a missing padlock, see website showing not secure.
Worked example: a hotel site down after an overnight update
This is a hypothetical case to show the sequence. Say a family-run hotel in Shimla uses WordPress with a booking plugin, a page builder and a commercial theme bought years ago. One morning the site shows “There has been a critical error on this website”, the admin area shows the same, and the recovery email went to a developer's old address.
With hosting access shared, the first step is a backup of files and database as they stand. Next, WP_DEBUG_LOG goes on with display off. One reload later, debug.log shows a fatal “Uncaught TypeError” inside the theme's functions file. The host had moved the account to a newer PHP version overnight.
Short term, the PHP version is set back to the previous one for that domain in the panel, and the site returns within minutes. Bookings are checked: the calendar loads and a test enquiry arrives. RECOVERY_MODE_EMAIL is set to the hotel's shared inbox.
Longer term, the theme vendor's latest version is tested on a staging copy running the newer PHP. It fixes the error, but two custom sections need reapplying. Once the log is clean on staging, the change goes live and PHP is upgraded again, this time on purpose. Debug mode is switched off and the log deleted.
WordPress critical error fixes for sites across India
We fix WordPress sites remotely, so location does not change the method. It does change the kind of site we tend to see broken.
Hotels and homestays in Shimla, Rishikesh and Puri run booking plugins that must be up during season. Educational institutions in Warangal, Gwalior and Jabalpur publish results and admission pages on WordPress that see heavy traffic on specific days. Manufacturers and suppliers in Jamshedpur, Belagavi and Solapur often run older sites built years ago that break when hosts upgrade PHP. Retailers in Kozhikode and Mangaluru increasingly sell through WooCommerce, where downtime costs orders directly.