Wedding RSVP microsites: from setup to event-day archive (2026)

The wedding is in six months. The save-the-dates went out last week. Guests are starting to ask the obvious questions: dress code, hotel suggestions, plus-ones, dietary preferences, where to send a gift. The couple builds a small microsite — date, venue, agenda, registry link, RSVP form. The site needs to be live for the next eight months and then go away.

Most ways to do this either keep billing after the wedding or leave a stale site online for years. There's a cleaner shape.

The wedding microsite's actual lifecycle

Four phases that recur across most weddings:

1. Setup and pre-event (months -6 to -2). The microsite goes live; save-the-dates point at it; guests start visiting to RSVP and check details. Updates happen frequently as venues confirm, agendas finalize, hotel blocks open.

2. Event week (-1 to 0). Peak traffic. Last-minute guests checking timing, weather logistics, the venue address one more time. The site shouldn't change much this week — last-minute updates create confusion.

3. Post-event window (0 to +2 months). Traffic drops sharply but doesn't disappear. Thank-you notes reference the site; out-of-town guests catch up; photographers share their gallery via the same channel. The site should still work for this window.

4. Long tail (+2 months onward). The site should retire. Stale "join us next month" copy is a small but recurring source of confusion when someone stumbles on the link in an old email thread.

Most hosting options handle phases 1-3 well; phase 4 is where the difference shows up.

What each hosting shape does for a wedding

Wedding-specific platforms (Zola, The Knot, Joy, Withjoy). Designed for the full wedding workflow — registry, RSVP, guest list management, vendor recommendations. Strong for the active window; the link typically stays live on the platform's subdomain indefinitely (the platforms keep the page up for nostalgic re-visits, which is a feature for some couples and clutter for others).

The URL is also platform-stamped (zola.com/wedding/...) by default; custom domain is usually a paid upgrade.

Squarespace / Wix / WordPress. Designed for ongoing websites. Strong CMS, full custom-domain support, easy editing. Trade-off: the subscription auto-renews. A $14-30/month plan started for a six-month engagement can quietly continue for years if nobody remembers to cancel.

Google Sites. Free, easy, simple. The URL is sites.google.com/... — readable but not couple-branded. No expiry behavior; the site lives until the Google account explicitly deletes it.

Static HTML at a private link with custom domain + expiry. Designed for one-page deliverables with a defined lifespan. The microsite is one HTML page (text + photos + RSVP form); it lives at the couple's chosen URL; the expiry is set once during setup and triggers automatically.

For the specific shape of "live for 8 months, retire after thank-you notes," this is the closest fit to the actual lifecycle. The same expiry-as-feature pattern that fits other event microsites is exactly what works here.

The setup

For a couple comfortable editing HTML (or working with someone who is) — and if "comfortable" is a stretch, an HTML editor that runs in the browser shows the page beside the markup as you type, so you can change the venue line without learning the rest:

1. Build the wedding page. A single HTML file with the standard sections: hero (couple's names + date), key info (venue, time, dress code, accommodations), RSVP, registry, FAQ, thank-you note placeholder for the post-event period. Most couples build this in Notion (export to HTML), Figma (export via Anima or similar), or work with a designer who hands them an HTML file.

2. Drop the file at a private-link host. Configure the link:

   • Permanent during setup window — the link stays live for the months of RSVP and the event itself.
   • Custom domain — couplelastname.com or firstandsecond.com pointing at the host via a single DNS CNAME. The URL reads as the couple's own surface, not as a vendor's subdomain.
   • Searchable opt-in OFF — most couples don't want the site Google-findable; the unguessable URL + share-by-link via email and save-the-dates is the right shape.

3. Set the expiry to event date + 60 days. This covers the thank-you note window and gives stragglers time to find the URL. After expiry, the page retires automatically.

4. Configure the white-label expiry page (Studio tier feature). The post-expiry message could be: "Thank you to everyone who celebrated with us in [Month, Year]. For the photo gallery, see [link]." This white-label expiry shape replaces the generic "this link has expired" with a planned retirement that matches the couple's voice.

5. Add an RSVP form. The simplest path is a third-party form service embed — Tally and Formspree both ship clean wedding-RSVP-shaped form embeds. The form data flows to the couple's email or a dashboard; the page itself stays static.

During the event week

Two specific considerations:

• Freeze updates a week before. Last-minute changes to venue or timing create confusion; if something genuinely changes, send a direct message to the guest list rather than updating the page silently (people who already checked the page won't re-visit before the event).
• Have the URL on the day's printed materials. The wedding program, the table cards, the hotel welcome bags — printing the URL gives guests a reference for "where do I find that thing they mentioned?" without having to dig through old emails.

For the event-microsite shape more generally, the same week-of considerations apply.

After the event

The post-event window is mostly inertia — the site stays live for thank-you notes and photo-gallery linking. Two months after the wedding, the expiry triggers. The white-label expiry page renders the thank-you message; old email links resolve to "thank you for celebrating with us" rather than to a 404.

For couples who want the wedding photos to stay accessible indefinitely (the "we'll send you the gallery link" promise from the photographer), the photo gallery typically lives separately — at the photographer's portal, on a separate dedicated photo-sharing service, or as its own private link with a longer expiry that the couple manages separately.

What this isn't

This setup doesn't replace:

• Full-featured wedding platforms for couples who want one place that handles registry + guest-list management + vendor recommendations + paper invitation matching. Zola / Joy / The Knot do this well; the static-HTML shape is for couples who'd rather build the page themselves and keep it portable.
• Dedicated photo galleries for sharing wedding photos with hundreds of guests over years. The wedding microsite is the front door; the photo gallery is a different surface that the front door references.
• Multi-language sites if the wedding guest list spans languages and the site needs careful localization. Static HTML works but the setup overhead grows; for international weddings, a dedicated platform with translation features often fits better.

The right framing: for the couple who wants a clean wedding microsite at their own URL that retires when the wedding is over without leaving a subscription running, the static-HTML-plus-expiry pattern is the closest match to the actual lifecycle. Most weddings fit; the ones that don't usually fit a platform that's purpose-built for them.