Eine strukturierte Methode, um eine Website zu verstehen und Performance, SEO, Barrierefreiheit sowie defensive Sicherheit zu prüfen.

Webseitenanalyse: Methode, Tools und gute Praktiken

0

Eine strukturierte Methode, um eine Website zu verstehen und Performance, SEO, Barrierefreiheit sowie defensive Sicherheit zu prüfen.

Foto: Pixabay / Pexels
9 min read

Ziel und Rahmen

Eine Website zu analysieren bedeutet nicht nur, den Quellcode anzusehen. Moderne Websites verbinden HTML, CSS, JavaScript, Medien, API-Aufrufe, Cookies, lokalen Speicher, Drittanbieter-Skripte, Analytics und manchmal Authentifizierung.

Ziel kann sein, die Funktionsweise zu verstehen, die eigene Website zu auditieren, Performance zu verbessern, SEO zu prüfen, Barrierefreiheit zu analysieren oder defensive Sicherheitsprobleme zu erkennen.

Diese Anleitung bleibt legal und ethisch. Sie dient nicht dazu, Authentifizierung zu umgehen, Schwachstellen auszunutzen, eine Website massiv zu crawlen, private Daten abzurufen oder einen Dienst zu stören.

Scope definieren

Vor dem Start sollte der Rahmen dokumentiert werden:

Analysierte Website:
Ziel: Lernen / internes Audit / Performance / SEO / Barrierefreiheit / Sicherheit
Eigentümer:
Autorisierung: ja / nein
Betroffene Seiten:
Erlaubte Aktionen:
Verbotene Aktionen:
Testdaten:
Technischer Kontakt:

HTML/CSS/JS im eigenen Browser zu inspizieren, DevTools zu nutzen, Performance zu messen, Barrierefreiheit zu prüfen, HTTP-Header zu lesen oder robots.txt und sitemap.xml anzusehen ist meist unproblematisch. Authentifizierung umgehen, private Endpoints nutzen, intrusive Scans starten oder personenbezogene Daten sammeln braucht klare Erlaubnis.

Analysebereiche

Eine Webanalyse hat mehrere Blickwinkel:

  • Front-end: HTML, CSS, JavaScript, DOM, Komponenten, Frameworks;
  • Netzwerk: Requests, APIs, Drittanbieter-Skripte, CDN, HTTP-Codes, Ladezeiten;
  • Performance: Ressourcengröße, initiales Rendering, Cache, Core Web Vitals;
  • SEO: Title, Meta Description, Überschriften, URLs, interne Links, Sitemap;
  • Barrierefreiheit: Kontrast, Tastatur, Alternativtexte, Labels, ARIA;
  • defensive Sicherheit: Header, Cookies, CORS, CSP, sichtbare Fehler, Abhängigkeiten.

Ziel ist Verstehen, nicht das Erzwingen von Verhalten außerhalb normaler Nutzung.

Umgebung vorbereiten

Ein moderner Browser reicht bereits weit. Nützliche Tools:

  • Chrome DevTools oder Firefox DevTools;
  • Lighthouse, PageSpeed Insights und WebPageTest;
  • Wappalyzer oder BuiltWith;
  • curl, wget oder httpie;
  • axe DevTools für Barrierefreiheit;
  • Screaming Frog SEO Spider für SEO;
  • Playwright oder Puppeteer für die eigene Website;
  • mitmproxy oder Burp Suite nur in autorisierten Audits.

Nutze ein eigenes Browserprofil, deaktiviere unnötige Erweiterungen, teste mit leerem und warmem Cache, prüfe Mobile und Desktop und notiere Datum, Browser und getestete Seiten.

Erste Inspektion mit DevTools

Öffne DevTools mit F12 oder Rechtsklick und Untersuchen. Wichtige Tabs sind Elements, Console, Network, Sources, Application, Performance und Lighthouse.

Starte mit einem Reload bei geöffnetem Network-Tab und aktivem "Preserve log".

HTML, CSS und JavaScript

Für HTML prüfen:

[ ] Ein Haupt-h1
[ ] Logische Überschriftenreihenfolge
[ ] Semantische Tags
[ ] Relevante alt-Texte
[ ] Formularlabels
[ ] Verständliche Links
[ ] Kein wichtiger Inhalt nur als Bild

CSS zeigt visuelle Architektur: Framework, Utility-Klassen, Variablen, Media Queries, Animationen, Inline-Styles und Responsive Design. Gute Zeichen sind klare Variablen, wenige Inline-Styles, wiederverwendbare Komponenten, sauberes Responsive Design und visuelle Konsistenz.

JavaScript zeigt Stack, Front-end-Logik, API-Aufrufe und Drittanbieter. Hinweise:

React   → __REACT_DEVTOOLS_GLOBAL_HOOK__, React root
Vue     → __VUE__, data-v-xxxx
Angular → ng-version
Next.js → __NEXT_DATA__, /_next/static/
Nuxt    → __NUXT__, /_nuxt/

Source Maps können Dateinamen, Kommentare, interne Pfade oder Geschäftslogik offenlegen. Das ist nicht immer kritisch, sollte aber in Produktion geprüft werden.

Network und HTTP-Header

Network zeigt Requests, Reihenfolge, Dauer, Größe, Header, Antworten, Fehler und Weiterleitungen.

Ein einfacher Ablauf:

  1. DevTools öffnen.
  2. Network wählen.
  3. "Preserve log" aktivieren.
  4. Seite neu laden.
  5. Nach JS, CSS, Img, Fetch/XHR, Doc filtern.
  6. Schwere, langsame oder fehlerhafte Ressourcen finden.

Header lassen sich mit curl lesen:

curl -I https://example.com

Interessante Header:

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Cache-Control

Fehlende Header beweisen keine Schwachstelle, zeigen aber oft Verbesserungsmöglichkeiten.

Cookies und lokaler Speicher

In DevTools unter Application prüft man Cookies, Local Storage, Session Storage und IndexedDB.

Bei Cookies: Domain, Ablauf, Path, HttpOnly, Secure, SameSite und lesbare sensible Daten.

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax; Path=/

Sensible Tokens sollten nicht leichtfertig in localStorage liegen, weil das Risiko bei XSS steigt.

Formulare

Prüfe GET oder POST, Endpoint, Clientvalidierung, Fehlermeldungen, autocomplete, Labels, Anti-Spam, CSRF bei authentifizierten Aktionen und Fehlerverhalten.

Clientvalidierung verbessert UX; serverseitige Validierung ist für Sicherheit Pflicht.

Technisches SEO

Grundlagen:

<title>Klarer Seitentitel</title>
<meta name="description" content="Nützliche kurze Beschreibung.">
<link rel="canonical" href="https://example.com/page">

Prüfe Überschriftenhierarchie, URLs, interne Links, JSON-LD, robots.txt und sitemap.xml.

Wichtig: robots.txt ist keine Sicherheitsgrenze. Es gibt Crawlern Hinweise, aber gelistete URLs können öffentlich erreichbar bleiben.

Performance

Messen mit Lighthouse, PageSpeed Insights, WebPageTest, Performance und Network.

Wichtige Metriken:

LCP  → Largest Contentful Paint
INP  → Interaction to Next Paint
CLS  → Cumulative Layout Shift
TTFB → Time To First Byte
FCP  → First Contentful Paint

Häufige Ursachen: schwere Bilder, zu viel JavaScript, blockierendes CSS, fehlender Cache, schlecht geladene Fonts, zu viele Drittanbieter, langsamer Server und unnötige Weiterleitungen.

Optimierungen: Bilder komprimieren, WebP/AVIF nutzen, Lazy Loading, Minifizierung, ungenutzten Code entfernen, HTTP-Cache aktivieren und nicht kritische Skripte verzögern.

Barrierefreiheit

Schnelle Checks:

[ ] Nur mit Tastatur navigieren
[ ] Sichtbarer Fokus
[ ] Ausreichender Kontrast
[ ] Bilder mit alt
[ ] Formularlabels
[ ] Überschriftenstruktur
[ ] Screenreader-Test wenn möglich

Typische Probleme: Icon-Buttons ohne zugänglichen Namen, fehlende alt-Texte, schwacher Kontrast, nicht per Tastatur bedienbare Modale, unsichtbarer Fokus, "hier klicken"-Links und inkonsistente Überschriften.

Technologien und Drittanbieter

Hinweise:

WordPress → /wp-content/, /wp-json/
Shopify   → cdn.shopify.com
Next.js   → /_next/static/
Nuxt      → /_nuxt/
Webflow   → webflow.js
Wix       → static.wixstatic.com

Liste Drittanbieter-Skripte: Analytics, Tag Manager, Pixel, Chat, Payment, reCAPTCHA, Marketing-Widgets und JS-CDNs. Zu viele Drittanbieter können Performance, Cookie-Consent und Angriffsfläche verschlechtern.

Lighthouse und Automatisierung

Lighthouse bewertet Performance, Accessibility, Best Practices und SEO. Es ist ein Hilfsmittel, kein endgültiges Urteil.

Für die eigene Website kann Playwright Checks automatisieren:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
console.log(await page.title());
await browser.close();

Auf fremden Websites ohne Erlaubnis sollte keine massive Automatisierung erfolgen.

Fiktive Mini-Analyse

Für https://example-demo.local zeigt Network:

main.js        900 KB
hero.jpg       3.4 MB
style.css      180 KB
analytics.js   Drittanbieter

Wahrscheinliche Probleme: schweres Hero-Bild und großes JavaScript-Bundle.

HTML enthält zwei h1; Verbesserung: ein Haupt-h1, h2 für Abschnitte.

Gut konfigurierter Session-Cookie:

session_id
Secure: true
HttpOnly: true
SameSite: Lax

Schnelle Checkliste

[ ] Ziel und Scope definiert
[ ] Hauptseiten identifiziert
[ ] HTML inspiziert
[ ] CSS inspiziert
[ ] JavaScript inspiziert
[ ] Console-Fehler notiert
[ ] Network-Requests analysiert
[ ] HTTP-Header geprüft
[ ] Cookies geprüft
[ ] localStorage/sessionStorage inspiziert
[ ] robots.txt geprüft
[ ] sitemap.xml geprüft
[ ] Performance gemessen
[ ] Technisches SEO geprüft
[ ] Barrierefreiheit geprüft
[ ] Drittanbieter-Skripte gelistet
[ ] Bericht geschrieben

Berichtsvorlage

# Webanalysebericht

## Allgemeine Informationen
Website:
Datum:
Browser:
Analysierte Seiten:
Ziel:

## Zusammenfassung
Wichtigste Erkenntnisse.

## Technologien
CMS/Framework:
JS-Bibliotheken:
Hosting/CDN:
Analytics:

## Performance / SEO / Barrierefreiheit / Defensive Sicherheit
Feststellungen:
Impact:
Empfehlungen:

## Priorisierung
Kritisch:
Hoch:
Mittel:
Niedrig:

Was man vermeiden sollte

Ohne ausdrückliche Erlaubnis: aggressive Scans, Brute Force, Exploitation, Authentifizierungs-Bypass, massive Datenextraktion, destruktive Tests, Manipulation sensibler Parameter, Paywall-Bypass oder unerlaubte Nutzung geschützter Inhalte.

Verantwortungsvolle Analyse bedeutet verbessern, verstehen und dokumentieren, nicht einen Dienst missbrauchen.

Fazit

Die Methode ist einfach: Scope definieren, HTML/CSS/JS prüfen, Netzwerk beobachten, Header, Cookies und Speicher kontrollieren, Performance, SEO und Barrierefreiheit messen, Technologien identifizieren, Findings dokumentieren und konkrete Empfehlungen geben.

Mit Browser und DevTools lernt man bereits sehr viel. Die Grenze bleibt klar: beobachten und verstehen, ja; umgehen, ausnutzen oder stören, nein.