A website, generally, is a collection of resources (typically pages), rather than being just a single page. Creating a site requires more planning than just a page. As well as having to understand the technicalities of authoring HTML, you have to understand some technicalities about your web server, and plan how you're going to put all your resources together.
For this guide, I started out by writing a simple table of contents. It outlined the areas I wanted to cover, and which parts would be handled separately (on their own pages). Then, as I wrote each page, I added more specific details to the table of contents, added references between pages, and entries to the index page.
As well as planning the content, I also made a plan about the style. Coming up with a plan about styling certain types of things in a consistent manner (examples, comment, etc.), and authoring the pages to fit into the guide. Developing a site plan and style guide helps to stop a project from turning into chaos, and makes it easier to maintain and modify.
If you're creating a website with a lot of files, it can help to put things into directories. Depending on the complexity, it could be just to keep images, stylesheets, and HTML separate from each other, or it could be separating different areas of content (like this web guide is in a different directory than other sections of my website).
When naming files and directories, it helps to name the files in a manner related to the content. Not only does this help you find the right things, for later modifications; but it also helps search engines catalogue a site (they can use the names of resources, as well as their contents). You also need to ensure that you don't name things in a manner that can't be done on the internet. For instance, blank spaces are forbidden in URIs, and so are various other characters (sticking to just using lower-case letters of the English alphabet, and numbers, is the safest bet).
Naming things in a coherent manner helps visitors who've got lost (many people arrive at a site via a search engine, and will probably not arrive at the first page). If you have a contents page, then calling it “contents” helps people (they're able to easily type it directly into the address gadget, and jump straight to it; as well as being able to make a reasonable guess at where links will take them, if they look at the address for something without any textual hint, such as when graphics are used). Likewise for an index page (a real “index”, not the default page served for a directory).
Provide navigational links on each page, in an easy to find location, which lead directly to a few main places (e.g. the homepage, contents page, index, help, etc.). As already mentioned, many visitors arrive via another website into the middle of a site. If there's no navigational links, they can't easily explore the rest of the site (only having links to the previous or next page, aren't very helpful).
For many people, creating a website involves putting files (that they've authored) onto a remote server. I can't go into the specifics of how to do that for every service, because there's too many different answers, but the most common is using FTP (file transfer protocol), it's the name of the process, and you use an FTP client program. You really need to find out how to put files on your host (look for their help guides, or ask them about it), find a suitable program to handle that for you (if you don't already have one), and read its own documentation to learn how to use it. For some people, their host will be their ISP, others will use an independent host, some will serve their website direct from their own machine.
When creating a website on a remote host, it's important to remember that different systems have different limitations (between yours and theirs, and the others used to view your webpages),and different methods of working. Here's three main areas that need addressing:
Many home systems don't care about filename cases, but URIs are case sensitive, and so are many webservers. Resources should use the exact same lower- or upper- case letters in the naming of resources as is used in any links that refer to them, even if they appear to work (for you) when written differently. It's simplest to always use lower-case. It's how people will probably hand-type any addresses into their browser, most won't expect a computer to act any different if they don't bother to capitalise certain words.
The character encoding is frequently different (sometimes only partially compatible), and it's a requirement that you specifically identify what's been used (so that correct conversions can be made, when necessary). Of course this means that you have to know what you've used (typically, “windows-1252” on Windows, or “iso-8859-1” on most other systems), and be able to configure your server appropriately. An alternative for when you can't configure the server, is to author your documents to suit the server's settings. An extremely poor substitute is to use a meta statement in the HTML to identify the charset, but this only works when the server doesn't override it with its own HTTP headers (the proper place for this information), and, even then, trying to specify it in a meta element still has problems. Specifying this information is a server configuration issue, and you really need to consult your web server manual for how to do it.
MIME types are used to describe the type of data being supplied to the browser (web pages, plain text, images, etc.). The server needs to correctly describe the data, so the browser can correctly handle it. This generally means naming files in expected ways on the server, to comply with the server's configuration. Alternatively, you can configure the server to suit your preferred naming conventions. The filenames that you use are completely arbitrary, they just have to suit how the server is set up. Getting it wrong, describing data as something that it isn't, means that errors are going to happen.
As already mentioned, one of the most common ways people find a website, is through a search engine. So, if you want people to find your site, you have to author it in a way that enables it to be well indexed by a search engine. This means things like:
Use appropriate titles and headings (for what the content really is, and using those elements in the appropriate places). Similarly, name your resources in a manner that's related to the content.
Use suitably descriptive prompts inside your inter-page links (don't use idiotic “click here” links).
Start the actual content of your page as close to the top of the HTML body as possible, so if search engines show a snippet from the top of your page in their listings, they show something useful from the page; rather than something useless, like a list of navigational links, advertising, disclaimers or stupid notes about website browser requirements.
Search engines will index resources based on a number of different ways (the names of the resources, their titles, headings and content on them, descriptions inside links, etc.), and can describe the page in various ways (snippets from the start of the page, snippets taken from some of the content around the keywords they searched for, meta data written about the page, etc.).
Also, people will generally arrive at the page that search engine mentioned, not the front page. You need to consider this while authoring pages. You should ensure that all pages have links to the main sections of the website, or visitors can get stuck at a single page (at the very least, you should have a link to the home page, if not to all of the main sections). You should also have inter-page linking, though don't expect people to work through an entire site to find what they're looking for. Links should have clearly obvious functions, avoid using obscure words or icons. Make your site easy for people to use.
Related to that, my own web logs show that most people who arrive via a search engine only look at the page they first loaded (i.e. they don't trawl through the website). With that in mind, it's best to keep all of the content about any one particular topic on the one page, and to write about different topics on their own pages.
Remember, a website that “appears to work” doesn't mean that it's correct, and isn't likely to break in someone's browser, unless you ensure that it actually is correct.
If you're using a programming language to generate a website (e.g. PHP), then you should still learn how to write HTML by hand, as you'll need to be able to write your programs so that they output correct HTML; and you'll probably need to correct some pre-built doodahs that come with your programming language, because they often create HTML incorrectly.
If I create all my pages properly, using real headings instead of tricks with fonts, etc., then I can generate the site's table of contents, by having the computer assess each page, making links to any heading with an “id”, and using the heading as the words in the link. Not only does this make it easy to generate the table of contents page, but it also makes it easy to update, should the site's contents be modified.
You really should properly check for problems with your pages, not just try them out in your own browser, but with programs designed as error checkers (there's links to some, on the references page of this guide). You can't use a web browser to error-check a webpage, they ignore a lot of errors, and someone else's web browser may handle them differently than yours (so you can't assume that because your browser copes with your pages, that someone else's browser will).
Check for HTML errors, CSS errors, errors in the addresses in any linked resources, as well as general typing and spelling errors.