Google Manual Action Recovery for Dispensary Websites

A manual action is the point at which a person at Google has looked at your site and decided something on it breaks the spam policies. Not an algorithm reweighting a signal. A human being, a judgement, and a note in your Search Console account saying so.

For dispensary sites the commonest cause is not deception. It is a chain that built location pages the way every chain builds them, from one template with the city name substituted, and crossed a line nobody drew on a map.

The second commonest is an age gate built to satisfy a regulator that ends up serving Googlebot something different from what a customer sees.

This module is the full recovery path: telling a manual action apart from an ordinary ranking fall, reading the notice properly, finding the true scope, deciding page by page what to do, assembling evidence, writing the request, and setting an honest expectation about what comes back and when.

It assumes the worst version, a site-wide match on a multi location chain, because the smaller cases are a subset of it.

It is the second of six modules, and the point at which cannabis SEO stops being about growth and becomes about damage control.

First, is it actually a manual action?

Most sites that believe they have a penalty do not have one. The distinction matters because the two problems have nothing in common except the feeling, and the remedy for one does nothing for the other.

Open Search Console and go to the Manual actions report. If it says no issues detected, you do not have a manual action, and no reconsideration request will help, because there is nothing for anyone to reconsider.

What you have is an algorithmic assessment, and the only route back is making the site genuinely better and waiting for a reassessment that arrives on its own schedule.

The shape of the traffic graph is the second tell. A manual action is a cliff: one date, a vertical drop, then a flat line at the bottom.

An algorithmic change is a slope, usually over a week or two as a core update rolls out, and it often affects some sections more than others.

If you cannot point at a single date on the chart, be sceptical of the penalty theory. The first twenty four hours covers the triage in short form.

One more thing to rule out before you spend a month on this. A Business Profile suspension is a different event entirely, with a different cause, a different appeal route and a different team behind it.

If the store has vanished from Maps but the website still ranks, that is a profile problem: module one covers it, and the suspension walkthrough is the short version. The two get confused constantly, and confusing them costs weeks.

The actions that actually reach cannabis sites

There are a dozen manual action types. In this industry, six of them account for nearly everything, and they cluster by where they came from rather than by how they are named.

• Scaled content abuse and thin content are the two that take down chains, and they are the same underlying fault seen from two angles: a large number of pages that exist to cover keywords rather than to serve readers. Google consolidated the language around scaled content in 2024, and the important part of that update was that it stopped mattering whether a human or a machine produced the pages. Volume plus sameness plus no added value is the test.
• Cloaking and sneaky redirects are the cannabis specific pair, because almost every dispensary site has an age gate and a meaningful number of them are built in a way that shows Googlebot something other than what a person sees. That has its own section below, because it is the one people are most surprised by.
• Unnatural links is usually archaeology. Somebody bought a directory package years ago, possibly a previous agency, possibly a founder who has since left, and nobody remembers.
• User generated spam is a comment section or a forum nobody has opened since launch.
• Pure spam is the exception to everything in this module. If that is the notice, the honest conversation is about whether the domain is worth recovering at all, and frequently it is not.

A related trap sits alongside the first of those. Marking cannabis products up with Product schema is ineligible by policy and adds risk for nothing, which module six goes into.

Site-wide or partial: the line that sizes the job

The notice contains one line that decides how large this project is, and it is easy to skim past while reading the alarming part. It says whether the action affects specific pages or the whole site.

A partial match is survivable and often barely visible in revenue. A defined set of URLs is demoted, the rest of the site continues, and the work is contained. It is also a warning: the same fault usually exists elsewhere, and the reviewer named a sample.

A site-wide match is a different event. It applies to everything, including the pages that were perfectly fine, including the homepage, including branded search. The store’s own customers cannot find its hours by searching its name.

That is the version where somebody senior needs to be told the same day, because it is a revenue problem rather than a marketing problem.

The practical difference for you is scope discipline. On a partial match you can fix the named set and reasonably appeal. On a site-wide match, fixing only the named examples is the single most common reason a first appeal comes back rejected, which is the subject of two sections from here.

Why dispensary chains attract scaled content actions

Nobody sets out to build scaled content. It is what happens when a reasonable instinct meets a template.

A chain opens its fourth store and wants a page for that city, because it wants to rank in that city, which is correct.

The fastest way to produce it is to copy the last one and change the city name, which is also, for a while, harmless. At four pages it is a small site.

At forty it is a pattern, and the pattern is what a person sees when they open three of them in a row.

Three things make cannabis retail worse than average for this. Compliance copy is genuinely repetitive, because the same warnings and the same licence language have to appear on every page, which inflates the similarity before anybody writes a word.

Menu embeds are identical across locations, so a large block of every page is the same by construction.

And multi state operators often run near identical brand copy across markets for legal review reasons, which is sensible for the lawyers and expensive for search.

Before you write anything else, measure it. A similarity number across the location pages is the fact the whole recovery is built on, it is the first thing to put in front of the owner, and it is what tells you whether you are rewriting eight pages or eighty.

How alike location pages get without anybody noticing is the short version of why this happens.

The location page checker samples the pages from your sitemap, strips the shared navigation and footer so the boilerplate does not flatter the result, and scores what is left.

The age gate trap, and how it becomes cloaking

This is the one that catches careful operators, because the offending feature was installed for a good reason and usually by somebody senior insisting on it.

An overlay is fine. The page exists in the HTML, the gate sits on top of it, and a crawler receives the same document a person receives. Nothing is hidden from anybody.

A hard redirect that sends every visitor to a splash page before they can reach anything is honest but self defeating.

Googlebot gets the splash page too, so the content never gets indexed, and the site quietly fails to rank for reasons that look like a penalty but are not one.

The same shape of failure hits an embedded menu that never reaches the HTML, and the menu visibility checker measures it.

The third build is the dangerous one, and it is dangerous precisely because it looks like the clever solution to the second.

Somebody notices the gate is blocking indexing, and adds a rule: if the request is from a crawler, skip the gate. It works. Rankings return. It is also, by definition, serving different content based on user agent, which is what cloaking means.

Two things follow. When you inherit a cannabis site, check this before you check anything else, because it is a live risk sitting in the codebase rather than a historical mistake.

And when you fix it, the fix is architectural rather than a setting: the gate becomes an overlay, the content stays in the HTML, and the compliance requirement is still met.

A crawler-level fetch of the page reports what actually came back rather than what a browser is shown, which is the fastest way to find out what your gate is really doing.

The first forty eight hours

What you do in the first two days mostly determines whether the recovery takes six weeks or six months, and almost all of it is restraint.

Do these two things immediately

1. Screenshot the notice in full, including the date, the type and the affected pages line. You will be quoting it in the appeal, and if the account changes hands or somebody clears the view, you want your own copy.
2. Export sixteen months of Search Console data now, because the window rolls and the before picture is the thing you will need in three months when somebody asks whether this worked. Crawl the site and keep the crawl file too. That crawl is the before state of every page you are about to change, and reconstructing it later is impossible.

Do none of these, however strong the instinct

• Do not delete the affected pages. The instinct is strong and it is wrong twice over: it destroys the evidence of what you fixed, and mass deletion immediately after a notice reads as hiding rather than remediation. Removal is a legitimate outcome for some pages, but it is a decision made after diagnosis, not a reflex on day one.
• Do not appeal the same day. Nothing has changed yet. A same day appeal is a rejection you volunteered for, and it starts a history of rejections that the next reviewer will read before they read your evidence.
• Do not migrate, redesign or change host in the middle of this. Whatever the reason, the effect is that the reviewer can no longer see the relationship between what was wrong and what you changed.

And tell the owner on day one that this takes weeks. An owner told to expect a fortnight will conclude in week three that you have failed, at exactly the point where the real work is halfway done. The engagement process sets that out phase by phase, which is easier than saying it once and hoping.

Finding the real scope

The URLs in the report are examples. They are what a reviewer happened to look at, not an inventory, and treating them as the list is the most reliable way to earn a second rejection.

The method is mechanical. Take the pattern the named URLs share, then find everything that matches it, then find everything the same template ever produced. In practice that means five places, and four of them are usually forgotten:

• Cities you expanded into and left. A store that closed in 2023 whose page is still live and still templated.
• A staging or development subdomain that was never noindexed, carrying a full copy of everything.
• Tag and category archives that assemble the same thin pages into more thin pages.
• Menu filter and parameter URLs, which can multiply a handful of real pages into thousands and eat the crawl budget while they do it. Module six deals with the rest of it.
• Campaign landing pages built by a previous agency, usually on a pattern nobody documented.

Two commands close most of the gap. A full crawl, so you are working from what exists rather than from what the sitemap claims. And a site query in Google filtered to the pattern, which surfaces indexed URLs the crawl may not reach because nothing links to them any more.

Then run the similarity measurement across the whole set rather than the sample. You are looking for the shape of the problem: whether it is forty pages at ninety percent, or four hundred at sixty. Those are different projects with different timelines, and you need to know which one you are quoting for before you promise anything.

Fix, consolidate, or remove

Every affected page gets exactly one of three outcomes, and the decision comes from two questions rather than from taste.

Rewrite when a real store sits behind the URL and the page can carry detail that is true of nothing else: the neighbourhoods this store serves, named staff, parking and the landmark on the corner, promotions running at this address, compliance copy for this state.

That is the standard from module one, and it is the slowest option. It is also the only one that leaves you with an asset rather than a smaller site.

Consolidate when two pages are genuinely competing for the same intent. Two stores in adjoining suburbs with one page each, both thin, both ranking for nothing, become one page that covers the area properly with both addresses on it.

Redirect the weaker into the stronger with a 301. Fewer, better pages is a defensible answer to a reviewer, and it is frequently the right answer commercially as well, because two stores fighting over one keyword usually means neither of them wins it. The cannibalization mapper shows you which pairs are doing it.

Remove when nothing real sits behind the URL. A city you never opened in. A page generated for a keyword. Return 410 rather than 404 where you can, since it states the removal was deliberate.

Do not redirect it to the homepage, which is a soft 404 and reads as an attempt to keep the equity without keeping the page.

Record the decision for every URL as you go, in a sheet, with a date. That sheet is not project admin. It is the document the appeal will link to, and building it afterwards from memory is both slower and less convincing.

The evidence a reviewer needs

A reconsideration request is read by a person with a queue. They are not looking for contrition. They are looking for a quick answer to one question: has this actually been fixed, or is this another appeal from somebody hoping.

The single most persuasive element is a list of URLs you found that the report did not name. It demonstrates that you diagnosed the fault rather than patched the examples, and it is the difference between an appeal that reads as compliance and one that reads as understanding.

Build the sheet with one row per URL and five columns: the URL, what the page was, what it is now, the action taken, and the date.

Keep it public and readable without a login, because a reviewer will not request access to a document.

If pages were rewritten, a before and after of one or two of them, in full, is worth more than a description of all forty.

If the action touched page copy rather than page count, run the new wording through the compliance checker before it goes back up.

The fourth element, what stops this happening again, is the one most appeals skip, and it is the one that separates a fix from a promise. A reviewer has read every possible version of “we will be more careful”.

They have read far fewer versions of “new location pages now require named local detail and pass a similarity check before they can be published”.

Writing the request

Short, specific, and structured. Four parts, no preamble, no history of the business, no apology paragraph.

Name the fault in your own words, plainly, without hedging. “We may have had some content issues” tells a reviewer you either do not know or will not say. “We published 41 location pages from one template and they were near duplicates of each other” tells them you found it.

Then what was done, in numbers rather than adjectives. Then the link to the sheet. Then the process change. Three hundred words is plenty; the document carries the detail. The reconsideration request builder walks through these four parts and assembles the text, which is mostly useful for making sure nothing is missing and nothing extra crept in.

Two things to leave out. Do not blame a previous agency, even accurately; it does not change what is on the site today and it reads as deflection. And do not mention the commercial impact. It is real, and it is not the reviewer’s concern, and every sentence about it is a sentence not spent on evidence.

After you submit

You get an automated confirmation, and then silence. Reviews take weeks rather than days, and there is no queue position to check.

If it is revoked, the report clears. Ranking does not return that day, and that gap is the part worth warning the owner about in advance rather than explaining afterwards.

If it is rejected, the overwhelmingly likely reason is scope. You fixed what was named and the reviewer found what was not.

Go back to the audit, widen it, fix the rest, and resubmit with the additional URLs called out explicitly, because “we also found and fixed these fourteen” is a strong signal on a second attempt. What a denial usually means goes through the common reasons in order.

What matters is that every submission contains a real change. A resubmission that is the same work with better wording teaches the next reviewer that this account appeals rather than fixes, and that impression is expensive to undo.

What recovery actually looks like

This is where most of the disappointment in this work comes from, and almost all of it is avoidable by setting the expectation early.

The fall is instant. The return is not. After revocation the pages have to be recrawled and reassessed, and the ones you rewrote are effectively new pages competing on their merits rather than resuming a position they held. Expect weeks of climbing rather than a step back up.

And it usually settles below the old line, for a reason that is easy to explain and worth explaining before it happens: some of that traffic belonged to pages you removed or merged. Those pages were ranking.

Thinly, for terms with little intent behind them, but ranking. A smaller, honest site that recovers to eighty percent of the old number is frequently earning more than the old number was, because the traffic that came back is the traffic that converts. The case studies give the measurement window on every figure for exactly this reason.

Say that at the start. An owner who hears it in month one treats it as a plan. An owner who hears it in month three hears an excuse.

Not getting a second one

A recovered site with the same publishing process will produce the same problem, usually within a year, usually when the chain opens three more stores and somebody is in a hurry.

1. No new location page publishes without named local detail. Not a field to fill in, a rule about what the page must contain: neighbourhoods, staff, parking, local promotions.
2. Run a similarity check before publishing, not after a notice arrives. Anything above seventy percent against an existing page does not go live.
3. Check the age gate after every deployment, from the crawler view rather than the browser view. It only takes one developer solving an indexing problem the clever way.
4. Audit what is indexed once a quarter. Staging subdomains, parameter URLs and abandoned campaign pages all appear on their own.
5. Keep the sheet. If it happens again, having the previous remediation documented is worth a great deal.

The uncomfortable truth is that most manual actions in this industry are self inflicted by people doing sensible things slightly too fast. The prevention is not vigilance, which fades.

It is a rule about what is allowed to be published, written down while somebody still remembers what a bad month this was.

If the rebuild is larger than the team can absorb, that is what the recovery work we take on is for, and the free audit will tell you which of the two you are looking at.