Running seven academic conference sites — Case study

The situation

Academic conference websites are strange things to maintain. They are public-facing for a few intense months, they carry information authors depend on to submit and register, and the dates on them are immovable — a submission deadline cannot slip because a page is broken. Between cycles they sit largely untouched, which is how they accumulate problems.

I took over seven of them across five domains, each built at a different time by different people, with no shared stack, no documentation and no handover. They run on ordinary shared hosting — Linux, cPanel, Apache, SSH — rather than anything with a deployment pipeline.

What I inherited

The first job was working out what was actually there, which took longer than fixing most of it. Broadly, the problems fell into four groups:

Correctness. Dates, committee listings and submission instructions that had drifted out of step with what organisers were telling authors elsewhere.
Accessibility. Pages that were unusable with a keyboard or a screen reader — a genuine problem for a conference audience, and one that most visitors never report.
Accumulated weight. Years of superseded files still being served, slowing sites down and making it hard to tell what was current.
Security and exposure. Inherited configuration that needed auditing and tightening.

How I approached it

Correctness before everything else

A slow page irritates people; a wrong deadline costs someone a submission. I worked outward from the pages authors actually act on — dates, submission instructions, registration — and only then to everything else. Anything that could send an author down the wrong path got fixed first.

Back up, change, verify — every time

With no staging environments and no rollback, the discipline had to come from process instead. Every change is preceded by a backup and followed by verification of the live result. It is not sophisticated, but it is the difference between a bad edit being an inconvenience and it being an incident during a submission week.

The constraint that shaped everything: there is no maintenance window. A conference site is busiest exactly when its deadlines approach, which is also when it is least forgiving of mistakes. Every decision was made with that in mind.

Accessibility as part of the work, not a project

Rather than treating accessibility as a separate remediation effort that would never get scheduled, new and edited pages are brought up to WCAG 2.1 AA as they are touched. The estate improves steadily without anyone having to approve an accessibility initiative.

Matching the house style

Each site has its own established design. New pages are built to the existing system rather than to my preferences — a conference site should look like itself, and a visitor should not be able to tell which pages I built.

What changed

Author-facing information is accurate and verified ahead of publication, not corrected after someone complains.
New and revised pages meet WCAG 2.1 AA, so the estate improves with every cycle instead of degrading.
Sites load faster, with superseded material no longer served.
Inherited security and configuration issues have been audited and addressed.
There is now a single point of contact who knows all seven sites, which is the part organisers actually notice.

What I would do differently

I would have written the inventory down sooner. I spent the first weeks rediscovering the same facts about which site did what, and a plain list of hosts, stacks and quirks would have paid for itself within days. I would also have pushed earlier for a staging copy of at least the busiest site; the back-up-and-verify discipline works, but it is a substitute for an environment I should have asked for.