What is a static WordPress website?

Static WordPress - what is it & why use it?

At its heart, WordPress is a highly popular, highly extensible, content management system that powers over 455 million websites.

….yes, isn’t that a big number?

The problem with big numbers

Because WordPress powers so many websites, it makes sense for hackers to focus on finding exploits in WordPress because it affords a big target.

That’s not to say that WordPress is itself is inherently insecure, no. A well looked after, sensibly hosted & maintained WordPress site is very secure. However, the stark reality is this: the Internet is a hostile environment – and if you cannot handle the remote possibility that your website might be hacked, perhaps being online is not for you.

Executable Code

WordPress is an application created in a programming language called PHP. All the clever logic that makes WordPress work (including any plugins you install) is written in PHP code, which then talks to a SQL server. Now I’m not trying to turn you into a programmer, but there is something important you need to focus on here, let’s drill into that…

When you visit the (current*) Glass Mountains website (powered by WordPress), this is what happens:

The webserver receives a request from the client (i.e. you and your web browser). It passes the request to WordPress which then executes lots of PHP code trying to work out what to do with the query, and how to respond to you.

So let’s say you are visiting the Glass Mountains homepage. Lots of PHP and SQL code is triggered because of your visit (including code relating to any WordPress plugins we have installed). The executable code churns away, assembling what it needs to respond to your request.

The response to the request typically takes the form of one or more of the following:

  • HTML code
  • CSS
  • Javascript
  • images etc

If we use nerdy languages these are pretty much ‘static assets‘ that our WordPress/PHP executable code is constructing for us, on the fly.

As you might imagine, WordPress is doing a lot of work to respond to your request, there is a lot of number crunching, and lines of code being run.

Note: this is one reason why you want to be on decent WordPress specific hosting, with a good caching strategy in place to help minimise the effects of all this executable code running – this gets increasingly important as your traffic grows (just get in touch if you need help with any of this).

By exposing so much of this executable code to the Internet at large, holes can be found, that can be exploited by hackers.

Closing the door

We have a lot of experience with hosting WordPress and know that, with all the goodwill in the world, and with all the best practices in place, a WordPress site can still be compromised (i.e. hacked). And when that happens you will be looking at a period of downtime whilst the damage is undone (which may involve rolling back the website to a version pre-the attack (your WordPress backups are working, yes?).

That’s just the price you pay for having the power and flexibility of WordPress at your disposal.

…there is an option though.

Static Assets?

Cast your mind back earlier to when we talked about the static assets that WordPress ends up sending back to the web browser (HTML/CSS/Javascript etc).

These static assets are really the only thing the web browser wants – so why don’t we do this?

Only put the static assets on the webserver; not WordPress etc. That way, hackers no longer have a way to access/leverage executable code as there isn’t any!

Such a move pretty much stops 99% of hacking attempts in the tracks.

But what about WordPress? Where has that gone?

You may have already spotted an issue here. A benefit of WordPress is that it makes doing things like adding pages, changing website content etc very straight forward. If we have replaced our WordPress website with this static one, where does that leave your website admin team? Having to copy and paste HTML code?!


Don’t panic!

The answer is actually that you can have the best of both worlds. The scenario is now:

Your website admin team will access a special, private, protected WordPress site where you can add new pages, change content etc. When your team is happy, they will invoke a process that refreshes the static version of the website. 

So you get all the benefits of WordPress, without the security worries. We have essentially divorced the admin-only WordPress site from the publicly facing, static one.


There is no such thing as a free lunch, so let’s look into some of the downsides of converting your WordPress site to static.

Ok, firstly this approach does not suit every WordPress site. If you are running an eCommerce store in WordPress, or a membership site, or anything with complex or highly personalised functionality – then storing it as a static site may well work. Can you imagine a static site with a shopping basket? It wouldn’t do anything,

However, that said, a huge percentage of WordPress sites are purely highly polished marketing sites, they don’t really have much in the way of functionality – perfect candidates for this approach.

There are some other aspects that need to be bare in mind:

  1. Traditional web forms won’t work
  2. Built-in WordPress search won’t work
  3. Pingbacks etc won’t work
  4. Native WordPress comments won’t work

As I’m sure you’ve worked out for yourself, there are plenty of alternatives and ways around the above ‘issues‘ (e.g. instead of WordPress comments use a client-side approach like Disqus). So none of the above should be show stoppers if you put your mind to it.

One thing you need to be prepared for before you go this route is this: many website admin teams are impatient when it comes to seeing changes they have made in WordPress appear on the frontend of the website – I’m sure you’ve heard about caching before and how that can (seem to) get in the way? Well, publishing to static introduces another step – as long as your website admin team understand there is a slightly more involved workflow to publish (only slightly) then they (and your website users) are free to enjoy the enormous benefits of moving to static.

Oh, added bonus!

Talking of benefits, here is a final one (and it’s a biggie)….

Because your web server is now no longer having to run thousand and thousand of lines of WordPress PHP (+ SQL) code on every page request, the speed of your website is now very fast. Very fast.

This is great news for your website users as they will be experiencing a very responsive website. Furthermore, highly performant websites are fantastic for SEO. Indeed, for many people, the speed benefit alone is worth going this route.

I’m convinced – what do I do next?

Aside from speaking to us, then you may well want to consider Strattic. Strattic is built from the ground up to help with this exact issue (WordPress to static). Plus, they already have some solutions for you re the issues we listed above (search, WordPress comments etc etc). Yes Strattic is a paid-for service but, at the end of the day, you get what you pay for.

Please comment if you have anything to add or get in touch if we can help.


P.s. *I say ‘current’ was we may well do some static tests and convert this over.


2 Responses

  1. Miriam Schwab says:

    Hi Joel, this is a great post! Just wanted to clarify that on Strattic, you can use WordPress form plugins like CF7 and Gravity Forms. Also, search continues to work since our static publishing system automatically replaces standard WP search with much higher quality Algolia search on the static replica of the site.

    I hope you do end up going static with your site :)

    • Joel Hughes says:

      Hi Miriam, yes, thanks for jumping on – yes, I may well have not made it clear that Strattic has solutions for many of the key WP > static problems. Perhaps I’ll do another post/tutorial on how we moved a site to Strattic which will make that all the more clear.

      Thanks again for stopping by


Leave a Reply