How To Set Up A Basic Website
Author: Alyssa Riceman
Posted:
I have now created my first real website! And it happens to be a new home for this blog. As of today, I am officially moving this blog off of its old home at WordPress and on to its new home at my personal website. Future posts will be at the new location and not the old one; be accordingly warned.
…and I could, in theory, stop there. Post for the first time in most of a year, say I’m moving, walk back out. But that’d be boring. So let’s instead go dive into what the process was for setting up the new site!
0. Introduction
This will be an overview of the process by which I assembled this website—this one, the new-as-of-November-2023 home of the Alyssa’s Coding Journal blog, also accessible via Internet Archive if one is reading this in the far future and wants to see the site in the form it took at the time of this post—and arranged for it to be accessible on the public internet.
This post will cover the process of building the HTML-tree, acquiring a domain, acquiring a hosted webserver, putting the HTML-tree at the server, pointing the domain at the server via DNS, and so forth. It will, however, cover all of these things vaguely and abstractly. This isn’t intended as an in-depth tutorial, really; I may try writing one of those, one day, but this is just a summary.
1. Motivation
The natural first question for a summary of how to put together one’s own website, of course, is: why do this? Why set up a blog at my own domain, built with a hard-to-learn static-site-generator tool, whose upkeep costs me a couple dollars a month in domain-registration and hosting costs, when I could just continue relying indefinitely on WordPress and similar free hosting platforms?
Going into the project of moving my blog over to here, I had two major reasons.
The First Reason
Building my site’s HTML-tree myself means that I get to customize everything about its design and content to my own tastes, without being subject to the limitations of other platforms’ various built-in UIs.
On WordPress, I could never make my blog’s display-column as wide as I wanted; on WordPress, I could never color links the way I wanted; on WordPress, due to some oddity of my blog’s stylesheet (over which I had no direct control), links within bulleted lists were entirely unmarked, without even an underline to indicate their presence. Not to mention the presence of ads, and a general sense of bloat to everything, pages displaying using complicated JavaScript where simple HTML and CSS ought to do fine.
Here, I can build everything from the ground up. I can include the things I want, like properly-colored links which don’t blend in with the rest of the text; I can omit the things I don’t want, like JavaScript (of which there’s not a single byte within this site’s file-tree); if I find myself dissatisfied with a bit of design, I can tweak it until I become satisfied; et cetera.
Taken to the extreme, this sort of customization can produce very beautiful websites indeed. I myself haven’t yet gone that far, nor become that skilled, at it; but I can, at the very least, do better by my own sensibilities here than I could on WordPress, and hopefully better by my readers’ sensibilities as well.
The Second Reason
The site looks slicker.
Not in the sense of being better-designed—it is that too, hopefully, but that was the first reason, not this one—but in the sense that it conveys an appearance of Put-Together-Ness. It’s at my own personal domain, rather than a .wordpress.com domain; it doesn’t have any logos lurking in its corners; et cetera. It’s cohesive, and the cohesive image it conveys is one of purposeful design, not just of doing the Low-Effort Cheap Thing. This seems like it has the potential to impress potential employers, and thus get me money. Something something “look at this nice professional-looking domain name! clearly this is someone we should give some money to” something something.
This may or may not ever actually tip any scales that matter to me, in practice. But it seems not-too-implausible that something it, or something like it, might, if I’m lucky; and that sort of outcome is worth putting in a bit of effort to make likelier, even given uncertainty.
The Surprise Third Reason
I went into this project with those two major reasons. To my surprise, as I finished the project, I discovered that there was a third major benefit, which I’d previously failed to foresee as such! Namely: development of basic website-building-skills and resulting independence from the big personal-site-farms like WordPress and the various big social media platforms.
One of my first thoughts, once I had this site up on the public internet, was: wow. That was surprisingly simple. I wish I’d learned to do this a decade ago, back when I was a teenager! Realistically, as a teenager, I had much less money and would have found the few-dollars-a-month cost accordingly more prohibitive; but being able to build my own site, unencumbered by the constraints of the various big providers, turned out to feel surprisingly satisfying, and now that I’ve done it once I feel pretty confident in my ability to do it again—iterating and improving my technique each time—with relative ease.
In short: I’m no longer trapped. I can build my own basic site and put it onto the public internet; with some more skill-building, I expect to become able to do the same with more complex sites, such as non-static database-backed sites, and with other software built for self-hostability, such as maybe my own Matrix server. I don’t need to rely on third parties to conveniently offer something suitable to my needs; if I want a website meeting a given set of specifications, and I can figure out how to build it myself, I can just do that.
It’s a surprisingly exhilarating and freeing sort of feeling. Enough that, while it wasn’t prominent among my motivations going into the site-building process, it’s ended up as probably the most significant of the three reasons for me in retrospect, ahead even of the first (which had been my most central motivation while I got started).
2. The Process
So! How does one go about doing this? What are all the pieces that need to be lined up, and how does one go about lining them up?
I don’t have anything resembling a universal answer here. Part of the beauty of modern internet-infrastructure is that it is, in fact, very decentralized at many points, offering a wide variety of options to choose from. But here are the core steps as I currently understand them, and the paths I myself took along those steps.
2.1. The HTML-Tree
The core essence of a website, in some sense, is its HTML-tree. There’s no point in having a domain name pointed at a server if the server isn’t serving anything, after all.
For basic site-building, one can hand-code all one’s HTML/CSS/JS/etc. But that can easily get very tedious and inefficient at scale, especially if one wants to offer fancier features like tags and RSS feeds (as I in fact do want to offer, and am offering, here); those sorts of things are very much designed to be generated programmatically.
Thus, the standard method for building a basic static site’s HTML-tree is via a static site generator. I myself chose Hugo, on the basis of its relatively-broad feature support; I have some frustrations with its template language—Go has never agreed with me, for whatever reason—but it has support for features like “have source files made of HTML rather than only of Markdown” and “generate RSS feeds” and so forth, and this is sufficiently valuable that I chose it nonetheless, and have stuck with it so far. And it took me a few weeks, but eventually I managed to build this site in it to my satisfaction!
(It would have been much faster if I’d been willing to settle for one of the premade themes in Hugo’s theme marketplace. But I very much wanted complete personal control over how the site is laid out—that was kind of one of my core reasons for switching to a static site in the first place, after all—and so I built my own theme from scratch, instead, and that took me a while to figure out the logistics of.)
2.2. The Domain Name
If one wants to have one’s site at one’s own domain, one needs to own a domain.
(If one doesn’t care so much about the at-one’s-own-domain part, there are plenty of static-site-hosting options which allow skipping this step and all the subsequent steps, such as Neocities, GitHub Pages, and various others.)
To do this, find a domain name registrar you like—or, if necessary, one you don’t like but find vaguely adequate (I myself went with Namecheap, with which I’m not hugely impressed but to which I have yet to put in the research-time to find a clearly-superior alternative to)—and buy a registration for a domain you like with them. Then you have the domain and you’re done!
2.3. The Hosting
Next up, find a web-hosting provider one likes, and go through whatever their process is for renting a server from them. I myself went with NearlyFreeSpeech—even when I’m blogging about code rather than anything popularly-controversial, it’s nice to have a background sense of not-being-likely-to-be-censored and thus of not-needing-to-be-self-conscious-about-what-I-write, and that made them a pretty obvious pick—and have been pretty satisfied with them so far; but this is a field in which options abound. While figuring out TLS, I ran into this list, and I expect that even it is incomplete, missing various smaller hosting providers scattered around the internet.
For whatever hosting provider you pick, you’ll then need to go through whatever their process is for setting up site-hosting on one of their servers. With so many different options, I have no generalized advice.
(There’s also the option of buying your own server and hosting it yourself, of course. I have even less advice there, for the moment, although it does seem like an interesting field to perhaps explore some time in the future.)
2.4. DNS Setup
(This step requires completion of steps 2.2 and 2.3.)
Once you’ve got your server up and running, you may—if this isn’t automatically handled by whatever domain registrar and hosting provider you’re using—then need to set up DNS records pointing from your domain name to your server’s IP address.
Setup for this given the [Namecheap, NearlyFreeSpeech] pair involved copying my server’s IP address off of NearlyFreeSpeech’s listing and then pasting it into the right corner of Namecheap’s “Advanced DNS” control panel. Moderate quantities of searching-for-docs-to-figure-out-details was involved, and this was ultimately the most complicated part of the process except for the static-site-building; but it still took me only maybe ~30-60 minutes to figure out, ultimately.
2.5. Putting the HTML on the Server
(This step requires completion of steps 2.1 and 2.3.)
Once you’ve got your server up and running, you need to put your HTML-tree onto the appropriate directory of the server for it to be served up! Hosting providers vary in the means they offer to go about this. One common option, which is the one offered by NearlyFreeSpeech, is access via ssh, allowing files to be sent via tools such as rsync; but others offer alternate means of access, such as web-dashboards, instead or in addition.
Regardless of the method, put your HTML-tree on the server, then visit the server—possibly directly by IP address, if you haven’t yet done step 2.4 and your hosting provider doesn’t offer access via other means—and make sure it’s showing up correctly!
2.6. TLS Setup
(This step requires completion of step 2.3.)
Although it’s not strictly mandatory—and is much less important for the typical static site than it would be for a site with e.g. password-protected user accounts—it’s still nice, for security purposes, to set up TLS (which is to say, HTTPS) for your website.
Once upon a time, I’ve heard, this was a terrible arcane process requiring extensive technical expertise and/or costing some amount of money. Nowadays, however, there’s a certificate authority called Let’s Encrypt which offers free TLS encryption to everyone they can figure out how to offer it to. They’re not the only certificate authority out there, but they sure do make themselves the most convenient one for ordinary users, with a big table of setup-processes by hosting provider and with these processes often being extremely simple.
(The setup process on NearlyFreeSpeech summed up to: run a shell script which is preexistingly present on the server’s PATH, then hit y to indicate agreement to Let’s Encrypt’s terms of service, then it’s set up and HTTPS connections to the site work from then on.)
(There probably is some argument to be made that excessive reliance on Let’s Encrypt is bad for the web’s robustness, opening up a single point of failure across a great many websites, much as I’ve seen made about excessively-widespread reliance on CloudFlare for DDOS-protection among those sites large or controversial enough to require it. In the long run, I may, in the spirit of that concern, try to figure out alternative means of TLS-setup. But Let’s Encrypt is sufficiently simple-and-easy that it’s the one I’m using for now, at least.)
3. Conclusion
And that’s that! That’s what I’ve spent the last few weeks learning and doing, and that’s my current understanding of how one can go about setting up one’s own website with a similar sort of backend to this one.
I expect to continue doing research in this field—improving this blog’s layout where I see opportunities to do so, learning to host new more-complex sorts of site, researching alternative providers of the various services I’m relying on just in case any of my current providers fail, et cetera—but, for now, I’ve hit the limit of my knowledge and experience.
I very much encourage others to join me in learning to do this sort of thing! I found it to be both a productive process and an emotionally-satisfying one, thus far, and I expect and hope that many others will experience it similarly.