How to Build a Peptide Site Age Gate Google Can Still Read

A peptide site's age gate should sit on top of a page that is already fully built, and it should never replace that page. Google exempts legally required age gates from its pop-up rules, but it can only index what is in the rendered page. So the gate has to stop people without hiding your content from search. Most gates fail one of those two jobs, and usually without anyone noticing for months.

This is a rewrite of an earlier post on the same subject. Everything below comes from the peptide sites we have built and from Google's own documentation, linked where we quote it.

What Google actually says about age gates

Three pieces of Google's documentation decide how a gate behaves in search.

Age gates are allowed. Google's guidance on pop-ups and interstitials says some sites "are required to show an interstitial due to the kind of content they are publishing," and that "mandatory interstitials are exempted" from its intrusive-interstitial guidelines. A research-use 21+ gate does not count against you the way a newsletter pop-up can. (Google: Avoid intrusive interstitials)

How you build it still matters. The same page tells you to "ensure that the content is overlaid with the interstitial" and not to "redirect the incoming HTTP requests to a different page for collecting consent." It spells out what happens if you do: "Redirecting all URLs to a single page will remove all but that one page from search results."

Google indexes what it renders, and it never clicks. Google renders pages in a headless browser, and "if the content isn't visible in the rendered HTML, Google won't be able to index it." It also states plainly that "Google Search does not interact with your page." It doesn't click, scroll or tap. (Google: JavaScript SEO basics; Google: Fix lazy-loaded content)

Put those together and the rules are short: put the gate over the content, never redirect to it, and make sure the page Google renders is the page itself and not the gate.

The three gate designs, from worst to best

1. A server-side redirect to a gate page

The visitor asks for a product page. The server checks for a cookie, finds none, and sends them to /verify. This is the design Google warns against by name. Google doesn't keep cookies between visits, so it gets sent to the gate every time, and every URL on the site turns into one page. One of the sites we built rules this out in its project notes: there is deliberately no server-side middleware, because "a server block would show Google the gate and nothing else."

2. A pop-up that opens as soon as the page loads

This is the most common design and it looks safe. The full page is in the HTML, and the gate is a JavaScript overlay that covers it. View the source and everything is there.

The trouble is that Google doesn't just read the source. It renders the page in a browser, and that browser arrives with no saved "I'm 21" confirmation, the same as a first-time visitor. So it gets the gate on every visit. On one site we built, that rendered snapshot was the modal on top of a blurred page, with scrolling locked. In search results the homepage showed with no description, and its title had shrunk to the bare site name. The content was technically all there. Google just had nothing useful to show from it.

3. A pop-up that opens on the first real interaction (what we build now)

The fix uses the one thing Google says it never does: interact. The full page renders as usual and no gate appears. The gate opens the moment the visitor first clicks, presses a key, uses a scroll wheel, moves a pointer or touches the screen. Every person trying to use the site sees it within a second. Google's renderer, which doesn't interact, never triggers it.

This behaves the same way for every visitor, person or bot. It doesn't check who is asking, so it isn't cloaking. It also never has to tell Google apart from anyone else, which keeps it simple.

There is a fourth option. For age-gated content, Google suggests "allowing Googlebot to crawl your content without triggering the age gate," by "verifying Googlebot requests" and "serving the content without age gate." That works, but only with real verification: a reverse-DNS check or Google's published IP ranges (Google: Verifying Googlebot). Checking the user-agent string alone isn't verification, because anyone can type "Googlebot" into a request. We prefer the interaction-triggered gate because there's nothing to verify and nothing to keep in step with Google's IP list.

The timer trap

Before we landed on design 3, we tried the obvious patch: wait five seconds before opening the gate, on the theory that Google's renderer takes its snapshot faster than that.

We measured it in headless Chrome against the live site. A snapshot at four seconds saw the page. A snapshot at six seconds saw the gate. Nobody knows exactly when Google takes its snapshot, so no delay is reliably shorter than it. The timer only worked by luck, and luck isn't a design. We removed it.

The mobile trap

Design 3 has a catch on phones, and we found it the hard way.

The first version opened the gate the instant a finger touched the screen. When that first touch was a tap on "Add to order," the gate appeared between the finger landing and the tap registering. The tap landed on the gate instead of the button, and the buyer's product was silently left out of the order. Nothing errored, and nothing showed up in analytics as a failure. The cart was just one item short.

The fix comes down to timing. On a tap, the gate now opens after the click goes through, so the tap still does what the buyer meant and the gate appears a beat later. On a swipe, it opens when the swipe ends. A finger that wobbles a few pixels during an ordinary tap still counts as a tap, not a drag. That last detail came out of review, and getting it wrong would have brought the bug straight back.

The broader lesson: test a gate the way a buyer meets it. That means a first visit, on a real phone, where the first thing they do is tap Add to cart.

Smaller details that add up

• Keep the gate text out of search snippets. Add Google's data-nosnippet attribute to the gate's wording so "Are you 21 or older?" never becomes the description under your listing. (Google: Control your snippets)
• Decide before the page paints. If the "already confirmed" check runs only after your JavaScript framework loads, returning buyers see the gate flash on every page. A tiny script in the <head> that runs before the first paint fixes that.
• Remember the answer, but not forever. We remember a confirmation for 30 days and give it a version number, so changing the wording asks everyone again.
• Leave the terms page ungated. The gate links to your research-use terms, and a visitor has to be able to read them before agreeing.
• Work without JavaScript. With scripts off, the gate never runs and the page reads normally. That's another sign the content really is in the HTML.

The gate is not your compliance record

A gate is a click-through, and anyone can click through it. On the sites we build, what the business keeps on file is the attestation at order time: a required, unticked checkbox stating the buyer's age and research-use purpose, saved word for word with the order in the business's records. What your business needs on file is a question for your attorney, not your web developer. But if a gate is the only place that statement exists, it isn't stored anywhere you can show anyone.

How to check your own site in ten minutes

1. View the source of a product page (not the inspector — the raw source). If the product name, description and price aren't in it, Google probably can't index them either.
2. Use URL Inspection in Search Console. Test the live URL, then look at the screenshot of the rendered page. If the screenshot is your gate, that's what Google is indexing.
3. Search for your own site. Search site:yourdomain.com. Listings with no description, or a title cut down to just your brand name, are a classic sign that Google is seeing a pop-up and not the page.
4. Test on a real phone. Open the site in a private tab, so it's a first visit, and make your very first move a tap on Add to cart. Check that the item actually made it into the cart.

If any of those turn up a problem, it's usually a contained fix, not a rebuild. We build peptide stores on WooCommerce and fully custom stacks, and we audit existing ones that aren't indexing the way they should. For the full picture of what a compliant peptide site needs beyond the gate, see peptide website design.