Conference website checklist: essential pages and content

Answer the first questions on the home page

Visitors want to know what the meeting is, when and where it takes place, whether they can submit and how to register. Put the dates, place and the next deadline at the top, with one primary action.

Essential pages

Not every meeting needs every page, but most scientific conferences need these.

• Home: name, dates, place, next deadline, main action.
• Call for papers: scope, dates, how to submit.
• Author guidelines: formats, limits, review process.
• Programme: sessions, chairs, rooms, updated date.
• Keynote speakers and committees.
• Registration: fee table, deadlines, inclusions, payment options.
• Venue and travel: address, transport, accommodation, accessibility.
• Sponsors and exhibitors.
• Contact and FAQ.
• Privacy notice and terms.

Keep dates and facts consistent

The same deadline should not appear differently on three pages. Store dates and fees once and reuse them. When something changes, update the source and check that every page that shows it has changed.

Make it usable on a phone

Many attendees will open the programme on a phone in the corridor. Check that tables scroll, text is readable without zooming, links are large enough to tap and the page loads on a poor connection.

What each essential page should contain

A page is finished when a visitor can complete their task on it without sending an email. Use this list as a brief for whoever writes each page.

• Home: one sentence on what the meeting is, dates, place, the next deadline and a single main button.
• Call for papers: scope, topics, contribution types, dates, how to submit, review method, contact.
• Author guidelines: word limits, file rules, roles, what happens after submission, withdrawal and change rules.
• Programme: day-by-day view, filters by track, chairs and rooms, a last-updated date and a link for each abstract.
• Registration: the fee table, deadlines, what is included, payment methods, invoices, refund policy, how to register.
• Venue and travel: address with a map, public transport, parking, accommodation, accessibility information.
• Contact and FAQ: named addresses for different topics, and answers to the questions the secretariat gets every year.

A navigation structure that visitors find naturally

Keep the main menu short, with no more than seven items, and use the words visitors search for. Group by task, not by the organiser’s internal departments. The structure below works for most scientific meetings.

Home Call for papers Topics and dates Author guidelines Submit an abstract Programme Keynote speakers Full programme Book of abstracts Registration Fees and deadlines Visa and invitation letters Venue and travel Sponsors Contact

What the home page should say, in order

Most visitors decide in a few seconds whether the meeting is for them. Put the answers in the order they ask the questions: what, when, where, what can I do now. Then add the details.

• The name of the meeting and one sentence describing it.
• Dates and place, in a format that cannot be misread.
• The next deadline, with the date written out, and a button for the action it belongs to.
• Two or three headline speakers, if they are confirmed.
• Short links to registration, programme and contact.
• Sponsors and partners, further down.

Write for the web, not for the printed page

People scan web pages. Use descriptive headings, short paragraphs, and lists for sequences of steps. Write link text that says where the link goes, such as “Read the author guidelines”, rather than “click here”. Put the most important information first on each page and avoid long introductions. Use the words your community uses, and avoid internal jargon and abbreviations that only the organisers know. Read each page aloud once; a sentence that is hard to say is usually hard to read.

Legal and policy pages

Even a small conference needs a few pages that visitors rarely read but that protect everyone. Publish them before the registration opens, and link them from the footer and from the forms they concern.

• Privacy notice: what personal data you collect, why, who sees it, how long you keep it and how to ask for deletion.
• Terms and conditions of registration, including cancellation and refund rules.
• Code of conduct, with a contact for reports and a description of what will happen.
• Accessibility statement: what the site and venue offer and how to ask for help.
• Cookie information if the site uses cookies that need consent.

Speed, mobile and basic search visibility

A slow or awkward site loses visitors, especially on a phone at a venue with poor coverage. Compress images, avoid large videos on the home page and test on a real phone. Give each page a unique title and a clear description that says what it contains, and use the meeting’s name and year in the home page title. Add descriptive text to images. Put the conference on your society’s and host institution’s websites, with a link, since visitors often reach the site from there. Submit the site to search engines only once the content is ready.

Launch-day checklist

Before the site goes public, go through this list with a colleague who has not worked on it.

• All links work, including those in the footer and in downloadable files.
• Forms send and produce the confirmation message and email.
• Dates, fees and deadlines are the same on every page.
• The site works on a phone, a tablet and a laptop, and in two browsers.
• The contact addresses are monitored, and someone is named to answer them.
• Analytics and consent notices are configured if you use them.
• A backup or snapshot of the site exists.

After the meeting

The site has one more job. Change the home page to say that the meeting has taken place, with a link to the programme, the book of abstracts and photographs if you have permission. Keep the pages online, since researchers cite them, and add the date of the next edition when it is known. If the site is moved to a new address, redirect the old pages to the new ones rather than letting them disappear.

Who owns the website during the cycle

Name one person who owns the website and one deputy. The owner approves changes, keeps the dates in one place and answers the question “Is this page up to date?” Without an owner, the site drifts: a deadline is extended in an email but not on the page, and visitors see two versions of the truth. Give the committee a simple way to request changes, such as a shared address, and publish updates in batches so that the owner can check consistency before going live.

Before launch and after the meeting

Before launch, read every page as a first-time visitor and try the submission and registration paths. After the meeting, keep the site online with a clear notice, the programme and the book of abstracts, and archive it instead of deleting it.