In 2014, we decided to switch over to the (now) commonly-used HTTPS to encrypt sensitive data that’s being sent across our website. This post describes some useful tips based on our own experiences that might come in handy if you’re considering switching. 

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

A little backstory

Back in 2014 HTTPS became a hot-topic after the Heartbleed bug became public. This bug allowed people with ill intent to listen in on traffic being transferred over SSL/TLS. It also gave them the ability to hijack and/or read the data. Luckily, this bug got patched quickly after its discovery. This incident was a wake-up call that properly encrypting user information over the internet is a necessity and shouldn’t be an optional thing.

To emphasize the importance of encrypting sensitive data, Google Chrome (since January, 2017) displays a clear warning next to the address bar whenever you visit a website that doesn’t encrypt – potential – sensitive data, such as forms.

How do I switch?

Because it’s important that your data is safe, we took steps in 2014 to ensure that we have SSL-certificates across our own websites. If you decide to switch (you really should!), there are a few things that you need to take into account to ensure your website fully works as intended once you’re done.

  • You need to change all your internal links. This also means updating links to assets (where necessary). Make sure to go through your theme and alter references to CSS, images and JavaScript files. Additionally, you can change all your links to start with // instead of https:// which will result in protocol-relative URLs.
  • Ensure your CDN supports SSL as well. We make use of MaxCDN, which allows you to easily set up SSL on your CDN subdomain.
  • There are various levels of SSL that you can choose from, each with their own pros and cons. You will find more information about that later on.
  • Ensure you have a canonical link present in the <head> section of your website to properly redirect all traffic coming in from http:// to https://.

Google also published a handy guide on how to move to HTTPS without massively impacting your ranking, which can be found here.

How does this influence my rankings?

Like stated in the previous section, moving from HTTP to HTTPS can influence your rankings slightly if you don’t plan accordingly. However, after you switch over to HTTPS, your rankings will actually improve over time. Google announced in 2014 that having an SSL certificate will be considered a positive ranking factor, so it’s worth the investment.

To make sure Googlebot can re-index your website more rapidly after the move, make sure you migrate to https:// during low-traffic hours. This way Googlebot can use more of your server’s resources. Just take into account that a medium-sized website might take a while to regain rankings. Have a sitemap? Then Googlebot might be able to recalculate and re-index your website even faster.

Setting up HTTPS & SSL on your server

Generally speaking, hosting providers have a service to allow you to enable HTTPS/order a certificate. There are a few types of certificates you can choose from, which differ in a few ways. Every variant also has their own price tag, so before purchasing one, make sure that you go with a certificate that fits your needs and budget!

If you’re a bit strapped for cash and tech-savvy, go take a look at Let’s Encrypt to acquire a free(!) certificate.

If you run and manage your own web server, there are a few things that you’ll have to enable in your server configuration before being able to use SSL certificates. This tutorial explains what steps to take to get a certificate running on your server.

OCSP stapling

Having to check the validity of an SSL certificate can result in a small hit in loading speed. To overcome this, you can make use of OCSP stapling. OCSP stapling is a feature that enables the server to download a copy of the certificate vendor’s response when checking the SSL certificate. This means that once a browser connects to the server, it checks the validity of the certificate based on the copy on the server instead of having to query the certificate vendor itself, resulting in a significant performance improvement.

Apache

Before enabling OCSP stapling on your Apache server, please check that you’re running version 2.3.3+ of Apache by running the command apache2 -v (or httpd -v) on your server. Lower versions of Apache do not support this feature.

If you went through the process of setting up HTTPS on your server as described in the ‘Setting up HTTPS & SSL on your server’ section, then you should have come into contact with a VirtualHost configuration specifically made for usage with HTTPS/SSL.

In that file, take the following steps:

  1. Inside the <VirtualHost></VirtualHost> section, you should add SSLUseStapling on.
  2. Just above the <VirtualHost></VirtualHost> section, add SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
  3. Check that the configuration is still valid by running apachectl -t. If so, reload Apache by running service apache2 reload.

Nginx

Nginx also supports OCSP stapling. Before editing the server configuration, please check that you’re running version 1.3.7+ of Nginx by running the command nginx -v on your server. Lower versions of Nginx do not support this feature.

If you went through the process of setting up HTTPS on your server as described in the ‘Setting up HTTPS & SSL on your server’ section, then you should have come into contact with an Nginx configuration specifically made for usage with HTTPS/SSL.

In that file, add the following lines in the server {} section:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;

The last line references a file that contains a list of trusted CA certificates. This file is used to verify client certificates when using OCSP.

After adding these lines to the file, check that the configuration is still valid by running service nginx configtest. If so, reload Nginx by running service nginx reload

Become a technical SEO expert with our Technical SEO 1 training! »

Technical SEO 1 training$ 199 - Buy now » Info

Strict Transport Security header

The Strict Transport Security Header (HSTS) is another handy feature that basically enforces browsers to use the HTTPS request instead of the HTTP equivalent. Enabling this feature is relatively painless.

Apache

If you’re running Apache, first enable the Apache Headers module by running a2enmod headers. After this, it’s only a matter of adding the following line to your VirtualHost configuration (in the <VirtualHost></VirtualHost> section) that you set up earlier for HTTPS:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Reload the Apache service and you’re good to go!

Nginx

Nginx requires you to add the following line in the server{} section of your server configuration file:

add_header Strict-Transport-Security max-age=31536000;

Testing

To see if your SSL certificate is working properly, head over to SSL Labs, fill in your domain name and see what kind of score you get.

Redirecting URLs

To ensure requests are properly redirected to the HTTPS URL, you need to add an extra line to you configuration. This way, traffic that tries to visit your website over HTTP, will automatically be redirected to HTTPS.

Apache

In your default VirtualHost configuration (so the one that’s used for HTTP requests), add the following to ensure URLs get properly redirected:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

As with the other changes we made before, don’t forget to reload Apache!

Nginx

In Nginx, change the default configuration file that was used for HTTP requests and alter it as such:

server {
    listen 80;
    server_name your-site.com www.your-site.com;
    return 301 https://your-site.com$request_uri;
}

Don’t forget to reload Nginx before testing these changes.

Conclusion

“Should I switch over to HTTPS?” Short answer: Yes. Using HTTPS ensures that private (user) information is being sent across the web in a more secure manner. Especially if you’re dealing with monetary transactions, HTTPS is a must.

What type of certificate you end up going with, depends on your specific use case and budget. Make sure to properly research your options beforehand.

Read more: ‘WordPress security in a few easy steps’ »

WordPress 4.7.5 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.7.4 and earlier are affected by six security issues:

  1. Insufficient redirect validation in the HTTP class. Reported by Ronni Skansing.
  2. Improper handling of post meta data values in the XML-RPC API. Reported by Sam Thomas.
  3. Lack of capability checks for post meta data in the XML-RPC API. Reported by Ben Bidner of the WordPress Security Team.
  4. A Cross Site Request Forgery (CRSF)  vulnerability was discovered in the filesystem credentials dialog. Reported by Yorick Koster.
  5. A cross-site scripting (XSS) vulnerability was discovered when attempting to upload very large files. Reported by Ronni Skansing.
  6. A cross-site scripting (XSS) vulnerability was discovered related to the Customizer. Reported by Weston Ruter of the WordPress Security Team.

Thank you to the reporters of these issues for practicing responsible disclosure.

In addition to the security issues above, WordPress 4.7.5 contains 3 maintenance fixes to the 4.7 release series. For more information, see the release notes or consult the list of changes.

Download WordPress 4.7.5 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.5.

Thanks to everyone who contributed to 4.7.5.

WordPress has grown a lot over the last thirteen years – it now powers more than 27% of the top ten million sites on the web. During this growth, each team has worked hard to continually improve their tools and processes. Today, the WordPress Security Team is happy to announce that WordPress is now officially on HackerOne!

HackerOne is a platform for security researchers to securely and responsibly report vulnerabilities to our team. It provides tools that improve the quality and consistency of communication with reporters, and will reduce the time spent on responding to commonly reported issues. This frees our team to spend more time working on improving the security of WordPress.

The security team has been working on this project for quite some time. Nikolay Bachiyski started the team working on it just over a year ago. We ran it as a private program while we worked out our procedures and processes, and are excited to finally make it public.

With the announcement of the WordPress HackerOne program we are also introducing bug bounties. Bug bounties let us reward reporters for disclosing issues to us and helping us secure our products and infrastructure. We’ve already awarded more than $3,700 in bounties to seven different reporters! We are thankful to Automattic for paying the bounties on behalf of the WordPress project.

The program and bounties cover all our projects including WordPress, BuddyPress, bbPress, GlotPress, and WP-CLI as well as all of our sites including WordPress.org, bbPress.org, WordCamp.org, BuddyPress.org, and GlotPress.org.

WordPress 4.7.3 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.7.2 and earlier are affected by six security issues:

  1. Cross-site scripting (XSS) via media file metadata.  Reported by Chris Andrè Dale, Yorick Koster, and Simon P. Briggs.
  2. Control characters can trick redirect URL validation.  Reported by Daniel Chatfield.
  3. Unintended files can be deleted by administrators using the plugin deletion functionality.  Reported by xuliang.
  4. Cross-site scripting (XSS) via video URL in YouTube embeds.  Reported by Marc Montpas.
  5. Cross-site scripting (XSS) via taxonomy term names.  Reported by Delta.
  6. Cross-site request forgery (CSRF) in Press This leading to excessive use of server resources.  Reported by Sipke Mellema.

Thank you to the reporters for practicing responsible disclosure.

In addition to the security issues above, WordPress 4.7.3 contains 39 maintenance fixes to the 4.7 release series. For more information, see the release notes or consult the list of changes.

Download WordPress 4.7.3 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.3.

Thanks to everyone who contributed to 4.7.3: Aaron D. Campbell, Adam Silverstein, Alex Concha, Andrea Fercia, Andrew Ozz, asalce, blobfolio, bonger, Boone Gorges, Boro Sitnikovski, Brady Vercher, Brandon Lavigne, Bunty, ccprog, chetansatasiya, David A. Kennedy, David Herrera, Dhanendran, Dion Hulse, Dominik Schilling (ocean90), Drivingralle, Ella Van Dorpe, Gary Pendergast, Ian Dunn, Ipstenu (Mika Epstein), James Nylen, jazbek, Jeremy Felt, Jeremy Pry, Joe Hoyle, Joe McGill, John Blackbourn, John James Jacoby, Jonathan Desrosiers, Kelly Dwan, Marko Heijnen, MatheusGimenez, Mike Nelson, Mike Schroder, Muhammet Arslan, Nick Halsey, Pascal Birchler, Paul Bearne, pavelevap, Peter Wilson, Rachel Baker, reldev, Robert O’Rourke, Ryan Welcher, Sanket Parmar, Sean Hayes, Sergey Biryukov, Stephen Edgar, triplejumper12, Weston Ruter, and wpfo.

WordPress 4.7.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.7.1 and earlier are affected by three security issues:

  1. The user interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it. Reported by David Herrera of Alley Interactive.
  2. WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data. WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Mo Jangda (batmoo).
  3. A cross-site scripting (XSS) vulnerability was discovered in the posts list table. Reported by Ian Dunn of the WordPress Security Team.

Thank you to the reporters of these issues for practicing responsible disclosure.

Download WordPress 4.7.2 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.2.

Thanks to everyone who contributed to 4.7.2.

The Yoast SEO plugin helps you to easily optimize the text of your post. This could definitely result in higher rankings. But unfortunately, green bullets do not magically put you on top of the search results. In this post, I’ll discuss a number of possible reasons why a post doesn’t rank, even though the text has been optimized with the Yoast SEO plugin.

Too much competition

In most cases, the reason a post doesn’t rank on top is because there’s simply too much competition. If you optimize your blogpost for Justin Bieber, chances are high you won’t rank for that term.  Too many sites and blog posts have established themselves in this niche. Your site doesn’t have the authority that some other sites do have. And a large portion of the other sites in this niche are probably also capable of writing SEO-friendly texts. Green bullets won’t help you to rank high in the search results if your niche is too competitive.

Read more: ‘Should you blog about Justin Bieber’ »

If you really want to rank for those highly competitive terms, you should try a long tail keyword strategy. Blog about all the nuances and little variations around the competitive keywords. If these long tail articles start ranking, you’ll be able to rank for more competitive terms as well. Such a strategy requires long-term efforts, but in the end, it will pay off.

Learn how to set up a keyword strategy for your site in our Keyword research training »

Keyword research training$ 99 - Buy now » Info

Technical issues

If your post doesn’t show up in the search engines at all, it could be that there are technical issues that prevent your post from appearing in the search results. Of course, when set up right, Yoast SEO takes care of all technical issues, but you could be running a plugin that interferes with our plugin. And we’ve seen some themes that actually prevent Google from indexing your site.

Hacked?

Always make sure your site isn’t hacked! If a site is hacked, your older posts will decrease in ranking as well. New post won’t rank as easily as they used to do. This will all evolve rather slowly, depending on how much crap is published on your site, without you knowing it. This really happens!

Keep reading: ‘WordPress Security’ »

Internal linking structure

A reason for your post not to end up high in the search engines , could be because other parts of your SEO strategy are not optimized. The structure of your site – the internal linking structure – is a very important aspect of an SEO strategy. Having a clear site structure leads to better understanding of your site by Google. If your internal linking structure is poor, chances to rank high (even though your content might be awesome) are lower. Yoast SEO premium could help you with your internal linking structure. If you want to improve your site structure, you should check out our site structure training.

Read on: ‘Site structure: the ultimate guide’ »

Few external links

If you just started out with your website, your content won’t instantly rank. Not even if all your bullets are green. You’ll need some links from other websites. Google has to know your website exists. In order to get backlinks, you should reach out to other websites. You’ll need to do some PR or link building. Ask them to mention your site or talk about your product and link to your site. Use social media to get the word out!

Content SEO: learn how to do keyword research, how to structure your site and how to write SEO friendly content »

Content SEO$ 19 - Buy now » Info

Green bullets, no ranking?

There are multiple reasons that could prevent a post from ranking. If you optimized it correctly with Yoast SEO, the most common cause will definitely be that the competition in a niche is just too hard. Unfortunately, SEO is a long-term strategy. You just need to have a little patience. In the meantime, there are a lot of other aspects of your SEO (site structure, link building) you can tackle. Try to focus on all aspects of website optimization, try to be that best result. It will pay off eventually!

Read more: ‘The temptation of the green bullet’ »

There are several reasons to move your website to a new domain. Maybe you’ve gained access to a much stronger domain. Perhaps you’re changing direction or you’re rebranding. Or you’d like to start over with a new name and a new site. Assuming you have a good reason for moving your site to a new domain – other then “this name just sounds catchier” – there are some things to consider concerning security and SEO when moving your website to a new domain.

In this Ask Yoast, we’ll answer a question from Anbu Devilhunter:

“If I move to a new domain are there any security measures I should take?

Check out the video or read the answer below!

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

Security measures new domain

Read this transcript to learn more about SEO and security measures when you’re moving your site to a new domain:

“Well, yes. You should make sure that you have your old domain and keep it forever, so that you can keep the redirects from that old domain to your new domain. Because otherwise, at some point, someone else is going to use that old domain and you’ll lose your redirects. So you’ll lose a lot of links pointing to your site.

Any other security measures? Well, yes, everything that you need to do to a good domain. But I’d suggest talking to our friends at Sucuri, and see what they can do for you. We run their web application firewall in front of everything we do and I would suggest you do too.

Good luck!”

Ask Yoast

In the series Ask Yoast we answer SEO questions from followers! Need help with SEO? Let us help you out! Send your question to ask@yoast.com.

Read more: ‘WordPress Security’ »

WordPress 4.7 has been downloaded over 10 million times since its release on December 6, 2016 and we are pleased to announce the immediate availability of WordPress 4.7.1. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.7 and earlier are affected by eight security issues:

  1. Remote code execution (RCE) in PHPMailer – No specific issue appears to affect WordPress or any of the major plugins we investigated but, out of an abundance of caution, we updated PHPMailer in this release. This issue was reported to PHPMailer by Dawid Golunski and Paul Buonopane.
  2. The REST API exposed user data for all users who had authored a post of a public post type. WordPress 4.7.1 limits this to only post types which have specified that they should be shown within the REST API. Reported by Krogsgard and Chris Jean.
  3. Cross-site scripting (XSS) via the plugin name or version header on update-core.php. Reported by Dominik Schilling of the WordPress Security Team.
  4. Cross-site request forgery (CSRF) bypass via uploading a Flash file. Reported by Abdullah Hussam.
  5. Cross-site scripting (XSS) via theme name fallback. Reported by Mehmet Ince.
  6. Post via email checks mail.example.com if default settings aren’t changed. Reported by John Blackbourn of the WordPress Security Team.
  7. A cross-site request forgery (CSRF) was discovered in the accessibility mode of widget editing. Reported by Ronnie Skansing.
  8. Weak cryptographic security for multisite activation key. Reported by Jack.

Thank you to the reporters for practicing responsible disclosure.

In addition to the security issues above, WordPress 4.7.1 fixes 62 bugs from 4.7. For more information, see the release notes or consult the list of changes.

Download WordPress 4.7.1 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.1.

Thanks to everyone who contributed to 4.7.1: Aaron D. Campbell, Aaron Jorbin, Adam Silverstein, Andrea Fercia, Andrew Ozz, bonger, Boone Gorges, Chandra Patel, David Herrera, David Shanske, Dion Hulse, Dominik Schilling (ocean90), DreamOn11, Edwin Cromley, Ella van Dorpe, Gary Pendergast, James Nylen, Jeff Bowen, Jeremy Felt, Jeremy Pry, Joe McGill, John Blackbourn, Keanan Koppenhaver, Konstantin Obenland, laurelfulford, Marin Atanasov, mattyrob, monikarao, Nate Reist, Nick Halsey, Nikhil Chavan, nullvariable, Payton Swick, Peter Wilson, Presskopp, Rachel Baker, Ryan McCue, Sanket Parmar, Sebastian Pisula, sfpt, shazahm1, Stanimir Stoyanov, Steven Word, szaqal21, timph, voldemortensen, vortfu, and Weston Ruter.

WordPress 4.6.1 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.6 and earlier are affected by two security issues: a cross-site scripting vulnerability via image filename, reported by SumOfPwn researcher Cengiz Han Sahin; and a path traversal vulnerability in the upgrade package uploader, reported by Dominik Schilling from the WordPress security team.

Thank you to the reporters for practicing responsible disclosure.

In addition to the security issues above, WordPress 4.6.1 fixes 15 bugs from 4.6. For more information, see the release notes or consult the list of changes.

Download WordPress 4.6.1 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.6.1.

Thanks to everyone who contributed to 4.6.1:

Andrew OzzbongerBoone GorgesChaos EngineDaniel Kanchev, Dion Hulse, Drew Jaynes, Felix ArntzFredrik ForsmoGary PendergastgeminorumIan Dunn, Ionut Stanciu, Jeremy Felt, Joe McGillMarius L. J. (Clorith)Pascal BirchlerRobert D PayneSergey Biryukov, and Triet Minh.

Even if you try your utmost best, chances are hackers will find a way to hack your site. Following our WordPress security article, I’ll show you five things you should do right after you find your site to be hacked. Some of those things you should probably do before it even happens!

1. Understand what just happened

Your site has been hacked. There are a number of ways this can happen. It might be due to poor maintenance (more on that later), or due to bad plugins. Regardless of what the cause is, you’d better prepare yourself. Your website is on WordPress, and because of the huge user base WordPress has, hackers like WordPress as well. I think my personal website is under brute force attack a couple of times a day. Don’t even get me started on the site you are reading now. This isn’t an invitation, but please realize that hackers try to hack your website all the time. You are no exception.

Tony Perez did a webinar about how websites get hacked earlier this year:

A few things that might lead you to believe you’re suffering a hack might include:

  • Google has blacklisted your website;
  • Google search result pages show “This site may be hacked”;
  • Your host has disabled your site;
  • Customers notify you via their local AntiVirus applications;
  • Your website is not behaving correctly or generating odd errors.

There are some free tools available to help you in the process, like the SiteCheck Scanner and Unmaskparasites Security Scanner.

Knowing what happens and realizing that you are vulnerable, is half the battle. Please read our WordPress security article and monitor your website at all times. On top of that, you might want to install a web application firewall and a local application security plugin.

2. Harden WordPress

There are a lot of things you can do, but at least address the following:

  1. Generate new security keys for WordPress. These are in your wp-config.php file and you can generate these here. Copy/paste in your wp-config.php file, save the file and step 1 is done.
  2. Reset your user passwords. Somehow, the hacker managed to hack your site. In a brute force attack, the method is just to guess your username (please don’t use ‘admin’) and password. After a hack, change all passwords just to make sure. Use a unique password with a complex structure. It’s always best to use a randomly generated password instead of a human generated one. Combine upper/lowercase, use special characters and numbers. WordPress helps with that these days. Use a password manager like 1Password or LastPass to store your passwords.
  3. Reinstall the core. Post-compromise, we highly recommend you always remove and reinstall the WordPress core manually. Do not use the update/reinstall feature via your dashboard. Instead, use your favorite FTP/SFTP client and manually replace the files. Attackers like to embed their files deep in your file structures, and a very common place is within the core directories (i.e., /wp-admin/ and /wp-includes/).
  4. Reinstall your plugins. Of course, that sounds drastic. But if you want to make sure no malicious code remains on your website, do a fresh install and hope all the additions and insertions of the hack disappear. We follow strict security guidelines here at Yoast and have our software reviewed by Sucuri on a regular basis. That’s still a best-effort, by the way, but it makes sure we can immediately address any vulnerabilities. All things considered, it’s our job as a plugin developer to do our very best. Unfortunately, not all plugin developers are as strict in this as we are. So reinstalling your plugins might be a good idea.

By the way, you can also find these three immediate actions in the Sucuri Scanner plugin, as Post-Hack recommendations.

Order a website review NOW and get a plugin of your choice for free. We'll even configure it for you!

Get a Yoast website review

3. Keep your website up-to-date

Keeping your site up-to-date sounds like SEO advice: “Dynamic content makes your website rank better”. But please keep in mind that a healthy technical install really protects your website from hacks. Personally, I stay away from plugins without updates in the last two years. There is a reason WordPress.org tells you that. Hackers target vulnerabilities in older versions of WordPress. The version of your WordPress install is in your WordPress readme.html file (so remove that), and sometimes even right in your source code.

The bottom line is to keep both plugins and WordPress up-to-date at all times. Note that this advice goes for activated and deactivated plugins, as these are just as vulnerable. Make sure to update all of your software (after cleaning up your website) after a hack. This way you’ll have all the latest security updates and makes you less vulnerable. Nevertheless, we find lots of sites running old versions of WordPress and plugins during our website reviews.

4. Restore a backup after the hack

Valentin Vesa of Sucuri pointed me to this when discussing the subject with him. Create a backup strategy. Please don’t be the guy that installed Backup to Dropbox or Backup Buddy and has never restored a backup. Make sure you can. Monitor your backups. Store your backups offsite. Plus, you have to test your backups now and then, to make sure all is right.

Solid backups make it possible to quickly restore your website after a hack. It might cost you a few updates, but at least you’ll keep your site up and running. After restoring a backup, follow up on advice number three of this list and make sure to update your WordPress install and all of your plugins.

5. Don’t try this at home

Don’t take security lightly. In most cases, it’s a trade of its own. You are probably not the most capable person to take care of it. Webmasters, web agencies, and business owners have other qualities that matter. If you hire a security company like Sucuri to take care of your website security business, you can focus on the things you are good at.

And yes, quality security services cost money. But think of all the time you are saving not having to worry, or dealing with a hack yourself. To make it even better for you, Sucuri has a nice offer for our readers:

A 25% discount if you purchase a complete security package of Website AntiVirus & Firewall (basic) and pay for a year upfront (currently $199.99 / year). This also goes for any of the higher Firewall plans as long as the payment is made for the year up front.
Use coupon code YOAST252016 at checkout and get a 25% discount :)

All the more reason to prevent your site from being hacked, instead of dealing with security after the hack is already done!

This article was written with the help of our good friends at Sucuri.
Thanks, Valentin and Tony!

Read more: ‘Regular security audits: taking our responsibility’ »