In the previous posts, I have outlined why it is a good idea to set up a personal website if you’re in academia, how to navigate the minefield of domains, and what to think about before actually making it. I have been talking quite a lot without practicalities not because I simply like talking (okay, maybe I do), but mainly because a website is not like some app that you just download to your computer and start using. There are a lot more things to consider before creating one.
But that I have now finished – by now you should have an idea as to what your website will look like, you already have decided on a domain name (or even already bought one!), and you are ready to go.
If you didn’t read any of the previous posts, I really recommend you do so now, because now we’re going to actually spend money. So pull out your wallets, daddy wants your dollars.
How a Website Actually Works
While you have already decided on what your website will look like, now it is time to decide how the website should work. Or: You have decided on the frontend, now it is time to set up the backend. The “frontend” is what your visitors will see, the “backend” ensures that they see a proper website. For the sociologists among you (or really anyone who knows what a theater is), the frontend is analogous to Goffman’s “front stage”, and the backend is the similar to the “backstage”.
There are two categories of website backends: static and dynamic. A static backend is most often called a “static website”. It works like so: You define some content and other data you want to put on your website, and then you run a program – Jekyll or Hugo, for example – that takes this information and “weaves” it into actual HTML pages. Those you then upload to some web server, and whenever a visitor then visits your website they are basically just viewing one of these HTML pages. Whenever you want to change or add information, you need to modify the files of the website, then run the static website generator program again, and upload the new files to your web server. Should you choose to use GitHub pages for this, GitHub handles the latter two steps for you. All you need to care about is modifying the files.
The other category is dynamic. It is dynamic because what the various pages of your website will look like is not decided upon in advance. Instead, you modify the data with some form of administrative interface, and whenever someone visits your website, it will be build using this information before it is sent to the user. Basically, the static website generator here is running all the time, building pages as people visit your website. If you have ever seen the admin interface of WordPress and compared what happens on the actual blog, this is this process in action.
So which of the two should you pick? Well, for an academic website it doesn’t really matter, and both will work fine. Many simply use static websites because the information on there rarely changes. Dynamic websites are a must when you have some user interaction (a forum, for example), but if all you care about is some comparatively static content, a static website is sufficient. I personally use a dynamic website, however. The reason is mostly ergonomics: I feel it makes more “sense” to actually “create” a blog post in an admin interface as opposed to creating a new file with its content in a git repository. Because that’s how you create blog posts on a static website: you create a new file for each one of them.
A dynamic website is more complex (and as such can also open up the gates to malicious actors if you are not careful), but it gives you a lot more flexibility. A static website is … well, more static, but therefore also much easier to maintain. However, dynamic websites are also what WordPress or graphical page builders will give you. So unless you choose GitHub pages, you will end up with a dynamic website. If you are just starting out, my recommendation is a static GitHub website.
Your Options In General
Now that you know the basic anatomy of a website backend, it’s time to give you the actual options you have. In the abstract sense, you have four types of websites that you can choose from:
- A static website that consists of a bunch of files that are somehow combined to make HTML pages. You’ll need some basic HTML, Markdown, CSS, and git knowledge to make them work.
- A classical CMS/Blog involves one of the traditional website hosting frameworks like WordPress or Joomla. Here you don’t work with Markdown but with rich text and instead of the website being static, you can add and remove content on the fly by logging in to the website. The benefit is that you can do this also on mobile.
- A graphical website builder is a more modern take on the classical WordPress way of creating websites. Providers such as Squarespace, Wix, or Weebly will give you a graphical editor to make your website look unique and their promise is that you won’t have to write a single line of code. These providers attempt to combine the ease of setting up a WordPress-like website with ensuring that it won’t look like a thousand other pages on the web. But this also means that those websites are very pricey compared to what you actually get.
- Your own webspace means that you have more freedom to choose your CMS and you get loads more storage space (i.e., for uploading images, videos, or PDF files), but it means that you will need to do some setup yourself. The best option to start is to get some managed webspace (as opposed to a web server). In these instances, the web server part is handled for you, and you only upload the necessary files for the CMS of your choice. After the upload, everything else should work out of the box. This is how I started with my online presence. The more advanced alternative is your own server. This is very similar to simple webspace, but instead of someone else managing the web server aspect, you’ll have to set this up yourself. It is akin to the saying “To make apple pie, you must first invent the universe”. But inventing the universe means you control its laws of physics and if you want apples to look like oranges, then you just do that.
A static website is often free, and classical CMS/Blog will have free options, too. When choosing a static website, you must purchase your domain separately, the classical CMS-way typically has offerings where you pay for the website alongside a domain. The graphical website builder approach is almost always paid, but it also typically includes a domain. Lastly, webspace is always paid, and so is the domain, but both come separate, so you can mix and choose. It gives you loads of freedom but increases the mental overhead of setting things up.
My recommended path for your own personal website is the following: Start off with a static site at GitHub. That will already teach you a thing or two about how websites work without overburdening you. It is a good mixture of learning and safety, knowing that your website can’t be “hacked”. Then, I recommend switching to a dedicated CMS hosted on some webspace. After that, the sky is the limit, and you will have what it takes to manage your very own web server.
I do not (!) recommend using WordPress.com (or any other free simple CMS option), (a) because it does not really address the needs of academics and (b) switching to another system later will be annoying. Also, you won’t learn anything that may help you beyond this little project. Nevertheless, I will introduce this here in case you are absolutely sure you want to follow this route.
With that out of the way, let’s glance over a few practical options.
Your Options More Concrete
This section is just a very large enumeration of different options I know of. While preparing this article series, a lot of people have asked me to share actual options and how good/bad I think they are, so this section will contain a lot of information in what we Germans would call a “Schweinsgalopp”. If you already have decided on a specific backend, you can skip to the next section.
First, static site generator options. Most static site generators are compatible with GitHub pages.
The most basic one is Jekyll. That’s what GitHub will use by default to build your pages if you pick the easiest option of a static website. The benefits are a large ecosystem and that it has proven its worth. Problems include, but are not limited to, a limited set of pre-built themes to choose from and that changing what Jekyll will do can be a pain.
A more modern alternative to Jekyll is Hugo. It works pretty similar to Jekyll with a few key differences. For one, because Hugo is built with Go, plugin options are a bit more limited. Also, I personally feel that its template syntax is unintuitive. This especially holds true for working with dates.
Besides these two main options, there is a plethora of static site generators out there that all work very similar.
If you want to have a look at what a heavily customized static site looks like, I once was pondering the thought of moving to a static site generator (but ultimately didn’t). The code is still online here. It’s essentially this website, but as a static version.
Second, ready-made CMS systems. These are probably the most comfortable out there because they only require superficial technical knowledge, but I feel they are also the most limited ones. All of them require you to sign up for an (often free) account and then create a site.
First, the obvious: WordPress.com. There you literally click and collect your own WordPress page. The benefit is that you can get started immediately without a single line of code, but after that your options are very limited. You can only pick from the themes that are readily available, and if there are a few things that you don’t like, you don’t have many options to change that. When it comes to plugins to customize what your website can do, you are even more limited. It’s a bit like learning to ride a bike with aiding wheels: It makes it really easy to get started fast, but you have to use a wrench to get rid of the aiding wheels.
An alternative to WordPress.com that is especially made for academics in the social sciences and humanities is hypotheses.org. It’s a French WordPress provider (there is a horribly bad pun in there) with a few customizations that adapt it more to the needs of academics. If you really want to use WordPress, I’d recommend this one, especially since you can use a hypotheses-blog without a custom domain and still signal “academica-ness” to visitors. A good example is Mathieu Jacomy’s page. The Soziologiemagazin, of which I’m lead editor, is also located on Hypotheses.
When it comes to paid site builders, those don’t use an existing CMS system like WordPress but often a custom solution they provide. Among the more popular site builders are Squarespace, Wix, and Weebly. The benefit of these systems is that they work like WordPress.com but allow you a bit more customization so that your website doesn’t entirely look like thousands of other ones. However, I can’t comment on these, since I’ve never used them – I have built my first website before those providers were around, and so I never had the need to use one. One key drawback to these is that they are extremely expensive. Most of these options start at $10 and that barely includes the necessities of a website, without any extras.
This leads me to the next category: renting webspace. There are three subcategories.
First is managed webspace. This means that some provider pre-installs and maintains some CMS for you (normally WordPress, but this may also include Joomla or Drupal). Managed webspace sometimes includes additional perks such as a free email address so that you can use your domain to receive your personal or work-related email.
Second is just webspace without the managed part. You normally get a similar amount of storage space for your files, but more freedom. This type of webspace comes with no pre-installed website CMS, so you’ll have to do that yourself. It should normally also come with at least one database that you can hook your CMS of choice into. I personally really recommend starting here and learning how to do that, because it’s not too difficult. The clear benefit of this is that you suddenly have a vastly bigger selection to choose from. Yes, you have a bit of a learning curve as to how Linux and web servers work, but you get an incomparably larger amount of freedom. In addition, this is still extremely cheap, coming in at about $5-$10 a month.
Third is an entire web server. This one is actually an entire server where you’ll have to set up everything yourself. That is also knowledge you can learn, and this gives you the biggest freedom because you essentially have an entire computer that you can fill with whatever you want. However, this also comes with the largest responsibility. I personally recommend to first try out (non-managed) webspace, and then once you are comfortable, switch to a web server. Then you can do additional funky things such as installing Nextcloud to have “free” cloud storage or a link shortener for when you want to share some long links easily.
This leads me to the last category: CMS systems that you can install by yourself. Here, the selection is insanely huge, so I’ll be brief and only mentioned what I tried out myself.
The first one you can install by yourself is obviously WordPress, which comes with the same caveats as above (except you can install most plugins and themes and adapt these).
A slightly more complex alternative to WordPress is Joomla. I always found it a bit unintuitive, but I know quite a lot of people who really enjoy working with it, so I’m going to give it a recommendation. Besides, we use Joomla for the website of the International Network of Analytical Sociology (INAS).
Then, there are a few “developer” CMS out there that give you a large amount of flexibility as to customizing what your website looks like. Instead of giving you a wide variety of themes that you can choose from, you’ll have to build the theme from the ground up. The drawback you’ll see is that you actually have to learn some HTML and CSS. But the benefit is that you control every pixel of your website.
My weapon of choice here is Winter CMS. Originally a fork of the (now proprietary) October CMS, it is relatively simple to set up, requires a bit of work to get a theme up and running, but then allows you to modify anything you like in a – in my opinion – very comfortable way. This is definitely by far my favorite.
Another CMS that may be a bit easier to set up because it tries to combine a dynamic CMS like WordPress with a static site generator is Grav. Grav doesn’t need a database, which absolves you from having to set that one up. I found it still a bit unintuitive back in the day when I was trying it out, but time doesn’t stop. So I’m sure they’ve fixed a lot of the issues I was experiencing a few years ago when I tried it out.
There are dozens of additional alternatives and the web is full of CMS, so this barely scratches the surface. If you aren’t satisfied with any of these options, feel free to look around.
Setting Up Your Website
Now to the fun part! Once you have decided on what to do (static website, managed CMS, graphical CMS, webspace) and which system to use, it is time to take the plunge and make a dent on the internet. Here I collect setup instructions for the three types of academic websites that I have experience with. I cannot give you any instructions with graphical CMS like Squarespace, but I figure the process will probably be very similar to the one for managed CMS.
Reminder: I recommend to start off with a static website on GitHub until you are comfortable dealing with HTML, CSS, and Markdown, and then switch to regular webspace and install one of the CMS I mentioned (or your own choice).
Static Website with GitHub
Let’s begin with the (currently) most popular choice: A static website with GitHub. First, you obviously need a free GitHub account, which you should now create if you don’t already have one. Then, you can follow the guide that GitHub has already written.
Basically, the process works as such: You’ll first need to create an empty GitHub repository. If you don’t know what that is, I made a video on Git repositories a few years ago. Inside this repository, you will then need to add some required files that Jekyll needs. Among those are a configuration file, data files, and pages in Markdown format. The guide I linked above will guide you to create an empty page with the default theme. What you will want to do next is choose a different theme for your page so that it doesn’t look like the default. The Jekyll documentation got you covered with resources on where to find themes and how to install them. You can further customize the theme with CSS.
If you want to see an example for a GitHub page that is “feature-complete”, i.e., which has most of the bells and whistles that Jekyll offers, have a look at my website’s repository. You will probably need less files than that, but feel free to use it as an example that shows you how to configure and customize your own website.
After setting up your page, it should go live within a few minutes under https://your-username.github.io.
Now the next step is to point your own domain to your GitHub pages site so that visitors to your site don’t see the “github.io” suffix, but instead can type in https://your-domain.tld. Again, for this, GitHub has a guide that you can follow. Read that to know how the general process works, and then see here for the actual steps you’ll need to follow. I have outlined a step-by-step instruction of how to change the corresponding DNS-settings below in the section “Pointing Your Domain to Your Website”.
Once you’ve followed these two tutorials, you have a website going – hooray! The next step is to familiarize yourself with the documentation for Jekyll so that you know what possibilities you have.
Lastly, if you want to use Hugo or another static site generator, you will need to set up a manual GitHub Actions Workflow. This is more advanced and requires a bit more tinkering, but I just saw that Hugo has an extensive guide on how to do exactly that. These instructions will also work for other static site generators – with some adaptation, of course.
Managed CMS with WordPress.com
Static websites may be difficult, especially for novice users. Therefore, some may want to just use a managed CMS. To create a website with WordPress, you’ll need to create an account there. Once you’ve done so, you need to create a new site. I really do not recommend using WordPress.com, but I chose to include it here for completeness’s sake.
After registering and starting the first website setup process, WordPress will offer you to buy a custom domain for a few bucks. If you want to commit to WordPress.com for now, you can enter a domain and order it via WordPress.com. According to their documentation, you will be able to move the domain to another provider later on, so it seems like a safe bet. You can also select “Choose domain later” and register the domain with another provider (or add a domain via WordPress.com later). You’ll need to pay to have your custom domain point to WordPress.com anyhow, however, so if you know you’ll stick to WordPress for now, you may go for the bundle.
Next, you need to choose a title and a short description of your “blog”. You can change this information later on. After the setup steps, you will be redirected to your administration dashboard. At that point, you can add two things to the WordPress installation: Static pages that might contain less regularly changed information, and blog posts. If you don’t intend on starting a blog right away, you’ll only need to create static pages. You can create and fill those with content in a relatively simple graphical editor using “blocks” of content. You should start with a static homepage and a CV-page first and fill those with the content I’ve discussed in the past articles.
You only have to remember to set your static home page also as your actual homepage in the settings. The instructions for this, as well as further information on how to customize your WordPress page are described in their documentation.
The major benefit of WordPress despite its limitations is that it is so widespread that it will be easy to find help online, even if the documentation doesn’t help you out. Note that one major drawback of a managed WordPress.com site is that in order to use plugins you will definitely have to pay them, otherwise you’ll only receive a naked website. This is sufficient for the start, but you may want to think about alternatives relatively soon. Also, I don’t know of a proper way of adding JSON-LD data later on (which I will cover in the next article).
Webspace
This is the most complex option of the three, but the one where I actually know a thing or two. For this option, you will have to select between the three alternatives I have described above: managed webspace, webspace, and a server. A managed webspace usually works almost identical to setting up WordPress.com, so I’m not going to cover this here. (It is merely more transparent, as most providers won’t offer a free plan and therefore don’t have to hide every useful setting behind a paywall.) I will also not cover the complete web server setup process. If you’re interested, let me know so that I can offer a dedicated article later on.
So let’s assume you want to upload and set up your own CMS. The process will vary a bit from CMS to CMS, so I’m only going to cover the conceptual steps. But each CMS comes with sometimes very verbose and easy to follow instructions. I will link to some below.
You will first need to pick the CMS of your choice and proceed to download a ZIP-file with the CMS files from the corresponding website. Some CMS may also only come in a .tar.gz-file. This is essentially the same as a ZIP file, but fancier. After you have done so, you’ll need to extract that file on your computer.
This will give you a folder of files, many of which end in .php. PHP is the most common language for programming CMS. It turns out that every CMS software is just a bunch of files, unlike programs on your computer that often end in .exe or .app.
You will now need to upload these files to your webspace. Your hosting provider should have given you a set of credentials in the form of username and password that you can use to log in to your webspace.
Imagine your webspace just as a remote file storage, very similar to Dropbox or One Drive. After logging in, you will have access to this remote storage, and all files you put there will end up public on the internet (so don’t upload your wedding pictures folder).
There are two ways of logging in to that remote file storage: via FTP or SSH. FTP is a very old protocol for transferring files between computers. SSH is similarly old, but more secure. If you have the choice, choose SSH. Otherwise, FTP will do.
You can handle the file upload from the command prompt or terminal, but there are graphical choices. For Windows only, I can recommend WinSCP, and for both Windows and macOS I can recommend Cyberduck. Back in the day, FileZilla was the most common choice, but that has really started to suck about ten years ago, so I cannot recommend it anymore.
Once you have the program, you’ll have to log in to your webspace. Refer to the corresponding documentation of how to do so. Then, upload the entire folder contents to the server. Some CMS want you to do some things to the files before doing so (such as modifying a config file), but they’ll mention this in their setup guide. If nothing is mentioned, just upload everything.
Make sure that the files are at the top level of your webspace, so don’t upload the folder to end up with webspace/cms-name/cms-name. Usually, there is a file called index.php – that one must be at the top of your webspace and not within any folder.
Once that is done, you may already be able to already reach your website! You can try it out: either your custom domain already points to the webspace, or you have a complicated-sounding subdomain of your hosting provider that points to your website (the provider should indicate this somewhere). If you visit that link now, you may either be greeted with a working website, an installer, or an error (in which case don’t worry, then their install process is just a bit … archaic).
Note: You can of course also use a static site generator in conjunction with your personal webspace. What you will need to do is build the website locally, and then just upload all resulting files to your server. Then your entire setup process is done at this point!
Many CMS need some more setup at this point. Specifically, some will need a database (except you’ve opted for Grav).
There are generally two types of database. First, you can use a so-called SQLite database. But your webspace likely came with a so-called MySQL database. (It may be called MariaDB, which – for your purposes – is exactly the same.) If so, you can use that one. Using the latter kind of database is the convention, and I’m using that one myself. There should be instructions from your hoster of how you can set up this database; many use a software called phpMyAdmin for that (find the manual here). You should end up with a database name, a database username, and a password. When the CMS installer asks for those, provide them so that the CMS can set itself up using this database. The CMS will create a bunch of tables inside that database that will hold your content.
And that’s it: During the setup process, you will create an administrative account that you can from then on use to log in to your website and do everything in a much more graphical way. Depending on your needs and the sophistication, you may never again need to log in to the webspace via FTP or SSH ever again! (Except, of course, you want to migrate away from that webspace, which I will cover in a future article.)
To end this section, here is a list of setup instructions for the various CMS I have mentioned earlier.
- Installing WordPress
- Installing Joomla
- Installing Winter CMS – Note: Choose “Web installer” in the section on “Alternative methods”
- Installing Grav
These guides will use a few terms:
- phpMyAdmin is a commonly used software that is used to administer a MySQL server. Your hosting provider may provide this for your webspace. Others may use different software for the same purpose.
- php.ini contains the configuration for the entire PHP installation. You will likely have no access to it, but you can safely ignore any suggestions.
- composer is a piece of software that requires actual SSH access to a web server to run. Some PHP-based software requires that during install (but not the ones I have linked here).
Pointing Your Domain to Your Website
Now we’re almost done! Are you already breaking a sweat? I can understand. Feel free to grab a cup of tea and take a few minutes of rest. You already managed quite a bit!
The final step of setup is to point your domain to your website. Remember that a domain is nothing but an easily rememberable name that maps to the hard to remember IP address of the corresponding web server. To make your domain point to your website you really only have to collect that info and apply the necessary changes. Here I explain how you do this in principle, and then again I will link to guides that cover the concrete steps for both GitHub and WordPress.
First, you will want to create both a “www”-subdomain and what GitHub calls the “apex” domain. In other words, you want both https://your-domain.tld and https://www.your-domain.tld to point to your website. The reason for this is that sometimes users will only type in the former, sometimes they will type in the latter. But both fundamentally “mean” the same, so configuring both will save visitors from seeing a “this website cannot be reached”-error. Try it out with my website: Both “just” hendrik-erz.de and www.hendrik-erz.de resolve to the same website. Many websites do that, so you should, too.
Some useful concepts when it comes to setting up your domain: What you will effectively do in the DNS settings is create entries in some database. Compare this to an Excel spreadsheet. You will always need to fill in three columns: (1) the type of record you want to create (A, AAAA, TXT, CNAME, or MX); (2) where the record will point to (can either be “the” domain, i.e., your-domain.tld, or any subdomain, e.g., “www”); and (3) the contents of the record (can be IPs/domains or just text).
- An A-record is an entry that maps a domain onto a regular IP address. So if you want to let a domain point to some server, you would put in the server’s IP address here. Example: The domains “hendrik-erz.de” and “www.hendrik-erz.de” both have an A-record that points to the IP 45.129.183.60.
- An AAAA-record is the same as an A-record but for IPv6 addresses. Since my server has an IPv6, I have AAAA-records for both domains that point them to the IPv6 2a03:4000:47:3d1:64ef:21ff:fe8f:330b. AAAA-records are not required because IPv6 is still somewhat niche, but should you have an IPv6 it certainly won’t hurt.
- A TXT-record is literally some piece of text. This is often used to verify you are the actual owner of a domain before providers such as GitHub will actually allow you to map a custom domain to your page. For example, you may need to add TXT-records in the form of “_github-challenge.your-domain.tld” with some key as its value.
- A CNAME-record is short for “Canonical name”. This basically just tells anyone who wants to visit your website that the domain “your-domain.tld” is actually just an alias for the canonical domain that points to your GitHub pages domain. Read more on CNAMES.
- An MX-record may come in handy should you want to configure emails for your domain. These types of records tell an email server where to deliver emails to.
There are other types of DNS-records, but I won’t go over them here, because you will probably never need them.
For your webspace, you will need to know the IP address or the subdomain of it, and then you can have your custom domain point there. Your hosting provider should have provided you with information on how to point a domain to your webspace. For GitHub and WordPress, the steps are a bit different, and they are outlined below:
- Using a Custom Domain with GitHub Pages
- Using a Custom Domain with WordPress.com – note however, that this requires a premium plan; it does not work with the free plan.
A Note on SSL
Before I end this (really long) article, I need to talk about security on the web. Specifically, SSL. SSL is an abbreviation for Secure Socket Layer and practically means the difference between “http” and “https”. If a website has SSL enabled, the address will start with “https” and you will see the famous lock-symbol in your browser’s address bar. If a website does not have SSL, you will know because your web browser will refuse to open the website. And this is good. If a website doesn’t use SSL, everything you do can be viewed by third parties. This is very crucial for when you enter credentials (i.e., when you log in to a website). But even if a website (like your personal one!) doesn’t use any credentials, other people could still track how you navigate the website.
Despite SSL being crucial to a safe web, it still breaks more often than you would think. To keep your website secure (and prevent the ugly warning message when other people try to visit your website), I want to give you a few tips to ensure everything works as expected.
SSL roughly works like so: On your website, there is a certificate file. This is basically just some encrypted text. When a web browser connects to your website, it will first request this certificate file. Then, it will look into the information in this file to confirm that the server it communicates with is actually the correct one for the provided domain name. If that is the case, your web browser next checks the validity of the certificate. SSL certificates expire, and also they need to be provided by a “Certificate Authority” (CA). Once these checks are successful, your browser actually connects to the website in a secure manner.
It is important to note that each SSL certificate is bound to a specific domain, so you can’t create a certificate for “some-website.com” and then use it for “some-other-website.com”. Also, while you can create SSL-certificates yourself, those won’t be trusted by browsers, so you shouldn’t do that.
With that out of the way, there are three general ways of obtaining SSL certificates for your website:
- When you create a GitHub Pages website or use WordPress, those normally automatically create an SSL certificate for you, and you don’t have to worry, since all is automated for you.
- If you opted to use webspace for your website, you’ll need to create one yourself. Some hosters provide one SSL certificate for free for your webspace, but you’ll probably need to click a few buttons in their administration panel to make the magic happen. For that, refer to their documentation.
- If there’s no certificate included, you can try to use Certbot, which is the free service from “Let’s Encrypt”. I use that service for my SSL certificates, for example.
- However, it may not be possible to run Certbot on your webspace, and then you’ll need to order a paid SSL certificate from a company that you can provide on your webspace. Try to avoid this like the plague, because SSL providers can act like leeches.
Final Thoughts
Phew, what a ride. When I started this article, I didn’t think it would get this long. But to be fair: I did explain three entirely different ways of setting up your personal website. Also, I tried to be very verbose about why all of these different steps matter.
I hope that you have success setting up your website; I poured almost two decades of experiences into this article. Let me know once you’ve set up your website to show it off!
In the coming articles, I will share a few fundamentals of what you want to do now that your website is set up. But rejoice: the most difficult part is now over! From now on it’s incremental additions and improvements.
Until the next article, you can start to fill in the info that we discussed in the past articles and ensure that you have the baseline set up.
