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.
What belongs on it, what belongs on paper, and the six pages that stop a hundred text messages before they are sent.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.