Have fun!
Please don’t be intimidated by new concepts or lack confidence because you’re “not a developer”. I have been tinkering with computers since I was very young and still deal with all sorts of anxiety from time to time. It’s ridiculous and we can do so much more if we silence those doubts! However, if it is too much for you, or you simply want to save time, consider using Strattic as a simple static conversion and web hosting solution.
Safety first!
Being confident and being reckless are two different things. By having backups of data and a (tested) plan to undo any changes can give us the confidence to try more things, click more buttons and experiment!
How things should look when you’re preparing to go static
These diagrams give an example of how you can set things up for safely transitioning to go static.
Testing without interrupting your live site
Here, we see your current live site, example.com. We don’t change that at all while testing our static generation. We simply make a clone of our live site, putting it into a new WordPress installation, which can be on our own computer or a remote server. For the staging server, we want this to be as close to our intended new production server as possible, so if you’re planning to use S3, Cloudflare, Netlify, etc for your new static site hosting, use the same for your staging server. This exposes you to more possible issues during testing, so you’re not putting out fires when you first deploy to production.
Note: I’ve used subdomains in the examples here, because you’re likely to already have one domain, so should be able to freely create subdomains. If you have spare, unused domains or can create some free/cheap ones for testing, that will be even better to use as your staging site’s URL, due to the slight differences in configuring static hosting for subdomains or the “naked” domain.
Example using remote server
Live site example.com --> clone --> Dev site dev.example.com
Dev site --> deploy -> Staging site staging.example.com
Example using a local dev server
Live site example.com --> clone --> Dev site localhost
Dev site --> deploy -> Staging site staging.example.com
How things should look once you’ve gone live with your static site
Most users only maintain their dev server and live site once they go static. This is fine, especially if you have a quick and reliable way to rollback to a previous deployment (Netlify is a great deployment option due to this). However, if you’re nervous about rolling out a big change or it’s mission-critical, maintaining a static server and deploying your static site there first for quality-checking is recommended, as shown in the last diagram.
Of course, your static site should look identical to your development WordPress site, so including an additional staging server here is more to test any issues specific to the static generation/post-processing.
Example using remote server
Dev site dev.example.com --> deploy -> Live site example.com
Example using a local dev server
Dev site localhost --> deploy -> Live site example.com
Example using a local dev server, maintaining staging server
Dev site localhost --> deploy -> Staging site staging.example.com
|
V
verify staging looks OK
|
V
Dev site localhost --> deploy -> Live site example.com