Open Google and search site: followed by your own domain.
If your site has forty pages and that search returns three, you do not have a content problem or a link problem. Something is stopping the crawler at the door, and on a cannabis site it is nearly always the age gate.
This is the second most expensive technical fault I find on dispensary websites, after invisible menus. It is also the one operators feel worst about, because the gate was built out of caution. Somebody was trying to do the right thing.
The mechanic almost nobody explains
Googlebot does not keep cookies. It does not hold a session, it does not remember a previous visit, and it does not carry anything from one crawl to the next.
Every single crawl is a first visit. Forever.
For a customer, an age gate is a one time interruption. They confirm, a cookie is set, and they never see it again. That experience is why nobody on your team has noticed a problem: they confirmed their age eighteen months ago and the gate has been invisible to them since.
For a crawler, that same gate is a permanent wall. It arrives with no cookie, gets stopped, stores nothing, and arrives with no cookie again tomorrow.
That single fact explains almost everything that goes wrong here. If your gate depends on a cookie or a session to decide what to serve, the crawler is stuck at visit one indefinitely.
The three builds, and why only one of them is safe
A server side redirect sends every request to /age-check/ until the visitor confirms. This is the most damaging version, because your entire site collapses into a single indexed URL. Google finds forty pages, gets redirected forty times to the same destination, and concludes you have one page.
A cookie wall returns a normal 200 response but holds the content back until the cookie exists. Less obviously broken, and in some ways worse, because everything looks healthy from the outside. Search Console will start reporting soft 404s, which is Google’s way of saying the page technically loaded and contained nothing.
A client side overlay loads the full page, then paints the gate on top of it. The server does not care who is asking, so the crawler and the customer receive identical HTML. This is the only version that is both compliant and crawlable. The age gate is one of several faults in the delivery layer that stop a dispensary site at the door, and the others are worth ruling out in the same sitting.
There is no state in the United States that requires the first two. The regulatory requirement is that you make a reasonable effort to verify age before someone views the content. An overlay does that. The over-engineering comes from fear rather than from any rule, and it is expensive fear.
The fix that makes it worse
At this point somebody suggests letting Googlebot through. Detect the crawler by its user agent and skip the gate for it.
That is cloaking. Not similar to cloaking, not a grey area, but the textbook definition: serving different content to search engines than to users based on who is asking.
Google does not weigh your intentions here, and it verifies user agents against its own IP ranges specifically to catch this. The penalty for cloaking is severe and it is applied at domain level, which for a chain means every store at once.
The uncomfortable part is that this fix usually works for a while. Rankings recover, the team concludes the problem is solved, and the exposure sits quietly on the site until somebody files a spam report or an algorithmic sweep finds it. I have seen it survive two years. Two years is not a green light, it is a longer fuse.
Do not whitelist Googlebot to get past your own gate.
If the crawler needs an exception to see your site, the gate is built wrong. Fix the gate rather than building a special door beside it.
How to check yours in three minutes
Three tests, in order of how much they tell you.
One: the site colon search. Search site:yourdomain.com. Count the results against the number of pages you know you have. A large gap is the signal. One or two results when you have dozens of pages is close to conclusive.
Two: Search Console coverage. Open the Pages report and look for a spike in “Page with redirect”, or a cluster of “Soft 404”, or “Crawled, currently not indexed” across pages you know have content. Each of those maps to one of the three builds above.
Three: view source with a clean session. Open a private window, go to a menu page, and use view source rather than Inspect Element. Inspect shows the live DOM after scripts run, which is why the page always looks fine there. View source shows the HTML as delivered. If your products are in Inspect but not in view source, the gate is holding content back.
That third test is the same principle behind checking whether your menu reaches the index, and the two faults compound. A site with an iframe menu behind a cookie wall has two independent reasons Google cannot see its products, and fixing either one alone changes nothing.
Check it in about twenty seconds
The site checker fetches your page the way a crawler does, with no cookies and no session, and reports whether an age gate is blocking the response, redirecting it, or sitting harmlessly on top.
Run the dispensary site checker
What it looks like on a real account
A multi-location operator came to me because organic traffic had been flat for eighteen months despite steady content spend.
Their site: search returned two results. Two, for a site with more than two hundred URLs.
The gate had been rebuilt during a redesign three years earlier, and the developer had made it a server side redirect because that felt more rigorous than an overlay. Nobody on the marketing team had ever run a site colon search, and no report they received would have surfaced it.
The content they had paid for over those eighteen months existed. It was well written. Google had simply never been allowed to read any of it.
How to build it properly
1. Serve the full page to everyone, always. No redirect, no conditional response, no user agent check. The HTML that leaves your server is identical whoever asked for it.
2. Draw the gate as an overlay after the page has loaded. A fixed position layer over the content, with the body scroll locked while it is open. Focus should move into the dialog and stay trapped there until it is dismissed, which is both an accessibility requirement and the behaviour a regulator would expect.
3. Store the confirmation client side. A cookie or local storage flag read on subsequent page loads. Because it is read in the browser rather than checked on the server, the crawler is never affected by its absence.
4. Keep the gate out of the indexable content. The overlay markup should not contain your headings or product text. If a search result ever shows “You must be 21 or older” as the meta description, the gate has become the page’s most prominent content.
The part worth saying to your developer
The conversation usually stalls on a misunderstanding, and it is worth naming directly. Your developer is not being obstructive. They built a server side gate because server side sounds stronger, and in most contexts it would be.
The framing that resolves it: age verification is a display requirement, not an access requirement. You are required to check before someone views the content, and an overlay checks before they view it. You are not required to withhold the file from the network.
Once that lands, the rebuild is usually half a day.
If you take one thing away
Run site:yourdomain.com today. If the number is far smaller than the number of pages you have, stop reading about content and go and look at your age gate.