WordPress website repair starts with the log
When WordPress shows a critical error or a white screen, the temptation is obvious: disable a plugin, change PHP, update the theme, press anything that might bring the homepage back. For a Dubai consultancy, a UAE clinic or a UK service business with enquiries coming through the website, that panic is understandable. It is also where the fun starts.
A WordPress critical error means WordPress has stopped running because something triggered a fatal problem, usually in PHP. It does not prove the newest plugin caused it. Safe WordPress website repair starts by preserving evidence, checking backup status, reviewing logs, recording recent changes, isolating plugins and themes carefully, checking PHP compatibility and memory limits, then rolling back in a controlled way if needed.
The message is a symptom, not the diagnosis
The critical-error screen tells you WordPress stopped. It does not tell you which layer caused it.
The plugin might be guilty. It might also just be standing closest to the scene of the crime.
The fault may come from a plugin update, a theme function, custom code, an incompatible PHP version, exhausted memory, a hosting constraint or an interaction between two components that were perfectly polite until yesterday. Assuming the most recently updated plugin is always the cause is a fast way to waste the only useful evidence you had.
Do this before touching anything else
A critical error needs a sequence, not a guessing competition. The first job is to stop making the crime scene worse.
| Check | What to collect | Why it matters |
|---|---|---|
| Backup status | Last full backup date, database backup, file backup and restore access | You need a safe return point before changing more files |
| Recent changes | Plugin updates, theme updates, PHP changes, code edits, hosting changes | The order of events often explains the fault |
| Error evidence | Recovery email, PHP error log, wp-content debug log, hosting log entry | The fatal error normally points to a file, line or memory problem |
| Access level | Admin login, hosting panel, FTP or file manager, staging access | Some repairs cannot be done safely from the dashboard alone |
| Business impact | Homepage, forms, checkout, booking page, campaign landing pages | Repair priority depends on what is losing enquiries |
The WordPress critical-error triage checklist
1. Stop changing the live website
If the site has failed after one plugin update, do not then update PHP, the theme and six other plugins for good measure. That turns one fault into a fog.
One Dubai consultancy scenario we see too often: one plugin is updated during business hours, the site throws a critical error, then PHP is upgraded and the theme is updated before anyone checks the log or creates a rollback point. By then, nobody knows which change actually exposed the problem.
2. Check whether a backup can actually be restored
A backup mentioned in a hosting panel is not the same as a tested restore path. Check whether you have files and database backups, when they were taken, and whether restoring them will overwrite fresh form entries, orders or content changes.
Proper maintenance is boring until it is the only thing that saves the site. If your backups are unclear, make that part of your future WordPress maintenance in Dubai, not a nice-to-have you remember during an outage.
3. Record the recent change sequence
Write down the order. Plugin updated at 09:15. Error appeared at 09:16. PHP changed at 09:24. Theme updated at 09:31. Cache cleared at 09:33.
That boring timeline is useful. Without it, the repair becomes guesswork with a dashboard.
4. Look for the actual fatal error
The useful clue is usually in the server error log, the WordPress recovery email or a debug log if logging is enabled. You are looking for a fatal error, memory exhausted message, missing function, incompatible method, parse error or file path pointing to a plugin, theme or custom code.
A line number is not always the full answer, but it is better than vibes.
5. Use recovery mode carefully
WordPress may email an admin recovery link. That can let you access the dashboard and pause the component named in the error. Useful, yes. Magic, no.
Before using it, check that the email went to a current inbox. Plenty of sites still send recovery emails to an old developer, an ex-staff member or an info inbox nobody checks. Not ideal.
6. Isolate plugins without playing plugin roulette
If the log points to a plugin, disable that plugin first. If you cannot access the dashboard, rename the plugin folder through hosting file manager or FTP. Do not deactivate everything unless you have a reason and a record of what was active.
If you do need to disable all plugins, do it in a controlled way and document the active list first. Screenshots count. So does a copied directory listing. Elegant? No. Useful? Very.
7. Test the theme and custom code
Theme functions can break WordPress just as easily as plugins. So can custom snippets added years ago by someone who was very confident at the time.
If the fatal error points to functions.php, a child theme, a mu-plugin or a custom integration, treat it as a code issue rather than blaming whichever plugin updated most recently.
8. Check PHP compatibility and memory limits
A PHP version change can expose old code. A plugin that runs on one PHP version may fail on another. Memory exhaustion can also present as a critical error, especially on heavier page builders, WooCommerce setups or sites with bloated plugin stacks.
Check the current PHP version, the previous PHP version if known, the memory_limit value and any hosting restrictions. Changing PHP back may be a sensible temporary rollback, but only if you know what changed first.
9. Roll back one thing at a time
If a rollback is needed, roll back the most likely component first and test. Then move to the next. Changing five things at once might bring the website back, but it teaches you nothing and can leave a fault waiting to return during the next update.
For controlled triage, repair planning and recovery support, Standish Services handles WordPress website repair in Dubai where the priority is to diagnose before experimenting on the live site.
10. Confirm the website is actually working again
A homepage loading is not the finish line. Test the pages that make money or generate enquiries: contact forms, booking forms, WhatsApp links, quote forms, checkout, payment gateways, thank-you pages and email notifications.
A form that says thanks but sends nothing is not working. It is just being polite about failing.
What not to do during a critical error
- Do not update PHP because someone in a forum said newer is better.
- Do not delete plugins unless you know what data they store.
- Do not overwrite the theme before checking whether it contains custom edits.
- Do not clear every cache and CDN setting without noting what changed.
- Do not let three different people repair the site at the same time in different tabs.
The commercial problem is not only downtime. It is downtime plus lost evidence. A recoverable fault becomes a longer outage when several components are changed at once and nobody can reconstruct the sequence.
FAQ
Can WordPress recovery mode fix a critical error?
Recovery mode can help if WordPress identifies the plugin or theme that triggered the fatal error and sends the recovery email to a working admin address. It is a useful access route, not a full diagnosis. You still need to check logs, recent changes, PHP compatibility and whether other parts of the website are affected.
Where are WordPress critical error logs usually found?
Error evidence may be in the hosting control panel, PHP error logs, the WordPress recovery email or a wp-content debug log if debugging has been enabled. The useful detail is usually the fatal error message, file path and line number. If you only have the front-end warning screen, you have not got enough evidence yet.
Should I disable all plugins on my Dubai WordPress website?
Only if there is no safer targeted route. If the log names one plugin, start there. If you must disable all plugins, record the active list first and bring them back carefully. Blanket disabling can break forms, multilingual tools, bookings, payment gateways and page builder layouts, which creates extra repair work.
Can changing PHP fix a WordPress white screen?
Sometimes, but it can also make the situation worse. A PHP version mismatch may cause the white screen, especially with older themes, plugins or custom code. Check what PHP version was running before the failure, review the fatal error and avoid changing PHP on the live site without a rollback path.
How long does WordPress website repair usually take?
It depends on access, backups, hosting quality, the error evidence and how many changes were made after the failure. A clean log and recent backup make repair faster. A site where plugins, PHP and theme files were all changed after the error usually takes longer because the diagnosis has to be rebuilt.
Get the fault diagnosed before the experiments begin
If your WordPress site is showing a critical error or white screen, start by preserving the evidence. Note the changes, check the backup position, collect the logs and avoid stacking new fixes on top of the original fault.
Record what changed and get the fault diagnosed before experimenting on the live website. If you want a practical repair review, message Standish Services on WhatsApp.