Your Google rankings dropped. Read this before you change anything

What is the first thing to do?

Nothing. Do not edit the page, do not revert the deploy, do not rewrite the content. The most expensive mistake here is changing things before you know what moved, because it destroys the evidence you need and adds a second variable to a problem that had one.

This is the opposite of what the situation feels like. Something is wrong, revenue is attached to it, and doing something is emotionally much easier than doing nothing for an hour. Resist it for that hour.

The reason is practical rather than philosophical. If you change three things today and the rankings recover next week, you have learned nothing and you will do all three again next time out of superstition. If they do not recover, you now cannot tell whether the original cause or your fix is responsible.

So the first hour is measurement. It is genuinely the highest-return hour in the whole process, and almost nobody spends it.

Question one: did anything actually drop?

A surprising share of reported drops are measurement artifacts. Average position is an average, so a change in which queries you appear for moves it without any single ranking changing at all.

Start in Search Console, not in a rank tracker. Compare the same weekday range against the previous period, and look at clicks and impressions separately from position. The three tell different stories and the difference between them is usually the diagnosis.

Impressions steady, clicks down, position unchanged means the ranking held and something changed about the result itself. That is a very different problem from a ranking loss, and it is increasingly common as more answers appear above the results. Impressions down and position steady usually means demand moved, not you.

Also check the obvious dull possibilities before anything else. A rank tracker checking from a different location or device. A seasonal pattern that repeats every year in the same week. A holiday. A tracking change on your side that broke reporting rather than rankings. We have watched teams spend a week on an emergency that turned out to be a tag firing twice.

Question two: which of the three things changed?

You changed something, Google changed something, or a competitor changed something. Everything else is a subcategory. Separating these takes about an hour and it decides the entire response.

The date is the most useful single piece of evidence you have. Pin down the exact day it started, then line it up against your own deploy history. If those two dates match, stop looking anywhere else.

What if it was us?

Then it is almost certainly one of a short list, and it is usually recent, structural, and accidental rather than editorial. The content is rarely the culprit when the drop is sudden.

Notice that most of these are invisible to a human visitor. The site looks completely normal in a browser, which is why teams look at the content first and waste days there. Check the machine view instead: fetch the page as a crawler would, read the raw HTML, confirm the response headers.

The good news about this bucket is that it is the fastest to recover from. Fix the technical cause and the recovery usually follows within a crawl cycle or two, because nothing about your standing changed. You were just briefly unreachable or misdeclared.

• A staging `noindex` or a `Disallow` that shipped to production with a release
• A URL structure change without redirects, which orphans everything that ranked
• A canonical tag now pointing somewhere unintended after a template edit
• Internal links removed in a redesign, so the page lost the paths that fed it
• Pages consolidated or deleted, including ones nobody realized were ranking
• A site move, a host change, or a certificate problem that made pages unreachable while crawlers visited
• A rendering change that put the main content behind JavaScript a crawler did not execute

What if it was Google?

Then you will usually see it across many pages, starting on a date that matches a published core update, and you cannot fix it in a week. Google confirms core updates publicly and runs a status dashboard for incidents, so check both before assuming.

Two things get confused here. A core update is a change in how quality is assessed across the board. A search feature change is a change in what the results page looks like, which can take clicks from you without touching your position at all. The second is now the more common experience and it does not show up as a ranking drop anywhere.

If it is a core update, Google's own guidance is that there is nothing to fix in the sense of a penalty, and that recovery comes from making the content genuinely better rather than from a technical correction. That advice is unsatisfying and it is also accurate. Rewriting in a panic within days of an update is how sites lose the pages that were still working.

The discipline that helps is to wait for the rollout to finish before drawing conclusions. Positions move around during one, sometimes considerably, and the state on day three is not the state on day twenty.

What if it was a competitor?

This is the least dramatic and the most common cause of a single page slipping a few positions. Somebody published something better, or something that matches the query more exactly than yours does.

Go and read the page that passed you, properly, as a buyer would. Not with a tool. Ask what question the searcher was actually asking and which of the two pages answers it more directly, sooner, and with more evidence a person could verify.

Usually the answer is uncomfortable and specific. Their page addresses the exact situation and yours addresses the category. Their page reaches a conclusion and yours surveys the options. They have a number from their own work and you have a general claim.

That is a fixable problem and it does not require a rewrite. It usually requires adding the thing you left out, which you left out because it was the hard part.

What should you not do?

Most of the standard panic response. These are the moves that turn a recoverable dip into a long one, roughly in order of how often we see them.

The thread running through these is acting at a wider scope than the evidence supports. A one-page problem gets a site-wide response, and the site-wide response is what causes the next problem. Match the size of the fix to the size of the finding.

• Rewriting pages that did not drop, because the drop felt site-wide
• Reverting an entire release when one file caused it, which discards good work with the bad
• Disavowing links reflexively, which is rarely the right tool and can cause real damage
• Changing titles and headings across the site to see what happens
• Requesting indexing repeatedly on pages that were never technically broken
• Buying links, which addresses none of the three causes and adds a fourth problem
• Deciding within four days that a core update has ruined you

How long until it comes back?

It depends entirely on which bucket you are in, and anyone who gives you a single number has not asked which one. Technical faults recover in days to a few weeks. Core update effects take a great deal longer, and sometimes the answer is that the previous position is not coming back.

For a technical cause, recovery follows recrawling, so it is bounded by how often the page gets visited, which on a small or young site can be slow. For a competitor cause, it follows whenever you actually close the gap. For a core update, Google's own framing points at the next update rather than at a fix date, which realistically means months.

Say that plainly to whoever is asking. A range with a reason behind it survives contact with a board meeting. A confident date does not, and you will be the one holding it when the date passes.

One last thing worth doing while you wait: write down what you found, what you changed, and on what date. The next drop is much cheaper to diagnose when somebody kept notes on the last one, and nobody ever does.