WordPress site broke after an update: What to do in the first 10 minutes and how to roll back

WordPress stuck in maintenance mode: How do you delete the .maintenance file?

If WordPress is stuck in maintenance mode, delete the .maintenance file in the site’s root directory to remove the message. WordPress creates this file during an update and shows visitors “Briefly unavailable for scheduled maintenance. Please check back in a minute.”; if the update finishes correctly, the file disappears automatically. WordPress documentation recommends connecting through FTP and deleting .maintenance if the message remains after an update.

The file is in the same folder as wp-config.php, and because its name begins with a dot, it appears hidden in some file managers. It may not appear in the list until “show hidden files” is enabled in the hosting panel’s file manager.

Deleting the file removes the message but does not complete the interrupted update. Check the version of the relevant plugin or core in the panel; rerun the update if it was interrupted. If the same message recurs with every update, investigate server connectivity, timeouts, or file permissions separately.

A plugin update broke the site: How do you disable it without panel access?

If the panel is inaccessible, disable the plugin by renaming its folder through FTP or the hosting file manager. WordPress does not load a plugin whose folder name it cannot find; because files are not deleted, settings remain in place too.

The two methods in WordPress documentation are as follows:

• A single plugin: Rename the suspected plugin’s folder under wp-content/plugins, for example by appending “-kapali” to its name.
• All plugins: Rename wp-content/plugins to plugins_old; this disables every plugin at once.
• Theme: Rename the active theme’s folder under wp-content/themes; WordPress falls back to an appropriate default theme.

If all plugins were disabled, restore the folder’s original name after the site opens, then activate plugins individually through the panel. The plugin that breaks the site again is the culprit. It is normal for pages to appear as plain text when the page builder is disabled; the design returns when the plugin is enabled.

Rolling back a WordPress update: Restore a backup or use the previous version?

There are two ways to roll back a WordPress update: fully restore a backup taken before the update, or install only the previous version of the problematic plugin. The choice depends on how many components are affected and how recent the backup is.

Restoring a backup

WordPress’s Backup documentation states that a website consists of two parts, files and the database, that both must be backed up, and recommends a backup before every upgrade. During restoration, restore files first, followed by the database. Orders, form records, and posts added after the backup may be lost when restoring it; this requires particular consideration on e-commerce sites. How to take backups and where to store them in the WordPress backup guide is explained.

The previous plugin version

On a plugin’s page in the WordPress.org directory, open “Advanced View” below the sidebar. Under “Advanced Options,” select and download a version from “Previous Versions.” The directory also displays an explicit warning for this area: previous versions may not be secure or stable and are not recommended for use on live sites. The older version is a temporary bridge; move to the current version when the plugin developer releases a fix.

The situation differs for core: WordPress’s Upgrading documentation states that downgrading core is generally not recommended because of security risks and database issues. If unavoidable, delete WordPress files other than wp-config.php and restore the backed-up files and database.

If the design has shifted: How do you clear Elementor and cache?

If the site opens but its design appears broken, the problem often comes from old style files remaining in cache rather than code. In this situation, clear cache layers in sequence before performing a rollback.

On sites using Elementor, “Clear Files & Data” under Elementor › Tools (“Regenerate CSS & Data” in older versions) regenerates style files. Then check these layers:

• The caching plugin’s option to clear all cache, such as LiteSpeed Cache or WP Rocket
• The hosting company’s server cache
• The cache of a CDN such as Cloudflare, if used
• CSS and JavaScript combining/minification settings; temporarily disable and test these settings after the update
• Browser cache; a private window bypasses this layer

If cleanup fixes the design, there is no persistent error. If it does not, examine version compatibility between the page builder and plugins working alongside it.

Random updates or testing in a staging environment?

Testing an update in a staging environment, a copy of the website, rather than on the live site catches breakage before visitors see it. Many hosting companies offer one-click staging copies through their panels; the WP_ENVIRONMENT_TYPE setting introduced in WordPress 5.5 also allows an installation to be marked as “staging.”

An update that causes no problems in staging is applied to the live site in the same sequence. The copy must be blocked from search engines and have a separate address to avoid confusion with the live site.

How should automatic updates be managed?

Rather than disabling automatic updates entirely, manage them per component: leave them enabled for security-critical, reliable plugins, and update components with a deep impact on the site manually after testing. According to WordPress’s Plugin and theme auto-updates documentation, since WordPress 5.5 this setting can be enabled or disabled individually through the “Automatic update” column on the Plugins screen and the link in the theme window.

According to the same documentation, WordPress runs automatic updates twice daily by default and emails the administrator about successful or failed attempts. For core, the upgrading documentation states that new installations since WordPress 5.6 automatically update both minor and major core versions by default. The WP_AUTO_UPDATE_CORE constant in wp-config.php can be set to ‘minor’ to allow only minor versions.

A protection introduced with WordPress 6.6 is also worth understanding. According to the core team’s rollback announcement, if an automatic plugin update causes a PHP fatal error on the homepage, the previous version is restored and the administrator is emailed. This protection covers only automatic plugin updates; it does not catch shifted designs or breakage that produces no fatal error.

Pre-update checklist

Most update-related failures can be prevented through a few minutes of checks before updating. We follow this list before every update round in our maintenance process:

1. Back up files and the database, and check that the backup can be opened.
2. Read release notes for the plugins being updated; flag major version jumps separately.
3. Compare “Tested up to” and “PHP version” information on plugin pages with server versions.
4. Check for direct code changes in the parent theme; move them to a child theme if present.
5. Perform updates in staging if possible, or during low-traffic hours if not.
6. Update in groups rather than all at once; check the site after every group.
7. Test critical pages such as the homepage, contact form, cart, and checkout.
8. Clear the cache and check the result again in a private window.

The upgrading documentation also recommends disabling plugins before manually upgrading core. This step is not required for ordinary dashboard updates; the main protection comes from backups and proceeding in stages.

Common mistakes during a failure and the correct method

During update failures, the greatest damage comes from hasty attempts to fix the problem. Common mistakes and the appropriate alternatives are as follows:

• Deleting the plugin through the panel: With some plugins, deletion also removes settings; the correct route is to disable it first or rename its folder.
• Attempting rollback without a backup: Every attempt made without backing up the broken state removes a point you could return to.
• Downloading old versions from unknown websites: Obtain the previous version only from the plugin’s official page or the developer’s account; modified files may contain malicious code.
• Disabling automatic updates entirely and forgetting them: Plugins left without updates turn into security vulnerabilities over time.
• Updating everything simultaneously: When a problem occurs, it becomes impossible to tell which update is responsible.

If unfamiliar redirects, new administrator accounts, or strange files appear after an update, the problem may be a security breach rather than incompatibility. In this case, instead of rollback, a hacked site recovery process is required.

When should you consult a specialist if a WordPress site breaks after an update?

If a site broken after an update cannot be fixed within 30 minutes by addressing a single plugin or clearing cache, specialist support saves time. Intervention should be systematic especially when there is no current backup, orders have stopped on an e-commerce site, the error log cannot be read, or the problem appeared alongside a PHP version change.

For one-time failures, the WordPress troubleshooting service diagnoses and resolves the problem. If you want updates performed regularly with backups and testing, the annual WordPress maintenance and updates service makes this an ongoing process. WordPress maintenance costs 500–2,000 TL per month depending on the site’s size and scope.

Under the maintenance arrangement, a backup is taken before each update round, critical pages are checked afterward, and the actions performed are recorded. This means that when another failure occurs, which update was performed and when can be read from records rather than guessed.