I've got three small content sites running—two niche blogs and a documentation project for a side project. They're not making anyone rich, but they cost money to host and take time to maintain. That's why I'm always testing ways to reduce the operational drag without turning them into AI-generated spam farms.
This month, I'm running a few practical experiments across these sites. Nothing glamorous. Some will probably fail. Here's what's on the test bench.
Automating the Tedious Parts Without Losing Your Mind
The biggest time sink on any content site isn't writing—it's the stuff around writing. Formatting, image handling, metadata, internal linking. For my documentation site, I spent hours manually updating YAML frontmatter every time I added a new page.
This month I built a small Python script that pulls from a Google Sheet where I draft content. It generates the Markdown files with frontmatter already populated—title, date, tags, canonical URL. Nothing fancy, just pandas reading the sheet and python-frontmatter writing files.
The script takes about 15 seconds to run. Before, I was spending 10-15 minutes per post doing metadata manually. That's not huge, but it adds up when you're publishing weekly.
The catch: the Google Sheet approach only works if your workflow already fits a spreadsheet. If you're writing in Notion or directly in Markdown, this adds a step instead of removing one. Know your actual process before automating.
Testing LLMs for First Drafts—Carefully
I'm not using AI to generate posts and pretend a human wrote them. That's not what this is about. What I'm testing is using a local LLM (running on a spare desktop I have) to help me restructure rough notes into something readable.
I take my scattered notes—bullet points, half-sentences, code snippets—and dump them into the LLM with a simple prompt: "Make this readable. Keep the technical details. Don't add fluff." Then I review what comes out and rewrite about 40% of it anyway.
The experiment is answering a specific question: does this save time compared to writing from scratch?
So far, the answer is "sometimes." For straightforward tutorials where I already know the steps, the LLM gets me 60% of the way there in five minutes instead of thirty. For opinion pieces or nuanced posts, it often produces bland content that needs more work than starting fresh.
Failure mode I'm seeing: the drafts come out technically correct but soulless. Readers won't know AI helped, but they'll notice it's forgettable. I'm keeping this in the "tool in the shed" category rather than a default workflow.
Hosting Cost Experiments
Two of my sites are on a $5/month DigitalOcean droplet. That's fine—it's reliable and I've got it automated with Ansible so I can rebuild it in 20 minutes if needed. But I'm testing whether I should move one of them to something cheaper.
The candidate is my smaller blog, which gets maybe 300 visits a month. It's a static site generated with Hugo. I'm testing Cloudflare Pages as the host. Free tier handles this traffic easily, and the deploy pipeline connects to GitHub so I push and it builds.
The tradeoff is losing some control. On the droplet, I can SSH in, tweak things, run scripts. On Cloudflare Pages, I'm dependent on their build system and worker limits if I want anything dynamic. For a static blog, that's fine.
For the documentation site, I'm staying on the droplet because I've got custom nginx configs and some server-side logic I need. Moving that would take more time than it's worth.
What Actually Matters in Analytics
I've been through the analytics rabbit hole multiple times. Google Analytics, Plausible, Fathom, simple server logs. This month I asked myself a question I should have asked years ago: what decisions does analytics actually change for me?
The answer, honestly, is "very few."
For these small sites, I mostly care about:
- Is anything broken? (I use a simple uptime check)
- Which posts get any traffic at all? (Server logs tell me this)
- Are people actually reading, or just bouncing? (I glance at time-on-page occasionally)
I don't need conversion funnels. I don't need heatmaps. I don't need to know that someone from a specific city visited at 2am.
So I stripped analytics off one site entirely and left another running the simplest possible solution—a self-hosted Plausible instance on the same droplet. It costs me basically nothing extra and gives me the two metrics I care about.
If you're running analytics on a small site and you can't name three decisions you've made because of the data, you're probably overcomplicating things.
The Maintenance Reality Nobody Talks About
Here's the part of content sites that nobody writes blog posts about: eventually, things break. Plugins stop updating. Hosting providers change their APIs. Your static site generator has a security vulnerability. You get a spam wave that floods your comments.
I'm testing a more aggressive approach to this: deliberate abandonment protocols.
For each site, I've started documenting what I'd actually do if I stopped maintaining it tomorrow. Can it go read-only? Can it be archived to a simple HTML export? What's the minimum viable version that still provides value?
This sounds pessimistic, but it's practical. Two years ago, I let a site rot because I didn't have time to update its WordPress install, and the plugin vulnerabilities made it a liability. I should have switched to static HTML six months earlier.
Right now I'm testing whether one of my blogs can be converted from a dynamic CMS to a static export. The content would be frozen—no new posts—but it would stay online indefinitely without maintenance. That's a feature, not a failure.
What I Would Do First
If you're running small content sites and feeling the drag, here's where I'd start:
- Audit your time. Track what you actually spend doing for a week. Writing might be 20% of it. The rest is formatting, promotion, maintenance, and fighting with tools. Automate the stuff that isn't writing.
- Cut analytics. If you can't explain why you're collecting data, stop. Most small sites don't need it.
- Know your abandonment point. Document what happens when you can't maintain the site. Plan for that scenario. Static exports are your friend.
- Test one thing. Don't rebuild your entire workflow. Pick one repetitive task and try automating it for a month. See if it actually saves time.
The goal isn't to build something impressive. It's to spend less time on maintenance and more time on whatever made you start the site in the first place.