We create digital solutions that work for businesses
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.
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.
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.
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.
The word “slow” means nothing until you see numbers. The response time check breaks loading into stages, and each points to its own cause:
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.
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.
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.
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.
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.
Let’s create something amazing together Leave your number — we will call you back within 15 minutes during working hours.
We will call you back shortly.