NGINX Let’s Encrypt Certbot Manual Installation

If you’re trying to update an outdated SSL certificate or even if you’re installing one for the first time and you don’t trust Certbot to modify your NGINX config for you then this article is for you.

Install Certbot

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx

Download Certificate

The downloaded certificates and all other Let’s Encrypt/Certbot files will be written to /etc/letsencrypt

# The "certonly" flag is important it tells Certbot to only download the certificates
# and not to install them automatically by modifying your NGINX config

sudo certbot --nginx certonly

You will receive the message below after successfully running certbot

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

Manually Install Certificate

This was my old config with the outdated certificate.

server {
  listen 80;
  return 301 https://$server_name$request_uri;

server {
  listen 443 ssl;

  ssl on;
  ssl_certificate /etc/nginx/ssl/canbyedfoundation_org-bundle.crt;
  ssl_certificate_key /etc/nginx/ssl/;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_redirect off;

To update the config I simply had to change the path to ssl_certificate and ssl_certificate_key

server {
  listen 80;
  return 301 https://$server_name$request_uri;

server {
  listen 443 ssl;

  ssl on;
  ssl_certificate /etc/letsencrypt/live/;
  ssl_certificate_key /etc/letsencrypt/live/;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_redirect off;

Verify Config File & Restart NGINX

sudo nginx -t && sudo nginx -s reload

React Native Publishing an Android App

Add/Create Keystore

This command will create a keystore with the given name if the file doesn’t exist or append a key to a current keystore.

keytool -genkey -v -keystore mykeystore.keystore -alias mykeyalias -keyalg RSA -keysize 2048 -validity 10000  

After you have generated the mykeystore.keystore file copy it to android/app.

Setting up gradle variables

Append the snippet below to android/ and add the correct values.


Adding signing config to your app’s gradle config

Edit android/app/build.gradle so it looks similar to the one below.

android {
    defaultConfig { ... }
    signingConfigs {
        release {
            storeFile file(MYAPP_RELEASE_STORE_FILE)
            storePassword MYAPP_RELEASE_STORE_PASSWORD
            keyAlias MYAPP_RELEASE_KEY_ALIAS
            keyPassword MYAPP_RELEASE_KEY_PASSWORD
    buildTypes {
        release {
            signingConfig signingConfigs.release

Add the siginingConfigs snippet right below but not in defaultConfig and then append signingConfig signingConfigs.release to buildTypes -> release.

Generating the release APK

cd android && ./gradlew assembleRelease

Testing the release build of your app

cd android && ./gradlew installRelease

Where is my bundled app?

The file you want to upload to the Google Play Store is android/app/build/outputs/apk/app-release.apk

Update version number for each build

In android/app/build.gradle increment:

versionCode 2
versionName "2.0"

Helpful Commands

# List aliases within a keystore with this command:
keytool -list -keystore mykeystore.keystore

How to setup NAT on Proxmox

Proxmox uses bridge networking to provide Internet access to virtual machines, but in a bridge networking you need a public IP for each machine. If you have limited IPs you can use NAT to access Internet on your machines. How ever it is preferable to have a static public IP if you are running public services like apache web server. Today we will see how to setup NAT on proxmox to provide private network for virtual machines.

Step 1: Create a bridge

Login to your proxmox host ssh, and run:

nano /etc/network/interfaces

This is your network configuration file for proxmox, you might see one bridged interface already configured (bridged to your physical interface), paste following at the end of your configuration file

  • vmbr2 : This is the bridge name for NAT.
  • vmbr1 : This is the interface that was already configured in your network file, adjust the name properly.
  • : This will be the network we are going to use in our internal network, our usable ips in this network will be:
    • If you plan to use different network, you can use this site to get help.
  • bridge_ports none : Bridge ports here is set to none, since we are not connecting to outside world directly.

You have successfully configured a NAT bridge.

Step 2: Bring up the NAT bridge

You can use this command to bring up the bridge you just created:

ifup vmbr2

This will bring up the bridge.

Step 3: Configure Virtual Machine

As a final step configure your virtual machine to use IP address, since DHCP is not present you will have to manually set IP address. Depending upon your OS you can use following details:

  • IP :
  • Gateway :
  • Netmask :

For further virtual machines you can use these ips:

  • ..upto 254

For DNS you can use google DNS


Step 4 : (Optional) Port forwarding to access from outside world

I am assuming you are working with linux guest. We will access ssh of our guest through public IP of main server.

Run this on proxmox host, we are forwarding host port 3033 to guest port 22. (SSH runs on 22)

Then run following to access guest SSH.

ssh -p 3033

It will ask for the password, once provided you will be successfully connected to guest SSH.

Converting between virtual image formats

qemu-img convert: raw, qcow2, qed, vdi, vmdk, vhd

The qemu-img convert command can do conversion between multiple formats, including qcow2qedrawvdivhd, and vmdk.

qemu-img format strings
Image formatArgument to qemu-img
QCOW2 (KVM, Xen)qcow2
QED (KVM)qed
VDI (VirtualBox)vdi
VHD (Hyper-V)vpc
VMDK (VMware)vmdk

This example will convert a raw image file named image.img to a qcow2 image file.

$ qemu-img convert -f raw -O qcow2 image.img image.qcow2

Run the following command to convert a vmdk image file to a raw image file.

$ qemu-img convert -f vmdk -O raw image.vmdk image.img

Run the following command to convert a vmdk image file to a qcow2 image file.

$ qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2

NoteThe -f format flag is optional. If omitted, qemu-img will try to infer the image format.

When converting an image file with Windows, ensure the virtio driver is installed. Otherwise, you will get a blue screen when launching the image due to lack of the virtio driver. Another option is to set the image properties as below when you update the image in the Image service to avoid this issue, but it will reduce virtual machine performance significantly.

$ openstack image set --property hw_disk_bus='ide' image_name_or_id

VBoxManage: VDI (VirtualBox) to raw

If you’ve created a VDI image using VirtualBox, you can convert it to raw format using the VBoxManage command-line tool that ships with VirtualBox. On Mac OS X, and Linux, VirtualBox stores images by default in the ~/VirtualBox VMs/ directory. The following example creates a raw image in the current directory from a VirtualBox VDI image.

$ VBoxManage clonehd ~/VirtualBox\ VMs/image.vdi image.img --format raw

Migrating VirtualBox .vdi to ProxMox VE

  1. Find your VM’s .vdi file – First we need to locate the VirtualBox hard drive (.vdi) file.
    • Open the VirtualBox GUI
    • Click on the VM we want to migrate and click the Settings button
    • Click on Storage and click the .vdi file listed under IDE Controller
    • Mouse over the Hard Disk: dropdown list box and note the path to the .vdi file
  2. Convert the .vdi to .img – Next we need to convert the hard drive to a RAW format for ProxMox
    • On the VirtualBox host open a command prompt
    • Run
      VBoxManage clonehd --format RAW [virtual_harddisk].vdi [virtual_harddisk].img
    • This may take a while so be patient. Go get some coffee.
  3. Create a new ProxMox VM – Next we need to create a Proxmox VM to hold our drive image.
    • Open up the Proxmox web interface
    • Click on Virtual Machines then click the Create tab
    • Leave all of the defaults. My Disk space (GB): was set to 32GB and my original .vdi was 20GB. This seems to have worked OK. I’ll edit if there are problems down the road.
    • Note the VMID: number of your new VM (i.e. « 106 »)
  4. Upload the .img file – now we need to upload the new /img file to the Proxmox server.
    • Start your file transfer softare (wither WinSCP or Filezilla are two good ones).
    • Transfer the .img file to the /var/lib/vz/images/106 folder (replace 106 with the number you noted from the VMID: field
  5. Rename the .img file – now all we need to do is rename the .img file
    • rename the existing .raw file (for instance vm-106-disk-1.raw) to .old
    • rename the .img file to the name of the existing .raw file (for instance vm-106-disk-1.raw)
  6. Boot it up!

Improving Website Performance – Enabling Keep-Alive

How does Keep-Alive work?

In this tutorial you will learn 4 different methods to enable keep-alive. Keep-Alive allows a visitor’s browser to download all the content (such as JavaScript, CSS, images, videos and etc.) through a persistent TCP connection instead of making different requests for each file. This will provide a speed and performance boost as your visitor’s browser will be able to get everything through a single, persistent HTTP connection. In short, Keep-Alive is a communication pattern between a web server and a browser with the potential to drastically reduce request amount and speed up a web page. Here is a picture that will help in understanding the difference and benefits of Keep-Alive:

Advantages of enabling Keep-Alive:

  • Keep-Alive reduces the usage of CPU and memory due to a smaller amount of generated HTTP requests. This will benefit all hosting platform users (free hosting, shared hosting, VPS)
  • Enabling Keep-Alive provides HTTP pipelining (delivery of requests via same TCP connection)
  • HTTPS requests need more CPU time and resources. Keep-Alive will greatly benefit your website if you use HTTPS and SSL.
  • Reduced latency and overall increase in loading speed and performance.
  • Keep-Alive is supported by all modern browsers
  • Enabling Keep-Alive will also benefit your website in terms of SEO and ranking due to better site performance.

In short, Keep-Alive is a great way to reduce your resource usage while increasing your website speed at the same time.

What you’ll need

Before you begin this guide you’ll need the following:

  • Access to .htaccess file
  • Access to httpd.conf (optional)
  • Access to HttpCoreModule (optional)

Step 1 — Analyzing your site

Firstly, you should analyze a website with a tool such as GTMetrix to determine whether Keep-Alive is enabled or disabled on your server. Here are the results after analysis of a test page:

Keep-Alive not fully working

On some servers or hosting providers, Keep-Alive is enabled by default. If your analysis gives a 100% score, there is nothing more that needs to be done.

Step 2 — Enabling Keep-Alive

There are several ways to turn on Keep-Alive and it all depends on your server or hosting provider. Here are a few options:

Option 1 – Editing .htaccess file

To enable Keep-Alive, adding the following code to your .htaccess file should do the trick. Enabling Keep-Alive using .htaccess will override any server settings and enable the persistent connection.

<ifModule mod_headers.c>
Header set Connection keep-alive

This method should work on most Linux shared hosting providers. In case you do not know where to find .htaccess, try referring to this tutorial.

Option 2 – Enabling Keep-Alive in Apache via httpd.conf file

If you have access to the Apache config file, you can enable the extension from there. Here is what the configuration should look like:

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
KeepAlive On

# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
MaxKeepAliveRequests 50

# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
KeepAliveTimeout 10
  • KeepAlive On section enables the extension.
  • MaxKeepAliveRequests section sets the max number of allowed requests for a single connection. 50 requests for one connection is a great place to start.
  • KeepAliveTimeout section specifies how long the server waits for new requests from a client. It is recommended to start with a smaller value such as 5 or 10 seconds and increasing it later if required. Settings this value too high can cause high server load.

If you cannot locate the httpd.conf file, run the following command in the command line:

find / -name httpd.conf

Option 3 – Enabling Keep-Alive in NGINX

Keep-Alive is enabled by default on NGINX, however, in some cases, it can be disabled. You can enable it using HttpCoreModule. Look for the value keepalive_disable, which is in a lot of cases the reason why Keep-Alive is not working. Before enabling it, make sure to know the reason why it’s disabled in the first place before attempting any changes.

Option 4 – Windows Server (IIS)

If you are using a Windows-based server, you can easily enable the Keep-Alive extension using the command line.

The following command will enable it:

appcmd set config /section:httpProtocol /allowKeepAlive:true

And if you wish to disable it, use:

appcmd set config /section:httpProtocol /allowKeepAlive:false

You can also refer to an official tutorial from Microsoft for a few extra options.

Step 3 — Testing the changes

Once Keep-Alive is fully enabled, run another scan with GTMetrix or any other website performance analysis tool to see if everything is working. Here are the results after Keep-Alive has been turned on:

Keep-Alive fully functional

It is also possible to check whether Keep-Alive is functioning by checking your HTTP header. This can be done via terminal using the following command:

curl -I

Here is an example:

curl -i

The results are:

HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Server: nginx
Date: Fri, 23 Dec 2016 18:58:14 GMT
Content-Type: text/html
Content-Length: 178

The Connection: keep-alive part signifies that Keep-Alive is functional.


To sum up, enabling Keep-Alive for your website is a great way to improve speed and performance. The persistent TCP connection will ensure faster load times and higher efficiency, thus keeping your visitors happy.

Proxmox Networking

This time, I would like to show how Proxmox networking configuration can be configured. In my last post, I showed, how to install Proxmox and get ready to create VM’s. I will show a typical configuration, which I always use. The official documentation can be found here:

Proxmox Network Model

I will show, how to configure the network connection for the Proxmox host itself and how to separate the VM traffic from the host traffic using VLAN’s.

Proxmox Networking: Management Traffic

To use the Proxmox host, you must be able to manage it somehow. If you have only one network interface, as I in my test lab, you can use the native network interface for the management and guest traffic. There is no spacial configuration needed. If yo have more than one network card I would recommend to use one for the host management and the other(s) network card(s) for the guest traffic.

Proxmox Networking: Bridged VM Traffic

This type is used to directly connect the VM’s to your network. If you have two or more network cards in your system, you should use a different network card then the one used for management traffic to separate the guest traffic from the management traffic.

To create a bridged networking, you have to create a virtual network card. You can use the web GUI of Proxmox for this, but I prefer to use the CLI. Login to your host, using ssh and open this file:

vi /etc/network/interfaces

Just create a new virtual network interface by adding those lines:

auto vmbr1
iface vmbr1 inet manual
 bridge_ports eth1
 bridge_stp off
 bridge_fd 0

This will create “vmbr1” which is bound to the “eth1” interface. I will not assign an IP address to the “eth1” or the “vmbr1” interface. This way, the guest VM’s are not able to connect to the host directly.

If you have no separate interface, you can either bound the virtual network card to the available interface like this:

auto eth0
iface eth0 inet static

auto vmbr1
iface vmbr1 inet static
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0

You have to assign the IP address which is used for “eth0″ to vmbr1”.

You can also use VLAN’s to separate the traffic, even if you only have one network interface. This can be configured this way:

auto vmbr1
iface vmbr1 inet manual
 bridge_ports eth0.10
 bridge_stp off
 bridge_fd 0

Creating “vmbr1” and binding it to “eth0.10” will create the tagged VLAN 10 on “eth0”. You have to configure the Switch port with the same setting. All VM’s bound to this virtual bridge interface, will be placed into VLAN 10.

Proxmox Networking: Host Only Network

If you need to connect VM’s directly on the host, without sending the traffic to the external world, you can use host only networks. You have to create another virtual bridge interface, but this time, you did not have to bind it to a physical network interface.

Open this file again:

vi /etc/network/interfaces

Add the following lines to the file:

auto vmbr1
iface vmbr1 inet static
 bridge_ports none
 bridge_stp off
 bridge_fd 0

All VM’s connected to this interface will be able to talk to each other. They will not be able to connect to the external world using this interface.

Proxmox Networking: Routed Networking

If you would like to hide your VM’s behind the host IP you can use a routed networking configuration. You have to create another virtual network interface and enable routing on this interface.

Open this file again:

vi /etc/network/interfaces

When working with a routed configuration, you need to enable proxy arp on the outgoing interface. In my scenario, this is “eth0”:

auto eth0
iface eth0 inet static
 post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

To create the virtual interface and enable routing add those lines:

auto vmbr1
iface vmbr1 inet static
 bridge_ports none
 bridge_stp off
 bridge_fd 0
 post-up echo 1 > /proc/sys/net/ipv4/ip_forward

The last line will enable routing on the interface. With this configuration the VM traffic will routed using the routing table of the host. The outside world needs to know, how to reach the “” subnet. To avoid working with static routes, you could NAT the traffic. This will hide the “” subnet behind the IP address of the Proxmox host. To enable the NAT function add those lines to the virtual network interface:

post-up iptables -t nat -A POSTROUTING -s '' -o eth0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s '' -o eth0 -j MASQUERADE

This will enable the NAT function for the internal network “” by using “eth0” as the egress network.

From my point of view, this describes the three main Proxmox networking options. There are other options, e.g. using a virtual switch or router on the host.

Install Proxmox on Debian Wheezy

In this post, I would like to show how to install Proxmox on debian Wheezy. Proxmox is a web-based GUI for KVM. I use this in my LAB for all the software related testing. It is free, but you can also get commercial support. It is one of those great open source tools.

Check Requirements

Before you can start the installation, you should check if your host is able to install Proxmox. You should have the latest version of Debian Wheezy, Debian Jessie is currently not supported by Proxmox.

You should also check, if your CPU is able to run KVM based virtual machines. You have to enable “vmx” “Intel VT-x” for Intel CPU’s and “svm” “AMD SVM” for AMD based CPU’s. Afterwards you can check if it is enabled by looking into /proc/cpuinfo

grep --color vmx /proc/cpuinfo


grep --color svm /proc/cpuinfo

For an intel CPU it could look like this:


I do not have any AMD based system to get a sample output, but it should look similar.

You should also make sure, that you have the correct settings in your hosts file. It should look like this: localhost proxmox.hpn.local proxmox

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

If you can make a check mark on the above requirements, head over to the next step.

Install Proxmox

To install proxmox on your system, you have to add the repository to your source list:

vi /etc/apt/sources.list

Add the following line:

# PVE repository provided by, only for installation (this repo will stay on 3.1)
deb wheezy pve

Before you can use this repository, you ave to import the repository key:

wget -O- "" | apt-key add -

Update your system:

apt-get update && apt-get dist-upgrade

This will fetch the information from the added repository and install the proxmox kernel.

If not automatically done with the update above, install the Proxmox kernel:

apt-get install pve-firmware pve-kernel-2.6.32-26-pve

Now, the tricky part starts. If you have no physical access to the server, you need to be very careful with the next step. It could happen that you machine will not boot correctly.

You have to configure grub that way, that the Proxmox kernel is loaded automatically. During the installation of the Proxmox kernel, you will see those lines:

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve

This will tell, which options are available at the boot screen. The default value for grub is “0”. This means, that the first line is option “0”. You should boot line number “3”, which means we need to tell grub to use option “2” for default. To change the default option open this file:

vi /etc/default/grub

Look for this entry:


I have to change it to “2”:


Save the file and update grub with the new configuration:

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve

Using this command will also bring up all boot options, if you missed it in the first place.

You can now reboot your system.

If you system is back online, you can check if the correct kernel was booted by:

uname -a
Linux 2.6.32-26-pve #1 SMP Mon Oct 14 08:22:20 CEST 2013 x86_64 GNU/Linux

The important part is “-pve”.

You can now remove the debian default kernel by:

apt-get remove linux-image-amd64 linux-image-3.2.0-4-amd64 linux-base

If you do so, you have to change the grub configuration again.

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-26-pve
Found initrd image: /boot/initrd.img-2.6.32-26-pve

For me, it is now “0” again.

The last step, is to install the rest of the Proxmox files:

apt-get install proxmox-ve-2.6.32 ntp ssh lvm2 postfix ksm-control-daemon vzprocps open-iscsi bootlogd

This will install a lot of packages.

You can now remove the Proxmox repository from your source list again. If you do not have a commercial support contract you have to remove the commercial repository from your system. Therefore open this file:

# vi /etc/apt/sources.list.d/pve-enterprise.list

and remove those lines:

deb wheezy pve-enterprise

and add those lines:

# PVE pve-no-subscription repository provided by, NOT recommended for production use
deb wheezy pve-no-subscription

Update the system to the latest Proxmox version:

# apt-get update && apt-get dist-upgrade

As this will install a newer kernel version, reboot the last time.

You can now access the GUI of Proxmox by using this url:


You can use your root credentials, to login to the system.

The next step would be to create networking for the VM’s. I will write a post about the network configuration next time.

10 Tips to Get a 100% Site Health Score in WordPress 5.2

WordPress 5.2 added a new Site Health score to your WordPress dashboard and, as with any score, that probably has you wondering how to get a perfect, 100% score.

In this post, we’re here to help. First, we’ll introduce you to what the new Site Health feature is. Then, we’ll take you through ten tips you can follow to score 100% on your Site Health in WordPress 5.2.

How the Site Health score works in WordPress 5.2

The Site Health functionality in WordPress 5.2 adds robust tools that help you identify potential issues and make it easy for you to fix your site if something goes wrong.

The Site Health tool runs a series of tests and then shares results and recommendations with you based on what it finds.

What’s even better is that the tests are filterable, and plugins and themes can add their own tests or remove existing ones.

Once you update your WordPress website, you’ll find two new pages under Tools > Site Health.

Tips to get 100% site health score - dashboard screenshot

The first page displays your Site Health Status with results categorized as:

  • Critical
  • Recommended
  • Good

These tests are what WordPress uses to calculate your Site Health Score. Needless to say, the critical tests weigh more heavily, and not faring well in them can dampen your chances to get 100% Site Health score.

site health score

The health check results show critical information pertaining to both performance and security. The performance checks include checking for:

  • WordPress version
  • Latest PHP version
  • SQL server version
  • Installation of recommended PHP modules
  • UTF8MB4 support
  • Scheduled events
  • Working HTTP requests
  • REST API availability
  • Performing loopback requests

The security checks include:

  • Active themes
  • Up to date plugins
  • HTTPS connection
  • Secure communication
  • Debug mode off
  • Communication with
  • Background updates enabled

The second page is the Site Health Info page that contains a load of information related to your site health. There’s a convenient button here that can copy all the information to your clipboard so that you can share it with a developer who’s supporting you. For example, if you’re asking a plugin author for help, this gives you a convenient way to provide them with information about your site:

SIte health info

Ten tips to get a 100% Site Health score in WordPress 5.2

Now that you know the checks that WordPress runs to assess your website, here’s what you can do to get a 100% Site Health score.

1. Keep WordPress up to date

We’ve heard this often enough, but in practice, not many of us pay attention to the update notifications that appear with (annoying!) frequency on our dashboard for major updates. Fortunately, updating WordPress is now just a one-click affair. By default, minor changes happen automatically.

Update WordPress

And while it’s possible to disable background updates, it’s really better not to do so.

The test results will let you know if your site is up to date and if it’s communicating with For the best way to run these updates, check out our guide on how to safely update WordPress.

2. Keep themes and plugins up to date

Don’t stop with updating the WordPress core. Go the whole distance and update all the themes and plugins as well. You can update these extensions from the regular WordPress updates area (Dashboard → Updates), as well as the respective Themesand Plugins areas:

Update plugins

3. Remove unused themes and plugins

Beyond updating themes and plugins that you are using, you’ll also want to remove any themes and plugins that you are not using. Themes and plugins that are not updated are a security risk, which is why it’s safer to remove them.

There is one exception, though – leave the latest default theme installed, even if you’re not using it (e.g. Twenty Nineteen).

4. Use the latest SQL server version

Your database server’s software is what powers the database that WordPress uses to store your content and settings. There are two common options, depending on your host’s configuration:

  1. MySQL
  2. MariaDB (a fork of MySQL)

To improve your site’s performance and security (and Site Health score), you’ll want to make sure you’re using the latest version – WordPress recommends running MySQL version 5.6+ or MariaDB version 10.1+.

If you’re not sure how to do this, the best way to get started is to reach out to your host’s support.

5. Upgrade to the latest PHP version

PHP is the programming language that powers much of WordPress’ functionality.

Upgrading to the latest version offers big performance improvements, as well as better security (because older versions no longer receive security updates).

Currently, WordPress recommends that you use PHP 7.3+.

Many WordPress hosts give you an option to choose your PHP version from your dashboard. Or, you can reach out to your host’s support for help.

6. Make sure debug mode is turned off

WordPress has a few built-in debugging tools that generate helpful messages to developers. The most important tool is WP_DEBUG in your WordPress install.

However, on a live site, the debug mode should not be turned on because it can reveal a load of information about your website to visitors and is, therefore, a security risk. That’s why WordPress will ding your Site Health score if you still have debug mode turned on.

To configure the debug mode, find this line in your wp-config.php file:

define( 'WP_DEBUG', true );

To turn it off, you can either change true to false, or just delete the entire line.

7. Install SSL certificate and use HTTPS

HTTPS (Secure HTTP) is a method of encryption that secures the communication between your server and the browser of any user visiting your website, and it’s what gets you that trust-building green padlock in web browsers.

Additionally, Google Chrome will eventually start marking all non-HTTPS pages as “Not Secure:”:

Insecure website

To avoid this, and get your Site Health score up, you’ll need to install an SSL certificate and then migrate your site to HTTPS.

Many hosts now offer free SSL certificates via Let’s Encrypt that you can install with a few clicks, or you can find other free and cheap SSL certificates.

8. Leave the REST API enabled

The WP REST API helps your WordPress core communicate with the various web, desktop, and mobile applications on the internet. This helps WordPress work effectively as a content management system, storing and serving up content to be visible on the internet.

By default, the WP REST API is enabled, but some plugins (especially security plugins) and developers will disable it.

However, if you want to get a perfect WordPress Site Health score, you’ll need to leave the WP REST API enabled. Most plugins or tools that disable the REST API will also give you a setting to leave it enabled.

9. Make sure WP Cron is enabled

Normally, WordPress handles a number of routine tasks such as backing up, publishing posts, or checking for updates. This function is handled by the cron job system, a special technology used by servers to handle scheduled tasks or recurring events. Many plugins also rely on the WordPress cron system to carry out tasks, but sometimes they hog most of the resources.

To check if WP Cron is working, you can use the free WP-Cron Status Checker plugin to get a new dashboard widget that tells you its status:

WP Cron

If it’s not working, you can check if the following line is in your wp-config.php file:

define('DISABLE_WP_CRON', true);

To re-enable WP Cron, you just need to remove that line. Or, if that’s not the issue, you can reach out to your host’s support for more help.

10. Install all the recommended PHP modules

PHP modules play an important role in executing the tasks on the server that make your site run. The WordPress core relies on a list of PHP modules to help it execute tasks. If you don’t have a certain module on your server, WordPress will either have to use a more inefficient method for that task, or it might just remove the functionality.

If you’re missing one of the recommended and required modules, WordPress will tell you which module is missing and ding your Site Health Score:

Missing PHP module in Site Health score

To fix this, ask your host’s support if they can help you to install the module.

Don’t stress about your WordPress Site Health score

While it can be satisfying to see a perfect 100% score in the Site Health area, you don’t need to get a perfect score to have a secure, functioning WordPress site, and some developers have expressed views against this new scoring methodology.

Overall, you should definitely fix the critical issues, and try to implement recommended issues. But don’t stress yourself out if you can’t eliminate every single recommended issue.