What is worth monitoring, what is situational, and what is fear insurance

The two questions that sort the whole market

If this alert fires at two in the morning, what will I do differently? A monitor that produces an alert you would not act on is not monitoring. It is a subscription. On this subject the distinction matters more than usual, because an entire product category sells continuous alerting about a threat whose central mechanism Google says it neutralizes - and because the natural response to those alerts, disavowing more, is the response Google's own documentation warns can hurt you.

The second question is narrower and more useful: would this record be worth having if I had to reconstruct what happened six months from now? Most of the genuine value of monitoring here is not real-time warning at all. It is contemporaneous baseline. You cannot reconstruct a competitive before-and-after after an incident; you can only have recorded one. That single insight reorders everything below, and it is why the highest-value items on this page are the ones nobody sells hard, because they do not page anybody and therefore do not feel like a product.

Nothing here prevents an attack. The honest claim for good monitoring is smaller and worth more: it shortens the time to a correct diagnosis, and it leaves a dated record if the diagnosis ever has to survive a challenge.

Tier one: Search Console verification, and the alerts nobody reads

Start here, because it is free, first-party, and covers the two things genuinely capable of destroying a site's traffic overnight - a manual action and a security issue. No third-party monitor can see either one. This is the highest-value monitoring available anywhere in the subject and it costs nothing.

Basic Search Console verification is the whole of the setup. Google's own guidance for site owners states that once verified "you'll receive email if any unusual events occur with your website. Unusual events include indications that your website has been hacked or problems that Google had when crawling or indexing your site" (Basic Search Console usage for website owners). For the report that matters most, Google states separately that a site affected by a manual action is notified in the Manual actions report and in the Search Console message center.

Now the monitoring failure that actually happens, and it is not exotic: the alerts go to an address nobody reads. A departed employee. A former agency. A generic webmaster alias routed to a mailbox no one owns. I have opened message centers holding two years of unread notices on sites whose owners were paying for third-party alerting the entire time. Verify multiple owners, on addresses read by someone who works at the company today, and check the message center for a backlog before you buy anything at all. This is the single most common real monitoring failure in this subject and fixing it costs nothing.

Verify both property types while you are there. A Domain property and a URL-prefix property expose different reports, and some - the robots.txt report and Crawl stats among them - are documented as domain-level or root-level only.

Tier one: uptime, response time, and the two checks people leave out

Uptime monitoring - an external service requesting your site on a schedule and alerting when it fails or slows - is cheap, unambiguous, and catches the category Google names first among technical causes of lost traffic: errors that prevent Google crawling, indexing or serving your pages, including server availability and robots.txt fetching.

It is also the only monitor that catches a crawler flood or scraping run while it is happening rather than in a post-mortem. Watch response time, not just up or down: a site that is technically up and answering in eight seconds is failing users and being crawled less. Corroborate anything it reports against Crawl stats, which holds ninety days of crawl requests, download size and average response time with a host status section.

Monitor /robots.txt as its own check, separately from the homepage. Google's crawl documentation is explicit: it "requests this file frequently, and if the request doesn't return either a valid file (either populated or empty) or a 404 (file does not exist) response, then Google will slow or stop crawling your site until it can get an acceptable robots.txt response." A generic uptime check watching your homepage will not see a 500 on that one file, and that failure suppresses crawling across the whole site. It is also exactly what a hastily installed bot-blocking product can cause, which makes it the check most worth adding immediately after any defensive change - the moment when people are least inclined to add checks and most likely to need one.

Monitor certificate expiry separately too. It is a classic overnight cliff, and uptime checks configured to ignore certificate errors will sail straight past it.

Tier one: file integrity, and the inversion nobody says out loud

Here is the argument this page exists to make. The negative SEO vectors that reliably work are the ones that change your own site: injected pages, injected redirects, cloaked content, modified templates, a hijacked canonical. Meanwhile the vector that gets monitored most - inbound links - is the one Google says it nullifies.

Monitoring spend in this subject is almost exactly inverted relative to risk. The category aimed at the attacks that actually work is systematically under-purchased, and the category aimed at the attacks that mostly do not is sold as essential.

What to watch: checksums or version control over the document root, themes and extensions; alerts on new files appearing in writable directories; alerts on changes to server configuration, redirect rules and robots.txt; database change alerts for injected content; and administrative account creation. Where a site deploys from version control, an alert on any drift between the repository and the live filesystem is the entire control in one line.

Add a rendered-page check on top of it, because file integrity misses server-side cloaking that varies by user agent. A periodic fetch using Googlebot's user agent, diffed against a fetch as an ordinary browser, is what surfaces a cloaked injection. It is cheap, it is rarely done, and it is the difference between finding an injection in a day and finding it in a quarter.

Tier one: the brand results page and the Business Profile

The Google Business Profile is the only attack surface in this entire subject with an author-attributed edit history, and it is a surface where third parties can propose changes that go live. Suggested edits, a false closure flag, category changes, address and phone changes are all documented vectors, and they are among the few negative SEO attacks that reliably work. For a business that depends on local visibility this is the second-highest-value monitor after Search Console alerts. For a business with no local footprint it is close to worthless. Be honest with yourself about which one you are.

Capture the brand results page periodically as well - a dated screenshot or archive of the full first page for the company name. That is baseline rather than alerting: it is what lets you show later that something changed, in a form that reads as evidence rather than as recollection. Free alerts on the brand name and distinctive product names are low-noise for most businesses and surface both hostile content and scraper republication.

Tier one: the records you will wish you had

None of these are alerts. All of them are the reason a later diagnosis is possible at all, and every one of them has to exist before the incident.

• Rank tracking that stores the whole result set, not only your own position. The stored top ten is what answers "did competitors move too," which is the decisive test in telling an update from an attack. A tracker that records only your rank cannot answer it, and no amount of money spent afterward will reconstruct it.
• Periodic Links report exports. Google documents the limits: the landing-page export yields up to 100,000 rows, the per-table download up to 1,000. A quarterly export is a dated, first-party record of your link profile that no third-party index substitutes for.
• Performance exports, or the bulk data export for sites where interface row limits bite. Google states that the first export happens up to 48 hours after configuration and that historical data preceding your setup requires other methods. It does not backfill. Configure it after the incident and it cannot tell you about the incident. That fact alone is the argument for setting it up while nothing is wrong.
• Extended server log retention. Logs are the only record of what actually requested what, default configurations discard them within days or weeks, and extending retention is close to free. If a matter ever becomes legal, this is the exhibit.
• A dated crawl of your own site, quarterly. It is how you prove a page existed, what it said, and what it linked to.

Tier two: situational, and only if you can name the decision

Each of these is defensible for some businesses and a waste for others. The test is whether you can name the decision the alert informs.

Backlink alerting on new referring domains. Useful as a tripwire, useless as a penalty predictor. Useful because a sudden cluster is sometimes the first visible sign of scraper republication or a redirect hijack, and because it timestamps the arrival of links you may later have to describe. Useless as a predictor because the thing it is sold to predict - a link-driven penalty - is not how Google's documented behavior works, and because it fires on discovery date rather than creation date, so it will alert you to a vendor's crawl schedule as readily as to an event. If you keep it, configure it on anchor distribution rather than volume. The count is mostly noise; the distribution occasionally is not.

Review monitoring. Genuinely valuable where reviews drive revenue and worthless where they do not. The attack is real and the platform recourse is time-sensitive, which is what makes alerting rather than periodic checking justifiable.

Copy detection. Scraping is common; scraping that outranks the original is rare and usually indicates a weakness in the original's indexing rather than an attack. Worth having if your content is a competitive asset. Not worth having as insurance against ranking loss.

Index-count checks - done correctly. Do not track site: counts: Google states the operator "doesn't necessarily return all the URLs that are indexed under the prefix specified in the query," that results are "not always exhaustive," and that it is designed primarily for search users. Track the Page indexing report's indexed count and the movement in each reason instead. The deltas are the signal; the totals are not. Where site: does earn a periodic manual sweep is qualitatively - paging through it looking for pages you did not create.

Blacklist checks are largely redundant with Search Console's Security Issues report for Google, and worth adding only for the non-Google lists, which have their own delisting paths. Removals checks - the Outdated content tab, which shows removal requests filed by non-owners - cost almost nothing to check periodically, though how completely or promptly it surfaces third-party requests is not documented anywhere I can point to.

Tier three: fear insurance. Do not buy it

This tier has a name and it should be used: it is fear insurance. It is sold against a risk that Google's documented behavior largely absorbs, its output is alarm, and acting on the alarm is what creates the damage.

Toxic backlink monitoring. The flagship product of the category. Its core metric - a toxicity or spam score attached to each referring domain - is a vendor-invented number with no counterpart inside Google. Google publishes no such metric, exposes none in Search Console, and defines none in its documentation. John Mueller of Google, writing publicly on 31 January 2023 about the businesses on both sides of this trade, said: "That's all made up & irrelevant. These agencies (both those creating, and those disavowing) are just making stuff up, and cashing in from those who don't know better" (reported by Search Engine Journal, 2 February 2023). His advice in the same exchange was to spend the time building the site up instead.

The product is not merely wasteful. It is actively hazardous, because its entire output is a standing recommendation to disavow, and Google's own disavow documentation says the tool "can potentially harm your site's performance in Google Search results" if used incorrectly, that "most sites will not need to use this tool," and that it is warranted only where links have caused or are likely to cause a manual action. A monitor whose alerts push you toward a tool Google restricts that narrowly is a monitor that generates risk rather than reducing it.

Negative SEO protection subscriptions. There is nothing to protect. You cannot stop a stranger publishing a link to your site, and the primary defense Google describes is its own systems declining to count it. What can genuinely be hardened is your own site - patching, credentials, file integrity, backups, access control - and that is security spend under its correct name, which is where it belongs on the invoice and in the conversation.

Continuous automated disavow regeneration. The most dangerous product in the category. It acts irreversibly, at scale, without review, on a vendor metric, against Google's stated criteria. It will eventually discard legitimate links, and that discarding is not practically reversible.

Rank tracking hundreds of keywords as an early-warning system, and real-time volatility alerting as an attack detector. Rankings move constantly for a hundred reasons; a tracker set to alert on position changes will fire every week and be ignored by month two. Volatility trackers measure the vendor's own keyword panel and say nothing about your site.

One disclosure, because it is the reason this section is worth reading. A practice that sells negative SEO recovery has an obvious commercial interest in telling you the opposite of everything in this tier. It is still true, and I would rather lose the engagement than have you buy it.

Alert fatigue, and what to do when something does fire

A monitor that fires constantly and is never actioned is worse than no monitor at all. It trains the team to dismiss the channel a real alert will arrive on, and it builds a documentary record showing the organization was told and did nothing - which reads badly in exactly the legal context where the monitoring was supposed to help.

So: alert on state changes rather than on thresholds crossed repeatedly. Route Search Console mail to a shared address someone actually reads. Keep the number of alerting channels small enough that each one stays credible. Review the baseline records on a calendar instead of waiting to be paged by them.

And when something does fire, do not act on the alert. Run the detection procedure: preserve the evidence first, then check manual actions and security issues, then date the event, in the order set out in how to check for negative SEO. An alert is a prompt to diagnose. It is never a diagnosis, and the products in tier three are sold on the pretense that it is.

Frequently asked questions