Technical website audit: TLS, redirects, headers, DNS and mail

A technical website audit checks the foundation: certificate, redirects, robots.txt and sitemap, security headers, caching, DNS, mail and exposed files.

Infrastructure · Published: 11 October 2026 · 6 min read · Анна Ковалёва

Design can be argued about and copy can be rewritten, but the technical layer either works or it does not. An expired certificate, a chain of four redirects, an .env file left in the web root or a missing DMARC record never show up in a mock-up or a sprint review — until the day the site stops opening, invoices land in spam and half the pages drop out of the index. A technical website audit is a check of exactly that foundation: everything that happens between the browser, the server and DNS before the first pixel is drawn.

How it differs from an SEO or UX audit

An SEO audit asks whether a search engine understands the page; a UX review asks whether a person can use it. A technical website audit asks whether either of them receives the right response at all: over HTTPS, with the right status code, without detours, with headers that shut down common attacks, from a domain that is not about to lapse. Most items are binary and can be checked from the outside without server access, which makes them easy to automate. The general method — scan, tickets, re-check — is covered in our guide to the website audit online; this article walks through the technical layer block by block.

1. HTTPS and the certificate

• Expiry. Alert at 30, 14 and 7 days. Auto-renewal fails more often than people think: DNS moved, port 80 closed, nginx never reloaded. The full story is in two dates that take the whole site down; what the report shows is explained under certificate expiry.
• Protocol versions. TLS 1.0 and 1.1 are withdrawn; the server should speak TLS 1.2 and 1.3.
• The full chain. Without the intermediate certificate desktop Chrome often copes, while Android, curl and payment webhooks fail.

From a terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -issuer

2. Addresses and redirects

A site should have exactly one canonical origin. http:// answers 301 to https:// (see HTTP to HTTPS redirect), and the www or bare variant answers 301 to the main one. Every extra hop is another round trip before the first byte, so count the redirects to the entry page: zero or one is fine, three is a ticket. Check the opposite case too: an address that does not exist must return 404, not 200 with "page not found" text.

curl -sI http://example.com/ | head -3
curl -s -o /dev/null -w "%{http_code}" https://example.com/no-such-page-123

3. robots.txt and sitemap.xml

These are technical files even though they decide SEO outcomes. The classic outage is a Disallow: / carried over from staging with a release. Make sure robots.txt does not block the home page, CSS or JavaScript and that it names the sitemap. The sitemap.xml itself should be valid XML, list only canonical URLs that answer 200, and contain no addresses from staging or another domain.

4. Security headers and leaks

The baseline is Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, frame protection and Referrer-Policy; why each matters and how to roll out CSP without breaking the site is in our piece on security headers. Equally important is what should not be on the server at all:

• files a deploy left behind — .env, .git/, database dumps; bots look for them within hours (exposed files);
• directory listings and published source maps;
• version banners such as Server: nginx/1.18.0 or X-Powered-By: PHP/7.4;
• a TRACE method the server echoes back.

5. Delivery: compression, caching, protocol

HTML and static files should go out compressed (gzip, ideally Brotli) over HTTP/2 or HTTP/3. Fingerprinted assets get Cache-Control: public, max-age=31536000, immutable; the HTML gets a short lifetime or no-cache plus an ETag so revisits cost a 304. A sensible server target is a first byte under 800 ms.

6. DNS, domain and mail

At least two nameservers, transfer lock on, domain auto-renew on. For mail: a single SPF record within the ten-lookup limit, DKIM, and DMARC starting at p=none with a reporting address before moving to quarantine. CAA, DNSSEC and MTA-STS are optional but worthwhile.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

Running a technical audit with SiteScan

1. Start a free scan from the home page: enter the domain and the report arrives in a minute or two.
2. Open the blocks "TLS certificate", "Domain registration", "Addresses & redirects", "Indexing", "Security headers" and "DNS & email". Every row has a "what is this?" button that leads to the help reference.
3. Click "Copy fix brief": the critical, high and medium findings go to the clipboard as a developer task list, with affected addresses and acceptance criteria.
4. After the fixes, scan again. "What changed since the last scan" lists what was fixed, what is new and what is still there.
5. Do not keep expiry dates in your head: "Watch this site" puts the domain on scheduled checks, with notices by email, Telegram or SMS.