Technisches Website-Audit: TLS, Redirects, Header, DNS

Ein technisches Website-Audit prüft das Fundament: Zertifikat, Redirects, robots.txt und Sitemap, Security-Header, Caching, DNS, E-Mail und offene Dateien.

Infrastruktur · Veröffentlicht: 11. Oktober 2026 · 5 Min. Lesezeit · Анна Ковалёва

Über Design lässt sich streiten, Texte lassen sich umschreiben – die technische Schicht dagegen funktioniert oder eben nicht. Ein abgelaufenes Zertifikat, vier Weiterleitungen am Stück oder eine im Webroot vergessene .env fallen in keinem Sprint-Review auf – bis die Seite nicht mehr lädt und Rechnungen im Spam landen. Ein technisches Website-Audit prüft genau dieses Fundament: alles, was zwischen Browser, Server und DNS passiert, bevor das erste Pixel erscheint.

Was es von SEO- und UX-Audits unterscheidet

Ein SEO-Audit fragt, ob eine Suchmaschine die Seite versteht; ein UX-Review, ob Menschen sie bedienen können. Das technische Website-Audit fragt, ob überhaupt die richtige Antwort ankommt: über HTTPS, mit dem passenden Statuscode, ohne Umwege, mit Headern gegen typische Angriffe und von einer Domain, die nicht nächste Woche ausläuft. Die meisten Punkte sind binär und von außen prüfbar, ohne Serverzugang. Die allgemeine Methode vom Scan über Tickets bis zur Nachprüfung beschreibt unser Beitrag zum Website-Audit online; hier geht es Block für Block um die technische Ebene.

1. HTTPS und Zertifikat

• Laufzeit. Warnungen bei 30, 14 und 7 Tagen. Die automatische Verlängerung scheitert öfter als gedacht: DNS umgezogen, Port 80 geschlossen, nginx nicht neu geladen. Die Details stehen im Artikel über Zertifikats- und Domainablauf, die Erklärung zur Berichtszeile unter Ablauf des TLS-Zertifikats.
• Protokollversionen. TLS 1.0 und 1.1 sind zurückgezogen; der Server sollte TLS 1.2 und 1.3 sprechen.
• Vollständige Kette. Ohne Zwischenzertifikat kommt Chrome auf dem Desktop oft noch zurecht, Android, curl und Zahlungs-Webhooks aber nicht.

Im Terminal:

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

2. Adressen und Weiterleitungen

Eine Website braucht genau eine Hauptadresse. http:// antwortet mit 301 auf https:// (siehe Weiterleitung auf HTTPS), die Variante mit oder ohne www mit 301 auf die Hauptvariante. Jeder zusätzliche Sprung kostet einen Roundtrip vor dem ersten Byte: null oder ein Redirect bis zur Einstiegsseite ist in Ordnung, drei sind ein Ticket. Prüfen Sie auch den umgekehrten Fall: Eine nicht existierende Adresse muss 404 liefern, nicht 200 mit dem Text „Seite nicht gefunden“.

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 und sitemap.xml

Der Klassiker unter den Ausfällen: ein Disallow: /, das mit einem Release vom Staging in die Produktion gewandert ist. Stellen Sie sicher, dass die robots.txt weder die Startseite noch CSS oder JavaScript sperrt und die Sitemap nennt. Die sitemap.xml selbst sollte valides XML sein, nur kanonische URLs mit Status 200 enthalten und keine Adressen vom Staging oder einer fremden Domain.

4. Security-Header und Lecks

Die Basis: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Schutz vor dem Einbetten in Frames und Referrer-Policy. Wozu jeder dient und wie CSP ohne Bruch eingeführt wird, steht im Beitrag zu Security-Headern. Genauso wichtig ist, was auf dem Server gar nicht liegen sollte:

• vom Deployment vergessene Dateien – .env, .git/, Datenbank-Dumps; Bots suchen binnen Stunden danach (offenliegende Dateien);
• Verzeichnislisten und veröffentlichte Source Maps;
• Versionsbanner wie Server: nginx/1.18.0 oder X-Powered-By: PHP/7.4;
• eine TRACE-Methode, die der Server zurückspiegelt.

5. Auslieferung: Kompression, Caching, Protokoll

HTML und statische Dateien sollten komprimiert (gzip, besser Brotli) über HTTP/2 oder HTTP/3 ausgeliefert werden. Dateien mit Hash im Namen bekommen Cache-Control: public, max-age=31536000, immutable, das HTML eine kurze Lebensdauer oder no-cache mit ETag, damit ein erneuter Besuch nur eine 304-Antwort kostet. Richtwert: erstes Byte unter 800 ms.

6. DNS, Domain und E-Mail

Mindestens zwei Nameserver, aktive Transfersperre, automatische Domainverlängerung. Für E-Mail: ein einziger SPF-Eintrag innerhalb des Limits von zehn DNS-Abfragen, DKIM und DMARC – zunächst p=none mit Berichtsadresse, später quarantine. CAA, DNSSEC und MTA-STS sind optional, aber lohnend.

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

Das technische Audit mit SiteScan

1. Starten Sie auf der Startseite einen kostenlosen Scan: Domain eingeben, nach ein bis zwei Minuten liegt der Bericht vor.
2. Öffnen Sie die Blöcke „TLS-Zertifikat“, „Domain-Registrierung“, „Adressen und Weiterleitungen“, „Indexierung“, „Security-Header“ und „DNS und E-Mail“. Jede Zeile hat eine Erklär-Schaltfläche, die ins Hilfe-Center führt.
3. Klicken Sie auf „Aufgabenliste kopieren“: Kritische, hohe und mittlere Befunde landen als Aufgabenliste für die Entwicklung in der Zwischenablage – mit betroffenen Adressen und Abnahmekriterium.
4. Scannen Sie nach den Korrekturen erneut. „Was sich seit dem letzten Scan geändert hat“ zeigt, was behoben, was neu und was geblieben ist.
5. Fristen gehören nicht ins Gedächtnis: „Diese Website überwachen“ setzt die Domain auf regelmäßige Prüfungen, Benachrichtigungen kommen per E-Mail, Telegram oder SMS.