Which update hit you? The fix depends on the answer
Structure and markup refreshed for current answer engines; the original analysis is preserved.
June 2021 was loud: a core update from 2 to 12 June, and two spam updates on 23 and 28 June, constantly mistaken for one another. They are nearly opposite events. A spam update is a penalty for breaking the spam policies; a core update is a relative re-rating that penalises no one. The recovery is opposite too — so before you fix anything, find out which one moved you.
the short answer
June 2021 brought a core update (2–12 June) and two spam updates (23 and 28 June). A spam update is enforcement — a penalty for breaking the spam policies. A core update is a relative re-rating that penalises no one. Recovery is opposite: spam means remove the violation; core means become a better answer. Diagnose by the dates before you react.
key takeaways
- June 2021 stacked updates: a core update (2–12 June), then two one-day spam updates (23 and 28 June), plus the page experience rollout beginning 15 June — easy to confuse.
- A spam update is enforcement: it demotes sites that break Google’s spam policies (cloaking, auto-generated or scraped content, hacked pages, manipulative links). It is a penalty, and should not affect most sites.
- A core update is the opposite: not a penalty, but a relative re-rating of quality and relevance. A site can drop having done nothing wrong, because the field was re-evaluated.
- The recovery is opposite, so diagnosis comes first: spam means find and remove the violation; core means become a genuinely better answer. Use the dates to tell them apart.
- If a legitimate site seems caught by a spam update, check first whether it was hacked — that quietly turns a clean site into a spam-serving one.
two updates, opposite fixes
Both feel identical from inside a traffic drop — a line on a chart falling — but the cause on the left is a broken rule and the cause on the right is a changed comparison. Treat one as the other and you will work hard in exactly the wrong direction.
The month, in four parts
A loud June; what a spam update is; how it differs from a core update; and how to diagnose which one hit you before you react. Open each part.
01 A loud June
June 2021 was an unusually busy month for Google Search updates, and the crowding is the root of the confusion this note is about. Three different kinds of change landed within weeks of each other. The June core update rolled out from 2 to 12 June, a broad re-rating of the sort Google ships every few months. The page experience update then began its slow rollout on 15 June, the one that makes Core Web Vitals a ranking signal, scheduled to creep along into late summer. And at the end of the month came two spam updates: Google confirmed the first on 23 June and the second on 28 June, each beginning and concluding within a single day, both global and affecting web and image results. Google said very little about the spam updates beyond pointing to its existing spam-prevention documentation, which left site owners to guess at what they targeted. The result was a month in which a site could move for any of three unrelated reasons, and in which the natural human response — to assume the most recent or most talked-about update was the cause — was often simply wrong. That crowding matters because the correct response to each of these is different, and to one of them it is the opposite of another. Before any recovery work, then, the first task is not to fix anything but to establish which event you are actually looking at. The rest of this note is about the most important and most confused pair: the spam updates against the core update, which feel similar from the inside of a traffic drop and call for almost opposite reactions.
02 What a spam update is
A spam update is enforcement. Google’s systems for detecting search spam run constantly, and from time to time Google makes a notable improvement to how they work; when it does, it calls that a spam update and announces it. What those systems look for is content and behaviour that violates Google’s spam policies — and that is a specific list, not a vague notion of low quality. It includes cloaking and sneaky redirects, where a site shows search engines something different from what users see; auto-generated content produced to game rankings rather than help anyone; scraped content lifted from other sites with nothing added; thin doorway pages that exist only to funnel traffic; hacked content placed on a site without the owner’s knowledge; and manipulative link schemes. When a spam update improves detection of these, the sites found to be doing them are demoted or dropped from results. That makes a spam update, unlike a core update, genuinely punitive: it is a consequence for crossing a policy line. The crucial corollary is the one Google states plainly — a spam update should not affect most sites, because most sites are not engaged in spam. So if you run a legitimate operation and a spam update appears to have caught you, that is surprising information worth taking seriously, and it points at a specific, findable cause rather than a diffuse quality problem. The mental model for a spam update is a rule and a referee: you are demoted because something on your site broke a stated rule, and the path back runs through finding and removing whatever that was.
03 How it differs from a core update
Set the two side by side and they are almost mirror images, which is exactly why confusing them is so expensive. A core update is not enforcement and not a penalty. It is a broad re-evaluation of how Google measures quality, relevance, and authority across the entire web, after which results are re-ranked everywhere. A site can fall in a core update without having broken any rule or done anything wrong; it falls because the field around it was re-rated and other pages were judged better answers to the queries it competes for. There is no violation involved and nothing punitive about it. A spam update is the opposite on every one of those axes: it is enforcement, it is a penalty, it is triggered by breaking a specific policy, and it targets the offending sites rather than re-rating the whole field. Hold the contrast on the single question that decides your response — did I break a rule, or did the comparison around me change? A spam update answers the first; a core update answers the second, and answers it with a flat no, you did not necessarily do anything wrong. Because the diagnosis splits there, so does the cure, and not by a little. Spam recovery is the removal of a concrete violation: find the hacked page, delete the doorway directory, strip the manipulative links, comply with the policy, and wait for re-assessment. Core recovery is the slow improvement of substance: become a better answer than the pages now above you, and wait for the next core update to re-rate you. Apply either cure to the other problem and you will work hard in the wrong direction — which is the precise failure this whole note exists to prevent.
04 Diagnose before you react
The discipline that makes all of this usable is to diagnose precisely before touching anything, and the strongest tool for that is the calendar. Map the exact day your traffic changed against the known windows, because in a month like June 2021 the dates separate the causes cleanly: movement inside 2–12 June points at the core update; a sharp change on or immediately after 23 or 28 June points at a spam update, since each landed and resolved in a day; a gradual mobile drift after 15 June might be the page experience rollout instead. Precise timing is the cleanest single signal you have, and it is sitting in your analytics for free. Once the dates narrow it down, let the shape of the change confirm it: spam updates tend to hit specific sites hard and conclude quickly, while core-update movement is broader and settles across a rollout window with aftershocks. Only once you are confident which event you faced should you choose a response, because the responses do not overlap. If it was a spam update, audit for a policy violation — and check first whether the site was hacked, the single most common way a legitimate site gets caught — then remove it and wait for re-assessment. If it was a core update, leave the violation hunt alone, because there is nothing to find, and put the effort into being a better answer. The cost of skipping this step is not abstract: teams that react before diagnosing routinely spend weeks fixing the wrong thing, sometimes damaging healthy content while the real cause sits untouched. Measuring carefully before you move — reading the dates and the signals to know exactly what you are responding to — is the diagnostic discipline the AC Group has worked by for 27 years.
Why diagnosis has to come first
The instinct after a drop is to act — to do something visible quickly, because waiting feels like negligence. But a drop is a symptom, and these two updates produce the same symptom from opposite causes, so acting before diagnosing is acting blind. If you assume the most recent or most-discussed update is to blame, you will often be wrong, and the cost is not just wasted effort: applying a spam fix to a core problem means hunting for a violation that does not exist, and applying a core fix to a spam problem means polishing quality while a hacked page or a doorway directory quietly holds you down. The same chart, read two ways, leads to two incompatible plans.
This is why measurement comes before motion. The dates of your traffic change, set against the known rollout windows, are usually enough to tell the two apart, and they are already sitting in your analytics waiting to be read. Spending an hour establishing exactly what you are responding to is not delay; it is the step that makes the following weeks count instead of cancel out. The teams that recover quickly are not the ones that react fastest, but the ones that diagnose first and then commit fully to the right response. Reading the signals carefully enough to know which update you are dealing with, before a single change is made, is the diagnostic discipline the AC Group has worked by for 27 years.
What to do with this
First, date the change precisely. Pull the day your traffic moved and line it up against June’s windows: 2–12 June for the core update, 23 June and 28 June for the two spam updates, and a slow drift after 15 June for the page experience rollout. Let the shape confirm the timing — a sharp single-day hit on a specific section looks like spam; a broad settling over a rollout looks like a core update. Do not choose a response until you are confident which event you faced.
Then apply the matching fix, and only that one. If it was a spam update, audit for a policy violation — checking first whether the site was hacked, the most common way a clean site gets caught — and remove auto-generated, scraped, or doorway pages, cloaking, and manipulative links, then wait for re-assessment. If it was a core update, do not go looking for a violation, because there is none; deepen your content, cover your topics fully, and earn the authority that makes you a better answer, then wait for the next core update. The whole point is that these two paths do not overlap, so the value is in not confusing them. Measuring carefully before you move, and matching the fix to the update you actually faced, is the diagnostic discipline the AC Group has worked by for 27 years.
Spam vs core updates, plainly: quick answers
What is the difference between a spam update and a core update?
They are almost opposite kinds of event, and confusing them is the fastest way to apply the wrong fix. A spam update is enforcement: Google improves the systems that detect content violating its spam policies — cloaking, sneaky redirects, auto-generated or scraped content, hacked pages, thin doorway pages, manipulative links — and demotes or removes the sites that are breaking those rules. It is, in effect, a penalty for a violation, and Google says it should not affect most sites at all, because most sites are not engaged in spam. A core update is the opposite in spirit: it is not enforcement and not a penalty, but a broad re-rating of how Google measures quality, relevance, and authority across the whole web, after which everything is re-ranked. A site can drop in a core update having done nothing wrong, simply because the field around it was re-evaluated and other pages were judged better answers. So the two differ on the question that matters most for your response: did you break a rule, or did the comparison around you change? A spam update says you may have crossed a policy line; a core update says nothing about rule-breaking at all. Diagnosing which one you are looking at is the whole game, because the recovery for each is not just different but pointed in a different direction.
How do I tell which update affected me?
Start with the dates, because timing is the cleanest single signal you have. June 2021 stacked several updates close together, so map your traffic change precisely against the known windows: the June core update ran 2–12 June, the first spam update ran on 23 June, and the second on 28 June, each of the spam updates landing and concluding within a single day. A drop that lines up with the 2–12 June window points at the core update; a sharp move on or right after 23 or 28 June points at a spam update. Be careful, because the page experience rollout also began on 15 June and ran slowly into the summer, so a gradual mobile shift in that period may be something else again. Once the timing narrows it down, the nature of the change confirms it: spam updates tend to hit specific sites hard and conclude in a day, while core-update movement is broader and settles over the rollout window with tremors after. The reason to be this careful is not pedantry. If a spam update demoted you, the fix is to find and remove the policy violation; if a core update re-rated you, there is no violation to remove and the fix is to become a better answer. Diagnose first, precisely, because the two paths do not overlap and time spent on the wrong one is time lost.
How do I recover from a spam update?
By finding and fixing the actual policy violation, then waiting for the systems to re-assess you — which is concrete in a way core-update recovery is not. A spam update demoted you because something on your site tripped Google’s spam detection, so the work is to identify and remove it: check whether the site has been hacked and is serving spam without your knowledge, which is a common and overlooked cause; remove auto-generated, scraped, or thin doorway pages that exist only to rank; stop any cloaking or sneaky redirects that show search engines something different from users; and clean up manipulative or low-quality links you have placed or acquired. Then bring the site genuinely into line with Google’s spam policies and webmaster guidelines, not just cosmetically. After that, recovery comes when Google’s spam systems re-evaluate the site, which can happen as the systems refresh rather than instantly, so there is a wait built in. The encouraging part is that, unlike a core update, there is a definite thing to fix — a violation with an address — and removing it is a clear, completable task. If you run a legitimate site and a spam update still seems to have caught you, the single most likely explanation worth checking first is that you were hacked, because that turns a clean site into a spam-serving one without the owner realising.
How do I recover from a core update, by contrast?
Differently, and this contrast is the whole reason to diagnose carefully first. Where a spam update has a specific violation to remove, a core update has nothing broken to repair — it re-rated your content against the field and judged other pages better answers for some queries. So recovery is not a fix but an improvement: deepen the substance and originality of your content, cover your topics completely, consolidate or improve thin pages, and earn the authority that makes Google trust you on a subject. None of that is about policy compliance; it is about genuinely being a better answer than the pages now above you. And the timeline differs too: core-update recovery often does not show until a later core update re-rates the field again with your improvements in place, whereas spam recovery follows the spam systems re-assessing your now-compliant site. This is exactly why mixing the two up is so costly. If you treat a core-update drop like a spam penalty, you go hunting for a violation that does not exist and may gut working content in the search; if you treat a spam demotion like a core re-rating, you pour effort into quality while the actual cause — a hacked page, a doorway directory — sits there keeping you down. Reading the signal correctly, then doing the right kind of work for the update you actually faced, is the measured diagnosis the AC Group has practised for 27 years.
A note on sources and timing
This is written at the end of June 2021. We have described the month’s updates as Google ran them — the June core update from 2 to 12 June, the page experience rollout beginning 15 June, and two spam updates confirmed on 23 and 28 June, each concluding within a day and affecting web and image results globally. Google said little about what the spam updates targeted beyond pointing to its spam-policy documentation, so we have described that policy set — cloaking, auto-generated and scraped content, hacked pages, doorway pages, manipulative links — rather than speculating on specifics. We have relied on Google’s consistent framing that a spam update is enforcement that should not affect most sites, while a core update is a non-punitive re-rating. The durable point holds past this particular month: a spam update and a core update produce the same symptom from opposite causes, and the fix depends entirely on telling them apart — the measure-first discipline the AC Group has worked by for 27 years.