Wedding Website Privacy: How to Keep Your Guest List Off Google

A couple once told me they Googled themselves after setting up their wedding website on a popular platform. Their names, wedding date, venue, and a link to their guest RSVP page all showed up on the first page of results. They hadn't changed any settings. The default was public.

This isn't unusual. Most wedding website builders are designed to be discoverable, because that's what most other websites want. Discoverable is fine if you want friends to find your site by Googling your names. It's a problem if you assumed your wedding details were private and they weren't.

What "public by default" really means

When a website is public, search engines crawl it and add the content to their index. That means anyone searching can land on a page with your full names, your wedding date and venue, the URL of your site, the page titles and descriptions (often including your names and date), and the body content (your story, event details, FAQ entries). On poorly built platforms, guest names and RSVP responses can end up exposed too, depending on how the data is stored.

Some couples genuinely want this. Friends Googling their names and finding the wedding site directly is convenient. For others, especially people in public-facing jobs, those dealing with complicated family situations, or anyone who simply prefers privacy, having their wedding date and venue show up in search results feels like an invasion they didn't agree to.

How indexing actually works

Search engines send automated programs (crawlers, or bots) out to visit websites and catalog the content. When a crawler visits your wedding website, it reads the page and adds it to the search index. Once indexed, the page can appear in search results, sometimes within hours of going live.

Two mechanisms control whether this happens. The first is a file called robots.txt, which sits at the root of your site and tells crawlers which pages they're allowed to visit. If it says "Disallow: /", well-behaved crawlers won't index anything. The second is a meta noindex tag, an HTML directive on each page that tells search engines "don't include this page in your results", even if the crawler visits it.

Both are requests, not legal guarantees. Google, Bing, and other reputable engines respect them. Less reputable scrapers may not. For practical purposes, having both in place means your wedding site won't appear in Google.

How the major platforms handle this

All of the big platforms let you do this. The difference is whether you have to go and find the setting, and whether you know to look before you share the link.

Settings and defaults change, so check yours rather than trusting a table in a blog post, including this one. The one thing worth knowing regardless of platform: if a site has already been indexed, turning the setting off later takes up to about thirty days for search engines to drop it. That's the real argument for deciding before you share the link rather than after.

Where the setting actually lives

Roughly, at time of writing, because these move.

Zola. Account, then Privacy Settings, then Website Password to require one. Separate controls there decide whether your site can be found by Google or by Zola's own search. There's also a visibility button on the Manage Website page that hides the site outright.

The Knot. On the Wedding Website dashboard, there's a pen icon next to your custom URL that opens privacy settings, where "Set a password" is a toggle. Search visibility is separate, under Settings, "Allow your site to appear in search engines".

WithJoy. The most granular of the three. Each page can be Public, Password Protected or Hidden, and you can password-protect the date and location specifically. Two separate toggles control whether guests can find you through Joy's own find-a-couple search and whether Google can.

Worth noticing that password protection and search visibility are two different switches on all three. Turning on a password does not remove you from Google, and hiding from Google does not stop anyone with the link. You usually want to think about both.

Password protection vs. just hiding from search

Password protection adds a layer beyond search engine blocking. Even if someone has the direct URL, they need a code to access the site. That's useful for couples who want to limit access strictly to invited guests, those with privacy concerns (public figures, complicated family dynamics), or anyone who wants to control when guests first see the site.

The trade-off is friction. Every guest needs the password, and some (especially older relatives) will forget it, lose the message you sent it in, or get confused at the login screen. If you go this route, keep the code simple (your wedding date, a pet's name, something easy to share verbally) and put it right on the invitation.

For most couples, search engine blocking without a password is the right balance. Your site won't appear in Google, but anyone with the link can access it. Since you control who gets the link through your invitations, that's usually private enough.

RSVP data and guest information

Privacy isn't only about search engines. It's also about what happens to the data your guests submit. When a guest RSVPs on your wedding website, they're sharing personal information: name, email, meal preference, dietary restrictions, sometimes a mailing address. In Canada, this data is protected under PIPEDA (the Personal Information Protection and Electronic Documents Act).

Things to expect from any platform you trust with guest data: guest information should only be visible to you, not to other guests. RSVP responses should never be exposed in the page source, URL parameters, or JavaScript bundles, because anyone who clicks "view source" can read whatever's there. Data should not be shared with advertisers or sold to vendor marketplaces, which is how many free platforms actually make money. And you should be able to export and delete the data when your site wraps up, both for your records and for your guests' privacy.

Read the privacy policy. If you can't tell within five minutes how the platform handles your guests' information, that's the answer.

What to check on a site you've already published

If your wedding website is already live, four quick checks will tell you where you stand. Google your full names plus "wedding". If your site appears in the results and you don't want it there, check the platform's privacy settings for a "hide from search engines" option, then enable it. Be aware that cached results can persist for a while.

Right-click your wedding website and pick "View Page Source", then search for guest names or email addresses. If they're in the source code, that's a leak; switch platforms or escalate to support. Read the platform's privacy policy with attention to language about data sharing with "third parties", "service providers", or "advertising partners". Those phrases usually mean the platform is monetizing your data. And if you want the extra layer of control, enable password protection if the platform offers it.

Why I made privacy the default

I think wedding websites should be private by default. Not because every couple needs the privacy, but because the default should protect you, and you should be able to opt in to discoverability if that's what you actually want.

That's how Always & Forever works. Every client site includes noindex meta tags and a robots.txt that blocks crawlers. Password protection is available for couples who want it. RSVP responses and guest data are never exposed in the page source or accessible without authentication. Couples can opt in to being discoverable if they want friends to find them through search, but it's never the default.

Whatever platform you end up using, understand its privacy defaults before you publish. And if you're still working out what your wedding website actually needs, I put together a full checklist that covers features, content, and the things most couples forget.