Evorrah

The Blog

Evorrah's Blog · Weddings · Planning

How to Build a Wedding Website Guests Actually Use

What belongs on it, what belongs on paper, and the six pages that stop a hundred text messages before they are sent.

A screen and a printed suite sharing one palette

Most wedding websites are built once, in an evening, and then quietly ignored by the people they were built for. The ones that work are not prettier — they are organised around what a guest is trying to find out at the moment they open the link, which is almost always something practical and slightly urgent. This is what to put on it, what to keep on paper, and how to tell the difference.

The division of labour

The invitation and the website are not two versions of the same information. They have different jobs, and the split is cleaner than most couples expect.

The invitation carries what will not change: who is marrying, the date, the place, the hour, and the tone of the whole event. It is an object someone keeps. The website carries everything that might change, everything that is long, and everything only some guests need: travel, parking, accommodation, the full schedule, registry, the dress-code paragraph that would ruin the invitation's composition.

One test settles most arguments: if this could change after printing, it goes online. Hotel release dates change. Shuttle times change. The ceremony hour does not.

The six pages that do the work

1. Schedule, with real times and real addresses

Not "afternoon — ceremony." Guests are planning trains, childcare and how long they can stay. Give the hour of each element, the address of each location, and the time the last thing ends. If there is a welcome dinner or a next-day brunch, say clearly who is invited to each; ambiguity here produces more messages than any other part of a wedding.

2. Travel and parking

The nearest station, roughly how long from the airport, whether there is parking and whether it can be left overnight. That last one matters more than it sounds — it is the difference between a guest having a drink and a guest driving home.

3. Accommodation, with the release date visible

If you hold a room block, print the release date in the same size as the hotel name. A block quietly expiring is one of the few website failures that costs guests actual money.

4. Dress code, stated plainly and once

Say the thing. "Black tie." "Summer formal — the ceremony is on grass." A dress code that hedges gets interpreted eight ways, and the guests who guess wrong are the ones who will remember it. One sentence of practical context is worth three of adjectives.

5. RSVP

The reply lives here, not in an email address. It should know who each guest is when they arrive, ask the questions worth asking, and chase on its own before the deadline. The wider mechanism is in the RSVP guide.

6. An FAQ that prevents messages

This is the highest-return page on the site and the one most often skipped. Write it by listing the questions you have already been asked twice. Ours, almost every wedding: are children invited · can I bring someone · is the ceremony outside · what happens between the ceremony and dinner · where do I park · is there a taxi at the end · what should I do about a gift.

Seven honest answers on one page removes most of the traffic that otherwise arrives on your phone in the fortnight you have least attention.

What to leave off

  • Your whole story at the top of the homepage. Put it on its own page and let the landing page answer logistics. Guests who want the story will look for it; guests who need the address are in a hurry.
  • Autoplaying music. Guests open these at work.
  • A countdown as the main element. It tells no one anything.
  • Registry as the first thing. Include it, plainly, on its own page.
  • Home addresses in public. If the site is open, keep addresses behind the RSVP.

Domain, slug and password

A short domain gets typed correctly from a printed card; a long one does not. Surnames plus year works and ages well. Whatever you choose, it has to be legible when set small on an enclosure — test it printed, not on screen.

Password-protect when the site carries home addresses, a room-block code or a private schedule. Leave it open when the site is mostly logistics: every password costs you a fraction of the guests who would otherwise have read the travel page.

Make it look like the wedding

A guest who opens the link should recognise it instantly as the same event as the card in their hand — the same palette, the same type, the same restraint. This is not decoration. It is the thing that makes the site feel official rather than like a form someone filled in, and it measurably changes whether people trust the information on it.

The general argument for carrying one set of decisions across every surface is here. On a website specifically it means: the invitation's typeface for headings, the suite's ink for links and buttons, and the same generosity of space. Where a suite and a site are built together, the site inherits all of it and there is nothing to match by hand.

When to launch it

Publish with the save the date, not with the invitation. At that point it needs only three things — names, date, place — and a line saying details will follow. Guests booking flights a year out will look, find the date confirmed, and stop asking. Fill in the rest as it is decided; the full sending calendar is in the timing guide.

Then keep it alive for a fortnight after the wedding. It is where people look for the photographer's gallery, the taxi number they meant to save, and the spelling of the name of the person they danced with.

Common questions

What should a wedding website include?

Six things earn their place: the schedule with real times and addresses, travel and parking, accommodation with any room-block release date, dress code stated plainly, RSVP, and an FAQ answering the questions guests would otherwise text. Everything else is optional.

What goes on the invitation and what goes on the website?

The invitation carries who, what, when, where and the tone. The website carries anything that might change, anything long, and anything only some guests need — travel, parking, accommodation, registry, the full schedule. If it could change after printing, it belongs online.

Should a wedding website be password protected?

Use a password when the site carries home addresses, a room-block code or a private schedule; it costs you a small amount of guest friction. Leave it open when the site is mostly logistics, and keep sensitive details behind the RSVP instead.

The Evorrah Edit, monthly

One email. The best of what we saw, designed, and forecast — write to hello@evorrah.com to join.