Infrastructure Overview
Creating a website bigger than "Hello World!" involves much more than simply a webserver. It will effectively have an entire network of systems and servers that work with each other to deliver the website.
This overview is to give you an idea of the infrastructure that is involved in running a website like this.
Flowchart Diagram
The flowchart below shows Deserted Chateau's infrastructure, which mostly resides in Amazon Web Services. This gives you an idea of the complexity of a website of this nature, but also shows many of the things you will need to set up and be familiar with (no matter which provider you use, the general concepts are going to be the same).
Webserver/s
Starting with the obvious, you will need webservers. Usually this will mean having more than one webserver, in case one goes down for some reason, and also because past a certain amount of traffic, one webserver will no longer be enough to serve all your visitors.
Load Balancer/s
Once you have more than one webserver, a load balancer is required. Unless you have a particular reason not to, it is usually worth having a load balancer set up to start with, even if it's only serving one webserver; this way, you don't have to worry about avoiding configuration pitfalls later when you do need more than one webserver.
Database Server/s
Storing data is something specialist servers and software are best at. You will need a database server that is designed to store and search information efficiently; your webservers, and some of your other servers, will connect to this database server to store and use information there.
Cache server/s
A cache server is critical, both for storing user sessions efficiently, and also for storing data that is commonly requested but rarely updated. For example, if your users love to search for "big juicy anime tiddies" (truly cultured users), constantly asking your database server to perform an exhaustive search of potentially millions of data records can cause a huge amount of strain on it, when the results both don't need to be exactly up-to-date and are also likely to be the same or similar.
In cases like that, a cache server is excellent for storing a copy of an operation's result for some period of time, then deleting the copy when it is too old.
Content Delivery Network (CDN)
A content delivery network is, in simple terms, a bunch of servers around the world that you use to deliver static content to users, since it is much more efficient and fast than doing it from your webservers. Static content means content that doesn't need to be evaluated by a server; images, videos, and code or scripts that are only evaluated by a user's browser (such as CSS and frontend JavaScript files) are all static content.
Your webservers are there to serve webpages, not perform complex processing tasks or serve large files. The CDN both removes this strain from your webservers, and also makes the loading of static content much faster for a user, especially on smaller websites. A user might be half a world away from your webserver, but the CDN is going to have a server much closer to their location, reducing the time taken for them to download images or other content and see them in their browser.
Cloud Storage
When a user uploads content to your website (e.g. an image), you can't store it on the webserver unless you only have one webserver. Otherwise, the user would navigate to the URL for that image, and unless it was stored on every webserver you have, they might not find it there.
Instead, you will need to store images and other content in cloud storage, where it can be accessed by all of your webservers. This is also necessary to use a CDN and some other infrastructure, since otherwise they will not have one single point of access to that data.
"Serverless" Code
This doesn't actually mean the code doesn't run on a server. What it means is that many infrastructure providers offer a service where you can run some code function you made "on demand", without having to provision a dedicated server 24/7 to sit around waiting for you to request running that code.
For various tasks, this is pretty much mandatory - keeping your own dedicated servers up 24/7 for tasks you might need to perform at any time of day is extremely inefficient, as you're paying for them even when you're not using them. Operations like resizing images and videos, which are too computationally expensive to do on your webservers (it would slow your website to a crawl) need to be done using serverless code.
Automated Email Service
This doesn't mean it just 'sends automated emails', but rather a service that can send emails programmatically, rather than by you going to an inbox and manually composing an email.
You'll need one of these for sending things like activation emails when users sign up, and any other use case where you need to send emails to users automatically, like on particular things they signed up to get emails about.
Email Provider
For actual email inboxes, you will need an email provider, who may or may not be the same company that provides the automated email service above. Having an email provider will let you use email addresses with your own domain name, rather than e.g. some gmail or other address, which is good for making a website look professional.