I've got three small content sites running right now. Two are niche blogs, one is a documentation site for a side project. None of them make money. All of them need maintenance. This month I'm testing specific changes to how I run them, and I wanted to write up what's working, what's not, and what I'd do differently.
If you're running small sites and tired of hearing about "AI-powered solutions" that solve problems you don't have, this one's for you.
Hosting: Moving Away from the Defaults
I've been running these sites on a mix of shared hosting and a small VPS. This month I'm testing moving one of them to a different VPS provider. Not because the current one is bad, but because I want to see if I can cut my monthly costs without sacrificing uptime.
The test site is running on a $5/month instance from a provider I've used before. So far, it's fine. The real test comes when something breaks and I need to actually talk to support or fix it myself.
What I'm looking at: Does the cheaper option require more of my time? If yes, the math changes. Time isn't free. A $5/month VPS that needs hand-holding is more expensive than a $15/month one that just works.
Automation: What I'm Actually Automating
I used to do everything manually. Publish a post, copy files via FTP, manually run backups. That was fine when I had one site. Now I have three, and manual processes are eating time.
This month I'm testing:
- Git-based deployment: One site is now pushing to a Git repo that auto-deploys to the server. It's not new tech, but it's new to me for this use case. The workflow is: write locally, push, site updates. Simple. No FTP.
- Automated backups: I'm using a simple cron job with rclone to push backups to B2. Costs almost nothing, runs daily. I've verified I can restore from them. That's the important part—I've actually tested a restore, not just assumed the backups work.
- SSL renewal: Certbot does this automatically now. I mention this because it used to be a pain and it's worth appreciating when something just works.
What's not worth automating: Fancy "content optimization" scripts. I've seen people talk about AI tools that will "optimize your content for SEO." My content is fine. It shows up in search. I'm not testing tools that promise to fix content that's not broken.
AI Tools: The Ones I'm Actually Using
Here's where I'll lose some of you. I'm using AI tools. But not the way the blog posts say to.
I'm using a local LLM (nothing fancy, running on a spare machine) for one specific task: rough drafts of technical documentation. I write a rough outline, feed it to the model, and it gives me something to edit. It's faster than staring at a blank page.
That's it. That's the use case. It's not "AI-powered content creation." It's "I have a rough idea and need something to edit."
What I'm not testing:
- AI tools that promise to write entire posts
- "SEO optimization" tools that analyze my content
- Anything that costs more than $0/month
The failure mode here is obvious: if the AI writes something and I don't edit it carefully, it sounds like AI. I've read content generated by these tools. It has a specific flavor—generic, slightly off, missing the point in subtle ways. My readers would notice. I'm not testing tools that would make my work worse.
Monitoring: What Actually Matters
I used to monitor everything. CPU usage, memory, disk I/O, network traffic. Now I monitor three things:
- Uptime: Is the site responding? I use a simple check from a different location. If it's down, I get a message.
- SSL expiration: Does the cert renew? If not, I get a warning.
- Disk space: Has the disk filled up? This has actually happened to me twice. Logs grow, backups accumulate. Now I get an alert at 80% capacity.
Everything else is noise. I don't care about CPU usage on a static site. I don't care about memory unless the site is crashing.
What I'm testing this month: A simpler monitoring setup. Instead of Prometheus + Grafana (which I know, I've used it at work), I'm trying a hosted service that does the checks for $2/month. The trade-off: less control, less customization, but also less maintenance. For three small sites, it's probably the right call.
What's Broken So Far
Two failures this month:
Git deployment broke once. I changed something in the deployment script and pushed a bad config. The site went down for about 20 minutes before I noticed. The fix was rolling back the change. The lesson: test deployment scripts before pushing to production, or accept that you'll break things occasionally.
One backup job failed silently for three days. The cron job ran but the destination was full. I only noticed because I happened to check the logs. Now there's a check that alerts me if a backup doesn't complete in 24 hours.
These aren't glamorous failures. They're the kind of small, boring problems that accumulate if you don't pay attention. This is the real work of running content sites—not exciting, not automated by AI, just maintenance.
What I Would Do First
If you're running small content sites and thinking about improving your setup, here's what I'd do in order:
- Get backups working and test them. Before anything else. I don't care what tool you use. Just make sure you can actually restore from a backup. I've seen too many people with "backups" that have never been tested.
- Automate deployment. If you're still FTPing files, stop. Set up Git-based deployment or use a simple CI/CD tool. It takes an hour to set up and saves time every time you publish.
- Add basic monitoring. Uptime check, SSL check, disk space alert. That's three things. You can do it with free tools or cheap hosted services.
- Then think about AI. Only after the basics work. If you can't restore from backup, if deployment is manual, if you don't know when the site goes down—AI isn't your problem.
That's it. That's the testing for this month. Nothing revolutionary, nothing that needs a blog post about it. Just the quiet work of making small sites run better, one practical change at a time.