Keeping Research Catalogues Online: Choosing Reliable Web Hosting
Research catalogues are built to last. A museum's collection database, a university library's special collections index or a lab's dataset register is meant to be cited in papers and theses for decades. Yet the hosting behind it is often chosen as if it were a temporary project website, and the catalogue quietly disappears when a grant ends or a server dies.
Reliability for a catalogue means something specific. The records must stay reachable at the same addresses, search must keep working as the collection grows, and the data must outlive the people who built it.
What makes catalogue hosting different
Most websites care about speed and uptime this month. A catalogue also has to care about the address of each record twenty years from now, because citations, footnotes and other catalogues point to those exact URLs. Changing the URL structure during a redesign breaks every external reference at once.
A hosting provider such as Jump.BG can supply the foundations a catalogue needs, including a stable server configuration, SSL certificates, daily backups and support that answers on a human timescale. The institution still has to decide what it will keep stable and for how long. Write down the URL pattern for records and treat it as a commitment.
Catalogues also behave differently under load. Traffic is usually modest, then spikes when a paper citing the collection gets attention or a teaching term begins and a class of 300 searches the same records. Database-heavy search pages suffer most, so load test them along with the homepage.
The scale of link rot
Digital decay is measurable. A Pew Research Center study of disappearing online content found that 38% of webpages that existed in 2013 were no longer accessible a decade later, and a quarter of all pages sampled between 2013 and 2023 had vanished.
The breakdown is useful for anyone running a catalogue. Of that quarter, 16% of pages disappeared from sites that were otherwise still working, while 9% were lost because the whole domain had stopped functioning. Most loss, in other words, comes from individual pages being moved or deleted on living sites, which is exactly what happens when a catalogue is migrated carelessly.
Catalogues have a structural disadvantage here. Their records are deep pages, several clicks from the homepage, and they depend on external links far more than on internal navigation menus. When a record URL breaks, staff rarely notice, because they reach records through search. The person who notices is the student following a footnote, and that student usually gives up.
The same study found that 54% of English Wikipedia pages contain at least one reference link pointing to a page that no longer exists. Research catalogues are among the sources such references cite, so each broken record URL damages work far beyond the institution that hosts it.
Choosing the hosting tier
Small catalogues built on Omeka, AtoM or a WordPress-based collection plugin can run comfortably on a good shared plan when the collection holds a few thousand records with modest images. Once the catalogue includes tens of thousands of high-resolution scans, an IIIF image server or a full-text search engine such as Solr or Elasticsearch, a VPS becomes the realistic minimum.
Requirement
Shared hosting
VPS
Dedicated server
Small catalogue, light images
Good fit
More than needed
Excessive
IIIF image server
Usually not supported
Good fit
Good fit
Full-text search engine
Rarely allowed
Good fit
Good fit
Scan archive in terabytes
Not practical
Possible with extra storage
Good fit
Staff skills required
Minimal
Linux administration
Linux administration
Pick the tier for the catalogue's expected size in three years. Migrating a live catalogue carries far more risk than paying a little more for headroom now, and every migration is a chance for record URLs to break.
Storage is the line item that grows fastest. Ask how much extra disk costs per 100 GB and whether it can be attached without moving to a bigger plan.
Backups that survive the people who made them
Catalogues often outlive their creators' contracts, so backups need to make sense to someone who has never seen the system. A database dump with no documentation of the schema, the software version or how image files map to records is close to useless five years later.
Follow the 3-2-1 approach of three copies of the data on two different types of storage, with one copy off site. The hosting provider's snapshots count as one copy. A second can sit on institutional storage, and a third in a separate cloud bucket or with a partner institution.
Export the records in an open, documented format as well, such as CSV with a data dictionary, Dublin Core XML or JSON. If the catalogue software is abandoned, the records can still be imported into whatever replaces it.
Write a one-page recovery guide and store it with every backup copy. It should list the software and version, the server requirements, the order in which to restore the database and media, and a contact at the hosting provider. Test it by asking a colleague who did not build the catalogue to restore it on a spare server, and record how long the restore takes.
Check file formats as part of the routine. Master scans stored as uncompressed TIFF or lossless JPEG 2000 remain readable for decades, while derivatives in a proprietary viewer format may not open once the vendor disappears. Record checksums for master files too, so silent corruption on any copy can be detected and repaired from another.
Keeping URLs alive through migrations
Every catalogue eventually moves to new software, and the move is where most link rot happens. Plan the redirects before anything else. Export a list of every record URL from the old system, map each one to its new address and implement permanent 301 redirects at the web server level.
Persistent identifiers add a second layer of protection. DOIs for datasets or ARKs for cultural heritage objects give each record an identifier that resolves through a central system, so only the resolver entry needs updating when hosting changes. Even without them, a plain pattern like /record/12345 that never includes software names or file extensions is far easier to preserve than /omeka/items/show.php?id=12345.
After the migration, run a link checker against the old URL list monthly for a year. Broken redirects surface slowly, as rarely visited records finally get requested by a reader following an old footnote.
Keep the redirect map under version control alongside the server configuration, so the next migration starts from an accurate list.
Funding the long tail
Grants pay for building catalogues and rarely for keeping them online. Hosting costs are small compared with digitisation budgets, yet they are the first thing to lapse when a project ends and the team disperses. Build at least five years of hosting into the original grant, or secure a commitment from the institution's IT budget before launch.
Pay attention to the domain as well. A catalogue on a project-specific domain dies when the renewal goes unpaid. Hosting it on a subdomain of the institution's main address, such as collections.uni-example.bg, ties its survival to a name the institution will never let expire.
Assign a named owner for the catalogue in the institution's records, defined as a role instead of a person, so responsibility passes on automatically when staff change. The owner signs off on renewals, approves migrations and keeps the redirect map current.
Plan for the end as well. If the institution ever decides to retire the catalogue, deposit a full export with a national library or a trusted digital repository, and point the old domain to a page explaining where the records now live.
