How to get notified when your organic traffic drops

Most people find out about a traffic drop in one of two ways: a client emails, or the monthly report comes round. Both are late. Search Console had the number days earlier and did nothing with it, because Search Console does not do anything with numbers. It shows them to whoever turns up.

This post is about closing that gap. There are three realistic ways to do it, and whichever you choose, the alert has to be designed a certain way or it will be switched off within a week.

What Search Console already emails you about

Google does send email, and the email is worth keeping: manual actions, security issues, and large changes in indexing coverage all arrive in your inbox. Those are the things that are broken in Search Console’s own terms.

What Google does not email you about is an ordinary, unexplained fall in clicks on a page that still indexes fine. No manual action, no error, nothing in the coverage report, just thirty percent less traffic since Tuesday. Commercially, that is the one that usually matters first, and it is the one you have to arrange a notification for yourself.

Keep one thing in mind for every option below: Search Console performance data is finalised two to three days after the fact, for everyone. No notification can arrive sooner than the data does. The goal is to hear about a drop the day the data is final, instead of the week after.

Option 1: a scheduled report

The least effort. Build a Looker Studio report on your Search Console data and schedule it to be emailed to you daily or weekly. It costs nothing and takes an afternoon.

It is a calendar, not a trigger. The report arrives whether or not anything changed, and you still have to open it and read the chart to see that something did. If it comes weekly, a drop on Tuesday is read on Monday. If it comes daily, you have signed up to read a PDF every morning for the rest of your life. Some people are fine with that, and for a single property it is honestly not a bad deal.

Option 2: a script

The Search Console API is public, and a few dozen lines of Apps Script or Python can pull the latest complete day for a property, compare it with a baseline, and send you an email or a Slack message when the difference is large. Plenty of SEOs have one of these running.

You get complete control and you own all the maintenance: the OAuth token that expires, the day Google’s API returns a partial day you did not expect, the weekend when every property “drops” because you compared Saturday with Friday. In practice the code is the easy part. The hard part is the baseline design, which is the same for every option and is the subject of the last section.

Option 3: an app with push alerts

The newest option. A handful of Search Console apps on iOS and Android now offer push notifications when a property’s traffic moves, QueryWatch among them, and at least one other that you will find on our comparison pages.

There is a trade that every one of these apps makes, and you should know it before you enable anything. A notification has to be computed while your phone is asleep, and a phone cannot reliably run a job every few hours in the background. So the check runs on a server, and that server needs permission to read your Search Console data. That means a credential of yours lives somewhere other than your phone. The app should say where, how it is protected, and what happens when you turn alerts off. We have written out our answers, and the same questions apply to any other app.

What a good alert has to carry, whichever way you build it

The difference between an alert you keep and an alert you mute is not the delivery channel. It is six design decisions.

Compare the latest complete day, not today. Today is always a partial day in Search Console, and a partial day always looks like a drop.

Use a weekday baseline, not yesterday. A site’s Sunday is not its Monday. Comparing each day with the same weekday over the previous four weeks absorbs the weekly rhythm; comparing it with the day before fires every Saturday, and even a seven-day average flags every quiet weekend on a site that lives on weekday traffic.

Set a threshold that fits the site. A property with fifty clicks a day is noisy; one with fifty thousand is not. QueryWatch’s default is a day that sits thirty percent away from its usual weekday, or two standard deviations from it, and both numbers can be changed per property. Whatever your rule, it should be adjustable per site.

Attach the evidence. “Clicks down 34%” is a feeling. “412 clicks on Sunday, Sep 6 against a usual Sunday of 624, and /pricing explains 56% of it” is something you can act on, and still makes sense a week later when the numbers have moved on. Those figures are from our demo dataset, but they are the shape every alert should have.

Cap it. One notification per property per day. An alert that fires twice for the same drop trains you to ignore it.

Fire on spikes too. A sudden rise is information as well, usually happier, and occasionally the first sign of a page ranking for something it should not.

That is the design. The alerts page describes how QueryWatch implements it, including the four rules, the six-hour check and what the notification actually looks like, and the anatomy of a traffic alert goes through each field and why it is there.