Posted on

The maintenance burden of running a personal website

A personal website gives you control because nobody else is quietly doing all the annoying parts for you.

That is both the feature and the trap.

Running an independent site can involve domain renewal, DNS, hosting, backups, software updates, security patches, spam filtering, broken links, image storage, certificates, theme changes, database maintenance, accessibility problems, and the occasional mystery where something worked yesterday and now produces a white screen.

None of those jobs are the reason most people wanted a website.

They are simply the rent charged by independence.

The IndieWeb community, which strongly advocates owning one’s online identity and publishing space, is unusually frank about this problem. Its documentation on personal domains lists setup and maintenance difficulty as a real barrier, specifically mentioning domain registration, DNS, hosting, misconfiguration, and the technical overhead involved. See IndieWeb’s personal-domain documentation.

Platforms remove chores by removing choices

Posting inside a large social app is operationally easy.

The user does not renew TLS certificates, patch the database, investigate PHP compatibility, fight comment spam at the server level, or wonder whether the domain registrar’s renewal email went to an abandoned inbox.

The platform absorbs those tasks.

In exchange, it controls the interface, account rules, recommendation system, export options, advertising environment, and sometimes whether the account exists next year.

A personal website reverses that trade.

The publisher owns much more of the stack and therefore inherits much more of the work.

Small maintenance failures accumulate

Most personal sites do not need an operations team.

That does not mean they require zero attention.

A domain card expires. A plugin becomes incompatible. A server version reaches end of life. A contact form becomes a spam cannon. An image host changes policy. A certificate renewal fails. A database backup has not been tested since the Bush administration.

Each problem is usually manageable by itself.

The burden is that the problems keep arriving while the site owner also has a job, family, hobbies, illnesses, moves, and years in which writing a new page is simply not the most important thing happening.

Easier systems solve real problems

Hosted website builders, managed WordPress, static-site hosts, newsletter platforms, and social apps can remove large parts of this operational burden.

They do not remove every tradeoff.

The more infrastructure someone else manages, the more the publisher depends on that provider’s continued pricing, policies, export tools, and existence.

This helps explain one part of The Human Retreat — Where Everybody Went.

Some people stopped updating personal sites because they stopped wanting to publish.

Others kept publishing constantly, but moved to places where uploading a photograph did not begin with checking whether the server needed updates.

The personal web did not lose every author to apathy.

Some of them got tired of being their own unpaid IT department.

Posted on

Blogrolls as personal recommendations with visible authorship

A blogroll is an algorithm with a human name attached to it.

It is usually just a list of websites, writers, feeds, or projects that one publisher reads or recommends. The IndieWeb page on blogrolls describes them plainly as lists of sites a person reads, follows, or recommends, and documents modern examples that are still being maintained.

That simplicity gives blogrolls a property modern recommendation systems often hide: visible authorship of the recommendation itself.

If I click a link because it appears on someone’s blogroll, I know who made that choice.

The bias is obvious because the person is obvious

A blogroll is not neutral.

It reflects one person’s interests, friendships, habits, professional circle, blind spots, and changing attention. Someone who reads mostly programming blogs will produce a very different map of the web from someone who follows experimental music or antique radios.

But the source of that bias is inspectable.

A reader can ask: Do I trust this person’s taste? Why might they recommend these sites? Are all the links from the same social circle? Has the list been updated recently?

That is a different relationship from a recommendation labeled merely For You.

A platform can recommend an excellent site without exposing why it was selected. A blogroll exposes at least one important piece of context immediately: this particular person thought the site was worth linking.

Maintenance is the weak point

The cost is upkeep.

People stop publishing. Domains die. A writer’s interests change. Lists become fossils.

The IndieWeb documentation itself includes both active and dead blogroll examples, which is useful evidence of the mechanism’s limitation. Human curation ages unless humans keep curating.

There is also no guarantee of breadth. One person’s list can be wonderfully specific while missing entire communities.

Yet that narrowness can be useful.

A strong blogroll is not trying to summarize the web. It is a trail left by a person through the parts of the web they actually value.

Some current blogrolls even publish OPML files so a reader can import many recommended feeds directly into an RSS reader. That turns the list from a static sidebar into a portable discovery path.

Dead Internet Theory often asks why the web feels less personal.

Part of the answer may be that discovery itself became less personal in the old sense of the word.

A blogroll does not say people like you also liked this.

It says something much more concrete:

I liked this. Maybe you will too.