Telling a core update from an attack, using data you already have

The prior, stated plainly

Most suspected negative SEO attacks are algorithm updates. That is the most useful sentence on this site for someone reading it mid-emergency, and the rest of this page exists so you can test it against your own data instead of believing me.

It rests on two documents rather than on intuition. The first is Google's own enumeration of why search traffic falls: algorithmic updates, technical issues, security threats, spam policy violations, seasonality and changing interests, site migrations, and reporting glitches. Third-party sabotage is not on the list. The second is the mechanism a link attack aims at, which Google retired in 2016. Announcing that Penguin - the ranking system built to deal with manipulative links - had become part of the core algorithm on 23 September 2016, Google wrote that it "now devalues spam by adjusting ranking based on spam signals, rather than affecting ranking of the whole site." The December 2022 link spam update went further: when Google's systems nullify spammy links, "the link credit that was previously generated is lost." A link that confers nothing also costs nothing.

No published figure exists for what share of suspected attacks turn out to be updates, and you should distrust anyone who quotes you one. This is reasoning from Google's own account of causes plus the documented shift to devaluation - a sound inference, not a measurement. What it changes is the order of operations. The question is not whether to check the update calendar, but whether to check it before or after paying for a link cleanup. Check it first; it is free and it takes an hour.

What a core update is, in Google's words

A core update is a broad, scheduled change to how Google ranks everything, not a judgment about you. From Google's own guidance on core updates and your website: "Several times a year, Google makes significant, broad changes to our search algorithms and systems," and "These changes are broad in nature, and don't target specific sites or individual web pages." Most site owners never notice one - Google says "most sites don't need to worry about core updates and may not even realize one has happened."

The analogy Google reaches for is a list of the top twenty restaurants in a city. When the list is redrawn, "restaurants that move down aren't necessarily 'bad'; there are just other restaurants that make your top 20." It is a careful sentence and worth sitting with, because it says something a frightened owner rarely hears: your pages can be exactly as good as they were last month and still be lower, because the comparison set changed.

Three consequences follow, and they are the whole point of this page.

1. A core update drop is not a penalty. Nothing has been issued against your site, there is nothing to appeal, and a reconsideration request has no target to aim at.
2. Nobody did it to you. Google states that core updates do not target specific sites. A competitor cannot trigger one against you, cannot aim one, and cannot buy one.
3. The clock is long. Google recommends waiting "at least a full week after a core update completes before analyzing your site in Search Console," and says of any recovery that while "some changes can take effect in a few days," it "could take several months" for its systems to confirm a site is producing helpful content over the long term. Act inside the rollout and you will be reacting to a half-applied change - then credit its completion to whatever you happened to do in the meantime. That is how false recovery stories are manufactured, and the industry runs on them.

Where the confirmed timeline lives now, and what it does not cover

Google's ranking update history moved. It is published on the Google Search Status Dashboard, and as of September 2026 the older documentation address for the ranking updates list redirects there. That relocation matters practically: the older list is what most third-party articles still point at, and a redirect is easy to follow but easy to mis-cite.

The detail that makes the dashboard diagnostic rather than merely informative is that every entry carries two dates - a launch date and a completion date. Recent entries, as listed there in early September 2026, include the August 2026 spam update (18 to 20 August 2026), the June 2026 spam update (24 to 26 June 2026), the May 2026 core update (21 May to 2 June 2026), the March 2026 core update (27 March to 8 April 2026), and the December 2025 core update (11 December to 29 December 2025).

Read both columns. The March 2024 core update ran from 5 March to 19 April 2024 - six and a half weeks between launch and completion. The August 2025 spam update ran from 26 August to 22 September 2025. An owner who saw a fall on 20 March 2024, checked a list showing launch dates only, thought "that update was two weeks ago," and concluded it must be something else was simply wrong: the update was still rolling out on the day their traffic moved. This single reading error sends more people looking for an attacker than any other.

Now the limit of the source, stated by Google itself: "We post about notable improvements to our systems on our list of ranking updates page." The operative word is notable. Google changes ranking continuously and announces a small fraction of it. A drop that does not land on a listed update is therefore not evidence of an attack. It is evidence that Google did not announce whatever happened - which is the ordinary case, not the exceptional one.

Third-party volatility trackers - the "SERP weather" products - are worth consulting and worth distrusting as primary evidence. Each measures the vendor's own fixed keyword panel in the vendor's own locations. They answer "did this market move on that date," which is genuinely useful. They are not announcements, and treating a volatility spike as confirmation of an unconfirmed update is inference stacked on inference.

How to date a drop precisely

Precision is the whole game here. "Around the middle of March" is not a date and cannot be matched against anything.

1. Open Performance, Search results, with a range wide enough to include a stable baseline - several months before the fall, not two weeks.
2. Switch to the Dates tab and read the day-level table. Export it. The chart smooths step changes; the table does not. Then discard the most recent days: Google states that "The newest data can be preliminary, meaning it's still being collected and might change in the next few hours." A "drop" that is only the last day or two of the chart is frequently incomplete collection, and it generates a meaningful share of the panic in this subject.
3. Identify the shape, because shape is diagnostic in a way that depth is not. A cliff on one day with a flat line after it is a discrete event - a deployment, a robots.txt fault, a certificate, a security flag, a manual action, a hijack. Core updates rarely look like that; they ramp. A ramp over days or weeks settling onto a new plateau is the classic update signature, and you can match its start and end against the two date columns. A repeating annual shape is seasonality. A single anomalous day followed by recovery is a reporting glitch or an outage, not a ranking event at all.
4. Separate impressions, clicks and position. Clicks down with impressions and position flat is a results-page or measurement effect, not a ranking one, and neither an update nor an attack is implicated.
5. Run the comparison Google prescribes: the Date filter, the Compare tab, then last three months against the previous period or year over year - and look at what changed by query, page, country, device and search type rather than in the total.
6. Do not analyze inside the window. Wait the full week after completion that Google advises. Everything you conclude before then, you will have to conclude again.

Did competitors move too? The decisive test

This is the single most informative check available, and almost nobody runs it, because it requires having recorded something before the incident.

The logic is simple. A core update reshuffles a market. A sabotage campaign, if it worked at all, moves one site. So the results page tells you which happened:

• The whole first page reshuffled and sites you have never thought about are now above you - an update. Overwhelmingly the most common finding.
• You fell, everyone else held their exact positions, and a new site appeared in your slot - still probably an update, but worth a second look.
• You fell, everyone else held, and nothing filled your slot - this is the pattern that is not update-shaped. Deindexing, a hijack, a manual action or a security flag all produce it, and so, rarely, does a genuine attack.

How to run it with data you actually have: use the Compare tab on the Performance report's Queries view - if impressions held while clicks and position fell, you are still being shown and have been displaced, which is a competitive change; if impressions collapsed too, you are being shown less often, which points at indexing, eligibility or a topic-level reassessment. Then read a rank tracker's history if one was running, and read the whole stored result set rather than your own row, because the stored top ten is the market's before-and-after and is worth more than any backlink report. Archived copies of competitor pages can show whether one of them materially changed near the date - slow, often inconclusive, free, and contemporaneous.

And if no historical data exists at all, say so and stop. A competitive before-and-after cannot be reconstructed after the fact, and pretending otherwise is how confident wrong answers get sold. Start recording it now; the record you want is described in negative SEO monitoring.

What the scope of the drop implies

Sort your Performance export by scope before anything else. Each scope has a short list of plausible causes, and the lists barely overlap.

Site-wide - everything fell, roughly proportionally

Most likely a core update reassessing the site as a whole, a site-level technical fault (hosting, DNS, certificate, a noindex or robots.txt rule shipped site-wide, a botched migration), a security issue putting warnings in front of users, or a site-wide manual action. The attack cases that fit are a hacked-site injection producing a site-level spam signal, a malware flag, or a site-wide redirect hijack - all of which are visible in Search Console in about a minute. If manual actions and security issues are both clean and the drop is site-wide and update-dated, Google's own remedy is a content self-assessment, not a link cleanup: its guidance for a sustained site-wide fall is to check whether the site overall is "delivering content that's helpful, reliable, and people first."

Query cluster - one topic fell, the rest of the site held

This is the most characteristic core-update shape there is, and it is the one most often misdiagnosed as an attack, because it looks aimed. It is not. Other honest explanations: an intent shift on those queries, a results-page feature now occupying the space, cannibalization between your own pages after a content change, or a seasonal collapse in one product line.

The attack cases that fit are essentially none, and this is the sharpest single diagnostic on the page. An outsider cannot selectively suppress one topic cluster on your site while leaving the rest intact. No documented link, content or listing attack has that granularity - not one. Links land on URLs, hijacks land on URLs, takedowns land on URLs; none of them has a concept of "your commercial category pages but not your blog." If the drop is query-clustered and the rest of the site is healthy, the answer is an update or an intent shift, and a link cleanup will do precisely nothing.

Page level - one or a handful of URLs

Most likely canonical consolidation, internal cannibalization, a page that was edited, redirected or accidentally set to noindex, or a page-level quality reassessment. But this is also the scope where an attack is genuinely plausible and where the evidence is genuinely obtainable: a canonical or 302 hijack, a fraudulent DMCA takedown removing specific URLs, or a scraper being consolidated over the original. Inspect each affected URL and read the Google-selected canonical field first, as set out in the diagnostic procedure.

Core update or spam update? The distinction changes the remedy

The dashboard lists both, and they are not the same event.

A core update is a broad ranking change. No policy violation is asserted, Google's remedy language is content self-assessment, and recovery is tied to a later reassessment. A spam update is Google's spam systems being refreshed. A drop on a spam-update date with no manual action in Search Console is an algorithmic spam demotion: nobody reviewed your site, a system reclassified something.

Before assuming that applies to you, read what the policy actually prohibits. Google's spam policies define link spam as "the practice of creating links to or from a site primarily for the purpose of manipulating search rankings," and every example given is conduct by the site owner - buying or selling links, excessive exchanges, "Using automated programs or services to create links to your site," advertorials, widget links, "Widely distributed links in the footers or templates of various sites," and "Forum comments with optimized links in the post or signature."

The link spam policy describes things you do, not things done to you. Nothing in it makes a site responsible for links a third party pointed at it, and Google says separately that it "works very hard to make sure that actions on third-party sites do not negatively affect a website." That is worth reading twice if you have spent a week frightened of somebody else's link building.

The practical difference: a spam-update drop is the one case where reviewing your own link acquisition history is genuinely indicated, because those systems act on link spam. Even then the documented behavior is nullification of the offending links rather than transfer of blame to the target. A spam update landing in the same week as an inbound spam run is a coincidence to be tested, not a causal chain to be assumed.

The honest failure modes of this exercise

A diagnosis that does not state its own limits is a sales pitch. Five limits apply to everything above.

• Unannounced changes are the norm. Notable improvements get posted; the rest do not. A drop with no matching entry is unexplained, not malicious.
• Correlation with an update date is not proof either. Something else can happen on the day an update launches. The calendar shifts the odds heavily; it does not close the question.
• Rollouts overlap. In March 2024 a core update and a spam update launched on the same day and completed a month apart. Inside a window like that, a date alone cannot tell you which one moved you.
• Google's own reporting can move. Reporting glitches are a named cause with a shape of their own.
• There is no control group. Everything here is inference from shape, scope, timing and first-party reports. A good diagnosis says how confident it is, and "probably an update, and here is what would change my mind" is a better answer than a certainty nobody can support.

The mistakes that cost the most

• Buying a link cleanup for an update-shaped drop. The most expensive error in the subject, and it produces a false success story when the next update restores some visibility months later.
• Disavowing during a rollout, then crediting the disavow with whatever happens next. Google restricts the tool to links that caused or are likely to cause a manual action.
• Filing a reconsideration request after a core update. There is no manual action to reconsider.
• Treating a query-cluster drop as targeted. It is the most update-like pattern that exists.
• Reading launch dates only and concluding the update was too long ago.
• Deleting or rewriting content in a panic. Google's guidance is that improvements should be meaningful rather than cosmetic and that deleting content is a last resort.
• Concluding "it must be an attack" from the absence of any other explanation. Absence of explanation is the normal state of a search ranking change, and it is not evidence of anybody's hand.

Frequently asked questions