EnterraHost
The fastest way to diagnose a website problem is to start from what you can see rather than from the tool you remember. There are nine checks here and they answer different questions, so the symptom you have is a better guide than a list of names.
This is the map. Every check below runs without an account from five regions, and each links to the guide that reads its output.
How to diagnose a website problem
Two questions narrow it almost every time. Is the problem that something cannot be reached, or that something can be reached and is wrong? And are you looking at the server, the network in front of it, or the way search engines see it?
Answer those and the check tends to pick itself. The rest of this page is that decision, written out.
Something is slow
Run the server check first, because it separates the time taken to connect from the time the application took to respond. Those two numbers have different owners. A slow connect is a network or a host problem, and a slow response after a connection is the code.
If the server looks fast and the site still feels slow, the problem is after the first byte and no check here will see it. That is a page problem rather than a server one.
If you want to know how the connection behaves over time rather than once, run the ping test and read the mdev column. A steady 20 milliseconds is a long distance. A jumpy 6 to 42 milliseconds is congestion, and it is the one that makes a page feel like it stalled.
Something is down, or answers from one place and not another
The server check tells you whether a connection completes and what status came back, which is the difference between a site that is down and a site that is up and refusing.
When it answers for you and not for someone else, the problem is usually the path rather than the server. The traceroute shows the hops and where the delay appears, and it is the tool that distinguishes a distant server from a congested route.
A page that responds in a browser and reports total loss to a ping is blocked rather than broken, and the server check separates that case too.
Search traffic fell, or a page will not appear
Work through these in order, because each assumes the one before it.
May it be crawled at all. The robots.txt tester checks a real path against the rules, and the most common finding is a site blocking something it needs, such as the stylesheets a renderer has to fetch.
Is it in the list. The sitemap validator checks the file against the protocol. Two of the three fields crawlers read are ignored entirely, and a modification date that cannot be honest is worse than none.
Does anything link to it. The link graph draws how your pages point at each other, and it separates links a person wrote from links the menu adds. A page only the menu reaches is reachable and unrecommended, which is a different problem from being missing.
Does it still work. The broken link crawler follows what your pages link to. Read the counters in the order the guide gives, because the 404s are not the expensive ones and a page returning 200 can be the worst result of all.
A certificate warning, or a trust problem
The server check reports the protocol version, the expiry date and the issuer in the same result as everything else. The certificate guide explains what each part means and, more usefully, the four things a valid certificate does not prove.
Short lifetimes are deliberate now, so a date inside the next fortnight is the finding rather than a note. Renewal is the step that silently fails.
You do not know what something is
A MAC address lookup names the organization the hardware prefix was registered to. That identifies a device you are holding or looking at, which is a different job from diagnosing one, and it is the only check here that answers what something is rather than what is wrong with it.
Expect no vendor at all on a modern phone or laptop. They generate their own addresses now, and the honest answer is that nothing is registered.
You are about to change something
Two checks belong before a change rather than after one.
The IPv6 test tells you whether a hostname publishes an IPv6 address and whether anything can reach it. Publishing one nobody can reach is worse than publishing none, because clients that believe the record wait for a timeout before they fall back.
The traceroute tells you the path before you move a service, so you have something to compare against afterwards. A route that is fine now is the baseline you will want when it is not.
What none of these can tell you
Every check here runs from outside, so nothing inside the server is visible. Load, memory, disk, database health and application errors are all invisible from the network, and a fast, correct response is not evidence that the machine behind it is healthy.
A content delivery network hides the origin, so the address, the network and the country all describe an edge rather than your server. A blocking firewall looks exactly like an outage. And no check reads your logs, which is usually where the answer is.
What they do well is rule things out in a few seconds. Run the two or three that fit your symptom, and the ones that come back clean have told you something worth knowing.