Website diagnostics: from symptom to cause

Website diagnostics the way a doctor works: start from the symptom — slow pages, lost traffic, mail in spam, outages, browser warnings — and find the cause.

Infrastructure · Published: 8 October 2026 · 6 min read · Дмитрий Орлов

Nobody runs website diagnostics for fun. It starts with a complaint: "the site is slow", "traffic halved", "clients say our invoices land in spam", "Chrome shows a warning". A complaint is a symptom, and the same symptom can have five unrelated causes. Good diagnostics goes from the symptom to a short list of suspects, checks each one with a measurement, and only then changes something.

Below are the five complaints we hear most often, with the usual causes and how to confirm them.

"The site is slow"

First ask: slow for whom and at which moment? Three different problems hide behind this phrase.

• The server is slow to answer. Time to first byte above 800 ms means the HTML is generated slowly: no page cache, heavy database queries, an overloaded host. Every page is slow, including tiny ones.
• The page is heavy. The first byte arrives fast, but the main image is 2 MB, fonts and scripts block rendering, and the largest contentful paint crosses 2.5 s. Typical for marketing pages.
• Repeat visits are slow too. Static files are sent without Cache-Control, so the browser downloads the same CSS and JS on every page. See HTTP caching.

Also check compression (HTML and scripts without gzip or Brotli) and HTTP/2. A redirect chain on every internal link adds a round trip each time.

"Traffic dropped"

Separate a sudden drop from a slow decline. A sudden drop after a release almost always has a technical cause:

• robots.txt from staging with Disallow: / went live — check what robots.txt actually says;
• a noindex landed on templates that should be indexed — product, category or article pages;
• canonical tags point to another host, to plain HTTP or to the home page; read about canonical URLs;
• old URLs return 404 after a migration instead of a 301 to the new address;
• the site started answering 5xx to crawlers under load.

A slow decline over months is usually not technical: competitors, content, search algorithm changes. Diagnostics from outside will not explain that — but it rules out the technical causes in minutes.

"Our emails go to spam"

Mail from your domain is judged by DNS records that have nothing to do with the website itself, which is why they are forgotten.

1. SPF lists the servers allowed to send for the domain. A missing one, or a second v=spf1 record, breaks it.
2. DKIM signs messages; it is configured at the mail provider.
3. DMARC tells receivers what to do with mail that fails the checks. Without it, large providers increasingly treat mail as suspicious.
4. Reputation. If the domain or its IP is on a DNS blocklist, even perfect records will not help. The report shows DNS blocklist results.

Details and examples of records are in email authentication.

"The site is down"

Before blaming the hosting, rule out the things that expire:

• The TLS certificate. Automatic renewal breaks quietly — a changed DNS, a firewall rule, a full disk. One day browsers show a full-page error.
• The domain. An expired card or an old email at the registrar, and the domain stops resolving.
• DNS. Moved nameservers, a deleted record, a typo in an A record.

All three are visible from the outside days or weeks in advance; see expiry dates. If none applies and the server answers 5xx or times out, the cause is on the server: logs, resources, the latest deploy.

"The browser shows a warning"

• "Not secure" in the address bar — the page or a form is loaded over HTTP, or an HTTPS page pulls scripts and images over HTTP. That is mixed content.
• A full-page certificate error — expired certificate, wrong host name, or a missing intermediate certificate. The last one is treacherous: desktop Chrome often fixes it by itself, while Android and API clients fail. Check the certificate chain.
• A "deceptive site" warning — the domain is on a safe-browsing list, usually after a hack. That is a security incident, not a configuration problem.

How to run diagnostics with SiteScan

A scan from the outside covers most suspects at once: response time and page weight, compression and caching, robots.txt, noindex and canonicals, broken links, certificate and domain dates, SPF, DMARC and blocklists. What it cannot see is your server logs and search console data, so combine both.

Run a scan of the affected site, open the category that matches the symptom and look at the critical and high findings first. After the fix, rescan to confirm the cause is gone rather than assuming it.