Happy New Year everybody! The last two weeks were reserved for the holidays, so there was no update here on the website. However, I still have two articles in the article series on building your own academic website left, and I want to begin the new year with finishing up the series. Again, if you feel there is something missing, please let me know!
Today, what I want to offer is simply some sort of “checklist” that you can use to make sure that you remember what you will have to do in two cases: First (and more importantly), how to ensure your website is up-to-date, and second how to migrate your entire website either to a different host, or switch out the backend.
So without further ado, let’s begin.
Keeping Your Website Safe
The internet is an unforgiving and brutal wasteland that doesn’t have to stand back behind Mad Max: On the internet, there are few actually enforceable rules (even in times of GDPR!), and if someone wants to mess with things, they have all the means to do so. Always remember: Your personal computer is always behind some sort of firewall, and that keeps it safe. But for content that you want to expose to the world, that would be counterproductive, so your web server is open like a barn.
Every day, security researchers find new ways of exploiting all types of websites: Big or small, off-the-shelf system or self-made website. Everything needs to be constantly patched so that the ship doesn’t sink like the Titanic. The most important thing therefore is to always keep your website up to date. This can be simpler or more difficult depending on which backend you use.
If you chose to use a static site generator, then you’re mostly off the hook: Because these things only write some static webpages, it is really hard to cause problems. Static sites have the drawback that they are not dynamic, but the benefit of this is that they are also the most secure type of website. In addition, if you decided to use the default Jekyll site generator from GitHub pages, GitHub will always provide the most recent version. The most you possibly have to do is re-generate your site from time to time to make any changes actually appear on your website.
Likewise, if you use WordPress.com or any other form of entirely managed CMS installation, your hosting provider will take care of keeping that up to date. You should still check from time to time to ensure that it keeps itself updated, but unless something goes wrong, you don’t have to move a finger.
It looks different if you installed your CMS by yourself, though. I am using Winter CMS, and that means that I will always have to log in to my server to keep that up to date whenever there was a new version. (They are promising that updating will also be possible from the backend at some point, but as of now, this doesn’t work.) If you installed WordPress on your own server, that is also by default instructed to always update its software, and it will notify you via email once it has updated itself.
Other CMS will have different update routines, and which applies to you is often documented in their setup guide. So make sure to read that and, from time to time, perform an update.
One note of relief, though: Your personal website is not Facebook or Twitter: It is just some random person’s online persona. In other words, even if your website is vulnerable to some attack, the chances are comparatively low that someone actually wants to hurt you. Indeed, the chances are higher that your arch enemy from the department across the street will poke around in your website to stir chaos rather than some anonymous Russian troll. So don’t frantically check every day if there is an update; once a month is absolutely fine. And if you miss a month, don’t worry. Chances are very slim that anything will happen.
Migrating Your Website
Now that you know how to keep your website safe, it is time to talk a bit about migrating it. I have already mentioned that depending on what you initially choose as your backend, you may want to switch that out at some point. Maybe because you come to the conclusion that your old one doesn’t give you all the options you need, or you just want to use a new backend. Or, your old backend is simply no longer maintained: if it doesn’t get security updates anymore, the chances will increase over the years that someone will be able to damage your website.
So, what do you do then? Conceptually there are three things you can do: Switch from one hosting provider to another one, exchange the backend, or both. In the following, I will give one guide for each of these situations to help you keep your website up and running no matter what you’re up to.
I want to Exchange Only the Hosting Provider
Say you have set up a website manually, but you’ve found a different hosting provider that gives you more storage and/or a cheaper price. Then what you will want to do is just move whatever you have as it is to the other hosting provider. Despite it sounding relatively simple, it is actually the hardest situation to be in. Here’s what you want to do:
First, make sure that the system settings on the new provider are the same or at least compatible to your current ones. This involves checking the available PHP version and ensuring that you’ll have the same database system available on the new provider. If that is a given, go and purchase the new hosting plan.
Then, you will want to plan for a window of time in which you are unlikely to change your website, and also plan for doing the migration maybe over the weekend. You will want a time slot that (a) doesn’t see many visitors viewing your website, and (b) gives you enough time to trouble shoot. Because things will go wrong, and you want to have enough time to fix those things during the migration.
When the time of migration has come, log in to your existing provider and download the entire folder with your website’s software/code. Do not leave any file out and ensure that you also download “hidden” files (those will start with a period). Then, you want to immediately log in to your database, and export that entire thing as it is. This will be relatively simple with phpMyAdmin, but may be more difficult with other systems. In any case, refer to the manual of whichever software your existing provider uses to know how to do that.
This will give you a file with all your data. Then, log in to your new provider, upload the entire folder you just downloaded as-is, and import the database export into the new database. Note, however, that you will likely have to create a new database for that first, and also a new user account. So while the actual data inside the database will still be the same, the log-in details for your website backend will have changed. So make sure to exchange those in the configuration file for your backend so that it can communicate with the new database. To find out where those are, consult the installation guide of your CMS.
Now it is time to test. Do not yet point your domain to the new provider! Instead, create some subdomain for your own domain that lets you test out whether everything has worked well. A common choice is “staging”, so that you can go to https://staging.your-domain.tld. Then, point only this subdomain to the new provider. Refer to my guide on setting up the website to see how to do this. Note also that it could in the worst case take two days for these changes to be picked up by your computer. (The longest I had to wait is an hour, but your mileage may vary.)
Some CMS also require you to tell them which domain they will be accessible at, and sometimes this can confuse the websites and make things load wrongly. If you get an error, double-check the installation manual for your software and temporarily exchange this information similar to your database credentials if that happens. (Remember to change that back afterwards.)
Now, go to this subdomain and have a look if everything looks and works as expected. If that is the case, you can now safely change the DNS entries for your domain and have them point to the new provider. Again, wait a few minutes/hours until these changes have been applied. When this has worked, you can finally cancel the plan with your old provider, and you’re done.
There are many things that may go wrong in this process, but I have made the experience that the internet almost always has the perfect answer to any question this may raise. Often, simply googling for the error code that you get is sufficient to get a detailed step-by-step description of how to solve the issue.
I want to Exchange the Backend System/CMS
If you want to keep your content, but exchange the backend system, this is a bit simpler than the previous case. Here, you don’t have to compare the exact system settings, because this is effectively setting up a new website. What you want to do is, again, create a subdomain (“staging”) and set up the new system you want to use going forward.
The hardest part here will be to re-create your old website’s theme as close as possible to what you have. This will involve dabbling with HTML and CSS, so you will need to learn this a bit. (As I already mentioned in a previous article, I do recommend this, as it’s a valuable skill.) You can of course also just use an entirely new theme, if you want to re-brand.
That’s why you will probably have two websites (the old, official one, and the new one reachable on the staging-subdomain) for quite some time, until it works. Once you are done adapting the looks of the new CMS, you can continue to copy and paste the information from your old website to your new one. This may take some time depending on how much content you have, but can be very quick if you don’t have a blog.
After that, you can – as in the above guide – just point your domain to the new provider (or the new place where your new website is at if you keep the same provider), and you’re done!
If you want to see how this can look in practice, have a look at my previous attempt at exchanging my backend system. I have recreated this website 1:1 using a static site generator. I ended up sticking to my existing backend, but I kept the repository open specifically for this case where it can serve as a teaching lesson.
I want to Change Both
This is the simplest case. In that case, you basically only follow my previous guide on setting up a website and then copying over those contents that you want to keep and adding additional content as you want. Then, point your domain to the new server, et voilà.
Mind the Redirects
One final thing we need to cover before I finish off this article: redirects. Whenever a link on your website changes, you need to use a redirect. On the internet, the actual link to your content is often tightly coupled with the content itself. In other words, the subpage with your CV on it will be tightly coupled to the link to it, in my case www.hendrik-erz.de/cv. What happens if you want to rename that link and make it www.hendrik-erz.de/curriculum-vitae? Well, in that case your old link would no longer work.
Search engines don’t like that. If a website suddenly disappears, this will be considered a problem or even an error. But then, things change, and so does the structure of your website; especially when you just start out and experiment around. So you will want to keep the amount of “errors” small. You do this with redirects.
There are two types of redirects, 301s, and 302s. A 302 is a temporary redirect (read more here). This often happens when a page moves to another link, and will eventually return to its old link. This is akin to moving the “cv” page to “curriculum-vitae” and then back. What this tells search engines is: “Don’t get too comfortable with the ‘curriculum-vitae’ page, it will soon be back at ‘cv’.”
A 301 then is a permanent redirect (read more here). You will normally only want to use that one. This tells search engines “This link here is outdated; the next time you come around, please directly go to ‘curriculum-vitae’ and do no longer use ‘cv’.” This also informs your users’ browsers: If a user navigates to cv and the web server responds with a 301 code, a permanent redirect, the browser itself will remember that. The next time the user navigates to cv, the browser will not do as the user wants, and instead directly request curriculum-vitae.
However, even a “permanent” redirect is not really permanent. Remember: it informs search engines and visitors that they should just go to the new link. So one after another, search engines will stop visiting the old page, and directly visit the new page. Many redirect plugins for websites will give you some statistics of how many people use the permanent redirect. When that number goes sufficiently small, you can rest assured that most have gotten the memo, and you can remove the permanent redirect again.
Use these redirects both when you modify your website and when you move the website entirely. All CMS – including static site generators – enable you to use such redirects. Don’t just rename a website, assign a redirect to it.
Final Thoughts
As you can easily see: when you want to move your website, the difficulty of the migration will increase with every piece you want to keep the same. The reason is that all CMS are tightly integrated and there are many differences between them. So you’ll need to adapt everything you want to keep to whatever new system you want to switch to. It is easier to simply set up an existing theme that has been written for whichever backend you want to switch to than adapting an existing one.
That’s why I recommended starting off with a static site generator first. Changing the website is not as comfortable as with a CMS. But when it is time to switch the entire backend after you have gathered some experience, it will be much easier than if you started with either a managed CMS or an entire webspace.
In the final article of this series, I will share a few cool tips. Two of them I have already shared, but there are a few other cool tricks you can do once you have your own website, and I will highlight a few of them in my final article on this series. So stay tuned!
