I've managed a few sites and even more servers that run other services other than an http/s web presence, so, while of course you should choose what fits your situation and usage case the best here are some things I've found to work well.
First, the site itself:
As noted above, one way you can manage your own website is by coding it by hand. This means you'll need knowledge of (at minimum) HTML, managing a web server (if your hosting company doesn't do this for you), css, and maybe some java.
With this method, you would be writing out your pages by hand complete with HTML tags for tables, links, and forms; any css themes you want to include (to get a similar "feel" across pages on your site); including any java code (if you want ads or usage stats), etc.
This method is as accessible as your operating system's "notepad" program. You would upload your oh-so-carefully handcrafted HTML pages and any other files to your server (hopefully not over ftp); if the files were placed in the proper directory the web server would start serving them immediately.
Personally, for any site that's going to have more than 3 or 4 pages that will be updated even on a semi-regular basis, I think that's too much work. So moving up on the "less work, more gain" scale, you have static site generators.
A bit of background first though: Most sites (including this forum!) aren't static sites. That is, there aren't html files sitting on a server somewhere that (to use this forum as an example), have the text of people's posts. Instead there is a relational database somewhere that has posts as a field in a row of that database. When users request a page (http://forum.audiogames.net/viewtopic.php?id=21432) for example, a php or other wsgi (web server gateway interface) compliant program takes the data it's given (URL parameters, post body, headers), and builds a response. In the case of this forum, it looks at the specific topic (that's what the id parameter is), and pulls the posts for this topic out of a database and returns them in the form of this web page your reading now.
After that digression, you might understand a bit more about "static" and "dynamic" web content. When you have a static site (like in the case of hand-coded HTML or using a static site generator), web content is not pulled from a database and no extra script needs to run to return your content; when you request a file, all the web server has to do is send it to you. For dynamic sites, a script must run and (based on things like what the client is asking for in the URL, post body, etc), it must build an HTML page and send it back.
Static site generators (ssgs) are tools that make creating and managing "static" sites easier and far less painful. This is what I use for my personal blog for many reasons, not the least of which that static sites are less vulnerable to easily being hacked from common content management system vulnerabilities. I use Nikola, which lets you write your pages in a multitude of markup languages (markdown, ReST, even the markup this forum uses I believe). It then converts that into valid HTML, handles themes, handles comments with several different backends, etc. All in all it's very nice, as you simply write your pages / posts in whatever markup language you want, run a command and then upload to your server (Nikola can also automatically do this for you, you just need to tell it how).
There are drawbacks to this method, of course. With "dynamic" content management systems like Wordpress and others, all you need to make a new web page on your site is a web browser. With Nikola (and any static site generator), you either need that software on the server (and if so you'll need root access to it, more on that in a minute), or you need it installed on your local machine.
As mentioned above, the ssg method has advantages, the biggest (in my opinion) being security. Since your website's pages are just static files, an attacker would need to compromise your server and be able to modify or create files. In the case of dynamic sites, every request to a site runs a script that needs to do some work to return the page; this gives an attacker chances to break things (e.g, inserting a new post in your database when they shouldn't be able to, etc).
Dynamic sites (as mentioned above) have to run a script / program that (based on the data it's given) does some work to return the requested content. This is how wordpress and similar sites work; your posts are in a database and the "work" is pulling them out and rendering them into HTML. The advantages of this are that you need no extra software on any client where you want to create a new post or page; you create your post by visiting a web page, entering text in the forms provided, and hitting a button (like this forum does). A script runs and inserts that page or post into your database.
Disadvantages are, of course, security. Wordpress and friends are very popular platforms for people's web content; thus they have a lot of eyes on their code, looking for vulnerabilities that can be used against them. Also, setup (while not as bad as it used to be), is still more than the other methods, as you need to configure your web server to pass certain requests off to php (not all URLs that request dynamic content end in .php, very few do, in fact). Most web-specific hosting companies can do this for you.
This brings me to my next point: hosting
Hosting your website also depends.
There are companies that deal with things like server configuration, wordpress setup, and leave you to do the content creating. This is all well and good, but if you do this you usually don't have "root access" to the box your site is running on. This means that, (outside of what your hosting company supports), you can't offer any other services as you can't install packages, compile things, etc. As a typical example, you won't be able to host a team talk server with just a web hosting company.
The other option is to buy a server. Companies like Digital Ocean, Linode, and chunk host allow you to buy a server (really a virtual machine running on a large machine somewhere, but it makes no difference) and pay monthly for it's usage. These are cheap (5 dollars will easily support a small to medium website with a database and other services). With this option you have more control over what specific web server you use, where things are stored, how you can upload content, etc. This also means you can mess up if you, say, accidentally enable a firewall but don't allow ssh connections through. You also should be familiar (or know someone who is and is willing to help you) with the linux terminal. With this option, (in case it wasn't clear), you have root access to your server, so you can change anything you like; installing packages, setting up a mail server (though that's a whole different can of worms); and generally doing what you want.
Both are great options, and it depends on how much you know (or are willing to learn).
You'll need a domain, but someone has already given a good recommendation so I'll just agree with them.
Whew, this post was longer than I thought it would be.
Hope it helps, and good luck.
Regards,
Blademan
Twitter: @bladehunter2213