How much do you spend on your website? I'm not asking how much it cost you to create/build -- I mean day to day, what does it cost to own and maintain your site?

And what happens if you stop paying that?

The costs of running a website

Let's break down the kinds of expenses you may have for your website:

  • Domain name -- without a domain name, you don't exist online.
  • Hosting -- without a host, you don't have a website.
    • Disk storage, processing, electricity, bandwidth -- this is usually part of your hosting.
  • Server maintenance -- may or may not be part of your hosting
  • Website maintenance -- which may mean a bunch of different things:
    • Code updates for active CMS sites and other web applications
    • Testing updates, checking for issues
    • Resolving conflicts and things that break with updates
    • Monitoring -- making sure it's available, and responds quickly
    • Security scans, checking for attacks
    • Updating sites to support new browser versions, new ways of browsing
    • Managing backups
  • Content updates
    • Writing new content, producing images/audio/video
    • Editing existing content
    • Publishing content
    • Tagging content for SEO
    • Tagging content for AI, other search needs
  • Offsite activities - promoting your website content
    • Social Media
    • Paid search/advertising
    • Active promotion through other marketing channels
  • Incident response/Risk management -- costs if you have a problem
    • Cleaning up a hacked website
    • Direct costs of cleaning up a hacked site -- server rebuilds, security audits, forensics
    • Reputation costs -- if your site is used to host malware/drugs/spam
    • Regulatory costs -- if a hack leads to disclosure of personal or financial information
    • Denial of service costs -- loss of income while your site is unavailable

So how much does this all cost? Like almost everything in tech, the answer is "it depends." Depends on what? A bunch of different things -- foremost being what is your site for. What is its reason for existing, and how well is it accomplishing that goal?

Simple brochure sites

Many business owners start out thinking that their website is just an online brochure. They don't expect new customers to find them through their website. If you have other reliable sources of business, this may be fine -- although the pandemic disrupted a lot of this and made it clear having an online presence is not really an optional thing anymore.

Still, if you run down that list, there are a bunch of tradeoffs to make. Want to avoid the risks of being attacked? Make the attack area smaller -- if you never update content on your site, you don't need a content management system (CMS), and if your website is just a collection of files on a server somewhere, there is no CMS to attack. This greatly reduces your cost to keep a website running -- but it greatly increases the costs of creating new content. (There are tools you can use that make it relatively easy to manage this type of "static" website, but those take technical skills to use).

Active CMS sites

Websites can do far more than be a simple brochure. For many businesses, their website is their leading source of sales leads. Or their storefront. Or a support portal. Or event management site. Or membership site. Or all of those rolled into one!

This means their website is not just "a collection of files on a server somewhere." It's an application that takes requests, processes data, and returns responses -- and as such, can be targeted by attackers from anywhere in the world.

What if I stop paying for maintenance?

If you stop paying for hosting, or your domain name, you disappear off the Internet, pretty quickly. But if you stop paying for maintenance, nothing happens -- at least not at first.

What happens is your risk of one of those bad consequences starts going up, bit by bit. If you stop applying updates, sooner or later a vulnerability will be discovered in something you're running, and you risk having your site getting hacked. Or, your backup disks fill up and stop backing the site up -- and then when a drive fails you've lost all your recent content. Or, a change in browser standards makes your site layout go wonky on new browsers. Or, a new AI bot starts hammering your site and makes it unavailable (this is happening more and more, even with maintenance -- but having someone available to track down and combat it is becoming more important).

There is also "opportunity cost" you could miss out on. We focus primarily on websites built with Drupal or WordPress. Both have been adding features to make their platforms easier to use -- and if you're not taking advantage of these, your competitors might!

Can't I do the maintenance myself?

WordPress has had automatic updates in core for a while now, and Drupal is on the verge of having that as well. This does make keeping your site up-to-date with code updates a lot easier for a lay person.

However, as a security-minded technologist, I see automatic updates as a disaster waiting to happen. The recent CloudStrike outage is a perfect example of this, along with the growing list of supply chain attacks that have plagued large businesses for years now.

Here's the thing: web applications running on the Internet are one of the easiest things for an attacker to go after. And the more popular your platform is, the bigger the target.

WordPress is the most widely deployed web application in the world, with somewhere north of 470 million installations -- and it does not have a particularly strong security record (primarily among the 70,000+ available plugins written by amateurs and non-developers). Drupal has a much stronger record, with an architecture that promotes writing secure code and a strong security team centralizing security updates across over 14,000 modules. Both use the PHP language which has itself had some serious security vulnerabilities as recently as a couple months ago.

Auto-updates in WordPress and Drupal are like having keys visible behind a window

If you have this functionality turned on on a production site, the smallest vulnerability in your application or the language it's running on could let an attacker take over the entire system. They can easily break the glass to grab your keys, get in, hide in a closet, wait for your return. Possibly even steal your car if you left the keys for that (as in used the same weak password in multiple places). They could install their own camera to look over your shoulder as you come and go.

With some simple hardening of the production environment, we can greatly limit how much damage an attacker can do if they succeed in a simple exploit. We make it so the accounts that run the CMS code are not allowed to save any code to the disk where it might be run. This blocks both attackers, and automatic updates -- and makes your site a lot harder to do much damage, even with a successful attack.

And then we make updates in a dev site using different accounts, where we can review and test before pushing them live.

Maintenance is getting harder

It's not just Drupal or WordPress maintenance that needs attention. PHP version upgrades often cause more disruption than core updates of either Drupal or WordPress.

It's much harder to run multiple different versions of PHP than different versions of a CMS. The language is installed on the server itself. We run different versions using a tool called Docker, but when you're trying to automate testing and deployment of 80+ websites, managing different PHP version explodes the complexity involved.

Right now we run all our Drupal sites using PHP 8.1 -- but the new Drupal 11 requires PHP 8.3. And many of our WordPress sites are stuck on PHP 7.4 due to plugins that are not compatible with any version of PHP 8. PHP 7.4 went past "end of life" nearly 2 years ago, in November 2022 -- meaning there is no official support for any security vulnerabilities found in that version. And PHP 8.1 reaches end of life at the end of 2024.

We've had to spend time fixing things that break when going from PHP 5.1 to 5.3. Then to 7.1. Then to 7.3. Then to 7.4. Then to 8.1. And now we're starting to fix the breakages going to 8.3. And we need to get our Drupal 10 sites running on 8.3 before we can even start upgrading them to Drupal 11.

WordPress ends up being worse -- with so many abandoned plugins and amateur code, we often can't wait for community updates -- it's up to us to fix things to make them compatible with current PHP -- or risk the sites getting hacked through the next critical PHP vulnerability. At least with Drupal, the vast majority of modules we use get regular maintenance (sometimes from us, with some funding from our clients).

It's not just updates

In 2024, the big scourge for website owners has been AI bots.

We've been managing web servers for over 20 years. Back when we started, "Slash-dotting" was a thing -- Slashdot was a very active bulletin board that was famous for sending thousands of visitors to your website all at once, whenever your site got a mention, often taking it down due to the level of traffic. We had a client make national news for a couple weeks, and learned the basics of provisioning for high traffic back then - along with providing consulting around keeping a couple rock band sites running quickly.

For most of those 20 years, we've architected our hosting to be fast and resilient -- mostly without using load balancers or "content delivery networks", which are extra servers that distribute load while adding a lot of complexity.

Our experience goes against a lot of what the tech community considers "best practices" -- we've improved performance, lowered downtime, and drastically reduced costs by ripping out load balancers on several sites. And that's because it turns out the database is the biggest bottleneck, not the front end servers.

AI bots have been crawling our clients' sites, with bursts of traffic that take them down while they attack. After ~20 years of having to deal with the occasional DOS attack, maybe two or three a quarter, we're suddenly having to play whack-a-mole with a new crawler every 2 or 3 weeks -- and some of them don't follow the rules.

We've been developing rate-limiting strategies, adding caching servers (Redis) to offload caching from the main database, tuning services, and having to be much more hands on this year compared to previous years.

And just when I'm about to throw my hands up and say "ok maybe it's time to cave and put you on CloudFlare" (the main content delivery network that's taking over the web world), I then hear about how other sites that are using all of these premiere services are still having the same trouble themselves -- only they don't have us helping them solve the problem!

It could happen to your site

The better your site does on the Internet, the more likely you'll have an issue like this. While some of our sites do require dedicated attention because they are specifically a target, most of our sites that are just moderate traffic content sites end up getting hit with attacks like these. That's what we cover with our server maintenance plans -- the fixes we put on one site we generally apply to our other sites, so if you're on our service, you're not necessarily paying the full cost of this preventative work. However, we are having to raise our rates for this service, because it's taking a lot more work to provide it.

What are the alternatives?

So we're left with, what are your choices when it comes to these increasing costs?

  1. Go to a static website.

    As mentioned earlier, if your website is just a collection of static files, there's nothing to attack, and no maintenance needed. You still need a good host, but this drastically reduces your costs. And it also makes it harder to keep your site active and fresh, posting new content to keep new business coming in.

  2. Go to a Software as a Service.

    This is an alternative to owning your site -- rent it instead. Hosted platforms like Wix, Squarespace, Shopify, allow you to set up shop and manage your own site and content while handling all of the maintenance and security across thousands of websites. However, you don't really own the resulting site -- there are limits to what you can do with it, and it's not easy to pick it up and move to another platform.

    Many of our clients come to us after outgrowing the capabilities of these platforms.

  3. Do it yourself

    You can always bring maintenance in house. If your needs are big enough, it can be more cost effective to pay an employee to handle all the maintenance on your site. However, you need to find and pay for someone with the appropriate skills, which may well cost more than outsourcing the service to a firm that's providing it for a bunch of clients, which brings other value to the table.

  4. Ignore it all

    As mentioned, if you simply stop, you may be ok for a while -- nothing's going to break immediately. However, your site will be accruing a bunch of technical debt -- the older it gets, the more work it will be when you eventually do upgrade it, and the more risk you'll have not just of being attacked, but also that the upgrade process will get much more expensive.

    Some places just plan on rebuilding their website every few years and ignore maintenance in between. This really makes no sense to me -- why would you throw away a site that could be kept active and current, and spend tens of thousands on a replacement? Why not put that into making your current site better, instead of starting over from scratch?

  5. Focus on the value you get from your website, and accept that costs are going up.

Obviously, we think this is the right answer. The fact is, the launch of a website is one day, and websites that get a lot of regular attention tend to perform far better for their purpose than those that are neglected. If you treat your website as a property that needs upkeep, routine maintenance, a fresh coat of paint now and then, it will deliver far more value.

If we can help you keep your Drupal or WordPress site up to date, don't hesitate to reach out!

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <blockquote cite> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h1> <h2 id> <h3 id> <h4 id> <h5 id> <p> <br> <img src alt height width>
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.