How to clean part of your database with the Redirection plugin

You may already know that I am an unconditional fan of the Redirection plugin, as it has proven to be the best plugin for such important SEO work as redirection management.

But if we also add other tools that it incorporates, it is unbeatable and will save you from installing other plugins:

• 404 error manager
• Enable and force HTTPS
• Define the URL of the site with or without www
• Add security headers

Of course, it also has its not-so-good things, if you are not careful and do not use it properly. One of them is that it can fill your database, adding hundreds of megabytes or even gigabytes to several of the plugin tables, and this could cause performance problems, even crashes, of your website.

So let’s see which Redirection plugin tools if mismanaged, can unnecessarily fill your database…

Specifically, we are going to control the size of the 4 tables that the Redirection plugin adds to our database:

• prefix_redirection_404
• prefix_redirection_groups
• prefix_redirection_items
• prefix_redirection_logs

Time of duration of logs

The first thing you should control is the duration time of the different logs that the plugin makes, but above all, it does not make sense to store information logs that you are not going to review with a frequency according to the duration time of the same.

For example, why keep the 404 error log for 1 month if you never check them or if, on the contrary, you check them daily? In that case, saving them for a week would be much more logical, wouldn’t it?

My recommended configuration would be this:

• Redirect logs (one week) – No need to keep them longer, it doesn’t affect whether your redirects work or not.
• 404 Logs (one week) – Here it depends on how often you check and manage 404 errors, but if you don’t do it at least once a week, to resolve 404 errors, you might as well not even use this feature, although it would be a waste, because of the SEO penalties due to 404 errors.
• IP logging (deactivated) – Usually do not contribute anything, if you are not going to investigate each IP, it will fill the plugin tables with more information and it is also contrary to privacy laws.
• Logging of external redirects (disabled) – Totally unnecessary.
• Track redirect visits (optional) – Enable this if you are going to analyze what redirect visits do, otherwise disable it.
• Capture HTTP header information (disabled) – Hardly ever used and greatly increases the size of the tables.

Where to store redirects

One of the less obvious settings for Redirection users is that you can choose where to store the redirects, and the options are as follows:

• WordPress database
• Apache configuration file
• Nginx configuration file

To specify where you want your redirects to be stored, both the automatic ones made by the plugin and the ones you create manually, you must go to the “Groups” tab of the plugin settings, and edit each group of redirects and choose the module where to store them.

My advice is to save them in Apache or Nginx, for 3 reasons:

• It only adds lines of text to the configuration file, while in WordPress it adds several rows of data to each table.
• The redirects are independent of the plugin, they are standard programming, so you can save them and use them without the plugin.
• The redirects from the server are always loaded, and always before WordPress, which avoids waiting times for the bots, or even not being loaded due to loading errors of WordPress, the database or even plugins or the theme.

So my recommendation is that you edit your redirect groups and activate the Apache or Nginx module (whichever you use, usually Apache).

Then go to the plugin options tab and manually add the path to the .htaccess file, in the case of using the Apache module, so that the plugin knows where to add the redirects because without this setting your group settings will not work.

You must add the full path to the .htaccess file, for example:

/home/www/etc/users/yourwebsite.com/public_html/.htaccess

Save the changes and your redirects will be saved in the most optimal place.

Mass deletion of logs

If you have followed my previous advice the Redirection plugin tables in the WordPress database will never grow out of proportion, but you may find yourself in the situation where you already have thousands of previous logs, from a not so efficient configuration.

How do you empty these logs?

Let’s say, for example, that you want to empty the 404 errors, because it contains thousands of logs that, reasonably, you are not going to be able to manage in a reasonable time, and you prefer to concentrate on the current and most frequent 404 errors.

Going from log page to log page would be a long and tedious task, but the plugin gives you the option to select all existing logs, and then apply batch actions to them, such as deleting them.

The process is simple:

• Check the full select box for all rows of logs.
• Click on the “Select all” link next to the log’s page navigator
• Select from the bulk actions on the screen the “Delete” option, click “Apply” and confirm the action.

Conclusions

The Redirection plugin can be the best SEO tool for your website next to your favorite SEO plugin, and for free, but if you also configure it correctly you can control the health of your installation, consume only the necessary resources, and offer the best possible performance.

With a correct configuration and maintenance of the information managed by the plugin on redirects, 404 errors and registrations we can improve the SEO of our site without compromising the performance of the web.