Resetting WordPress: Methods and tips

WordPress is the world’s most widely used content management system (CMS). Using WordPress makes building a website much easier. From a vast selection of plugins and themes, you can put together the desired functionality and the right look. Within five minutes you can have your own site online.

Despite its apparent simplicity, it is easy to get bogged down when creating a WordPress site. Then the site stops loading properly or just doesn’t work at all. When you’ve had enough, you’ll want to reset the WordPress site and just start over from scratch. What options are there for resetting WordPress and when does it make sense to do so?

WordPress is a flexible Content Management System (CMS). Because the software is so flexible, it’s possible to create completely different sites and apps based on the CMS. Whether it’s a single page scroller, an online shop or a social network, you can find suitable plugins for almost any undertaking. However, the flexibility of WordPress is both a blessing and a curse. If you’re a layman getting entangled in the thicket of mutually incompatible plugins, you might wish for a reset button.

Even as part of the regular administration of a WordPress site, it is sometimes useful to be able to reset at least part of a WordPress site. Most of the time, the need arises when major changes are to be made to the site. There are some common scenarios where it is recommended to reset WordPress. These include moving a WordPress domain to a new host provider (migration), creating a new design (redesign) or relaunching the site under the existing domain (relaunch).

There are also certain circumstances that require a WordPress site to be reset, for example, if the site has been hacked or stops loading after an update (restore/recovery). Sometimes it is also useful to reset parts of WordPress as part of a “spring clean”. Periodically removing idle legacy files increases site security and can lead to improved WordPress performance.

Resetting is most useful in the context of development and test workflows. Ideally, you’d work on a staging site or local dev site. This way you don’t have to worry about any damage the site might sustain.

What do we actually mean when we talk about resetting WordPress? It can actually mean several things. WordPress is made up of four fundamental components:

1. WordPress core files and data
2. WordPress configuration data
3. WordPress database
4. WordPress site data in wp-content files

If you want to reset WordPress, you have to be clear about what exactly you want to achieve. Do you want to remove only the content, or do you want to reset the settings or the WordPress theme to its initial state? Has the site been hacked or moved? Depending on the scenario, different components of the site must be reset.

It’s important to understand that the components are interlocked. If you delete only the database for example, plugins, themes, and uploaded files (uploads) will remain. However, due to the loss of the database, the uploads will no longer show up in the WordPress media library. You will then no longer be able to delete them from WordPress. In this case, it would be appropriate to reset the WordPress uploads folder.

“WordPress core” refers to the folders and files that make up WordPress “at its core”. These are created during the installation of WordPress and changed during updates if necessary. The WordPress developers at iThemes contribute a plausible definition:

Let’s look at the names of important WordPress core files and folders in the WordPress root directory as an example. As a user, don’t touch these folders and files, otherwise you can easily corrupt your WordPress installation:

• index.php
• wp-login.php
• wp-admin/
• wp-includes/
• etc.

If the WordPress core has been corrupted, a reset can be useful. WordPress core corruption is usually caused by improper user access or introduced malware. If the WordPress core was changed by a hacker, it is better to rebuild the site completely from a backup. This guarantees that the malware is eliminated.

WordPress configuration files are a handful of files located in the root directory of the WordPress installation. These store special configuration settings outside the database. The following WordPress configuration files are found in most WordPress installations:

Modifications to WordPress configuration files quickly cause damage to the site. This damage is often immediate; the site stops loading properly. However, subtle damage can also occur that only becomes noticeable after a long time, for example, when the Google ranking of the site drops dramatically.

If there is any damage to the WordPress configuration files, it is highly recommended to restore them from a backup. If you try to trace the damage and repair it manually, you may make it even worse. In such cases, it is possible to reset a corrupted WordPress configuration file to its initial state. However, all page-specific settings will be lost.

The WordPress database contains most of the site’s content and configuration settings. These are stored in individual database tables. Two basic types of tables are used:

1. WordPress core tables, including:
   • wp_posts
   • wp_options
   • wp_users
   • wp_comments
2. Tables from plugins and themes
   • What these are called exactly depends on the respective plugin or theme.

If you remove parts of the database, this may affect WordPress like a reset. It should be noted that there are two ways to reset the WordPress database:

1. Delete database entries (DELETE * FROM <table>)
2. Delete database tables  (DROP TABLE <table>)

It is essential to create a database backup (“Database Dump”) before modifying the WordPress database. Usually, a database dump results in a compressed text file with SQL statement. To reset the WordPress database to a previous state, the Database Dump is imported. In this process, the SQL statements contained are executed sequentially and the data is reconstituted.

There is a pitfall when restoring the WordPress database after reset: If only individual entries were removed during the reset, the database dump must have been exported with DROP TABLE IF EXISTS entries. Otherwise, the restore will fail.

Unlike WordPress core, site data is changeable over time. The site data includes all folders and files in the wp-content folder. Let’s take a look at the most important folders and their relative paths:

• Site data: wp-content/
  • Installed plugins: plugins/
  • Installed themes: themes/
  • Uploaded data: uploads/

Each plugin and theme is in its own folder. If you delete one of these folders, the respective theme or plugin will be removed. If necessary, however, tables and entries should remain in the WordPress database. If you remove the complete wp-content folder, you reset the WordPress site data. You can then start from scratch installing plugins and themes.

There are three basic ways to reset a WordPress site. We’ll discuss these in detail as we go along:

1. Reset WordPress page manually
2. Reset WordPress site using plugins
3. Reset WordPress page using WP-CLI

Many WordPress reset guides found on the web recommend a manual approach with a series of individual steps. Work on the server or the backend of the hosting environment, deleted targeted files and folders and change configuration settings of the WordPress installation as well as the hosting environment. Adjust DNS settings, create a new database or delete tables in the existing database. If necessary, you can make use of special scripts.

In most cases, doing it manually is not the optimal way to reset a WordPress site. Most of the time it is easier to create a new, clean WordPress installation. This is because a WordPress site should ideally be indistinguishable from a freshly installed WordPress after a complete reset.

The manual approach is the most powerful and allows you to reset parts of WordPress with surgical precision – provided you have the right know-how. If you lack the necessary knowledge and experience, it is easy to crash your site. Therefore, it is essential to create a backup before starting work. Even better would be to work on a WordPress staging site. Let’s look at a few scenarios where the manual approach comes into play.

Let’s imagine we have an existing WordPress site under the domain www.example.com. Now we want to start from scratch with a fresh WordPress. Of course, we want to keep the existing domain and the associated search engine authority. A commonly shown approach is to reset the existing WordPress site and then rebuild it under the existing domain. However, this approach is based on an error in thinking.

Remember, a completely reset version should ideally be indistinguishable from a freshly installed WordPress. Therefore, it is better to install WordPress fresh and then direct the existing domain to the new installation. To do that, adjust DNS settings in the hosting backend or domain registrar to associate the domain with the server’s IP address. Then adjust the WordPress site URL and replace all instances in the database with the new URL.

It is often practical to leave the old site in place when relaunching. This way, you can still view content and settings later and transfer them if needed. A good approach is to host the existing site under a subdomain like old.example.com after the relaunch. Similarly, before the relaunch, build the new site under a subdomain like dev.example.com. At the time of the relaunch, swap the two sites:

If you choose this approach, it is essential to create a robots.txt file in the root directory of the old site to hide it from search engines. Otherwise, the duplicate content problem remains, which can have negative consequences for the ranking of the new and old site. In the old site’s robots.txt file, make the following entry:

If you use a commercial or free theme for the design of a WordPress site, you should ideally create a child theme when you build the site. All changes to the theme will then apply to the child theme. Once this approach has been taken, it will be easy to develop a new design in the future.

For the redesign, simply create a new child theme and test it on a staging site until you are satisfied with the result. Then copy the finished child theme into the existing WordPress installation. If you now activate the child theme, you start over with a fresh theme.

But what if no child theme was created? In this case, all changes were made directly to the theme. How to reset the WordPress theme then depends on the theme.

This method is most often found on the web when looking for instructions to reset a WordPress site. This involves manually removing the components of the WordPress site that are variable over time but leaving some (in theory) unchangeable components in place. The site is effectively “gutted” in order to fill it with new content afterwards.

We will show this procedure here for the sake of completeness. The process is no less time-consuming than completely reinstalling WordPress. However, since some WordPress components survive the reset, there is a risk that components from the old installation will cause problems later. Let’s take a look at the process:

1. Create a complete backup of the existing site.

Backup WordPress database and WordPress directory!

       2. Create new database and save access data of the new database.

Create the new database in the hosting backend or use the mysql command on the command line.

It is often recommended to delete the existing database at this point. This is actually unnecessary. It is often better to hold onto the data a little longer. Remove the old database only when you are sure that everything is working.

       3. Empty all content in the wp-content/ folder.

At this point, it is often recommended to delete the wp-content folder completely. On the Linux command line, the following command does this, as long as you are in the WordPress root directory:

It is more practical to rename or move the folder:

WordPress is then no longer able to find the folder and creates a new, empty wp-content folder. At the same time, the original content remains in the _wp-content folder. So, you can still access them to view files and transfer them if necessary.

       4. Reinstall WordPress

To do this, bring up the WordPress address in the browser and add the following suffix: /wp-admin/install.php

Enter the access data of the new database and continue the installation process.

The manual process of resetting a WordPress site is laborious and prone to error. It is better to limit potential influence. If there are only a few, well-defined paths, it’s harder to make mistakes. WordPress reset plugins do just that. We present “WP Reset” plugin in detail here.

For most users, WP Reset is the easiest and most direct way to reset a WordPress site. The plugin has an intuitive web interface and offers a good level of functionality. The plugin conveniently allows you to create a snapshot of the WordPress database. This is how you can undo a reset. Beware: The snapshot contains only the database; files are not backed up! So, you still have to make a complete backup beforehand.

The “WordPress Command Line Interface” WP-CLI is a good tool for WordPress admins. You can control WordPress from the command line with it. The software combines operations on file system and database under one consistent interface. This can be used to reset a WordPress site with WP-CLI, among other things.

Command line tools are useful because they allow you to standardize work steps. Using the command line makes processes reproducible and allows them to be encapsulated as scripts. Using WP-CLI is quicker and less risky than doing it manually.

Using WP-CLI requires SSH access to the server running WordPress. A solid approach to working with WP-CLI is to first try out each step on a staging site. You can execute commands and document them in a text file. If the result is successful, the tested commands will be executed in the correct order on the live site.

Let’s consider some useful WP CLI commands that help to reset a WordPress site:

Using a plugin is easiest but it requires a working WordPress. Plugins could stop working, for example, if the database is unresponsive, the WordPress core has been corrupted, or there is a server error. In addition, the use of a plugin allows for less detailed potential influence than the other two methods.

Using WP-CLI offers a good compromise between power and user-friendliness. However, to use WP-CLI, the software must be present on the server. You also need SSH access to the server. WP-CLI may also refuse service in some circumstances. This happens, for example, in the case of a version conflict between the WordPress installation and the installed WP-CLI or if PHP fails completely on the server.

The manual method is powerful and always works as long as you have access to the server or the resources located on it. Besides SSH, access can be made via (S)FTP, cPanel, and phpMyAdmin. As powerful as the manual method is, it also requires the greatest skill. If you lack the necessary knowledge, you can quickly cause a lot of damage.

To summarize, we will assess the three approaches as follows: