I have been doing SEO for a few years; I work at an agency with a portfolio of several dozen clients. Shops, company sites, a handful of content sites, a few WordPress installs somebody built once and nobody knows who. And for a long time my "monitoring" process looked like this: every now and then I would open a client's site, check that everything was in order, run it through the SEO tools and go back to link building.

The trouble is that in SEO an outage does not cost you an hour. It costs you weeks. A site down for three hours at night is one thing. But a noindex pushed by a developer during a deployment and unnoticed for three weeks is a slide it takes months to climb out of - and a conversation with the client in which we are the side that "did not notice" the problem.

So here is how I have it arranged today in Uptime Monitor, and which features genuinely changed my work. No marketing padding - the way I actually use it.

First: availability, but done sensibly

The basics are dull, and that is how it should be. Every client site has an HTTP/HTTPS monitor checked every minute (you set the interval yourself, from 1 minute to 12 hours - for a landing page I look at once a day there is no sense in burning the allowance).

What matters from an agency's point of view:

  • Alerts go where I actually look. E-mail, browser push notifications and phone notifications through ntfy. I have push on the desktop during working hours and ntfy on the phone - an outage at 23:00 reaches me before the client writes in the morning.
  • I set alerts per monitor. For a shop I want to know about everything. For a company blog that goes down for 40 seconds once a quarter, the report alone is enough.
  • The times in e-mails are in my time zone, so "Down since 02:14" means 02:14 where I am, not in UTC. A small thing, but it makes a difference when reporting to a client.
  • Pausing a monitor. The client is migrating hosting on Saturday? I pause the monitor, the break window is recorded in the history and does not spoil the uptime statistics. I then do not have to explain in the report where 97% came from.

On top of that there is the "Needs attention" page - I come in the morning and see on one screen what is down, what came back and which client's certificate is about to expire. That replaced a spreadsheet for me.

Four monitor types, and why an SEO needs three of them

You start by adding an HTTP monitor and that covers 80% of cases. But the remaining types solve exactly the failures you cannot see by eye, because the page opens.

Type What it does When I use it
HTTP/HTTPS Fetches the address and judges the response Every client site, by default
Port (TCP) Opens a connection to host:port Servers that wake up slowly, mail, control panels
DNS Asks a resolver for a record and compares it with the expected value After every migration, on client domains
API (JSON) Compares the shape of a response with a stored pattern Shops and services whose front end feeds on an API

There is one more option worth knowing about: the inverted monitor, meaning "this address must be unavailable". That is how I keep client staging sites locked to an IP. If somebody lifts the block and the staging site starts answering publicly, I get an alert - before Google has time to index a copy of the site.

The SSL certificate, an outage straight from the calendar

A certificate always expires on a Friday evening or on Christmas Eve. I turn on certificate monitoring and get warnings 30, 14 and 7 days before expiry. A certificate error marks the site as unavailable, so if something goes wrong with a Let's Encrypt renewal, I know about it immediately.

Thirty days is exactly as long as it takes to write to the client, remind the client, remind the client once more and finally sort it out with their host.

Content monitoring, or why "the site works" is not enough

Here is where the thing that matters more to SEO than uptime itself begins. A server can answer with a 200 and carry a database error message on the page. To availability monitoring - all fine. To Google - also fine, and that is precisely the problem.

In a content monitor I enter up to five phrases and pick a mode:

  • must contain - the company name in the footer, say, or the text on an "Add to cart" button. If the phrase disappears, the page did not render as it should.
  • must not contain - "Error establishing a database connection", "Fatal error", "Site under construction". A classic after a failed plugin update.

For one client I have a phrase entered from a section generated by an outside supplier's script. When the supplier is down, their section disappears and the page looks normal - apart from being missing half the offer.

What I really like about this monitor is that on a single monitor (one specific URL) I can enter up to five different phrases that matter to me and that ought to be present on the client's page for ranking purposes. If the client removes those phrases from the page, by mistake or on purpose, Uptime Monitor tells me about it.

Site health, the feature I do all this for

This is the module that stopped me treating this tool as "something for sysadmins". Once a day the site goes through an audit, and the result is compared with the previous one. The categories: availability, security, SEO, best practices and performance (Core Web Vitals from Google's CrUX data, that is real Chrome user measurements).

This is not a tool meant to replace dedicated solutions like PageSpeed Insights, Lighthouse and the like, because that is not what the application is for. Its job is watching a site's health in order to catch regressions.

From the list of checks, an SEO mostly cares about:

  • indexing - whether the page carries a noindex in the robots meta tag or in the X-Robots-Tag header,
  • title and meta description - whether they exist and are a sensible length,
  • the canonical address,
  • exactly one H1,
  • the lang attribute,
  • mixed content - resources over HTTP on an HTTPS page,
  • redirect chains - whether the site is reached in two hops instead of one,
  • the meta viewport, structured data and Open Graph, image alts and dimensions.

Plus security (HSTS, CSP, X-Frame-Options, cookie flags, leaked software versions) - less often my department, but excellent material for a conversation about a budget for "technical housekeeping".

The best part, though, is the regression detection. The system does not show me a list of "100 things to fix" the way most auditors do. The history is a change log: an entry appears when something broke, got fixed or changed (plus a control entry every 7 days, so I know we are still watching). When I get a "health got worse" alert, I know something genuinely changed since yesterday.

With every regression I also get context: what else changed in the same time window - whether the page content changed, whether headers disappeared, whether the server changed, how much the HTML grew, whether a redirect appeared. That is exactly the set of facts that lets me write to a developer "you deployed something on 12 March around 14:00 and that is when the noindex slipped in" rather than "something broke, please look into it".

The score for the page itself (without CrUX) is calculated separately, because Core Web Vitals can move without any change on our side - and it is that "clean" score which triggers regression alerts. A sensible decision, otherwise I would be getting alerts about somebody else's fluctuations.

There is also TTFB measured every minute, with a median and a P95 day by day. Not a "test from a single click", but a baseline the recent days are compared against.

Four situations from the last few months

1. A noindex after a deployment

A client (a shop, about 4,000 subpages) was having a redesign done by an outside developer. Deployment on Thursday evening; on Friday morning I have a health degradation alert: the "Search engine indexing" check flipped to an error. The developer had pushed the staging configuration to production, noindex and all.

I reported it at 9:15, it was fixed before 11:00. Without that alert I would have found out at the next audit or - realistically - two weeks later from a drop in impressions in Search Console. At that scale it is the difference between "it did not have time to hurt" and a quarter spent rebuilding.

2. The plugin that ate the server

A content site, traffic mostly from the blog. Nothing was down, nobody reported problems. But the TTFB chart showed the median server response jumping from about 300 ms to over 1.2 s, and staying there. The date of the change matched the installation of an "optimisation" plugin (irony intended) by somebody at the client's company.

I had a specific chart and a specific date. The conversation with the client took five minutes instead of two weeks of establishing whether "it only seems slower to us".

3. The host that was only down at night

A small client insisted on his hosting plan at 90 złoty a year. I maintained the server was overloaded, he maintained that "it always works for me". And he was right - it always worked when he checked, which was during the day.

A monitor running every minute showed regular breaks between 02:00 and 04:00, several to a dozen or so minutes each, almost daily. Uptime for the month: 98.6%. I showed the event history from the last 90 days and the client moved to decent hosting within a week. Google crawls at night just as happily as during the day.

4. The client deleted the phrases the site ranked for

A client in the home renovation business, a site with several landing pages. A new marketing person on the client's side decided the copy "sounded artificial" and rewrote part of it over the weekend. We were not told, because after all it was only a content change.

In the wash, the phrases the entire visibility of those subpages rested on disappeared, and the home page title changed from something specific to the company name and a slogan.

I knew about it on Monday morning from two directions at once. The content monitor on three landing pages reported an error, because phrases set to "must contain" simply stopped appearing on the page. On top of that the health audit showed in its change log that the page content had changed and that the "Page title" check had changed status.

I wrote to the client on Monday with a list of the specific subpages and exactly what had disappeared. We went back to the previous versions of the copy on Wednesday, working those phrases back in on the way in a form that satisfied both sides. The rankings never had time to move.

Without content monitoring I would have seen this at the monthly visibility report, so about five weeks later - by which point "somebody rewrote the copy" already sounds like looking for an excuse.

How I arrange this across several dozen sites

A few things that save me organisationally:

  • Projects. I group monitors by client. A shop has its home page, a product page, the cart, the API and the DNS records in one project - I see the whole client on one screen.
  • Adding several addresses at once. When taking on a new client I drop in a dozen or so URLs straight away (home page, key categories, the most important landing pages) instead of clicking through each one separately.
  • The team and sharing. I share selected monitors with team members. The junior running a client sees the statuses and sets their own alerts, but will not delete a monitor of mine. When needed I grant the editor permission - they can then change the settings of a shared monitor, but still cannot add or remove any.
  • Public status pages. This is the element I underrated and clients love. I create a page with the client's selected services and send them the link. Optionally I protect it with a password. The client checks for themselves whether their site is working instead of writing to me. And along the way they see that somebody is watching over it - which is a surprisingly good argument at renewal time.

What I would tell somebody starting out

Do not start with everything. My sensible minimum for a new client looks like this:

  1. An HTTP monitor on the home page, every 1-5 minutes, availability alert to e-mail and phone.
  2. SSL certificate monitoring with an alert at 30/14/7 days.
  3. Site health monitoring with a regression alert - this is the one thing that defends organic traffic.
  4. DNS monitors on the A and MX records, especially if the client has access to the domain panel (and they always do).
  5. A content monitor with a phrase that must be on the page - ideally from a section that renders dynamically.
  6. A public status page for the client, with the link in the welcome e-mail.

That is fifteen minutes of work per client. In exchange you stop being the person who learns about an outage from the client's e-mail - and start being the one who writes first.

And from my experience: it is one of the cheapest things you can do for client retention at an agency.