One of the most popular mottos in the development world is that “Content is King!”.
Your content is what will truly distinguish your website from the countless others out there.
Most websites serve one of two main purposes:
- To promote or sell a product
- To express ideas, stories, or narratives
In the second case, the crucial role of content is obvious. But even on product-based sites, the sales pitch is still content. In that sense, content is King. And the product? Well, let’s say that’s the queen.
The main point you should take away is this: no one returns to a website just for the visuals or a fancy modern user interface if the content is weak.
On the flip side, if your content is strong, people will come back. Even if your site is just a plain HTML file with no styling at all.
So, let’s jump into content creation with Alpha and Hugo and then, you’re free to go wild and crown your own King.
Content
Open VS Code. The folder alpha-starter/
should already be open in the Explorer. If not, open it manually.
Now find and expand the content folder. You should see something like this:
content
├── blog
├── _index.md
└── policy.md
This is where all your website’s content lives. Every post and page is a Markdown file (ending in .md
).
Markdown Files
The file policy.en.md
is a standalone page. For example, try clicking the Policy link in the hamburger menu or footer of your Alpha site, the content of that page is generated the from the policy.md
file.
Folders
Folders inside the content folder can play two roles:
- If a folder contains an
_index.md
file it’s a section (like the_index.md
inside theblog/
folder) - If a folder contains a
index.md
file it’s a page bundle (like thewhy-hugo/
folder inside theblog/
)
Sections
A folder becomes a section when it contains an _index.md
file.
Sections usually provide a list of all the pages or posts inside them. Like a category or collection.
The underscore in the filename is what distinguishes a folder from a section (
_index.md
) or a page bundle (index.md
).
Page Bundles
Page bundles, folders with an index.md
, are the recommended format for posts in Alpha. They help keep the content folder neat and make it easy to manage assets for each post.
At first glance, the structure might seem complex, but the logic is actually very simple and once you get the hang of it, it becomes second nature.
Let’s create some demo content to see how this works in action.
Creating content
If you have closed your terminal (PowerShell 7) reopen it and cd
into your site folder.
This time, instead of running hugo server, paste the following command:
hugo new content articles/my-first-article/index.en.md
What this command does:
- Tells Hugo to create new content.
- The new content will be a page (
--kind page
). - Places it in the articles folder
- Names the post my-first-article
- Creates it as a page bundle with a file named index.en.md
If you expand the new articles folder in VS Code, you’ll now see something like this:
articles
└── my-first-article
└── index.en.md
Now start the Hugo server again and visit:
http://localhost:1313/articles/my-first-article/.
You’ll see a new page with the title My First Article and today’s date.
Back in VS Code, open the index.en.md
file inside the my-article folder.
You’ll notice some text at the top of the file, surrounded by three plus signs, *+++:
+++
draft = false
date = "2025-03-18T09:27:05+02:00"
title = "My First Article"
author = ""
description = ""
# Use a specific archetype with `--kind`
# More info at https://alpha.oxypteros.com/docs/content-creation
+++
This is called frontmatter. It contains metadata and instructions for Hugo:
- It’s always at the top of a content file
- Must be wrapped by +++
If you delete a + or write anything before the opening +++, Hugo will break or treat that content as regular text. Go ahead and try it!
(Just make sure to undo any changes before continuing.)
Now let’s make some edits:
- Change the title:
title = "My Demo Article"
- Add an author:
author = "John Smith"
- Add a short description:
description = "This is the description for my demo article"
Then, below the closing +++, add the actual content:
## I did it
These are the first words that I write on my site!!!
Save the file, and that’s it, your changes appear instantly in the browser.
You just wrote your first article using Hugo and Alpha!
Feel that? That’s a hint of the power of static site creation.
Disclaimer
Right now, I’m sure you have questions:
- Can I change the date?
- Why can’t I see the description?
- What means “archetype with –kind”
- What do the ## mean?
And probably many more.
But here’s the thing: what we did until now in this guide is actually a pretty complex process, simplified and broken down into small, manageable steps.
To keep it clear and digestible, I had to make choices about what’s essential to your goal right now and what might overcomplicate things too early.
Yes, your questions are valid. They’re threads we could pull, but if we tug on too many at once, the whole learning structure might collapse.
Be patient all of it will be explained, either later in this guide, or in the Alpha documentation.
And if not?
Reach out! I’m always happy to help.
Publish to the web
Let’s pretend that the phrase you wrote in My Demo Article is your long-awaited masterpiece. You’ve poured hours into it, and now it’s time to share it with the world.
Here’s how:
- In VS Code, look at the left sidebar and find the Source Control icon (the one with the badge showing a number).
- Click on it, you’ll see a list of changed files. These are the files we just created and edited. Git has automatically tracked them.
- At the top, you’ll see a field that says Message type in:
Add my first content
- Press the Commit button.
- Now hit Sync Changes.
Now sit back for a moment while Cloudflare does its thing. It will detect the new changes in your GitHub repo and automatically rebuild your site.
After a minute or so, head to: https://[your-project-name].pages.dev/articles/my-first-article
And there it is your first published article.
On your site.
Live on the web.
Just like that.
But can you create and publish another article without following this guide step-by-step?
You should try it!
Just like you learned how to run hugo server
, you should now be able to go through the content creation and publishing process on your own.
Go ahead, create some demo articles, like my-second-article/index.en.md
write a few lines after the frontmatter, and publish them.
Don’t worry, we’ll delete them later.
What matters most right now is building your confidence in the content creation process.
Bonus: Tips and Correct use
Although simplified, this chapter packed in a lot. Honestly, I left out several details on purpose but a few of them I felt bad about skipping. So here they are:
Title ≠ URL
When we created my-first-article
, the folder name (my-first-article) was used to generate the URL, and the title
in the frontmatter was used for the page headline (Later on we changed My First Article → My Demo Article).
But after you changed the title, the URL still remained /articles/my-article/
.
Why? Because Hugo generates the URL from the folder name, not from the title in the frontmatter.
So, if you:
- Change the post title later and want the URL to match,
- Or you have a long title but want a shorter URL,
- Or simply want the URL to reflect something else,
Just rename the folder, and the new folder name will become the new URL.
Better Git Practices
Another thing we skipped: Git commits.
Earlier, when you committed everything with the message Add my first content
, that included all the changes that you made, even the hugo.toml
file where you changed the baseURL
in the
previous step.
Technically, this works fine.
But ideally, commit messages should clearly describe the changes they contain.
In our case:
- For
hugo.toml
, a better message would have been: Update baseURL - For the content files: Add first article
What we should have done in VS Code was this:
- On the Source Control panel.
- Instead of committing everything at once, we should hover over each file and click the plus icon (this stages it).
- Enter a commit message for the staged file(s), and hit Commit.
- Repeat for the rest, grouping files by the changes they represent.
So when you’re working with multiple changes, try to:
- Group related files together.
- Stage them.
- Write a clear message that the future you will understand (don’t be cryptic).
- Commit in batches.
- Don’t forget to sync
It’s cleaner and easier to track changes later this way.
If you want, you can now repeat the procedure properly for the new demo articles, and this time stage them and then commit them with clear, meaningful messages. It’s great practice and helps you develop good Git habits early on.