# Your Age Gate Is Hiding Your Whole Site From Google and ChatGPT

**Author:** John Morabito (Founder, /winston)
**Published:** September 20, 2026
**Reading time:** 11 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/cannabis-age-gate-seo/

**Short answer:** There are three common ways to build a cannabis age gate and only one of them leaves your pages readable by a crawler. The other two answer every request with the door: one redirects each URL to the same verification template, the other refuses to return anything until a cookie shows up. Both produce a site that works perfectly in a browser and is close to empty from the outside. One curl command tells you which one you have.

The gate is not the problem. Every licensed operator has one, nobody is arguing about whether it should be there, and it is the least interesting part of a cannabis website. What matters is what your server hands back when something asks for a URL behind it, and on most of the cannabis sites I look at, the answer is the door, again, for every page on the site.

That failure does not announce itself. The site works. Your staff click through it all day. A customer clicks through once and never sees the gate again because the cookie is set. Meanwhile Google holds a copy of the same verification template under every URL you own, an AI assistant asked about dispensaries in your city has never read a word you wrote, and the only symptom anybody notices is that nothing ranks. Which gets diagnosed as a content problem, and then somebody spends a quarter writing strain guides that land behind the same closed door.

General information, not legal advice. Age verification obligations for cannabis differ by state, by license type, and by what you are selling, and they change. Nothing on this page tells you what your jurisdiction requires or whether a given gate satisfies it. Take that question to your own counsel and your state regulator. What follows is a technical question only: given that you are going to have a gate, how do you build it so it does not erase your site.

## Three implementations, three very different outcomes

Almost every cannabis age gate in the wild is one of these three. They are indistinguishable to a human visitor and they could not be more different to a machine.

### 1. The JavaScript overlay that leaves the page in the DOM

The server returns the requested page, complete, with a 200. The full HTML of whatever was asked for is in the response: the product copy, the location page, the article. A script then paints a modal over the top of it and locks scrolling until somebody confirms their age, and a cookie or a localStorage entry remembers the answer.

From a crawler's point of view, nothing has happened. The response body contains the page. Google indexes it. A fetcher that never runs a line of JavaScript still receives the full text, because the text was in the response before any script existed. This is the implementation you want. In my experience it is the least common of the three.

### 2. The hard redirect to a verification URL

Request any page, get a 302 to /age-check/ or /age-verification/, usually with the original path tacked on as a query parameter so the visitor can be sent back after confirming. The verification page is a real page with a real template, and it is the same template no matter which URL sent you there.

What a crawler sees here is one page, repeated. It requests your Blue Dream product page and is redirected to the gate. It requests the article you spent a week on and is redirected to the gate. Every URL on the site resolves, eventually, to the same document, and that document does not contain the content of the URL that was requested. There is nothing to index except the gate.

### 3. The cookie wall that returns a 403 or an interstitial

The strictest version and the most damaging one. The server checks for a verification cookie on every single request, and no cookie means no page. Depending on how it was built, a request without the cookie gets a 403 Forbidden, or a 200 carrying interstitial markup with none of the real content, or occasionally a 401.

Crawlers do not carry a cookie from one request to the next the way a browser session does, and they do not click the button that sets it. So the cookie is never present, and every request gets the same treatment. A 403 tells a search engine that the content is not available to it, which is a straightforward instruction to stop asking. A 200 with interstitial markup is worse in a quieter way: you have told the engine that the interstitial is the content of that URL.

## What each one does to indexing

The redirect gate collapses your site into one URL. In Search Console this shows up as a large count under Page with redirect, and an indexed page count that is a small fraction of the URLs in your sitemap. Nothing in the interface says your age gate did this.

The cookie wall keeps your pages out of the index entirely and removes the ones that were already there. A 403 gets reported as blocked due to access forbidden. The interstitial variant is subtler, because the pages are technically indexable and technically all identical, so search engines treat them as duplicates and pick one URL to represent the set. Your whole site becomes one result for one query.

None of this produces a penalty, which is part of why it survives for years. There is no message, no manual action, no warning. There is a coverage report with a big number in an unfamiliar category, a site that ranks for its own brand name and nothing else, and a marketing team that concludes it needs more content.

The tell that separates this from an ordinary visibility problem is the shape of it. A content or authority problem produces a site that ranks poorly across the board. A gate problem produces a site that ranks for the homepage, or for one page, and for nothing else at all, no matter how much you publish. If you are adding pages every month and your indexed count is not moving, stop writing and check the door.

## What each one does to AI retrieval

Search engines at least have a rendering pipeline. Google will run JavaScript on a second pass, which is why an overlay gate survives and why a lot of badly built cannabis sites limp along in organic search rather than disappearing outright.

The retrieval fetchers behind AI assistants mostly do not work that way. They request a URL, take the bytes in the response body, and move on. Some render and many do not, and the ones that do not make up the bulk of the AI crawling that reaches a small site. They also do not maintain a cookie jar across a crawl, and they do not follow a redirect chain hoping the destination turns into the page they wanted.

So the ranking of the three implementations flips. The overlay, which is merely tolerable for Google because Google renders, is the only one of the three that works at all for AI retrieval, and it works for the opposite reason: the content was sitting in the response body before any script ran. The redirect gate hands an assistant your verification template. The cookie wall hands it a 403.

It is worth being precise about how this fails, because it fails silently in a way search does not. An assistant asked about dispensaries in your neighborhood does not tell the user that your site was unreadable. It answers from Weedmaps, from Leafly, from a local news roundup, from a Reddit thread, and from the one competitor whose gate happened to be built correctly. There is no error state anywhere in that exchange. You are simply not in the answer, and from the outside there is no difference between a brand that could not be read and a brand that does not exist.

## How to tell which one you have, in under five minutes

Two commands and one browser setting. You do not need a crawler license or a developer.

### Step one: ask for a page the way a bot does

Pick a real page, not the homepage. A product page, a location page, a blog post.

```
curl -s -L -o /dev/null \
  -w "%{http_code} %{url_effective}\n" \
  https://yoursite.com/your-real-page/
```

That prints the final status code and the URL you actually ended up at. Read it like this:

- **200 and the URL you asked for.** No redirect gate. Go to step two.
- **200 and a verification URL.** Implementation two. Every page on your site is resolving to the gate.
- **403.** Implementation three. The server is refusing the request outright.

### Step two: read what actually came back

A 200 on the right URL is not the end of it, because the interstitial variant returns exactly that. Pick a sentence that appears only on that page, something from the middle of the body copy or the street address on a location page, and look for it:

```
curl -s https://yoursite.com/your-real-page/ \
  | grep -c "a distinctive sentence from that page"
```

A count above zero means the content is in the response and your gate is an overlay. A zero, on a response that is still several kilobytes, means you are holding the gate's markup and nothing else, which is the interstitial case. If you want to see it directly rather than trusting a count, pipe the same response through a text-only render and read what a machine would read.

### Step three: confirm it in a browser with JavaScript off

Open DevTools, disable JavaScript in the settings panel, and hard reload the page. What is left on the screen is roughly what a non-rendering fetcher receives. If the page is readable, you are in good shape. If you get a blank screen, a spinner, or the gate with nothing behind it, you have your answer.

Run all three steps on three different URL types: the homepage, a product or menu page, and a deep content page. It is common to find the homepage fine and everything else gated, because the gate was added to the page template and the homepage got special cased somewhere along the way. Testing only the homepage is how this goes unnoticed.

## The pattern that keeps the gate and keeps the page

The rule is one sentence. The server returns the requested page, complete, with a 200, to everyone. The gate is applied on top of it, in the browser, after the response has already left.

In practice that means:

1. **Serve full HTML for every URL, every time.** No server-side redirect to a gate, no conditional rendering based on a cookie, no middleware that inspects the request and decides whether the visitor has earned the content.
2. **Render the gate as an overlay over the document.** The page content stays in the DOM underneath the modal instead of being replaced by it. It was in the response body regardless, which is the part that matters.
3. **Keep the block in the browser.** Fix the body, disable scrolling, trap keyboard focus inside the modal. A visitor cannot use the page until they answer. A crawler already has it.
4. **Store the answer client side and check it client side.** A cookie or a localStorage entry, read by the script that decides whether to show the modal. That check never influences what the server sends.
5. **Keep the overlay accessible.** Focus moves into the modal, it is operable by keyboard, and the decline path goes somewhere real. An age gate is the first thing every visitor meets, which makes it the worst place on the site to ship an accessibility problem.

Two objections come up every time.

The first is that a determined visitor can read the page without confirming anything. True, and it has been true of every client-side gate ever built, including the one on the site you are comparing yourself to. Whether that satisfies your obligation is a question for counsel and your state regulator, and the answer genuinely differs by state and license type. What I can tell you is what the alternative costs, because that part is not a matter of interpretation: a site no search engine and no assistant can read.

The second is whether this counts as cloaking. It does not, and the distinction is exact. Cloaking is serving different content to crawlers than you serve to people. An overlay gate serves identical bytes to everybody and changes only what the browser does afterward. What would be cloaking is detecting a bot user agent and giving it the real page while giving humans the gate. Build it so the server never inspects who is asking and never varies the response, and no crawler ever receives anything a visitor would not.

## The canonical and the status code on the gate itself

If you keep a dedicated verification URL, either as the destination for a decline or as a fallback, two details need deciding on purpose rather than by default.

**The status code.** Requested directly, the gate page should return 200, because it is a real page and it exists. What it must never do is return 200 while standing in for some other URL. If a request for a product page is answered with gate markup and a 200, you have declared that the gate is the content of that URL, and a search engine will believe you. Either serve the real page, which is the fix, or return a status that describes what happened instead of a 200 carrying the wrong body.

**The canonical and the indexing directive.** The gate page canonicals to itself and carries a noindex directive. Keep it out of the sitemap. Do not disallow it in robots.txt, because a noindex on a page a crawler is not permitted to fetch never gets read, and you end up with a URL that is both uncrawlable and eligible to appear in results.

One specific thing worth grepping for today: a hardcoded canonical inside a shared gate template. If the gate ships with a canonical pointing at the homepage, and that template is what gets served for every URL on the site, you have told search engines that every page you own is the homepage. It is one line of markup, it is invisible in a browser, and it does more damage than the gate does.

## An age gate plus a JavaScript menu leaves nothing behind

The gate rarely travels alone. The same build decisions that produce a server-side gate tend to produce a navigation with no real links in it, where the menu is assembled by a script and a crawler that does not render finds no way to walk from the homepage to anything else. And on a dispensary site there is usually a second menu problem underneath that one: the product catalog arrives from a third-party domain inside an iframe, so the products and their prices never exist in your own HTML at all.

Stack those and the amount of your business that is machine readable approaches zero. The gate hides the pages. The scripted navigation hides the path between them. The iframe hides the inventory that was the reason anybody was searching. Each one on its own is a recoverable problem, and together they produce a site that is functionally a single URL with a picture of a business on it.

The order of operations matters. Fix the gate first, because there is no value in making a menu crawlable behind a door that no crawler opens. The embedded menu case has its own treatment in the Dutchie iframe SEO problem (https://www.winstondigitalmarketing.com/playbooks/dutchie-iframe-seo-problem/), and the general version of the failure, content that only exists after a script runs, is covered in JavaScript SEO: making dynamic sites crawlable (https://www.winstondigitalmarketing.com/playbooks/javascript-seo-making-dynamic-sites-crawlable/). If you are rebuilding rather than patching, the gate is one of the decisions covered in the broader cannabis website design playbook (https://www.winstondigitalmarketing.com/playbooks/cannabis-website-design/).

## What to do this week

1. Run the three-step check on three URL types. Ten minutes for all three, and it tells you which implementation you are running.
2. Compare your indexed page count in Search Console against the URL count in your sitemap. A large gap with a large Page with redirect or blocked count is the fingerprint of a server-side gate.
3. Grep the gate template for a hardcoded canonical. Fix it before anything else if you find one.
4. If you are on implementation two or three, scope the move to an overlay. On most stacks it is a smaller job than it sounds, because the gate logic moves from the server to a script and the templates stop being touched at all.
5. Take the compliance question to counsel before you ship the change, with the specific implementation in front of them. Requirements differ by state and by license, and this is the one part of the work that is not a technical decision.

An age gate built this way costs you nothing in search or in AI retrieval, and it takes an afternoon. An age gate built the other way costs you the site for as long as nobody checks. We do this kind of technical work as part of cannabis marketing (https://www.winstondigitalmarketing.com/services/cannabis-marketing/), where the first job is almost always making sure the pages exist before arguing about what should be on them.

## Frequently asked questions

### Does an age gate hurt cannabis SEO?

Only if it changes what the server sends. An age gate that is painted on top of a fully delivered page costs you nothing, because the crawler already has the content before any script runs. An age gate that redirects every request to a verification URL, or that refuses to return the page until a cookie is present, costs you the entire site, because every URL resolves to the same document or to an error. The gate itself is never the problem. What the server returns to a request for a real page is the problem, and the two are easy to confuse because both versions look identical in a browser. This is general information, not legal advice.

### How do I check whether my age gate is blocking Google?

Request one of your real pages with curl and look at two things: the status code with redirects followed, and whether a distinctive sentence from that page appears in the response body. If the final URL is the one you asked for, the code is 200, and your sentence is in the body, the gate is an overlay and you are fine. If the final URL is a verification path, you have a redirect gate. If the code is 403, you have a cookie wall. Confirm the result in a browser with JavaScript disabled, and run the check on three URL types rather than one, because gates are frequently applied to the page template while the homepage is special cased.

### Should the age verification page be indexed?

No. If you keep a dedicated verification URL, it should return 200 when requested directly, canonical to itself, carry a noindex directive, and stay out of your sitemap. Do not disallow it in robots.txt, because a noindex directive on a page a crawler is not permitted to fetch is never read. The detail worth checking specifically is the canonical: a shared gate template that ships with a hardcoded canonical pointing at the homepage will quietly tell search engines that every URL on your site is the homepage, which is a larger problem than the gate itself.

### Can AI crawlers like ChatGPT get past an age gate?

Generally no, and they fail more completely than Google does. Search engines maintain a rendering pipeline that can execute JavaScript on a second pass, so an overlay gate is survivable for them. Most retrieval fetchers behind AI assistants request a URL, take whatever the response body contains, and move on without rendering or carrying cookies between requests. A redirect gate hands them the verification template, a cookie wall hands them a 403, and an overlay hands them the full page because the text was in the response before any script ran. Nothing reports this back to you. The assistant just answers about your category using directories, local press, and competitors whose gates were built correctly.

### Is a JavaScript age gate considered cloaking?

No, and the distinction is exact. Cloaking means serving different content to crawlers than you serve to people. An overlay gate serves identical bytes to every visitor and every bot, and changes only what the browser does with them afterward. What would be cloaking is detecting a crawler user agent and returning the real page to it while returning a gate to humans, or the reverse. Build the gate so that the server never inspects who is asking and never varies the response, and the question does not arise.

## The rest of the crawlability problem

- JavaScript SEO: making dynamic sites crawlable: https://www.winstondigitalmarketing.com/playbooks/javascript-seo-making-dynamic-sites-crawlable/
- The Dutchie iframe SEO problem: https://www.winstondigitalmarketing.com/playbooks/dutchie-iframe-seo-problem/
- Cannabis website design: compliance, search, AI, and shoppers: https://www.winstondigitalmarketing.com/playbooks/cannabis-website-design/
- Dispensary menu sync: why your products are invisible in search: https://www.winstondigitalmarketing.com/playbooks/dispensary-menu-sync-seo/

## Want to know what your site actually returns?

We check the gate, the navigation, and the menu before anybody argues about content, because a page that does not reach a crawler cannot be optimized. This page is general information, not legal advice. Confirm your age verification requirements with counsel and your state regulator.

Service: https://www.winstondigitalmarketing.com/services/cannabis-marketing/
Audit: https://www.winstondigitalmarketing.com/audit/