NEW CASE
Antana

We create digital solutions that work for businesses


Give us a call +38 (066) 35-14-529

Let's take the first step towards your website — write to us

Close
August 20, 2026 7 min read

How to Check a Domain, Hosting and Server: 7 Steps in 10 Minutes

Hosting & tech
How to Check a Domain, Hosting and Server: 7 Steps in 10 Minutes

Before buying a domain, when moving to a new host, or when a site suddenly “stops opening” — every answer sits in a handful of technical checks. They take ten minutes and require neither server access nor paid services.

Below is the sequence we use ourselves to diagnose somebody else’s site when a client arrives with a problem. Every step can be completed with free tools, linked throughout the text.

Step 1. Find out the age and owner of the domain

The first thing worth knowing about a domain is when it was registered. That explains more than it seems: if the domain is three months old, the absence of Google rankings is not a fault but a normal stage. Google needs three to six months to begin trusting a new name.

Open the WHOIS check and look at three fields: creation date, expiry date and registrar. The expiry date matters separately — a lapsed domain is switched off without warning and the site disappears for everyone at once.

If you are buying a domain second-hand, WHOIS also reveals its history. A ten-year-old domain costs more for a reason, but make sure it never carried a penalty. Check by searching Google with the site: operator — if the index suddenly holds hundreds of unrelated pages of dubious content, walk away.

Step 2. See where the DNS records point

DNS is the system that turns a domain name into a server address. When a site does not open and the host swears everything works, the cause is usually here.

In the DNS record check, look at these types:

Record What it controls What to look for
A the server IPv4 address whether it matches your hosting IP
NS the zone name servers whether they belong to your host
MX mail servers whether old ones survived a migration
TXT SPF, DMARC, ownership verification whether SPF records are duplicated
CNAME an alias to another domain whether there is a chain of several CNAMEs

A classic migration scenario: the A record already points to the new server while MX records still belong to the old host — the site opens, but email keeps landing in a mailbox everyone forgot about.

Pay attention to the TTL beside each record. It is the number of seconds providers cache the answer. Before a planned migration TTL is lowered to 300, the move happens, and the normal value is restored — so changes propagate in minutes rather than a day.

Step 3. Find out which host the site runs on

The hosting check shows who owns the servers and in which country they physically sit. This is useful in three situations.

First, when vetting a contractor. If you were sold a “dedicated server” but the site actually sits on cheap shared hosting alongside a hundred others, it shows immediately.

Second, when analysing a competitor. A fast site is often fast not through magic but because it runs on decent hardware close to its audience.

Third, geography. If your customers are in Ukraine and the server is in Singapore, every request travels half the world. For a Ukrainian business, Ukraine or Europe is optimal: the latency difference between Kyiv and Frankfurt is small, between Kyiv and Asia it is critical.

Step 4. Measure the real response time

The word “slow” means nothing until you see numbers. The response time check breaks loading into stages, and each points to its own cause:

  • DNS — over 100 ms means slow name servers; moving to Cloudflare sometimes helps;
  • Connection — depends on distance to the server, and only relocation changes it;
  • TLS — the encryption handshake, rarely a problem;
  • TTFB — the key figure. Under 200 ms is excellent, under 400 is fine, over 800 means something needs investigating in the hosting or the site itself.

If TTFB is high while the other phases are normal, the network is not to blame — the server simply takes long to build the page. That is either a weak plan, heavy database queries or missing caching. Dig deeper with the speed audit: it additionally checks compression, caching and image formats.

Step 5. Check the redirect chain

After a migration or a URL restructure, a site often bounces visitors in circles: http to https, www to non-www, an old URL to a new one, and then to a trailing slash. Every hop adds delay, and for a search engine it also dilutes link equity.

The redirect checker shows the entire chain with status codes. The rule is simple: any URL should take no more than one hop to the final page. Three or four means the rules need rewriting. Doing it correctly is easier with the 301 redirect generator: it checks immediately whether your rules create an infinite loop.

The same tool unshortens links. If somebody sent you a bit.ly and you are unsure where it leads, paste it here and you will see the final domain without opening it and without leaving your IP there.

Step 6. See which ports are open

This is administration territory, but a site owner benefits from knowing it too. The port checker shows what is visible from outside.

The most dangerous finding is open database ports: 3306 for MySQL, 5432 for PostgreSQL, 6379 for Redis, 27017 for MongoDB. They should not face the internet at all — database access belongs on the server itself or through an SSH tunnel. Redis and MongoDB historically shipped without a password, so an open port means anyone can read the data.

Note the difference between states. “Closed” means the server actively refused — the port is reachable but nothing listens on it. “Filtered” means silence: the packet vanished, which is how a firewall behaves. If you have just configured a service and see “filtered”, look at the firewall rules rather than the application.

Step 7. Check the SSL certificate

The most mundane and most expensive outage: the certificate expired and browsers started showing visitors a red warning page. The site is technically alive, but nobody will enter it.

The SSL check shows the issuer and the days remaining. Set yourself a reminder two weeks before that date — even with Let’s Encrypt auto-renewal in place, it occasionally breaks after a server configuration change.

A ten-minute checklist

  1. WHOIS — domain age and expiry date.
  2. DNS — A points to the right server, MX did not survive from the old host.
  3. Hosting — country and provider match your audience.
  4. Response time — TTFB under 400 ms.
  5. Redirects — no more than one hop to the final URL.
  6. Ports — databases closed from outside.
  7. SSL — more than two weeks until expiry.

These seven steps catch the overwhelming majority of technical problems clients bring us. The full set of checks lives in our catalogue of 43 tools.

If something looks suspicious after the checks and working it out alone is hard, get in touch — we will look together.

Rate this article
It helps us write better content
Be the first to rate 5.0 of 5 0 votes

Recommended reading

Let’s create something amazing together

Become a clientBecome a client
Telegram Viber Call us