// Full report

What is actually wrong with your site?

One scan across six areas: DNS, email authentication, your certificate, redirects, robots.txt and your sitemap. Every finding shows the record or response behind it. No signup, no email required.

// What gets checked

Every test, explained

Six areas, one pass. Each one is the same check the single-purpose tool runs, so nothing is shortened for the combined view.

DNS and delegation

Where your domain points, and whether the pointing is sound. This reads your nameservers, the SOA timers, the apex and www addresses, IPv6 consistency, CAA records and the TTLs. A single nameserver is the one that bites hardest. When it goes down nothing resolves, and no amount of working web server helps you.

Email authentication

Whether somebody can send mail as you. SPF, DKIM and DMARC are read together, because they only mean anything together — a soft-fail SPF is correct under an enforcing DMARC policy and close to useless without one. Your MX records are checked at the same time, since mail that is not routed cannot be authenticated either.

Certificate and TLS

The certificate your server actually presents, not the one your control panel thinks it has. Validity window, whether it covers the name visitors type, the chain and its intermediates, the signature and key strength, and which TLS versions are still accepted. The most common finding here is a certificate that covers example.com but not www.example.com, or the reverse.

Redirects

What happens between the address someone types and the page they land on. Hop count, loops, chains that end on a 404 or a server error, deep links quietly sent to the homepage, temporary status codes used for permanent moves, and whether HTTPS is enforced at all. Deep links landing on the homepage is the classic migration defect, and it is invisible from the front page.

robots.txt

The file that tells crawlers where they may go. This checks that it is served as text rather than as an HTML error page, that its rules parse, and that it is not blocking the site or the CSS and JavaScript a page needs in order to render. A 5xx on this file is worse than a missing one: crawlers read a server error as “assume everything is forbidden” and stop.

XML sitemap

Whether the list of pages you hand search engines is one they can use. The file is found the way a crawler finds it, then checked for valid XML, the right root element and namespace, and entries that are relative, cross-domain or on the wrong scheme. A sample of the URLs inside is opened to see whether they still load.

// Common problems

What usually goes wrong, and how it gets fixed

These are the ones you only see when you look at all six areas together. Each single-purpose tool covers its own ground in more detail.

Everything broke at once after a migration

This is the usual reason somebody runs a combined check. The site moved, and the report comes back red in four places at the same time. It looks like four problems. It is normally one, with three consequences.

The order matters, because fixing them out of order wastes a day. DNS first, because every other check is reading the wrong server until it is right. The certificate next, since it cannot be issued or validated until the name resolves to the host that will hold it. Then redirects, then the sitemap, which is just a list of addresses and is worth nothing until the addresses work.

# 1. Where does it actually resolve, and with what time to live
dig +noall +answer example.com A www.example.com A

# 2. Which certificate is that host presenting, and for which names
openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

# 3. Where does a deep link end up
curl -sIL https://example.com/a-real-old-url/ | grep -iE "^(HTTP|location)"

Work down that list and re-run this check after each step. Findings below the one you just fixed often disappear on their own, because they were describing the same cause from a different angle.

The certificate is valid but visitors still get a warning

A certificate covers the exact names written into it. If it lists example.com and a visitor types www.example.com, the browser stops them, and the certificate is not faulty in any way you can see from your control panel.

It shows up on a combined report as a healthy certificate finding sitting next to a DNS finding about the two names, which is why it is easy to miss when you check them separately.

# Ask each name for itself. Compare the SAN list in both answers.
for h in example.com www.example.com; do
  echo "== $h"
  openssl s_client -connect "$h:443" -servername "$h" </dev/null 2>/dev/null \
    | openssl x509 -noout -ext subjectAltName
done

Reissue the certificate covering both names. Then pick one as canonical and redirect the other to it, so you are not maintaining two versions of the same site for the rest of its life.

You changed a DNS record and nothing happened

Almost always the TTL. A record published with a 24-hour TTL is cached by resolvers for up to 24 hours, so the change is real and the internet has not noticed yet. Checking from your own machine tells you very little, because your resolver may have cached the old answer minutes before you made the change.

The fix is to plan for it rather than to wait it out. Lower the TTL well before you need to move anything, then raise it again once the move has settled.

# The number in the second column is the remaining TTL in seconds
dig +noall +answer example.com A

# Ask an authoritative server directly and skip every cache in between
dig +norecurse @$(dig +short NS example.com | head -1) example.com A

Drop the TTL to 300 a day or two ahead of a planned move. Put it back to something sensible afterwards — a permanently short TTL means every visitor pays for a lookup that could have been cached.

Email stopped arriving after the website moved

Web hosting and mail hosting are separate things that happen to share a domain name. Move the site and it is easy to take the whole zone with it, including the MX records that were pointing at a mail provider you did not change.

The other half of it is SPF. If your SPF record authorises the old host’s addresses, mail sent from the new one fails authentication even though it is genuinely yours.

# Who is meant to receive your mail
dig +short MX example.com

# And who is authorised to send as you
dig +short TXT example.com | grep -i spf

Point the MX records back at whoever actually runs your mailboxes, then update SPF to authorise the servers that send for you now. Change one and not the other and you get the confusing version, where mail arrives but lands in spam.

Found something broken?

Send me the result. I'll tell you what it takes to fix it, and whether it's worth paying anyone to do — including me.

Send me a message ↓

Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.

// FAQ

Questions

Why does this take longer than your other tools?

Because it runs all six of them. A single-purpose check has twenty seconds; this one has forty-five, split across the six areas so that a slow sitemap cannot eat the time the certificate check needs. Most sites finish well inside that. The ones that take the full budget are usually the ones with something wrong.

Is anything held back until I give you my email address?

No. There is no email wall, no signup and no hidden verdict. Every check that ran is on the results page with the evidence behind it, including the ones that passed, and there is no longer version of that page. What I do not publish is the remediation written for your specific setup — the order to fix things in and the actual configuration — because that is consulting work rather than something a scanner can generate. You can act on everything the report tells you without contacting me at all.

One of the checks said it did not finish. What does that mean?

Exactly what it says. That area ran out of its share of the time, usually because the server was slow to answer, so what it reports may be incomplete. It is not a teaser and there is no paid version of that check. Re-running often completes it, and the single-purpose tool for that area has the whole budget to itself, so it always will.

Is this the same as running your six separate tools?

The same code, and the same findings. This page calls the same six check modules and merges what they return, so nothing is watered down for the combined view. What you get on top is the whole picture at once, which matters because these areas depend on each other — a certificate problem is often a DNS problem, and a sitemap full of redirects is usually a migration that was never finished.

It says it checked a different domain to the one I typed.

Nameservers, the SOA record, CAA and everything about email belong to a zone rather than to a name inside it. So if you enter blog.example.com, those checks report on example.com, because that is where the records live. The page says which zone it read rather than quietly substituting one. Your certificate, redirects and robots.txt are still checked on the exact host you entered.

Do you store the addresses I check?

Not beyond a cache. Results are cached for thirty minutes, so a shared link does not re-run the whole scan for every reader, and after that the entry expires. There is no account, no email field and no signup. Being straight about the rest: the address you check is part of the result page URL, so like any page address it appears in this server’s access log and in Google Analytics. It is not published anywhere and it is never used to contact you. Scanning is limited to ten checks an hour per visitor and three an hour per domain, which is what stops the tool being pointed at somebody else’s site over and over.

Can I check several domains at once?

Not from this page — it takes one address at a time, and the rate limits are there so that it cannot be used to work through a list of sites belonging to other people. If you need the same report across a portfolio of domains, or on a schedule, that is something I set up as a piece of work rather than as a form.

Is it safe to run this against a site I do not own?

It is passive. It reads public DNS and requests a handful of pages on ports 80 and 443, the same way any visitor or crawler would. Nothing is scanned, enumerated or brute forced, no form is ever submitted, and no attempt is made to log in or to find anything that is not linked. That said, the per-domain limit exists for a reason, and pointing it repeatedly at somebody else’s infrastructure is not what it is for.