{"id":1635,"date":"2026-10-07T08:43:34","date_gmt":"2026-10-07T07:43:34","guid":{"rendered":"https:\/\/blog.lboro.ac.uk\/rdm\/?p=1635"},"modified":"2026-10-07T10:14:27","modified_gmt":"2026-10-07T09:14:27","slug":"archiving-research-project-websites","status":"publish","type":"post","link":"https:\/\/blog.lboro.ac.uk\/rdm\/2026\/10\/archiving-research-project-websites\/","title":{"rendered":"Archiving Research Project websites"},"content":{"rendered":"\n

Written by Stevie Ashurst, Web Projects Delivery Manager at Loughborough University<\/em><\/p>\n\n\n\n

The end<\/strong><\/h2>\n\n\n\n

This seems as good a place to start as any. What happens at the end of the agreed hosting period for a research project website? The simple answer would be that it gets taken down. It stops being an active website. It is deleted.<\/p>\n\n\n\n

In most cases, this is the expected outcome when a project begins. But at the beginning, the end of a website’s life is usually years away and not much of a concern for those involved. The focus is on getting the project off the ground, delivering the research and ensuring that the website accurately conveys the right information to its target audience. And getting a brand new website noticed at all is enough of a challenge, fighting against the 1.49 billion other websites out there [1<\/a>]. But the end of a website is just as important as its beginning, and needs to be properly understood and planned for.<\/p>\n\n\n\n

What happens when the project ends?<\/strong><\/h2>\n\n\n\n

Research project websites are slightly unusual. Unlike many websites, their purpose is often tied directly to a project with a specified lifespan. Once that project has finished, the website may no longer have an active purpose.<\/p>\n\n\n\n

But that doesn’t necessarily mean that the information it contains has lost its value. Research findings may continue to be useful to other researchers. Publications may continue to reference the project. A website may provide valuable background information about how a project was conducted, or simply provide a record of work that has now been completed.<\/p>\n\n\n\n

From experience, a good number of the research project websites we have created and hosted have prompted clients to ask about some form of continued visibility after the project has ended. This might mean keeping a static HTML export for themselves, archiving the site files somewhere else, or continuing to host the website for another number of years, either with the original host or another hosting provider. Indeed, we at Loughborough University, have found ourselves being asked to continue hosting websites that originated and had already been hosted elsewhere for a number of years. So while deleting a website at the end of a project may be the simplest option, it isn’t necessarily the most appropriate one.<\/p>\n\n\n\n

The dangers of keeping a website alive<\/strong><\/h2>\n\n\n\n

There is an obvious argument for continuing to host a website: if the information remains useful, why not simply leave it online? In theory, one concern with hosting a website beyond an initial period of, for example, five years would be the relevance of the information it contains. Certain facts, assumptions or understandings may have changed since the information was first published, whether because of changes to the project itself or wider developments in the research subject. However, and probably unsurprisingly, technology and security may play a much larger role in determining whether an old website should remain online.<\/p>\n\n\n\n

Dynamic websites that use a content management system (CMS) are an obvious example. The fact that a website can be edited through a web browser, using login credentials, creates a potential vulnerability. This is compounded by the additional functionality commonly added through plugins or modules, and by themes that can alter a site’s appearance while also introducing additional functionality.<\/p>\n\n\n\n

Each of these components can have its own vulnerabilities and its own potential means of allowing malicious attacks to gain entry to a website.<\/p>\n\n\n\n

Within the Loughborough University Web and Digital team, we have largely made use of the well-known CMS WordPress. There are many alternative systems, both free and paid, but WordPress is widely used and supported, making it relatively straightforward for both developers and content editors to work with. Being the most widely used CMS in the world [2<\/a>] also means that many people are likely to have some familiarity with it. That widespread use, however, has another side to it. A vulnerability affecting a widely used system potentially provides an opportunity to compromise a large number of websites. Keeping a site secure therefore relies not just on the security of the original system, but on continued updates and maintenance. This is one of the reasons that simply leaving an old website online indefinitely isn’t necessarily a sensible form of archiving.<\/p>\n\n\n\n

Technology doesn’t stand still<\/strong><\/h2>\n\n\n\n

The emergence of AI has added another layer to the security picture, although this isn’t entirely one-sided. AI has been used both to identify and exploit vulnerabilities and by developers to help identify and address vulnerabilities that might otherwise have been missed [3]<\/a>. The result is a security landscape that is becoming more significant and rapidly evolving. And it isn’t only the CMS itself that can become a problem. Vulnerabilities can also be found in older JavaScript libraries and other dependencies. This means that even a seemingly secure static HTML website could potentially contain outdated and vulnerable code [4<\/a>]. A website that was perfectly reasonable to host five or ten years ago therefore cannot necessarily be assumed to remain safe simply because nobody has changed it.<\/p>\n\n\n\n

In some respects, an old website is rather like an old building. The fact that nobody is using it doesn’t mean that it stops needing maintenance.<\/p>\n\n\n\n

Accessibility<\/strong><\/strong><\/h2>\n\n\n\n

As technology advances, so does an understanding of how this impacts users who may have challenges in accessing the information being presented on a website. Whilst most principles are fundamental, the ways to achieve accessibility for content changes over time. Older websites need to be reviewed in terms of their accessibility for current requirements [5<\/a>], which were not necessarily considered when the site was built. Even if the site meets current standards, a request for the website to continue running may fall foul of future changes in requirements, if so, whose responsibility is it to make these changes?<\/p>\n\n\n\n

Carbon footprint<\/strong><\/h2>\n\n\n\n

All websites generate a carbon footprint because of the energy used by computers in developing the website, by data centres in hosting and serving the website to viewers across the globe and of course energy is used at the other end when users view the website [6<\/a>]. So continuing to host a website beyond its useful lifespan, still contributes to the impact on the environment, especially if this website is user older and less streamlined images and media.<\/p>\n\n\n\n

Preserving the legacy<\/strong><\/h2>\n\n\n\n

There are several ways of preserving a research project website, and the appropriate option will depend on what the website is intended to achieve after the project has finished. If the aim is simply to preserve a record, a static copy of the website may be sufficient. The files can be archived and stored somewhere appropriate, either privately or publicly. Compressing the files into a ZIP archive also means that potentially vulnerable scripts cannot be directly accessed as part of a live website. If continued public visibility is important, a static version could potentially be hosted separately from the original CMS-driven website. This removes many of the risks associated with maintaining a live, editable system while retaining the information for future visitors.<\/p>\n\n\n\n

Another option is to retain the original website in an environment that is not publicly accessible, allowing it to be preserved for reference without exposing it directly to the wider internet. There are also established online archiving services. If a website has a reasonable search engine ranking, it may have been automatically recorded by the Wayback Machine, a non-profit digital archive and library that records snapshots of websites over time. Other online tools and services offer private or public archival options, with varying prices to match. The difficulty is that there is no guarantee that any particular service will remain available or relevant indefinitely. Today’s solution may itself become obsolete, replaced by something better in the future.<\/p>\n\n\n\n

A case-by-case decision<\/strong><\/h2>\n\n\n\n

The reality is that there isn’t a one-size-fits-all solution for research project websites. Each site needs to be considered on a case-by-case basis, taking into account its content, target audience, budget and connection to other relevant research. But recent experience with the vulnerabilities of web technology means that security needs to play a significant part in that decision. The important question isn’t simply: “Should we keep this website?”<\/strong> It is: “What do we need to preserve, who needs to access it, and what is the safest way of doing that?”<\/strong> Sometimes the answer will be to keep the website running. Sometimes it will be to create a static version. Sometimes the most appropriate solution may simply be to archive the files and remove the website from the public internet altogether. Whatever the outcome, the end of a research project website shouldn’t be an afterthought. Websites have always been built on changing technology, but as that technology becomes more complex, the process of bringing a website to an end needs to be considered just as carefully as the process of bringing it to life. So when a new research website is commissioned, one of the questions that should be asked right at the beginning is: “What happens when this website reaches its end?”<\/strong><\/p>\n\n\n\n

More information<\/strong><\/h2>\n\n\n\n

If you would like to know more about these issues, or to discuss current or potential new website development, you can contact the Web Team, within Marketing and Advancement.<\/p>\n\n\n\n

Loughborough University Web Team<\/strong><\/a><\/p>\n\n\n\n

References<\/strong><\/h2>\n\n\n\n

[1] How many websites are there on the internet in 2026?<\/strong>, 9 August 2026. https:\/\/musemind.agency\/blog\/how-many-websites-are-there<\/em><\/a><\/em><\/p>\n\n\n\n

[2] WordPress is recognised as the most widely used CMS in the world. Let\u2019s examine its success<\/strong>, 3 April 2025. https:\/\/www.michelebedin.com\/en\/wordpress-most-widely-used-cms-in-the-world-lets-examine-its-success\/<\/em><\/a><\/em><\/p>\n\n\n\n

[3] AI Security in WordPress – Vulnerabilities, Threats, and the Cyber Resilience Act<\/strong>, 15 April 2026. https:\/\/weboptimo.pl\/en\/know-how\/wordpress-ai-security<\/em><\/a><\/p>\n\n\n\n

[4] Outdated Javascript Libraries: Why Old Dependencies Are a Security Risk<\/strong>, 27 April 2026. https:\/\/websentry.dev\/blog\/outdated-javascript-libraries-security-risks\/<\/em><\/a><\/em><\/p>\n\n\n\n

[5] Legacy Applications and Accessibility<\/strong>, 9 June 2020. https:\/\/www.deque.com\/blog\/legacy-applications-and-accessibility\/<\/em><\/a><\/p>\n\n\n\n

[6] How slimmed-down websites can cut their carbon immersions<\/strong>, 7 March 2023. https:\/\/www.bbc.co.uk\/news\/business-64623955<\/em><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Written by Stevie Ashurst, Web Projects Delivery Manager at Loughborough University The end This seems as good a place to start as any. What happens at the end of the agreed hosting period for a research project website? The simple answer would be that it gets taken down. It stops being an active website. It […]<\/p>\n","protected":false},"author":720,"featured_media":1638,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"lboro_blog_alternative_thumbnail_image":"1638","footnotes":"","_links_to":"","_links_to_target":""},"categories":[122],"tags":[91,195],"class_list":["post-1635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-archives","tag-research-repository","tag-website-archiving"],"_links":{"self":[{"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/posts\/1635","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/users\/720"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/comments?post=1635"}],"version-history":[{"count":4,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/posts\/1635\/revisions"}],"predecessor-version":[{"id":1640,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/posts\/1635\/revisions\/1640"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/media\/1638"}],"wp:attachment":[{"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/media?parent=1635"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/categories?post=1635"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/rdm\/wp-json\/wp\/v2\/tags?post=1635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}