My WordPress website broke after an update: what should I do?

Did your WordPress website break after an update? Learn what may have changed, which checks are safe, how to roll back carefully and when to ask for support.

Open a support ticket

If your website stopped working properly right after an update, something in the new version is not working well with the rest of your website.

The problem can show up in different ways:

  • the layout looks broken or unstyled
  • WordPress shows a critical error
  • the dashboard is no longer accessible
  • a function has disappeared, such as a form, a menu or a slider
  • the checkout or the payment step no longer works
  • the website is stuck on a maintenance message

This is one of the most common WordPress problems, and it is usually fixable. An update that went wrong does not necessarily mean that your content, orders or customer data have been lost.

The most important thing is to work out which update caused the problem before trying to undo it. Undoing the wrong thing, or undoing everything at once, can create new problems on top of the original one.

This guide explains which updates are usually involved, which checks you can do safely, how to roll back carefully and when it is better to ask for technical support.

Which update could have caused the problem?

A WordPress website is updated in several layers. Each one can trigger a problem in a different way.

A plugin update

This is the most frequent case. A new plugin version may not be compatible with:

  • another plugin
  • the active theme
  • the version of WordPress
  • the PHP version on the server
  • custom code written for your website

The new version is not necessarily faulty. Sometimes it simply changes something that another component relied on.

A WordPress core update

Major WordPress releases can change how the editor, blocks or certain functions behave. Older plugins, themes or custom code that have not been updated for some time are the most likely to be affected.

A theme update

If the theme was customized by editing its files directly, an update can overwrite those changes. This often looks like a layout that suddenly changed, missing sections or styling that disappeared.

A child theme protects customizations from parent theme updates. If your website does not use one, a theme update is a common reason for lost changes.

A PHP update by the hosting provider

PHP is the programming language that WordPress runs on. Hosting providers periodically retire old PHP versions and move websites to newer ones.

This kind of update can happen without anyone logging into WordPress. If nobody on your side updated anything, ask your hosting provider whether the PHP version changed recently.

Automatic updates

WordPress can update itself, and plugins and themes can be set to update automatically. Some hosting providers also run updates on your behalf.

This means a website can break overnight even if nobody touched it. Check the update history in your hosting panel or ask whoever manages the website.

First: try to understand what was updated

You do not need to be technical to collect useful information.

Think about what happened right before the problem appeared:

  • Did you click "Update" on one plugin or on several at once?
  • Did you update WordPress itself?
  • Did you update the theme?
  • Did someone else work on the website?
  • Did you receive an email saying that updates were installed automatically?
  • Did the hosting provider announce a PHP or server change?

If you are not sure what was updated, open:

Dashboard → Updates

Then:

Plugins → Installed Plugins

The plugin list shows the current version of each plugin. Comparing it with what you remember, or with a recent backup report, can help you identify what changed.

WordPress may also send an email to the administrator address after automatic updates or when it detects a critical error. Check the inbox and the spam folder.

Write down everything you find. A note such as "the problem started after updating three plugins this morning" is already very useful.

Clear caches before anything else

Sometimes the website is actually fine, but you are seeing an old or mixed version of it.

After an update, cached files can combine new code with old styles or scripts. This can make the layout look broken when the underlying problem is only temporary.

Check these layers, one at a time:

  • Browser cache: open the website in a private or incognito window, or try a different browser.
  • Caching plugin: if you use a caching or performance plugin, use its option to clear or purge the cache.
  • Hosting cache: many hosting providers have their own cache, which can be cleared from the hosting panel.
  • CDN: if the website uses a service such as Cloudflare, clear its cache from the service dashboard.

If the website looks correct after clearing caches, test it again on a different device and check the important functions to confirm.

If the problem is still there, the update has most likely caused a real compatibility issue.

Check exactly what is broken

Open the website in a private window and test the homepage, an internal page, the login page, the dashboard and the main business functions, such as forms, cart, checkout or bookings.

Write down what works and what does not. For example, the pages may look fine while the contact form no longer sends, or the shop may work until the payment step.

Knowing exactly where the problem appears often points directly to the plugin or function involved.

What can you safely try?

The right approach depends on how important the website is and how comfortable you are managing WordPress.

Option 1: contact the person who ran the update

If an agency, developer, colleague or hosting provider ran the update, contact them first.

Ask them which components were updated, in which order, whether any warnings appeared and whether a backup was taken right before.

Option 2: deactivate the plugin that was just updated

Only try this if you can access the dashboard and you are fairly sure which plugin is involved.

Go to:

Plugins → Installed Plugins

Deactivate only the suspected plugin, then check whether the problem disappears.

Keep in mind that plugins can control important functions such as payments, subscriptions, forms, security or translations. If the website looks fine again, the function provided by that plugin is now missing. Test it before deciding what to do next.

Option 3: roll back the plugin or theme to the previous version

If one specific update caused the problem, going back to the previous version can be a reasonable temporary fix.

Before rolling back:

  • take a full backup of the current website, including the database
  • check which version was installed before the update
  • check the plugin changelog, if available, to see whether the update included security fixes

There are two important risks:

  • Some updates also change the database. Going back to the old plugin files does not always undo those changes, and the older version may not work correctly with the updated data.
  • If the update fixed a security vulnerability, rolling back leaves that vulnerability open again.

A rollback should buy time, not become permanent. The goal is to understand the incompatibility and move back to an up to date, working version as soon as possible.

Premium plugins and themes are often not available from the WordPress.org directory. Older versions may need to be downloaded from the vendor account.

Option 4: restore a backup

A restore can be the right choice when the website broke right after a known update and a reliable backup exists from just before it.

However, a restore brings back the whole website as it was at the time of the backup. Anything created after that moment can be overwritten, including:

  • orders
  • payments recorded on the website
  • customer accounts
  • subscription renewals
  • form submissions
  • content edits

This is especially important for WooCommerce, membership and booking websites. Even a few hours of lost orders can cause serious problems with customers, stock and accounting.

On these websites, do not restore a backup without first checking what data would be lost. It is sometimes possible to restore only the files, or to preserve recent orders while restoring the rest.

D4Hub can help you decide whether a restore is appropriate and how to protect more recent data.

What should you avoid doing?

When the website is not working, it is natural to want to try everything quickly. This often makes the original problem harder to find.

Avoid:

  • running the remaining pending updates in the hope that they fix the issue
  • deactivating all plugins at once on a live shop
  • deleting plugins or themes without a backup
  • restoring an old backup without checking its date
  • changing the PHP version back and forth
  • reinstalling WordPress over the existing installation without a backup
  • editing the database
  • copying code from forums without understanding it
  • making several changes before testing the result

Change one thing at a time and write down what you did and what happened after each step.

If you are unsure, stopping is often safer than continuing. D4Hub can pick up the investigation at any point, including after an unsuccessful attempt.

How can you avoid this next time?

Updates are necessary: they fix bugs and security vulnerabilities, and skipping them for a long time usually makes the next update riskier. The goal is to update safely, not to stop updating.

A safer routine usually includes:

  • a staging environment: a private copy of the website where updates are tested before they reach the live site. Many hosting providers offer one.
  • a backup right before updating: files and database, from a backup you know can actually be restored.
  • small batches: updating one plugin or a few at a time makes the cause much easier to find.
  • careful auto-updates: they are useful for security, but for plugins that handle payments or subscriptions many businesses prefer to update manually after testing. You can enable or disable them for each plugin from Plugins → Installed Plugins.
  • a quick test afterwards: check forms, checkout and the other functions that matter most to your business.

When should you ask for technical support?

Technical support is recommended when:

  • the whole website is down
  • checkout, payments or subscriptions are affected
  • you cannot access the dashboard
  • you do not know which update caused the problem
  • several components were updated at the same time
  • you do not have a recent, verified backup
  • the website handles orders or customer data that cannot be lost
  • the problem involves custom code or a customized theme
  • a rollback did not fix the problem, or created new ones
  • the hosting provider changed the PHP version and the website no longer works

You do not need to diagnose the problem yourself before asking for help.

What information should you collect?

Before opening a support request, collect whatever is easily available:

  • the website URL
  • screenshots of the problem
  • the approximate time the problem started
  • which updates were run, if you know
  • whether updates were manual or automatic
  • which pages or functions are affected
  • whether the dashboard is accessible
  • any email received from WordPress or the hosting provider
  • the name of the hosting provider
  • whether a backup from before the update is available

Do not send passwords or access details by ordinary email, and do not post screenshots that show credentials or full error logs in public forums.

If you cannot provide everything, that is fine. D4Hub can help you understand what else is needed.

How D4Hub can help

The objective is not only to make the website work again today. It is also to understand what broke, so the next update does not cause the same problem.

Depending on the situation, D4Hub can help with:

  • identifying which update caused the problem
  • checking compatibility between WordPress, plugins, theme and PHP
  • rolling back a plugin, theme or WordPress version safely
  • evaluating whether a backup should be restored and what data could be lost
  • preserving recent orders and customer data during a recovery
  • repairing custom code that stopped working after an update
  • coordinating with the hosting provider about PHP or server changes
  • testing checkout, forms, login and other important functions
  • setting up a staging environment to test future updates
  • reviewing your auto-update settings and update routine

You can ask for support at any stage of the process.

For example, D4Hub can tell you whether a rollback or a restore is safe in your case, take over when the dashboard is inaccessible, or review the website after a temporary fix.

If any step in this guide feels unclear or risky, you do not need to do it alone.

Open a support ticket

For hands-on users: technical checks and rollbacks

The following checks are intended for users who are comfortable with hosting panels, SFTP, the command line and WP-CLI.

Take a full backup of files and database before making any change. Make sure you are working on the correct WordPress installation, and change one thing at a time.

Check WordPress, plugin and PHP versions

With WP-CLI, run these commands from the WordPress root folder.

Check the WordPress version:

wp core version

List plugins with their status and current version:

wp plugin list --fields=name,status,version,update_version

Do the same for themes:

wp theme list

WP-CLI does not show a history of when each plugin was updated. Compare the versions with your backup reports, the update emails from WordPress or the update history in your hosting panel.

Check PHP information for the command line:

wp --info

or:

php -v

Be aware that the PHP version used on the command line can be different from the one used by the website. The hosting panel usually shows the PHP version assigned to the website itself.

Run WP-CLI when the website has a fatal error

If a plugin or theme causes a fatal error, WP-CLI commands may fail too. You can skip loading plugins and themes:

wp plugin list --skip-plugins --skip-themes

Deactivate a plugin

With WP-CLI:

wp plugin deactivate plugin-slug

Without WP-CLI, open the hosting file manager or connect through SFTP and go to:

wp-content/plugins/

Rename the folder of the suspected plugin, for example from plugin-slug to plugin-slug-disabled. WordPress will no longer load it. Do not delete the folder.

Roll back a plugin to a specific version

For plugins hosted in the WordPress.org directory, you can reinstall a previous version:

wp plugin install plugin-slug --version=1.2.3 --force

Replace plugin-slug with the plugin folder name and 1.2.3 with the version that was installed before the update. Previous versions are listed under "Advanced View" on the plugin page at WordPress.org.

This does not work for premium plugins that are not in the directory. Remember that rolling back the files does not undo database changes made by the newer version.

Check whether an update was interrupted

If the website shows a message like "Briefly unavailable for scheduled maintenance" for a long time, an update may have stopped halfway.

Look for a file named .maintenance in the WordPress root folder. Removing it ends maintenance mode, but the interrupted update may have left incomplete files that still need to be checked.

To check whether WordPress core files match the official release:

wp core verify-checksums

Enable a temporary debug log

To see the actual error, you can enable logging in wp-config.php, before the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the problem once, then read:

wp-content/debug.log

Turn debugging off again when you are done. Logs can contain file paths and other sensitive information: do not publish them.

D4Hub can help you read the results, choose the safest rollback and test the website afterwards.

FAQFrequently asked questions

Usually not. An update that breaks the website normally affects the code, not the content stored in the database.

The bigger risk is what happens next: restoring an old backup without checking it can overwrite recent orders or content. Check before restoring.

On a simple brochure website with no recent changes, this can be a quick solution.

On a shop, membership or booking website, a restore can remove orders, payments and registrations created since the backup. Check the backup date and what would be lost first.

Not safely. Updates often include security fixes, and outdated plugins are a common way websites get compromised. It is better to change how you update: staging, backups and smaller batches.

Not necessarily. Automatic updates can be very useful for security. Many businesses keep them on for minor WordPress releases and low risk plugins, and update critical plugins manually after testing.

This can be a short term solution if the old version is still available. However, old PHP versions stop receiving security updates. The long term solution is to make the website compatible with the newer version.

Yes. Explain what you tried and what happened after each step. This helps reconstruct the incident and decide the next safe action.