WordPress plugin auditing

I would compare a plugin audit to a health check. Or a vehicle inspection. It’s a process designed to find and fix misconfigured plugins to prevent a collapse or crash.

When and why to audit plugins

Plugin auditing has several goals, all aimed at keeping the site running efficiently and the software up to date. We also think it’s important to avoid having any inactive software on the site (which can cause problems). So the goal is to:

• remove plugins that are unnecessary, increase risk and slow down the site,
• replace old, nonfunctional or completely unsuitable plugins with more suitable ones or possibly with a snippet (a mini-plugin for your WordPress site, providing added functionality without the clutter),
• activate unlicensed plugins with a valid license or remove them,
• add plugins that we consider important and have on the site for good reasons.

We (in our company) perform audits both on customer’s order („I have a lot of plugins, can you check if they are all needed?“), and on our own initiative – before acceleration, when taking over the site into maintenance or on any other appropriate occasion (we just don’t like clutter on the site and we try to explain to the site owner that the deficiencies should be removed).

How the audit itself works

We usually use the cloned version of the website because “everything comes with a price”. But it’s not necessary, with a responsible approach it can be done on a real site.

First, we compile the list of plugins into a table that has approximately the following columns (depending on the complexity of the site and the personal creativity of the technician):

• the name of the plugin,
• location (sometimes there are two columns – for production website and for development copy, because the plugin may be needed for the next stage of work, but it will be removed at the end of the day),
• plugin features, categories,
• current state (sometimes the plugin is not functional, but it is still on the site),
• amendment proposal,
• confirmation of the change by the customer,
• comment

The spreadsheet is sent to the customer with instructions to comment on the red notes if they can. If not, it is our responsibility. Every customer or site owner has a different approach, some are very interested in what we want to do on their site, some will say they don’t understand and leave it up to us. We take this approach into account and the responsibility is always ours. Even discussing why plugins X or Y need to be removed isn’t something we’re afraid to do.

Candidates for removal

Types of plugins and reasons why we remove them from websites, or we try to find arguments for removal.

• inactive plugins – if they are not used, why should they be on the site?
• one-off plugins, e.g.:
  • searching strings in the database: search and replace, string locator – use once: install, use, delete.
  • export, import plugin: also used once or cyclically, does not have to be on the site all the time.
  • editing user roles (user role editor): checking that it is really needed, would it be possible to edit the rights permanently and remove the plugin?
• abandoned plugins (= no updates), security risk, e.g.:
  • local business services integration – find out if the connected service still operates, if the plugin should be on the site and try to get rid of it
  • plugins uploaded directly from GitHub, plugins removed from wordpress.org repository
• unused/unnecessary/unconfigured plugins, examples:
  • plugin belongs to a template that is not used,
  • Envato account manager (not usually used),
  • cache plugin for other hosting
  • Akismet anti-spam – is it linked to WordPress.com and does it work?
  • Really Simple SSL for redirection to https – fix it directly in the database and set it in .htaccess,
  • WP Page Info, PHP info or other installation information – information will be supplied by Tools > Site Health,
• conflicting or duplicate plugins, examples:
  • plugins for inserting GTM – isn’t the snippet also in the template?
  • GA insertion plugins – does the GTM code also load or is there a duplicate loading of the analytics code?
  • plugins for sliders – more than one?
  • backup plugin (BackWpUp, UpDraftPlus) – does it actually successfully backup the site? Are the tasks properly set up and working?
  • security plugins Wordfence, Solid (iThemes) Security, Titan Security etc. – usually only one is allowed
  • image optimization plugins, e.g. ShortPixel, EWWW Image Optimizer or TinyPNG at the same time, does not over-optimize?
  • more form plugins, are they justified?
  • reCaptcha settings – beware of collisions between places where reCaptcha is loaded
    • form plugins (Contact Form 7, Gravity Forms have their own integration)
    • login forms
    • forms for comments
  • multiple visual builders on one site: Gutenberg, Elementor, WP Bakery, Divi, Bricks, etc.
• improperly selected plugins, examples
  • Loco translate – it is often better to create the translation locally and upload it
  • Classic Editor, Classic Widgets – should they really still be there?
  • Code snippets for inserting snippets – all code should be in the template or provided by a suitable plugin; we don’t want executable code lying around in the backend of the site – it’s cluttered, not very secure and difficult to manage

Each time it is necessary to justify whether the plugin is needed, used, necessary, etc. There is no universally valid conclusion on this. It is the result of an audit.

Pay special attention to custom plugins. Sometimes they can be of poor quality and need to be analyzed to see if we need them, can update or replace them. This may result in a commercial offer to redesign the site.

Replacing plugins

Some plugins take centre stage, yet only add one key function. This could be placed in a child theme via a snippet. If a child theme exists or is appropriate to create – if we direct more customizations to it, its existence makes sense. Another use might be to embed GTM measurement code, authentication code for Search Console, or simply some other external service. (Yes, Search Console is already primarily authenticated by the domain record, but that’s not always feasible.)

TIP. I am a big fan of „tag manager“. The most famous is Google Tag Manager, but I also use Matomo and their MTM. I think all JS codes of external services should go into it, with regards to cookie management it actually makes perfect sense. But that’s academic theory, in practice we take into account the technical capabilities and context of the site.

Examples for plugin exchange.

• WP 404 Auto Redirect to Similar Post – replace by checking in Search Console, redirect using .htaccess or SEO plugin or Redirection
• Disable Cart Fragments – this is a cart cache, can be solved with a snippet
• Admin Columns – edit columns in backend, can be solved by snippet
• Facebook for WooCommerce – can probably be solved with a better plugin or by moving to GTM

If you aren’t a developer and can’t replace the plugin function with your own code, then of course don’t do it, otherwise you’ll create more problems than you’re trying to solve.

Addition of suitable plugins

We add some plugins when we take over the site on a monthly/annual basis. Others we activate temporarily – for a specific period of time. Most of them serve one purpose and we remove them again when the work is done (unless otherwise agreed). Examples:

• Activity Log (we keep)
• Better Password Hashing (we keep)
• Email logging (temporary)
• We use Query Monitor or other debugging plugin quite often, we reactivate it as needed,
• export, import of data, templates, configurations, etc.
• we do not install licensed plugins unless the customer is a license holder!

Somewhat different is when it’s a paid order, i.e. we don’t set the plugin automatically, but based on the order:

• security plugin
• spam protection
• setting cookies, GTM, …

Benefits of plugin auditing

The aim of the audit is to critique the plugin configuration and suggest changes. It is necessary to know the processes of the site and think through the impact of the decision. Don’t be afraid to question the current configuration if you have an argument for improving it.

• Why do you have the Classic Editor plugin on your website?
• Why do you have four „addons for Elementor“ plugins? Are all widgets really used? What page do we find them on?
• Can we unify the measurement snippets into GTM?
• Are you actually using Mailchimp, creating FB audiences and tracking those stats in MonsterInsights/Site Kit?
• Is WPML or Polylang really needed to translate five strings? (Both of course are not intended for translating user strings, it’s just a rubbish at the end

So keep it fast and keep your sites tidy.