Domain & SEO Analyse - sofort & gratis.

Ja. Let's Encrypt ist eine gemeinnützige CA, die kostenlose DV-Zertifikate ausstellt - genutzt von über 300 Millionen Domains. Die meisten Webhoster bieten Let's Encrypt mit Ein-Klick-Installation an.

Seit September 2020 maximal 398 Tage. Let's Encrypt-Zertifikate laufen 90 Tage und sind für automatische Erneuerung ausgelegt. Apple hat angekündigt, ab 2027 nur noch 47-Tage-Zertifikate zu akzeptieren.

SSL/TLS ist das Verschlüsselungsprotokoll. HTTPS ist HTTP über eine SSL/TLS-Verbindung. Das Schloss bedeutet: Verbindung verschlüsselt, Zertifikat gültig. HTTPS ist seit 2014 ein offizieller Google-Rankingfaktor.

SANs erlauben ein einzelnes Zertifikat für mehrere Domains. Ein Zertifikat für example.com kann gleichzeitig www.example.com, mail.example.com und andere Domains absichern.

SSL/TLS schützt die Übertragung vor Abhören und Man-in-the-Middle-Angriffen. Es sagt nichts über die Sicherheit der Website selbst aus - eine gehackte Site kann ein gültiges SSL-Zertifikat haben.

HTTP Strict Transport Security weist den Browser an, eine Domain immer nur über HTTPS aufzurufen. Das verhindert SSL-Stripping-Angriffe. Unser HSTS-Checker prüft die korrekte Konfiguration.

Das liegt an der TTL (Time to Live). Steht die TTL auf 86400 (24 Stunden), dauert es bis zu 24 Stunden bis alle DNS-Server die neue Adresse kennen. Tipp: TTL vor einer Migration auf 300 Sekunden senken - dann propagiert die Änderung in Minuten.

DNS ist das System als Ganzes. Ein Nameserver ist ein konkreter Server der DNS-Einträge verwaltet. Jede Domain hat mindestens zwei Nameserver für Redundanz.

Der Zeitraum in dem eine DNS-Änderung sich weltweit verbreitet. Da Resolver cachen, sehen verschiedene Nutzer zeitweise unterschiedliche DNS-Informationen.

DNS Security Extensions signiert DNS-Antworten digital und verhindert DNS-Spoofing. Angreifer können keine gefälschten DNS-Antworten einschleusen.

Cloudflare (1.1.1.1) und Google (8.8.8.8) sind die bekanntesten öffentlichen DNS-Resolver. Der tatsächlich schnellste hängt von deinem Standort ab.

Diese Header verraten Angreifern welche Software und Version eingesetzt wird. Kennt ein Angreifer z.B. "Apache 2.4.49" kann er gezielt nach bekannten Schwachstellen suchen. Mit Header always unset Server in der .htaccess entfernst du diese Informationen.

Direkt kaum. Aber Caching verbessert die Ladezeit - ein Google-Rankingfaktor. Statische Assets wie CSS und JS sollten lang gecacht werden (max-age=31536000), HTML-Seiten eher kurz (no-cache) damit Änderungen sofort sichtbar sind.

Ein ETag ist ein Fingerabdruck einer Ressource. Ändert sich die Datei, ändert sich der ETag. Browser speichern den ETag und fragen beim nächsten Aufruf nur neu wenn sich der ETag geändert hat - spart Bandbreite und beschleunigt Seitenaufrufe.

GET überträgt Daten in der URL - sichtbar, cachebar, für Suchanfragen geeignet. POST überträgt Daten im Request-Body - unsichtbar, nicht cachebar, für Formulare und Login. Sensible Daten wie Passwörter gehören immer in einen POST-Request, niemals in die URL.

Gzip komprimiert Textdateien (HTML, CSS, JS) um 60-80%. Der Server komprimiert, der Browser entpackt automatisch. Brotli ist eine modernere Alternative mit ca. 15% besserer Komprimierung. Aktivieren in Apache mit mod_deflate, in Nginx mit gzip on;.

Ja. Seit 2024 verlangen Google und Yahoo DMARC von allen die mehr als 5.000 E-Mails/Tag versenden. Ohne DMARC können Betrüger E-Mails mit deiner Domain als Absender versenden. Mit p=reject ist das praktisch unmöglich. Außerdem verbessert DMARC die Zustellbarkeit legitimer E-Mails.

Aggregate Reports (RUA) sind XML-Dateien die Mailserver täglich senden. Sie zeigen welche IPs E-Mails in deinem Namen versenden und ob SPF/DKIM bestanden wurde. Tools wie dmarcian oder Google Postmaster Tools helfen beim Auswerten der oft unlesbar komplexen XML-Dateien.

Erst SPF (autorisierte Mailserver), dann DKIM (kryptografische Signatur), dann DMARC mit p=none starten und Berichte auswerten. Nach einigen Wochen auf p=quarantine erhöhen, dann p=reject. Dieser schrittweise Ansatz verhindert dass legitime E-Mails geblockt werden.

RUA (Aggregate Reports) sind tägliche Zusammenfassungen aller E-Mails in deinem Namen. RUF (Forensic Reports) sind Einzelberichte bei jedem Fehler inklusive Nachrichtenheader. RUF sind aus Datenschutzgründen bei vielen Providern deaktiviert. RUA reicht für das meiste Monitoring.

Nein - DMARC schützt nur deine exakte Domain. Betrüger nutzen Lookalike-Domains wie "paypa1.com". Dagegen helfen nur präventive Domain-Registrierung ähnlicher Varianten oder Brand-Monitor-Dienste die bei neuen ähnlichen Registrierungen warnen.

Das SPF-Protokoll begrenzt Abfragen auf 10 um Mailserver vor DoS-Angriffen zu schützen. Jedes include: und a: zählt als Lookup. Mit Google, Sendgrid und Mailchimp gleichzeitig ist das Limit schnell erreicht. Lösung: SPF-Flattening-Dienste die alle IPs in einen einzigen Eintrag konsolidieren.

Spammer können E-Mails mit deiner Domain als Absender versenden. Viele Mailprovider behandeln E-Mails von Domains ohne SPF als verdächtig. Seit 2024 ist SPF Voraussetzung für gute Zustellbarkeit bei Google und Yahoo.

Nein - pro Domain ist nur ein SPF-TXT-Eintrag erlaubt. Mehrere SPF-Einträge führen zu einem PermError und die Prüfung schlägt fehl. Alle includes müssen in einen einzigen Eintrag.

Nein - das ist eine bekannte Schwäche. Bei Weiterleitungen ändert sich die sendende IP aber nicht der From-Header. Die neue IP ist nicht im SPF eingetragen und die Prüfung schlägt fehl. Deshalb ist DKIM so wichtig: DKIM-Signaturen überleben Weiterleitungen.

Permerror (Permanent Error): Der Eintrag ist fehlerhaft - mehr als 10 Lookups, Syntaxfehler oder mehrere SPF-Einträge. Muss manuell behoben werden. Temperror: Temporäres DNS-Problem, meist selbst lösend. Permerror führt oft zu Spam-Einstufung.

Alignment bedeutet die Domain im From-Header stimmt mit der Domain überein die SPF oder DKIM authentifiziert hat. Strict: exakte Übereinstimmung. Relaxed: Subdomains erlaubt. Relaxed Alignment ist für die meisten Setups ausreichend und der Standard.

Täglich - Google, Microsoft und Yahoo senden Aggregate Reports (RUA) einmal täglich. Forensische Reports (RUF) werden bei jedem Fehler einzeln gesendet, sind aber aus Datenschutzgründen bei vielen Providern inzwischen deaktiviert.

Das kann legitim sein (Drittanbieter-Dienst der E-Mails in deinem Namen sendet aber nicht in SPF eingetragen ist) oder ein Angriff. Zunächst prüfen ob die IP zu einem bekannten Dienst gehört (z.B. CRM, Newsletter-Tool). Falls nicht: Incident-Response einleiten.

Zuerst prüfen ob die IP zu einem bekannten Dienst gehört der E-Mails in deinem Namen sendet aber nicht in SPF eingetragen ist. Falls unbekannt: Incident-Response einleiten, Passwörter ändern, Server auf Kompromittierung prüfen. DMARC-Berichte sind ein frühes Warnsystem für Account-Übernahmen.

Maximal 4-8 Wochen - lang genug um alle legitimen E-Mail-Quellen zu sehen und in SPF/DKIM einzutragen. Danach p=quarantine für 2-4 Wochen, dann p=reject. Viele Domains bleiben jahrelang auf p=none - das bietet keinen echten Schutz.

Das hängt vom Registrar und Wohnsitz des Inhabers ab. Bei europäischen Domains sind Daten seit der DSGVO meist anonymisiert. Bei US-Domains oder ohne Privacy-Schutz sind Name und Organisation oft noch sichtbar.

Dieser Domain-Status verhindert ungewollte Transfers zu anderen Registraren. Um eine Domain zu transferieren, muss dieser Status zunächst beim aktuellen Registrar aufgehoben werden.

Nach dem Ablauf gibt es eine Grace Period (~45 Tage zur Verlängerung), dann Redemption Period (~30 Tage mit Strafgebühren), dann wird die Domain freigegeben und kann von jedem neu registriert werden.

RDAP liefert strukturierte JSON-Antworten statt Freitext, nutzt HTTPS-Verschlüsselung und bietet standardisierte Felder. Unser Tool nutzt RDAP wo verfügbar und fällt auf WHOIS zurück.

Eine WHOIS-Abfrage zeigt ob eine Domain registriert ist. Gibt es keinen Eintrag, ist sie wahrscheinlich verfügbar. Für die tatsächliche Registrierung benötigst du einen Domain-Registrar.

Nur ungefähr. Geolocation-Datenbanken können Land und Stadt bestimmen - oft stimmt das auf Stadtebene, manchmal nur auf Länderebene. Den exakten Haushalt kann man nicht bestimmen. VPNs und Proxy-Dienste können die IP-Geolocation komplett verschleiern.

Ein PTR-Record löst eine IP-Adresse zurück in einen Hostnamen auf. Für Mailserver ist ein korrekter PTR-Record wichtig - viele Mailprovider lehnen E-Mails von IPs ohne PTR ab oder stufen sie als Spam ein.

Wenn du einen eigenen Mailserver betreibst (PTR-Record nötig), einen VPN-Server hostest oder DNS-Einträge auf deine IP zeigen sollen. Für normale Websites reicht eine dynamische IP mit DDNS-Dienst.

Carrier-Grade NAT (CGNAT) bedeutet dein Anbieter gibt dir keine eigene öffentliche IP sondern teilt eine mit vielen Kunden. Das macht eingehende Verbindungen (Homeserver, VPN) unmöglich und führt zu Problemen bei IP-basierten Diensten. Abhilfe: Beim Anbieter eine dedizierte öffentliche IPv4 hinzubuchen.

IPv4 (32 Bit, ~4 Mrd. Adressen) ist seit Jahrzehnten der Standard aber knapp. IPv6 (128 Bit, 340 Sextillionen Adressen) löst die Knappheit und bringt integriertes IPsec sowie einfacheres Routing. Beide Protokolle laufen heute parallel (Dual Stack). IPv6 ist für Webserver empfohlen da moderne ISPs und Mobilnetze es bevorzugen.

Maximal 3–4 Hops sind akzeptabel. Google folgt bis zu 10 Weiterleitungen, danach gibt es auf. Jeder Hop kostet 50–200ms extra Ladezeit und verwässert den PageRank-Transfer. Direkte 301-Weiterleitungen ohne Zwischenstops sind ideal.

Seite A leitet auf B weiter und B zurück auf A - der Browser bricht mit "Too many redirects" ab. Häufige Ursachen: Fehler in .htaccess-Regeln, CMS-Einstellungen die mit Server-Redirects kollidieren, oder HTTP-zu-HTTPS-Regeln die sich gegenseitig auslösen.

Seit 2016 sagt Google offiziell dass 301-Weiterleitungen keinen PageRank verlieren. In der Praxis gibt es minimal Verlust bei langen Redirect-Ketten. Direkte Verlinkung auf die finale URL ist immer besser.

Eine kanonische URL ist die bevorzugte Version einer Seite. Canonical-Tags sagen Google welche URL indexiert werden soll ohne einen Redirect zu erzwingen - nützlich wenn technische Gründe mehrere URLs für denselben Inhalt erfordern (z.B. URL-Parameter). Für echte Duplikate ist ein 301-Redirect die stärkere Maßnahme.

Unser Redirect-Checker verfolgt die komplette Redirect-Kette und zeigt jeden Hop mit Statuscode und Ladezeit. Alternativ: curl -I -L in der Kommandozeile oder Browser DevTools (Network-Tab, preserve log aktivieren). Wichtig: auch von HTTP und www-Variante aus testen.

Alle die du nicht aktiv benötigst. Besonders kritisch offen: 3306 (MySQL), 5432 (PostgreSQL), 27017 (MongoDB) - Datenbanken gehören nie direkt ins Internet. Auch RDP (3389) ist ein häufiges Brute-Force-Ziel. Eine Firewall sollte nur notwendige Ports öffnen.

Das Scannen eigener Server ist völlig legal. Das Scannen fremder Server ohne Erlaubnis ist in Deutschland nach §202a StGB (Ausspähen von Daten) strafbar und kann als Angriffsvorbereitung gewertet werden. Unser Tool ist ausschließlich für die Analyse eigener Systeme gedacht.

Ein gefilterter Port antwortet weder mit offen noch geschlossen - eine Firewall blockiert Anfragen still. Das ist sicherer als ein offener Port und auch besser als ein geschlossener (der noch eine RST-Antwort sendet und damit seine Existenz verrät).

TCP stellt sicher dass alle Pakete ankommen und in richtiger Reihenfolge - gut für HTTP, SSH, Dateiübertragung. UDP ist schneller ohne Zustellgarantie - gut für DNS, Video-Streaming und Gaming wo Geschwindigkeit wichtiger ist als vollständige Übertragung.

Port 22 wird permanent von Bots nach Standard-Zugangsdaten abgesucht. Schutz: SSH-Port ändern (reduziert automatisches Scanning), Passwort-Login deaktivieren und nur SSH-Keys erlauben, fail2ban installieren das IPs nach Fehlversuchen blockiert.

Nur eingeschränkt via SMTP-Check. Viele Server antworten aus Datenschutzgründen immer mit "akzeptiert" ohne die Adresse zu prüfen (Catch-All). Der zuverlässigste Test ist eine echte E-Mail zu senden und auf Bounce zu warten.

Wegwerf-Adressen werden für Fake-Registrierungen, Bonus-Missbrauch und Spam genutzt. Für seriöse Dienste ist das Blockieren bei der Registrierung sinnvoll. Unser Validator erkennt über 1.000 bekannte Wegwerf-Domains.

Role-Accounts wie info@, admin@ oder noreply@ gehören keiner einzelnen Person sondern einer Funktion. Sie sind kein Indikator für eine invalide Adresse, aber für Marketing-E-Mails ungeeignet - sie haben oft hohe Spam-Raten da mehrere Personen darauf zugreifen.

RFC 5321 definiert das SMTP-Protokoll, RFC 5322 das E-Mail-Format. Der lokale Teil (vor dem @) darf Buchstaben, Zahlen und Sonderzeichen wie +, -, _ und . enthalten. Technisch sind auch "test test"@example.com (mit Leerzeichen in Anführungszeichen) valide - aber praktisch akzeptieren die wenigsten Systeme solche Adressen.

Laut E-Mail-Marketing-Studien sind nach 12 Monaten ca. 22% einer E-Mail-Liste ungültig geworden - durch Job-Wechsel, Domain-Aufgabe oder manuelle Abmeldung. Regelmäßiges Validieren und Bereinigen der Liste ist entscheidend für gute Zustellbarkeit und Absender-Reputation.

Jede Blacklist hat einen eigenen Delisting-Prozess. Problem zuerst beheben (Spam stoppen, Malware entfernen), dann Antrag stellen. Bei Spamhaus 1-7 Tage, bei manchen Listen automatisch nach 24-48 Stunden ohne neue Vorfälle.

Spamhaus (SBL, XBL, PBL) ist die einflussreichste - fast alle großen Mailprovider nutzen sie. Weitere: Barracuda, SURBL, SpamCop und UCEPROTECT. Unser Tool prüft gleichzeitig gegen über 12 der wichtigsten RBL-Listen.

E-Mail-Blacklists beeinflussen das Web-Ranking nicht direkt. Aber wenn Google deine Domain als Malware-Quelle einstuft (Google Safe Browsing) zeigt Chrome eine rote Warnseite und dein Ranking bricht ein. Das ist ein anderes System aber ebenso dringend zu beheben.

Das variiert: Spamhaus-Einträge bleiben bis zur manuellen Bereinigung. Automatische Listen wie UCEPROTECT entfernen Einträge nach 7 Tagen ohne neue Vorfälle automatisch. Manche Listen bieten bezahltes Delisting an für schnellere Entfernung.

Ja - bei Shared Hosting teilen sich viele Kunden eine IP. Versendet ein anderer Kunde Spam landet die geteilte IP auf der Blacklist. Lösung: Dedizierte IP oder einen externen E-Mail-Dienst (Mailgun, Postmark, Brevo) nutzen.

crt.sh ist eine kostenlose Suchmaschine für CT-Logs betrieben von Sectigo (früher Comodo). Sie aggregiert Zertifikatsdaten aus allen öffentlichen CT-Logs und ermöglicht die Suche nach Domain-Namen, Aussteller und Zertifikat-Fingerprints.

CAA-Records (Certification Authority Authorization) im DNS legen fest welche CAs Zertifikate für deine Domain ausstellen dürfen. Ein Eintrag wie example.com CAA 0 issue "letsencrypt.org" erlaubt nur Let's Encrypt. Alle anderen CAs müssen ablehnen.

Zunächst prüfen ob eine autorisierte Person das Zertifikat angefordert hat. Falls nicht: sofort bei der ausstellenden CA ein Incident melden (jede CA hat eine Pflicht zur Revokation bei Missbrauch). Zusätzlich CAA-Records setzen um zukünftige unautorisierten Ausstellungen zu verhindern.

CT-Logs sind append-only - einmal eingetragene Zertifikate können nicht gelöscht werden. Das ist Absicht: die Unveränderlichkeit des Logs macht Manipulation erkennbar. Auch abgelaufene Zertifikate bleiben dauerhaft sichtbar, was forensische Analysen ermöglicht.

Wildcard-Zertifikate (*.example.com) decken alle Subdomains ab. Im CT-Log erscheinen sie als *.example.com. Sie sind praktisch aber aus Sicherheitssicht riskant: Ein kompromittierter privater Schlüssel gibt Zugriff auf alle Subdomains gleichzeitig. Für kritische Subdomains sind separate Zertifikate sicherer.

Ja, unbedingt. Bitwarden (Open Source, kostenlos), 1Password oder KeePass generieren und speichern starke einzigartige Passwörter für jeden Account. Du merkst dir nur noch ein Master-Passwort. Das ist die effektivste Maßnahme gegen Account-Übernahmen.

Credential Stuffing: Bei einem Datenleck werden gestohlene E-Mail/Passwort-Kombinationen automatisch bei Hunderten anderer Dienste ausprobiert. Nutzt du überall dasselbe Passwort reicht ein einziges Leck um alle deine Accounts zu kompromittieren. haveibeenpwned.com zeigt ob deine E-Mail in bekannten Leaks auftaucht.

Eine Passphrase besteht aus mehreren zufälligen Wörtern (z.B. "Koffer-Elefant-Nebel-Turm"). Länger als typische Passwörter, aber leichter zu merken. Für Master-Passwörter von Passwort-Managern oder Geräteverschlüsselung sind Passphrases oft die bessere Wahl.

Sonderzeichen erhöhen den Zeichensatz - aber Länge ist wichtiger. Ein 16-stelliges Passwort aus Buchstaben ist sicherer als ein 8-stelliges mit Sonderzeichen. Viele Websites haben restriktive Regeln (kein &, kein ") die Sonderzeichen problematisch machen. Länge schlägt Komplexität.

Laut Analysen geleakter Datenbanken dominieren: "123456", "password", "qwerty", Geburtsdaten und Wörter aus dem Wörterbuch. Wörterbuchangriffe testen Millionen bekannter Passwörter in Sekunden. Jedes Passwort das ein Mensch sich merken kann ist potenziell schwach.

Kaum. HTTP/2 ist ein Protokoll-Upgrade - dein Code bleibt gleich. Du brauchst HTTPS (HTTP/2 läuft praktisch nur verschlüsselt) und einen Server der HTTP/2 unterstützt. Nginx ab 1.9.5 und Apache ab 2.4.17 mit mod_http2 unterstützen es nativ.

Besonders auf mobilen Verbindungen und bei Paketverlusten ist HTTP/3 deutlich schneller. Google-Studien zeigen 20-30% schnellere Ladezeiten unter schlechten Netzwerkbedingungen. Auf stabilen Leitungen ist der Unterschied zu HTTP/2 gering.

Unser HTTP/2-Checker prüft das direkt. Alternativ: Chrome DevTools → Network → Protokoll-Spalte zeigt h2 (HTTP/2) oder h3 (HTTP/3). Im Firefox-Netzwerkmonitor steht das Protokoll ebenfalls in der Übersicht.

Technisch ja, aber Chrome hat Server Push 2022 faktisch eingestellt. Moderner Ersatz: der 103 Early Hints-Statuscode der dem Browser erlaubt Ressourcen vorzuladen während der Server noch die Hauptantwort aufbaut.

Technisch erlaubt der Standard HTTP/2 ohne Verschlüsselung (h2c). In der Praxis unterstützt aber kein moderner Browser unverschlüsseltes HTTP/2. HTTPS ist daher effektiv Pflichtvoraussetzung.

Eine in Chrome, Firefox, Safari und Edge eingebaute Liste von Domains die immer über HTTPS aufgerufen werden - auch beim ersten Besuch. Eintragen unter hstspreload.org. Voraussetzung: max-age mindestens 1 Jahr, includeSubDomains und preload gesetzt, alle Subdomains HTTPS-fähig.

Ja, wenn includeSubDomains gesetzt ist aber eine Subdomain kein gültiges SSL-Zertifikat hat. Browser verweigern die Verbindung komplett ohne Möglichkeit die Warnung wegzuklicken. Deshalb: Vorsichtig testen, mit kurzem max-age beginnen.

In Chrome: chrome://net-internals/#hsts - dort HSTS-Einträge für einzelne Domains löschen. In Firefox: Verlauf löschen inklusive aktive Logins. Wichtig beim Testen oder wenn du von HTTPS zurück zu HTTP wechseln musst.

Ein 301-Redirect ist serverseitig - der Browser sendet zuerst eine HTTP-Anfrage und bekommt die Weiterleitung. HSTS verhindert diese erste HTTP-Anfrage komplett: Der Browser weiß aus seinem Cache dass er direkt HTTPS nehmen muss. Das schließt das Angriffsfenster der ersten unverschlüsselten Anfrage.

Google empfiehlt mindestens 1 Jahr (31536000 Sekunden). Für die HSTS Preload List ist das Minimum. Beim ersten Rollout empfiehlt sich ein kurzer Wert (300 Sekunden) zum Testen - danach schrittweise erhöhen. Ein zu langer Wert ist bei Problemen schwer rückgängig zu machen.

Die größte Schutzwirkung hat die Content-Security-Policy, gefolgt von HSTS. X-Frame-Options und X-Content-Type-Options sind schnell gesetzt und bieten sofortigen Schutz.

Direkt nicht. Indirekt schützt HSTS das HTTPS-Ranking und eine gute CSP verhindert eingeschleuste Spam-Links die dein Ranking schädigen könnten.

Ja. Eine zu restriktive CSP kann externe Fonts, Analytics oder Videos blockieren. Empfehlung: Mit Content-Security-Policy-Report-Only testen bevor der echte Header gesetzt wird.

A+ bedeutet alle empfohlenen Header sind gesetzt und korrekt konfiguriert. Die meisten Websites liegen bei C oder D - schon wenige Änderungen reichen für B oder A.

In den meisten Fällen ja. Bei Cloudflare, Netlify und Vercel gibt es Templates. Bei klassischem Hosting per .htaccess oder nginx.conf. Unser Header-Generator erstellt den passenden Code.

PTR-Records werden nicht vom Domain-Inhaber gesetzt sondern vom IP-Adressinhaber - also dem Hosting-Provider oder Rechenzentrum. Du musst bei deinem Hoster oder ISP anfragen einen PTR-Record einzurichten. Bei Cloud-Anbietern (Hetzner, AWS, etc.) ist das oft im Control Panel direkt möglich.

Forward-Confirmed Reverse DNS bedeutet: PTR von IP → Hostname, und A-Record von Hostname → gleiche IP. Diese gegenseitige Bestätigung ist für E-Mail-Versand fast zwingend notwendig. Mailserver wie Gmail und Microsoft prüfen FCrDNS als Teil der Spam-Bewertung.

Häufige Ursachen: Server-Umzug ohne PTR-Aktualisierung, Shared Hosting wo der PTR auf den Hoster zeigt statt auf deine Domain, oder CDN-Nutzung wo die IP einem CDN-Anbieter gehört. Für E-Mail-Server ist ein übereinstimmender PTR wichtig - für Webserver meist nicht.

Ja. IPv6-PTR-Records liegen in der .ip6.arpa-Zone. Eine IPv6-Adresse wie 2001:db8::1 wird zu 1.0.0.0...1.b.d.0.1.0.0.2.ip6.arpa umgekehrt. Viele Server haben IPv6-PTR nicht konfiguriert, was bei IPv6-E-Mail-Versand zu Problemen führen kann.

Bei Hetzner: Server → Networking → PTR-Record eintragen. Bei AWS EC2: Elastic IP → Reverse DNS anfordern. Bei anderen Hostern: Support-Ticket mit gewünschtem Hostnamen und IP. Der Hostname muss per A-Record auf die IP zeigen bevor der PTR gesetzt werden kann.

Subdomain Takeover passiert wenn eine Subdomain per CNAME auf einen externen Dienst zeigt dessen Account gelöscht wurde. Ein Angreifer kann den Account neu anlegen und die Subdomain übernehmen. Hunderte Microsoft-Subdomains waren zeitweise übernehmbar. Regelmäßige Überprüfung ist wichtig.

Technisch unbegrenzt. Große Unternehmen haben oft Hunderte oder Tausende. Für kleine Websites sind 5–20 typisch (www, mail, api, blog, shop etc.). Wildcard-Einträge (*.example.com) erlauben beliebige Subdomains auf einmal.

Google behandelt Subdomains als separate Websites - sie teilen nicht automatisch die Autorität der Hauptdomain. blog.example.com rankt unabhängig von example.com. Für SEO ist ein Unterverzeichnis (example.com/blog/) daher oft besser als eine Subdomain da alle Backlinks der Hauptdomain zugutekommen.

Ein DNS-Eintrag *.example.com leitet alle Subdomains auf dieselbe IP. Praktisch für dynamisch erzeugte Subdomains (z.B. username.example.com). Sicherheitsrisiko: Eine Wildcard-Subdomain ohne korrekte Konfiguration kann Subdomain Takeover erleichtern.

Unser Finder nutzt Certificate Transparency Logs - jedes SSL-Zertifikat wird in öffentlichen Logs eingetragen und enthält alle SANs (Subdomains). Das ist die zuverlässigste Methode da keine aktiven Scans nötig sind. Passive Quellen wie crt.sh zeigen historische Daten.

Gmail (mit VMC-Pflicht), Yahoo Mail, Apple Mail (iOS/macOS), Fastmail und Cloudflare Area 1. Outlook und andere Microsoft-Dienste unterstützen BIMI bisher nicht. Die Abdeckung wächst aber stetig.

Ein Verified Mark Certificate (VMC) ist ein digitales Zertifikat das bestätigt dass du Inhaber der eingetragenen Marke bist. Ausgestellt von DigiCert oder Entrust, kostet ~1.000–1.500 €/Jahr. Google setzt ein VMC für die BIMI-Anzeige in Gmail voraus - andere Mailclients zeigen auch ohne VMC das Logo.

Tiny PS (Tiny Portable/Secure) ist eine sichere SVG-Untermenge die JavaScript, externe Ressourcen und gefährliche SVG-Features verbietet. Normales SVG wird von BIMI abgelehnt. Tools wie Inkscape können SVG-Dateien in Tiny PS konvertieren.

Nicht direkt - BIMI selbst ist kein Zustellbarkeits-Signal. Aber die Voraussetzungen (DMARC mit quarantine/reject) verbessern die Reputation erheblich. Studien zeigen dass BIMI-E-Mails bis zu 10% höhere Öffnungsraten erzielen weil das Logo Vertrauen signalisiert.

Das Logo muss quadratisch sein (1:1), darf keinen Hintergrund haben (transparent), und muss als Tiny PS SVG exportiert werden. Adobe Illustrator: Export as SVG → SVG Profiles: SVG Tiny 1.2. Inkscape: Speichern unter → Optimiertes SVG. Anschließend mit einem BIMI-SVG-Validator prüfen.

Physische Distanz (Lichtgeschwindigkeit im Kabel), überlastete Netzwerkknoten, schlechte Router-Konfiguration oder zu viele Hops. Ein CDN reduziert Latenz indem Inhalte näher beim Nutzer gespeichert werden.

Viele Server blockieren ICMP-Pakete per Firewall. Das bedeutet nicht dass der Server offline ist. HTTP-basierte Prüfungen sind zuverlässiger um festzustellen ob ein Webserver erreichbar ist.

Latenz ist die Verzögerungszeit (ms) - wie schnell ein einzelnes Paket ankommt. Bandbreite ist der Datendurchsatz (Mbit/s) - wie viel Daten pro Sekunde übertragen werden können. Eine Satellitenverbindung hat hohe Bandbreite aber hohe Latenz (500ms+). Glasfaser hat beides niedrig.

Time to First Byte ist die Zeit bis der Browser das erste Byte der Server-Antwort erhält. Er umfasst DNS-Lookup, TCP-Verbindung, TLS-Handshake und Server-Verarbeitung. Verbesserungen: schnelleres Hosting, Server-Caching (Redis, Memcached), CDN und Datenbankoptimierung.

Typisch sind 8–15 Hops zwischen zwei beliebigen Punkten im Internet. Mit traceroute (Windows: tracert) kannst du jeden Hop sehen. CDN-Anbieter wie Cloudflare reduzieren effektiv die Hop-Zahl da sie an Tausenden Standorten weltweit Präsenz haben.

E-Mail-Anbieter wie Google Workspace und Microsoft 365 generieren den DKIM-Schlüssel und geben dir den DNS-Eintrag. Der private Schlüssel bleibt beim Anbieter. Du musst nur den öffentlichen Schlüssel in deinem DNS hinterlegen.

SPF prüft ob die sendende IP autorisiert ist. DKIM prüft ob der E-Mail-Inhalt unverändert ist und vom angegebenen Server stammt. SPF schützt vor IP-Spoofing, DKIM vor Inhaltsverfälschung. DMARC baut auf beiden auf.

1024-Bit-RSA gilt heute als unsicher und kann theoretisch gebrochen werden. 2048 Bit ist der aktuelle Standard. Noch besser: Ed25519-Schlüssel - kürzer aber kryptografisch stärker. Google Workspace unterstützt Ed25519 bereits.

Die E-Mail wird nicht automatisch abgelehnt - das entscheidet DMARC. Ohne DMARC wird eine ungültige DKIM-Signatur von den meisten Servern ignoriert. Mit DMARC p=reject wird die E-Mail abgelehnt. Eine kaputte Signatur deutet auf Konfigurationsfehler oder E-Mail-Manipulation hin.

DKIM selbst kann nicht gefälscht werden - ohne den privaten Schlüssel ist es unmöglich eine gültige Signatur zu erstellen. Was Spammer tun: eigene Domains registrieren, dort DKIM korrekt einrichten und dann Spam versenden. DKIM authentifiziert die Domain, sagt aber nichts über deren Vertrauenswürdigkeit aus.

E-Mails an deine Domain werden nicht zugestellt. Absender erhalten eine Bounce-Nachricht. Mailserver versuchen 24–72 Stunden zu senden bevor sie endgültig aufgeben und eine Fehler-Benachrichtigung schicken.

Ja, das ist der Normalfall. Deine Website läuft auf einem Webhoster, E-Mails aber über Google Workspace oder Microsoft 365. Die MX-Records zeigen auf die Server des E-Mail-Anbieters - völlig unabhängig vom Webhosting.

Der Eintrag "domain IN MX 0 ." signalisiert explizit dass eine Domain keine E-Mails empfängt. Das verhindert dass Mailserver lange auf einen Bounce warten und reduziert Spam-Versuche. Für reine Website-Domains ohne E-Mail-Empfang empfehlenswert.

Abhängig von der TTL (Time to Live) des Records. Mit einer TTL von 3600 Sekunden (1 Stunde) dauert die Propagation bis zu einer Stunde. Tipp: TTL vor einer geplanten E-Mail-Migration auf 300 Sekunden senken damit Änderungen schnell wirksam werden.

MX-Failover bedeutet ein zweiter Mailserver übernimmt wenn der primäre nicht erreichbar ist. Einfach zwei MX-Records mit unterschiedlichen Prioritäten setzen (z.B. 10 und 20). Viele E-Mail-Anbieter wie Google Workspace liefern automatisch mehrere MX-Records für Redundanz.

Die meisten Internetanbieter blockieren Port 25 für Privatanschlüsse um Spam zu verhindern. Für Applikationen Port 587 mit STARTTLS oder Port 465 mit SSL nutzen. Port 25 ist für Server-zu-Server-Kommunikation reserviert.

Ein SMTP-Server der E-Mails für beliebige Empfänger von beliebigen Absendern akzeptiert. Spammer suchen automatisch nach solchen Servern. Folge: Sofortige Aufnahme in alle Blacklists. SMTP-Server sollten nur authentifizierte Nutzer und eigene Domains akzeptieren.

SMTP-Auth verlangt Benutzername und Passwort bevor E-Mails gesendet werden dürfen. Ohne Authentifizierung ist der Server ein Open Relay. Auf Port 587 und 465 ist SMTP-Auth Pflicht. Verwendet immer starke Passwörter und wo möglich App-spezifische Passwörter statt des Haupt-Passworts.

Greylisting ist eine Anti-Spam-Maßnahme: Unbekannte Absender werden beim ersten Versuch mit einem temporären Fehler abgewiesen. Legitime Mailserver wiederholen den Versuch nach einigen Minuten und werden dann akzeptiert. Spam-Bots wiederholen meist nicht. Nachteil: Erste E-Mails an neue Empfänger kommen mit 5–30 Minuten Verzögerung an.

Unser SMTP-Checker prüft Verbindung, TLS-Unterstützung und grundlegende Konfiguration. Für tiefergehende Tests: mail-tester.com zeigt einen umfassenden Score für Zustellbarkeit. MXToolbox SMTP Diagnostics prüft Blacklist-Status, PTR-Record und weitere Faktoren.

Bilder in WebP/AVIF konvertieren (60–80% Größenreduzierung), CSS und JS minifizieren, Browser-Caching aktivieren, CDN nutzen und unnötige Plugins entfernen. Diese Maßnahmen bringen den Score oft von 40 auf 80+.

PageSpeed-Score und wahrgenommene Ladezeit können auseinanderfallen. Der Score misst technische Metriken im Labor. Echte Nutzer haben verschiedene Geräte und Verbindungen. WebPageTest.org von verschiedenen Standorten aus gibt ein realistischeres Bild.

Seit dem Page Experience Update (2021) fließen Core Web Vitals direkt ins Google-Ranking ein. Besonders mobil ist der Effekt spürbar da Google Mobile-First-Indexing nutzt.

LCP ist das größte sichtbare Element beim Laden - meist ein Hero-Bild oder H1-Überschrift. Verbesserungen: Bild vorausladen mit <link rel="preload">, keine Lazy-Loading für Above-the-fold-Bilder, Bildgröße optimieren, schnellen Hosting-Server nutzen.

Cumulative Layout Shift misst unerwartete Verschiebungen im Layout. Häufige Ursachen: Bilder ohne definierte Breite/Höhe, nachgeladene Werbeanzeigen, Web-Fonts die Text verschieben und dynamisch eingefügter Inhalt. Lösung: Immer explizite Dimensionen für Bilder und Embeds setzen.

Forward Secrecy (PFS) bedeutet dass jede Sitzung einen eigenen temporären Schlüssel nutzt. Wird ein Schlüssel kompromittiert können vergangene Sitzungen nicht entschlüsselt werden. TLS 1.3 erzwingt Forward Secrecy, bei TLS 1.2 muss es explizit über ECDHE-Cipher-Suites konfiguriert werden.

Cipher-Suites sind Kombinationen aus Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung. Unsicher und zu deaktivieren: RC4 (gebrochen), 3DES (SWEET32-Angriff), DES, MD5, Export-Cipher. TLS 1.3 hat die Auswahl auf fünf starke Suites reduziert und unsichere komplett entfernt.

Bekannte TLS-Angriffe die veraltete Protokolle ausnutzen: POODLE (2014) macht SSL 3.0 unsicher, BEAST (2011) betrifft TLS 1.0 mit bestimmten Cipher-Suites, HEARTBLEED (2014) war ein OpenSSL-Bug der private Schlüssel leaken konnte. Alle drei sind durch aktuelle TLS-Versionen und gepatchte Software behoben.

OCSP Stapling ist eine Optimierung bei der der Server die Gültigkeitsbestätigung seines Zertifikats direkt in den TLS-Handshake einbettet. Ohne Stapling muss der Browser selbst beim CA-Server nachfragen - das kostet 100-300ms extra. Mit Stapling entfällt diese Anfrage und der Verbindungsaufbau wird schneller.

Unser TLS-Checker gibt eine schnelle Übersicht. Für detaillierte Analysen: SSL Labs (ssllabs.com/ssltest) gibt eine Note von A+ bis F mit genauer Aufschlüsselung aller Schwachstellen. testssl.sh ist ein Open-Source-Kommandozeilen-Tool für eigene Server ohne externe Dienste.

Apache-Header per .htaccess funktionieren mit aktivem mod_headers-Modul. Nginx-Konfiguration gehört in den server{}-Block. Auf Cloudflare lassen sich Header bequem über Transform Rules setzen ohne Serverkonfiguration zu ändern - ideal für Managed Hosting.

Ja, mit header("X-Frame-Options: SAMEORIGIN"); - aber nur bevor HTML ausgegeben wird. Für Content-Security-Policy empfiehlt sich die Serverkonfiguration da PHP-Header bei gecachten Seiten möglicherweise nicht gesetzt werden und Performance schlechter ist.

"Header set" gilt nur für erfolgreiche Antworten (HTTP 200). "Header always set" gilt für alle Statuscodes inklusive 3xx, 4xx und 5xx - wichtig damit Security-Header auch bei Fehlerseiten gesetzt werden. Immer "always set" verwenden.

X-Powered-By verrät die verwendete Technologie (PHP/7.4, ASP.NET etc.). Diese Information hilft Angreifern gezielt nach Schwachstellen dieser Version zu suchen. Entfernen in Apache: Header always unset X-Powered-By. In PHP: expose_php = Off in der php.ini.

Permissions-Policy (früher Feature-Policy) kontrolliert welche Browser-Features deine Seite und eingebettete Inhalte nutzen dürfen. Empfehlung für die meisten Websites: Kamera, Mikrofon, Geolocation, USB und Payment deaktivieren sofern nicht benötigt. Das verhindert dass eingebettete Scripts heimlich auf Hardware zugreifen.

Ja, massiv. Häufige Fehler: CSS- und JS-Dateien sperren (Google kann die Seite nicht rendern), Login-Seiten sperren die für internes Crawling nötig sind, oder versehentlich die gesamte Website mit "Disallow: /" sperren. Google Search Console warnt bei solchen Fehlern.

robots.txt verhindert das Crawlen - Google besucht die Seite nicht. Noindex verhindert das Indexieren - Google besucht die Seite aber nimmt sie nicht in den Index. Für Seiten die nicht in Suchergebnissen erscheinen sollen: Noindex nutzen. robots.txt nur für Bereiche die komplett ignoriert werden sollen.

Googlebot cached die robots.txt für 24 Stunden. Änderungen dauern bis zu einen Tag. Über die Google Search Console kann man Googlebot bitten die robots.txt sofort neu einzulesen und mit dem robots.txt-Tester Regeln überprüfen.

Ja - jeder User-agent-Block gilt für den genannten Bot. Du kannst Googlebot, Bingbot und andere separat konfigurieren. Bestimmte KI-Crawler wie GPTBot (OpenAI) oder CCBot lassen sich so gezielt sperren wenn du nicht möchtest dass deine Inhalte für KI-Training genutzt werden.

Das Crawl-Budget ist die Anzahl Seiten die Googlebot pro Tag crawlt. Bei großen Websites begrenzt Google das Budget. Schonen durch: Nicht-indexierbare Seiten (Paginierung, Filter-URLs) per robots.txt sperren, interne Duplikate vermeiden, Ladezeiten optimieren und kaputte Links beseitigen.

Nein. Eine Sitemap ist eine Einladung zum Crawlen, keine Garantie. Google entscheidet anhand von Qualität und PageRank welche Seiten indexiert werden. Seiten ohne Inhalt oder mit Duplicate Content werden auch mit Sitemap nicht indexiert.

Bei CMS wie WordPress generieren Plugins (Yoast SEO, RankMath) die Sitemap automatisch. Bei eigenen Systemen sollte die Sitemap dynamisch aus einer Datenbank generiert werden - genau wie unsere sitemap-audits.xml die alle analysierten Domains automatisch einträgt.

Bei über 50.000 URLs oder verschiedenen Inhaltskategorien empfiehlt sich ein Sitemap-Index: Eine Master-Datei die auf mehrere Sub-Sitemaps verweist (sitemap-blog.xml, sitemap-produkte.xml etc.). Das verbessert die Übersicht und erlaubt separate Einreichung einzelner Kategorien in der Search Console.

Priority (0.1–1.0) teilt Google die relative Wichtigkeit von Seiten mit. Google sagt selbst dass priority kaum Einfluss auf das Ranking hat und meist ignoriert wird. Sinnvoller ist es wichtige Seiten durch interne Verlinkung zu stärken. Trotzdem: Startseite 1.0, Hauptkategorien 0.8, Unterseiten 0.5–0.6.

Drei Wege: (1) Google Search Console → Sitemaps → URL eingeben und einreichen. (2) In robots.txt eintragen: "Sitemap: https://example.com/sitemap.xml" - Google findet sie beim nächsten Crawl automatisch. (3) Über die Ping-URL: fetch("https://www.google.com/ping?sitemap=...") nach jeder Aktualisierung.

"unsafe-inline" erlaubt inline-JavaScript und -CSS. Das ist der größte XSS-Angriffsvektor - eingeschleuster Code wird als inline betrachtet und ausgeführt. Moderne Alternative: Nonces (einmalige zufällige Werte) oder Hashes für spezifische Scripts erlauben ohne unsafe-inline zu brauchen.

Mit dem Content-Security-Policy-Report-Only Header. Er verhält sich identisch wie CSP, blockiert aber keine Ressourcen sondern sendet Verstöße an eine Report-URL. So kann man die CSP wochenlang testen und alle Verstöße sammeln bevor der echte Header aktiviert wird.

Eine Nonce ist ein zufälliger einmaliger Wert der bei jeder Anfrage neu generiert wird. Scripts mit dem passenden nonce-Attribut werden erlaubt, alle anderen geblockt. Das erlaubt inline-Scripts ohne unsafe-inline: script-src "nonce-abc123" und <script nonce="abc123">.

CSP blockiert standardmäßig alle externen Quellen die nicht explizit erlaubt sind. Für Google Analytics muss script-src *.google-analytics.com und connect-src stats.g.doubleclick.net erlaubt sein. Für Google Fonts: style-src fonts.googleapis.com und font-src fonts.gstatic.com. Unser CSP-Checker zeigt alle erkannten Verstöße.

WordPress mit vielen Plugins ist CSP-technisch herausfordernd da viele Plugins inline-Scripts nutzen. Empfehlung: Mit Report-Only starten, alle Verstöße 2-4 Wochen sammeln, dann eine Whitelist erstellen. Das Plugin "CSP Manager" hilft bei der Verwaltung. Vollständige CSP ohne unsafe-inline ist bei Standard-WordPress kaum erreichbar.

Grundlage ist die übertragene Datenmenge (KB) multipliziert mit einem Energiefaktor für Netzwerk, Server und Endgerät. Der Website Carbon Calculator nutzt ca. 1,805 kWh pro GB Datentransfer. Dazu kommt der CO₂-Faktor des Strommixes - bei grünem Hosting deutlich niedriger.

Green Hosting bedeutet der Rechenzentrum-Betreiber nutzt 100% erneuerbare Energien oder kompensiert seinen Verbrauch vollständig. Zertifizierte Anbieter in Deutschland: Hetzner (eigene Wasserkraft), netcup (100% Ökostrom), Greenesta. Die Green Web Foundation führt eine öffentliche Datenbank unter thegreenwebfoundation.org.

Indirekt - eine schlanke schnelle Website hat automatisch weniger CO₂-Fußabdruck und rankt durch besseren PageSpeed besser. "Green Hosting" ist kein direkter Google-Rankingfaktor, aber Google hat signalisiert dass Nachhaltigkeit langfristig eine Rolle spielen könnte.

Reduktion bedeutet weniger Energie verbrauchen - durch optimierten Code, kleinere Dateien und effiziente Server. Kompensation bedeutet den unvermeidbaren Verbrauch durch Investitionen in erneuerbare Energien oder Aufforstung ausgleichen. Reduktion ist immer besser als Kompensation da keine Energie "zurückgeholt" werden kann.

Die Sustainable Web Manifesto-Initiative versammelt Unternehmen die sich zu nachhaltigem Web-Design verpflichten. Große Tech-Unternehmen wie Google, Microsoft und Shopify haben eigene Net-Zero-Ziele. Für kleine Websites ist Green Hosting die einfachste und wirkungsvollste Maßnahme.

Server-Caching (Redis, Full Page Cache), Datenbankabfragen optimieren, PHP OpCache aktivieren und CDN einsetzen sind die wirkungsvollsten Maßnahmen. Ein hoher TTFB ist fast immer ein serverseitiges Problem.

TTFB misst nur bis zum ersten Byte - die eigentliche Übertragung kommt danach. Ein guter TTFB bedeutet der Server antwortet schnell, aber eine große Seite kann trotzdem langsam laden. Beide Werte sind wichtig.

DNS wird gecacht, TCP-Verbindungen können wiederverwendet werden, Server-Last schwankt. Mehrere Messungen zu verschiedenen Zeiten geben ein realistischeres Bild als eine einzelne Messung.

HTTP/3 verwendet QUIC statt TCP und eliminiert Head-of-Line-Blocking. Besonders auf mobilen Verbindungen deutlich schneller. Chrome, Firefox und viele CDNs unterstützen HTTP/3 bereits.

TLS 1.3 aktivieren, OCSP Stapling einrichten, Session Tickets aktivieren und Server geografisch nah zu den Nutzern platzieren oder ein CDN nutzen.

Nein, direkt nicht. Google ignoriert die Meta-Description fürs Ranking. Aber sie erscheint in Suchergebnissen und beeinflusst die Click-Through-Rate. Höhere CTR signalisiert Relevanz und kann indirekt das Ranking verbessern. Google überschreibt die Description manchmal mit eigenem Text wenn er relevanter erscheint.

Social-Media-Plattformen wählen automatisch ein Bild aus - oft das erstbeste unpassende. Das wirkt unprofessionell und reduziert Klicks. og:image sollte mindestens 1200×630 Pixel groß sein für optimale Darstellung. Für Twitter/X sind 1200×628 px ideal.

Google zeigt in Suchergebnissen ca. 50–60 Zeichen des Titles. Längere Titles werden abgeschnitten. Das Haupt-Keyword sollte möglichst am Anfang stehen da Google frühe Keywords höher gewichtet. Der Markenname kommt ans Ende: "Keyword | Marke" ist besser als "Marke | Keyword".

Der title-Tag wird von Suchmaschinen und Browser-Tabs genutzt. og:title wird von Social-Media-Plattformen beim Teilen genutzt. Beide können unterschiedlich sein - für Social Media darf og:title etwas werblicher formuliert sein während der title SEO-optimiert bleibt.

Unser Meta-Tag-Checker zeigt eine Vorschau der Google-Darstellung direkt im Tool. Alternativ: Google Search Console → URL-Prüfung zeigt wie Google die Seite sieht. Der Rich Results Test prüft ob strukturierte Daten (Schema.org) korrekt sind und für Rich Snippets qualifizieren.

Google bestraft Duplicate Content nicht aktiv - es wählt eine Version als kanonisch aus und ignoriert die anderen. Das kann dazu führen dass die falsche URL rankt oder Backlinks aufgeteilt werden. Canonical-Tags und 301-Redirects lösen das Problem zuverlässig.

Es gibt keine offizielle Google-Grenze. Als Faustregel: über 85% Übereinstimmung ist problematisch. Unser Duplicate-Content-Checker berechnet die Cosine-Similarity zwischen zwei URLs - über 70% ist ein Warnsignal, über 85% sollte eine Maßnahme ergriffen werden.

Ein Canonical-Tag (<link rel="canonical" href="...">) sagt Google welche URL die bevorzugte Version ist. Sinnvoll wenn technische Gründe mehrere URLs für denselben Inhalt erfordern z.B. bei URL-Parametern für Sortierung und Filterung. Für echte Duplikate ist ein 301-Redirect die stärkere Maßnahme.

Nicht zwingend - wenn du der Original-Autor bist und der Artikel zuerst auf deiner Website erscheint. Wichtig: canonical-Tag auf die Original-URL setzen, idealerweise auf deiner Domain publizieren bevor der Gastbeitrag erscheint. Google erkennt in der Regel das Original und wertet es höher.

Unser Tool prüft zwei URLs direkt. Für eine vollständige Website-Analyse: Screaming Frog (bis 500 URLs kostenlos) findet doppelte Title-Tags, Descriptions und Inhalte. Google Search Console zeigt unter "Abdeckung" Seiten die Google als Duplikate erkennt und nicht indexiert.

Direkt wenig - Google wertet einzelne defekte Bilder nicht als starken Rankingfaktor. Aber sie verschlechtern die User Experience und erhöhen die Absprungrate. Alt-Text von defekten Bildern verliert seine Wirkung. Bei vielen defekten Ressourcen wird das Crawl-Budget ineffizient genutzt.

Alle Bild-URLs in der Datenbank nach dem Umzug aktualisieren (bei WordPress hilft "Better Search Replace"), oder 301-Redirects für alte Pfade einrichten. Nach dem Umzug Screaming Frog über die gesamte Website laufen lassen um alle defekten Ressourcen zu finden.

Hotlinking bedeutet Bilder von einem fremden Server direkt einzubinden statt sie selbst zu hosten. Das verbraucht die Bandbreite des fremden Servers ohne dessen Erlaubnis. Viele Server sperren Hotlinking per .htaccess - dann erscheint das Bild als defekt. Immer eigene Kopien von Bildern hosten.

Per JavaScript: img.onerror = function(){this.src='/fallback.jpg'}. Per CSS ist kein echter Fallback möglich aber man kann den alt-Text stylen um gut auszusehen wenn das Bild nicht lädt. Am besten: defekte Bilder direkt beheben statt mit Fallbacks zu maskieren.

Unser Broken-Image-Finder prüft eine URL auf defekte Bilder. Für die gesamte Website: Screaming Frog (Response Codes filtern auf 4xx für Bilder), Google Search Console zeigt unter "Abdeckung" Crawl-Fehler, und Browser DevTools (Netzwerk-Tab) zeigt beim Laden einer Seite alle fehlgeschlagenen Bild-Anfragen.

Nein - Google rankt Seiten nicht direkt nach HTML-Validität. Aber strukturell sauberes HTML hilft Googlebot die Seite korrekt zu verstehen. Kritische Fehler wie fehlende alt-Tags, doppelte H1-Überschriften oder fehlerhafte kanonische Links haben direkten SEO-Einfluss.

Ohne korrekten DOCTYPE schalten Browser in den Quirks-Mode und emulieren altes Browser-Verhalten aus den 1990ern. Das führt zu unvorhersehbarem Rendering. Lösung: Immer als erste Zeile setzen - das aktiviert den Standards-Mode in allen modernen Browsern.

HTML-Validierung prüft technische Korrektheit nach W3C-Standard. Barrierefreiheit (WCAG) geht weiter: ausreichende Farbkontraste, Tastaturnavigation, ARIA-Labels für Screenreader, sinnvolle Überschriften-Hierarchie. Eine valide Seite kann dennoch schlecht zugänglich sein.

Kritisch: fehlende oder doppelte title-Tags, fehlende meta-charset-Angabe (führt zu Zeichensatz-Problemen), fehlendes lang-Attribut im html-Tag (wichtig für Screenreader und SEO), doppelte IDs (bricht JavaScript und CSS) und fehlende alt-Attribute bei Bildern.

HTML5 ist der aktuelle Standard - fehlertoleranter, mit semantischen Tags wie <article>, <section>, <nav>. XHTML war strenger (alle Tags mussten geschlossen sein, Kleinschreibung Pflicht) und ist heute kaum noch im Einsatz. HTML5 mit sauberem Code ist für neue Projekte immer die richtige Wahl.

Nein - Google hat keine offizielle Grenze. Als Faustregel gilt 1–3% für das Haupt-Keyword. Wichtiger als die Dichte ist der natürliche Lesefluss: Wenn ein Text sich für Menschen gut liest und das Thema umfassend behandelt ist die Keyword-Dichte meist automatisch im richtigen Bereich.

Keyword Stuffing ist das übermäßige, unnatürliche Wiederholen von Keywords um Rankings zu manipulieren. Google erkennt es durch maschinelles Lernen und kann die Seite manuell oder algorithmisch bestrafen - bis hin zur kompletten Deindexierung. Auch versteckte Keywords (weißer Text auf weißem Hintergrund) werden erkannt und streng bestraft.

LSI (Latent Semantic Indexing) Keywords sind thematisch verwandte Begriffe. Für "SEO-Analyse" wären das: Webseitenanalyse, Google Ranking, Suchmaschinenoptimierung, Backlinks. Google nutzt semantische Analyse um zu verstehen ob eine Seite ein Thema wirklich tief behandelt. Synonyme und Verwandte stärken die thematische Autorität.

Unser Keyword-Density-Checker zeigt die häufigsten Begriffe einer URL. Für tiefere Analyse: Sistrix, Semrush oder Ahrefs zeigen für welche Keywords eine Seite rankt. Google Search Console zeigt welche Suchanfragen Traffic auf deine Seite bringen - oft gibt es überraschende Keywords für die man unbeabsichtigt rankt.

TF-IDF (Term Frequency–Inverse Document Frequency) ist ein statistisches Maß das bewertet wie relevant ein Begriff für ein Dokument im Vergleich zu allen anderen Dokumenten ist. Es berücksichtigt dass häufige Wörter wie "und" oder "ist" wenig Bedeutung haben. Moderne SEO-Tools nutzen TF-IDF um zu bestimmen welche Begriffe in einem Text fehlen im Vergleich zu Top-Rankings.

Open Graph Tags werden von Facebook, LinkedIn, WhatsApp und den meisten Plattformen genutzt. Twitter/X hat ein eigenes System - Twitter Cards mit twitter:card, twitter:title etc. Viele Plattformen nutzen OG als Fallback wenn keine Twitter Cards gesetzt sind. Für maximale Kompatibilität beides setzen.

Facebook cached OG-Daten aggressiv. Lösung: Facebook Sharing Debugger (developers.facebook.com/tools/debug) aufrufen, die URL eingeben und auf "Scrape Again" klicken. Das erzwingt eine Aktualisierung des Caches. LinkedIn hat einen ähnlichen Post Inspector unter linkedin.com/post-inspector.

1200×630 Pixel ist der Standard für die meisten Plattformen (Seitenverhältnis 1.91:1). WhatsApp schneidet auf 1:1 zu. Für maximale Kompatibilität: ein quadratisches Bild (1200×1200) vermeidet ungewolltes Zuschneiden auf allen Plattformen. Text im Bild immer in der Mitte platzieren.

og:type="article" ist für Blogbeiträge, News und redaktionelle Inhalte. Es erlaubt zusätzliche Tags wie article:published_time, article:author und article:section. Facebook zeigt bei article-Typ den Autornamen prominent. Für Produktseiten: og:type="product", für Videos: og:type="video.movie".

Unser OG-Tag-Generator und -Checker zeigt eine Vorschau direkt im Tool. Für Plattform-spezifische Tests: Facebook Sharing Debugger, LinkedIn Post Inspector, Twitter Card Validator (cards-dev.twitter.com/validator) und opengraph.xyz für eine Übersicht aller Plattformen gleichzeitig.

Für aktive Websites empfiehlt sich ein monatlicher Check. Externe Links veralten schneller als interne - Websites verschwinden, URLs ändern sich.

Direkt auf die finale URL verlinken. Redirect-Ketten kosten unnötig PageRank und verlangsamen das Crawling.

Beide sind schlecht, aus unterschiedlichen Gründen. Interne Broken Links blockieren Crawling. Externe schaden der Nutzererfahrung und der wahrgenommenen Qualität.

Einige Server blockieren Bot-Anfragen mit 403 obwohl der Link für Menschen funktioniert. LinkedIn und viele Login-Seiten tun das - manuelles Überprüfen empfiehlt sich.

Intern: URL korrigieren oder 301-Redirect. Extern: Alternative Quelle finden oder Link entfernen. Die Wayback Machine hilft bei dauerhaft verschwundenen Seiten.

PageSpeed Insights (PSI) kombiniert Lighthouse-Labordaten mit echten Nutzerdaten aus dem Chrome User Experience Report (CrUX). Lighthouse allein ist ein Labortest - PSI zeigt zusätzlich wie echte Nutzer die Seite erleben. Für SEO sind die CrUX-Daten in PSI relevanter da Google sie direkt fürs Ranking nutzt.

Lighthouse-Scores variieren natürlich um 5–10 Punkte je nach Netzwerkbedingungen, Serverlast und Browser-Hintergrundprozessen. Für aussagekräftige Ergebnisse: mehrfach messen und Durchschnitt bilden, im Inkognito-Modus testen (keine Extensions), auf Throttling achten (Lighthouse simuliert standardmäßig eine langsamere Verbindung).

Time to Interactive ist die Zeit bis die Seite vollständig geladen und für Nutzerinteraktion bereit ist - alle Scripts ausgeführt, Hauptthread frei. Eine Seite kann visuell fertig aussehen (LCP gut) aber noch nicht interaktiv sein. Langes TTI entsteht durch zu viel JavaScript das den Hauptthread blockiert.

Häufige Probleme: fehlende alt-Texte bei Bildern, zu geringer Farbkontrast (Mindest-Verhältnis 4,5:1 für normalen Text), fehlende Labels bei Formularfeldern, nicht tastaturnavigierbare Elemente, fehlende Sprach-Angabe im html-Tag. Das axe-Browser-Plugin hilft bei der detaillierten Analyse.

Ja - Lighthouse CI (github.com/GoogleChrome/lighthouse-ci) lässt sich als GitHub Action einrichten und blockiert Deployments wenn der Score unter einen definierten Schwellenwert fällt. So werden Performance-Regressionen automatisch erkannt bevor sie in Produktion gehen. Für kleinere Projekte reicht der manuelle Check über PageSpeed Insights.