Four reasons to delete at least 95% of your website
The web is an archive – a vast, sprawling record of everything you ever posted, chaotically categorised, linked to a handful of the other billions of published bits and pieces.
We don’t like the idea of deleting anything we post, and there’s a special term for allowing links to wither and die: link rot. Indeed, it can be difficult to expunge content entirely, as the Way Back Machine indexes the things you wrote years ago. And anyway, it’s far better to have all this information available digitally rather than on paper, right?
Still, I think it’s worth questioning the value of all this stuff. Just because it takes little physical space doesn’t mean it’s problem free. Here are four reasons to carry out a spring clean of all those posts you’ve made over the last 13 years.
1. Old content can provide inaccurate information
This is especially true in technical fields, such as front end web development. While some advice is timeless, and will remain true until the end of days, most of those exciting CSS tips date in a matter of months.
More seriously, some information is just out of date. 12 years ago I published a popular WordPress theme (the first responsive theme published in the official directory, no less). I can safely say there are now better options out there, but the page announcing Scherzo still sits on this site, attracting search engine traffic.
2. More content makes it harder to find good quality information
Anyone who runs a large scale website knows how important search is. Now, there are many ways to implement good quality search that indexes hundreds of thousands of pages, but you will always get better results if the pool of available information has been kept up to date. Fewer, better quality search results increase the searcher’s confidence in what they’re clicking through to.
There are lots of examples of out of date pages clogging up search indexes. Perhaps the worst (and I’m not unguilty of this) are events. By its nature, an event loses 99% of its interest once it’s passed, so we should automatically delete old events from our websites, thereby making it easier to find events that are still to take place.
3. More content requires more management
If you’re managing a website the chances are you’re running some form of periodic content audit, which you’ll use to make decisions about what you’ve published.
Often your audit will take place in a spreadsheet. It is far easier to use, review and filter a spreadsheet with 200 rows compared to one with 200,000. It is of course possible that those 200,000 pages are of value to the outside world, but often they’re simply there because no-one’s bothered deleting them, or there’s a misguided view that any deletion is bad. Perhaps some day, someone, somewhere will find the post useful?
Content proliferation can be a sign of a culture that values simple production over outcomes.
The primary purpose of a content audit should be to reduce the size of what you’re auditing.
4. More content is bad for the environment
If the internet was a country, it would be the seventh largest polluter on the planet. All that hosting produces a huge amount of energy.
There are lots of ways to reduce your site’s carbon footprint, which also improve user experience. Don’t automatically reach for a large javascript framework, generate static pages, use webfonts sparingly, optimise images, use a thousand words instead of an image, don’t publish huge PDFs instead of web pages etc. etc.
Of course, the most environmentally friendly website is no website at all, but let’s assume you need some form of web presence. Simply reducing the number of pages you produce will reduce your environmental impact.
Further reading
Your first port of call for all things web content excision is definitely Gerry McGovern, ironically enough a stellar example of someone whose content remains useful over time.
Previous post Navigation submenus – what’s the best approach? Dropdown, hovers, clicks or keeping it flat?
Next post Edit your RSS feed to control your site’s output to micro.blog