Building Your First Website: Pick How It's Generated First, Then the Deploy Platform

The most common build order I see is almost backwards

A lot of people first choose between WordPress, Hexo, Next.js and various hosts, then buy a domain and a server, and only at the end ask: how does this site actually need to update?

The order should be reversed. First look at where the content comes from, whether an update needs a rebuild, whether viewing a page needs server-side computation, and who maintains the data and accounts long-term. Once those four answers exist, the tool range narrows itself.

If you're just publishing articles, work or project docs, a static site is often enough; if you need multiple people writing in a backend, look at a content management system; only when you truly need login, orders and real-time data do you move into a web app.

This article won't pick a "strongest framework" for you. It first puts local files, the build, the repo, the host, the domain and DNS back in their own places, so the first launch has a path you can explain.

A website passes through at least five layers

Layer one: content

Content is the titles, body text, images, links and page data.

It can be written directly in HTML, or stored as Markdown, database records or backend forms. The content format decides how you edit later, but it still isn't a public website.

Layer two: page generation

The browser ultimately needs HTML, CSS and JavaScript.

If you write HTML directly, this layer barely transforms anything. If you write Markdown, use Hexo or another generator, you need a build that turns source files into pages the browser can read.

The current Kenton Blog works this way: article bodies are stored in Markdown, and a build script generates the individual HTML, the homepage and the sitemap.

Layer three: the code repository

A GitHub repo handles versions, collaboration and rollback. It isn't required, but it lets you know what a given change did, and makes it easy for a host to rebuild after each push.

A repo existing doesn't mean the website is public. It only means the source or build output is saved to a remote location.

Layer four: the host

The host puts the generated files on always-connected infrastructure.

GitHub Pages and Cloudflare Pages can both host a static site. Cloudflare Pages' docs note that plain static HTML can deploy too, with no framework required; after a successful deploy you get a pages.dev subdomain.

Layer five: the domain and DNS

The host's default address is already reachable. A custom domain just points your own name at that site.

DNS handles resolution, not page generation. When a domain won't open, it could be DNS, the certificate, the host config or the site files — you can't blame every error on "the domain hasn't taken effect."

First decide which kind of site you are

A purely static site

Good for:

• A personal blog.
• Project docs.
• A product intro page.
• A portfolio.
• Content pages that need no login or database.

The upside is a simple structure, a smaller attack surface, and low hosting cost. The downside is you update content through files or a build process.

If your need is just "publish a set of articles that will keep updating," a static site is usually the first recommendation.

A content management system

Good for:

• Multiple people writing through a backend.
• Needing comments, user roles and plugins.
• Not wanting to touch a code repo on every update.

WordPress is this type. It gives you a backend and a database, but it also brings server, update, plugin-security, backup and recovery responsibility.

A web app

Good for:

• User login.
• Personalized data.
• Real-time actions.
• Payments, orders or complex forms.
• A product that needs server-side logic.

Now a frontend framework, APIs, a database and a deploy method become the core. Don't take on a whole app's maintenance ahead of time for a blog with five pages.

The first success only needs one file

Create a new directory and make an index.html in it:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My first website</title>
</head>
<body>
  <h1>The website is working</h1>
  <p>This is a real HTML page.</p>
</body>
</html>

Double-clicking opens it, but a local file address differs from a real website environment. If your computer already has Python, run this in that directory:

python3 -m http.server 8000

Then open:

http://localhost:8000

The sign of success isn't a line in the terminal — it's the browser showing the title and paragraph, still there after a refresh.

To stop the server, go back to the terminal and press Control + C.

From a local page to a public page

Option one: GitHub Pages

GitHub's official quickstart gives a path to create a Pages site from a repo. It suits people already on GitHub who want the repo and site to map closely.

The minimal flow:

1. Create a repo.
2. Upload index.html.
3. Enable Pages in the repo settings.
4. Choose the publishing source.
5. Wait for the public address to generate.
6. Open the public URL from a logged-out browser.

That last step matters. Seeing the page while logged into GitHub yourself doesn't mean an ordinary visitor can reach it.

Option two: Cloudflare Pages

Cloudflare Pages supports GitHub or GitLab integration, and can also deploy plain static HTML.

For a static directory that needs no build, the docs allow a custom output directory, and note that the site root needs a working index.html, or the default address may return 404.

When using Git integration, be clear about:

• Which repo.
• Which branch.
• Whether a build command is needed.
• Which directory the build output is in.
• Which push triggered the deploy.

After the deploy, verify the pages.dev address first, then attach a custom domain. That way, when DNS goes wrong, you can tell whether the site itself is fine.

What a build command and output directory are

This is where beginners most often get stuck.

Say you write articles in Markdown and a build script generates pages into a dist directory:

content/
  article.md

After the build:

dist/
  index.html
  articles/
    article.html

The host needs dist, not content.

The build command produces dist.

The output directory tells the platform which batch of files to make public.

Fill it in wrong and the common results are:

• The build succeeds but pages 404.
• The homepage opens but the article path doesn't exist.
• The platform exposes source code instead of generated pages.
• Fine locally, but missing images or CSS online.

To troubleshoot, read the platform build log first, then confirm whether an index.html really exists in the public directory.

The domain goes on last

A custom domain involves at least:

• The domain registrar.
• DNS hosting.
• The Pages project.
• The DNS records.
• The HTTPS certificate.

Don't change every layer at once.

A steadier order:

1. The default platform address is reachable.
2. The custom domain is added to the correct project.
3. DNS is configured as the platform prompts.
4. Wait for the platform to confirm the domain.
5. HTTPS is fine.
6. www and the root domain redirect as expected.

A DNS page showing a record doesn't mean the browser has the correct content yet. Visit again in an incognito window or on another network to avoid local cache giving you a false read.

How to tell the site really published

Finish at least these seven:

• The homepage returns the right title.
• One article detail page is reachable.
• CSS and images aren't missing.
• No horizontal scroll at phone width.
• The default address and the custom domain behave clearly.
• The sitemap and RSS open when needed.
• After updating an article, you know which build published it.

"The platform shows green" only proves the build task passed. An actual read-back of the public URL proves a user can see it.

On a 404, work these five layers

The local file layer

Whether there's an index.html in the output directory, and whether the filename case is consistent.

The build layer

Whether the build command exited successfully, and whether the generated files were written to a different directory.

The host layer

Whether the project's chosen branch, build command and output directory are correct.

The path layer

Whether pages use absolute or relative paths, and whether asset addresses change when deployed in a subdirectory.

The domain layer

Whether the default platform address is reachable. If it is, the problem is more likely the custom domain, DNS or the certificate.

Don't swap frameworks the moment you see a 404. Find the first layer that's missing a file.

Where the cost shows up

A static site can start on free hosting, but long-term there can still be:

• Domain renewal.
• Builds or traffic over the free tier.
• Image storage.
• Email and form services.
• Analytics tools.
• Paid themes or plugins.
• Maintenance time.

Prices change, so this article won't hard-code plan numbers. Check the platform's current pricing and limits before you use it.

My default pick for a first-time builder

If you just want a blog, project page or portfolio:

1. Write content in Markdown or simple HTML.
2. Generate static files.
3. Use GitHub to save versions.
4. Host on GitHub Pages or Cloudflare Pages.
5. Bind a domain only after the default address works.
6. Don't buy a server first.
7. Don't install a database first.

When you genuinely need login, a backend and dynamic data, then move into WordPress or a web app.

For a first build, this is enough: you know where the content lives, which command generates pages, which batch of files is hosted, where the domain points, and which layer to check first on a 404. The tech stack can change later; this path has to be explainable first.