After the money stops, most EU project websites die quietly. The hosting invoice goes unpaid, the CMS goes unpatched, the domain lapses, and the deliverables the site carried become unreachable. Grant agreements expect results to remain available well after the final payment, but nothing in the budget pays for that availability. The fix is decided in the proposal, not at the final review: pick one of three endings for the site (static archive, transfer to a surviving partner, or continued operation with a named owner), and write domain ownership, hosting responsibility and an archiving step into the sustainability section.
A typical dissemination site is launched in the project's first months, filled in bursts before each review, and updated for the last time just before the final report. Then the consortium disbands. The work package that owned the site no longer exists, the partner that built it has moved its developers to the next contract, and the coordinator is writing the next application. Nothing dramatic happens to the website on that day; it simply stops having an owner. Every failure that follows is an ownership failure first and a technical failure second.
We usually meet this story after the ending: a coordinator needs a deliverable for an audit or wants to cite a previous project in a new proposal, and the link resolves to a parked page offering the domain for sale.
This is a practical reading from operating experience, not legal advice; your grant agreement and programme guide are the texts that bind you.
Across Erasmus+, Horizon Europe, CERV and Interreg the pattern is consistent: you commit to disseminating results and keeping them accessible, to record-keeping for a period after the final payment so auditors can verify what you reported, and to acknowledging EU funding wherever results appear. None of these obligations names your website, and none of them ends when the hosting line does.
The Commission's own infrastructure carries part of the load: Horizon projects keep permanent pages on CORDIS, and Erasmus+ projects publish summaries and results to the programme's results platform. Upload your key deliverables there and they survive your domain. Everything else, the course materials, the toolkits, the event archives, the pages other people linked to, lives on infrastructure you pay for. The obligation continues while the funding stops; that gap is the whole problem.
The failure sequence is boringly consistent, and it is almost never a server crash.
Each step is silent: no alert, no handover meeting, no decision anyone can point to afterwards. That is what makes this an operations problem rather than a technology problem.
More than a URL disappears.
Every project site ends in one of three ways, and the proposal should say which.
Ending 1: static archive. The site is frozen into plain HTML files, hosted at negligible cost, with the domain renewed for the whole availability period. This is the correct default for pure dissemination sites.
Ending 2: transfer. The site and domain are handed to a partner that outlives the project: a university, a network, an NGO with permanent staff. The handover is written down: domain, DNS, hosting account, credentials, and the right to keep publishing the content.
Ending 3: continued operation. The platform keeps running because people still use it. This is the rarest ending and the only one that needs ongoing money and a named operator.
A CMS is an asset while there is an editor and a liability the day there is not. It needs updates, security patches and a person who cares; a static export needs almost nothing and offers almost nothing to attack. So the default for a dissemination site is static from birth or static at handover: generate the pages, freeze them, host them cheaply, keep the domain.
A living platform is warranted when the project's value is a service rather than a publication: an active membership, recurring events, a knowledge base people query, an AI assistant that answers from the project's materials with sources. Those things justify operation, and operation means an operator: someone contractually responsible for uptime, backups, security and content, with a budget line attached. That is the operating model we work in. The honest test: if no partner will own the platform after the grant, it becomes an archive when the grant ends. Impactful, the community platform we run for the Founders community in Cyprus, is a platform with a standing operator that outlives any single funded initiative running on it.
Whatever ending you choose, two rules hold. The domain belongs to the coordinator organisation: institutional registrar account, institutional card, renewal alerts to a role mailbox such as projects@, never to a person. And access is never singular: registrar, DNS, hosting and CMS credentials live in a shared vault, with named administrators at two different partners. People leave; institutions and role mailboxes stay.
Paste this into the proposal's sustainability section and fill in the brackets. At proposal stage it costs a paragraph; in the project's final months it costs a negotiation between partners who are already gone.
StrandsUnited designs, builds and operates platforms for EU cooperation projects and communities, so we inherit websites at every stage of this lifecycle. We also maintain a consortium graph of 114,731 organisations and 83,490 projects built from CORDIS and Erasmus+ open data (2014-2027), and following project links out of that graph is a daily reminder of how many published results are already unreachable. The checklist above is the one we wish every proposal we inherit had contained.