How to Make Content Websites in 2025? My Thoughts

Over the years, the web, or technology in general, has become unnecessarily complicated. The scene can be overwhelming for someone just getting started.

However, if you take a closer look at it, you can soon realize that most of this extra complications have accumulated in the superficial layer. The underlying technology has not changed much.

Who am I writing this for

First of all, let me tell you one thing - who all are my target audience, and who aren't. If you are in it for getting a developer or software engineer job, this blog may not be for you. Because I don't claim myself to be an 'expert' developer.

Instead, I write as if I am speaking to my future self, or to someone who is trying to figure out how to setup their own blog or small business website in this cluttered and chaotic times. So the scope of this article revolves around simple projects.

And, I am just sharing the things that I learn daily while developing and maintaining this website, and a few others.

In the earlier times, there was a term called 'webmaster'. It refers to the people who own and run websites, mostly on their own. Now I don't see that term mentioned so often. Nowadays, people have moved more and more into the specialisation rabbit hole.

Anyways, I am speaking to such webmasters like myself, who mainly manages blogs, small eCommerce sites, and small projects.

Why the web needs some simplification?

The reason why things has become overly complicated is, during the past few years, every other developer was trying to come up with 'solutions' that were supposed to make things easier, which partly did, but with bad side effects, in the front-end and in the back-end.

And guess what? Now you're left with a plethora of platforms, tools, saas, themes, plugins, frameworks, libraries, and what not?! Fitting these pieces together can seem next to impossible.

However, the truth is that, in order to build a great looking, fast, and economical website, you don't need to learn these unnecessary things. It will be a waste of time in the long run.

From past experiences, I have now come to the conclusion that in order to build your own blog, eCommerce site, or web application, you only need to learn the fundamentals, not the superficial things.

So, what are those fundamentals, and what are the superficial ones?

Fundamentals

Things that reside in the base layer are called fundamentals. Right? For instance, any website that you view in the browser is just plain HTML, CSS, and JavaScript at the end of the day.

But that's not everything. This base layer can also be:

• Concepts: how authentication logic works, how the internet works, how web hosting works, DNS management, sessions, web security, web performance, etc.
• Languages: HTML, CSS, JavaScript, PHP, Python, GoLang, SQL, C, etc
• Database systems: MySQL, MariaDB, PostreSQL, etc.
• DevOps: basic Linux command line, Nginx webserver (but this is totally optional, you can always start with a shared hosting provider)
• Git: It's version control system for your codebase, which you can integrate with remote repositories on GitHub or GitLab.
• SEO: adding proper tags, sitemaps, formatting, and good user experience

Now you might be thinking, "OMG, that's a lot to learn". Don't worry. You don't need to master all these upfront to get started.

Start with a simple HTML-CSS landing page, and see if you can get it hosted online with a custom domain name.

If you are completely new to coding, you can download some random free HTML template. Make some simple modifications by opening it in a text editor - like changing the title - then upload it to a shared hosting provider. By then, you'll get a hang of it.

Then try uploading the same template to a VPS as well. Providers like DigitalOcean, Vultr, and Linode give free credits to get started. This introduces you to some DevOps concepts as well - like SSH-in to a remote server, setting up virtual hosts, etc. This way, you can learn incrementally with a mix of bottom-up and top-down approaches.

Here is a path I would take from simple to complex (bottom-up):

• Level 1 (start small): HTML & CSS page, shared hosting, DNS
• Level 2 (expand): multiple HTML & CSS pages, shared hosting, DNS
• Level 3 (make dynamic): PHP-HTML-CSS, shared hosting, DNS
• Level 4 (bring in database): PHP-HTML-CSS-SQL, shared hosting, DNS
• Level 5 (add version control): PHP-HTML-CSS-SQL, Git, shared hosting, DNS
• Level 6 (integrate CDN): PHP-HTML-CSS-SQL, Git , CDN, shared hosting, DNS
• Level 7 (shared hosting to VPS): PHP-HTML-CSS-SQL, Git, CDN, VPS & SSH, DNS
• Level 8 (replace PHP with GoLang): GoLang-HTML-CSS-SQL, Git, CDN, VPS & SSH, DNS

Superficial Technology

And with 'superficial', I am generally referring to content management systems, frameworks, and anything that ties you down to a particular ecosystem. For example:

• self-hosted content management systems like WordPress
• frequently evolving frameworks like Next.js
• huge frameworks like Laravel, Django, which is usually overkill for small websites and apps

Why do I call these superficial?

WordPress CMS, for instance, is primarily built using fundamental technologies like PHP, HTML, CSS, and JavaScript. The database is MySQL/MariaDB. Try getting a high-level view, and you will realize that the whole WordPress Admin area is nothing but a GUI that modifies the data that resides in the underlying MySQL/MariaDB database, using PHP, based on the inputs you give.

Also, Laravel is a PHP framework. It's feature-rich. But when a framework is feature-rich, it's normal for it to be a little sluggish and resource-intensive. With proper caching and other optimisations, you might be able to make it load faster. But that's unnecessary work for a small project like a blog.

Same is the case with Next.js. It is a powerful fullstack framework built on top of React.js. It's great for building complex user interfaces. But I don't think it is the right choice for a blog or even an eCommerce site, which are mostly content-oriented.

Over the years, I have felt that if you go with these superficial tech to build small to medium sites, you may save some time initially, but in the long run, you may end up wasting more time in the form of:

• optimising themes, plugins, and extensions created by others
• time spent in chat and email supports with hosting providers
• managing frequent updates on your CMS
• fighting with the framework
• worrying about security

Instead, getting hold of the fundamentals allows you to create your own custom system, which always beats the above-mentioned pre-built systems any day, in terms of speed, cost, and freedom.

How would I create a website in 2025 and beyond?

Now let me share the four methods I would consider for building simple content-oriented websites and apps.

Custom Lightweight PHP app (Method 1)

This is the method I've currently implemented on this site.

Earlier, this blog was built using WordPress, and hosted on Cloudways. I also used to write a lot about it. You can still find those posts if you go a few pages deep in the blog section.

But overtime, I got familiar with the fundamentals. So I started ripping it part-by-part. First I removed some plugins, and replaced it with a custom site plugin written in PHP. Once I got hold of PHP and SQL, I realised that WordPress itself is unnecessary to run this blog. So I removed that as well.

At present, this blog is run directly using PHP, MariaDB, HTML, CSS, and some JavaScript.

In the meantime I also learned to manage a Linux server. So I replaced Cloudways as well. Now it is sitting directly on a DigitalOcean Droplet.

I no longer need to worry about someone trying to break my password, or brute-force the admin area. Because this site does not have a backend area to login. But still it retains its dynamic nature with PHP.

Then how do I manage the content without a backend?

Content management with Obsidian

I write posts using Obsidian on my local Ubuntu desktop. Obsidian is a note-taking app that allows writing content in markdown.

It's not open-source, but it is forever free to use unless you are not a for-profit organisation with two or more employees. That's what their license says, when I last checked. So, one-person webmasters, bloggers, and sole-proprietors are good to go with the free version.

Obsidian gives a clutter-free and customisable editing experience. I like it way more than the WordPress block editor.

Moreover, it stores all the content locally, so no privacy issues. You can create 'vaults' to organize all your writings. So you can easily manage content for multiple sites without messing up.

Then what? Just copy-paste the blog post to DBeaver.

Database Workflow

No, I don't directly update the remote database. I can mess up. Instead, I have a copy of the site locally, inside a docker container, where I make the changes using good old SQL, and see if it works.

The GUI provided by DBeaver is more than enough for my db-related tasks across multiple sites. It's an open-source tool that can connect to a variety of database systems including MySQL, PostreSQL, and MariaDB. Since it runs on the desktop, there is so no overhead on your server for running something like PhpMyAdmin.

I can also run direct SQL commands if needed right from within DBeaver. I have a .sql script that stores SQL commands for common tasks, like updating categories and tags, searching for a keyword, listing related posts, and so on.

To move the changes from the local to the remote, I have a shell script. The script makes use of the binary log files to incrementally apply the changes to the remote database. The connection to the remote database is via an SSH tunnel, which runs in the background.

Media storage

For file uploads, I upload images to BunnyCDN storage. I also have PHP script that automatically generates thumbnails and webp versions. The database only references those image URLs. No content images are stored on the web server.

Code hosting

The application code resides in a GitHub repository, from where it gets deployed automatically to the DigitalOcean droplet via GitHub Actions.

So there is no need to worry about backing up the code. Even if DigitalOcean goes down, my site's code-base is safe on GitHub.

My principles

Overall, these are my principles:

• keep things as simple and lightweight as possible
• no unnecessary code
• fewer the dependencies on third-party code, more stable the code base
• no tolerance to bugs and security loopholes

Benefits of this approach

As a result, a lot of headaches have gone:

• no more chatting with hosting support
• optimising WordPress? not again.
• no more searching for the right plugin or theme, reading their reviews

With that being said, I need to perform server updates once in a while SSH-ing into the Ubuntu server. But that's quite infrequent compared to a typical WordPress site's updates.

What if I need some user interactivity

Currently this is content website. However, suppose I adding some pages that requires a little user interactivity. For instance, adding a color picker in the Tools section (yet to come) would be a meaningful addition. Or even a shop page that allows product searching, filtering, and sorting.

In such a case, my first approach would be to do it with vanilla JavaScript. If it feels too cumbersome, I would use something like React.js. But still I won't convert the whole website to a React framework. Instead, I would only load the library on the frontend on the specific pages that require it. That way, I can ensure that the remaining pages will remain untouched.

Static HTML site (Method 2)

The above method is currently my choice. But the downside is that it still involves few complex steps, like Git deployment.

So for simpler projects, another route I would consider is a Static Site Generator. Hugo is a great choice written in Go programming language.

A static site generator runs fully on the local machine with content written in markdown files. You can also define template files, so there is no repetition like manually creating each HTML file. Then the generator builds the HTML files by putting the content inside these templates.

You can then upload it to any hosting provider, even directly to a CDN.

Since it is just HTML and CSS, performance will be the fastest. However, the downside is that it won't have any dynamic elements. Not even comments and contact form are possible, without some third-party embeddings.

How to use WordPress properly (Method 3)

Although I said that WordPress is superficial, I would still use it in some cases, with some trade-offs in performance and cost.

So, if I am using WordPress again, here are the points I would keep in mind:

• no more custom coding, because that mostly defeats the purpose of using WordPress.
• make the most out of existing themes and plugins
• learn to utilize the new block themes very well, without touching code
• understand optimisation in detail - page caching, object caching, CDN integration, Cloudflare, etc.
• also learn to make use of tools like Query Monitor to optimise backend performance
• choose a shared or managed hosting provider - no point in self-managed hosting because that's extra work that defeats the purpose of using WordPress.

By the way, with aggressive optimisation, WordPress can be as fast as even a static HTML site. But using it without caching is not recommended.

Website Builders & hosted solutions (Method 4)

I am not saying that you should always take a DIY route. Sometimes, you may not feel confident enough to handle everything on your own. That's okay. In such cases, you can always go with fully hosted solutions like Shopify or Squarespace. Hosting, optimisation, etc will be handled by the platform provider.

However, if you can do it yourself, you get the full control, and it is also economical.

Summary

Based on what we've discussed above, here are the scores I would give, out of ten, for each of the methods:

	Custom	Static HTML	WordPress/other CMS	Hosted solutions
Performance	9	10	6	(depends)
Learning curve	5	9	7	8
Security	10	10	5	(depends)
Maintenance	9	10	6	10
Flexibility	9	3	9	5
Freedom	10	10	6	3
Cost	8	10	6	4
Total	60	62	45	30-50

In the above table, the static HTML site gets the maximum score - 62/70. It also has the most 10/10s. However there is not much flexibility - just 3/10.

Whereas a custom lightweight app has more balanced score. The only area where WordPress beats Custom is in the learning curve. However, time spent learning a programming language, web concepts, and SQL cannot be considered a waste of time, as they are comparatively solid, and don't change frequently.