Dispensary menu SEO and the iframe problem

This page was written, stopped and shelved on 31 August. We had a strong hunch about what a dispensary menu embed does to a website and no evidence we were willing to publish, so we left the gap in the playbook and said why in public.

What changed is not that we found a clever workaround. It is that both vendors publish developer documentation describing exactly how their menus work, on subdomains that answer an ordinary request even though their marketing sites do not. Their own words turn out to be better evidence than the handful of live examples we were waiting for.

What the embed actually is

From Dutchie's own documentation:

Dutchie's embed menu solution uses a script tag to render an iframe element and display your store's menu.

Dutchie Platform Documentation, Dutchie Embed SDK Overview, read 8 September 2026

The documented script tag is a single async script loading from dutchie.com/api/v2/embedded-menu/DISPENSARYID.js, and Dutchie notes that "the script renders the iframe menu wherever it is placed". Your menu content is served from Dutchie's domain and displayed inside a frame on your page.

Jane is the same shape. Its embed documentation describes two postMessage APIs used to "customize the look and feel of their embedded iFrame menus" and to pass user data into checkout. The target origin in Jane's own sample code is https://www.iheartjane.com, which is the plain confirmation that the frame is a different origin from your site.

None of this is hidden or improper. It is a sensible way to ship a complex, compliance-heavy commerce experience to thousands of retailers. It just has consequences that nobody selling it leads with.

What Google does and does not say

Here is where most articles on this subject start inventing, so let us be exact.

Google publishes no guidance on iframe indexing. We searched its JavaScript SEO documentation for it on 31 August 2026, again on 8 September while writing about age gates, and again while writing this page. Zero mentions. There is no Google rule saying content inside a third-party iframe does or does not count for the host page, and we are not going to manufacture one.

What Google does document is how rendering works: every page returning a 200 goes into a rendering queue, a headless Chromium runs the JavaScript "once Google's resources allow", and "Google also uses the rendered HTML to index the page". It adds, about a related case, that "Google can only see content that's visible in the rendered HTML". An iframe's content is a separate document at a separate URL, which is precisely why the question exists and why Google's silence on it is frustrating rather than reassuring. The website spoke covers the rendering pipeline in more detail.

So we cannot hand you a Google sentence. What we can hand you is the behavior of the two companies who know their own products best.

Both vendors sell a way off the iframe

This is the part that settles the argument as far as it can be settled.

Dutchie sells Dutchie Pro Proxy, which it describes as a Cloudflare Worker that serves your storefront from your own domain. Its documentation explains the reasoning:

By serving your Dutchie-powered storefront at yourdomain.com/stores instead of a third-party subdomain, you consolidate your web presence under a single domain. When your storefront lives on your primary domain, all the traffic, backlinks, and engagement your store generates contribute directly to your domain's search rankings, rather than being attributed to a separate subdomain.

Dutchie Platform Documentation, Dutchie Pro Proxy

Read that carefully and read it fairly. The architectural facts are documentation: a Cloudflare Worker, the storefront on your domain, an automatic sitemap at /stores/sitemap.xml, and client IP addresses forwarded "to maintain analytics accuracy". The surrounding SEO claims, higher rankings and consolidated domain authority, are Dutchie's marketing claims, not Google statements, and we are not going to launder them into facts just because they support our own argument. What matters is that the company built the product, and the problem it names is the one this page is about.

Jane arrives at the same place from the other direction. Its guidance on handling SEO is emphatic about separate URLs:

You will need a separate URL for each product details page ... The reason why you want separate pages for each product is that search engines will index each page, and will consider it relevant for search terms related to the page content.

Jane Docs, Handling SEO

Jane goes on to recommend separate brand and category pages and Product JSON-LD. The detail worth noticing is where that advice lives: in the documentation for building your own menu, not in the documentation for the embed. Neither vendor claims the plain embed gives you indexable product pages, and the one that discusses indexing at all does so in the section about not using the embed.

The attribution break, confirmed by the patch for it

There is a second consequence, and it is measurable in a way the indexing question is not.

An iframe on a different origin cannot read the parent page's analytics identifier or its referrer. So without intervention, a customer who arrives from Google, browses your site and opens the menu appears inside the menu's analytics as a session that started there, from nowhere.

Jane ships a GA Referrer Script to patch exactly this. It reads the parent page's client_id from gtag and posts it, along with document.referrer, into the frame:

gtag('get', '{UA-Code}', 'client_id', function (clientId) { frameWindow.postMessage({ messageType: 'initializeGa', payload: { clientId: clientId, referrer: document.referrer } }, 'https://www.iheartjane.com'); });

Jane Docs, GA Referrer Script

That script existing is the clearest possible confirmation of the problem. You do not build a referrer bridge unless the referrer is being lost. It is the same client_id join that the tracking and attribution spoke covers, arriving from a different direction. One honest note: Jane's published sample still uses a UA- property ID, which is Universal Analytics and has been shut down, so the mechanism is current while the code sample is not.

Three architectures, ranked by what you keep

Every dispensary menu we have seen documented falls into one of these.

1. The plain embed. A script tag renders an iframe from the vendor's domain. Fastest to install, and the one where the least is yours. There is no separate URL per product to rank or to link to, and analytics needs a bridge to see where visitors came from.
2. The proxy. Dutchie's Pro Proxy serves the storefront from your own domain with its own sitemap. Your pages, your domain, the vendor's application. This is the change that actually addresses the problem, and it requires a Cloudflare account and the Pro tier.
3. The built menu. Jane's Roots path, or Dutchie's Pro SDK, where you build the storefront yourself against the vendor's data. Dutchie's SDK exposes a metadata function returning title, description, canonical, Open Graph image and JSON-LD, which is the head contract an indexable page needs. Most control, most work.

The right answer depends on whether online ordering is a real channel for you or a convenience for people who already chose you. If your menu is mostly a reference for regulars, the embed is doing its job and rebuilding it is an expensive answer to a question you do not have.

One implementation warning if you take the SDK route, because Dutchie flags it and a wrong canonical is worse than no canonical: build the canonical URL from the storefront origin rather than concatenating the storefront root with the pathname, or you will duplicate the /stores/ segment and emit a relative URL.

What we still cannot tell you

• Whether Google indexes iframe menu content for your domain. No Google rule exists. Everything above is vendor behavior plus Google's rendering documentation.
• How many dispensaries run which architecture. The original condition for writing this page was three to five real dispensary sites to inspect, and we never got them. This page describes architectures, not prevalence, and publishes no percentage.
• What the proxy or the Pro tier costs. Not published in the documentation. Ask.
• Whether moving produced a result for anyone. We have no before-and-after case we are free to publish, so there is no case study here and no projected lift.

One process note, since this page is partly about evidence. Both vendors' documentation sites offer an endpoint that will answer questions about the docs using a language model. We did not use it. A generated answer is not a citable source, and the entire value of this page is that every claim traces to a document you can open yourself.

The working checklist

1. Find out what you are running. View source on your menu page and look for a script loading from your vendor's domain, or a frame element.
2. Run site:yourdomain.com and search for a product you carry. If no product pages on your domain appear, that is the finding.
3. Ask the five questions in the FAQ below of your menu provider, and get the answers in writing.
4. Check whether analytics sessions start at the menu. If they do, the referrer bridge is missing.
5. Decide whether online ordering is a channel or a convenience before you spend anything, because that decides whether any of this is worth doing.
6. If you move, confirm the sitemap and that your canonical URLs are absolute and correct.
7. Keep the content you want to rank in your own HTML regardless of architecture: categories, education, hours, staff picks and local detail.

Frequently asked questions