"Wedding Website With Multiple Events: Weekends, Rehearsals and Brunches"

A wedding used to be a ceremony and a reception. Now it's often a weekend: welcome drinks on Friday, the wedding on Saturday, brunch before everyone flies home — plus a rehearsal dinner, a cultural ceremony, a family lunch or an after-party, each with a different guest list.

The website has to carry all of that without turning into a timetable nobody can find themselves in. Two things make the difference: one schedule that you control centrally, and a clear head about which parts of it belong in public.

Build one master schedule first

Put every wedding-related event in one place, including the ones guests will never see. Something like:

Friday Rehearsal — 4:00pm Rehearsal dinner — 6:00pm Welcome drinks — 8:30pm

Saturday Ceremony — 3:00pm Cocktail hour — 4:00pm Reception — 5:00pm After-party — 11:00pm

Sunday Farewell brunch — 10:30am

This list is now the single source for your website schedule, your RSVP, your run sheet and your vendor timings. The alternative — a schedule in a document, a different one on the website, and a third in your head — is how a shuttle time ends up wrong in exactly one of the three.

Decide what's public before you publish anything

Here's the part couples get wrong, and it's worth being precise about.

A published wedding website is visible to anyone with the link. Guests share it. It gets forwarded to relatives, pasted into family group chats and read by people you didn't invite to everything. Password-protecting the site raises the bar but doesn't change the model: everyone who gets in sees the same page.

So the question for each event isn't "who's invited?" — it's "am I comfortable with every guest reading this?"

Take a rehearsal dinner for 24 people at a wedding of 150. Putting Rehearsal Dinner — Friday, 6pm, Osteria on the public schedule tells 126 people about a dinner they aren't invited to, in enough detail that some of them will ask. That's not a website problem; it's the reason physical invitations put those details on a separate card in specific envelopes.

The practical split:

• Public schedule: events all your guests are invited to, or that they'd expect to know exist — ceremony, reception, welcome drinks if everyone's welcome, brunch if it's open to all.
• Invitation only: rehearsal dinner, family lunch, wedding-party events. Communicate these on the stationery those guests receive, or by a direct message, and keep them out of the public listing.
• Planning only: hair and makeup times, vendor load-in, photo schedule. These belong in your own timeline and on no website at all.

In Shared Beginning each event has a visibility setting, and events marked hidden stay in your planning — the run sheet, the timeline, your vendor reports — without appearing on the public site. That's what you want for the last two categories.

Assign guests to events, then ask each one separately

Public visibility is one question. Who is invited is a different one, and it's the one that drives your headcounts.

Assign each guest to the events they're invited to, then collect an RSVP per event rather than for the weekend as a whole. Someone might come Friday and Saturday but fly out before brunch. Someone else is at the wedding only. One yes/no can't express either, and you'll be reconstructing the difference from text messages in the final fortnight.

Done properly, a guest's RSVP shows them only the events they're actually invited to — so the rehearsal dinner question appears for the 24 people it concerns and for nobody else. (That's how Shared Beginning's RSVP works: events come from each guest's own invitations, so there's no way to accidentally offer an event to someone who wasn't invited.)

The payoff is per-event numbers you can hand straight to each venue and caterer, instead of one total that only describes Saturday.

What each event needs on the page

For every event you do publish:

• Day, date and start time — and an end time if guests need to plan around it
• Venue name and the full address, not just the name
• Dress code, in plain words. "Cocktail" means four different things; "jackets, no ties, the lawn is grass so avoid stiletto heels" means one.
• How to get there: parking, the shuttle and where it leaves from, the nearest station
• Anything that changes what someone packs — an outdoor ceremony, a beach, a church with a dress requirement, a venue with stairs and no lift

That last category is worth over-communicating. A guest who arrives in the wrong shoes for a lawn ceremony remembers it, and the fix cost you one sentence.

Don't build a website per event

For elaborate weekends, some couples create separate sites — one for the wedding, one for the welcome party. Don't. Guests can hold one address in their heads, and only one. Three sites means three places to check, three places for the schedule to drift out of sync, and a guaranteed set of people who bookmark the wrong one.

One site, one schedule, the events organised within it. If it feels like it needs to be several sites, what it usually needs is clearer days and headings.

The bits that go wrong

A time changes and only one place gets updated. Change it on the master schedule and let everything read from there.

The shuttle time is buried in a paragraph. Put departure times on their own line. People scan; they don't read.

Guests can't tell which events they're invited to. If your public schedule lists five events and a given guest is invited to three, say so on their invitation. The website is a reference, not the invitation itself — it works best when it confirms what someone already knows.

Brunch appears with no end time. People with flights need to know whether they can make an 11am checkout and a 2pm departure. Add the end time to anything on a travel day.

A wedding weekend is genuinely more complicated than a wedding. The website's job is to make it feel like it isn't — one schedule, one address, and nothing on the page a guest has to work out whether it applies to them.