Phase 1: Go live<\/h3>\n
![](\"https:\/\/i.stack.imgur.com\/tM18j.gif\")
Before it’s visible to the public, most websites spend a few days, weeks or months in an inchoate state. Some websites never actually go live as the need for them goes away, or they turn out to require more work than anticipated.<\/p>\n
Phase 2: Actively maintained<\/h3>\n
This is the time when the owners of the site care about it and keep it updated. The end of this phase can be very clear or interest wanes.<\/p>\n
For research project websites people’s funding ends on a date, and few people want to put much effort in after this date. For conferences and other events, the actively maintained phase ends at the end of the event or soon after.<\/p>\n
Many sites should be formally retired at the end of this phase, but people keep them around, just because.<\/p>\n
Phase 3: Embalming<\/h3>\n
Why would a website need to exist past the period it’s actively maintained? Often it shouldn’t and the lifecycle should proceed rapidly to the “interred” and “cremated” phases, but there’s plenty of good reasons to keep some sites around:<\/p>\n
- \n
- Many research funders make a requirement that websites for a project should stick around for 3, 5 or 10 years after the end of a project.<\/li>\n
- Some sites provide a public record that an event or project happened, what the outcomes were and who was involved. For major events and projects, this may be the source-of-truth for Wikipedia, historians, and future researchers.<\/li>\n
- Extending the previous point, discovering past work can lead researchers to new research contacts, collaborations and other opportunities.<\/li>\n
- Finally, and the most important one: As a university, our job is to increase and spread knowledge. The cream of our websites do this in large and small ways. A simple example is the “Music in the Second Empire Theatre<\/a>” website I just worked on. You can read my blog post<\/a> about it. The information on this website could be valuable to music researchers centuries from now.<\/li>\n<\/ul>\n
![](\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/c\/cc\/Mummy_at_British_Museum.jpg\/1920px-Mummy_at_British_Museum.jpg\")
Appropriate steps for the preservation of a website can prevent it going rotten later on.<\/p><\/div>\n
Something I’ve given a lot of thought to lately is how to reduce the long term support costs of interactive research outputs. Right now we’re having an incident every two weeks or so where some ancient VM goes to 100% CPU and it’s hard to resolve as it’s the research-output of someone who’s left or retired, and still of value, but maybe not worth the cost if it’s causing lots of work to keep up and running.<\/p>\n
Old systems like that are also a bit of a horror story we tell young information security specialists. They can also be a, er, challenge to GDPR audit and secure against hackers.<\/p>\n
Some sites and services should be preserved indefinitely but to do that they need to have no back-end dynamic code and be easy to shift to a new URL as really long term preservation will probably mean moving into some kind of repository.<\/p>\n
When a site is at the end of it’s “active” life we need the site owner to decide if it’s going to be shut off or preserved. If it’s to be preserved then we should be expecting the site owner to do some work to prepare it. This is where we really drop the ball — we ned to make this chore understood and accepted as the price of having your website preserved beyond it’s “actively maintained” phase.<\/p>\n
For conferences, removing irrelevant information and removing future tense where it looks silly.<\/p>\n
For research projects this would be to remove any private areas (not an issue for more recent projects which tend to use services for sharing files and conversation rather than .htaccess protected directories and wikis). Research projects also need to remove any placeholder pages for planned information which will never be created, and link to outcomes and publications.<\/p>\n
This step is a big challenge as it’s boring and unrewarding for the people who need to do it. Often the end of the project is either a race to hit deliverables or a time when it’s hard to care as you’re about to lose your job. After a big event like a conference, it can be hard to find the energy to tidy up the website for posterity.<\/p>\n
Phase 4: Fossilisation<\/h3>\n
For dynamic websites, and blogs, using things like node.js, .net or php,\u00a0 this would mean turning the site to static files. Static .html files are at virtually no risk of being exploited by hackers and much less risk of breaking when a server has to be upgraded to a new version of PHP (or whatever back end you use), so making long term support much lower cost.<\/p>\n
![](\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/9\/9d\/Archaeopteryx_lithographica_%28Berlin_specimen%29.jpg\/1024px-Archaeopteryx_lithographica_%28Berlin_specimen%29.jpg\")
I like to think of this process as fossilisation. The new site is the same “shape” as the site you copied, but it’s lifeless and rock solid and should last a very long time.<\/p>\nThe tool “wget” (as seen in The Social Network<\/em>) is great for turning websites into fossilised versions. It can even rewrite the links to pages, images, javascript etc. to be relative links so they work on a new web location, or even a local filesystem. The one thing it can’t do is edit the filenames inside javascript code, so really fancy stuff may require some manual intervention after the site is crawled.<\/p>\n
When serving a fossilised site, the MIME type<\/a> of each file is not recorded, and the new webserver will guess the MIME type based on filename. This can be a bother if you had something odd going on, like PDF files that didn’t end in “.pdf”. A more long term solution is to save the website as a single huge WARC file. I’ll explain more about that in the repository phase, but the important thing to know here is that it stores the retrieved MIME type with each file, and wget <\/em>will generate such a file.<\/p>\n
One tip, from embarrassing experience: before creating such a “fossilised” site, make sure that hackers haven’t already done anything to the site!\u00a0 I was responsible for a website for a major conference<\/a>, which had a very naive “upload your slides” PHP function. Many years after I turned it all to static files, we discovered some cheeky person had uploaded some spam documents amidst the valid content! So a check for stuff like that is recommended, especially for old wikis.<\/p>\n
For sites at this stage I have started using apache to inject a <script> tag which<\/p>\n
Phase 5: Placed in a repository<\/h3>\n
The very long preservation of things isn’t really a job for the IT or Comms department. This is a job for librarians and archivists. While this is currently rare, in future more websites may be preserved in institutional repositories, like EPrints, D-Space, PURE etc.<\/p>\n
![](\"https:\/\/www.timeshighereducation.com\/sites\/default\/files\/Pictures\/web\/c\/x\/e\/raiders_of_the_lost_ark_warehouse_scene.jpg\")
These repositories may or may not make the deposited website visible to the general public. The long term value of preserving the information then becomes a decision for people with appropriate training. Some sites may be important to preserve for future generations, and which ones may be hard to decide, but the IT department can help by making such preservation cheaper and lower risk.<\/p>\n
![](\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/7\/7a\/Cheops_pyramid_01.jpg\")
People can be very nervous about destroying data so it may be useful to offer to take a site offline, but keep the data, and place a useful message at it’s previous location for a period of time. Say 6 months or 12 months. At the end of this time, if nobody has actually needed the content it gets destroyed.<\/p>\n![](\"http:\/\/globalflare.com\/wp-content\/uploads\/2015\/12\/darth-vader-burning.jpg\")
I like the metaphor, even if it’s a bit morbid. There is a point where a website is gone and we have destroyed all copies of it under our control. This sounds a bit dramatic, and it is. We want people to understand that after this point it’s gone and they can’t get it back. This step is most important on sites with a data protection issue.<\/p>\n